Subject: Re: Confirm decision on identity handling.

From: Michael Richardson <[email-masked]>
Date: Sat, 03 May 2003 13:38:55 -0400

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

>>>>> "Scott" == Scott G Kelly <[email-masked]> 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[
] [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: Mon, 05 May 2003 10:13:17 -0700

Hi Michael,

> and the sender does not send an ID payload, then the negotiation fails.

I think we're talking past one another here. I meant that if the
contents aren't meaningful to the receiver, the receiver most likely
can't parse the cert or use the public key contained therein. I think
you must mean something different (like maybe the ID doesn't matter,
since the receiver only requires that the sender present a cert from a
given issuer).

<trimmed...> 
> in this situation leads to lack of interoperability.
<trimmed...> 
>   No identifier is provided, derive one from the provided certificate.

This is essentially what Jim Knowles proposed (I think), and I think
this is a reasonable compromise. However, I think it will only improve
interoperability if all implementations are required to support it.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 May 2003 15:32:05 -0400

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

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    Scott> If the cert contents are not meaningful to the receiver, the
    Scott> discussion is moot, is it not?

    >> and the sender does not send an ID payload, then the negotiation fails.

    Scott> I think we're talking past one another here. I meant that if the
    Scott> contents aren't meaningful to the receiver, the receiver most
    Scott> likely can't parse the cert or use the public key contained
    Scott> therein. I think 

  Imagine a situation where the receiver has been made aware of the sender's
public key, and it has been attached to an ID that the sender is expected to
use. 
  (remember, this may even occur by trial-and-error, plus reading of logs by
the receiver!) 

  The receiver can't parse the CERT in real time, but they can attach the
public key. So, if you drop the ID, then the protocols gets weird, and the
receiver can't cope.

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

    Scott> This is essentially what Jim Knowles proposed (I think), and I think
    Scott> this is a reasonable compromise. However, I think it will only
    Scott> improve interoperability if all implementations are required to
    Scott> support it. 

  Unless we make CERTs a MUST, you won't get that.
  But, I keep suggesting that VPNs should have a difference set of MUSTs.

  Let's not mix up different applicability situations.