RE: Confirm decision on identity handling.

[jknowles@SonicWALL.com]

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:scott@airespace.com]
> Sent: Wednesday, April 30, 2003 1:48 PM
> To: Jim Knowles
> Cc: Gregory@netscreen.com; paul.hoffman@vpnc.org;
> ipsec@lists.tislabs.com
> Subject: Re: Confirm decision on identity handling.
> 
> 
> Hi Jim,
> 
> I trimmed most of this in order to focus on one point:
> 
> jknowles@SonicWALL.com 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
>