Re: Confirm decision on identity handling.

[Brian Korver <[e-mail]>]

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