Subject: [IPsec] RFC4869 bis submitted

From: "Law, Laurie" <[email-masked]>
Date: Tue, 10 Nov 2009 17:15:36 -0500

A bis has been submitted for RFC 4869, "Suite B Cryptographic Suites for
IPsec". It is available at
http://tools.ietf.org/html/draft-law-rfc4869bis-00 
 
This Internet-Draft makes several minor changes to the suites in RFC
4869 and incorporates comments that have been posted to the ipsec
mailing list.
 
Laurie Law
National Information Assurance Research Laboratory
National Security Agency

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Nov 2009 22:07:31 +0200

Hi

If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates?

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. 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 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. I don't think it's part of the algorithm configuration.

Yoav

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Law, Laurie [[email-masked]]
Sent: Wednesday, November 11, 2009 00:15
To: [email-masked]
Subject: [IPsec] RFC4869 bis submitted

A bis has been submitted for RFC 4869, "Suite B Cryptographic Suites for IPsec". It is available at http://tools.ietf.org/html/draft-law-rfc4869bis-00

This Internet-Draft makes several minor changes to the suites in RFC 4869 and incorporates comments that have been posted to the ipsec mailing list.

Laurie Law

---

From: Dan McDonald <[email-masked]>
Date: Wed, 11 Nov 2009 15:52:38 -0500

On Wed, Nov 11, 2009 at 10:07:31PM +0200, Yoav Nir wrote:
> 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. 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.

I strongly agree with Yoav here.

Especially given certificate operations are much rarer in IKEv2 (given their
SAs last indefinitely long), would 2048-bit RSA or 4096-bit RSA certs be
unreasonable?  I understand the cert-chain issues with weak hashes, but those
do not come directly into play during the IKE exchange.  (Imagine self-signed
certs for IKE, e.g.)

> 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. I don't think it's part of
> the algorithm configuration.

Also --> the new bis document talks about IKEv1's Phase 2 Diffie-Hellman as a
MAY without saying it.  I quote:

  Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
  MUST be supported by both parties in this suite.  The initiator of
  this exchange MAY include a new Diffie-Hellman key; if it is
  included, it MUST use the 256-bit random ECP group.  If the
  initiator of the exchange includes a Diffie-Hellman key, the
  responder MUST include a Diffie-Hellman key, and it MUST use the
  256-bit random ECP group.

Many IKEv1's have Phase 2 PFS as an on/off switch.  It would be nice if you
picked one for these (either always-on or always-off).

Dan

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 12 Nov 2009 14:42:00 -0500

> I strongly agree with Yoav here.

I strongly agree with Yoav and Dan on decoupling the authentication method 
from the suite.  This places an unnatural configuration burden on an IKE 
implementation.  It is proper to configure one's choice of certificate -- 
but it is not natural to configure the certificate's authentication 
algorithm independently of simply choosing the desired certificate or CA.

> picked one for these (either always-on or always-off).

How would such an implementation handle RFC 4308?  Our own implementation 
supports sending offers with and without PFS, but it does seem odd to me 
that these RFCs would punt on the decision to use PFS.  There are valid 
reasons for either approach (CPU cost versus key independence).  I suppose 
we could create separate versions of the suites with and without PFS, but 
it's probably ok for the suites to simply be "opinionated".  I guess that 
means we'd go with PFS=on.

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

From:
Dan McDonald <[email-masked]>
To:
Yoav Nir <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>, "Law, Laurie" <[email-masked]>
Date:
11/11/2009 03:54 PM
Subject:
Re: [IPsec] RFC4869 bis submitted

Especially given certificate operations are much rarer in IKEv2 (given 
their
SAs last indefinitely long), would 2048-bit RSA or 4096-bit RSA certs be
unreasonable?  I understand the cert-chain issues with weak hashes, but 
those
do not come directly into play during the IKE exchange.  (Imagine 
self-signed
certs for IKE, e.g.)

