[ntpwg] Stronger symmetric NTP authentication
David L. Mills
mills at udel.edu
Sat Dec 6 00:10:31 UTC 2008
Greg,
Your suggestion would preclude the use of Autokey. Even if this is
acceptable, the 16-bit key space is already too small to partition.
Dave
Greg Dowd wrote:
>Since MAC always includes keyed, why not let the key id specify the
>expected hash length, as opposed to a separate configuration element.
>The rest of the rules would still apply. That is actually the current
>definition, although I haven't seen a DES key used in a while.
>
>-----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: Friday, December 05, 2008 1:21 PM
>To: ntpwg at lists.ntp.org
>Subject: Re: [ntpwg] Stronger symmetric NTP authentication
>
>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.
>
>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
>implicit in 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
>
>Brian Utterback wrote:
>
>
>
>>I realize that. But the point I am making is that if we can change the
>>
>>
>
>
>
>> format of the packet, then adding longer MAC hashes is trivial, just
>>make the field bigger and add whatever you need to get to work. So, I
>>presume that the discussion in this thread is how to do this in a
>>backwards compatible manner within the existing format.
>>
>>Danny Mayer wrote:
>>
>>
>>
>>>Brian Utterback wrote:
>>>
>>>
>>>
>>>>Wasn't the whole point of this discussion about how to do it without
>>>>changing (or not incompatibly changing) the protocol? If we are
>>>>going to
>>>>allow a change in the protocol, then simply make the MAC field
>>>>
>>>>
>variable
>
>
>>>>length we're pretty much done.
>>>>
>>>>
>>>>
>>>No, you also have to identify the digest type or you will have
>>>interoperability issues. it's not just a matter of specifying the MAC
>>>field length.
>>>
>>>Danny
>>>
>>>
>>>
>>>>Danny Mayer wrote:
>>>>
>>>>
>>>>
>>>>>In addition this would require an update to the NTPv4 protocol.
>>>>>
>>>>>Danny
>>>>>David L. Mills wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Brian,
>>>>>>
>>>>>>Publish my list? At the top is work for JPL on time
>>>>>>
>>>>>>
>synchronization
>
>
>>>>>>in space, followed closely by a second edition of my book. At the
>>>>>>moment, there is nothing about NTP on that list, but that could
>>>>>>change.
>>>>>>
>>>>>>The work to bring up a 20-octet digest is messy. In principle it
>>>>>>
>>>>>>
>is
>
>
>>>>>>easy, as the required crypto code is already available in OpenSSL
>>>>>>
>>>>>>
>and
>
>
>>>>>>the NTP crypto interface is the same. However, the ick comes in
>>>>>>
>>>>>>
>the
>
>
>>>>>>build and configuration code and interaction with various defines
>>>>>>scattered all over the code.
>>>>>>
>>>>>>For instance, the OPENSSL define is lit when the OpenSSL library
>>>>>>
>>>>>>
>is
>
>
>>>>>>present and in that case lights up Autokey. Probably, if you need
>>>>>>only HMAC and don't want Autoke, that has to change. Also, it
>>>>>>
>>>>>>
>could
>
>
>>>>>>be that somebody wants HMAC with Autokey.
>>>>>>
>>>>>>Next, the crypto command is used to configure Autokey now. Some
>>>>>>change to th econfiguration syntax and semantics would need to be
>>>>>>done to configure HMAC separatly from the digest/signature
>>>>>>combinations now supported. Those combinations are built in the
>>>>>>OpenSSL library and passed transparently by th econfiguration
>>>>>>
>>>>>>
>code..
>
>
>>>>>>Next, some considerations need to be implemented to handle cases
>>>>>>where the digests are mismatched. An innocent client equipped with
>>>>>>both MD5 and HMAC would need to automatically reconfigure when
>>>>>>presented with one or the other. This might apply also if other
>>>>>>digest algorithms were available.
>>>>>>
>>>>>>Next, the key cache code would need to be modified to support
>>>>>>20-octet keys. This is in principle not hard, but needs review. My
>>>>>>approach would be to allow keys of any length independent of
>>>>>>
>>>>>>
>digest
>
>
>>>>>>algorithm, but that requires overhaul of the cache code.
>>>>>>
>>>>>>I'm really opposed to a hack; the issues should be thought through
>>>>>>and carefully integrated in a seamless design.
>>>>>>
>>>>>>Dave
>>>>>>
>>>>>>Brian Utterback wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I happen to agree with you Dave. We don't need to implement this
>>>>>>>ASAP. On the other hand, you say that the design has provisions
>>>>>>>
>>>>>>>
>to
>
>
>>>>>>>support 20-octet digests, but that it isn't high on the list.
>>>>>>>
>>>>>>>
>>>>>>>I would like to suggest that you publish your list and provide
>>>>>>>
>>>>>>>
>the
>
>
>>>>>>>notes you have on the line items. The beauty of open source is
>>>>>>>
>>>>>>>
>that
>
>
>>>>>>>with enough hands, "all problems are shallow". Keep the list to
>>>>>>>yourself, and one or two of the top items may get implemented.
>>>>>>>Publish the list and probably two or three times as many will
>>>>>>>eventually happen, although not necessarily in your priority
>>>>>>>
>>>>>>>
>order.
>
>
>>>>>>>Their are hands available to you Dave, if you would just allow
>>>>>>>
>>>>>>>
>them
>
>
>>>>>>>to help.
>>>>>>>
>>>>>>>
>>>>>>>David L. Mills wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Manav,
>>>>>>>>
>>>>>>>>
>>>>>>>>Will you read my messages again? I don't disagree it would be a
>>>>>>>>good idea to implement a 20-octet digest; in fact, as I said
>>>>>>>>previously, there are already provisions for that in the design
>>>>>>>>
>>>>>>>>
>to
>
>
>>>>>>>>suppor that. However, in the wisdom of good engineering design
>>>>>>>>
>>>>>>>>
>and
>
>
>>>>>>>>utilization of current resources, this is not likely to be done
>>>>>>>>soon. There are lots of other projects of importance in the
>>>>>>>>evolution of NTP and this is not one of urgent priority. An
>>>>>>>>advocacy to implement a 20-octet digest based purely on he
>>>>>>>>perceived hazard of possible masquerade without consideration of
>>>>>>>>the overall security hazard is simply not a good engineering
>>>>>>>>strategy.
>>>>>>>>
>>>>>>>>
>>>>>>>>If your point is that NIST says SHA is good and MD5 is bad based
>>>>>>>>
>>>>>>>>
>on
>
>
>>>>>>>>nothing other than demonstration that it is possible so spoof a
>>>>>>>>digest with a contrived but necessarily invalid NTP message,
>>>>>>>>
>>>>>>>>
>then I
>
>
>>>>>>>>suggest there is something seriously wrong with the security
>>>>>>>>analysis. This point is stressed in the course I teach on
>>>>>>>>
>>>>>>>>
>computer
>
>
>>>>>>>>security.
>>>>>>>>
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>
>>>>>>>>DaeBhatia, Manav (Manav) wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Tony,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>This is not applicable to most usages of HMAC-MD5 for two
>>>>>>>>>>
>>>>>>>>>>very good reasons:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>If you read draft-ietf-ntp-ntpv4-proto-11 you will realize that
>>>>>>>>>NTP uses
>>>>>>>>>
>>>>>>>>>MD5 and not HMAC-MD5.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>I totally agree that the attacks may not necessarily result in
>>>>>>>>>direct
>>>>>>>>>
>>>>>>>>>vulnerabilities in MD5 as used in NTP authentication purposes,
>>>>>>>>>because
>>>>>>>>>
>>>>>>>>>the colliding message may not necessarily be a syntactically
>>>>>>>>>correct
>>>>>>>>>
>>>>>>>>>protocol packet. However, there is a need felt to move away
>>>>>>>>>from MD5
>>>>>>>>>
>>>>>>>>>towards more complex and difficult to break hash algorithms and
>>>>>>>>>
>>>>>>>>>
>
>
>
>>>>>>>>>I was
>>>>>>>>>
>>>>>>>>>just trying to propose an extension that does just that. One
>>>>>>>>>cannot
>>>>>>>>>
>>>>>>>>>always assume that the authentication data would *always* be
>>>>>>>>>just 16
>>>>>>>>>
>>>>>>>>>octets (unless somebody is thinking of truncating the SHA hash
>>>>>>>>>
>>>>>>>>>
>:))
>
>
>>>>>>>>>At the very least, NTP should be using the HMAC construct along
>>>>>>>>>with MD5
>>>>>>>>>
>>>>>>>>>as against plain MD5 that the spec mandates.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Cheers, Manav
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>
>>>>>>>>>>From: Tony Li [mailto:tony.li at tony.li]
>>>>>>>>>>
>>>>>>>>>>Sent: Tuesday, December 02, 2008 8.26 AM
>>>>>>>>>>
>>>>>>>>>>To: Bhatia, Manav (Manav); 'David L. Mills'
>>>>>>>>>>
>>>>>>>>>>Cc: ntpwg at lists.ntp.org
>>>>>>>>>>
>>>>>>>>>>Subject: RE: [ntpwg] Stronger symmetric NTP authentication
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Hi all,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>|Current NTP specs provide provision for only MD5 digests (16
>>>>>>>>>>octets).
>>>>>>>>>>
>>>>>>>>>>|This is not good enough, as there have been attacks found
>>>>>>>>>>against MD5
>>>>>>>>>>
>>>>>>>>>>|and the IETF community is moving away from this towards
>>>>>>>>>>
>>>>>>>>>>
>stronger
>
>
>>>>>>>>>>hash
>>>>>>>>>>
>>>>>>>>>>|algorithms (HMAC-SHA-1, HMAC-SHA-224, etc).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>This is vastly misleading. The literature documents the
>>>>>>>>>>
>>>>>>>>>>ability to find
>>>>>>>>>>
>>>>>>>>>>collisions against straight MD5 hashing. Thus, given a
>>>>>>>>>>
>>>>>>>>>>plaintext block and
>>>>>>>>>>
>>>>>>>>>>a hash result, it is possible to compute a specific alternate
>>>>>>>>>>
>>>>>>>>>>plaintext
>>>>>>>>>>
>>>>>>>>>>block that would produce the same hash result.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>This is not applicable to most usages of HMAC-MD5 for two
>>>>>>>>>>
>>>>>>>>>>very good reasons:
>>>>>>>>>>
>>>>>>>>>>first, there is typically a password or other key material
>>>>>>>>>>
>>>>>>>>>>concatenated with
>>>>>>>>>>
>>>>>>>>>>the plaintext block before hashing. The password is presumably
>>>>>>>>>>
>>>>>>>>>>
>
>
>
>>>>>>>>>>not
>>>>>>>>>>
>>>>>>>>>>available to the attacker. [If it is, the algorithm is
>>>>>>>>>>
>>>>>>>>>>irrelevant. ;-)]
>>>>>>>>>>
>>>>>>>>>>No one has demonstrated a technique for determining a
>>>>>>>>>>
>>>>>>>>>>collision to a fixed
>>>>>>>>>>
>>>>>>>>>>plaintext block modification that is also hashed by key
>>>>>>>>>>
>>>>>>>>>>material. Thus,
>>>>>>>>>>
>>>>>>>>>>given a valid packet, there is still no documented way to
>>>>>>>>>>
>>>>>>>>>>tweak that packet
>>>>>>>>>>
>>>>>>>>>>and have it pass authentication.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Second, no one has demonstrated the ability to generate valid
>>>>>>>>>>
>>>>>>>>>>hashes of
>>>>>>>>>>
>>>>>>>>>>plaintext blocks and key material without the actual access to
>>>>>>>>>>the key
>>>>>>>>>>
>>>>>>>>>>material. Instead, the alternate blocks that are generated
>>>>>>>>>>
>>>>>>>>>>are unlikely to
>>>>>>>>>>
>>>>>>>>>>be valid protocol structures in the first place, result in
>>>>>>>>>>
>>>>>>>>>>parsing errors in
>>>>>>>>>>
>>>>>>>>>>the protocol. Thus, there is no way to wholly forge a packet
>>>>>>>>>>
>>>>>>>>>>and generate
>>>>>>>>>>
>>>>>>>>>>correct authentication for it without the key.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>That said, as always with security, there is no such thing as
>>>>>>>>>>
>>>>>>>>>>a perfect
>>>>>>>>>>
>>>>>>>>>>algorithm and increasing the available algorithms is always a
>>>>>>>>>>
>>>>>>>>>>good thing.
>>>>>>>>>>
>>>>>>>>>>However, it is a vast misrepresentation to suggest that this
>>>>>>>>>>
>>>>>>>>>>is a practical
>>>>>>>>>>
>>>>>>>>>>necessity today. There is one single (tho large ;-) customer
>>>>>>>>>>
>>>>>>>>>>that truly
>>>>>>>>>>
>>>>>>>>>>requires SHA algorithms today. BTW, HMAC-SHA-1 has been
>>>>>>>>>>
>>>>>>>>>>broken and the
>>>>>>>>>>
>>>>>>>>>>customer is interested in the larger values.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Tony
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>P.s. This same scare tactic has been used in other IETF WG's.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>
>>>>>>>>>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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>_______________________________________________
>>>>>>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
>>>>>
>>>>>
>
>_______________________________________________
>ntpwg mailing list
>ntpwg at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/ntpwg
>
>
More information about the ntpwg
mailing list