[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