RE: Scope of applicability for CUI

["Nelson, David" <dnelson@enterasys.com>]

Avi Lior writes...

> As a driving usecase for this work we noted that when certain EAP
> methods are used the identity of the user is hidden and mediating 
> networks have no way to associate an Authentication\Authorization 
> and or Accounting events to a specific user or chargeable entity. 
> CUI provides a mechanims whereby the home network can provide a 
> handle to the chargeable entity (without revealing the true identity),
> to the roaming partners and or mediating networks.

Yes, this is the justification for standardizing the CUI attribute as a
RADEXT WG work item. (And the *only* justification, IMHO.)

> This does not mean that it is required when EAP is used.  Nor does it
mean
> that it can't be used in cases where EAP is not used.
> 
> It simply means that it is available to be used when it is required by
> roaming partners - for whatever reason.

I object to the "for whatever reason" line of reasoning.  We have
justified the existence, usage and support requirement for
Chargeable-User-ID by a very specific use case.  Since it is an "alias"
for User-Name, and User-Name SHOULD always be used in preference to
Chargeable-User-ID, unless these specific circumstances apply, why would
it lead to greater interoperability in RADIUS for this attribute to be
generally available for various undocumented uses?

I am generally opposed to "opaque carrier attributes" that have the
imprimatur of standardization, by being described in a Standards Track
RFC for a specific, well documented purpose, but are then used for
other, potentially proprietary, purposes besides the explicitly
documented one.  I am vaguely concerned that the Chargeable-User-ID
might become one of these, if its scope of use is not clearly and
concisely defined.


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