Re: [IPsec] Updating IPsec algorithm requirements

Paul Koning <Paul_Koning@dell.com> Fri, 06 November 2009 19:08 UTC

Return-Path: <Paul_Koning@Dell.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 39C1E3A69DD for <ipsec@core3.amsl.com>; Fri, 6 Nov 2009 11:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 o6B9DmJXiRpM for <ipsec@core3.amsl.com>; Fri, 6 Nov 2009 11:08:00 -0800 (PST)
Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 5CB873A683A for <ipsec@ietf.org>; Fri, 6 Nov 2009 11:08:00 -0800 (PST)
X-Loopcount0: from 12.110.134.31
X-IronPort-AV: E=Sophos;i="4.44,695,1249275600"; d="scan'208";a="420123507"
Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 06 Nov 2009 13:08:23 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19188.29670.319220.85945@pkoning-laptop.lab.equallogic.com>
Date: Fri, 6 Nov 2009 14:07:18 -0500
From: Paul Koning <Paul_Koning@dell.com>
To: mcgrew@cisco.com
References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com>
X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid
X-OriginalArrivalTime: 06 Nov 2009 19:07:22.0869 (UTC) FILETIME=[5ED82A50:01CA5F14]
Cc: ipsec@ietf.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: Fri, 06 Nov 2009 19:08:01 -0000

Excerpt of message (sent 6 November 2009) by David McGrew:
> Hi Paul, Yaron, and IPsec ME WG participants,
> 
> I would like to propose an update to the algorithm requirements, as  
> outlined below.
> ...
> 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.

... and therefore no confidentiality either, if used by itself, via
the Bellovin attack.

>  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 especially important that AES-GCM be recommended over the use of
> AES-CTR with HMAC-SHA-256, ...

I agree.  For the reasons you gave, and also to remove the temptation
to run AES-CTR without authentication for performance reasons, even
though the standard says not to do this.

       paul