Network Working Group Farid Adrangi INTERNET DRAFT Intel Corporation Category: Informational (or standards?) Avi Lior Expires: Feb 7, 2005 Bridgewater Systems Jouni Korhonen Teliasonera Sept 7, 2004 Chargeable User Identity draft-adrangi-radius-chargeable-user-identity-00.txt 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 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. Abstract 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", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Chargeable User Identity Type To be assigned by IANA Length >= 6 String 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 [9]). 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: ö02:charging-id@realm.orgö ö03:+4689761234ö ö05:charging-idö 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 Request 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 2000. [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. 1998. [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 2004. AuthorsÆ Addresses Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro OR USA Phone: 503-712-1791 Email: farid.adrangi@intel.com Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Suite 100 Ottawa, Ontario K2K 3J1 Canada 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 Reserved. 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 assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Adrangi, et al. Expires February 7, 2005 [Page 8]