Subject: Re: [Ipsec] First draft of IKEv2.1

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 01 Jan 2006 15:51:50 -0500

In message <p06230946bfda06ff78c5@[10.20.30.249]>, Paul Hoffman writes:
>Greetings again. Some VPNC members have complained about having to 
>jump back and forth between the IKEv2 Clarifications document with 
>the IKEv2 RFC. At the same time, they also have said that they don't 
>like the SHOULDs in IKEv2 that have nothing to do with 
>interoperability.
>
>To that end, I have created a new document, for IKEv2.1. The first 
>draft is at 
><http://www.ietf.org/internet-drafts/draft-hoffman-ikev2-1-00.txt>. 
>Its main purpose is to fix the above two problems, but it can also be 
>a springboard for needed core features that are not clarifications. 
>The version number is 2.1 because some of the normative requirements 
>(SHOULD and MUST) have changed. So far, there are no bits-on-the-wire 
>changes, although it is believable that some will be introduced (such 
>as new notifications) before the document is done.
>
>Of course, I am open to comments and suggestions on improving the 
>document. Given that we are starting to see IKEv2 implementations in 
>the market, it would be good to close this document within a few 
>months so that new implementers can go straight to version 2.1.
>

If we're going to reopen IKEv2, I think we should add hash and signature
algorithm negotiation at the same time.  

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 2 Jan 2006 09:51:10 +0200

And Re-Auth, and multiple EAP, and EAP-only authentication, and IKE over TCP
(or SCTP) and lots of other stuff some people want.

If we're reopening IKEv2, we need a new working group, and all issues can be
re-opened. If it's just the clarifications, they can be published in a
separate Best-Current-Practice RFC without any need for changing bits-on-the
wire.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Jan 2006 10:53:16 +0200

Yoav Nir wrote:

>re-opened. 
Indeed. But I have three comments;

1) Doing a new revision should not normally mean that
    "all" issues can be re-opened. Hopefully this is not the
    open season to redesign IKEv2 to suit whatever preferences
    some of us may have had. Sure, we can do clarifications,
    bug fixes, and also extensions. But lets not re-open all
    issues.

2) I'm getting increasingly convinced that it would be better
    to issue a clarifications RFC soon, and leave all new
    functionality to new documents. Not sure where Steven's
    hash negotiation belongs. You could reasonably call it
    a bug fix, too :-)

3) If there are new features I'd recommend getting a new
    WG and having a public discussion about the set of
    extensions we want.

--Jari

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 2 Jan 2006 11:02:01 +0200

>     WG and having a public discussion about the set of

True. I think a new WG working on version 2.1 or 2.5 or 3.0 is inevitable,
but in true IETF form, such a group will probably take 3-4 years to produce
an RFC.  If we're doing a new version, everything will have to be discussed
again.

The clarification document (or BCP) can be done and in the RFC Editor's
queue in a couple of months, and not change any bits on the wire. That's the
way I think we should go.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Jan 2006 11:33:56 +0200

> (or SCTP) and lots of other stuff some people want.

I am not sure we want to put all that to the IKEv2 base document. I
think it might be better to have separate documents for those. 

> separate Best-Current-Practice RFC without any need for changing bits-on-the

Actually if it is just clarifications, with no bits-on-the wire
changes then we can probably just do the changes and aim for the next
step on the standarization (i.e. issue new rfc that will be on the
draft standard status instead of proposed standard).

The old IKEv1 RFCs (rfc 2407-2409) are now obsoleted by the RFC 4306,
so it would be good if we could start its way towards to full
standard. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Jan 2006 12:29:03 +0200

> algorithm negotiation at the same time.  

What do you mean by hash algorithm negotiation? As far I as I know we
do have that already in the IKEv2. We can negotiate PRFs and Integrity
hash algorithms separately. We do use fixed hash-algorithms in few
cases, but there is no real need for cryptographic hash-function for
those cases (hash and URL, NAT-T etc).

The only place where we do not negotiate hash functions is the case of
certificates, i.e. the signature algorithm used when signing data is
coming from the certificate (i.e. SHA-1 for the DSS, and most likely
same signature algorithm than what was used to sign certificate for
the RSA certificates). 

