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

                        Chargeable User Identity
                draft-ietf-radext-chargeable-user-id-00
                draft-ietf-radext-chargeable-user-id-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of 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.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes a new RADIUS attribute, Chargeable User
   Identity.
   Chargeable-User-Identity.  This attribute can be used by a home
   network to identity 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
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Chargeable User Identity   Chargeable-User-Identity (CUI) Attribute . . . . . . . . .  5
   3.  Attribute Table  . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Diameter RADIUS Interoperability . . . . . . . . . . . . . . .  8
   4.  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   5.  7
     5.1   CUI RADIUS Attribute . . . . . . . . . . . . . . . . . . .  7
     5.2   Error-Cause Attribute  . . . . . . . . . . . . . . . . . .  7
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  8
   6.
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   7.
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1
     8.1   Normative references . . . . . . . . . . . . . . . . . . .  8
     7.2
     8.2   Informative references . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10  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.,
   @example.com) 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 in order
   to enforce usage policies.

   For example, local or intermediate networks may limit the number of
   simultaneous sessions for specific users; they may require a
   chargeable user identity
   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 Chargeable-User-Identity
   (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 temporal temporary identity
   representing the subscriber and at the same time protecting the
   anonymity of the subscriber.

1.1  Motivation

   Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
   IRAP, have been studying mechanisms to provide roaming services,
   using RADIUS.  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 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
   scenarios.

   Existing

   The CUI support by RADIUS servers that do not understand infrastructure is driven by the CUI attribute
   SHOULD silently discard business
   requirements between roaming entities.  Therefore whether a RADIUS
   server/proxy or client accepts or rejects the attribute.  Use presence or lack of
   presence of the CUI attribute is geared to
   multi-identity EAP authentications which are, for the most part,
   recent deployments. a matter of business policy.

   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.
   Chargeable-User-Identity.  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 below.

      - On use of RADIUS Class(25) attribute:

      [RFC2865] states 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 for 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 makes it hard to the entities outside
      home network to determine which one contains the CUI.

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

      The home network could use User-Name(1) in the Access-Accept
      message to convey the CUI to intermediaries and the NAS.  However,
      as the Access-Accept packet is routed to the NAS, the User-Name(1)
      attribute could be (completely) rewritten by an intermediary and
      therefore the NAS or other intermediaries along the way will not
      have access to the CUI.  Furthermore, the NAS may use the original
      value of the User-Name(1) attribute (the one sent in the
      Access-Request packet) in the Accounting-Request packets to ensure
      the billing follows the same path as authentication 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 to such that it
   can be used to identify the user.

1.2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

      3GPP - Third Generation Partnership Program
      AAA - Authentication, Authorization and Accounting
      CUI - Chargeable User Identity 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  Chargeable-User-Identity (CUI) Attribute

   This attribute serves as an alias to the user's real identity.  It is
   assigned
   provided by the home network as a suplemental or alternative
   information to User-Name(1).  RADIUS server and MAY be sent in Access-Accept
   message.  The NAS clients (proxy 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 and
   supported by the NAS.  Entities (e.g., NASes, proxies) NAS) outside
   the home network MUST NOT modify the CUI attribute.  Servers which do not
   understand the CUI attribute SHOULD silently discard

   In accordance to business policies, the attribute.

   The NAS MAY RADIUS server (a RADIUS
   proxy, home RADIUS server) may include the CUI attribute with a null character for its
   data field in the Access-Request
   Access-Accept message destined to indicate its support for
   this attribute to a roaming partner.

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

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

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

   If RADIUS server client (Proxy or NAS) requires the NAS support for presence of the CUI
   attribute in the Access-Accept, it MUST indicate its requirement by
   including this attribute with a nul character for any reason
   (e.g., for billing or charging purposes), its data field
   (hereafter, it is also referred to as a nul CUI) in the
   Access-Request message.

   If a home RADIUS server MUST
   reject that supports the request by sending an Access-Reject message including CUI attribute receives an
   Error-Cause
   Access-Request containing a nul CUI, it MUST include the CUI
   attribute [RFC3576] with value (to-be-defined) (decimal),
   "CUI-Support-Undetermined". in the Access-Accept.  Otherwise, if the authentication is
   successful, Access-Request
   does not contain a null CUI, the home RADIUS server MUST send both NOT include
   the User-Name (1) CUI attribute and in the CUI attribute, with Access-Accept.

   A RADIUS server (a RADIUS proxy or the understanding home RADIUS server) that if the
   NAS supports
   requires the CUI attribute presence of the CUI attribute will override in the
   identity portion Accounting-Response messages
   (Start, Stop, Interims) MAY respond with an Access-Reject message if
   it receives an Access-Request messsage from a RADIUS client, or proxy
   chain that does not support the User-Name (1) CUI attribute.  That is, the
   User-Name(1)  The Access-Reject
   message MUST include Error-Cause attribute will be used for routing and [RFC3576] with value
   (to-be-defined) (decimal), "CUI-Support-Required".

   If the NAS supports CUI attribute
   will be used for identity purposes.

   If then the RADIUS server includes this CUI attribute in an Access-Accept
   message it MAY also use this attribute be
   used as one of the identity
   attributes attribute in a Disconnect Message and
   Change of Authorization
   message 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. Chargeable-User-Identity.

   Length: >= 3

   String:

      The string identifies the CUI of the end-user and is of type
      UTF8String.  It consists two parts separated by a colon, ':'.  The
      first part determines the CUI type and the  second  part  is  the
      actual  Chargeable User Identity value.  The CUI type is coded as
      two octet strings representing a hexadecimal number.  The CUI
      value must be at least one octet.  In cases where the attribute is
      used to indicate the NAS support for the CUI, the string value
      contains a null character.

      The following User-Identity types have been defined:

      00 - 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 [E164] and [CE164]).

      01 - IMSI
         The is in international IMSI format according to the ITU-T
         E.212 numbering plan as defined in [E212] and [CE212]).

      02 - SIP URI
         The identifier is in the form of a SIP URI as defined in
         [RFC3261].

      03 - NAI
         The identifier is in the form of a Network Access Identifier as
         defined in [rfc2486bis].

      04 - Opaque string
         Opaque  This string is a value that is assigned to the user by the
         home network in an unspecified format, where the home network
         asserts that this value represents a reference to a particular
      user.

      05 - reserved  The length of time for which format and the CUI is valid is outside interpretation of the
      scope of this specification.  It is assumed to be deployment
      related.  It should typically be long enough to serve some
      business needs string value , and short enough such that it minimizes
      the chance binding lifetime of revealing the true identity of reference to the user (either directly or
      indirectly).

      Below are examples of CUI strings with NAI and E.164 Charging
      Types:

                "03:charging-id@realm.org"
                "00:+4689761234"
                "04:charging-id"

      The real user identity SHOULD NOT is determined
      based on business agreements.  For example, the lifetime can be revealed through this
      attribute.  However,
      set to one billing period.  In cases where the value of this attribute is determined by used
      to indicate the NAS support for the CUI, the service provider. 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
                                      Request
     0-1     0-1     0       0        0-1       TBD  Chargeable User ID   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  Chargeable-User-Identity

   [Note 2] 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).

