Re: NAI decoration: User Identity issues

[Bernard Aboba <aboba@internaut.com>]

> > Class attributes could change over the lifetime of even a session because
> > class attribute may store stuff other then just  the User Alias.  So you
> > cant use it as the User's Identity.

Depends who "you" is.  Presumably, the RADIUS server can use it, since it
sent the Class attribute.  But I think the point is that the RADIUS client
can't be sure that the Class attribute contains a billable identity. If
in addition the User-Name does not contain a billable identity (e.g.
privacy) then the RADIUS client has no assurance of billability.

> all the world's NAS's have to be upgraded?

This raises the question about whether the billable-identity is an
optional or mandatory attribute.  My take is that it is optional.
Here's why. If it is sent by the RADIUS server and not understood
by the NAS, RFC 2865 states clearly that it MAY be ignored.

My understanding is that the issue here is on the RADIUS client side,
because if the RADIUS server wanted to make sure that got the opaque
string back in the accounting record, it could always send that opaque
blob *both* in the billable-identity attribute and in Class.  That way,
if the RADIUS client cared about billable-identity, it would have it;
if not, it would ignore it.

If you buy this logic, then no NAS upgrade is required.

> If all NAS's are not forced to upgrade, how will the server know whether
> it can include User-Alias?

If the above argument isn't convincing, and we conclude that this
attribute is Mandatory, then we have an issue.  RFC 2865 doesn't
support Mandatory attributes.  There are a number of proposals
on the table to fix this, however (e.g. Jari's proposal for a
new attribute format with an 'M' bit).

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