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 [paul.hoff...@vpnc.org] Sent: Friday, November 13, 2009 02:58 To: Yoav Nir; Law, Laurie; ipsec@ietf.org 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