So what we might want to do we might want to explicitly say that the
signature algorithm used for the RSA digitial signatures should be
same than what was used to sign that certificate.

How to negotiate signature algorithms used for certificate chains is
more general problem than IKEv2 problem, and I am not sure what would
be the best way to do that.

We could for example fix this completely by using different CAs, i.e.
we would have multiple overlapping hierarchies, where each public key
is signed with multiple hash-algorithms using different top level CA
certificates having different public keys.

This way when the client sends out list of CAs it supports it would
also express which hash-algorithms it supports (it supports the hash
algorithm used by the top level CAs it lists, as otherwise he would
not be able to verify those certificates from that hierarchy).

I also think it is ok to expect that if the certificate chain
validation supports certain signature algorithms the IKEv2 AUTH
payload supports the same algorithms too, i.e. the IKEv2 and
certificate library uses same signature verification routine. This
does not say that the IKEv2 module supports same hash algorithm for
example for the integrity algorith or for prf. Signature verification
is more closely tied to the certificate validation than to the
integrity verification or prf, thus it is safe to assume that all
signature algorithm verifications use same set of algorithms.

Anyways I think all this certificate chain problem is not really IKEv2
problem, but more generic PKIX problem, that needs to be fixed there
first, and then we can fix it in IKEv2 based on the guidelines
specified there. 
-- 
[email-masked]

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 02 Jan 2006 09:17:07 -0500

>same signature algorithm than what was used to sign certificate for

I'm referring to the concerns raised in the paper by myself and ekr, on 
how to negotiate use of newer hash functions and signature algorithms 
for certificates.  Briefly, the SAi1 and SAr1 messages need to contain 
optional payloads indicating what hash functions and signature 
algorithms are accepted.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Jan 2006 07:35:16 -0800

>(or SCTP) and lots of other stuff some people want.

Serious question for the whole list, not just Yoav: why should those 
be in the base IKEvSomthing spec? Why should they not be extensions?

Which are needed for a minimal useful IKE, and which are good for 
more capable IKEs?

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 11:37:43 +0200

Steven M. Bellovin writes:
> for certificates.

Ok, so it is more of PKIX problem than IPsec problem. I always
wondered why you listed IPsec as problematic in your paper, as for
example with pre shared key or with EAP there is no hash problems in
the IKEv2.

The problem only occurs when using certificates. 

> Briefly, the SAi1 and SAr1 messages need to contain 

I am not sure that is correct way to fix it. We do not need to select
on hash function for the both directions, which happens if we put them
to SA payloads. We need to announce to the other end what hash
functions we accept and the other end will need to use one of those
when selecting hash function for the RSA key signature.

The problem is that regardless what we do if the other end does not
have certificate signed with the supported hash function, we cannot
get interoperability. On the other hand if the other hand has
certificates signed with multiple hash functions they can use the
certificate authority payload to select CAs with suitable hash
functions.

I do not think we want to modify SA payload because of this PKIX
problem. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 11:46:17 +0200

> be in the base IKEvSomthing spec? Why should they not be extensions?

I think at least Re-Auth, multiple EAP and EAP-only should all be
extensions, not part of base IKEvX spec. IKE over TCP or SCTP is
different, as I do not think we want those at all.  The very simple
IKE over TCP, where we simply say you use TCP stream to send IKE
packets, and we do not try to recover from lost TCP streams is not
really useful. On the other hand if we start to do complicated
recovery / retranmission processing for the TCP over IKE, then we can
ask what is the benefits for using TCP instead of UDP at all. 

> Which are needed for a minimal useful IKE, and which are good for 

I think the base IKEv2 now already has the minimal useful set of
features, and I do think that all extensions to it should be mostly
done as extensions, not as part of base spec. 
-- 
[email-masked]

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 03 Jan 2006 10:32:39 -0500

>I do not think we want to modify SA payload because of this PKIX

No, it is not a PKIX problem, it is an IKE problem when certificates 
are used.  Your note is dancing around the problem; I'll put it in 
concrete terms.  Suppose that either the initiator or the responder has 
RSA-MD5, RSA-SHA256, and ECC-SHA256 certificates.  Which should be used?
I agree, of course, that PKIX needs to define those certificate types 
if they're not already defined; that's quite different than saying what 
can be used in any given protocol.

