Subject: [IPsec] Updating IPsec algorithm requirements

From: David McGrew <[email-masked]>
Date: Fri, 6 Nov 2009 08:22:09 -0800

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.

---

From: Paul Koning <[email-masked]>
Date: Fri, 6 Nov 2009 14:07:18 -0500

Excerpt of message (sent 6 November 2009) by David McGrew:
> ...

... and therefore no confidentiality either, if used by itself, via
the Bellovin attack.

> AES-GCM was designed specifically to overcome this problem.  ...
> 
> AES-CTR with HMAC-SHA-256, ...

I agree.  For the reasons you gave, and also to remove the temptation
to run AES-CTR without authentication for performance reasons, even
though the standard says not to do this.

       paul

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Nov 2009 07:09:32 +0900

>though the standard says not to do this.

It is usually not temptation, but by mistake, aided by poor UI practice on the parts of >90% of VPN vendors. That is, I have found few vendors in the VPNC lab that *prevent* you from running with null authentication. Having a combined mode in the mix, particularly if it is the required algorithm, would reduce the prevalence of this kind of mistake.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 9 Nov 2009 04:17:26 +0200

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:[email-masked]]
> Sent: Saturday, November 07, 2009 1:22
> To: Paul Hoffman; Yaron Sheffer; [email-masked]
> Subject: Updating IPsec algorithm requirements
> 
> Scanned by Check Point Total Security Gateway.

---

From: David McGrew <[email-masked]>
Date: Mon, 9 Nov 2009 06:02:23 -0800

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.

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.

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