Re: [IPsec] Updating IPsec algorithm requirements

[Yaron Sheffer <[e-mail]>]

Hi David,

I believe it's a bit early to make a SHOULD/MUST recommendation, at the time we are still finalizing the algorithm requirements, with the work on the Roadmap document, and the AES-CTR draft.

The vast majority of deployed systems are software-based, and AES-GCM provides them with a marginal performance improvement at best. So we would need a strong security argument to start this migration.

May I also ask that you validate consensus behind your proposal on CFRG, i.e. the superiority of AES-GCM (presumably, 128-bit) over AES-CBC+SHA-1 or AES-CBC+AES-XCBC, and whether or not there are any good alternatives to it.

Thanks,
	Yaron

> -----Original Message-----
> From: David McGrew [mailto:[e-mail]]
> Sent: Saturday, November 07, 2009 1:22
> To: Paul Hoffman; Yaron Sheffer; [e-mail]
> Subject: Updating IPsec algorithm requirements
> 
> Hi Paul, Yaron, and IPsec ME WG participants,
> 
> I would like to propose an update to the algorithm requirements, as
> outlined below.
> 
> regards,
> 
> David
> 
> --
> 
> Updating IPsec Algorithm Requirements
> 
> AES in Galois/Counter Mode of operation (AES-GCM)[RFC4106][RFC4543]
> [RFC5282] should be recommended or required by the IPsec standards,
> because it provides higher efficiency than currently recommended
> algorithms with equivalent security, and is recommended by newer IPsec
> profiles [RFC4869].
> 
> Currently, AES in Counter Mode (AES-CTR)[RFC3686] is recommended as a
> SHOULD in "Cryptographic Algorithm Implementation Requirements for
> Encapsulating Security Payload (ESP) and Authentication Header (AH)",
> RFC 4835.  AES-CTR is a useful algorithm because it admits efficient
> high speed implementations.  However, it provides no authentication.
>  From RFC3686: "With AES-CTR, it is trivial to use a valid ciphertext
> to forge other (valid to the decryptor) ciphertexts. Thus, it is
> equally catastrophic to use AES-CTR without a companion authentication
> function. Implementations MUST use AES-CTR in conjunction with an
> authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]."
> Unfortunately, none of the authentication algorithms currently defined
> for IPsec (HMAC, XCBC-MAC) admit efficient high speed
> implementations.  Thus the need for authentication undermines the
> efficiency of AES-CTR.
> 
> AES-GCM was designed specifically to overcome this problem.  It is a
> "combined mode" in the ESP sense [RFC4303], that provides both
> encryption and authentication.  Internally, it combines AES-CTR with
> an authentication mechanism that can be efficiently implemented at
> high data rates.
> 
> At the time that RFC 4835 was published (April 2007), there was not
> yet a stable normative reference for AES-GCM.  This may have motivated
> the IPsec community to not rely on that algorithm in its
> recommendations.  But November 2007 saw the publication of NIST SP
> 800-38D, "Recommendation for Block Cipher Modes of Operation: Galois/
> Counter Mode (GCM) and GMAC", which removes any such concern.  An
> additional change in favor of AES-GCM is its wide adoption by
> crypto hardware and software suppliers.
> 
> It is especially important that AES-GCM be recommended over the use of
> AES-CTR with HMAC-SHA-256, because the latter combination of
> algorithms is considerably less efficient, and the former algorithm
> meets the security requirements.  The IPsec ME Working Group should
> set a policy that makes it clear that HMAC-SHA-256 is not required for
> future implementations.  HMAC-SHA-1 is believed to be secure (recall
> the "No Need for SHA-2" Open Letter
> http://www.vpnc.org/ietf-ipsec/02.ipsec/msg01840.html), but as the
> industry moves away from SHA1, HMAC-SHA-256 may be the first algorithm
> that comes to mind for some users of IPsec.  Thus a policy
> clarification by the WG is essential.  This should be done as soon
> as is practical, because the transition away from SHA-1 for digital
> signatures is already underway; many users plan to have that transition
> completed by the end of 2010 (see NIST SP 800-107, for example).
> 
> AES-CBC and HMAC-SHA1 are valuable because those algorithms are widely
> implemented.  This suggests that it makes sense to rely on those
> algorithms as mandatory-to-implement until such time as it becomes
> necessary or desirable to stop using HMAC-SHA1.   AES-GCM should
> replace this combination of algorithms, when that time comes.
> 
> 
> 
> Scanned by Check Point Total Security Gateway.