RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Hi David,

Great let me summarize here.

Regarding scenario 1)  I could agree that that is in scope of the document:
Notice I reworded it a bit.

"The home network provides the CUI as a suplemental or alternative
information to User-Name."

Scenario 2) is out.  We the authors decided to keep CUI out of the COA
domain.  But maybe we should put it back in.  Why? In the absence of a
user-identity in the User-Name as in EAP methods we may not be able to use
User-Name since it would be too broad (it will cover all the realm of users
belonging to example.com).  Hmmmm something to think about.

Scenario 3) I think we agree.

So now to the argument of what format of CUI to support:

An opaque CUI will suffice for scenario 2 and 3.  Which are the original
intent of this draft.

At some point later we added other possibilities for CUI.  One driver was to
match Diameter, the other one is that it came from GSMA folks.  A CUI that
is not opaque can server scenario 3 and scenario 1.

So as Jari points out:

"However, looking at the definition of the CUI, it seems
that people want *also* the ability to use a cleartext
user handle of a specific format. One reason for wanting
to do this would be to, say, be able to feed the identity
to an existing roaming/accounting/billing system that can
only support a specific type of an identity. Is this
the reason why we have non-opaque values in the document
too? Or is there some other reason, such as tracing/
legal interception/logging need to see actual user
identities?"

At this point we can go to a CUI that is pure Opaque (like Class) and only
support scenario 3; or
We can allow for the other values and stick the above text in the draft.

Also note that if we stay with Opaque, that would not prevent a SDO like GSM
to specify what is in the CUI blob.  But obviously they would do that only
for their networks.

Lastly, related to the Opaque CUI, is the issue that concerns Barney and
others, and  that is how long is the binding of the Opaque value to the
Identity.

My position was to leave that out but only because I don't think we can
specify this in the IETF.  It would change depending on many circumstances.
Types of networks, bgusiness relationships, etc.  So we let others figure it
out. If anyone has a good answer to this problem please let us know.

We could say that: "When the value is opaque, the lifetime of the binding to
the true identity, is not in scope.  This duration MUST be understood by the
parties, and it SHOULD NOT be long enough to comprimse the user's identity
when privacy is concerned."

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

Yes it is. Does it need to be tightened? Give us some words. Note Identity
is defined to be Chargeable User Identity.  So "Assertion of Chargeable User
Identity".

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

Well so ignoring accounting id. The NAS includes a previously received CUI
in Accounting-Request message as suplemental or alternative information to
User-name.

Okay. But for whom? For the home network? No. For intermediaries perhaps
yes.

But even then, I think the wording of the use case is more accurate this
way:

"The home network provides the CUI as a suplemental or alternative
information to User-Name."

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

Hold on lets reset the converstation. Here it the general behavior:

The RADIUS Client includes the NUL CUI in the Access Request to signal its
requirement for the CUI.
Upon Receiving the NUL CUI, the RADIUS server that owns the user identity
MUST supply the CUI in an Access-Accept.

The RADIUS Client that requested the CUI MUST ensure that it copies the CUI
received in an Access Accept to the Accounting messages associated with that
session.



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

There has been other versions since that may not have hit the street.

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

So usecase one I belive I covered up there.
 
> 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/>
> 

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