[ntpwg] Stronger symmetric NTP authentication

Greg Dowd GDowd at symmetricom.com
Fri Dec 5 22:26:30 UTC 2008 

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