Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-erx-00

[Qin Wu <[e-mail]>]

Hi,
----- Original Message ----- 
From: "Yoav Nir" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>rg>; "Dan Harkins" <[e-mail]>rg>; <[e-mail]>
Sent: Wednesday, May 11, 2011 10:19 PM
Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00


> 
> On May 7, 2011, at 3:42 AM, Qin Wu wrote:
> 
>>  
>> 
>>> 
>>> It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com".com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names.
>>> 
>>> So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions.
>> 
>> I'm not even sure of that. Qin, does ERP give us the domain name of the original authenticating server?  Do we even know if the user came from this-isp or that-isp?
>> 
>>> 
>>> Thanks,
>>>     Yaron
>>  
>> [Qin]: Sure.
>>  
>> The domain name of the original authenticating server you are talking about is actually home domain name.
>> The peer bootstraps from the home domain at the first time and should know home domain name or home ER server name wherever it moves around.
>> The peer learns local domain name through ERP message or other lower layer mechanism. Therefore the peer can identify which domain it move to.
>> The local ER server and ER  authenticator can know domain name through realm part of KeyName-NAI TLV carried in the ERP message sent from the peer.
>> Comparing realm part of KeyName-NAI and the domain which they belong to, they also can identify if the user come from home domain or local domain.
> 
> I wonder if local domain is ever distinct from home domain with IKE.

[Qin]: From AAA perspective, local domain or visited domain should be distinct from home domain.
>From IKE perspective, I am not sure.

> IKE/IPsec is usually used for site-to-site and for remote access VPNs. There is also some use for host-to-host, but I don't know what they use for authentication.
> 
> In the case of remote-access, the client connects to some home gateway. Unless there's some complex federation going with a single gateway answering for multiple domains, everyone connects to a gateway that is connected directly to the home RADIUS server. Even phones with an Internet (not 3G/4G) connection will connect to their "home" operator network rather than to a local operator network.
> 
> So I don't think there's a case where the AAA server is not the home server. And in that case, the AAA server has the real user name. So if we're using re-authentication, the VPN gateway has the domain (it is the same domain) and an ephemeral identity generated by the original EAP, which may have been done with another authenticator (such as a 802.1x access point)

[Qin]: It depdents on the scenario you are talking about.
When you are doing authorization, you should go back to home domain to talk with home
 AAA server since Home AAA server maintain user profile. When you are doing authentication, 
it is not necessary to go back to talk with home server each time since keying materails can be
transported to the domain which the client currectly connected to.

If you assume authorization and authentication are doing together each time, Fine, ERP described in RFC5296 allows this case.
In such case, there is no local ER server deployed in the visited domain, therefore each time the client or the peer should
go back to talk with home server.

Also I should point out EAP server or ER server may be separated from AAA server.

> This reduces the problem to getting the real ID from the ephemeral ID, assuming that you are talking to the real RADIUS server, or else being able to fetch policy from such a server or from an LDAP server. I guess vendors could have proprietary solutions, but I'm wondering if there's a standardized way to do this.

[Qin] We can go to do authorization in home domain each time. In this way, we can be easy to get real ID.

BTW:I remember this similar issue had been discussed in DIME and Hokey Working group.
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec