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

Re: Confirm decision on identity handling.



At 5:18 PM -0400 4/9/03, 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.

The proposed addition is close, but doesn't match what many people 
were asking for in the San Francisco meeting, namely to let the use 
of the ID payload be a local option for the receiver. If you want to 
follow what those people asked for, the proposed addition must say 
"This identity may be used for ...".

The sentence to which the new material is appended ("The ID Payload 
names the identity to be authenticated with the AUTH payload.") is 
now not correct. You can't authenticate something with a certificate 
that doesn't necessarily contain it.

We are better off with just the first sentence and a revision of the 
one proposed here by Ted:

    The Identification Payload, denoted ID in this memo, allows peers to
    assert an identify to one another. This identity may be 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.


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

No, there isn't. Sensible implementations will ignore the ID payload 
altogether and simply look for identities out of the certificate. 
That means there is one *less* knob to manage for the sender. The 
sending application can simply pick any identifier from the cert and 
send it in the ID payload.

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

To say that the document "precisely defines the matching rules" is 
quite a stretch. It ignores commonly-used Subject OIDs, and gives 
conflicting SHOULD NOTs.

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

Not true. The draft explicitly did not say what to do with the 
identities in the certificate. The receiving system might take the 
Subject, or one or more of the SubjectAltNames, or might ignore the 
identities altogether and simply say "if the cert is valid and from a 
trusted root, I'll use it as the identifier, or other possible 
options.

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

That is not true about the revised identity proposal. The name in the 
SA policy could be a certificate ID, a public key ID, a name from the 
SubjectAltName, or a combination.


--Paul Hoffman, Director
--VPN Consortium