RE: Confirm decision on identity handling.

[jknowles@SonicWALL.com]

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