RE: User Identity issues

[Bernard Aboba <aboba@internaut.com>]

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

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.

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.


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