For that matter, I'm not at all convinced that EAP and shared secret 
are safe.  Clearly, today's collision attacks don't cause problems.  
Would a sufficiently powerful preimage attack be a threat?  That's much 
less clear.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 18:19:01 +0200

Steven M. Bellovin writes:
> are used.

There is no way of knowing whether the other end can parse your chain,
as he might have different set of certificates and certificate roots
that you have. I.e. even when you have certificate chain from CA1
through Intermediate CA2 to end certificate CERT1, that does not mean
that other end has the exact same chain. He could have same CA1, but
could have newer intermediate CA2, which uses different hash
algorithm, and then another end entity certificate CERT2 for the exact
same private and public key for of the node.

Even when host A can verify that path does not have any unsupported
hash algorithms, that might not be true for the other end. There is
nothing IPsec or IKE can really do there, unless it defines that
chains are not used, or if they are used, they must be transmitted
completely inside the IKE. 

> Your note is dancing around the problem; I'll put it in 

If the other end has sent out certificate request for the top level
CA, and that top level CA has a hash-algorithm statement saying that
this CA hierarchy is supporting RSA-SHA1, RSA-SHA256 or RSA-SHA512
certificates (there is no such extension yet), then he would be
selecting RSA-SHA256.

Currently there is no such thing to tell in the PKIX certificates.

> can be used in any given protocol.

I think there is signature algorithms already there, but that still
does not mean that we can say anything about the intermediate
certificates the other end might see during the validation process. Or
the signature algorithms used for the CRLs etc.

> Would a sufficiently powerful preimage attack be a threat?  That's much 

If HMAC is not safe, then I think we have much bigger problems than
what we have with IKEv2. And we do already have AES128_XCBC as prf and
integrity algorithm defined for the IKEv2, thus I do not think there
is problem with EAP and HMAC or AES128_XCBC use in there.

Hmm.. actually just noticed that the EAP and shared keys are not
allowed in IKEv2:
----------------------------------------------------------------------
2.16.  Extensible Authentication Protocol Methods
...
   For
   this reason, these protocols are typically used to authenticate the
   initiator to the responder and MUST be used in conjunction with a
   public key signature based authentication of the responder to the
   initiator.
----------------------------------------------------------------------

That is one MUST that quite a few implementors in the last interop
didn't follow. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Jan 2006 08:38:49 -0800

At 11:37 AM +0200 1/3/06, Tero Kivinen wrote:
>get interoperability.

Yes.

>On the other hand if the other hand has

No. It is explicitly allowed that a trust anchor can sign its own key 
with one algorithm, but issue certificates that are signed with 
different algorithms.

At 10:32 AM -0500 1/3/06, Steven M. Bellovin wrote:
>Suppose that either the initiator or the responder has

Simple: any of the ones that chain to any of the trust anchors given 
in the CERTREQ payload that was received, as long as the side 
receiving the certificate can validate it. It is the latter part that 
we don't have today.

A simple extension (not part of the IKEv2 core) that would solve 
this: a vendor ID that says which certificate types beyond the 
required ones you can interpret. You add this to the message that has 
the CERTREQ in it.

There is no need to make this a *negotiated* item, simply an 
announcement. Adding it to the negotiation will reduce 
interoperability (because we now have a new negotiated item), and 
will not get the two parties any further than a simple announcement.

Do folks agree with this thought? If so, I can whip up a short 
Internet Draft on the extension.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 18:55:13 +0200

> required ones you can interpret. You add this to the message that has 

You do assume that both ends do see exactly same set of certificates
in their hierarchies. I.e. what happens if the host A has certificate
hierarchy using intermediate CA signed with SHA1, and that is
acceptable to B. But when B goes and fetches that intermediate
certificate from the LDAP repository there is already new version of
it that is now signed with the SHA-256, as the signer of that CA
decided to start reissuing intermediate CA certificates with stronger
hash. Now B cannot validate the path, but A do think he should be able
to validate the path. A might not refetch the intermediate CA for long
time (years) as the old one is not revoced and it has long lifetime.

> will not get the two parties any further than a simple announcement.

True. 

> Internet Draft on the extension.

If you make that kind of draft, use status notification instead of
vendor ID. We are already using status notifications for this kind of
announcements (IPcomp, transport/tunnel etc).

