Re: Confirm decision on identity handling.

[Ravi <[e-mail]>]

Hi Ted,

This proposal looks OK to me too.
As mentioned, it requires configuration of both
payload ID information and Certicate ID
information to be present in the configuration.

-Ravi 



Brian Korver wrote:

>Ted,
>
>The proposed text to add sounds good to me.
>
>- brian
>[e-mail] 
>
>
>On 4/9/03 2:18 PM, "Theodore Ts'o" <[e-mail]> wrote:
>  
>
>>At the San Jose IETF, the IPSEC working group came to a rough
>>consensus (confirmed by a straw poll) to solve an interoperability
>>problem as follows:  (quoting from the minutes)
>>
>>    
>>
>>>Comment: Deal with this in 2401bis. Short term solution is to say that what
>>>goes in ID v CERT  payload is a local matter for now. It need not match.
>>>
>>>Comment: SO we will put in sentence that ID payload is for policy lookup and
>>>does not need to  match anything in CERT payload. Both fields may be used
>>>for access control decisions, but need not be correlated. 2-1 in favor.
>>>      
>>>
>>The consensus was relatively rough, and there was a desire expressed
>>by some to continue the discussion on the list.
>>
>>In order to move the discussion forward, we propose the following
>>addition to section 3.5 of the ikev2-06 as meeting the spirit of the
>>consensus which was developed in San Francisco.  Append to the first
>>paragraph, which begins:
>>
>> The Identification Payload, denoted ID in this memo, allows peers to
>> assert an identify to one another. The ID Payload names the identity
>> to be authenticated with the AUTH payload.
>>
>>.. the following text:
>>
>> ... This identity is used for policy lookup, but does not
>> necessarily have to match anything in the CERT payload; both fields
>> may be used by an implementation to perform access control
>> decisions.
>>
>>Discussion:
>>
>>The implication of this change, as was discussed in San Francisco, is
>>that it gives freedom to implementations to make more sophisticated
>>access control policies, where the responder might use the identity in
>>the ID payload to look up an access control list, and match the
>>subject name in the certificate against that ACL, for example.  This
>>can be advantageous in that do not need to dictate the form of the
>>subject names in the certificate, which could promote the reuse of
>>certificates across multiple applications.  The downside is that the
>>initiator must now allow the configuration of two pieces of
>>information; there is an additional configuration "knob" which must be
>>set correct in order for two peers to successfully ocmmunicate.
>>
>>There are other alternatives, which have been discussed in the past.
>>Two self-consistent and workable alternatives are presented here:
>>
>>2) Require that that IPSEC strictly define the types of X.509
>>certificate subject names that would be accepted, and precisely define
>>the matching rules of the identity payload.  This in effect would
>>predefine the access control policies in the system.  One mechanism
>>for doing so can be found in section 3.2 of
>>draft-ietf-ipsec-pki-profile-02.txt.
>>
>>3) Specify that the ID payload must not be sent and/or is ignored when
>>using certificates to authenticate.  In this case, the Certificate
>>subject name is used to lookup the policy information associated with
>>the SA instead of the contents identity payload.  (This is essentially
>>very similar to a proposla contained in Paul Hoffman's
>>revised-identity I-D.)
>>
>>These alternatives have tradeoffs: to differing degress, they
>>essentially limit flexibility in the choice of certificate names and
>>the name (identity) used to look up policy information.  In the first
>>case, the choice of the name found in certificate is limited to
>>something which passes the matching rule defined in the pki-profile
>>I-D when the subject name or the subject alt name is matched against
>>the contents of the identity payload.  In the second case, the name
>>used to look up the SA policy is constrained to be exactly the subject
>>name in the certificate, or perhaps the certificate itself.
>>
>>The latter alternative in particular may impact some implementations
>>significantly, by changing the key used to look up and manage SA
>>policy information.
>>
>>Decision path:
>>
>>At the San Francisco meeting, there was clear (but rough) consensus to
>>explicitly specify that the contents of the ID payload do not have to
>>match the contents of the CERT payload, and which will require that
>>initiators have sufficient configuration controls to set both the ID and
>>Cert payloads.  Proposed text which implements this rough conensus has
>>been included in this messange.
>>
>>Since the straw poll indicated that of the people in the room at San
>>Francisco, that people were 2-1 in favor of this choice, and this
>>chice should be considered the privileged or "default" choice.
>>However, especially given the roughness of the consensus there, this
>>decision must be confirmed on the mailing list.  People who believe
>>that one of the above alternatives, or some other alternative, should
>>be adopted instead, are encouraged to speak up.
>>
>>    
>>
>
>  
>

-- 


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: [phone] / 1175 / 1184

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