E193MxO-0000c8-00@think.thunk.org">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 implementati!
ons 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 p!
ayload. 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, t!
he 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 r!
oughness 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.