Subject: RE: Confirm decision on identity handling.

From: [email-masked]
Date: Wed, 23 Apr 2003 11:47:08 -0700

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:[email-masked]]
> Sent: Tuesday, April 22, 2003 10:53 AM
> To: [email-masked]
> 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
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 23 Apr 2003 12:08:06 -0700

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 23 Apr 2003 15:34:33 -0700

Paul Hoffman / VPNC wrote:
> 
> At 11:47 AM -0700 4/23/03, [email-masked] wrote:
> >lookup.
> There is nothing in the IKEv2 spec that says this, and there is
> nothing in RFC 2409 that says this. Hence, the desire for more
> specificity in IKEv2.
> 

And since the decision as to which ID will be used for this purpose is
left to the receiver, it is not clear that the ID payload could ever be
reliably used this way...

Scott

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 23 Apr 2003 15:30:07 -0700

--Paul Hoffman, Director
--VPN Consortium