RE: Confirm decision on identity handling.

[jknowles@SonicWALL.com]

Hi Scott, Gregory, Paul,

I also appreciate the effort.  Comments inline...

> -----Original Message-----
> From: Scott G. Kelly [mailto:scott@airespace.com]
> Sent: Wednesday, April 30, 2003 9:42 AM
> To: Gregory Lebovitz
> Cc: Jim Knowles; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Confirm decision on identity handling.
> 
> 
> Hi Gregory,
> 
> Thanks for summarizing and trying to bring this to a close.

< snip>

> I think the bottom line is that some vendors have come up with
> proprietary ways to use the ID payload in their responder-side
> processing. 

Using the ID to look up policy (which is what I've asked for)
is not proprietary.  At least, that's my interpretation of
section 4.6.2 of RFC 2407.  What's proprietary is the mapping of
ID-to-cert and that's because we never clearly defined the mapping.
I agree that this causes interoperability pain.

< snip >

> > > Implementations MUST NOT mandate a check that the ID match
> > > anything in the certificate presented

I interpret "MUST NOT mandate" to mean that we can never require
such a check.

> > To allow for more stringent local security policy,
> > implementations MAY offer
> > a configuration option to check that the idenity presented in
> > the identity
> > payload matches the equivalent identity type in the presented
> > certificate.

Seems to contradict "MUST NOT mandate".

From Gregory's "Goals of text":

> > - implementations MUST be able to handle IDs that do not
> > match cert contents
> > - implementations MAY be configured to match.
> > - Matching will only interoperate if both sides support the
> > feature and have matching turned on. (ie, we may not get good interop

This seems like more consistent text.  Maybe just replacing
"Implementations MUST NOT mandate..." with the "implementations
MUST be able to handle..." line would be better.

But, it might be better to just state flatly that there is
no IKEv2-defined relationship between the ID payload and any
CERT payload.

This doesn't answer Scott's request to ban the ID payload when a
cert payload is present.  Could we add a new ID type of
"ID_CERT" to support the opportunistic scenario?

"The ID_CERT type specifies that an identity present in the
certificate sent in the CERT payload SHOULD be used in place
of an explicit ID payload."

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.


Regards,

Jim