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

["Adrangi, Farid" <farid.adrangi@intel.com>]

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