Re: Confirm decision on identity handling.

["Scott G. Kelly" <scott@airespace.com>]

Hi Jim,

Comments inline...

jknowles@SonicWALL.com wrote:
> 
> 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.

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

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

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.

> 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 :-). 

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


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

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