Re: [IPsec] RFC4869 bis submitted
Scott C Moonen <smoonen@us.ibm.com> Fri, 13 November 2009 14:10 UTC
Return-Path: <smoonen@us.ibm.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 A8C553A6810; Fri, 13 Nov 2009 06:10:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.498
X-Spam-Level:
X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KqNMYfMjLRBe; Fri, 13 Nov 2009 06:10:50 -0800 (PST)
Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id AE1E83A6844; Fri, 13 Nov 2009 06:10:46 -0800 (PST)
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nADE8toj002642; Fri, 13 Nov 2009 07:08:55 -0700
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nADEAxOk147530; Fri, 13 Nov 2009 07:11:02 -0700
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nADEAtR6004070; Fri, 13 Nov 2009 07:10:55 -0700
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nADEAt1n004067; Fri, 13 Nov 2009 07:10:55 -0700
In-Reply-To: <p06240845c7225d09166e@[133.93.128.35]>
References: <D22B261D1FA3CD48B0414DF484E43D3211B49B@celebration.infosec.tycho.ncsc.mil > <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> <p06240845c7225d09166e@[133.93.128.35]>
To: Paul Hoffman <paul.hoffman@vpnc.org>
MIME-Version: 1.0
X-KeepSent: A410ADE8:D37DCBCB-8525766D:00484633; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
From: Scott C Moonen <smoonen@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/13/2009 09:10:38 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/13/2009 09:10:38 AM, Serialize complete at 11/13/2009 09:10:38 AM, S/MIME Sign failed at 11/13/2009 09:10:38 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/13/2009 07:10:55, Serialize complete at 11/13/2009 07:10:55
Message-ID: <OFA410ADE8.D37DCBCB-ON8525766D.00484633-8525766D.004DE6B2@us.ibm.com>
Date: Fri, 13 Nov 2009 09:10:54 -0500
Content-Type: multipart/alternative; boundary="=_alternative 004DE0E18525766D_="
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org, Yoav Nir <ynir@checkpoint.com>, "Law, Laurie" <lelaw@tycho.ncsc.mil>
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 14:10:53 -0000
> 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. > . . . > How is the signing algorithm of the certificates used *not* part of > the algorithm configuration? I agree that is a natural goal for an organization's policy. But we can still discuss whether it is appropriate for the goal to be enforced in a suite. For example, it's a reasonable goal to require that "ICMP redirects are not permitted through this SA", but it's unnatural to enforce that requirement in a suite. I think the ECDSA requirement is another case where it is more appropriate to address the policy requirement elsewhere -- through an organization's PKI infrastructure and administration rather than through the IKE configuration. Often the IKE administration and PKI administration are separate roles, and the IKE administrator uses whatever certificates the PKI folks provide. IKE already configures the certificate to be used; RFC 4869 and this draft essentially require IKE to configure right alongside that the assertion to "fail this operation if this certificate (which my PKI administrator has already deemed acceptable) is not ECDSA-256 or ECDSA-384". It does provide another level of assurance that ECDSA was used, but is it IKE's job to second-guess the PKI administrator? Furthermore, the requirement as stated isn't well-defined: 1) Does this require that IKE check its local certificate for use of ECDSA? 2) Does this require that IKE check the remote certificate for use of ECDSA? 3) Does this require that IKE check the trust chain for use of ECDSA? So far we've interpreted RFC 4869 as requiring only #1 (you're responsible to ensure your own certificate is ECDSA-nnn) but not #2 and #3. I would still much prefer to see the ECDSA requirement dropped from the draft, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Paul Hoffman <paul.hoffman@vpnc.org> To: Yoav Nir <ynir@checkpoint.com>, "Law, Laurie" <lelaw@tycho.ncsc.mil>, "ipsec@ietf.org" <ipsec@ietf.org> Date: 11/12/2009 07:59 PM 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. 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
- Re: [IPsec] RFC4869 bis submitted Yoav Nir
- [IPsec] RFC4869 bis submitted Law, Laurie
- Re: [IPsec] RFC4869 bis submitted Dan McDonald
- Re: [IPsec] RFC4869 bis submitted Scott C Moonen
- Re: [IPsec] RFC4869 bis submitted Paul Hoffman
- Re: [IPsec] RFC4869 bis submitted Stephen Kent
- Re: [IPsec] RFC4869 bis submitted Scott C Moonen
- Re: [IPsec] RFC4869 bis submitted Scott C Moonen
- Re: [IPsec] RFC4869 bis submitted Yoav Nir
- Re: [IPsec] RFC4869 bis submitted Bill Sommerfeld
- Re: [IPsec] RFC4869 bis submitted Bill Sommerfeld
- Re: [IPsec] RFC4869 bis submitted Paul Hoffman
- Re: [IPsec] RFC4869 bis submitted Paul Hoffman