Hi Miroslav, On Fri, Mar 02, 2018 at 10:11:45AM +0100, Miroslav Lichvar wrote: > On Thu, Mar 01, 2018 at 06:40:45PM -0500, Matthew Van Gundy wrote: > > On Wed, Feb 28, 2018 at 11:06:36PM -0800, Hal Murray wrote: > > > Why is AES-CMAC more interesting than one of the digests supported by > > > OpenSSL? > > > > The keyed-hash construction that NTP uses is not a secure message > > authentication code, it is vulnerable to the classic length extension > > attack [1] when used with common hash functions, such as MD5, SHA-1, > > and the SHA-2 family of hash functions. This allows an attacker to > > append additional forged NTPv4 extension fields on to an authenticated > > NTPv4 packet. > > Does this actually apply to NTPv4? Do you have any examples how could > an attacker append a valid extension field to an NTPv4 packet? > > My understanding is that the NTPv4 packet format (with or without > RFC7822) prevents the length-extension attack as extension fields > cannot have a length of zero, which would come from the padding > (always starting with 0x80000000). Even if the length field could be > zero, there is no EF type 0x8000 assigned yet and it could be avoided > in future in case people are for some reason still using the old MAC.
I was speaking in general terms. I have not actually proved out an attack against an NTPv4 implementation. I believe you are correct: since most hash functions in common use pad the last block with a binary string beginning with 0x80000000 or 0x00000000, an NTPv4 implementation would parse a length extended packet as an extension of length zero, and would probably discard it (or fail to process additional extensions in a meaningful way). However, there is no requirement that hash functions pad the last block with any specific value. Though it may be unlikely, this is a brittle assumption that could be invalidated by future hash functions. Using secure message authentication codes such as CMAC or HMAC avoids this potential failure case. Cheers, Matt
signature.asc
Description: PGP signature
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
