Subject: Re: Confirm decision on identity handling.

From: David Wierbowski <[email-masked]>
Date: Thu, 1 May 2003 10:37:30 -0400

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

I agree.  This seems like an obvious flaw.  If the ID is not required to
match the identity in the cert there does not seem to be a defined
verification mechanism.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 01 May 2003 09:10:05 -0700

Hi Andrew,

Can you give a real-world example of the process you describe below?
That is, what sort of ID payload would be sent, what might it contain,
and how would the policies look against which this compared?

Thanks,

Scott

Andrew Krywaniuk wrote:
> 
> >And what is the point of this? It seems to make the policy lookup
> >slightly simpler, since you can get the ID payload from the packet
> >instead of parsing the cert. But this is only on the front end, because
> >you still have to parse the cert, and you have the added step of
> >verifying that the ID matches something in the cert (if you care about
> >security).
> 
> Some people have been referring to the id as a "key for policy lookup". The
> idea is that if you have a decorrelated database (or an ordered database
> where more specific rules serve only to grant privileges and not to take
> them away), a unique id can allow a very fast policy lookup.
> 
> However, once this lookup is complete, you can throw the id away. It is not
> necessary to check the id against a field in the certificate. You only have
> to check the certificate against the policy (and the signature against the
> public key and the validity of the cert chain).
> 
> I wish people would stop saying thing like "you can check the id against the
> certificate if you require a more stringent policy check."
> 
> Andrew
> --------------------------------------
> The odd thing about fairness is when
> we strive so hard to be equitable
> that we forget to be correct.
> 
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail

---

From: [email-masked]
Date: Thu, 1 May 2003 10:32:04 -0700

Hi Scott,

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

< snip>

> 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