Re: [IPsec] [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
Tero Kivinen <kivinen@iki.fi> Wed, 28 October 2009 11:58 UTC
Return-Path: <kivinen@iki.fi>
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 660813A6784 for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 04:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599]
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 xsqjpyO0FjGQ for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 04:58:28 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3891B3A681D for <ipsec@ietf.org>; Wed, 28 Oct 2009 04:58:28 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9SBwbse014166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 13:58:37 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9SBwag1013594; Wed, 28 Oct 2009 13:58:36 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19176.12780.93344.730093@fireball.kivinen.iki.fi>
Date: Wed, 28 Oct 2009 13:58:36 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Frankel, Sheila E." <sheila.frankel@nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930789878B73@MBCLUSTER.xchange.nist.gov>
References: <063.764926e4414cb9e492e9c76aed2dcc1d@tools.ietf.org> <D7A0423E5E193F40BE6E94126930C4930789878B73@MBCLUSTER.xchange.nist.gov>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 14 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>
Subject: Re: [IPsec] [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
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: Wed, 28 Oct 2009 11:58:29 -0000
Frankel, Sheila E. writes:
>
> #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
>
> Proposed changes to Roadmap doc:
>
> 1) Add text to section 5.4 (Combined Mode Algorithms)
...
> Additional text:
> Some IKEv1 implementations have added the capability to negotiate
> combined mode algorithms for use in IPsec SAs; these implementations
> do not include the capability to use combined mode algorithms to protect
> IKE SAs. Since combined mode algorithms are not a feature of IPsec-v2,
> these IKEv1 implementations are used in conjunction with IPsec-v3. IANA
> numbers for combined mode algorithms have been added to the IKEv1 registry.
That text seems ok.
> 2) Change IKEv2 and IPsec-v2 requirement levels
>
> Requirements levels for AES-GMAC:
> old IKEv2 - optional
> new IKEv2 - optional (integrity-protection algorithm)
> N/A (combined mode algorithm with NULL encryption)
IKEv2 SA cannot be used with NULL encryption, so using AES-GMAC
requires some other encryption algorithm when used in IKEv2. AES-GMAC
requires IV and some other encryption algorithm used with it also
requires IV, which means we require two IVs or they require sharing
the IV, which might not be possible as there IV generation rules (and
lengths) might be different.
I do not think it is possible to use AES-GMAC at all to protect IKEv2
traffic, and also it does not make any sense to use AES-GMAC as it
says that it is to be used when no confidentiality is desired, and as
in IKEv2 that is required then AES-GCM should be used instead.
>From RFC5282:
----------------------------------------------------------------------
3. The Use of AES-GMAC in ESP
...
If confidentiality is desired, then
GCM ESP [RFC4106] SHOULD be used instead.
----------------------------------------------------------------------
So I think the correct change is
IKEv2 - N/A (IKEv2 requires encryption).
--
kivinen@iki.fi
- Re: [IPsec] [ipsecme] #111: Can IKEv1 negotiate c… Frankel, Sheila E.
- Re: [IPsec] [ipsecme] #111: Can IKEv1 negotiate c… Tero Kivinen