Bernard,
let me answer your question if username-rewrite could do the job as follows:
context (lothar wrote)
> "privacy-protected-identity", which - when present - is used instead
> of the NAI for all kinds of purposes normally the NAI is used for,
> including billing, re-authorization, abuse tracking etc.
Bernhard wrote:
Can't that function be handled by sending a User-Name attribute in the Access-Accept? Why would another attribute be needed?
Lothar responds:
I think the answer lies in Blair Bullocks mail in the below appendix.
Blair's mail has led me to believe that username rewrite may not be suitable in all cases. Also, it would be less overloading of the NAI and therefore more expandable if we introduce a "privacy protected identity" which can be uses as "billable identity" as well, compared to overloading the already overloaded NAI even more (with privacy feature).
This should allow more flexibility by virtue of being able to separate the "routing" function of the NAI from the "accountability" function which for privacy purposes may be "hidden" and home-resolvable only.
Please note that I meanwhile would propose to refer to the new attribute which we are discussing as "accountable-identity". This attribute name is IMHO more suitable than "billing-identity", as it also includes the notion of a malicious user being held accountable for abuse, even if no accounting is taking place for billing purposes, just logging of RADIUS accounting messages for abuse trackability purposes. It also covers the "privacy-protected-identity" as even though the identity is privacy protected, it is still accountable - but not without cooperation of the home network which may not be willing to share the true identity with all access networks and intermediaries.
Best Regards, Lothar
Appendix:
Blair Bullock wrote on 15.7.2004
"The routing is done based on the realm and/or prefix/suffix used for NAI decoration. In the context of conveying a billable identity, the
UserName(1) rewrite does not have to impact the realm or prefix/suffix parts of the decorated NAI. For example, if the AAA server receives UserName value Ananymous@anyisp.com in the Access-Request, the AAA server can convey the billable identity via UserName (1) rewrite like 2345@anyisp.com , where 2345 is the billable identity. This should cause the accounting packets follow the same path as the authorization. "
Assumes that all routing is suffix based in a direct peer-to-peer relationship. We don't route every domain to every other domain. The constant realm add/remove process is a total nightmare! Therefore a chained suffix or prefix is typically used to aggregate unknown suffixes under a roaming agency:
user@enterprise@ipass.com
Or
IPASS/user@enterprise.com
Either way, if the Access-Accept returns User-Name=user@enterprise.com and the accounting is re-written with this User-Name value, it will not route to the proper AAA exchange.
To reiterate some from my last email:
1- maintaining the re-decoration of the User-Name of the Access-Accept User-Name by the intermediary proxy requires statefulness of all AAA events.
2- To have the Access-Accept username return the decorated NAI from the Home AS requires knowledge of the aggregation principles (suffix or
prefix) and provisioning of that information at the Home Authentication Server so it will normalize the user-name and won't mess-up local requests. (not to mention what if the Home Network uses multiple aggregators with different aggregation suffixes and/or prefix). 3 - To route via suffix only with a root NAI as per the RFC user@realm requires realm add/deletes ad nauseum from now until the end of time. A reseller adds a new enterprise realm and we have to update every RADIUS proxy in the system to tell them it should be routed to our exchange?! When you have hundreds of networks it is untenable. Also, what if that realm can be routed via multiple intermediaries?!
Thus the intermediary decoration of user@enterprise@ipass.com or user@enterprise@gric.com (or IPASS/user@enterprise.com or even
IPASS/user@enterprise.com@reseller.com) is necessary to address these footprint aggregation, routing, reselling and billable user resolution requirements for roaming. Prefixes and suffix chains serve a very valid business functions. NAI decoration must be inclusive of all service models and is primarily used to eliminate the constant ongoing provisioning requirements of direct suffix peering. User@realm is too simplistic and doesn't reflect all of the business models that have emerged in our space over the past eight years.
On a side note, what if the inner method authentication simply uses "john" with no suffix in the user-name? Accounting will be re-written as just "john" and it will not route at all, even if there is a direct suffix relationship between two networks.
Position swapping of any NAI element is right-out bad.
Blair