RE: NAI decoration: User Identity issues

["Blair T. Bullock" <bbullock@ipass.com>]

Absolutely agreed, Bernard. Good deal. 

What you describe makes loads of sense and provides a framework for the
necessary flexibility, consistent behavior and reliability when using
mixed standard and tunneled EAP methods.

Thanks y'all for your consideration, 

Blair

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com] 
Sent: Wednesday, July 14, 2004 3:39 PM
To: Blair T. Bullock
Cc: Nakhjiri Madjid-MNAKHJI1; Adrangi, Farid; radiusext@ops.ietf.org
Subject: RE: NAI decoration: User Identity issues

> Hallelujah, I wholeheartedly concur with this statement.  It is 
> basically the same concept as the proposed Class usage for the 
> purposes of user-name accounting data reflection, but specifically 
> dedicated to the resolution of RADIUS-routable and billable identities

> in Tunneled EAP methods.

This is an important distinction because it allows the local ISP to know
that a billable identity has been returned without having to parse the
Class attibute which is supposed to be treated like opaque text.  After
all, multiple Class attributes can be returned, some of which might
represent a billable identity, some might not.  How is the local
operator to know?  So I think a billable identity attribute is required
here.

> the NAS and an Authenticated-User which is the Billable authenticated

The Billable Identity is an identity used for accounting purposes, not
authentication.  I hope we're clear on that.

> from a RADIUS standpoint...  While also maintaining an Authenticator 
> protected billable identity (or alias) which is not transmitted over 
> the air, but represented by the NAS from the value of the User-Name in

> the Access-Accept.

In the case of Privacy, it might not relate to the User-Name attribute
at all.  There is no requirement that they match in any way.

> not pass the user-name back in the Access-accept to maintain the

That is always the RADIUS server choice, because it is optional.

> checking to ensure that the Inner and Outer identities are identical 
> at a 'root' NAI level (regardless of additional chained suffixes or

Careful.  These identities may not relate to each other.




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