SPD name entries & IKE

[Stephen Kent <kent@bbn.com>]

Folks,

In revising 2401 we tried to more clearly describe how the SPD works, 
as well as expanding it to cover new selector types, i.e., mobility 
header and ICMP type & code values.

In the course of this work we encountered a problem with the use of 
symbolic names. The primary motivation for accommodating a symbolic 
name in an SPD entry is to allow for an incoming SA creation request 
for a user or machine for which no fixed Ip address is known a 
priori. Other possible uses noted in 2401 included providing 
fine-grained access control for individual users/processes on a 
multi-user system. However, this latter case seems to be not a 
significant requirement based on existing practice, right?

In the primary case, the symbolic name in an SPD entry is a 
placeholder to be replaced with the IP address associated with the 
IKE peer, when the peer is authenticated as an authorized 
representative for the name. For example, a road warrior might be 
authenticated using a cert. In that case, the PAD (a newly 
articulated construct in 2401bis) would indicate that the CA who 
issued the cert is authorized to issue credentials to all employees 
(or maybe just to road warriors). Thus the ID asserted by IKE would 
be verified as acceptable, relative to the CA, and the PAD indicates 
how the ID asserted by IKE is verified, e.g., is it matched to the 
cert Subject name, or simply accepted because the cert itself has 
been validated?

However, even with the introduction of the PAD, we still have a 
problem in this case. Specifically, how do we know that, for a 
specific SA establishment activity, we should perform an SPD lookup 
using the ID from IKE in the SPD as a substitute for the source IP 
address for inbound traffic, instead of using the the address that 
appears in the traffic selector payloads?  We need to use the latter 
address when we instantiate the SPD cache and SAD entries, but we 
need to use the name for the initial SPD lookup.

What we discovered, in talking with several folks, is that there 
appears to be no standard way for the IKE initiator to signal to a 
responder that the ID is to be used for the lookup, vs. the selector 
payloads.  To me, this suggests that we need yet one more minor 
modification to IKE to accommodate this case. \

Suggestions?

Steve