3.

4.  Diameter RADIUS Interoperability

   In deployments with both RADIUS and Diameter interworking, a
   translation agent will be deployed and operate in accordance to the
   NASREQ specification.  The Diameter Credit-Control Application's
   specifies a similar concept, the Subscription-ID AVP [DiameterCC].

4.

5.  IANA Considerations

5.1  CUI RADIUS Attribute

   This document uses the RADIUS [RFC2865] namespace, see
   "http://www.iana.org/assignments/radius-types".  This document
   instructs IANA to assign a new RADIUS attribute number for the CUI
   attribute.

5.

         CUI		   TBA

5.2  Error-Cause Attribute

   This document instructs IANA to assign a new 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 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 Event-Timestamp(55) can be used to
   further protect against Man-in-the-middle attacks.

   In this document, entities outside

   It is strongly recommended that the home network are required CUI form used is such that the
   real user identity is not revealed.  Furthermore, where a reference
   is used to modify a real user identity, the value binding lifetime of this attribute, however there are no
   provisions for protecting against or detecting that a RADIUS Proxy
   has modified the attribute.

   As
   reference to the CUI contains an identity that can be used for authorizing and
   accounting of services, this attribute must real user be protected against
   snooping.

6. kept as short as possible.

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.

7.

8.  References

7.1

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.

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

   [E164]     "The International Public Telecommunication Numbering
              Plan", , May 1997.

   [CE164]    "List of ITU-T Recommendation E.164 assigned country
              codes", , June 2000.

   [E212]     "The international identification plan for mobile
              terminals and mobile users", , November 1998.

   [CE212]    "List of mobile country or geographical area codes", ,
              February 1999.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
              "SIP: Session Initiation Protocol", RFC 3261, June 2002.

7.2

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.

   [DiameterCC]
              Hakala, H., Koskinen, j., Stura, M. and J. Loughney, "The
              Network Access Identifier",
              draft-ietf-aaa-diameter-cc-06.txt  (work in progress),
              July 2004.

Authors' Addresses

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

   Phone: +1 503-712-1791
   EMail: farid.adrangi@intel.com

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

   Phone: +1 613-591-9104
   EMail: avi@bridgewatersystems.com

   Jouni Korhonen
   Teliasonera Corporation
   P.O.Box 970
   FIN-00051,   Sonera
   Finland

   Phone: +358405344455
   EMail: jouni.korhonen@teliasonera.com
   John Loughney
   Nokia
   Itamerenkatu 11-13
   FIN-00180,   Helsinki
   Finland

   Phone: +358504836342
   EMail: john.loughney@nokia.com

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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Acknowledgment

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