RE: -01 version of Chargeable User Identity

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

I only intended 2 cents, but ended up with a buck fifty and change....

A perspective.

Typically iPass restricts the User-Name in the Access-Accept by policy
because of the emergence and continuing possibility of proxy routing
failures in both dial and Wi-Fi.  While specifically allowed in RADIUS,
and certainly valuable in peer-to-peer arrangements, it causes havoc
with logical peering through mediating networks, particularly when the
inner EAP method is completely negotiated independently by the peer and
H.A.S.  

Which is okay!  This was never really a problem until tunneled EAP
methods introduced the second Identity, yah.   So for any provisioned
WPA service we have to audit the capability of each network and ensure
that this capability is known and supported wherever tunneled methods
are to be used for any Public Access service.  That is the challenge,
Greg.

For supplying UAM/GIS service or RAS narrowband, this doesn't really
matter (unless you are using EAP) since there is only a single Identity
and the billable subscriber can always be derived by the NAI post-facto;
therefore such cases we just filter the User-Name return in the
Access-Accept to guard against User-Name re-write and route failure.

However the spec is word-smithed, for many well established systems to
remain remotely stable for legacy radius proxy roaming involving
aggregation and mediation, the *User-Name must never be modified* unless
explicit knowledge of the supplier access arrangement is known.  Without
it, a Home Network won't always get a copy of their own acct due to
their own Access-Accept into a heterogeneous source-routed (by
necessity) proxy network.  Ergo if there is a need to expose the inner
EAP Identity (or alias of the authorizing profile), you must include it
in some attribute of the RADIUS accounting...but not the User-Name.

In sum, if you want to muck with the user-name on the
Access-Accept...you can't, thereby you must put it in the Chargeable
User Identity alias. Those networks who do overwrite the
User-Name...don't pass them one in an Access-Accept.  And for any
reasonable semblance of service oversight or fraud detection beyond the
Home Authentication Server's log, networks would be wise to ensure and
verify this Chargeable Alias feature is available for any WPA network
intending to use a tunneled EAP.  =^)   When a User-Name is returned, it
must go into the Chargeable Identity or get dropped, but the originally
(decorated and presented) User-Name must remain untouched to maintain
legacy RADIUS and OSS support.  That is truly our challenge as a VNO,
but we can't operationally approach an end-to-end EAP service without
the feature.  The added benefit is that now we can decorate the NAI
however we all want to!  =^))

There are some reasonable alternatives which iPass implement, but none
are as good as this proposal for handling multiple ID AAA and not
everybody has our advanced policy and privacy features.

Rambling, 

Blair


-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Greg Weber
Sent: Tuesday, October 12, 2004 4:40 PM
To: farid.adrangi@intel.com
Cc: radiusext@ops.ietf.org; bernarda@windows.microsoft.com;
david.mariblanca@ericsson.com
Subject: Re: -01 version of Chargeable User Identity


Hi Farid,
A question on how -01 attempts to resolve a particular
part of issue #14.

  From -00:
                       The NAS or the access network AAA server MUST 
      include  this  attribute  in  the  Accounting  Requests  (Start, 
      Interim, and Stop) messages if it was included in the Access 
      Accept message. 
  
  From #14:
      [BA] I don't understand how backward compatibility is achieved. 
      How is a RADIUS server to know whether the NAS supports the CUI 
      attribute?

  -01 adds:
      In cases where the home RADIUS server cannot determine the NAS 
      support for CUI attribute, it MUST send both the UserName (1) 
      attribute and CUI attribute, with the understanding that if the 
      NAS supports the CUI attribute the CUI attribute will override 
      the identity portion the UserName (1) attribute.  That is, the 
      UserName(1) attribute will be used for routing and the CUI 
      attribute will be used for identity purposes. 

But the additional text does not obviate the still existing
excerpt from the -00 draft.  -01 still says that the NAS
MUST send the new attribute if it is received and that is 
a compatibility problem.

Greg

> 
> Hi all,
> The version -01 should appear on ID repository soon.  In the mean
time,
> you can access the draft here :
>
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-chargeable-use
> r-id-01.txt.
> 
> The -01 update addresses the two issues (issue 13 and 14) submitted
> against the draft by David and Bernard respectively - please see
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed
> descriptions of the issues.
> 
> 
> Bernard,
> 
> Regarding two of your comments,
> 
> - Made a clarification on encoded format for CUI string.  But, we
> weren't sure if you were also questioning the proposed
> XX:YYYYYYYYYY format rather than just NAI or other encoding supported
by
> Username.   
> 
> - Diameter translation /CoA message comment, are you suggesting to
> prohibit the user of the attribute in COA/Disconnect message?  Please
> note that the CUI is for identifying the user session than username.  
> 
> BR,
> Farid
> 
> --
> 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/>