1 May 2003 03:07
Re: Confirm decision on identity handling.
Scott G. Kelly <scott <at> airespace.com>
2003-05-01 01:07:07 GMT
2003-05-01 01:07:07 GMT
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