Re: Confirm decision on identity handling.

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

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


>>>>> "Scott" == Scott G Kelly <scott@airespace.com> writes:
    Scott> If the cert contents are not meaningful to the receiver, the discussion
    Scott> is moot, is it not?

  Not entirely. If the cert contents is not meaningful to the receiver,
and the sender does not send an ID payload, then the negotiation fails.

  It is this risk that I am trying avoid.

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


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

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

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

  I agree that the ID payload is a problem.
  You'll get no argument from me.
  As I've said, I'd prefer to fix the ID payload.

  I am just concerned about the proposed solution of dropping the ID payload
in this situation leads to lack of interoperability.

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

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

  The thing that I'm trying to emphasis is that it happens with the awareness
of both parties. As such, the sender can easily be configured to either put
something meaningful in the ID payload, or to put recognizeable nonsense in.

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

  I agree.

  As an alternative, how about:

      ID_PKIX_CERT                      12

  No identifier is provided, derive one from the provided certificate.

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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPrFprIqHRg3pndX9AQFrPwQA22ML0cYBOd3WhfYDr2iWoqcBjcpjcMXD
Uul6AnYdCWzQxsG43EO0Cl+kwn1brT2QnBgbBAfEBiV57NTLhUBkztknzj7WkLAi
kzLxwi0RcBNapPmU7poBqe1GZWb1aMkFiU4qZ3O/An7gn2mklVxyu9VU9Z3V1bky
sKphN4BHuhE=
=Zg7J
-----END PGP SIGNATURE-----