RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

David,

See inline,

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Wednesday, December 22, 2004 10:15 AM
> To: radiusext@ops.ietf.org
> Subject: RE: Scope of applicability for CUI
> 
> 
> 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.

If CUI was carried in the Class attribute then NASes (or more accurately)
RADIUS clients would have to infere what is in the Class attribute. This is
because Class can carry more then just CUI.

Since CUI servers one purpose as defined by the draft then the RADIUS
clients just need to use it without interpreting its contents.

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

Are you suggesting the CUI would be "TEXT" as opposed to "String".  I hope
not.  I mean one of the most crucial piece of evidence would be the
User-name attribute which is a String.  So are we going to re-write all of
these attributes in "TEXT". Lets get real here.

I think presentation of a packet has a hex dump as evidence would *not* be
considered novel in judice prudence.
 
> - 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.

CUI is a String and is no different then User-Name also a string.
The user identity part in username can be a number as well. As in an account
number. I think we are going ahead of ourselves.

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

How an operator comes up with a unique value is really no concern of ours.
The attribute if it conforms to the draft must be unique for a given amount
of time.

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

I think you don't understand how class works.  
The fundemental piece that you are missing is that the only entity that can
draw any meaning out of the "Class" attribute is the entity that issued the
"Class" attribute.  This is well documented in 2865.
 
> 
> --
> 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/>
> 

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