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.