Subject: IKEV2: Issue #4 Revised Identity

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 07 Feb 2003 22:39:34 -0500

This item has not received as much discussion as the working group
chairs have hoped.  In the past week, Paul Hoffman has sent a message
questioning the process by which the working group chairs would
attempt to determine the consensus position of the working group.
Our position about this the process issue has been addressed in an
earlier message.  

As far as technical discussion of this proposal, Cheryl Madson and
Scott Kelley both agreed that from a requirements standpoint, the
behavior under-specification of certificate handling in IKEv1 needs to
be avoided.

Francis Dupont noted that either revised-identity draft or sections
of the draft-ietf-ipsec-pki-profile I-D would serve to fully define
certificate handling.  This point was echoed by Michael Choung Sheih,
who pointed out that the pki-profile document would address these
issues.

Derrell Piper agreed, and also expressed concerns about how "the
management paradigm for many vendors is tied to the existing IKE
identity types, so wholesale revision on this area might well
represent a serious headache for many vendors".  He was also concerned
that implementing revised-identity might force vendors to "start from
scratch" at the next IKE bake-off.  He contrasted this with the impact
of the other IKEv2 protocol changes, which are largely transparent
(aside from the need to delete some options) to existing management
software, end-user documentation, and regression testing.

Gregory Lebovitz has spoken up in favor of revised identities, agreeing
with the central premise of the revised-identity I-D that by using the
certificate itself as the identity, it eliminates a number of
interoperability problems which original IKE implementations suffered
at the bakeoffs.  (This issues have largely been settled at this
point, although to quote Cheryl Madson, "the WG has been extremely
apathetic about any attempts to clarify things", by which presumably
she is referring to the pki-profile I-D, and perhaps earlier attempts
to specify certificate handling.)   

Gregory also argued that most deployed uses of IPSEC are using shared
secrets, and are not certificates, and that that therefore this is an
opportunity to simplify how certificates and identity are handled.
While it is certainly a true statement that IKEv2 represents an
opportunity to change how certificates are handled, the deployment
status of certificate-based IPSEC clients/servers seems to be mostly
irrelevant to the question at hand, since nearly all or most IPSEC
implementations support certificates.  Gregory's observation does
imply, however, that the number of customers/administrators that might
require retraining is small; however, it does not change the work
required of IPSEC implementors to make (perhaps significant) changes
to the implementation, documentation, and training to support the
revised identities.

The choice between the working group, then is between using language
taken from pki-profile-01 to make explicit when certificate payloads
are sent, or choosing the revised-identity proposal.  More comments
about the tradeoffs inherent between these two choices are hereby
requested.

					Barbara Fraser
					Ted Ts'o
					IPSEC working group chairs

---

From: Eric Rescorla <[email-masked]>
Date: 10 Feb 2003 19:05:47 -0800

I don't see how we can reasonably move forward with the revised identity
proposal as is, for a number of reasons:

(1) There's no way to use caching without having HTTP access.
    This is quite undesirable since these two issues are
    actually unrelated and it's reasonable to believe that
    there will be a significant number of agents which don't
    have HTTP access but can cache. Even if one believes that
    all agents have HTTP access, the need to do an HTTP
    fetch adds significant additional latency.

    What you actually want is for peer A to say "I have the
    following cert cached for you. Either send me an OK
    or send me a new cert." But there's no way to do that
    with this proposal. 

(2) It's underspecified.

    (a) The actual contents and encodings of TrustedRoot and IDAccepted
    payloads are not specified.

    (b) The actual data that's at the target of the URL is left
    unclear. What's the MIME type? What is the actual ASN.1 type
    of the data?
	
    (b) New error codes are invented but not actually assigned.

(3) Removal of semantically meaningful IDs. There are a number of
    different ways in which it might be meaningful to name a
    peer (e.g. IP address, FQDN, etc.) This proposal reduces
    the names to whatever happens to appear in the certificate.
    Since certificates often have multiple name forms of 
    different types, or worse yet, everything compressed into
    the CN, this proposal is going to make it very hard
    for a verifier to figure out what the peer's identity is.

(4) It invents new mechanisms to do things that do things that
    are already done (confusingly) in IKEv1. The problem with
    IKEv1 certificate handling is largely that it's underspecified.
    Keeping essentially the same certificate handling in IKEv2
    but clarifying the semantics allows us to tighten IKEv1
    as well. This is a good thing since we are probably stuck with
    IKEv1 for a while.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 Feb 2003 21:19:18 -0800

>(1) There's no way to use caching without having HTTP access.

Sure you can. You can cache earlier receipt of a full cert in IKE messages.

>     have HTTP access but can cache.

See above.

>  Even if one believes that

Which is why it is not mandatory. Gateways that are not concerned 
about latency on the first hit use it, others don't. They can even 
change based on current latency times.

>     or send me a new cert." But there's no way to do that

But that's a reasonable counter-proposal that gets to the same end: 
not having to send certs each time, and therefore avoid the failure 
in routers and firewalls that don't pass fragmented UDP. Without a 
hash-of-cert mechanism, implementations will continue to suffer this 
silent failure.

>     payloads are not specified.

This is trivial to fix, and was supposed to be done if the WG showed 
more interest.

>     unclear. What's the MIME type? What is the actual ASN.1 type

Not true; this has been fully specified in the PKIX and OpenPGP WGs 
for many years.

>	    (b) New error codes are invented but not actually assigned.

I don't understand this.

>     the names to whatever happens to appear in the certificate.

Not true at all. It works exactly like IKEv1 works, except that you 
don't have the ID payload. If the receiver knows that Joe is 
identified by his IP address, regardless of what is in the 
certificate, the receiver uses that information.

>     for a verifier to figure out what the peer's identity is.

To recap: IKEv1 implementers cannot decide what to do with the 
information in the ID payload when used with certificates. Does the 
receiver have to use it as the identifier? What if the ID payload 
contains something that isn't in the certificate? What if the ID 
payload matches something in the certificate but the receiver uses 
some other type of identification?

There are almost as many answers to these questions as there are 
implementations. Different profiles have attempted to pick a single 
meaning, and each proposal has had a shower of complaints because it 
doesn't match with what many implementers are already doing while 
following the lack of information in IKEv1.

I take it that you think this is just fine for IKEv2. Others, 
particularly implementers who have been hurt by the lack of 
interoperability, have said they disagree.

>     are already done (confusingly) in IKEv1.

Fully agree.

>  The problem with

Right.

>     as well.

But this is not what the WG chairs have proposed. There is no 
proposal for clarifying the semantics in IKEv2 on the table. We are 
left with the same nothing as in IKEv1. Why would an implementer go 
to IKEv2 if the major user problems with IKEv1 are left the same?

>  This is a good thing since we are probably stuck with
>     IKEv1 for a while.

Folks who have been badly hurt by the lack of interoperability might 
disagree with that assessment.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: 10 Feb 2003 23:07:13 -0800

> Sure you can. You can cache earlier receipt of a full cert in IKE messages.
How do you tell the peer that you don't want to get the
cert in the revised identity scheme?

> not having to send certs each time, and therefore avoid the failure in
> routers and firewalls that don't pass fragmented UDP. Without a
You need some kind of mechanism. It doesn't necessarily have to
be hash-of-cert. Section 3.3.11.2 of draft-ietf-ipsec-pki-profile
describes how to make this work with the current CERTREQ payload
(using the DN).

> This is trivial to fix, and was supposed to be done if the WG showed
It may or may not be trivial to fix. I generally prefer to see
protocols fully specified before I draw that kind of conclusion.

> Not true; this has been fully specified in the PKIX and OpenPGP WGs
I don't recall such a mechanism, and Russ was in the WG meeting
when TLS was thrashing around for one. You have a reference? In
any case, the revised identity draft doesn't reference it.

> >	    (b) New error codes are invented but not actually assigned.
Section 4 of your document names a bunch of new errors but
doesn't give them codes.

The point isn't that one couldn't specify this stuff, but
merely that your proposal isn't finished. Given that
we're proposing being done in 4-5 days, that's pretty scary.

> certificate, the receiver uses that information.
In IKEv1 the authenticating party tells the client what its identity is
and then the verifying party compares the ID payload to the
certificate. In your scheme the verifying party has to
guess based on the certificate, which is a potential problem
if the cert has ambiguous identity information.

[IKEv1 is underspecified]
> interoperability, have said they disagree.
No, I don't think it's just fine. I think that it needs to be
nailed down. 

> But this is not what the WG chairs have proposed. There is no proposal
> for clarifying the semantics in IKEv2 on the table. We are left with
> the same nothing as in IKEv1. Why would an implementer go to IKEv2 if
> the major user problems with IKEv1 are left the same?
As far as I can tell, it is what they've proposed. Quoting from
Ted's message:

        The choice between the working group, then is between using
        language taken from pki-profile-01 to make explicit when
        certificate payloads are sent, or choosing the
        revised-identity proposal.  More comments about the tradeoffs
        inherent between these two choices are hereby requested.

-Ekr

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 11 Feb 2003 10:34:48 -0800

At 11:07 PM -0800 2/10/03, Eric Rescorla wrote:
>certificate.

That is one interpretation; there are many others. As others have 
said before on this thread, anyone who has gone to the bakeoffs knows 
this.

>  In your scheme the verifying party has to

There is no such thing as a certificate with ambiguous identifying 
information. You inherently trust the certificate issuer to give the 
right information.

>         inherent between these two choices are hereby requested.

So, let's ask the WG chairs then: is Eric's interpretation correct? 
Is this also a WG last call on pki-profile-01? If not, then IKEv2 
will be plagued with the same interop problems that IKEv1 has. If it 
is a last call, the WG should be discussing the document, which has 
gotten no traffic to date.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: 11 Feb 2003 13:40:04 -0800

Paul Hoffman / VPNC <[email-masked]> writes:

> That is one interpretation; there are many others. As others have said
> before on this thread, anyone who has gone to the bakeoffs knows this.
I agree that it's ambiguous. I'm concerned to clarify it.
I believe the interpretation i just provided is the most
straightforward one.

> information.
I'm afraid that's not true. Consider what happens when you get
a certificate with CN="www.rtfm.com". Is that a domain name?
Someone's name? Something else?

-Ekr

---

From: "Greg Carter" <[email-masked]>
Date: Tue, 11 Feb 2003 21:11:35 -0500

Mucho comments below...

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Paul Hoffman / VPNC
>Sent: February 11, 2003 1:35 PM
>To: [email-masked]
>Subject: Re: IKEV2: Issue #4 Revised Identity

>said before on this thread, anyone who has gone to the bakeoffs knows

Yeah they know it is the correct way to do it.  And if they were not doing
it before now, the pkix profile draft makes it explicitly clear.  I
remembered talking about this a lot 'back in the day', and here is a message
from 1998 that I wrote to the list:
http://www.sandelman.ottawa.on.ca/ipsec/1998/07/msg00074.html
and another from 1999
http://www.sandelman.ottawa.on.ca/ipsec/1999/10/msg00212.html

I am sure I mentioned it in other emails, but I am guessing that was to the
ANX bakeoff (bakeoff!) list.  At the bakeoffs I know I told anyone who would
listen.

>silent failure

Just so I am clear, with your Revised ID proposal the only way to achieve
certificate caching is if the IKE implementation supports retrieval of
certificates via http URLs? Further the only way to prevent IKE UDP packet
fragmentation is via out of band certificate/chain retrieval (http)?

So the problems solved are caching and UDP fragmentation (BTW the latter is
not a stated goal of your draft).  I am not a router guru so I don't know
the details of the fragmentation issue.  I guess I would like to see a
better description of the UDP fragmentation problem if that is one of the
goals.  I think I did see it once at a bakeoff but that was with large CRLs,
and at the time was dismissed as a problem with the receiver.

Problems with the Revised Identity proposal:
 - mandates HTTP to retrieve the certificate.  What about the rest of the
chain (intermediate CAs and CRLs)?  Ideally you would allow either LDAP or
HTTP.  If I can do full path building via a repository it will most likely
be via LDAP (well that is my experience), not HTTP.  With the risk of being
stoned to death I'll mention WAP defined a decent certificate URL format for
both HTTP and LDAP.  So if this proposal goes further you might want to look
at it.
 - does not allow CRLs in band.  Whether or not IKEv1 implementations use
this feature today isn't the issue, the fact is you can do this in IKEv1 and
it handles the VPN case nicely.  Gateway pushes down its certificate, any
intermediate certificates, and any CRLs needed over IKE.  Client has
everything it needs to validate, doesn't have to go to any remote repository
or validation server (which presumably it couldn't even if it wanted to).
 - Certificate bundling - The end of section 3.1 implies that a certificate
bundle will contain end entity certificates with different IDs (CAs?).  How
am I supposed to know which certificate to use (look in the ID payload
haha)?  I assume they will all have different key pairs, so the process of
choosing one becomes "attempt signature validation for cert N, repeat".
This seems a bit at odds with the notion of "The certificate is the ID"
philosophy.  I would rather see a definition that limited the cert bundle to
only one end entity certificate (or only one with the correct key usage).

Along the same lines, I don't understand this statement from section 3.1:
 "If a system can resolve URLs, it SHOULD use type 3 and 4 unless it is sure
that it does not have the certificate of the other side, such as if it has
just recovered from a crash and its cache is empty."

If it can resolve URLs, it can resolve URLs, it doesn't matter if the cache
is empty.  If the cache is empty then it, oddly enough, resolves the URL :)
Maybe I am missing something.

Caching Alternatives
I haven't put too much thought into this, and I expect it is too late to
define something like this but here goes:
One way to add explicit caching would be to have a new payload "CERT_HASH"
which would optionally be sent in messages 1 & 2.   The payload would
contain a list of hash values of the end entity certificates you could
possibly send to the other end.  If the receiver of the "CERT_HASH" payload
doesn't have one of those hash values in it's cache then it sends the cert
request payload in message 3 or 4.  If you do not receive a CERT_REQ
payload, do not send your certificate.  This mechanism could be defined to
indicate what CERT type is associated with the hash (caching CRLs etc).  IDs
remain as in IKEv1.  Not sure if this will leak identity...

Of course the another alternative is to do nothing.  A clever implementation
could keep state associated with the peer (works for clients, not the VPN
gateway), or define your own vendor payload ("Hey I connected yesterday, so
you probably have my cert cached so don't ask for it unless you think you
need it").

UDP Fragmentation
Neither of the above alternatives would help with fragmentation, but I don't
know enough about the problem.

One last thing... in another email to the list you mentioned the problems of
IKEv2 referencing the profile draft.  Putting aside IETF protocol, the
difference between referencing it and the Revised ID draft is that the
profile draft clarifies how existing implementations should already be
working, not defining new behaviour.

Greg Carter

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 11 Feb 2003 19:58:46 -0800

At 9:11 PM -0500 2/11/03, Greg Carter wrote:
>certificates via http URLs?

Nope, nothing in the document says that. You can cache any certs you 
know about from any means, such as from people who sent them to you 
in IKE.

>  Further the only way to prevent IKE UDP packet

Nope, nothing in the document says this either. The only way to 
prevent IKE UDP packet fragmentation is to make the fragments small 
enough not to fragment. URL-and-hash will help that. Sending only a 
single small cert will help that. Sending raw RSA keys will help that.

>and at the time was dismissed as a problem with the receiver.

This has been discussed in the WG a few times. Basically, some 
devices will drop any fragmented UDP packets either all the time or 
when their reassembly buffers are full.

>HTTP.

Ideally for whom? That is certainly not ideal for IPsec implementers.

>   If I can do full path building via a repository it will most likely

IPsec vendors have looked at it, and they came to a different 
conclusion than the PKI vendors. No surprise there.

See above.

>haha)?

The ID payload wouldn't help you there, obviously. You parse the 
certificates looking for CAs you trust. If multiple certs match, you 
parse them for IDs that you trust. Done.

>   I assume they will all have different key pairs, so the process of

Spoken like a true PKI vendor. :-)

>only one end entity certificate (or only one with the correct key usage).

That's a possibility. Well, it was a possibility before the proposal was axed.

>IKEv2 referencing the profile draft.  Putting aside IETF protocol,

Er, this is a WG in the IETF. We don't get to "put aside IETF protocol".

>  the

...and thereby screwing all the vendors who implemented IKEv1 in good 
faith, following what little it said and making guesses about the 
rest. The IETF has rules about not doing that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: 11 Feb 2003 23:07:33 -0800

Paul Hoffman / VPNC <[email-masked]> writes:

> know about from any means, such as from people who sent them to you in
> IKE.

Right, but how do you arrange to communicate what you've cached to the
peer so that they send you the right certificate if your cache is
invalid for some reason (assuming that you can't retrieve the
right one with HTTP)?

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Feb 2003 04:25:32 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
    Eric> Paul Hoffman / VPNC <[email-masked]> writes:

    >> At 9:11 PM -0500 2/11/03, Greg Carter wrote: >Just so I am clear, with
    >> your Revised ID proposal the only way to achieve >certificate caching
    >> is if the IKE implementation supports retrieval of >certificates via
    >> http URLs?
    >> 

    Eric> Right, but how do you arrange to communicate what you've cached to
    Eric> the peer so that they send you the right certificate if your cache
    Eric> is invalid for some reason (assuming that you can't retrieve the
    Eric> right one with HTTP)?

  That's really not a problem for IKE.
  If the right goop isn't there, you loose.

  That's why we want to just send the URL (or URN if you want) where the
certificate, whatever chain you need, and maybe the CRL, can be
found. 
  Sending the whole thing makes total sense for TLS, and it works well for
HTTPS, SMTP(STARTTLS), but not for IKE over UDP.  Maybe IKE v3 will run over
SCTP... maybe not. 

  Honestly. With something like 80% of VPNs running pre-shared secrets
because there are multiple implementations out there that can't even cope
with importing or exporting even a self-signed certificate (or making it
so hard nobody bothers), I really do not think that we need any more 
esoteric situations.
  Once we have 90% of deployment running with public keys, and the rest doing
legacy auth, maybe with public keys assymetrically, then it will be time
worry about extended chain resolution etc... 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Feb 2003 12:27:00 +0100

In your previous mail you wrote:

=> I agree: even if the revised identity proposal seems a bit drastic
it fully solved the issue (this is why I support it).

=> in my IPsec for Mobile IPv6 experiments, the message with the whole
thing *never* reached the other end at the first try!
I agree IKE should run over SCTP (with funny consequences on peer
addresses :-) but perhaps it is too soon to propose this?
IMHO IKE is a signaling protocol so should use SCTP...

=> unfortunately with weak implementations of XAUTH for mobile clients...

=> I can't parse your conclusion: do you support or not the revised
identity proposal for IKEv2?

     Once we have 90% of deployment running with public keys, and the
  rest doing legacy auth, maybe with public keys assymetrically, then it
  will be time worry about extended chain resolution etc...
   
=> IMHO a large part of the issue comes from the network access control
(the AAA) done by IKE when IKE has no native interface with an AAA system.
The PKI stuff should be integrated with legacy authentication
in order to provide a native AAA interface in charge of the strong
authentication with authorization and accounting as goodies...

Regards

[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Tue, 11 Feb 2003 22:18:04 -0800

Paul,

Comments below...

-brian
[email-masked]

> know about from any means, such as from people who sent them to you

Of course you can cache anything you want, but what the Revised ID
proposal is missing is a way to specify to a peer that it needn't
resend the already-cached items.  Certs and CRLs are large, processing
them is costly, and IKE is over UDP, so some see not having to resend
these as a real benefit.  YMMV.

> Ideally for whom? That is certainly not ideal for IPsec implementers.

That the caching mechanism does not support CRLs does seem like a shortcoming.
Regarding LDAP, I think Greg might have a good point here, at least one that
deserves more discussion.

> rest. The IETF has rules about not doing that.

The pki-profile draft is currently being revised due to comments that
were posted to the list, so now is an excellent time to submit feedback
describing how the draft could be improved.  BTW, the currently draft is
advertised as a straw man, so no one should feel "screwed" by it.

---

From: Eric Rescorla <[email-masked]>
Date: 12 Feb 2003 07:22:10 -0800

>   If the right goop isn't there, you loose.
Uh, then why bother having caching at all? If you're going
to have caching you have to have cache invalidation.

> certificate, whatever chain you need, and maybe the CRL, can be
And if the implementation can't do HTTP you're completely SOL--or
rather you have to send the whole chain over UDP, which is
what you say you're trying to avoid.

> so hard nobody bothers), I really do not think that we need any more 
It's my view that part of REASON that so many implementations run shared
secrets is that IKE certificate handling is so screwed up.

-Ekr

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 12 Feb 2003 10:01:39 -0500

On Wed, Feb 12, 2003 at 02:36:51PM +0100, Pekka Riikonen wrote:
> 
> The revised identity can solve the problem of defining what the ID
> actually is and when not to send certificates.  

Well, the revised identity draft does solve the problem, essentially
be eliminating the ID and CERT payloads altogether, conflating the
IKEv1 concept of identity and certificate, and instead always
requiring both sides to send a certificate, which *is* the identity.  

> However, having read the draft it is in my opinion clear that same
> features can be accomplished without introducing new payloads, but
> using the Certificate Request (CR) payload, and revising the
> specification for this payload.  

Well, yes, and that's what the pki-profile document does, and without
needing to change the IKEv1 specification (but instead making the
specification tighter):

   3.3.7. Presence or Absence of Certificate Request Payloads

   When in-band exchange of certificate keying materials is desired,
   implementations MUST inform the peer of this by sending at least one
   CERTREQ. An implementation which does not send any CERTREQs during an
   exchange SHOULD NOT expect to receive any CERT payloads.

	...

   3.3.8.1. Specifying Certificate Authorities

   Implementations MUST generate CERTREQs for every peer root that local
   policy explicitly deems trusted during a given exchange. Implementa-
   tions MUST populate the Certificate Authority field with the Subject
   Name of the trusted root, populated such that binary comparison of
   the Subject Name and the Certificate Authority will succeed.

   Upon receipt of a CERTREQ where the Certificate Type is either "X.509
   Certificate - Signature" or "X.509 Certificate - Key Exchange",
   implementations MUST respond by sending each certificate in the chain
   from the end entity certificate to the certificate whose Issuer Name
   matches the name specified in the Certificate Authority field. Imple-
   mentations MAY send other certificates from the chain.

The IKEv1 interoperability problems arose because IKEv1 underspecified
how the payloads should be used.  

> What is nice about revised identity draft (as opposed to pki-profile) is
> that it allows the use of URL to tell where the cert is available.  This
> too could be done by revising the Certificate payload by adding new
> encoding types (like URL) if this feature is really needed.

As I have pointed out in the past, this could be added to IKEv2 (and
IKEv1) for that matter, simply by defining a new certificate encoding
type to the CERT payload.  This issue is independent of whether to use
a IKEv1 or Revisied identity-style approach.  The tradeoffs are
reducing the UDP packet size, versus additional complexity caused by
(a) needing to have some kind of access controls since you don't want
to responder to visit an arbitrary URL based on an unauthenticated
request from the initiator, and (b) dealing with the case where the
initiator doesn't have access to the global internet (i.e., in the
dialup VPN case), and is presented with a certificate URL.

						- Ted

---

From: Eric Rescorla <[email-masked]>
Date: 12 Feb 2003 07:18:39 -0800

> rest. The IETF has rules about not doing that.

I disagree.

In fact, it's SOP to publish new drafts that clarify behavior
that was underspecified in previous drafts. Naturally, this
occasionally screws people who took the interpretation not
chosen and that's a strong incentive to choose carefully.
But at the end of the day there has to be one interpretation
and that means that someone has to change.

From RFC 2026:
   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

...

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

-Ekr

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 12 Feb 2003 10:27:43 -0500

> gotten no traffic to date.

If you take a close look at the pki-profile ID, you will find that it
is really two documents in one.  Following the introduction and the
background information, section 3 is a profile of ISAKMP/IKEv1, and
section 4 is a profile of PKIX/x.509 certificates.  

If you then take a closer look at section 3, a good part of the
material in section 3 are definitions already found in the IKEv1 and
IKEv2 drafts (but which were necessary to make pki-profile a
standalone document), and the rest are a tightening up of the
requirements, because IKEv1 was too loose in its specifications.  For
example, pki-profile states that if in-band certificats are expected,
implementations MUST inform the peer of this by sending at least one
CERTREQ, and that implementations MUST respond to CERTREQ's by sending
a CERT payload with the appropriate certificate.  

This is all arguably good stuff that should have been in the original
IKEv1 specification, but which was very unfortunately missing.  If it
had been there, I suspect most of the interoperability headaches that
IKEv1 implementors suffered from could have been avoided --- and I
believe a goood part of what is in the pki-profile is essentially
summarizing what IKEv1 implementors have had to discover the hard way
from bakeoffs, and codifying it into a specification.  In essense,
pki-profile supplies the semantics to IKEv1, which in the case of the
CERT and ID payload, very unfortunately had synxtax only, but no
semantics in its original specification.  

In our summary of the revised identity issue, we pointed to comments
made by at least two working group members, who stated that an
alternative to revised identity would be to adopt text from the
pki-profile ID to fully define certificate handling.  Presumably, this
would be taking selected text from section 3 of this document, which
arguably should have been in IKEv1 in the first place, and not in a
separate profile document.  Fortunately, we have an opportunity to fix
this in IKEv1, and Francis Dupont stated that if we didn't incorporate
the revised-identity proposal, that taking text from pki-profile-01
would be a requirement.

Hence, our sumary of the discussion on this issue pointed out what we
believe are the alternatives facing the working group:

#1) adopting text from the revised-idendity I-D and including it into
	the ikev2 I-D

#2) adopting text from the pki-profile I-D and including it into ikev2 I-D

I am in agreement with you in that I wish there had been more
discussion on both proposals.  Howeer, neither I-D is new, and to my
knowledge no one has shown substantive, show-stopping technical
problems with either text.  They have tradeoffs, to be sure, and
indeed the dispute seems to center around preferences towards one
engineering tradeoff versus the other.  But one way or another, we
need to decide.

						- Ted

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Feb 2003 15:55:48 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Francis" == Francis Dupont <[email-masked]> writes:
    mcr> because there are multiple implementations out there that can't
    mcr> even cope with importing or exporting even a self-signed
    mcr> certificate (or making it so hard nobody bothers), I really do
    mcr> not think that we need any more esoteric situations.

    Francis> => I can't parse your conclusion: do you support or not the
    Francis> revised identity proposal for IKEv2?

  I support:
    http://www.sandelman.ca/ipsec/2002/12/msg00250.html

  I specifically am not interesting in tilting at the wind "what if" for
certificate retrival. I.e. the problems that Eric described. I'm sure that
they are real problems. They are just so far away from where we are now, that
I do not think that we can engineer a proper solution to them.

    Francis> => IMHO a large part of the issue comes from the network access
    Francis> control (the AAA) done by IKE when IKE has no native interface
    Francis> with an AAA system.  The PKI stuff should be integrated with
    Francis> legacy authentication in order to provide a native AAA interface
    Francis> in charge of the strong authentication with authorization and
    Francis> accounting as goodies...

  An IKE gateway can talk AAA, or radius, or COPS, or whatever it likes.
  We suffer greatly because there are vendors who think that they can read
one document and implement an entire solution to a wide set of
problems. Actually, I doubt any of the real problem ones are still in
business :-)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Feb 2003 16:01:18 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    Eric> Michael Richardson <[email-masked]> writes:
    >> That's really not a problem for IKE.  If the right goop isn't there,
    >> you loose.

    Eric> Uh, then why bother having caching at all? If you're going to have
    Eric> caching you have to have cache invalidation.

  Don't all these fancy certificates come with expiry dates? 
  Maybe the HTTP URL access mechanism means to do:
	s/(.*)\.cert$/\1.crl$/

  and that's where you find the crl. I don't know. I punt to pkix to decide
what the "URL" means. I think that there are documents now that tell me
how to get stuff via HTTP, right?

    >> certificate, whatever chain you need, and maybe the CRL, can be found.

    Eric> And if the implementation can't do HTTP you're completely SOL--or
    Eric> rather you have to send the whole chain over UDP, which is what you
    Eric> say you're trying to avoid.

  No, if the implementation can't do HTTP, then I buy another implementation,
or I preconfigure the appropriate chain, or I simplify the trust model.

  The problem that people doing certificates keep running into is that they 
keep thinking that they are building the "global PKI" and run into how do
two random people communicate securely, even though there isn't a global PKI.

  This is why you say things like this - you assume that the two parties are
random people and don't have any clue about each other's situation. So far,
there isn't anyone that wants to do this kind of thing that is using pkix
certificates. 90% of deployed certificate based VPNs are inside a single
enterprise.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 12 Feb 2003 18:14:31 -0500

> how to get stuff via HTTP, right?

Yes, and there's also apparently some way to embed URLs pointing to
(multiple) CRL distribution points into certificates.

					- Bill

---

From: Eric Rescorla <[email-masked]>
Date: 12 Feb 2003 15:11:54 -0800

>   Don't all these fancy certificates come with expiry dates? 
Not all rollovers or reconfigurations happen on expiry dates.

Why not just get the design right in the first place?:

> certificates.
This works just fine with TLS.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 12 Feb 2003 15:19:41 -0800

> #2) adopting text from the pki-profile I-D and including it into ikev2 I-D

Regrettably, I don't think that either of these possibilities is
ready for prime time. Although the I-Ds have been out there for
a while, neither has seen much review and I'm not convinced that
either is finished enough to go to WG last call at this time.

If you're a pki-profile guy (which I clearly am), then the obvious
thing to do is go ahead with IKEv2 as is and then publish the
pki-profile document ASAP (where ASAP is "as soon as the WG
really reviews it"). Since it's just a clarification/profile
for IKE, this shouldn't be a problem.

The other alternative, of course, is to actually let the IKE
authors merge one of the proposals into IKE and then 
give it some time to be reviewed, but this blows your deadline.

-Ekr

---

From: "Greg Carter" <[email-masked]>
Date: Wed, 12 Feb 2003 10:50:04 -0500

>know about from any means, such as from people who sent them to you

Yeah but the only way for it to be useful is if you support URL retrieval.
If the only way I can obtain a certificate is in band IKE but I say I
support URL retrieval (the only way to get the hash) and therefore you send
me a URL how do I get your certificate?  Does this mean that you propose
that I first send an IDAccept of URL then if I can't find it in the cache
then fail IKE, and retry with an IDAccept of Certificate?  Otherwise I don't
see how to get around the start-up problem.

>Nope, nothing in the document says this either. The only way to

Yeah I know nothing in the document says that, in fact there is no mention
of UDP fragmentation in the document at all.

>Ideally for whom? That is certainly not ideal for IPsec implementers.

So here we are defining mechanisms for X.509 and you don't even want to
consider the optional use of a DIRECTORY for retrieval of certificate
information.  Great.  So instead you'll dupe IPSec vendors into believing
that if they implement HTTP that they will magically have everything they
need to do certificate validation.  This would only work for rather simple
certificate chain validation (or handing it off to some as of yet not
defined certificate validation server).  I don't know of any CA that will
publish a cert chain bundle to an HTTP server, however I have been lead to
believe that LDAP client code is in a fair amount of router code.

>>deleted crl stuff

I don't follow.  If you are going to spec out a solution for X.509 you can't
ignore CRLs.  I haven't seen any discussion on this list.

>The ID payload wouldn't help you there, obviously. You parse the

Hence the haha, since your proposal does away with it in its current form.

>parse them for IDs that you trust. Done.

But that would mean multiple queries to a policy database looking for a
match.  With the IKEv1 style you explicitly have an ID (in the ID Payload)
which to match on.  With your method you would have to look for matches in
your policy db for each ID in a certificate, and then possibly do that for
multiple certificates.  Yes I know you said that the implementer is free to
chose which ever ID they want to then use in the certificate, but I fail to
see how this helps interoperability.  If I choose to only accept DNs, and
you choose to only accept DNS (in the subjectAltName) as "ID" how do we
interoperate?  In the current scheme an implementation would have to accept
any of the ID types as input to the policy engine, so theoretically you
could at least configure my DN as acceptable.

>Spoken like a true PKI vendor. :-)

Actually I have no affiliation.

>Er, this is a WG in the IETF. We don't get to "put aside IETF protocol".

Yeah when logic and reason fail...

>rest. The IETF has rules about not doing that.

From the DOI:
"When an IKE exchange is authenticated using certificates (of any
   format), any ID's used for input to local policy decisions SHOULD be
   contained in the certificate used in the authentication of the
   exchange."

Yes it didn't hand hold the implementer of how to actually do the mapping,
they would have had to pick up a copy of the PKIX or X.509 specs to find
where to look for IDs (with only two places, the DN or subjectAltName).  At
every bakeoff from about Sept '97 I had a CA there with instructions on how
to put IPSec ID information in a certificate, I also had a free test site up
at http://freecerts.entrust.com/vpncerts/certreq.htm (even appears to still
work, damn) which I sent emails to the IPSec list altering any implementers
to.  And even you pointed out a 'problem' as early as 1999 to the list (and
I replied).  So if they implemented in good faith they missed a lot of
opportunities to get it right.  For the sake of argument I'll even concede
my point and agree that it was possible to get it wrong if implemented in
good faith.  However I do not see how the profile draft will punish those
people who got it wrong.  Yes they will have to fix it, but by doing so they
end up with an implementation that is secure and interoperable, that doesn't
sound like screwing anyone to me.

Greg

---

From: Pekka Riikonen <[email-masked]>
Date: Wed, 12 Feb 2003 14:36:51 +0100 (CET)

The revised identity can solve the problem of defining what the ID
actually is and when not to send certificates.  However, having read the
draft it is in my opinion clear that same features can be accomplished
without introducing new payloads, but using the Certificate Request (CR)
payload, and revising the specification for this payload.  The name
Certificate Request payload already implies or could be made to imply that
if sent, a certificate is requested, otherwise not.

Some scenarios (-> initiator, <- responder):

- I don't have remote cert
	-> send CR with the CA
	<- send cert

- I don't have remote cert and I don't know the CA (or don't care, ie.
  I just want to get your cert)
	-> send empty CR, indicating send all certs, any cert,
	   or what ever cert you are about to use with me
	<- send all, any or local policy dictated cert

- I have a cert for remote
	-> do not send CR at all
	<- do not send cert

It would be nice to be able to say that "I have _this_ cert cached, is
that ok?".  This could be done with CR payload as well, if it is revised
so that it can include the subject (or hash) of an end entity cert (by
adding new encoding type).  If it matches no cert is sent back, otherwise
local policy can rule, which then tells that cert cache must be updated.

All this would require revising the specs for CR payload handling, and
addition of new Certificate Encoding types.  The benefits is that no new
payloads are introduced, the use of CR payload is made explicit, new
encoding types are easy to add, and the verification of whether the cached
cert is correct or not can be done.  Whether or not changing/adding this
sort of thing would be acceptable, I don't know. :)

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: [email-masked]
 SILC - http://silcnet.org/        | http://iki.fi/priikone/
 Tel. +358 (0)40 580 6673          | Snellmanninkatu 34 A 15, 70100 Kuopio
 PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 12 Feb 2003 18:36:48 -0800

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: 12 Feb 2003 19:59:05 -0800

> sort of thing would be acceptable, I don't know. :)
I think this is a good idea.

-Ekr

---