> the algorithm configuration.

Also --> the new bis document talks about IKEv1's Phase 2 Diffie-Hellman 
as a
MAY without saying it.  I quote:

Many IKEv1's have Phase 2 PFS as an on/off switch.  It would be nice if 
you
picked one for these (either always-on or always-off).

Dan
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Nov 2009 09:58:15 +0900

>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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Nov 2009 21:38:13 -0500

I agree with all of Paul's observations. The scope of this profile is 
entirely appropriate.

Steve

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 13 Nov 2009 09:10:54 -0500

> 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.
> . . .

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,

From:
Paul Hoffman <[email-masked]>
To:
Yoav Nir <[email-masked]>, "Law, Laurie" <[email-masked]>, 
"[email-masked]" <[email-masked]>
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.

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

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 13 Nov 2009 15:45:03 -0500

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.

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

From: 

The draft says:

DSA.

Correct.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Fri, 13 Nov 2009 23:36:29 +0200

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 [[email-masked]]
Sent: Friday, November 13, 2009 02:58
To: Yoav Nir; Law, Laurie; [email-masked]
Subject: Re: [IPsec] RFC4869 bis submitted

The draft says:

Correct.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 19 Nov 2009 13:51:37 -0800

> 4869 and incorporates comments that have been posted to the ipsec

On reading the spec, it's not clear to me whether an IKEv1
implementation which supports ECP-based DH (rfc4753) with preshared keys
but not ECDSA (rfc4754) is considered to usefully implement this
specification.

As a practical matter, the ECDSA piece of this spec is likely to be the
largest and last piece built -- given a working elliptic curve codebase,
plugging ephemeral ECDH into an IKE implementation is a much smaller
problem than building ECDSA into both an IKE implementation and the PKI
client codebase, tools, and keystores it relies on.

							- Bill

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Nov 2009 15:08:39 -0800

>but not ECDSA (rfc4754) is considered to usefully implement this

The text says:
  IKEv1 implementations MUST
  support pre-shared key authentication [RFC2409] for interoperability.
  The authentication method used with IKEv1 MUST be either pre-shared
  key [RFC2409] or ECDSA-256 [RFC4754].
To me, that sounds like preshared keys are just fine for IKEv1 in this profile, but I might be misunderstanding what you mean by "usefully".

>client codebase, tools, and keystores it relies on.

Probably true, but ECDSA is far from impossible, as the OpenSSL people have shown for a while now.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 19 Nov 2009 15:45:34 -0800

On Thu, 2009-11-19 at 15:08 -0800, Paul Hoffman wrote:
> To me, that sounds like preshared keys are just fine for IKEv1 in this
> profile, but I might be misunderstanding what you mean by "usefully".

I make a distinction between "optional to use" and "optional to
implement".  There are many things which are optional to use but
effectively mandatory to implement -- an implementation is not viewed as
complete unless it allows the use of the option.

As you pointed out earlier in this thread, this profile is an individual
submission describing a particular organization's requirements.  I'm
reluctant to guess or rely on the guess of someone who isn't part of
this organization when the document itself could be clarified.

> have shown for a while now.

There is a large gap between "can deliver next week" and "impossible".
(I'll also note in passing that changing which PKI client codebase you
use in an IKE implementation is also a sizeable task).

					- Bill

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Nov 2009 15:56:24 -0800

>complete unless it allows the use of the option.

Given that this is IKEv1, where both parties must authenticate using the same authentication mechanism, I have assumed that this text means that ECDSA is not mandatory to implement in IKEv1 for this profile.

>this organization when the document itself could be clarified.

Given that this is a revision to an existing RFC, the authors may not know the words that would make this clear to you. Suggested wording for them?

>There is a large gap between "can deliver next week" and "impossible".

RFC 4869 was published more than a week ago. :-)

--Paul Hoffman, Director
--VPN Consortium