RE: Scope of applicability for CUI

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

John Loughney writes...

> Is there a need or use fo have the attribute be parsable by the NAS or
> Proxy? 

It seems to me that there is, based on assertions that have been made on
the list regarding the properties and uses of CUI.  For example:

- It has been asserted that one of the reasons that the Class attribute
doesn't fill the need is because NASes are prohibited from interpreting
the content of Class.  I infer, therefore, that NASes are, in at least
some cases, required to interpret the content of CUI.

- It has been asserted that one of the use cases for CUI is to provide a
mechanism for all parties (ISPs, Mediators, Brokers, Roaming Consortia
Members, etc.) to be able to ensure that that get their full share of
the attendant revenues.  In order for any such mechanism to have any
"teeth" it is required, I think, that the evidence of any such
transactions, including the CUI, be in a format suitable for submission
to a court of law.  Yes, this is the last resort, but without it the
system has no checks and balances.  Therefore, I presume that the CUI
must be printable ASCII and capable of convincing a Judge that payment
for services rendered is due to the plaintiff.

- It has been asserted that in certain jurisdictions, IPSs (and others)
may have a legal obligation to provide the identity of users who are
suspected of launching cyber-attacks.  In such jurisdictions, one would
suppose that the level of privacy in the CUI would not be resistant to
judicial inspection, however that might be arranged.  In such cases the
parties to the transaction need to have a form of CUI that that can be
delivered to the authorized law enforcement authorities.

> I guess you are worried that if there is no standardized format,
> it could be used at some point in the future to carry other
information
> not related to CUI uses;

That is a secondary concern.  There is some inherent temptation for
implementers to overload IETF standard RADIUS attributes, that are
opaque strings, with new functions, rather that using VSAs, or seeking
to standardize new attributes.

> but as currently defined, I don't see the issue of needing a standard 
> format and syntax for CUI.

Hmmm. If the format of CUI can be *anything*, then it is an opaque token
or cookie, and fairly indistinguishable from Class.  Am I missing a
fundamental point here?


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