RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)

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

iPass decorates the NAI via our Smart-Client/Supplicant to provide an
identity that navigates the local RADIUS infrastructure to select our
AAA exchange for purposes of mediated access.  This decoration is
independent from any customer-level decorations to navigate to the Home
AAA or via a reseller arrangement.  

The Accounting User-Name attribute replacement, returning the inner
identity, completely breaks the ability for the accounting messages to
follow the same path that the authentication events took based on the
promiscuous decoration of the NAI to form supply arrangements, basically
dropping them on the floor.  

Using the last revision of the AP firmware, all is well... but a simple
upgrade and all accounting stops unless a domain-specific or DEFAULT
route is used to capture them (which is worse than the cure).  Whoops!
Therefore, in order to maintain the initially provided NAI decorations
(which we can resolve since we put them there), we must not pass back
the User-Name in the Access-Accept even though it is highly recommended.

The question is, is this an acceptable control of this function, simply
allowing the User-Name to return in the Access-Accept where we can be
assured of proper accounting transmission, but then not include the
User-Name when keeping the originally presented NAI is required to
navigate mediated roaming exchanges by a decoration other than those
provisioned or controlled by the Home Authentication Server (who is
consuming the network, but not necessarily decorating an NAI for
purposes of footprint aggregation or mediated roaming services). 

-Blair

-----Original Message-----
From: Adrangi, Farid [mailto:farid.adrangi@intel.com] 
Sent: Tuesday, June 15, 2004 1:43 AM
To: Bernard Aboba
Cc: jari.arkko@piuha.net; radiusext@ops.ietf.org
Subject: RE: User Alias Identity (Was: Re: comments on
draft-adrangi-radius-attributes-extension-00.tx)

Hi Bernard,
Thanks for your comments and questions. Please see my responses inline.
BR,
Farid

> 
> > >    So, presumably the NASes were not prepared for the
> > >    possibility that the User-Name attribute might change.
> > >    Do they actually break, or is it just that they ignore
> > >    the User-Name attribute when it comes back?
> >
> > It will break the billing functionality according to the information

> > that we got from GSMA vendors.
> 
> Can you explain what this means?  Does the NAS crash?  Send an 
> accounting record with the User-Name sent in the Access-Request 
> instead?  Do something else?  Perhaps we should hear directly from the

> vendors in question about how they handle this.
> 

One type of failure is that the NAS discards the User-Name (rewritten)
in the Access-Accept.  I am not in a position to provide any vendor's
name here -- but all I can say GSMA has included this attribute in the
EAP-SIM roaming guidelines, and it was already implemented by all
vendors participated in the GSMA EAP-SIM trial.   Jouni Korhonen (the
editor of GSMA's EAP-SIM roaming guidelines) can provide more
information if needed.

> Remember that RFC 2865 enables inclusion of the User-Name attribute in

> an Access-Accept, so that compliant RADIUS client implementations need

> to be able to deal with this:
> 
>    Request   Accept   Reject   Challenge   #    Attribute
>    0-1       0-1      0        0            1   User-Name
> 

RFC 2865 does not say anything about the UserName(1) rewrite.  Please
see below for more ...

> > It applies to all scenarios where user's real or billable
> identity is
> > not revealed to the NAS by the user.
> 
> RFC 3579 contains the same entry as RFC 2865 with respect to
> User-Name:
> 
> Request  Accept  Reject  Challenge   #    Attribute
> 0-1      0-1     0       0            1   User-Name
> 

Please see my response below to the specific text in RFC 3579.

> > RFC3579 does not mandate supporting user-name(1) rewrite so
> in my mind
> > it won't make it uncompliant. No?
> 
> Here is what RFC 3579 says:
> 
> "In order to permit forwarding of the Access-Reply by EAP-unaware 
> proxies, if a User-Name attribute was included in an Access-Request, 
> the RADIUS server MUST include the User-Name attribute in subsequent 
> Access-Accept packets. Without the User-Name attribute, accounting and

> billing becomes difficult to manage.  The User-Name attribute within 
> the Access-Accept packet need not be the same as the User-Name 
> attribute in the Access-Request."
> 

I think this is the source of the problem -- the RFC 3579 is not clear
about whether a NAS should include the UserName (1) value received in
the AccessAccept rather than the one was orginally sent in the
Access-Accept packet in the accounting request. 


> So I'd say that a RADIUS client needs to support User-Name in an 
> Access-Accept and also needs to be prepared for user-name rewrite.
> 

Again the RFC is not clear which UserName value should be used by the
NAS.

> > The difference in the amount of code changes required by these two 
> > methods is not the core issue.  The main goal is to provide
> a solution
> > that can be deployment without any changes to NAS, and without 
> > disturbing the current use of User-Name(1) -- i.e., GSMA 
> > vendors/operators don't want to overload the use of UserName(1) or 
> > create conflicts/incompatibilities.
> 
> This seems like one of several areas in which there are 
> interoperability issues with current RADIUS implementations.  Where 
> there are interoperability problems, it is typically required for 
> *some* implementation to change.  The purpose of the "RADIUS 
> Implementation Errors and Fixes" document is to document these 
> problems and propose solutions.
> 
> > >    ensure that the above NAS-need-not-be-changed properties can
> > >    be achieved if we move into this separation. That is, I'd like
> > >    to understand how this works in a backwards compatible manner
> > >    without requiring updates to the NASes.
> 
> I don't see how this can possibly be implemented without changing 
> NASes.
> Since this is an interoperability issue, the problem isn't "does 
> someone have to change" -- but rather "what  should change" and "how".
> 
> 
This can be handled by the access network AAA proxy.

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