Subject: RE: Confirm decision on identity handling.

From: [email-masked]
Date: Wed, 30 Apr 2003 15:53:26 -0700

Hi Scott,

The verification/authentication is the cert.  I
haven't proposed removing the authentication, so
I'm not sure why you say there's no defined
verification mechanism.  You had earlier proposed
omitting the ID payload and just using the cert as
policy selector.  Which identity in the cert would
you use?  That's local policy as well.  You may
authenticate the cert and still reject the identity
based on your policy.  You've eliminated the
requirement for configuring which ID payload
to send.  That's fine - less headaches although
you still need to configure which cert to send.
At least there's no ID payload/cert impedence
mismatch.  But, I don't see any security issue
with allowing an ID payload.

Our client puts the certificate subjectName or
subjectAltName into the ID payload depending on
the ID type.  The ID type has to be configured.
As you know, certain ID types could be in either
subjectName or subjectAltName or both.  We had
to make implementation decisions about which of
these to send as ID.  We took as much guidance as
possible from the RFCs.  Some things are rather
vague :-).  Yeah, this can make inter-vendor
configuration more fun than it needs to be.
So, I understand your desire to omit the ID
payload.  Rather than make it optional or ban
it, we can explicitly say "ignore me, use the
cert" via a new ID type.  Since I still see
a use for the ID payload, I'd prefer this.

Regards,

Jim

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 1:48 PM
> To: Jim Knowles
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Confirm decision on identity handling.
> 
> 
> Hi Jim,
> 
> I trimmed most of this in order to focus on one point:
> 
> [email-masked] wrote:
> > 
> > Then we could say there is no other IKEv2-defined relationship
> > between ID and CERT and that implementations MAY define such
> > relationships locally at their own extreme interoperable peril.
> 
> I must be missing something really obvious here. If we don't assume
> anything about the initiator (e.g. that it can be trusted to put an
> "appropriate" policy selector in the ID payload), then I think there
> must be security issues with blindly using whatever is passed as a
> policy selector, with no defined verification mechanism. As an aside,
> exactly what does your client put into the ID payload?
> 
> It still sounds to me like we're trying to standardize proprietary
> behavior here. What am I missing?
> 
> Scott
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 30 Apr 2003 17:30:59 -0700

Hi Jim,

Comments inline...

[email-masked] wrote:
> verification mechanism.

I'm saying this because the proposed language says the ID payload does
not have to match anything in the cert. If we allow this and you choose
your policy based on the ID payload, I may be able to misdirect you to
the "wrong" policy by simply enclosing the "right" ID payload.

>  You had earlier proposed
> you use?  That's local policy as well.

This is precisely my point: since it's the responder's decision, and
since there are multiple choices and combinations, how can the initiator
reliably know what to put in the ID payload? And supposing the responder
tells the intiator in advance, what is the responder to do if the ID
payload is the "wrong" one? It only works if the responder verifies the
ID payload against the credential, and in this case, there is nothing
saved by using the separate payload, rather than simply extracting it
from the cert.

>  You may

The security issues arise if you decouple the ID payload from the cert,
i.e. when the ID payload is no longer a reliable policy selector.

> vague :-). 

...which is why I *really* want us to get it right this time.

> Yeah, this can make inter-vendor

It sounds like your client is putting something that can be verified
against the cert into the ID payload. So long as you verify this against
the cert, this is probably okay, though as I said in an earlier post,
there really is no computational benefit to this, and I think it
actually may complicate the processing. The main point, though, is that
your implementation appears to verify the ID payload against the cert -
the proposed language I'm disgreeing with says this is not required.

Scott