Hallelujah, I wholeheartedly concur with this statement. It is
basically the same concept as the proposed Class usage for the purposes
of user-name accounting data reflection, but specifically dedicated to
the resolution of RADIUS-routable and billable identities in Tunneled
EAP methods.
This is an important distinction because it allows the local ISP to know
that a billable identity has been returned without having to parse the
Class attibute which is supposed to be treated like opaque text. After
all, multiple Class attributes can be returned, some of which might
represent a billable identity, some might not. How is the local operator
to know? So I think a billable identity attribute is required here.
the NAS and an Authenticated-User which is the Billable authenticated
The Billable Identity is an identity used for accounting purposes, not
authentication. I hope we're clear on that.
from a RADIUS standpoint... While also maintaining an Authenticator
protected billable identity (or alias) which is not transmitted over the
air, but represented by the NAS from the value of the User-Name in the
Access-Accept.
In the case of Privacy, it might not relate to the User-Name attribute at
all. There is no requirement that they match in any way.
not pass the user-name back in the Access-accept to maintain the
That is always the RADIUS server choice, because it is optional.
checking to ensure that the Inner and Outer identities are identical at
a 'root' NAI level (regardless of additional chained suffixes or
Careful. These identities may not relate to each other.
--
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/>