[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Scope of applicability for CUI
From: Jari Arkko [mailto:email@example.com]
Sent: Saturday, December 18, 2004 3:21 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Avi Lior'; 'Nelson, David'; firstname.lastname@example.org
Subject: Re: Scope of applicability for CUI
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.
Madjid>>I thought user-aliases were needed during EAP to locate the TTLS server (or AAAH server for the user), no?
Why would the TTLS server need to send the CUI to the NAS?
The TTLS server knows which NAS the EAP signaling is coming from. The NAS knows which the user the request is coming from through L2 addressing methods. Did I miss something?
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.