--- 1/draft-ietf-radext-chargeable-user-id-02.txt 2006-02-05 01:15:29.000000000 +0100 +++ 2/draft-ietf-radext-chargeable-user-id-03.txt 2006-02-05 01:15:29.000000000 +0100 @@ -1,23 +1,22 @@ - Network Working Group F. Adrangi Internet-Draft Intel -Expires: July 5, 2005 A. Lior +Expires: September 2, 2005 A. Lior Bridgewater Systems J. Korhonen Teliasonera J. Loughney Nokia - January 2005 + March 2005 Chargeable User Identity - draft-ietf-radext-chargeable-user-id-02 + draft-ietf-radext-chargeable-user-id-03 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. @@ -30,52 +29,51 @@ 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 July 5, 2005. + This Internet-Draft will expire on September 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Chargeable-User-Identity (CUI) Attribute . . . . . . . . . 5 + 2.2 CUI Attribute . . . . . . . . . . . . . . . . . . . . . . 6 3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . . 7 4. Diameter Consideration . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 5.1 CUI RADIUS Attribute . . . . . . . . . . . . . . . . . . . 7 - 5.2 Error-Cause Attribute . . . . . . . . . . . . . . . . . . 8 - 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 + 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Normative references . . . . . . . . . . . . . . . . . . . 8 - 8.2 Informative references . . . . . . . . . . . . . . . . . . 9 + 8.2 Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 10 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 @@ -106,89 +104,87 @@ subscriber. 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. One missing element is a mechanism for providing the - current deployments with the capacity to deploy, bill and oversee WPA - networks against fraud. + using RADIUS. Missing elements include mechanisms for billing and + fraud prevention. The CUI attribute 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, + negatively. Use of the CUI is geared toward EAP methods supporting + privacy (such as PEAP and EAP-TTLS), 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. 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 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 below. - 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 + server to the client in an Access-Accept packet 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, 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 User-Name(1) attribute included in the Access-Request may be - used for the purpose of routing the Access-Request packet, and in - the process may be rewritten by intermediaries. As a result, a - RADIUS server receiving an Access-Request packet relayed by a - proxy cannot assume that the User-Name(1) attribute remained + The User-Name(1) attribute included in the Access-Request packet + may be used for the purpose of routing the Access-Request packet, + and in the process may be rewritten by intermediaries. As a + result, a RADIUS server receiving an Access-Request packet relayed + by a proxy cannot assume that the User-Name(1) attribute remained unmodified. On the other hand, rewriting of a User-Name(1) attribute sent 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 - 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 the RADIUS client, so that the CUI can be - included in the accounting packets. + packet will add this information to a User-Name(1) attribute + included within an Access-Accept packet. The result is that when + a User-Name(1) attribute is sent in an Access-Accept packet it is + possible that the Access-Request packet 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 the + RADIUS client, so that the 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. + The CUI attribute provides a solution to the above problems and + avoids overloading RADIUS User-Name(1) attribute or changing the + usage of existing RADIUS Class(25) attribute. The CUI therefore + provides a standard approach to billing and fraud prevention when EAP + methods supporting privacy are used. It does not solve all related + problems, but does provide for billing and fraud prevention. 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 @@ -212,62 +208,53 @@ representing a chargeable identity as defined and provided by the home network as a 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. The RADIUS server (a RADIUS proxy, home RADIUS server) may include the CUI attribute in the Access-Accept 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. + business requirements between roaming entities. Therefore a RADIUS + server supporting this specification may not choose to send the CUI + in response to an Access-Request packet from a given NAS, even if the + NAS has indicated that it supports CUI. If an Access-Accept 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 packet MAY be treated as an - Access-Reject packet based on local policies. + a RADIUS client that requested the CUI attribute, then the + Access-Accept packet MAY be treated as an Access-Reject. - If the CUI was included in the Access-Accept 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). + If the CUI was included in an Access-Accept packet, RADIUS clients + supporting 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 or server that does not support the CUI - 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 the CUI attribute in the Access-Request packet with a value - set to the nul character (hereafter, it is also referred to as a nul - CUI). + Therefore, RADIUS clients or servers that do not support the CUI may + ignore the attribute. A RADIUS client requesting the CUI attribute + in an Access-Accept packet MUST include within the Access-Request + packet a CUI attribute with a single NUL character (referred to as a + nul CUI). If a home RADIUS server that supports the CUI attribute receives an - Access-Request containing a CUI (set to nul or otherwise), it MUST - include the CUI attribute in the Access-Accept. Otherwise, if the - Access-Request does not contain a CUI, the home RADIUS server MUST - NOT include the CUI attribute in the Access-Accept. + Access-Request packet containing a CUI (set to nul or otherwise), it + MUST include the CUI attribute in the Access-Accept packet. + Otherwise, if the Access-Request packet does not contain a CUI, the + home RADIUS server MUST NOT include the CUI attribute in the + Access-Accept packet. - A RADIUS server (a RADIUS proxy or the home RADIUS server) that - requires the presence of the CUI in the Accounting-Request packets - (Start, Stop, Interims) MAY respond with an Access-Reject packet if - it receives an Access-Request messsage from a RADIUS client, that - does not support the CUI attribute. The Access-Reject packet MUST - include Error-Cause attribute [RFC3576] with value (to-be-defined) - (decimal), "CUI-Support-Required". +2.2 CUI Attribute 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. @@ -286,64 +272,56 @@ 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-identity - [Note 1] If the Access-Accept contains CUI then the NAS MUST include - the CUI in Accounting Requests (Start, Interim and Stop) packets. + [Note 1] If the Access-Accept packet contains CUI then the NAS MUST + include the CUI in Accounting Requests (Start, Interim and Stop) + packets. 4. Diameter Consideration Diameter needs to define an identical attribute with the same Type value. The CUI should be available as part of the NASREQ application. 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. 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 It is strongly recommended that the CUI 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. + If the NAS includes CUI in an Access-Request packet, a + man-in-the-middle may remove it. This will cause the Access-Accept + packet to not include a CUI attribute, which may cause the NAS to + reject the session. To prevent such a DoS attack, the NAS SHOULD + include a Message-Authenticator(80) attribute within Access-Request + packets containing a CUI attribute. 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