Re: [IPsec] Updating IPsec algorithm requirements
David McGrew <mcgrew@cisco.com> Mon, 09 November 2009 14:02 UTC
Return-Path: <mcgrew@cisco.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 AE7393A6B6E for <ipsec@core3.amsl.com>; Mon, 9 Nov 2009 06:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.491
X-Spam-Level:
X-Spam-Status: No, score=-7.491 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 sfssoXLtqv5A for <ipsec@core3.amsl.com>; Mon, 9 Nov 2009 06:01:59 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4AB833A69DB for <ipsec@ietf.org>; Mon, 9 Nov 2009 06:01:59 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: smime.p7s : 1760
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAPKu90qrR7H+/2dsb2JhbADGC5ZYgkaBeASBaA
X-IronPort-AV: E=Sophos; i="4.44,708,1249257600"; d="p7s'?scan'208"; a="428170395"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2009 14:02:25 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA9E2PA9007890; Mon, 9 Nov 2009 14:02:25 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:02:25 -0800
Received: from stealth-10-32-254-214.cisco.com ([10.32.254.214]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:02:24 -0800
Message-Id: <E6BD63FA-3712-46FD-B84A-D6AB4CC801ED@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Yaron Sheffer <yaronf@checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872BB9C@il-ex01.ad.checkpoint.com>
Content-Type: multipart/signed; boundary="Apple-Mail-222-295269496"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 09 Nov 2009 06:02:23 -0800
References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872BB9C@il-ex01.ad.checkpoint.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 09 Nov 2009 14:02:25.0221 (UTC) FILETIME=[43D5E750:01CA6145]
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
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 14:02:00 -0000
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 > > 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.
- [IPsec] Updating IPsec algorithm requirements David McGrew
- Re: [IPsec] Updating IPsec algorithm requirements Paul Koning
- Re: [IPsec] Updating IPsec algorithm requirements Paul Hoffman
- Re: [IPsec] Updating IPsec algorithm requirements Yaron Sheffer
- Re: [IPsec] Updating IPsec algorithm requirements David McGrew