some thoughts on identity handling

[Stephen Kent <kent@bbn.com>]

Folks,

I've been listening to the discussion about whether there ought to be 
a requirement to match an asserted ID payload to any field in a cert 
that was passed in IKE, or maybe pre-configured into the SPD, etc.

I certainly can't dispute the bad experiences that Paul and Gregory 
have reported. But, I think we ought to back up from the mechanistic 
discussion (the "how") and try to figure out what problem we are 
solving (the "why") to see if we are heading down the right path.

One can imagine several models for what we want to accomplish by 
using certs for initial authentication in IPsec. I believe that we 
perform this authentication in order to make an access control 
decision. This assumes that we are generally NOT prepared to 
communicate with arbitrary peers. At a minimum we need to be able to 
determine their identity, and then use that to decide if we wish to 
communicate and if so, with what constraints. (This may be in 
conflict with the opportunistic encryption model of operation. If so, 
that may be a source of confusion, i.e., we don't agree on the 
problem we are trying to solve.  However, I don't know if this is an 
issue yet and I'll defer to Mike to say what he thinks on this topic, 
relative to my notes below.)

Note that there is a difference between not wanting to make an access 
control decision based on an authenticated identity, and wanting to 
make such a decision but not knowing the identity of specific peers 
in advance. The latter goal is easily accommodated using PKI 
technology, for example. The former is not well aligned with the 
overall thrust of IPsec, since IPsec is an IP layer security protocol 
in which access control is a fundamental service, not just an IP 
layer confidentiality or integrity protocol.

So, we need to explore the ways in which an ID established by a cert, 
with or without an ID payload, might be used in access control 
decisions. In IPsec, these decisions are centralized in the SPDs. 
But, what is the type, granularity, and scope of the cert-based 
authentication, i.e., what type and range of identities does the cert 
serve to verify, and to what SPD entries does it apply?

There has been discussion about the utility of different types of 
IDs, e.g., IP addresses, FQDNs, etc.  I don't want to add to that 
debate, since I believe that there are contexts on which each of 
these ID types is useful. So let's assume that we are dealing with 
any of these ID types in the following discussion, and focus instead 
on scope.

One might adopt a various models. In the examples below, when I say 
"valid cert" I mean an X.509 cert that can be validated relative to 
one or more pre-configured trust anchors in the responder. Recall 
that a trust anchor is a (CA) public key  and associated data that is 
used for cert path validation. (It need not be a self-signed cert, 
although that may be a convenient format.) When I say "assert an ID" 
I mean send an ID payload in IKE.

	1. when a peer presents a valid cert, one could allow the 
peer assert any ID and then compare it against any SPD entry. This is 
probably a bad idea in general, as it allows any configured TA to 
assert any identity without constraints. However, if you configure 
only one TA, and that TA is managed by the folks responsible for 
securing your environment, then even this simple case may be OK. It 
has moved all responsibility to that TA (CA) to ensure that the 
entities to which/whom certs are issued will only do "good" things. 
it really means trusting all these entities to not abuse the certs 
they have. Nonetheless, this does not strike me as a good approach 
for more general authorization requirements.

	2. when a peer presents a valid cert, one could allow the 
peer to assert any ID against any SPD entry that is linked to the 
cert. the linkage could be direct, e.g., a pointer to the cert in 
each SPD entry to which the cert applies, or it might be indirect, 
e.g., a pointer to a trust anchor from each SPD entry to which ... 
This model constrains the scope of the authenticated peer, allowing 
different certs or TAs to be applied to different SPD entries.  If 
the cert/SPD entry binding is 1-1, then there may be no security 
concerns here because the asserted ID may be irrelevant. If multiple 
SPD entries link to the cert, then the implications of the asserted 
ID may still be quite limited, based on which SPD entries are links 
to which certs. When a cert can apply to multiple SPD entries, then 
there is an opportunity to make use of an ID payload to match against 
a subset of these entries. For example, a TA might represent Company 
A, which issues certs to all its employees. When a company a employee 
tries to establish an SA to the Company B IPsec SG, the intent is to 
limit the access to that accorded to those employees.  But, within 
that context, different employees may have different permissions and 
thus have different SPD entries. The danger here is that an error in 
managing the cert/SPD entry table could allow one of these certs to 
be applied to other SPD entries that should be out of scope relative 
to the intended access control policy. if the goal is to allow 
assertion of different IDs for different authorizations relative to 
the Company A context, one could achieve the same goal by binding the 
certs for the individuals to the relevant SPD entries, but this would 
require much more management overhead. So, in this example, it does 
seem that there is benefit to asserting an ID separate from the ID(s) 
in the cert used in establishing the IKE SA. However, one might 
prefer to limit the range of IDs that might be asserted, e.g., by 
requiring the equivalent of name constraints to be applied to the 
asserted ID.


	3. when a peer presents a valid cert, and asserts an ID, one 
could require that the ID be matched to the Subject DN or to a 
Subject AltName. If we did this we would need to know how to map the 
asserted ID to the cert, i.e., which fields to compare and with which 
"matching rules." And, we still have to address the question of the 
scope of the cert validation. is it global, i.e., applies to all SPD 
entries, or is it linked to specific SPD entries? the latter case 
looks like #2 above, in terms of linkage options, but this time we 
apply some rules for matching. This is where #2 ended, discussing not 
direct matches but rather looking at matching rules like the name 
constraints extension. if the scope is global, then the cert may be 
implicitly linked to SPD entries, depending on the type of ID 
asserted. For example, a FQDN, 822Address, or DN would match only 
those SPD entries that used symbolic names for the IP address 
selector fields. If one used the name constraints extension in the 
configured trust anchors, this might be a fairly safe scope. But, 
without name constraints, any trust anchor could, in principle, issue 
a cert with any ID type and value and the resulting scope might not 
be any better than in #1 above.

I don't claim that this brief analysis resolves the question, but at 
least it may provide a context on which to clarify the discussions.

It seems that there are situations in which being able to assert an 
ID distinct from the cert used in the IKE exchange is valuable. So, I 
don't believe we ought to consider deleting that facility.

Rather, the problems seem to be how we describe the use of certs 
relative to SPD entries (something 2401 did not address), and what 
sort of matching rules we use
to decide if an asserted ID is valid relative to a provided cert. 
The problem I hear from Paul et al. is that often it is not possible 
for the administrators of IPsec systems to specify the data that CAs 
put into the certs that are exchanged (different unions?). if so, 
then it will be hard to take advantage of that data to constrain 
asserted IDs, and we need to make other provisions for achieving 
similar or equivalent scoping.  However, we might want to specify 
mechanisms for how to match ID against cert data, in a standard (vs. 
purely local) fashion, to facilitate interoperability and make this 
all more understandable when it is possible to take advantage of 
certs in a more sophisticated fashion.  We could make the former 
capabilities (for mapping certs to SPD entries) a MUST, as they will 
work in all cases, and the latter capability (matching rules for 
asserted IDs relative to certs) a SHOULD or MAY.

Steve