RE: Confirm decision on identity handling.

[jknowles@SonicWALL.com]

Hi Scott,

> -----Original Message-----

< snip>

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

Sure, but you've authenticated to me via the AUTH payload,
so the ID is verified.  It is not directly verified by the
issuer of the cert, true.  But, people seem to want be able
to allow this case (ID explicitly de-coupled from the cert).

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

Through configuration the sender can know what to put in the ID
payload.  Or, send the proposed "ID_CERT" payload.

> And supposing 
> the responder
> tells the intiator in advance, what is the responder to do if the ID
> payload is the "wrong" one?

If the configuration allows an authenticated ID to select the
wrong policy, then fix the configuration.  That could include
requiring the match as a local policy decision so that
misconfiguration results in SA failure.

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

In some cases, the ID payload can be useful.  Here's one
case: early rejection of wrong ID configuration before
cert processing.  It the ID is wrong, I don't need to
authenticate it to know that.  I can simply reject it.
If the ID is right, I do need to authenticate so, in that
case, you're correct, nothing is saved.

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

If you say "configuration issues", I agree.  And, yes,
misconfiguration can lead to bad security.  I understand
your position that we should remove points of possible
misconfiguration as a security concern.

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

We disagree about the computational benefit, at least in some
cases.  The complication is minor and worth the benefit, IMHO.

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

Not required, not prevented.  And I still get the ID payload.
If others agree with you, that the security risk arising from
having a misconfigured ID payload is too great for us to allow
this in the spec (ID payload when there is a CERT payload), fine.
I can live with that.

> 
> Scott
> 

Regards,

Jim