Re: Confirm decision on identity handling.

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

Hi Jim,

I'm partially addressing your comments, and partially addressing Michael
Richardson's comments, which I see on the vpnc archive, but have yet to
receive here. I think Michael makes a good point: if the cert is not
included in the packet, then the ID payload is useful. It allows a way
to indicate which cert is intended absent the cert itself. But note the
subtle difference here: we are not trying to use the id payload as a
policy selector so much as we are using it as a credential identifer in
this case.

In general, I think we're mixing the notion of a credential (or
credential identifier) with a policy selector. When the cert is passed
in the packet, the cert is the credential, but it is also used as a
policy selector. I may use one or more fields in the cert as a policy
selector, but you have no way of knowing a priori (unless we agree ahead
of time) which ones that will include. Since the criteria by which I
evaluate your certificate is wholly left to me (it is not explicitly
specified), then any additional information you pass me is liable to be
superfluous, unless we are running the same implementation at both ends,
and/or you *know* exactly what I expect.

Think about it: since you can send me either the DN or the GN (or who
knows what else?), I need to know what to do if what you send doesn't
match my expectations (policy). For example, suppose you send the DN. If
my policy is to accept certs from issuer x, then your ID payload is
meaningless. Or, if my policy is to require your GN to contain
jknowles@foo.com, again your ID payload is meaningless. And if my policy
is to accept certs from issuer x containing {xyz} in the DN, even if
this is in the ID payload you pass, I still must verify that it matches
the cert, and validate the cert. 

Back to the case where you send me the wrong ID payload, it has been
suggested that I can just ignore what you send, meaning I will parse the
cert anyway, but what if I don't? Instead I can fail the negotiation, in
which case a customer will likely call and say "what does ID-MISMATCH
mean?".

The bottom line is 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 - but it's not clear *when* I should ignore it.
Should I ignore it always, or just when it fails to match my policy? It
doesn't seem worthwhile to introduce this ambiguity for the very small
amount of convenience it might provide in a single vendor
implementation.

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? Nailing
down little twists like this go a long way toward fostering
interoperability...

Scott

jknowles@SonicWALL.com wrote:
> 
> Hi Scott,
> 
> OK, I see your point.  However, the recipient policy
> can still say "ignore ID payloads, get me an email addr
> from the cert subjectAltName" and get the same
> behaviour you'd like.   Choosing between two (or more)
> recipient policies that expect different cert ID fields
> will be interesting when a cert matches more than one.
> An ID payload could differentiate in this case and
> avoids the cert parsing when ID's don't match, but
> you're right that the initiator needs to know which
> ID to send.  I'd like to have that option in cases
> where the ID payload type can be selected by the
> sender.
> 
> Regards,
> 
> Jim
> 
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:scott@airespace.com]
> > Sent: Wednesday, April 23, 2003 12:08 PM
> > To: Jim Knowles
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: Confirm decision on identity handling.
> >
> >
> > Hi Jim,
> >
> > I think the problem arises precisely when we try to
> > interoperate. If one
> > vendor owns both sides of the connection, then one might
> > assume that the
> > initiator knows what to send in the ID payload, but this is not
> > necessarily the case when interoperating. Since the choice of which ID
> > value to use as a policy selector is a matter for the recipient to
> > decide (it is, after all, the recipient's policy which must be
> > satisfied), the sender may or may not choose the proper value
> > to insert
> > in the ID payload, even though the cert is acceptable to the
> > recipient.
> >
> > However, the recipient (hopefully) knows what to look at in the cert,
> > and it can extract this without verifying the cert and still gain the
> > same level of assurance as it would if it grabbed it from an
> > ID payload,
> > did the policy lookup, and then verified that the ID payload
> > matched the
> > cert field and then verified the cert itself.
> >
> > I think the right answer is a well-defined profile which makes all of
> > this explicit. However, this working group seems to anxious to simply
> > produce a document and disband without addressing this or
> > other interop
> > issues. It is not clear to me that anyone has much incentive to
> > implement ike2 if it doesn't address the fundamental shortcomings of
> > ike1, though, and the lack of clear guidelines for pki-based policy is
> > (in my view) one of the significant shortcomings of ike1.
> >
> > I guess if the ID payload is important to you, then
> > (somone's) suggested
> > language which makes it optional to process it might be more to your
> > liking. I'm not sure that I feel strongly that we shouldn't
> > just go that
> > way, except that this sort of slop in the spec is what causes interop
> > problems.
> >
> > Scott
> >
> > jknowles@SonicWALL.com wrote:
> > >
> > > Hi Scott,
> > >
> > > I don't like banning ID payloads when using certs.
> > > The ID check against policy is cheap compared to
> > > cert sig processing so I'd like to have the option
> > > of checking for policy match prior to cert processing.
> > > I'm also not sure how I look up the policy without
> > > an ID payload.
> > >
> > > I think the purpose of the ID payload when using
> > > certs is (was) to specify which of several possible IDs
> > > contained in the cert should be used for policy
> > > lookup.  Unfortunately, the mapping was never
> > > clearly defined.  De-coupling the ID from the cert
> > > allows the lookup as well and avoids the ID-to-cert
> > > mapping mess.  I guess all that we lose is the direct
> > > authentication of the ID (if in the cert) by the
> > > issuing authority.  Since the ID is ultimately signed
> > > anyway, we don't lose too much.  It's true that
> > > someone holding the private key could send a rogue
> > > identity that is not directly confirmed by the CA/RA.
> > > Depending on your views of PKI, that could be good
> > > or bad :-).  As local policy, we can mandate the
> > > ID-to-cert mapping as we wish.  We just need to
> > > provide the knobs and levers to specify interoperable
> > > mappings.
> > >
> > > Regards,
> > >
> > > Jim
> > >
> > > > -----Original Message-----
> > > > From: Scott G. Kelly [mailto:scott@airespace.com]
> > > > Sent: Tuesday, April 22, 2003 10:53 AM
> > > > To: ipsec@lists.tislabs.com
> > > > Subject: Re: Confirm decision on identity handling.
> > > >
> > > >
> > > >
> > > > Just wanted to comment on this: I agree with Paul. Since we seem
> > > > unable to produce a coherent specification with respect
> > to PKI-related
> > > > policies, when using certs the ID payload should not be
> > present. If we
> > > > cannot agree on this, then the next best position is that the
> > > > ID payload
> > > > must exactly match an identity contained in the cert.
> > Anything else
> > > > leads to utter confusion and confounds interoperability.
> > > >
> > > > I can't believe that after so many years, we are still
> > > > paralyzed w.r.t.
> > > > this topic. What a farce. For the last several weeks,
> > I've been trying
> > > > to get several ostensibly mature implementations to
> > interoperate using
> > > > certs, and I've not had much success. How sad.
> > > >
> > > > Scott
> > > >
> >