[IPsec] Updating IPsec algorithm requirements

David McGrew <mcgrew@cisco.com> Fri, 06 November 2009 16:21 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 D39F33A683A for <ipsec@core3.amsl.com>; Fri, 6 Nov 2009 08:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level:
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 fdf+ZJU9Cw7U for <ipsec@core3.amsl.com>; Fri, 6 Nov 2009 08:21:54 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BBD413A682D for <ipsec@ietf.org>; Fri, 6 Nov 2009 08:21:54 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAG/c80qrR7Ht/2dsb2JhbADFSpd4hD0EgWc
X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208";a="267376901"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2009 16:22:15 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6GMDnE004955; Fri, 6 Nov 2009 16:22:15 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 17:22:13 +0100
Received: from stealth-10-32-254-213.cisco.com ([10.32.254.213]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 17:22:11 +0100
Message-Id: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Yaron Sheffer <yaronf@checkpoint.com>, ipsec@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 6 Nov 2009 08:22:09 -0800
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 06 Nov 2009 16:22:13.0102 (UTC) FILETIME=[4C29B8E0:01CA5EFD]
Subject: [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: Fri, 06 Nov 2009 16:21:55 -0000

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.