[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confirm decision on identity handling.



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 >briank@briank.com > > >On 4/9/03 2:18 PM, "Theodore Ts'o" 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: +91-40-2335 1214 / 1175 / 1184 ROC home page