Re: [tcpm] Guidance on selection of MAC algorithms for TCP-AO

At Tue, 18 Nov 2008 11:48:35 -0800,
Joe Touch wrote:
> TCP-AO needs to make two decisions with respect to MAC algorithms:
> select algorithms for the current specification; and establish
> criteria for specification of MAC algorithms in the future.  To be
> honest, there are numerous MAC algorithms that could satisfy TCP-AO's
> security requirements.  Pragmatic issues like performance and current
> code bases need to be factored in as well.
> 
> The two most attractive options for generating the MAC are AES 128 in
> the cipher-based message authentication code (CMAC) mode and the
> SHA-1 Hash-based Message Authentication Code (HMAC).   Both options
> provide a high level of security and efficiency.  The AES 128 CMAC is
> potentially more efficient, particularly in hardware, but SHA-1 HMAC
> is more widely used in Internet protocols and in most cases could be
> supported with little or no additional code.
> 
> Another aspect of the algorithm selection is whether the tags should
> be truncated.  CMAC-AES-128 produces a 128 bit MAC, and HMAC SHA-1
> produces a 160 bit result.  The MAC can be truncated to 96 bits
> provide a reasonable tradeoff between security and message size.  So,
> the algorithms that were in draft-bonica are entirely reasonable
> choices: AES-128-CMAC-96 and HMAC-SHA-1-96.  For interoperability,
> the working group needs to either specify one MAC algorithm as a MUST
> and the other as a SHOULD, or specify MUST implement for both
> algorithms.
> 
> Note that the security issues driving the migration from SHA-1 to
> SHA-256 for digital signatures do not apply here.  The security
> strength of SHA-1 HMACs should be sufficient for the foreseeable
> future.

I'm sorry to be difficult, but I don't think that this is quite so
clear. The relevant cite here is:

Jongsung Kim and Alex Biryukov and Bart Preneel and Seokhie Hong,
"On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1",
SCN 2006.

http://eprint.iacr.org/2006/187
http://www.springerlink.com/content/00w4v62651001303/

While it's clear that the attacks aren't practical on SHA-1, or probably
MD5, it's not like the types of analysis people are mounting don't
potentially pose a concern for HMAC forgery if they were significantly
improved, so I don't think that it's fair to say that the "security issues
driving the migration... don't apply here"

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm