RE: Scope of applicability for CUI

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

Avi Lior writes...

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

OK. That's a helpful clarification.

> Huh? Accounting-Session-Id? Accounting Session Id changes even 
> within a single Login.  Its purpose is to link Starts with Interims 
> and Stops.

I'm fishing for a better understanding of CUI.  The term "assertion of
identity" is pretty general.

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

I'd swear this use case is described in the 00 CUI draft.  :-)  If it's
out of scope, then I'm even more confused...  Perhaps the analogy to
Acct-Session-ID has clouded the issue for you?

So, the RADIUS Client never includes the CUI attribute in any RADIUS
messages, with the possible exception of a NULL version in an
Access-Request as capability advertisement?  That's not what the 00 CUI
draft says.

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

There are still references in the 00 CUI draft.
 
> > 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.

We need to resolve the disposition of use case (1) above, as it does
appear in the 00 CUI draft, and has been frequently discussed on the
list.  We also need to see if there is consensus on these use cases as
being the only important ones to consider.  

If that consensus is obtained, then I would agree that the CUI format
(syntax) should be changed to an opaque token, and perhaps we could
borrow the syntax description from Class (but not the semantics
description!).  In that case it would be the explicit CUI "name formats"
(01 - 04) that should be removed from the draft.  We should also include
text that prohibits RADIUS Clients from attempting to interpret the CUI
content, or make any other local use of CUI beyond the equality
comparison operation.

I have heard other use cases advocated on the list, however, so it will
be important to poll for consensus on this issue.

 

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