Network Working Group                                         F. Adrangi
Internet-Draft                                                     Intel
Expires: June 29, July 5, 2005                                            A. Lior
                                                     Bridgewater Systems
                                                             J. Korhonen
                                                             J. Loughney
                                                       December 29, 2004
                                                            January 2005

                        Chargeable User Identity

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 29, July 5, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).


   This document describes a new RADIUS attribute,
   Chargeable-User-Identity.  This attribute can be used by a home
   network to identify a user for the purpose of roaming transactions
   that occur outside of the home network.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3  4
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Chargeable-User-Identity (CUI) Attribute . . . . . . . . .  5
   3.  Attribute Table  . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Diameter RADIUS Interoperability Consideration . . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
     5.1   CUI RADIUS Attribute . . . . . . . . . . . . . . . . . . .  7
     5.2   Error-Cause Attribute  . . . . . . . . . . . . . . . . . .  7  8
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1   Normative references . . . . . . . . . . . . . . . . . . .  8
     8.2   Informative references . . . . . . . . . . . . . . . . . .  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . . . 11

1.  Introduction

   Some authentication methods, including EAP-PEAP,  EAP-TTLS, EAP-SIM
   and EAP-AKA, can hide the true identity of the user from RADIUS
   servers outside of the user's home network.  In these methods, the
   User-Name(1) attribute contains an anonymous identity (e.g., sufficient to route the RADIUS packets to the home
   network but otherwise insufficient to identify the user.  While this
   mechanism is good practice in some circumstances, there are problems
   if local and intermediate networks require a user identity identity.

   This document introduces an attribute that serves as an alias or
   handle (hereafter, it is called Chargeable-User-Identity) to the real
   user's identity.  Chargeable-User-Identity can be used outside the
   home network in order scenarios that traditionaly relied on User-Name(1) to enforce usage policies.
   correlate a session to a user.

   For example, local or intermediate networks may limit the number of
   simultaneous sessions for specific users; they may require a
   Chargeable-User-Identity in order to demonstrate willingness to pay
   or otherwise limit the potential for fraud.

   This implies that an authenticated and unique identity provided by
   the home network should be able to be conveyed to all parties
   involved in the roaming transaction for correlating the
   authentication and accounting packets.

   Providing a unique identity, called the Chargeable-User-Identity
   (CUI) (CUI), to
   intermediaries, is necessary to fulfill certain business needs.  This
   should not undermine the anonymity of the user.  The mechanism
   provided by this draft allows the home operator to meet these
   business requirements by providing a temporary identity representing
   the subscriber and at the same time protecting the anonymity of the

1.1  Motivation

   When the home network assigns a value to the CUI, it asserts that
   this value represents a user in the home network.  The assertion
   should be temporary.  Long enough to be useful for the external
   applications and not too long such that it can be used to identify
   the user.

   Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
   IRAP, have been studying mechanisms to provide roaming services,
   using RADIUS.  A  One missing element is a mechanism for providing the
   current deployments with the capacity to deploy, bill and oversee WPA
   networks against fraud.

   The CUI attribute has been designed is intended to close operational loopholes in
   RADIUS specifications that have impacted roaming solutions
   negatively, especially when tunneled protocols with multiple
   identities, such as PEAP or TTLS, are used.  Use of the CUI is geared
   to multi-identity EAP authentications which are, for the most part,
   recent deployments.  A chargeable identity reflecting the user
   profile authenticated by the home network is needed in such roaming

   The CUI support by RADIUS infrastructure is driven by the business
   requirements between roaming entities.  Therefore whether a RADIUS
   server/proxy or client accepts or rejects the presence or lack of
   presence of the CUI attribute is a matter of business policy.

1.1  Motivation

   Some other mechanisms have been proposed in place of the CUI
   attribute.  These mechanisms are insufficient or cause other
   problems.  It has been suggested that standard RADIUS Class(25) or
   User-Name(1) attributes could be used to indicate the
   Chargeable-User-Identity. CUI.  However,
   in a complex global roaming environment where there could be one or
   more intermediaries between the NAS and the home RADIUS server, the
   use of aforementioned attributes could lead to problems as described

      - On the use of RADIUS Class(25) attribute:

      [RFC2865] states: "This Attribute is available to be sent by the
      server to the client in an Access-Accept and SHOULD be sent
      unmodified by the client to the accounting server as part of the
      Accounting-Request packet if accounting is supported.  The client
      MUST NOT interpret the attribute locally."  So RADIUS clients or
      intermediaries MUST NOT interpret the Class(25) attribute, which
      precludes determining whether it contains a CUI.  Additionally,
      there could be multiple class attributes in a RADIUS packet with
      unspecified ordering, which packet, and
      since the contents of Class(25) attribute is not to be interpreted
      by clients, this makes it hard to the entities outside home
      network to determine which one contains the CUI.

      - On the use of RADIUS User-Name(1) attribute:

      The home network could use User-Name(1) attribute included in the Access-Accept
      message to convey the CUI to intermediaries and the NAS.  However,
      as Access-Request may be
      used for the Access-Accept packet is routed to purpose of routing the NAS, Access-Request packet, and in
      the User-Name(1)
      attribute could process may be (completely) rewritten by intermediaries.  As a result, a
      RADIUS server receiving an intermediary and
      therefore the NAS or other intermediaries along the way will not
      have access to the CUI.  Furthermore, Access-Request packet relayed by a
      proxy cannot assume that the NAS may use User-Name(1) attribute remained
      On the original
      value other hand, rewriting of the a User-Name(1) attribute (the one sent in the
      within an Access-Accept packet occurs more rarely, since a
      Proxy-State(33) attribute can be used to route the Access-Accept
      packet without parsing the User-Name(1) attribute.  As a result, a
      RADIUS server cannot assume that a proxy stripping routing
      information from a User-Name(1) attribute within an Access-Request packet)
      will add this information to a User-Name(1) attribute included
      within an Access-Accept.  The result is that when a User-Name(1)
      attribute is sent in an Access-Accept it is possible that the
      Access-Request and Accounting-Request packets will follow
      different paths.  Where this outcome is undesirable, the RADIUS
      client should use the original User-Name(1) in accounting packets.
      Therfore, another mechanism is required to convey a CUI within an
      Access-Accept packet to ensure the billing follows RADIUS client, so that the same path as authentication CUI can be
      included in the accounting packets.

   The CUI attribute provides a solution to the above problem and avoids
   overloading the use of current RADIUS attributes (e.g., User-Name(1)
   re-write).  The CUI is the correct standards-based approach to fixing
   the problems which have arisen with multiple-identity RADIUS
   authorization and accounting methods.  It does not solve all related
   problems, but does provide networks the ability to bill and oversee
   WPA networks against fraud.  When the home network assigns a value to
   the CUI, it asserts that this value represents a user in the home
   network.  The assertion should be temporary.  Long enough to be
   useful for the external applications and not too long such that it
   can be used to identify the user.

1.2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

      3GPP - Third Generation Partnership Program
      AAA - Authentication, Authorization and Accounting
      CUI - Chargeable-User-Identity
      GSMA - GSM Association
      IRAP -  International Roaming Access Protocols Program
      NAS - Network Access Server
      PEAP - Protected Extensible Authentication Protocol
      TTLS - Tunneled Transport Layer Security
      WISPr - Wireless ISP Roaming
      WPA -  Wi-Fi Protected Access

2.  Operation

   This document assumes that the RADIUS protocol operates as specified
   in [RFC2865], [RFC2866], dynamic authorization as specified in
   [RFC3576], and the Diameter protocol as specified in [RFC3588].

2.1  Chargeable-User-Identity (CUI) Attribute


   The CUI attribute serves as an alias to the user's real identity.  It is identity,
   representing a chargeable identity as defined and provided by the
   home network as a suplemental supplemental or alternative information to
   User-Name(1).  Typically the CUI represents the identity of the
   actual user but it may also indicate other chargeable identities such
   as a group of users.  RADIUS clients (proxy or NAS) outside the home
   network MUST NOT modify the CUI attribute.

   In accordance to business policies, the

   The RADIUS server (a RADIUS proxy, home RADIUS server) may include
   the CUI attribute in the Access-Accept message packet destined to a roaming
   partner.  The CUI support by RADIUS infrastructure is driven by the
   business requirements between roaming entities.  Therefore whether a
   RADIUS server/proxy or client accepts or rejects the presence or lack
   of presence of the CUI attribute is a matter of business policy.

   If an Access-Accept message packet without the CUI attribute was received by
   a RADIUS client (NAS or Proxy) that requires the presence of the CUI
   attribute, then the Access-Accept message packet MAY be treated as an
   Access-Reject message packet based on local policies.

   If the CUI was included in the Access-Accept message, packet, RADIUS client
   (Proxy or NAS) that supports the CUI attribute MUST ensure that the
   CUI attribute appears in the RADIUS Accounting-Request (Start,
   Interim, and Stop).

   RFC 2865 includes the following statements about behaviors of RADIUS
   client and server with respect to unsupported attributes:

      - "A RADIUS client MAY ignore Attributes with an unknown Type."
      - "A RADIUS server MAY ignore Attributes with an unknown Type."

   Therefore, RADIUS client (Proxy or NAS) server that does not support the CUI attribute
   MAY ignore this attribute or MAY treat the Access-Accept as
   attribute MAY ignore this attribute.

   If RADIUS client (Proxy or NAS) requires the presence of the CUI
   attribute in the Access-Accept, it MUST indicate its requirement by
   including this the CUI attribute in the Access-Request packet with a value
   set to the nul character for its data field (hereafter, it is also referred to as a nul CUI) in the
   Access-Request message.

   If a home RADIUS server that supports the CUI attribute receives an
   Access-Request containing a CUI (set to nul CUI, or otherwise), it MUST
   include the CUI attribute in the Access-Accept.  Otherwise, if the
   Access-Request does not contain a null CUI, the home RADIUS server MUST
   NOT include the CUI attribute in the Access-Accept.

   A RADIUS server (a RADIUS proxy or the home RADIUS server) that
   requires the presence of the CUI in the Accounting-Response messages Accounting-Request packets
   (Start, Stop, Interims) MAY respond with an Access-Reject message packet if
   it receives an Access-Request messsage from a RADIUS client, or proxy
   chain that
   does not support the CUI attribute.  The Access-Reject
   message packet MUST
   include Error-Cause attribute [RFC3576] with value (to-be-defined)
   (decimal), "CUI-Support-Required".

   If the NAS supports CUI attribute then the CUI attribute MAY also be
   used as one of the identity attribute in Disconnect Message and
   Change of Authorization messages defined by [RFC3576].  Determination
   of NAS support for the CUI is outside the scope of this document.

   A summary of the RADIUS CUI Attribute is given below.

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |     Type      |    Length     | String...

   Type: TBD for Chargeable-User-Identity.

   Length: >= 3


      The string identifies the CUI of the end-user and is of type
      UTF8String.  This string value is a reference to a particular
      user.  The format and the interpretation of the string value , and
      the binding lifetime of the reference to the user is determined
      based on business agreements.  For example, the lifetime can be
      set to one billing period.  In cases where the attribute is used
      to indicate the NAS support for the CUI, the string value contains
      a nul character.

3.  Attribute Table

   The following table provides a guide to which attribute(s) may be
   found in which kinds of packets, and in what quantity.

   Request Accept Reject Challenge Accounting  #  Attribute
     0-1     0-1     0       0        0-1       TBD   Chargeable-User-identity
     0       0       0-1     0        0         101   Error-Cause

   [Note 1] If the Access-Accept contains CUI then the NAS MUST include
   the CUI in Accounting Requests (Start, Interim and Stop) packets.

   [Note 2] The Error-Cause attribute is defined in [RFC3576].

   Change of Authorization and Disconnect-Request
   Request      ACK      NAK   #    Attribute
      0-1       0        0     TBD  Chargeable-User-Identity

   [Note 3] Where CUI attribute is included in Disconnect-Request or
   CoA-Request messages, it is used for session identification purposes
   only.  This attribute MUST NOT be used for purposes other than
   identification (e.g.  within CoA-Request messages to request
   authorization changes).

4.  Diameter RADIUS Interoperability

   In deployments with both RADIUS and Consideration

   Diameter interworking, a
   translation agent will be deployed and operate in accordance needs to define an identical attribute with the same Type
   value.  The CUI should be available as part of the NASREQ specification.

5.  IANA Considerations

5.1  CUI RADIUS Attribute

   This document uses the RADIUS [RFC2865] namespace, see
   "".  This document
   instructs IANA to assign a new RADIUS attribute number for the CUI

         CUI		   TBA

5.2  Error-Cause Attribute

   This document instructs IANA to assign a new value for Error-Cause
   attribute [RFC3576],

         "CUI-Support-Required"     TBA

6.  Security considerations

   The CUI attribute must be protected against Man-in-the-Middle
   attacks.  The CUI appears in Access-Accept and Accounting-Requests
   packets and is protected by the mechanisms that are defined for
   RADIUS [RFC2865] and [RFC2866].  Therefore there are no additional
   security considerations beyond those already identified in [RFC2865]
   and [RFC2866].

   Message-Authenticator(80) and Event-Timestamp(55) can be used to
   further protect against Man-in-the-middle attacks.

   It is strongly recommended that the CUI form format used is such that the
   real user identity is not revealed.  Furthermore, where a reference
   is used to a real user identity, the binding lifetime of that
   reference to the real user be kept as short as possible.

   The RADIUS entities (RADIUS proxies and clients)outside the home
   netowrk MUST NOT modify the CUI.  However, there is no way to detect
   or prevent this.

   If the NAS includes CUI in an Access-Request.  A man in the middle
   may remove the CUI attribute from the Access-Request.  The result is
   that the Access-Accept will not have a CUI which will cause the NAS
   to reject the session resulting in a DOS attack.  To prevent this
   attack, the NAS SHOULD include Message-Authenticator(80) in the
   Access-Request packets that contain a CUI.

7.  Acknowledgements

   The authors would like to thank Jari Arkko, Bernard Aboba, David
   Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith,
   David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson, for
   their feedback and guidance.

8.  References

8.1  Normative references

   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

              Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
              Network Access Identifier",
              draft-arkko-roamops-rfc2486bis-02 (work in progress),
              Internet-Draft draft-arkko-roamops-rfc2486bis-02, July

8.2  Informative references

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

Authors' Addresses

   Farid Adrangi
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR  97124

   Phone: +1 503-712-1791

   Avi Lior
   Bridgewater Systems Corporation
   303 Terry Fox Drive
   Ottawa, Ontario  K2K 3J1

   Phone: +1 613-591-9104
   Jouni Korhonen
   Teliasonera Corporation
   P.O.Box 970
   FIN-00051,   Sonera

   Phone: +358405344455

   John Loughney
   Itamerenkatu 11-13
   FIN-00180,   Helsinki

   Phone: +358504836342

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004). (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.