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

[Jari Arkko <[e-mail]>]

Hi Farid,

>>Here's what RFC 3579 says: "The User-Name attribute within the Access-
>>Accept packet need not be the same as the User-Name attribute in the
>>Access-Request."
>>
>>I wonder if this could be used to implement the functionality that
>>you want, without adding a new attribute. But you could still
>>include the explanation of the problem and guidelines for the
>>servers.
>>
> 
> Good question.  We had a long discussion on this subject amongst GSMA
> delegates.  In summary, the decision was made not to use UserName(1)
> rewrite because:
> 
> 1) Some NASes may not like user-name rewriting
> 2) Need for a structured identity for indicating user's chargeable
> identity
> 3) Avoid overloading the UserName(1) attribute for this purpose

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

   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?
   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"? 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?
   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.

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

   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.

--Jari

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>