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.
------------------------------------------------------------------------------
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
