RE: NAI decoration: User Identity issues

["Blair T. Bullock" <bbullock@ipass.com>]

"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

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] 
Sent: Wednesday, July 14, 2004 12:30 PM
To: 'Adrangi, Farid'; Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: NAI decoration: User Identity issues

Can somebody point me to a drafts/ literature describing different
methods of NAI decoration (prefix/ suffix based) and their rewrites by
the AAA infrastructure?

Thank you in advance,

Madjid

-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid
Sent: Wednesday, June 16, 2004 12:10 PM
To: Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: User Identity issues



Hi Bernard,
Please see my responses inline.
BR,
Farid

> 
> As Blair notes, there are cases where the Accounting data needs to 
> follow the same path as Authorization, and User-Name rewriting can 
> break that.

It depends.  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.

When a decorated NAI is used, we have a problem even if the UserName(1)
rewrite is done by the AAA server.  Let's say the client uses a
decorated NAI as per syntax defined in 2486bis - for example
home.com!Ananymous@intermediary.com.  Upon receipt of the
Access-Request, the intermediary strips off the decoration and forwards
the Access-Request.  Therefore, the UserName received by the AAA server
will be Ananymous@home.com.  In this case, even if the AAA server puts
the received UserName value as is (i.e., Ananymous@home.com) in the
Access-Accept, this will appear to NAS like UserName rewrite.  

However, please note that if prefix-based NAI decoration (e.g.,
intermediary.com/Ananymous@home.com) is used on contrary to what is
specified in 2486bis, the intermediary can forward the AccessRequest
without striping off the decoration -- that is, the AAA server will see
intermediary.com/joe@home.com.  The AAA server can return
intermediary.com/Ananymous@home.com or preferably
intermediary.com/2345@home.com (where 2345 is the billable identity).
This should cause the accounting packets follow the same path as the
authorization.


> This argument against User-Name rewrite is more compelling than NAS 
> compatibility or billing system compatibility since new attributes 
> will also require changes to NASen and billing systems.
> 
> I'd suggest that we need a discussion of the issues so that we can 
> understand when it is safe to do User-Name rewriting, and when this 
> can cause problems.

In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute.  

> 
> The major impetus for User-Name rewrite as I understand it is for use 
> in privacy.  There are also the cosmetic cases that Dave Mitton has 
> mentioned (e.g. changing case) but I think these are relatively 
> benign.
> 
> So how do we go forward?  There may need to be an errata submitted for

> RFC 3579.  As Barney Wolff pointed out, the text of RFC 3579 is 
> somewhat misleading; User-Name rewriting is not required for the 
> routing of the Access-Accept back to the NAS;  Proxy State can handle 
> this.
> 

RFC 3579 also needs to make it clear which identity the NAS should use
in the accounting requests -- the original identity sent in the
Access-Request, or the identity received in the Access-Accept.  

> I'd also like to understand if there are guidelines that a server can 
> use to determine when User-Name rewrite is safe and when it isn't.  
> For example, what if a user attempts to protect Privacy in a network 
> set up as Blair has suggested?  What breaks?  Is there a way for the 
> server to detect the situation and not cause problems?
> 
> I also think that we need to discuss this in the Network Discovery 
> Problem Statement, since if a user desires to influence the mediating 
> network, then accounting supporting that decision needs to be carried 
> out.
> 
> 

Yes. And, I think use of prefix-based decorated NAI (as originally
specified in the mediating network discovery draft!) would solve this
problem - please see the argument above.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>