[ntpwg] Stronger symmetric NTP authentication

Thu Dec 4 15:56:26 UTC 2008

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
>>
>