Re: [IPsec] RFC4869 bis submitted

Yoav Nir <> Fri, 13 November 2009 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 084863A6830 for <>; Fri, 13 Nov 2009 13:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id faMOmIf5sH6H for <>; Fri, 13 Nov 2009 13:35:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 875FD3A67E7 for <>; Fri, 13 Nov 2009 13:35:57 -0800 (PST)
X-CheckPoint: {4AFDCE1C-5-14201DC2-FFFF}
Received: by (Postfix, from userid 105) id 973DF29C005; Fri, 13 Nov 2009 23:36:25 +0200 (IST)
Received: from ( []) by (Postfix) with ESMTP id 7641A29C002; Fri, 13 Nov 2009 23:36:25 +0200 (IST)
X-CheckPoint: {4AFDCE1C-0-14201DC2-FFFF}
Received: from (localhost []) by (8.12.10+Sun/8.12.10) with ESMTP id nADLaOc6012159; Fri, 13 Nov 2009 23:36:25 +0200 (IST)
Received: from ([]) by ([]) with mapi; Fri, 13 Nov 2009 23:36:30 +0200
From: Yoav Nir <>
To: Paul Hoffman <>, "Law, Laurie" <>, "" <>
Date: Fri, 13 Nov 2009 23:36:29 +0200
Thread-Topic: [IPsec] RFC4869 bis submitted
Thread-Index: Acpj/H/a53jsEq2/QJqSc2E+uHr38gAq/64F
Message-ID: <>
References: < > <>, <p06240845c7225d09166e@[]>
In-Reply-To: <p06240845c7225d09166e@[]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] RFC4869 bis submitted
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Nov 2009 21:35:59 -0000

I strongly disagree with this.  UI suites are not "profiles". To quote from RFC 4308:
   This document specifies optional suites of
   algorithms and attributes that can be used to simplify the
   administration of IPsec when used in manual keying mode, with IKEv1
   or with IKEv2.

Since we want them to be in the UI, we can't have 50 different ones, so this registry cannot accommodate a profile for every government, institution and military in the world. We want to have few of them (I'd say no more than 8) that are relevant at any given point. This is why I was against defining a "VPN-C" a few years ago, that would have been AES-CBC with HMAC-SHA1, and DH group 14. 

So while I'd like to have a "new algorithm" suite in my UI, that would use AES-GCM, SHA-256/384 and the ECDH groups, it doesn't make sense to add a requirement for ECDSA certs to that list.  Definitely not when they're in the same "list" as VPN-A and VPN-B.
From: Paul Hoffman []
Sent: Friday, November 13, 2009 02:58
To: Yoav Nir; Law, Laurie;
Subject: Re: [IPsec] RFC4869 bis submitted

At 10:07 PM +0200 11/11/09, Yoav Nir wrote:
>If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates?

There is no "we" here. It is not a WG item, it is an individual submission that the authors chose to alert the WG about.

Having said that, it is perfectly natural for the submitters to require a particular type of authentication in a suite. For this one, it is clear that they want to use EC throughout the suite for asymmetric operations. For a different one, the organization specifying the suite might allow RSA but require a particular key size to match the strength desired.

>While the algorithms and DH groups are subject to configuration in the UI and negotiation in IKE, the algorithm used to sign the certificates is outside the IKE implementation.

That is not at all true. The IKE implementation must be able to both sign and verify using the keys in the certificates, so the algorithm is quite inside the IKE implementation.

> You usually have a certificate that you need to use, and it's the CA's decision whether this is signed with RSA, DSA or ECDSA. There's even some ambiguity, because it's not necessarily true, that the public key in the certificate is for the same algorithms used to sign the certificate.

The draft says:
  The authentication method for systems that use IKEv2 MUST be either
  ECDSA-256 or ECDSA-384 [RFC4754].
How would you reword that to say that both the keys in the certificates and the keys that signed them must be either ECDSA-256 or ECDSA-384?

>The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA.


>I don't see why 4869 or 4869-bis should.

Because that is what the creators of the profile want. The whole purpose of profiles is to allow the creators to be able to state all of the relevant crypto policy.

>I don't think it's part of the algorithm configuration.

How is the signing algorithm of the certificates used *not* part of the algorithm configuration?

--Paul Hoffman, Director
--VPN Consortium