Re: Response to Issue 46

[Bernard Aboba <aboba@internaut.com>]

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.

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.



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