RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Hi Alan,

See comments inline.

> -----Original Message-----
> From: Alan DeKok [mailto:aland@ox.org] 
> Sent: Wednesday, December 22, 2004 11:26 AM
> To: radiusext@ops.ietf.org
> Subject: Re: Scope of applicability for CUI
> 
> 
> "Nelson, David" <dnelson@enterasys.com> wrote:
> > 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 rephrase:
> 
>   User-Name is a token by which the NAS which establishes the 
> "identity" of a user within a session.

Not 100% accurate. User-Name may only be used for routing. Right?

>   Class is one or more tokens by which each proxying RADIUS 
> server establishes it's own view of the "identity" of a session.

Again not 100% accurate.  We can't really say what class is used for. It
could be for identity tracking and it could be for other things.  That is
the problem with class. The minute we try to standerdize it's meaning we
will break someone's RADIUS implementation.

For us class carries some state information and not necessarily identity.
It's use changes between customers etc.

For example, the value for Class that I use for joe's session
(Joe@example.com) and for franks session (frank@example.com) may be
identical.  After all I maybe using the Class attribute to track something
about realms and not users.

>   CUI is proposed to be a token by which the home server 
> establishes it's own view of the "identity" of a session.  
> (If I interpret the proposal correctly.)

CUI is a token by which the home network (home server) establishes a handle
to a user in the home network. The value can be a permament handle (bad if
privacy is an issue) or a temporary handle that is valid for some period of
time.

So to make sure that we are 100% accurate: the identity is not for for the
homenetwork its for the those outside the homenetwork that require this
assertion by the home network to do business.
 
>   The attributes are created by different entities in the 
> network, and are intended to do different things.  There's 
> only one NAS in a session, so there can be only one 
> User-Name.  There are multiple proxying servers, so there can 
> be multiple Class attributes.  There's only one home server, 
> so there can only be one CUI.

They may or may not be created by different entities in the homenetwork.
But yes to the rest.

>   Taken in combination, the above attributes allows each 
> participant in the RADIUS conversation to associate a "token" 
> with a login session, that it, and it alone, controls.

I suppose this can be correct.  That is if we agree that Class is used for
identity tracking.
 
>   Like the User-Name, the CUI should be (at some level) 
> visible & interpretable by every participant in the RADIUS 
> conversation.  This may include a definition of CUI as an 
> opaque token.  The important difference between CUI and 
> Class, though, is that CUI is defined to be a token added by 
> the home server.  All proxying servers, and the NAS, can use 
> & interpret CUI in that context.  They are explicitly 
> forbidden from doing so for the Class attribute.

Exactly.

Well the importance difference between CUI and Class is that:
-We can't use Class to do what we want because the standards already tell us
what Class is used for.
 
>   Avi?  Does that sound like a reasonable summary?


>   Alan DeKok.
> 
> --
> 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/>