Subject: SPD name entries & IKE

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Jan 2004 13:17:00 -0500

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

---

From: vamsi <[email-masked]>
Date: Wed, 21 Jan 2004 12:13:54 -0800

Some implementation, including ours, identify the remote roaming user by 
their ID (ID in certificate
OR ID from the payload) and corresponding SPD policies are activated upon 
phase1 completion.
While activating the SPD policies, the Destiantion IP address of outbound 
policies and Source IP address
of corresponding incoming policies are changed to the remote user's IP 
address (Source  IP of phase1 first message).
Due to this, Quick Mode (QM) succeeds and finds the right SPD policy by 
matching with the selectors.

At the end of phase1 and phase2  SA termination and
if no phase1 is initiated by remote client for some duration of time, 
corresponding SPD policies are de-activated and go
to dormant state.

Due to this, I don't see any need for searching for SPD policy based on 
symbolic name, during QM.
It might offer other advantages, but for this scenario, I don't see the need.

At 01:17 PM 1/21/2004 -0500, Stephen Kent wrote:
>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.
>
>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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 21 Jan 2004 12:43:59 -0800

At 1:17 PM -0500 1/21/04, Stephen Kent wrote:
>payloads.

Correct.

>   To me, this suggests that we need yet one more minor modification 
>to IKE to accommodate this case.

Implementers seem to be of (at least) two minds on this. One camp 
says "the initiator has no right telling the responder what the 
responder should be doing in its security policy lookup". The other 
camp says "in a closed IPsec environment, the system administrator 
can tell the initiator how to tell the responder to use the ID for 
lookup". The revised identity discussion didn't come to agreement on 
this; it seems like it is a religious issue.

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.

--Paul Hoffman, Director
--VPN Consortium

---

From: Thor Lancelot Simon <[email-masked]>
Date: Wed, 21 Jan 2004 18:21:36 -0500

> matching with the selectors.

The ReefEdge implementation did something similar to this, at least when
I worked on it; I assume it still does.  For users with preshared key
authentication in IKE, we had to use an out-of-band mechanism to identify
the user and communicate a single-use PSK, which is conceptually similar
to what PIC does.

When we added certificate support, we ended up doing approximately what
vamsi describes.  I suspect that others who do so share another of our
concerns, which was that of securely binding together an identity used
in IKE with an identity used by a separate -- legacy or otherwise --
AAA system.  One thing you need to be *extremely* careful of when you
set out to do this is to avoid session-stealing attacks, in which a
different authorized user renegotiates Phase 1 and then may use the
network as the user you originally authenticated, and whose security
policy rules you looked up.  Essentially, this approach obligates you
to track which identities are used in Phase 1 and destroy *all* state
associated with a given IP address when that identity changes.  It is
possible, but I have seen other vendors get it wrong; indeed, we
very nearly got it wrong ourselves, and felt pretty lucky that we
managed to thrash out a better solution than our original one!

Thor

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Jan 2004 16:21:06 -0500

At 12:13 -0800 1/21/04, vamsi wrote:
>Some implementation, including ours, identify the remote roaming 
>user by their ID (ID in certificate
>OR ID from the payload) and corresponding SPD policies are activated 
>upon phase1 completion.
>While activating the SPD policies, the Destiantion IP address of 
>outbound policies and Source IP address
>of corresponding incoming policies are changed to the remote user's 
>IP address (Source  IP of phase1 first message).
>Due to this, Quick Mode (QM) succeeds and finds the right SPD policy 
>by matching with the selectors.
>
>if no phase1 is initiated by remote client for some duration of 
>time, corresponding SPD policies are de-activated and go
>to dormant state.
>
>Due to this, I don't see any need for searching for SPD policy based 
>on symbolic name, during QM.

Thanks for the explanation of how you resolve the ambiguity. A few 
details are missing from your description, so let me try to fill them 
in, and you can correct me if I guess wrong.

First, you said that you use the name from the payload (or cert 
Subject) to select an SPD entry. This suggests that a given ID always 
is used to select an named SPD entry, or never is used. (In the new 
model, the PAD is where this info could be maintained.) However, this 
is not a completely general solution, although it may be fine in many 
contexts. For example, if I use my laptop as a road warrior sometimes 
but as my desktop machine at other times (which is exactly what I do) 
I'll always be mapped to a name-based SPD entry. This might not 
always be the desired effect.

also, I'm focusing on IKEv2, not IKEv1, something I should have made 
clear in my message. your message seems to emphasize QM, and what I 
am looking to describe is a uniform mechanism, in the IKE v2 context.

Let's hear from other vendors to see if there is common approach we 
can describe in 2401bis, or if we need to do something new (for 
IKVv2).

Thanks,

Steve

---

From: vamsi <[email-masked]>
Date: Thu, 22 Jan 2004 12:34:25 -0800

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. I understand that, proposed common name (named 
tag) can be used to
     identify set of policies in both of above cases. If my understanding 
is wrong, following
     text can be skipped.

     Typically, in this case, two different IDs can point to the same set 
of SPD policies.
     Thereby, access from laptop (road warrior) or desktop would give same 
security.

     What I observed is that, user specific SPD policies are activated, not 
only
     by IKE or extended authentication, but also by 802.1x based 
authentication and
     SSL based authentication. In later cases, even the IKE policies are 
associated
     with the user ID. Using user ID (Certificate Id or ID from ID paylaod) 
would be
     good to associate with any kind of policies and it provides uniform 
authorization.

     There is also one more point to be considered. If user ID is not used for
     SPD policy selection, impersonation may be possible. Consider, two 
employees
     with different access permissions are on road and accessing corporate
     resources. It would be possible for anybody to use any ''named tag' and
     get other employees access permissions to the corporate network, 
unless this
     'named tag'  itself  is authenticated.  Since, user ID is 
authenticated, same can
     be used to select the policies, including SPD policies.

     If some scenarios require this type of 'common name' , then I feel 
that it should be
     somehow associated with user ID OR it needs to authenticated.

Thanks
Vamsi
CTO Office
Intoto Inc.
www.intoto.com

At 04:21 PM 1/21/2004 -0500, Stephen Kent wrote:
>Thanks for the explanation of how you resolve the ambiguity. A few details 
>are missing from your description, so let me try to fill them in, and you 
>can correct me if I guess wrong.
>
>First, you said that you use the name from the payload (or cert Subject) 
>to select an SPD entry. This suggests that a given ID always is used to 
>select an named SPD entry, or never is used. (In the new model, the PAD is 
>where this info could be maintained.) However, this is not a completely 
>general solution, although it may be fine in many contexts. For example, 
>if I use my laptop as a road warrior sometimes but as my desktop machine 
>at other times (which is exactly what I do) I'll always be mapped to a 
>name-based SPD entry. This might not always be the desired effect.
>
>also, I'm focusing on IKEv2, not IKEv1, something I should have made clear 
>in my message. your message seems to emphasize QM, and what I am looking 
>to describe is a uniform mechanism, in the IKE v2 context.
>
>Let's hear from other vendors to see if there is common approach we can 
>describe in 2401bis, or if we need to do something new (for IKVv2).
>
>Thanks,
>
>Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Jan 2004 15:39:41 -0500

At 12:34 -0800 1/22/04, vamsi wrote:
>     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:

>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