RE: Scope of applicability for CUI

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

Avi Lior writes...

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

Agreed.  However, if the only "consumer" of CUI is the Home AAA server,
then it doesn't matter if CUI is commingled with Class.  So therefore,
NASes and Proxies must be "consumers" of CUI.

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

I guess this is what still confuses me -- how the NASes and Proxies make
use of the CUI without interpreting it.  That leads me to believe they
treat it as an opaque cookie, similar to (but subtly different from)
Class.  What, exactly, do the NASes and Proxies do with this CUI cookie?
Is that not for the RFC reader to know?

> Are you suggesting the CUI would be "TEXT" as opposed to "String".  
> I hope not.

While I had not explicitly made that connection, it might be logical in
support of some of the suggested use cases.  Let me be clear -- it is
not at all evident to me that there is consensus on the list as to what
the CUI use cases are.  Quite a few differing suggestions have been made
(and not all of them by the authors of the CUI draft).

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

Please be assured that I am "real".  :-)  The User-Name attribute was
defined in the very first RADIUS RFC, before the introduction of the
Text data type.  Therefore it is still String.  I suspect most
implementations, however, in fact treat it as Text.

> I think presentation of a packet has a hex dump as evidence would 
> *not* be considered novel in judice prudence.

That may be so.  Let me play amateur attorney here for a second and
suggest that learned counsel for the plaintiff would not likely
recommend HEX format evidence as the preferential format, given a
choice.  :-)   The difference being what you *could* do, if pressed, and
what would be *convenient* to do, given some influence over the choice.
Why make life complicated?
 
> 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'm simply reflecting what I have heard from posters to the list...

> How an operator comes up with a unique value is really no concern 
> of ours.

Yes, assuming we finally come to consensus that opaque is the way to go,
and that the semantics are limited to the stated purpose of the CUI
attribute.

> I think you don't understand how class works.

I think that you're mistaken in that assertion.

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

No argument here.

What baffles me, however is two apparently conflicting assertions:

- CUI is issued by the Home AAA Server and is intended to be interpreted
by the NASes and Proxies.

- CUI is opaque (or might be opaque) and therefore can only be
interpreted by the Home AAA Server that issued it.

I see two possible ways to resolve this apparent paradox:

- The CUI is opaque to the Internet Community at large and therefore can
only be interpreted by the Home AAA Server that issues it, but with the
knowledge of some "secret sauce", the NASes and Proxies in specific
deployment environments are capable of interpreting the CUI.

- The CUI is opaque to the NASes and Proxies that use it, and the only
form that the "use" takes is to compare one instance of a CUI cookie to
see if it matches another instance of a CUI cookie.  (I would note that
this does not meet all the requirements of all of the proposed CUI use
cases.)

It is the potential for any such "secret sauce" that concerns me, in
terms of its negative impact on global, multi-vendor interoperability.
IMHO, the existence of "secret sauce" is incompatible with IETF
Standards Track protocol definition.

Is there another, more satisfying, resolution to this apparent paradox?



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