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:mcg...@cisco.com]
> Sent: Saturday, November 07, 2009 1:22
> To: Paul Hoffman; Yaron Sheffer; ipsec@ietf.org
> 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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
