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

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

Hi Jari,
Sorry for a late reply -- catching up with my e-mails.  Thanks for your
good questions -- please see my responses inline.
BR,
Farid


> 
> Ok. Let me go into a bit more depth here. Lets
> look at the issues one at a time:
> 
> "Some NASes may not like user-name rewriting"
> 
>    Fair enough. This may well be the case. Let me try to
>    understand why, and talk about the potential alternative
>    solutions and what makes them better in this respect.
> 
>    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.

> 
>    It seems like the functionality we are talking about
>    could be applied either in the context of EAP (RFC 3579)
>    or web-based logins (plain RADIUS). Are these problems
>    common in both cases or just in one?

It applies to all scenarios where user's real or billable identity is
not revealed to the NAS by the user.

> 
>    Am I correct in assuming that if the context is EAP usage,
>    then a NAS which would be unable to support a rewritten
>    username would be uncompliant per requirements of RFC 3579?

RFC3579 does not mandate supporting user-name(1) rewrite so in my mind
it won't make it uncompliant. No?

>    It seems so, from Section 3. Now, I really don't want to
>    say that RFC 3579 is 100% right here -- it could well be that
>    this requirement should not have been there. However, I'd
>    like to ensure that the addition of the User Alias Identity
>    attributes helps solve the problem. I think the question
>    is "does the NAS vendor have to do something to get solution
>    X working in his product"?

Not really.  Because, this attribute can be handled by the access
network AAA proxy if the software update to NAS is not feasible.

> Presumably, the action to make
>    the User-Name approach work is to add code to read the
>    incoming User-Name from an Access-Accept and make it be
>    sent on accounting requests. Is there a similar code
>    change for User Alias Identity, or will all currently
>    unknown attributes be copied to the accounting requests?

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.  

>    I tried to look at RFCs 2866 and 2869 but I did not find
>    a clear answer... but it would seem logical to copy all
>    attributes.
> 
> "Need for a structured identity for indicating user's 
> chargeable identity"
> 
>    Right now, the chargeable identity has normally been the User-Name.
>    But I do agree that divorcing the identity used in the 
> authentication
>    process -- which may be a specific temporary identity to 
> begin with --
>    and the accounting identity would be useful. However, I'd like to
>    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.

Please see my response above.

> 
>    The second issue I'd like to have a better understanding and better
>    text on is the privacy issue. I think the privacy issues within the
>    authentication identity and the accounting identity are somewhat
>    separate; in the former we are most concerned about 
> over-the-wireless
>    privacy. But I would also like to avoid telling the cleartext or
>    trackable user identity to a zillion access points attached to
>    coffee shop walls. 

You are right.  But, operators have a choice to indicate an opaque
identity that makes the user untrackable.  

>I think that boils down to suggesting in the
>    document that the accounting identity should be hidden somehow.
>    This is what you said in your response, but maybe we
>    could write it to the document as well.

I agree.  I Will make this clear in the next update.

> 
>    Finally, I would note that since the routing of the 
> Accounting-Request
>    packets is based on the User-Name domain part, it would appear that
>    the User-Name needs to be kept there as well.

Absolutely. We are not changing the behaviour or use the UserName(1)
attribute.
> 
> --Jari
> 
> --
> 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/>