Re: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)

[Barney Wolff <barney@databus.com>]

On Mon, Jun 14, 2004 at 06:20:22PM -0700, Bernard Aboba wrote:
> 
> Here is what RFC 3579 says:
> 
> "In order to permit forwarding of the Access-Reply by EAP-unaware proxies,
> if a User-Name attribute was included in an Access-Request, the RADIUS
> server MUST include the User-Name attribute in subsequent Access-Accept
> packets. Without the User-Name attribute, accounting and billing becomes
> difficult to manage.  The User-Name attribute within the Access-Accept packet
> need not be the same as the User-Name attribute in the Access-Request."
> 
> So in effect, handling of a User-Name attribute within an Access-Accept is
> mandatory.  RFC 3579 also warns RADIUS client implementations not to
> assume that the User-Name attribute will not necessarily be the same in a
> response as in a request.
> 
> So I'd say that a RADIUS client needs to support User-Name in an
> Access-Accept and also needs to be prepared for user-name rewrite.

RFC3579 is specifically for EAP support in RADIUS.  Are you saying that
you believe it mandates behavior for RADIUS implementations that do not
support EAP?

Also, I don't understand the paragraph as written.  How would a User-Name
in an access reply help a proxy to forward it towards the original sender
of the request?  I would have thought that a stateless proxy would use
the State attribute to remember from whence a request came.

I hold no strong opinion on User-Name rewriting, but simply want to
understand the logic of the debate.

Regards,
Barney

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