Re: Confirm decision on identity handling.

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

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