summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4372.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4372.txt')
-rw-r--r--doc/rfc/rfc4372.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc4372.txt b/doc/rfc/rfc4372.txt
new file mode 100644
index 0000000..228ab8f
--- /dev/null
+++ b/doc/rfc/rfc4372.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group F. Adrangi
+Request for Comments: 4372 Intel
+Category: Standards Track A. Lior
+ Bridgewater Systems
+ J. Korhonen
+ Teliasonera
+ J. Loughney
+ Nokia
+ January 2006
+
+
+ Chargeable User Identity
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes a new Remote Authentication Dial-In User
+ Service (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 ....................................................2
+ 1.1. Motivation .................................................3
+ 1.2. Terminology ................................................4
+ 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
+ 6. Security Considerations .........................................7
+ 7. Acknowledgements ................................................8
+ 8. References ......................................................8
+ 8.1. Normative References .......................................8
+ 8.2. Informative References .....................................8
+
+
+
+Adrangi, et al. Standards Track [Page 1]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+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 surrogate identity to
+ bind the current session.
+
+ 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 scenarios that traditionally relied on User-Name(1)
+ to 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 a 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, 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 document allows the home operator to meet these
+ business requirements by providing a temporary identity representing
+ the user and at the same time protecting the anonymity of the user.
+
+ 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,
+ and IRAP, have been studying mechanisms to provide roaming services,
+ using RADIUS. Missing elements include mechanisms for billing and
+ fraud prevention.
+
+
+
+
+
+
+Adrangi, et al. Standards Track [Page 2]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+ The CUI attribute is intended to close operational loopholes in
+ RADIUS specifications that have impacted roaming solutions
+ 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 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 [RFC4282] 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 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 for the entities outside the 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 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
+ packet will add this information to a User-Name(1) attribute
+
+
+
+Adrangi, et al. Standards Track [Page 3]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+ 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. Therefore, 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 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].
+
+ The following acronyms are used:
+
+ 3GPP - Third Generation Partnership Project
+ AAA - Authentication, Authorization, and Accounting
+ AKA - Authentication and Key Agreement
+ CUI - Chargeable-User-Identity
+ GSMA - GSM Association
+ IRAP - International Roaming Access Protocols Program
+ NAS - Network Access Server
+ PEAP - Protected Extensible Authentication Protocol
+ SIM - Subscriber Identity Modules
+ TTLS - Tunneled Transport Layer Security
+ WISPr - Wireless ISP Roaming
+ WPA - Wi-Fi Protected Access
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adrangi, et al. Standards Track [Page 4]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+2. Operation
+
+ This document assumes that the RADIUS protocol operates as specified
+ in [RFC2865] and [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,
+ 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, a RADIUS
+ server supporting this specification may choose not 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 that requested the CUI attribute, then the
+ Access-Accept packet MAY be treated as an Access-Reject.
+
+ 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).
+ This requirement applies regardless of whether the RADIUS client
+ requested the CUI attribute.
+
+ 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 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.
+ For the initial authentication, the CUI attribute will include a
+ single NUL character (referred to as a nul CUI). And, during
+
+
+
+
+Adrangi, et al. Standards Track [Page 5]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+ re-authentication, the CUI attribute will include a previously
+ received CUI value (referred to as a non-nul CUI value) in the
+ Access-Accept.
+
+ Upon receiving a non-nul CUI value in an Access-Request, the home
+ RADIUS server MAY verify that the value of CUI matches the CUI from
+ the previous Access-Accept. If the verification fails, then the
+ RADIUS server SHOULD respond with an Access-Reject message.
+
+ If a home RADIUS server that supports the CUI attribute receives an
+ 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 SHOULD NOT include the CUI attribute in the
+ Access-Accept packet. The Access-Request may be sent either in the
+ initial authentication or during re-authentication.
+
+ A NAS that requested the CUI during re-authentication by including
+ the CUI in the Access-Request will receive the CUI in the
+ Access-Accept. The NAS MUST include the value of that CUI in all
+ Accounting Messages.
+
+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: 89 for Chargeable-User-Identity.
+
+ Length: >= 3
+
+ String:
+
+ The string identifies the CUI of the end-user. This string value
+ is a reference to a particular user. The format and content of
+ the string value are determined by the Home RADIUS server. 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. RADIUS entities other than the Home RADIUS
+ server MUST treat the CUI content as an opaque token, and SHOULD
+ NOT perform operations on its content other than a binary equality
+ comparison test, between two instances of CUI. In cases where the
+
+
+
+
+Adrangi, et al. Standards Track [Page 6]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+ 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
+ Request
+ 0-1 0-1 0 0 0-1 89 Chargeable-User-Identity
+
+ Note: 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
+ [RFC4005].
+
+5. IANA Considerations
+
+ This document uses the RADIUS [RFC2865] namespace; see
+ http://www.iana.org/assignments/radius-types. The IANA has assigned
+ a new RADIUS attribute number for the CUI attribute.
+
+ CUI 89
+
+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, it is recommended that 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
+ network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
+ However, there is no way to detect or prevent this.
+
+ Attempting theft of service, a man-in-the-middle may try to insert,
+ modify, or remove the CUI in the Access-Accept packets and Accounting
+ packets. However, RADIUS Access-Accept and Accounting packets
+ already provide integrity protection.
+
+
+
+
+
+Adrangi, et al. Standards Track [Page 7]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+ 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 denial of service (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
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+ [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
+ "Diameter Network Access Server Application", RFC 4005,
+ August 2005.
+
+ [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+ Network Access Identifier", RFC 4282, December 2005.
+
+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.
+
+
+
+
+
+
+
+
+Adrangi, et al. Standards Track [Page 8]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Adrangi, et al. Standards Track [Page 9]
+
+RFC 4372 Chargeable User Identity January 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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.
+
+ 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.
+
+Intellectual Property
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Adrangi, et al. Standards Track [Page 10]
+