In any case it does not solve the problem, as we cannot solve it
without restricting what CAs can do.
-- 
[email-masked]

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 03 Jan 2006 11:57:45 -0500

>will not get the two parties any further than a simple announcement.

I agree that it's an announcement and not a negotiation.
>Internet Draft on the extension.
I very much disagree with using vendor IDs -- that's a hack that 
doesn't scale very well.  Let's be explicit about what we're announcing.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Jan 2006 09:15:30 -0800

>time (years) as the old one is not revoced and it has long lifetime.

All true, but not relevant here. Restricting chains or eliminating 
chains for PKI4IPSEC, not IKEv2.

>announcements (IPcomp, transport/tunnel etc).

Gaaah, of course.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 19:37:18 +0200

> chains for PKI4IPSEC, not IKEv2.

So shouldn't the whole problem then belong to the PKI4IPSEC group? I
mean what does it help if we do partial solution which does not solve
the problem itself, but simply moves it a bit to the one direction.

Of course if you plan to say that PKI4IPSEC will be saying: CA MUST
use exactly one signature algorithm for all intermediate certificates,
CRLs, and end entity certificates inside its hierarchy, then this
notification will fix the problem.

Before we see that in the PKI4IPSEC we do not know whether the
notification will fix the problem or simply make it less frequent. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Jan 2006 10:29:14 -0800

At 7:37 PM +0200 1/3/06, Tero Kivinen wrote:
>So shouldn't the whole problem then belong to the PKI4IPSEC group?

No.

>  I

The proposal (notify the other end which signature algorithms you can 
valdiate) solves the problem for everyone who does not use chains. 
This is probably at least 90% of the users of certificates in IPsec.

>notification will fix the problem.

Yes, and if the CA doesn't have chains, this notification fixes the 
problem. And if the CA has chains that only use the algorithms used 
in the notification, this fixes the problem.

The only problem not fixed is a CA who allows multiple algorithms in 
the chain that the user cannot resolve. That is no different with or 
without the notification.

>notification will fix the problem or simply make it less frequent.

Two things:
- The main document for PKI4IPSEC is now in WG last call there. If 
you are concerned with what it says, this is a very good time to read 
it and comment.
- Less frequent is good.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 20:35:51 +0200

> This is probably at least 90% of the users of certificates in IPsec.

It does not solve the problem if CRLs are used, as they can again use
different algorithm, especially if the other end uses OCSP or
something else and the other end CRLs.

Actually if we limit ourselves to hierarchy where we have CA cert,
end entity cert and the CRL all signed with same hash algorith, then
we do not need to anything for IKEv2. The negotiation happens
automatically by selecting the right CA. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Jan 2006 13:34:43 -0500

A CA might support more than one hash and/or signature algorithm. 
Although this is rare today, it may be more common as CAs transition 
to new hash algorithms in the future.  The primary problem is 
discovering which certs have been issued by a CA under more than one 
algorithm, i.e., to detect when there is a choice. This has generally 
been viewed as a directory search problem, rather than a problem to 
be addressed via an extension. We do have an exception to this 
general rule: a new I-D in the S/MIME WG: smime-certcapa-05.txt. 
This extension defines a way for a cert to advertise the (S/MIME) 
crypto capabilities for an S/MIME recipient.  So, one could argue 
that an analogous extension in a CA cert could be used to advertise 
the cert/CRL algorithm capabilities of a CA, as a hint to  request 
certs or CRLs using other algorithms, either from a peer or from a 
directory. If one adopted this approach, then the solution might be 
viewed as a PKIX issue rather than an IPsec issue.

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Jan 2006 15:22:31 -0600

> completely inside the IKE. 

So, the cert paths are not the real issue here.

The real issue is having the ability to migrate from one algorithm to
another, where "migrate" != "flag day."

Eventually one would like to end the migration by dropping support for
legacy algorithms, which means no longer "interoperating" with peers
that were not updated in a timely fashion.

I think you're right though that the SA payloads are the wrong place to
fix the problem since the SA payload "is used to negotiate attributes of
a security association" whereas what we want is to negotiate selection
of certs used to authenticate the peers in IKEv2.

Nico
--