[ntpwg] Stronger symmetric NTP authentication

Thu Dec 4 20:07:54 UTC 2008

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
> 