Re: [IPsec] Updating IPsec algorithm requirements

Yaron Sheffer <> Mon, 09 November 2009 02:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E31F23A68E3 for <>; Sun, 8 Nov 2009 18:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.625
X-Spam-Status: No, score=-4.625 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TbUW8qah63lD for <>; Sun, 8 Nov 2009 18:17:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 47F5F3A6841 for <>; Sun, 8 Nov 2009 18:17:09 -0800 (PST)
Received: from (localhost []) by (8.12.10+Sun/8.12.10) with ESMTP id nA92HPc6021349; Mon, 9 Nov 2009 04:17:25 +0200 (IST)
Received: from ([]) by ([]) with mapi; Mon, 9 Nov 2009 04:17:28 +0200
From: Yaron Sheffer <>
To: David McGrew <>, Paul Hoffman <>, "" <>
Date: Mon, 9 Nov 2009 04:17:26 +0200
Thread-Topic: Updating IPsec algorithm requirements
Thread-Index: Acpe/VQTlbYzY70/RUGhEYE1fwkQQwB47taw
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] Updating IPsec algorithm requirements
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Nov 2009 02:17:11 -0000

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.


> -----Original Message-----
> From: David McGrew []
> Sent: Saturday, November 07, 2009 1:22
> To: Paul Hoffman; Yaron Sheffer;
> 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
>, 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.