RE: User Identity issues

["Adrangi, Farid" <farid.adrangi@intel.com>]

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/>