RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Hi David,

See comments inline.

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

Yes. And that is why we say that Home Netowrk is the producer of CUI and not
the consumer 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?

They use it as a number. So if CUI is "234OIUOIU" they know that that value
represents an assertion by the home network that this is represent user A in
my network.  That is why originally we wanted to call it an Alias.

A lot different then Class.  Because Class has no such meaning and can have
no such meaning from a standard point of view. The purpose and use of Class
is already cast in stone.


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

We are not looking for consensus of the use cases.  I don't belive that we
would ever achieve consensus on the list for all or even most use cases.

I think though that there is consensus on the following:
-CUI is for the entities outside the home network;
-It is needed in cases where clients need to have an identity assertion
especially where there is no such possibility as in the case where the
username cannot be used for that purpose.

I think that other use cases are possible.  And we have some suggest them.
 
> > 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.

And is that broken?  I don't think so.
When CUI is opaque then it should be able to take any octet as a value. 

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

Exactly why make life complicated. Lets just move on here ;-)

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

Well sorry for shoting the messenger.  It still doesn't change the fact that
the username can be 122345@example.com

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

No. The "How: is not important. The "What" is. How you calculate the number
is really up to the operator.  The important thing is the "What" which is
what the number stands for. That is what we are to standardize.

Whether they take the username and apply a hash to it, or whether they
assign the CUI to each user is up to them.  The end result needs to be the
same. The number must be unique withing the scope of the home network.

> > I think you don't understand how class works.
> 
> I think that you're mistaken in that assertion.

Well perhaps I am but then why do we come back to class?

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

I don't understand interpreted by the Home AAA Server.  In the case where
the CUI is opaque, the Home Network sets its value to some "String" that it
asserts represents a unique user in the network.  Call it a temporary user
id if you like.

We call it opaque because:

The homenetwork could do the following:

"Timestamp|hashofUser|...."

So its opaque because we don't need the consumers of the CUI to know what
the receipe or format of the number is.  We are intentianly not specifying
what the value is.

So this is not a new concept in IETF. I think we are going to agree to
disagree here.


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

We therefore allow several forms other then Opaque. My original assertions
is that Opaque was the only one that was needed. But there are just some
things that are not worth taking on.  After all, I want to maintain a good
working relationship with my authors.

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

How the unique number is internally formated and/or generated does not break
interoperability.  That is why we say opaque. We don't care.

I don't see how we can't achieve interoperability with an opaque value.  If
I tell you that the number represents a unique user in my network then you
really don't need to know how I calculated it.  

What we care about is What that number represents!!!.

And the IETF has lots of examples of opaque attributes.

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

I don't see a paradox but lets just agree to disagree and move on.

And even if I agree there is a paradox.  I don't think all paradoxes need to
be solved.

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