Re: [IPsec] RFC4869 bis submitted

[Scott C Moonen <[e-mail]>]

Also, it occurs to me that the purpose of a suite isn't to enforce this 
kind of policy decision, just to give them names for interoperability 
purposes.

E.g., the existence of SuiteB-XYZ doesn't prevent you from negotiating DES 
under the table somewhere; it just prevents you from negotiating DES and 
calling it SuiteB-XYZ.

That doesn't in itself imply that ECDSA doesn't belong in the suite.  But 
since the goal is interoperability, maybe there are alternative ways of 
achieving interoperability.  For example, one could simply state this:

"An implementation MUST NOT indicate support for SuiteB-XYZ for IKEv2 
unless it supports authentication using ECDSA-256 and ECDSA-384 digital 
signatures.  An implementation MUST NOT indicate support for SuiteB-XYZ 
for IKEv1 unless it supports either pre-shared key authentication or 
authentication using ECDSA-256 and ECDSA-384 digital signatures."

Something like that, perhaps?  That achieves the goal of guaranteeing 
ECDSA interoperability for SuiteB-*, but without making IKE responsible to 
micromanage decisions that are really within the PKI domain.


Scott Moonen ([e-mail])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen



From:
Scott C Moonen/Raleigh/IBM@IBMUS
To:
Paul Hoffman <[e-mail]>
Cc:
"[e-mail]" <[e-mail]>, [e-mail], Yoav Nir 
<[e-mail]>, "Law, Laurie" <[e-mail]>
Date:
11/13/2009 09:11 AM
Subject:
Re: [IPsec] RFC4869 bis submitted




> 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 ([e-mail])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen 


From: 
Paul Hoffman <[e-mail]> 
To: 
Yoav Nir <[e-mail]>, "Law, Laurie" <[e-mail]>, 
"[e-mail]" <[e-mail]> 
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
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec