[ntpwg] Stronger symmetric NTP authentication
David L. Mills
mills at udel.edu
Fri Dec 12 00:51:07 UTC 2008
Greg,
My proposal was not intended to be a generic solution, but rather a
practical approach that would work in most cases without rewriting the
protocol and causing version warp. Most would agree that, if the digest
is 16 octets, the only reasonable choice is MD5. Most would agree on a
common denominator for a 20-octet digest, but I won't hazard which at
this time. My orginal proposal was for the client to keep an
individually configured list of NIDs and use them in round-robin order
if a MAC fails. This assumes only a small number of choices are
available for the servers.
Save fancier schemes for some future NTP protocol rewrite. Frankly, I
don't see the wisdom of a backwards incompatible protocol rewrite if the
only reason is to provide completely general selection of algortihm.
I don't know if the OpenSSL NID conforms to the ISO or not, but from a
practical standpoint it doesn't matter. I and those appl;ication
developers known to me use the OpenSSL library because it is freely
available, not ITAR vulnerable and the NID selection is on the basis of
a printable ASCII string as a configuration parameter. The use of some
other library with incompatible interface or different string mappings
or ITAR vulnerable is simply not in the cards.
Dave
Greg Dowd wrote:
>I'm not quite following this proposal. If the client gets to choose an
>algorithm to associate with a particular digest size, how would the
>server know which one was chosen. The example of version is an invalid
>case as version is transferred in the frame. Where would NID be
>transferred? Also, is NID proprietary to OpenSSL? If it human readable
>for config file usage? If these are issues, wouldn't we rather select
>by ISO OID? Not that I'm saying that is legible.
>
>-----Original Message-----
>From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org
>[mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of
>David L. Mills
>Sent: Thursday, December 11, 2008 5:39 AM
>To: ntpwg at lists.ntp.org
>Subject: Re: [ntpwg] Stronger symmetric NTP authentication
>
>Danny,
>
>I repeat. Whatever is in OpenSSL, specifically the NID for each
>algorithm, is transparent and NTP could in principle support any of
>them.
>
>Dave
>Danny Mayer wrote:
>
>
>
>>David L. Mills wrote:
>>
>>
>>
>>
>>>Danny,
>>>
>>>I don't understand your objection. There already is a different NID
>>>
>>>
>for
>
>
>>>each algorithm and a matching ASCII string defined in the OpenSSL
>>>library. In the scheme I proposed the operator selects NIDs for
>>>
>>>
>16-octet
>
>
>>>or 20-octet digests or both. Normally the client would select one
>>>16-octet MD5 and one 20-octet SHA or whatever as defaults. The server
>>>would select either based on the client request digest size and reply
>>>with the same NID. This is the same paradigm as selecting the version
>>>number when replying to a client request.
>>>
>>>
>>>
>>>
>>>
>>What I mean is that the ID's need to be specific algorithm identifiers,
>>that's all. SHA-1 comes in different flavors and strengths, for
>>
>>
>example.
>
>
>>The protocol just needs to understand what the specific algorithm is. I
>>have no problem with the rest.
>>
>>Danny
>>
>>
>>
>>
>>
>>>The scheme I suggested is a natural extension, providing multiple NIDs
>>>
>>>
>
>
>
>>>when more than one NID for each digest size is available. Most
>>>
>>>
>operators
>
>
>>>not care to use it, but it would support a more complicated setup
>>>
>>>
>should
>
>
>>>some diversity remain in the digest proponent community.
>>>
>>>Dave
>>>
>>>Danny Mayer wrote:
>>>
>>>
>>>
>>>
>>>
>>>>David L. Mills wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Brian,
>>>>>
>>>>>The new interleaved modes aren't in the specification either.
>>>>>
>>>>>
>However,
>
>
>>>>>servers and clients automatically back out of these modes if the
>>>>>
>>>>>
>server
>
>
>>>>>or client is not equipped for them. So, the operation is completely
>>>>>transparent. The current development version supporting these modes
>>>>>
>>>>>
>is
>
>
>>>>>on all our public and private servers and clients. Yes, it is in the
>>>>>
>>>>>
>web
>
>
>>>>>document collection and further described in the white paper on the
>>>>>
>>>>>
>NTP
>
>
>>>>>Project Page.
>>>>>
>>>>>A similar thing can be done for 20-octet digests. The original plan
>>>>>
>>>>>
>for
>
>
>>>>>this was formulated several years ago. The parsing rules provide
>>>>>
>>>>>
>for
>
>
>>>>>8-octet (DES), 16-octet (MD5) and 20-octet (SHA) digests. This does
>>>>>
>>>>>
>not
>
>
>>>>>change the specification other than to require extension fields to
>>>>>
>>>>>
>have
>
>
>>>>>a minimum of two 32-bit words with 16-octet digests. A simple
>>>>>
>>>>>
>extension
>
>
>>>>>field test would even detect an extension field of only one word.
>>>>>
>>>>>The parsing rules detect the digest as a function of the number of
>>>>>
>>>>>
>words
>
>
>>>>>following the NTP payload including extension fields):
>>>>>
>>>>>0 none (no extension fields)
>>>>>1 crypto-NAK
>>>>>2 invalid
>>>>>3 DES (no extension fields)
>>>>>4 invalid
>>>>>5 MD5 minimum extension field two words)
>>>>>6 SHA (minimum extension field one word)
>>>>>7 or more extension field
>>>>>
>>>>>For all extension fields now defined the minimum extension field
>>>>>
>>>>>
>length
>
>
>>>>>is two words.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>This won't work since each digest algorithm will give a different
>>>>
>>>>
>digest
>
>
>>>>output and you should not assume that the length is sufficient to
>>>>
>>>>
>tell
>
>
>>>>you the difference. You actually need different id's for each digest
>>>>algorithm.
>>>>
>>>>Danny
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The interoperability and configuration rules are proposed as
>>>>>
>>>>>
>follows:
>
>
>>>>>A host is configured to support specified algorithms for both 16-
>>>>>
>>>>>
>and
>
>
>>>>>20-octet digests. This includes all algorithms supported by the
>>>>>
>>>>>
>OpenSSL
>
>
>>>>>library with the expected defaults. A new configuration command
>>>>>
>>>>>digest <NID> ...
>>>>>
>>>>>Where NID is consistent with OpenSSL NIDs used in the crypto
>>>>>
>>>>>
>command.
>
>
>>>>>There can be one NID or several in a circular list. The digest size
>>>>>
>>>>>
>is
>
>
>>>>>implicitin the NID. The client and symmetric peer maintains a
>>>>>
>>>>>
>pointer
>
>
>>>>>to the current NID. When a digest arrives, the first NID with
>>>>>
>>>>>
>matching
>
>
>>>>>digest size is used for subsequent packets. In case of crypto NAK,
>>>>>
>>>>>
>the
>
>
>>>>>next NID on the list is used, whether that be 16 or 20 octets. In
>>>>>principle, the list could be populated with all OpenSSL digest NIDs
>>>>>
>>>>>
>and
>
>
>>>>>a caller with any of them would clank around until a matching pair
>>>>>
>>>>>
>was
>
>
>>>>>found.
>>>>>
>>>>>Operation with a stateless server with lots of clients would be
>>>>>
>>>>>
>somewhat
>
>
>>>>>messy with a mixture of clients using different NIDs. Normally there
>>>>>
>>>>>
>
>
>
>>>>>would be one NID for 16-octet digests and another for 20-octet
>>>>>
>>>>>
>digests.
>
>
>>>>>The server would select either depending on the client request and
>>>>>
>>>>>
>use
>
>
>>>>>the same one for the server reply.
>>>>>
>>>>>Note the digest size determines the size of the key material
>>>>>
>>>>>
>prepended
>
>
>>>>>by the keyed-MD5 operation defined by the RFC. So far as I know, a
>>>>>similar operation has not been defined for digests other than MD5,
>>>>>
>>>>>
>but
>
>
>>>>>the extension is obvious.
>>>>>
>>>>>Dave
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>_______________________________________________
>>>ntpwg mailing list
>>>ntpwg at lists.ntp.org
>>>https://lists.ntp.org/mailman/listinfo/ntpwg
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>_______________________________________________
>ntpwg mailing list
>ntpwg at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/ntpwg
>
>
More information about the ntpwg
mailing list