Re: Scope of applicability for CUI

[Jari Arkko <jari.arkko@piuha.net>]

Nakhjiri Madjid-MNAKHJI1 wrote:
> Hi Avi,
>
> I agree with most of what you are saying. I guess I know understand the point "EAP cannot be the only use case for CUI). I can think one example where CUI would not even work with EAP. The way I understand it, EAP-TTLS uses a model where a TTLS server that can be different from the AAAH of the client establishes a TLS session with the client. The purpose of TLS is to protect the user identity/ authentication. So in the early stage of EAP you need to use a pseudo identity. If the AAAH is the only place that understands that pseudo identity, then you are in trouble, because the TLS is established with the TTLS server and not with the AAAH. AAAH only comes in place when the client is authenticating. The TTLS server does not know the CUI. So in that case you can't even use CUI as an alias.

This is an interesting issue. But presumably *some* server
will eventually learn the true user identity. If this server
is the TTLS server, it can use CUI to inform the NAS. If this
server is someone else, that server and the TTLS server need
to communicate first so that the TTLS server can send the CUI
to the NAS.

This also implies that the CUI is something that can be learned
very late in the process, perhaps even as late as in the Access-Accept.

By the way, what would be the meaning of CUI for "pay as you go"
type of approaches, e.g., micropayments or the like over EAP?
There might not be any billable user identity; the only thing
that could be provided in those cases is some kind of a session
identifier so that the home AAA and the NAS can correlate their
accounting records.

--Jari

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