[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> 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).
> 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.
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...)
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.
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?
--
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/>