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", 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. 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) 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. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
