[ntpwg] Stronger symmetric NTP authentication

Tue Dec 2 14:31:11 UTC 2008

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

-- 
blu

"Murderous organizations have increased in size and scope; they are
more daring, they are served by the most terrible weapons offered by
modern science, and the world is nowadays threatened by new forces
which, if recklessly unchained, may some day wreck universal
destruction."  - Arthur Griffith, 1898
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom