[ntpwg] Stronger symmetric NTP authentication
Tony Li
tony.li at tony.li
Tue Dec 2 02:56:15 UTC 2008
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.
More information about the ntpwg
mailing list