RE: Response to Issue 46

["Adrangi, Farid" <farid.adrangi@intel.com>]

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Sunday, January 16, 2005 10:17 PM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org; dnelson@enterasys.com
> Subject: Re: Response to Issue 46 
> 
> 
> As I understand it, this scenario cannot be handled by the User-Name
> attribute when:
> 
> a) The CUI is not a valid NAI
> b) It is necessary for the Authentication-Request and
> Accounting-Request to traverse the same path.
> 
> Are we clear why the Class attribute couldn't be used to handle this
> scenario?  While RFC 2865, Section 5.25 says "The client MUST NOT
> interpret the attribute locally", it doesn't say that the client can't
> store the blob for the purpose of simultaneous usage comparison.
>

Using the class attribute as a comparison is against the intent of 2865.
The client would do the comparison for a reason.  Isn't that a local
interpretation of the class attribute? In this case the reason would be
to extract an alias for the user. 

But even then, Servers that use the class attribute use it for their own
purposes.  Mainly for keeping state etc.  There is no guarantee that the
class attribute wouldn't change between a user's session.  Therefore
this overloading would create a problem for implementations.  They may
have to use multiple class attribute, one for the state maintaining
purpose the other for the indentity alias purpose.

Finally, a client may see many class attributes.  Even if we allowed
clients to use the class attribute as you indicated, which one should it
use?
 
> I think the issue may be that the CUI is potentially usable 
> by accounting
> servers at intermediaries as well as the home accounting 
> server.  This may
> imply something about the CUI, such as that there needs to be a
> unique mapping between a CUI and the actual user.  If so, the document
> should state the requirement.
> 

Isn't the draft say that the CUI is an alias to user's real identity?
Doesn't that mean that there needs to be a unique mapping between CUI
and the actual user?

> 
> 
> On Sun, 16 Jan 2005, Adrangi, Farid wrote:
> 
> > Background:
> > ===========
> > The CUI document define a new RADIUS attribute called a 
> CUI.  The CUI
> > functions as an handle or an alias to a user identity 
> especially when
> > the more traditional user identity attributes (username) do 
> not convey
> > the user identity.  The draft cites one example when this 
> happens mainly
> > EAP methods that hide that hide the identity.
> >
> > As per the document, the CUI is assigned a value by the 
> home network so
> > that entities outside the home network, can have a handle 
> to the user to
> > fulfill certain business scenarios.  The document cites two 
> cases: 1)
> > when an intermediary requires to ensure that a user is only 
> logged in
> > once; and 2) For the purpose of billing mediation.
> >
> > To function as a handle to the user identity, it is suffice 
> that the CUI
> > which is of type string contain an opaque value that is 
> generated by the
> > home network.  This value is an assertion by the home network that
> > represents a unique user in their network.  The only 
> operation that is
> > reasonably allowed to be performed by none home network 
> entities on this
> > attribute therefore is a binary comparison.
> >
> > Are there other use-cases?
> > =========================-
> >
> > As instructed by David Nelson we are seeking any other use-case
> > scenarios that would demonstrate the need to change the 
> content of the
> > CUI, that is would require non-opaqueness; Or ones that 
> would require
> > semantic changes to the current document.   We are not 
> looking for use
> > cases that will further support the current CUI document.
> >
> > If there are such use cases, can you please respond with: 
> "[CUI USECASE]
> > some title" on the list. We will look for consensus to support this
> > scenario.
> >
> > BR,
> > Farid
> >
> 

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