RE: NAI decoration: User Identity issues

[Bernard Aboba <aboba@internaut.com>]

> It would seem to me that in order to function as a billing
> reconciliation mechanism (see Roy Albert's response) such an attribute
> (User-Alias) MUST NOT be decorated or modified by intermediaries.

Yes.

> Could someone please review the technical (and business) reasons that
> State could not serve this requirement?  Is it that State is supposed to
> be an opaque object?  Is it that State is not required to contain
> printable ASCII suitable for inclusion on billing statements?

I think that's the reason.  Basically, the local operator needs to be
assured that it has a billable identity on hand before providing service.
If privacy is being used, the User-Name may not contain a billable
identity, and the local operator may not be able to determine from the
Class, State, etc. attribute whether a billable identity is present or
not.

For example, what if the NAS receives 3 Class/State attributes:

dnelson@enterasys.com
82673F0D2745037126@BH239487sdkd2jd
ToBeOrNotToBe.Shakespeare

Which one of these 3 attribute is the billable identity?  Does the NAS
have to parse the attributes and determine which, if any, comply with the
grammar of RFC 2486bis?  Remember, the problem exists not on the RADIUS
server (which presumably can sort things out) but on the RADIUS client
that is trying to figure out if it is going to get paid.

Of course, exactly the same problems occur if a new attribute is defined
that can contain "anything", and can be sent multiple times by the RADIUS
server.

In summary:

* The problem occurs when Privacy is used and the User-Name cannot be used
  as a billable identity by the local operator.

* If sent in the Access-Accept, the User-Name attribute is included in the
  accounting record.

* Since the User-Name attribute sent by the RADIUS server is undecorated,
  it may cause mis-routing of accounting packets. So the
  RADIUS server may not wish to send the User-Name attribute.

* The Billable-Identity attribute if sent by the RADIUS server, is
  guaranteed to contain a billable identity.  It MUST NOT be modified
  by intermediaries, and if received, is placed in the accounting record
  by the NAS.

* In all cases, the User-Name MUST be included in the Accounting-Record.

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