RE: Scope of applicability for CUI (was: RE: AW: backwards compa tible introduction of NEW attribute such as CU I)

[Avi Lior <avi@bridgewatersystems.com>]

David,

There maybe others that I am not aware of. 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.

Avi.

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Thursday, December 16, 2004 1:07 PM
> To: radiusext@ops.ietf.org
> Subject: Scope of applicability for CUI (was: RE: AW: 
> backwards compatible introduction of NEW attribute such as CU I)
> 
> 
> Avi Lior writes...
> 
> > I stated this in another email but I want to do it here as well.  I
> don't
> > think that CUI should be tied down to 3579.
> 
> CUI is only *needed* when User-Name doesn't serve the 
> purpose.  What are the use cases when User-Name isn't 
> sufficient?  I think they are:
> 
> 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.
> 
> Are there any other relevant use cases?
> 
> 
> 
> --
> 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/>