Re: SPD name entries & IKE

[Stephen Kent <kent@bbn.com>]

At 12:34 -0800 1/22/04, vamsi wrote:
>Hi Steve,
>     I understand the scenario which you described. You seem to indicate that
>     you might use two different Identifications - One while using 
>laptop as road warrior and
>     another by Desktop.


Not exactly right. What I said was that I might not want to be forced 
to do that. I might want to be able to use the same ID in both 
contexts, since I'm still ME, but be able to assert when the ID is 
used for SPD lookup, vs. when the IP address traffic selectors are 
used as the search keys.  However, maybe that is not a requirement; 
maybe I'm trying to be too flexible here. If everybody can live with 
a simple rule about when to use a name as the search key for SPD 
lookup, I'm happy and we will not need to make changes to IKE.

Note that the PAD, newly introduced in 2401bis, is a means to 
constraining the range of traffic selectors that is asserted by a 
peer, after the peer is authenticated. This addresses an issue Paul 
raised when he said:

>Looking at it a different way might help. In the presence of an 
>authenticator, why would the responder ever use the information in 
>the selector payloads? The authenticators are always externally 
>assured. If they are preshared keys, the act of presharing assures 
>both sides of the identities; if they are certs, the 
>mutually-trusted CA assures both sides that the identities in the 
>certs are valid. Selector payloads are just assertions by the 
>initiator of what they are supposed to have access to. Always using 
>the externally assured authenticators seems like a better idea.

The ID asserted in IKE should be used to locate a PAD entry that says 
how to verify the asserted identity, and that then says what 
constraints, of any, ought to be imposed on the peers traffic 
selector assertions, based on the authentication. So, for example, 
one could constrain the range of addresses (source or dest) that the 
peer asserts in traffic selector payloads that are passed for lookup 
in the SPD.

If we adopted Paul's suggestion, and always used a name for the ID, 
then one could always require using this ID to select SPD entries, 
which would allow one to impose constrains directly via the SPD 
entries.  I have no problem with this approach, and agree that it 
seems intrinsically more secure.

Also, if folks are not concerned about the restrictions imposed by 
always using the ID to select SPD entries (when acting as a 
responder), then maybe we can make minimal changes to the text to 
resolve this issue. For example, we could say that the PAD will 
indicate whether the ID asserted in the IKE ID payload is to be used 
for SPD lookup as a substitute for IP source or dest address, or 
whether the addresses from the traffic selector payload are used.

Steve