[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>