Re: SPD name entries & IKE

[vamsi <vamsi@intotoinc.com>]

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:
>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.
>>
>>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.
>
>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