Re: [IPsec] Updating IPsec algorithm requirements

[David McGrew]

Hi Yaron,

On Nov 8, 2009, at 6:17 PM, Yaron Sheffer wrote:

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.

Is the intent of the Roadmap to document the extant RFCs, or the current consensus of the working group? If it is only documenting current RFCs, then surely it should not hold up WG action on recommending policy updates. If it is documenting current consensus of the WG, then it would seem appropriate to discuss updating the algorithm requirements in the context of that draft (and it would seem urgent to do so). What bearing does draft-ietf-ipsecme-aes-ctr-ikev2-02.txt have on the policy issue? There are good reasons for recommending AES-GCM over AES-CTR, and there are already RFCs for using AES-GCM in IKEv2.

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.

I respectfully but strongly disagree. The important issue is not about security; it is about performance/cost. All of the algorithms that we are discussing provide enough security, but they have widely different performance/cost characteristics. Even if AES-GCM provided advantages only to hardware-based systems, it would be worth recommending for broad adoption, because software-based systems need to make connections with hardware-based systems. A broad recommendation is needed in order to ensure interoperability. However, many software implementations (perhaps even a majority) can benefit from performance advantages. Some new processors have added support for the finite-field multiplication operation used in GCM [1] as well as for AES [2]. Extremely fast software implementations have been reported [3].

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.

regards,

David

[1] 
http://software.intel.com/en-us/articles/carry-less-multiplication-and-its-usage-for-computing-the-gcm-mode/

[2] http://software.intel.com/file/20457

[3] http://eprint.iacr.org/2009/129

There is not much point to asking CFRG, since the performance advantages of GCM are well established. If we want to find out how well those advantages apply to the implementation environments that are typical for IPsec, let's ask for input from this WG. But even this question is tangential. There are implementers that will benefit from using AES-GCM, and that algorithm is clearly better than AES- CTR. What possible reason can one put forward for recommending AES- CTR over AES-GCM in ESP? Let's develop an IPsec policy that supports cost effective high speed implementations. We know that AES-CBC won't get us there, and neither will AES-CTR with HMAC-SHA-256.

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

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

function. Implementations MUST use AES-CTR in conjunction with an
authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]."

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

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.


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

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

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

completed by the end of 2010 (see NIST SP 800-107, for example).


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.

algorithms with equivalent security, and is recommended by newer IPsec equally catastrophic to use AES-CTR without a companion authentication Unfortunately, none of the authentication algorithms currently defined yet a stable normative reference for AES-GCM. This may have motivated It is especially important that AES-GCM be recommended over the use of set a policy that makes it clear that HMAC-SHA-256 is not required for industry moves away from SHA1, HMAC-SHA-256 may be the first algorithm signatures is already underway; many users plan to have that transition AES-CBC and HMAC-SHA1 are valuable because those algorithms are widely

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec