Subject: RE: Confirm decision on identity handling.

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 29 Apr 2003 17:43:15 -0700

==Attempted summary of thread to date:
- Paul proposed final text.

- Gregory thought it was a bit too loose for interop, and proposed text with
same intent, just more explicit (or at least I tried to). This text made it
clear that interoperability bar is satisfied when when ID payload is used
with certs and no connection is made between the two. It allowed for other
use cases, but these would be implementation specific, and (honestly) are
not guaranteed to interoperate.

- Scott asserts that in order to guarantee interoperability, as a
responder I will need to have the ability to ignore the ID payload and
parse the cert instead for policy lookup, so why not simply treat the cert
as the ID in this case, and not add superfluous ID payloads which someone
may or may not ignore? Scott wants it as cut and dry as possible, for the
sake of interop.

- Jim K. would like the option to be able to use ID payload for policy
lookup, and cert contents for credentials. 

- we need something for policy lookup when the cert is not included in the
exchange, but are used. ID payload is a way to do this.

== In order to finalize something, I would like to re-assert my proposed
text and ask for either replacement text or to ratify this text:

Goals of text:
> - the base interoperable way is DO NOT CHECK ID matches cert. This is the
only guaranteed interoperable way.
> - implementations MUST be able to handle IDs that do not 
> match cert contents
> - implementations MAY be configured to match.
> - Matching will only interoperate if both sides support the 
> feature and have matching turned on. (ie, we may not get good interop
here)
> 
> Proposed Text:
> The Identification Payload, denoted ID in this memo, allows peers to
> assert an identify to one another. The receiver will 
> interpret the identity
> payload as a unique identity string for policy lookup in its SPD.
> Implementations MUST NOT mandate a check that the ID match 
> anything in the
> certificate presented, and therefore MUST be able to accept 
> the case where
> the identity presented does NOT match the certificate contents. 
> 
> To allow for more stringent local security policy, 
> implementations MAY offer
> a configuration option to check that the idenity presented in 
> the identity
> payload matches the equivalent identity type in the presented 
> certificate.
> In such a case, interoperability will only be achieved by two 
> consenting
> parties who both have such configuration options available on their
> respective gateways and who both enable the option. 

 Gregory.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 30 Apr 2003 09:42:14 -0700

Hi Gregory,

Thanks for summarizing and trying to bring this to a close. I still have
some trepidation about the proposed text. I think we need to question
our underlying assumptions and I think problems arise from considering
all auth scenarios to be equivalent, and attempting to squeeze them into
a framework together in which the fit isn't quite right - square and
round pegs, round holes.

What is the purpose of the ID payload, and how is it used? There are two
overarching cases: preshared keys, and public/private keys. In the case
of preshared keys, the ID payload serves as a signal from the initiator
to the responder as to which psk the initiator (and therefore the
responder) will use. Note that this is not the same as a policy
selector, but functions similarly: wrong id payload implies selection of
wrong psk, resulting in authentication failure. For non-interactive
interoperability (e.g. no special config on the initiator side), the IP
address is used. Other cases require explicit configuration of the
initiator (key id, fqdn) in order to work.

In the case of public keys, the ID payload *may* indicate which public
key to use (assuming these keys are used without certs), but this has
never been clearly specified. When certs are used, the ID payload *may*
indicate which cert to choose, but only if the cert is not included in
the exchange - otherwise, the ID payload is superfluous. And the
currently defined ID payloads _don't uniquely define a cert_. A given DN
or GN may appear in certs from multiple issuers. The only way to
uniquely identify a cert is with explicit issuer identifying information
(issuer name, verification key, serial number, etc), but these are not
currently supported. So the ID payload is only a reliable policy
selector with interactive pre-configuration of the initiator, in which
it is explicitly told which ID to send, when the cert accompanies the ID
in the exchange, and when the intiator is trusted to do the right thing.

And what is the point of this? It seems to make the policy lookup
slightly simpler, since you can get the ID payload from the packet
instead of parsing the cert. But this is only on the front end, because
you still have to parse the cert, and you have the added step of
verifying that the ID matches something in the cert (if you care about
security). What threat does the first approach mitigate better than the
second? If I'm attacking, I can put an acceptable ID payload in the
packet, and then you'll sill have to parse the cert to find out I lied -
this is *more* work whether under attack or not.

I think the bottom line is that some vendors have come up with
proprietary ways to use the ID payload in their responder-side
processing. These methods make assumptions about the implementation at
the other end, and so long as these assumptions are correct (i.e. it is
the vendors own implementation at the other end), this works fine - but
it is not interoperable, and I think it actually incurs some additional
DoS risk. I don't see the point in standardizing on non-interoperable
functionality. It seems like a contradiction in terms.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Apr 2003 18:17:01 -0400

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

Scott, to summarize, your summary:

*If* using public keys carried in CERTs
AND  there is a CERT payload
AND  the CERT contents are meaningful to the receiver
THEN the ID payload is superfluous for the sender.

(I avoid initiator/responder here on purpose)

***************** please confirm *************

The problem that I have with this is that sender is making
an assumption about the responder. 

Right now, I can make a system that does not support certificates
in the IKE *at all* interoperate with one that does by taking
the certificate (which I might get in a CERT payload written
to disk or logged), extracting the public key and putting it
into my configuration file/into DNS/etc.

How do I know this? I do it all the time. That's how one gets
RACOON and FreeSWAN to interoperate using RSA public keys. Every night
my NetBSD backup server talks to a dozen FreeSWAN boxes to back them up.
Did it take configuration? Yes. Of course. I don't know of any VPNs
that do not take some configuration.

So, my problem with dropping the ID payload is that you are depending upon
the sender to know details about the receiver. If you know all of those
details, why not just copy the public keys? (Oh, yeah. You told me.
Because some products are just broken)

So, the situation where all of your conditions hold true is the 
road warrior case, where access is granted not by configuration, but
by permitting any client to connect that has a certificate signed by
some CA.

I.e. the situation where you can omit the ID payload is one the
one where you have intentionally mixed authentication with authorization. 

So, I'd vote not to do this.

I can't say that I'd be happy about the current document if I was payed
to care a lot of PKIX. In fact, I'd be fuming.

]       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: "Scott G. Kelly" <[email-masked]>
Date: Wed, 30 Apr 2003 18:07:07 -0700

Hi Michael,

> ***************** please confirm *************

If the cert contents are not meaningful to the receiver, the discussion
is moot, is it not?

That aside, I think it's a bit more complex than you say, but you might
be able to summarize it like this:

 *If* using public keys carried in CERTs
 AND there is a CERT payload
 then only the receiver knows what identifer contained in the
 cert is acceptable as a policy selector for the receiver

 *If* using public keys carried in CERTs
 AND there is a CERT payload
 AND there is an ID payload
 AND the receiver uses this ID payload to select a policy
 THEN  the receiver risks choosing the wrong policy, UNLESS it verifies
 the ID payload against the cert

And I might add

 *If* using public keys carried in CERTs
 AND there is NOT a CERT payload
 then any currently defined ID chosen by the sender does not
  unambiguously define exactly one certificate (or public key)

> Because some products are just broken)

See filtering example below...

> by permitting any client to connect that has a certificate signed by

No, this is not the only case. I may construct a policy filter which
looks like this:

ISSUER: me
DN FILTER: c=*,o=ietf,ou=ipsec-wg,cn=Michael*,*
GN FILTER: *

In this case, if you know that I require the DN, you can send it, or I
can simply extract it from the cert. But what if I want to construct
filters using things other than DN and GN? If I use issuerName, there is
no ID payload you can send me that makes sense. If I require multiple
criteria to be satisfied (e.g. issuer + dn fields + gn fields), there is
no way to express this using currently defined IDs - and why should you,
as the sender, have to know what to extract from the cert?

> one where you have intentionally mixed authentication with authorization.

Can't really argue with you there, but I don't see how this can be
avoided.

> to care a lot of PKIX. In fact, I'd be fuming.

As I said in my first post on this topic, I think the next best thing is
to require that the ID payload, when present, match something in the
cert. The text on the table renders this optional. I think that's a
mistake.

Scott