Re: [IPsec] Updating IPsec algorithm requirements

Yaron Sheffer <yaronf@checkpoint.com> Mon, 09 November 2009 02:17 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31F23A68E3 for <ipsec@core3.amsl.com>; Sun, 8 Nov 2009 18:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.625
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbUW8qah63lD for <ipsec@core3.amsl.com>; Sun, 8 Nov 2009 18:17:09 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 47F5F3A6841 for <ipsec@ietf.org>; Sun, 8 Nov 2009 18:17:09 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA92HPc6021349; Mon, 9 Nov 2009 04:17:25 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 04:17:28 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: David McGrew <mcgrew@cisco.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "ipsec@ietf.org" <ipsec@ietf.org>
Date: Mon, 9 Nov 2009 04:17:26 +0200
Thread-Topic: Updating IPsec algorithm requirements
Thread-Index: Acpe/VQTlbYzY70/RUGhEYE1fwkQQwB47taw
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872BB9C@il-ex01.ad.checkpoint.com>
References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com>
In-Reply-To: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=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.

Thanks,
	Yaron

> -----Original Message-----
> From: David McGrew [mailto:mcgrew@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.