From: Tero Kivinen <[email-masked]>
Date: 13 Feb 2003 02:29:14 +0200

> what you say you're trying to avoid.

For the client / remote access case you do following: If you have
certificate for the other end you ask only the hash and url of the
certificate from the other end. If you do not have certificate for the
other end then you request either PKIX certificate or certificate
bundle.

If the other end replies to your hash + URL request with hash that you
do not have in your cache (for example the key of the other end has
changed), you remove (or mark the key to be old) the old key from the
cache and restart (i.e start over and then you notice that you do not
have key for the other end and request full certificate).

When you receive PKIX certificate or bundle from the other end you
store that certificate to your cache and associate it with the
gateway, so you know next time that you have key for that site.

The gateway side normally will have connection to the internet and can
use http, thus it can always request hash + URL and cache the
certificates it fetches using http.

> secrets is that IKE certificate handling is so screwed up.

And thats why we should fix it and take the text from the
revised-identity draft.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Pekka Riikonen <[email-masked]>
Date: Wed, 12 Feb 2003 17:20:26 +0100 (CET)

On Wed, 12 Feb 2003, Theodore Ts'o wrote:

: > The revised identity can solve the problem of defining what the ID
: > actually is and when not to send certificates.
:
: Well, the revised identity draft does solve the problem, essentially
: be eliminating the ID and CERT payloads altogether, conflating the
: IKEv1 concept of identity and certificate, and instead always
: requiring both sides to send a certificate, which *is* the identity.
:
The revised identity draft effectively creates same payloads but named
differently.  We already have those but only their definition has been
sloppy.  It would seem simple to just fix where we have gone wrong instead
of replacing them.  I know what I wrote is much the same pki-profile has,
except for the specific points I tried to make:

:    3.3.8.1. Specifying Certificate Authorities
:    Upon receipt of a CERTREQ where the Certificate Type is either "X.509
:    Certificate - Signature" or "X.509 Certificate - Key Exchange",
:    implementations MUST respond by sending each certificate in the chain
:    from the end entity certificate to the certificate whose Issuer Name
:    matches the name specified in the Certificate Authority field. Imple-
:    mentations MAY send other certificates from the chain.
:
: The IKEv1 interoperability problems arose because IKEv1 underspecified
: how the payloads should be used.
:
If the CA in CR is wrong, then it's probable that implementation will not
reply with any cert.  If you have never connected with remote, don't know
who it trusts, and only thing you want is to just probe (or connect
opportunisticly) to get the remote's cert so that you can make the
decision whether you trust it or not (say, ask it from user), would not
work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty
CR.

For IKEv1 we agreed several times over the years that receiving empty CR
means sending all your local certs, or what ever your local policy happens
to dictate.  This is very good since it allows to get remote's certificate
regardless whether or not you know who it trusts, but the problem was that
it was never written down anywhere.  I'd like very much to see the MUST
NOT lifted from IKEv2 and specify that if empty CR is received the
receiver SHOULD send local cert(s).  The section 3.3.8.2 in pki-profile
"maybe or maybe not" allows this with "non-conformant"  implementations.
I think it should be either it's not allowed or it's allowed and it's
correct behavior.  Now it's like, "ok, you can't really do this, but, hey
if you do it work with it anyway"...

The second point was the ability to check whether cached cert is correct
or not.  This is very simple to do just by allowing the CR payload (by
adding new cert encoding type) to have the cert information (subject,
hash, what ever) in the CR data.  OTOH, same feature could work with
revised identity draft too (in either TrustedRoot or IDAccepted)...

	Pekka

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 13 Feb 2003 22:20:44 +0100 (CET)

: > opportunisticly) to get the remote's cert so that you can make the
: > decision whether you trust it or not (say, ask it from user), would not
: > work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty
: > CR.
:
: Could you provide a use case where this is a problem?  Let's say that I
: know I trust CAs A and B, and I tell you that I trust them by sending
: you CERTREQ payloads containing the DNs of these two CAs.  If you don't
: have a certificate backed by A or B, we have no common ground and I
: cannot hope to authenticate you, so IKE fails.  Are you thinking
: opportunistic IPSec?
:
One case is opportunistic IPSec, second is use of self-signed certs.
Assuming your friend has only a self-signed cert it would be nice to get
that cert in IKE so that you could cache it (and verify it, sign it, etc).

	Pekka

---

From: Brian Korver <[email-masked]>
Date: Thu, 13 Feb 2003 12:58:42 -0800

> work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty

Could you provide a use case where this is a problem?  Let's say that I
know I trust CAs A and B, and I tell you that I trust them by sending
you CERTREQ payloads containing the DNs of these two CAs.  If you don't
have a certificate backed by A or B, we have no common ground and I
cannot hope to authenticate you, so IKE fails.  Are you thinking
opportunistic IPSec?

> revised identity draft too (in either TrustedRoot or IDAccepted)...

- brian
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Feb 2003 14:46:31 -0500

>(multiple) CRL distribution points into certificates.

See RFC 3280, section 4.2.1.14, on  CRL Distribution Points.

    The CRL distribution points extension identifies how CRL information
    is obtained.  The extension SHOULD be non-critical, but this profile
    RECOMMENDS support for this extension by CAs and applications.

Russ