Re: Scope of applicability for CUI

["Alan DeKok" <aland@ox.org>]

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

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

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

  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.

  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.

  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.

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