[ntpwg] Stronger symmetric NTP authentication

[Bhatia, Manav (Manav)]

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