Re: Confirm decision on identity handling.

[Ravi <ravivsn@roc.co.in>]

Hi,

I am trying to understand the issues. Some time back, there was
rough consensus that 'Matching ID payload data with certificate
Identification' is local matter as a receiver. As a sender,
implementation need to make sure to send ID payload data same as
Certificate ID as the receiver may be checking for equality of both IDs.
If the sender knows that receiver does not check for the equality, then
the sender can send different IDs between ID payload from certificate
ID.

Some implementations already do this for supporting remote access.
In remote access, road warriors are initiators and Corporate SG is
typically configured in 'Responder' only mode. One IKE policy is
created with
           - Wild card domain name as peer ID.
             For example, *.abc.com can be give as Peer ID.
             Then all remote access users whose IDs are ending with 

             abc.com will be authenticating using this IKE policy.

          -  Accept any whose signing CA is 'DN of CA'.
             This is typically useful when corporate office has their own
             CA and anybody got certificate from this CA is authenticated
             using this policy.

In above examples, really there is no check between ID payload and
Certificate in verbatim. It is local decision.

Can't we leave the decision of IDs check as local decision? What type of
additional simplification are we trying to make it for easy deployment?
Thanks and regards
Ravi





Gregory Lebovitz wrote:
> 
>>At 8:29 AM -0700 5/15/03, Eric Rescorla wrote:
>>
>>> > You could have a security policy that ignored the 
>>
>>identity in the cert
>>
>>>> ("allow an SA with these restrictions to anyone who has a 
>>>
>>cert from
>>
>>>> XYZRoot"), or one that was identity-based ("let 
>>>
>>chris@example.com make
>>
>>>> an SA").
>>>
>>>But you would presumably want to have some restrictions
>>>on the IP addresses they were allowed to front for, right?
>>
>>Sure.
> 
> 
> you could, but there are plenty of cases (the roaming user) where there is
> no need. Those of us advocating the disassociation are not saying 100%
> disassociate. We are saying make the base-line MUST disassociation, but
> allow the user's the ability in configuration to associate and look for ID
> in a certain place in the cert IF THEY WANT. That way, the 10% of the cert
> users that want to associate will get what they need, and the rest of the
> 90% will have something that works easily. 
> 
> This is the basic convenience vs. security continuum. Our job as protocol
> designers is to give the people something they can use. 20% want it super
> secure at the cost of convenience. 80% want it secure, but convenient, and
> are willing to make the trade-off from the super-secure. The text I proposed
> tried to reach this goal.
> 


-- 


The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>