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 3:01 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> While my last posting in this thread addressed process 
> issues, here I attempt to address substance.
>  
> > 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.
> 
> In the absence of any bindings, it would appear that the CUI, 
> as you describe it, is an assertion by the Home AAA Server 
> that the content is a token that represents *some* user, or 
> group of users, known to the HAAA.  It would be a stretch to 
> assert that it represents "user A" or any other *specific* 
> meta-user.  The only binding is that the CUI token is 
> associated with the current NAS service session, as 
> authorized by the Access-Accept message in which the CUI appears.

If the home network is compliant to the draft it the assertion must be of a
User or a Chargeable Entity in the home network.  Any other meaning are not
acceptable.
  
> > 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.

> OK.  So in this use case CUI is an alternate to User-Name (or 
> possibly to Acct-Session-ID).

Huh? Accounting-Session-Id? Accounting Session Id changes even within a
single Login.  Its purpose is to link Starts with Interims and Stops. That's
it.
 
> > 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.
> 
> I take it you are proposing to exclude from consideration any 
> use cases for CUI other than:
> 
> 1.) The NAS includes a previously received CUI in 
> Accounting-Request messages, as supplemental or alternative 
> information to User-Name or Acct-Session-ID.

What problem does this usecase address? If this usecase is trying to
*STRICTLY* solve the association of an particular Access-Request to an
accounting stream associated with that session, Irrespective of the User
Identity. Then this use case is not in-scope.  Class and Acct-Session-Id
could do this.   So we would exclude this one. It's covered by other RFCs.

> 2.) The HAAA (or Proxies??) include CUI in a CoA-Request 
> message as a session identifier, of sorts.  (Of course, this 
> begs the question of whether CUI is always unique to a 
> particular session...)

I think we dropped CUI for dynamic authorization. BTW CUI would identify all
sessions for the user on that NAS, just the same as username would.  You
need a session identifier (e.g., Acct-Session-Id) to surgically remove a
particular session of a user.

> 3.) The NAS may compare the value of one instance of CUI to 
> another instance of CUI to get some idea of whether the Home 
> AAA Server considerers the identity of the users represented 
> by these CUI instances as "equivalent" in some sense -- 
> either the same user or members of the same user group.

Yes NAS or to be even more precise RADIUS Client.
 
> I think it is true that the Class attribute could be used for 
> (1) but not for (2) or (3).
                       
> Does that sound about right?

As indicated, yes. 
> 
> --
> 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/>