Re: Confirm decision on identity handling.

["Scott G. Kelly" <scott@airespace.com>]

Hi Michael,

Michael Richardson wrote:
> 
> -----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 *************

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)


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

See filtering example below...

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


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?

> I.e. the situation where you can omit the ID payload is one the
> 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.

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

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