[ntpwg] Stronger symmetric NTP authentication

Danny Mayer mayer at ntp.isc.org
Thu Dec 4 17:56:09 UTC 2008 

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

More information about the ntpwg mailing list