[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

   Network Working Group                            Farid Adrangi
   INTERNET DRAFT                                   Intel Corporation
   Category: Informational (or standards?)          Avi Lior
   Expires: Feb 7, 2005                             Bridgewater Systems
                                                    Jouni Korhonen
                                                    Sept 7, 2004
                            Chargeable User Identity
   Status of this Memo
        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026.
        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.
        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 document describes a new RADIUS attribute used by a home RADIUS
   to indicate Chargeable User Identity to all parties involved in the
   roaming transaction outside the home network.
   Table of Contents
   1. Introduction...................................................2
   1.1 Requirements language..........................................3
   2. Operation.......................................................3
   2.1 Chargeable User Identity Attribute.............................3
   3. Diameter RADIUS Interoperability................................5
   4. IANA Considerations.............................................6
   5. Security Considerations.........................................6
   6. Acknowledgements................................................6
   7. References......................................................6
   Adrangi, et al.          Expires Dec 16, 2004             [Page 1]

   Internet Draft   RADIUS Chargeable User Identity       7 Sept 2004
   AuthorsÆ Addresses.................................................7
   1. Introduction
     In certain authentication methods such as, EAP-PEAP or EAP-TTLS,
     EAP-SIM, and EAP-AKA, the true identity of the subscriber can be
     hidden from the RADIUS AAA servers outside the subscriberÆs home
     network.  In these methods the User-Name(1) attribute contains an
     anonymous identity (e.g., anonymous@example.com) sufficient to
     route the RADIUS packets to the home network but otherwise
     insufficient to identify the subscriber.  While this mechanism is
     good practice there are situations where this creates problems:
     -     In certain roaming situations intermediaries and visited
     network require to be able to correlate an authentication session
     with a user identity known to the userÆs home network for fraud
     detection and revenue assurance.  For example, a broker may
     require to implement a policy where by only one session is allowed
     per user entity, or third party billing brokers may require to
     match accounting records to a user identity.
     -     NAS may require to match the user session and accounting
     records to a user identity known to the userÆs home network for
     future use û for example, charging dispute.
     This basically implies that a unique identity known by the home
     network needs to be conveyed to all parties involved in the
     roaming transaction.
     Providing a unique identity to intermediaries is therefore a
     requirement to fulfill certain business needs.  This fulfillment
     need not undermine the need to protect the anonymity of the user.
     The mechanism provided by this draft allows the home operator to
     meet these business requirements by providing a temporal identity
     representing the subscriber and at the same time protecting the
     anonymity of the subscriber.
     Standard RADIUS Class(25) or User-Name(1) attributes could be used
     to indicate the CUI.  However, in a complex global roaming
     environment where there could be one or more intermediary between
     the NAS and the home RADIUS server, the use of aforementioned
     attributes could lead to problems as described below.
        O RADIUS Class (25) is intended to be opaque to entities
        outside the home network.  It is known and interpreted by the
        home RADIUS server.  This combined with the fact that there
        could be multiple class attributes or it could contain other
        data than a chargeable identity, would make it impossible for
   Adrangi, et al.        Expires February 7, 2005           [Page 2]

   Internet Draft   RADIUS Chargeable User Identity       7 Sept 2004
        the entities outside the home network to identify which class
        attributes contains a chargeable identity.
        O Use of RADIUS UserName(1) would be a problem, because it
        could be rewritten by the intermediaries.  Furthermore,
        subsequent accounting request may fail to route through the
        intermediary exchanges due to the lack of decoration knowledge
        by the home network.
     The Chargeable User Identity (CUI) attribute provides a solution
     to the above problem and avoids overloading the use of current
     RADIUS attributes (e.g., UserName(1) re-write).  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 to such that it can be used to identify the user.
   1.1 Requirements language
      In this document, several words are used to signify the
      requirements of the specification.  These words are often
      capitalized.  The key words "MUST", "MUST NOT", "REQUIRED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in [RFC2119].
   2. Operation
     This document assumes that the RADIUS protocol operates as
     specified in [1, 2] and that the Diameter protocol operates as
     specified in[RFC 3588, NASREQ].
   2.1 Chargeable User Identity Attribute
      This attribute serves as an alias to the userÆs identity. It is
      assigned by the home RADIUS server and MAY be sent in Access-
      Accept message.  The NAS or the access network AAA server MUST
      include  this  attribute  in  the  Accounting  Requests  (Start,
      Interim, and Stop) messages if it was included in the Access
      Accept message.  Entities (e.g., NASes, proxies) outside the home
      network MUST NOT modify the Chargeable User Identity attribute.
      If the RADIUS server includes this attribute in an Access-Accept
      message it MAY also use this attribute as one of the identity
      attributes in a Disconnect Message and Change of Authorization
      message defined by [4].
   Adrangi, et al.        Expires February 7, 2005           [Page 3]

   Internet Draft   RADIUS Chargeable User Identity       7 Sept 2004
      A summary of the RADIUS Chargeable User Identity 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...
           Chargeable User Identity
           To be assigned by IANA
           >= 6
           The string field is four or more octets. This non-NULL
           terminated string consists of two colon separated parts. The
           first part determines the Chargeable-User-Identity type and
           the  second  part  is  the  actual  Chargeable-User-Identity
           value. The Chargeable-User-Identity type is coded as two
           octet string. The Chargeable-User-Identity value must be at
           least one octet.
           The following User-Identity Alias types have been defined:
           00 û reserved
           01 û IMSI
                  The is in international IMSI format according to the
                  ITU-T E.212 numbering plan as defined in [8] and
           02 û NAI
                  The identifier is in the form of a Network Access
                  Identifier as defined in [5].
           03 û E.164 number
                  The  identifier  is  in  international  E.164  format
                  (e.g. MSISDN, according to the ITU-T E.164
                  numbering plan as defined in [6] and [7]).
           04 û SIP URL
                  The identifier is in the form of a SIP URI as defined
                  (as defined in [10]).
           05 û Opaque string
                  Opague string is a value that is assigned to the user
                  by the home network in an unspecified format. where
   Adrangi, et al.        Expires February 7, 2005           [Page 4]

   Internet Draft   RADIUS Chargeable User Identity       7 Sept 2004
                  the home network asserts that this value represents a
                  particular user û itÆs a handle to the user.
           The length of time for which the Chargeable User Identity is
           valid is unspecified by this specification and typically
           would be long enough to serve some business needs and short
           enough such that it minimizes the chance of revealing the
           true identity of the user (either directly or indirectly).
           Below are examples of User Identity Alias strings with NAI
           and E.164 Charging Types:
           Ideally, the real user identity should not be revealed
           through this attribute.  However, the operators will have
           the final word on the used charging type and its identifier.
     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      0-1     0       0        0-1       TBD  Chargeable User ID
   [Note 1] If the Access Accept contains Chargeable-User-Identity then
   the NAS MUST include the Chargeable-User-Identity in Accounting
   Requests (Start, Interim and Stop) packets.
   Change of Authorization and Disconnect-Request
   Request      ACK      NAK   #    Attribute
      0-1       0        0     TBD  Chargeable User
   [Note 2] Where Chargeable-User-Identity attribute is included in
   Disconnect-Request or CoA-Request messages, they are used for
   identification purposes only.  This attribute MUST NOT be used for
   purposes other than identification (e.g. within CoA-Request messages
   to request authorization changes).
   3. Diameter RADIUS Interoperability
      In deployments where both RADIUS clients talking with Diameter
      Servers or Diameter Client talking with RADIUS server then a
      translation agent will be deployed and operate in accordance to
      the NASREQ specification. A counterpart Diameter AVP with a
      similar content to Chargeable-User-Identity is Diameter Credit-
      Control ApplicationÆs Subscription-ID AVP [11].
   Adrangi, et al.        Expires February 7, 2005           [Page 5]

   Internet Draft   RADIUS Chargeable User Identity       7 Sept 2004
   4. IANA Considerations
     This document requires the assignment of a new RADIUS attribute
     number for the Chargeable User Identity attribute.
   5. Security Considerations
     The Chargeable-User-Identity attribute must be protected against
     Man-in-the-Middle attacks.  The Chargeable-User-Identity appears
     in Access-Accept and Accounting Requests packets and is protected
     by the mechanisms that are defined for RADIUS [1] and [2].
     Therefore there are no additional security considerations beyond
     those already identified in [1] and [2].
     Message-Authenticator (80) and Event-Timestamp can be used to
     further protect against Man-in-the-middle attacks.
     In this document we require that entities outside the home network
     not modify the value of this attribute yet there are no provisions
     for protecting against or detecting that a RADIUS Proxy has
     modified the attribute.
   6. Acknowledgements
      The authors would like to thank Jari Arkko (of Ericsson), Bernard
      Aboba (of Microsoft), Blair Bullock (of iPass), Sami Ala-luukko
      (of Teliasonera), Eugene Chang (of Funk), and Mark Grayson (of
      Cisco) for their feedback and guidance.
   7. References
     [1]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
          Authentication Dial In User Server (RADIUS)", RFC 2865, June
     [2]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
     [3]  Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions",
          RFC 2869, June 2000.
     [4] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B.,
         öDynamic Authorization Extensions to Remote Authentication
         Dial In User Service (RADIUS)ö, RFC 3576, July 2003.
   Adrangi, et al.        Expires February 7, 2005           [Page 6]

   Internet Draft   RADIUS Chargeable User Identity       7 Sept 2004
     [5] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
         Access Identifier", draft-arkko-roamops-rfc2486bis-02 (work in
         progress), July 2004.
     [6] Recommendation E.164/I.331 (05/97): The International Public
         Telecommunication Numbering Plan. 1997.
     [7] Complement to ITU-T Recommendation E.164 (05/1997):"List of
         ITU-T Recommendation E.164 assigned country codes", June 2000.
     [8] Recommendation E.212 (11/98): The international
         identification plan for mobile terminals and mobile users.
     [9] Complement to ITU-T Recommendation E.212 (11/1997):" List of
         mobile country or geographical area codes ", February 1999.
     [10] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,
          G. Camarillo, A. Johnston, J. Peterson, R. Sparks
          "SIP: Session Initiation Protocol", RFC 3261. June 2002.
     [11] Hakala, H., Mattila, L., Koskinen, J.-P., Stura M., and
         Loughney J., "Diameter Credit-Control Application", draft-
         ietf-aaa-diameter-cc-06.txt (work in progress), September
   AuthorsÆ Addresses
         Farid Adrangi
         Intel Corporation
         2111 N.E. 25th Avenue
         Hillsboro  OR
         Phone:  503-712-1791
         Email:  farid.adrangi@intel.com
         Avi Lior
         Bridgewater Systems Corporation
         303 Terry Fox Drive
         Suite 100
         Ottawa, Ontario  K2K 3J1
         Phone:  613-591-9104 ;x 6417
         Email:  avi@bridgewatersystems.com
         Jouni Korhonen
         Teliasonera Corporation
   Adrangi, et al.        Expires February 7, 2005           [Page 7]

   Internet Draft   RADIUS Chargeable User Identity       7 Sept 2004
         Phone: +358405344455
         Email: jouni.korhonen@teliasonera.com
   Full Copyright Statement
        Copyright  (C)  The  Internet  Society  (2002).    All  Rights
        This  document  and  translations  of  it  may  be  copied  and
        furnished to others, and derivative works that comment on or
        otherwise explain it or assist in its implementation may be
        prepared, copied, published and distributed, in whole or in
        part, without restriction of any kind, provided that the above
        copyright notice and this paragraph are included on all such
        copies and derivative works.  However, this document itself may
        not be modified in any way, such as by removing the copyright
        notice or references to the Internet Society or other Internet
        organizations, except as needed for the purpose of developing
        Internet standards in which case the procedures for copyrights
        defined in the Internet Standards process must be followed, or
        as required to translate it into languages other than English.
        The limited permissions granted above are perpetual and will
        not be revoked by the Internet Society or its successors or
        This document and the information contained herein is provided
        Funding for the RFC Editor function is currently provided by
        the Internet Society.
   Adrangi, et al.        Expires February 7, 2005           [Page 8]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/