[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Scope of applicability for CUI



Avi,

I don't understand CUI well, but I care about EAP. Doesn't this mean the EAP server and the EAP authentication methods must now support use of CUI as identity and be able to do the conversions? 

Madjid

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior
Sent: Thursday, December 16, 2004 5:14 PM
To: 'Nelson, David'; radiusext@ops.ietf.org
Subject: RE: Scope of applicability for CUI

David,

Sorry for the short reply. I was rushed away. Let me expand.

We already mention in the document that CUI is useable when EAP is used and
in particular when EAP methods hide the user identity.

What I am opposed to is mandating that the only case for CUI is tied to the
use of EAP. Operationaly it does not depend on EAP. There could be other
uses in the future.  So the current text in the draft is sufficient.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Thursday, December 16, 2004 1:29 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Scope of applicability for CUI
> 
> 
> 
> Avi Lior writes...
> 
> > There maybe others that I am not aware of.
> 
> It's hard to design practical and interoperable protocols to 
> meet the requirements of unknown use cases -- so perhaps we 
> can focus on the known ones.
> 
> > But these specific once are the once that we have seen 
> requests for. I 
> > believe these are mentioned in the draft as request by folks here.
> 
> OK.  Since User-Name re-write is considered "evil" in roaming 
> applications, because it changes the routing for RADIUS 
> request traffic, can we assume that only addressing use case 
> (B) is sufficient to meet the current needs?
> 
> If so, how is linking the use of CUI to the use of EAP 
> authentication inappropriate?
> 
> > > A) when the User-Name re-write feature (for accounting
> > > purposes) obscures the original authentication identity, or
> > >
> > > B) when the RADIUS authentication method is EAP, allowing for a 
> > > "method internal" user identity for authentication, and an 
> > > "anonymous" or "routing-only" value in User-Name.
> > >
> > > These use cases are further restricted to multi-party 
> (e.g. roaming
> > > consortia) environments, because for deployments where 
> the NAS and 
> > > the Home RADIUS server belong to a single administrative 
> entity the 
> > > Class attribute has been seen to be sufficient.
> 
> --
> 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/>
> 

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

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