Re: [IPsec] RFC4869 bis submitted

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 13 November 2009 00:58 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 E339528C148 for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 16:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.933
X-Spam-Level:
X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 SGGgu6kWliED for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 16:58:34 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8FF2D28C0D8 for <ipsec@ietf.org>; Thu, 12 Nov 2009 16:58:32 -0800 (PST)
Received: from [133.93.128.35] (host-56-202.meeting.ietf.org [133.93.56.202]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAD0wtUg059978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 17:58:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240845c7225d09166e@[133.93.128.35]>
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com>
References: <D22B261D1FA3CD48B0414DF484E43D3211B49B@celebration.infosec.tycho.ncsc.mil > <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com>
Date: Fri, 13 Nov 2009 09:58:15 +0900
To: Yoav Nir <ynir@checkpoint.com>, "Law, Laurie" <lelaw@tycho.ncsc.mil>, "ipsec@ietf.org" <ipsec@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] RFC4869 bis submitted
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, 13 Nov 2009 00:58:35 -0000

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.

Correct.

>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