7 Network Working Group F. Adrangi
8 Request for Comments: 4372 Intel
9 Category: Standards Track A. Lior
18 Chargeable User Identity
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
30 Copyright (C) The Internet Society (2006).
34 This document describes a new Remote Authentication Dial-In User
35 Service (RADIUS) attribute, Chargeable-User-Identity. This attribute
36 can be used by a home network to identify a user for the purpose of
37 roaming transactions that occur outside of the home network.
41 1. Introduction ....................................................2
42 1.1. Motivation .................................................3
43 1.2. Terminology ................................................4
44 2. Operation .......................................................5
45 2.1. Chargeable-User-Identity (CUI) Attribute ...................5
46 2.2. CUI Attribute ..............................................6
47 3. Attribute Table .................................................7
48 4. Diameter Consideration ..........................................7
49 5. IANA Considerations .............................................7
50 6. Security Considerations .........................................7
51 7. Acknowledgements ................................................8
52 8. References ......................................................8
53 8.1. Normative References .......................................8
54 8.2. Informative References .....................................8
58 Adrangi, et al. Standards Track [Page 1]
60 RFC 4372 Chargeable User Identity January 2006
65 Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM
66 and EAP-AKA, can hide the true identity of the user from RADIUS
67 servers outside of the user's home network. In these methods, the
68 User-Name(1) attribute contains an anonymous identity (e.g.,
69 @example.com) sufficient to route the RADIUS packets to the home
70 network but otherwise insufficient to identify the user. While this
71 mechanism is good practice in some circumstances, there are problems
72 if local and intermediate networks require a surrogate identity to
73 bind the current session.
75 This document introduces an attribute that serves as an alias or
76 handle (hereafter, it is called Chargeable-User-Identity) to the real
77 user's identity. Chargeable-User-Identity can be used outside the
78 home network in scenarios that traditionally relied on User-Name(1)
79 to correlate a session to a user.
81 For example, local or intermediate networks may limit the number of
82 simultaneous sessions for specific users; they may require a
83 Chargeable-User-Identity in order to demonstrate willingness to pay
84 or otherwise limit the potential for fraud.
86 This implies that a unique identity provided by the home network
87 should be able to be conveyed to all parties involved in the roaming
88 transaction for correlating the authentication and accounting
91 Providing a unique identity, Chargeable-User-Identity (CUI), to
92 intermediaries, is necessary to fulfill certain business needs. This
93 should not undermine the anonymity of the user. The mechanism
94 provided by this document allows the home operator to meet these
95 business requirements by providing a temporary identity representing
96 the user and at the same time protecting the anonymity of the user.
98 When the home network assigns a value to the CUI, it asserts that
99 this value represents a user in the home network. The assertion
100 should be temporary -- long enough to be useful for the external
101 applications and not too long such that it can be used to identify
104 Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
105 and IRAP, have been studying mechanisms to provide roaming services,
106 using RADIUS. Missing elements include mechanisms for billing and
114 Adrangi, et al. Standards Track [Page 2]
116 RFC 4372 Chargeable User Identity January 2006
119 The CUI attribute is intended to close operational loopholes in
120 RADIUS specifications that have impacted roaming solutions
121 negatively. Use of the CUI is geared toward EAP methods supporting
122 privacy (such as PEAP and EAP-TTLS), which are, for the most part,
123 recent deployments. A chargeable identity reflecting the user
124 profile by the home network is needed in such roaming scenarios.
128 Some other mechanisms have been proposed in place of the CUI
129 attribute. These mechanisms are insufficient or cause other
130 problems. It has been suggested that standard RADIUS Class(25) or
131 User-Name(1) attributes could be used to indicate the CUI. However,
132 in a complex global roaming environment where there could be one or
133 more intermediaries between the NAS [RFC4282] and the home RADIUS
134 server, the use of aforementioned attributes could lead to problems
137 - On the use of RADIUS Class(25) attribute:
139 [RFC2865] states: "This Attribute is available to be sent by the
140 server to the client in an Access-Accept packet and SHOULD be sent
141 unmodified by the client to the accounting server as part of the
142 Accounting-Request packet if accounting is supported. The client
143 MUST NOT interpret the attribute locally." So RADIUS clients or
144 intermediaries MUST NOT interpret the Class(25) attribute, which
145 precludes determining whether it contains a CUI. Additionally,
146 there could be multiple class attributes in a RADIUS packet, and
147 since the contents of Class(25) attribute is not to be interpreted
148 by clients, this makes it hard for the entities outside the home
149 network to determine which one contains the CUI.
151 - On the use of RADIUS User-Name(1) attribute:
153 The User-Name(1) attribute included in the Access-Request packet
154 may be used for the purpose of routing the Access-Request packet,
155 and in the process may be rewritten by intermediaries. As a
156 result, a RADIUS server receiving an Access-Request packet relayed
157 by a proxy cannot assume that the User-Name(1) attribute remained
160 On the other hand, rewriting of a User-Name(1) attribute sent
161 within an Access-Accept packet occurs more rarely, since a
162 Proxy-State(33) attribute can be used to route the Access-Accept
163 packet without parsing the User-Name(1) attribute. As a result, a
164 RADIUS server cannot assume that a proxy stripping routing
165 information from a User-Name(1) attribute within an Access-Request
166 packet will add this information to a User-Name(1) attribute
170 Adrangi, et al. Standards Track [Page 3]
172 RFC 4372 Chargeable User Identity January 2006
175 included within an Access-Accept packet. The result is that when
176 a User-Name(1) attribute is sent in an Access-Accept packet, it is
177 possible that the Access-Request packet and Accounting-Request
178 packets will follow different paths. Where this outcome is
179 undesirable, the RADIUS client should use the original
180 User-Name(1) in accounting packets. Therefore, another mechanism
181 is required to convey a CUI within an Access-Accept packet to the
182 RADIUS client, so that the CUI can be included in the accounting
185 The CUI attribute provides a solution to the above problems and
186 avoids overloading RADIUS User-Name(1) attribute or changing the
187 usage of existing RADIUS Class(25) attribute. The CUI therefore
188 provides a standard approach to billing and fraud prevention when EAP
189 methods supporting privacy are used. It does not solve all related
190 problems, but does provide for billing and fraud prevention.
194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
196 document are to be interpreted as described in [RFC2119].
198 The following acronyms are used:
200 3GPP - Third Generation Partnership Project
201 AAA - Authentication, Authorization, and Accounting
202 AKA - Authentication and Key Agreement
203 CUI - Chargeable-User-Identity
204 GSMA - GSM Association
205 IRAP - International Roaming Access Protocols Program
206 NAS - Network Access Server
207 PEAP - Protected Extensible Authentication Protocol
208 SIM - Subscriber Identity Modules
209 TTLS - Tunneled Transport Layer Security
210 WISPr - Wireless ISP Roaming
211 WPA - Wi-Fi Protected Access
226 Adrangi, et al. Standards Track [Page 4]
228 RFC 4372 Chargeable User Identity January 2006
233 This document assumes that the RADIUS protocol operates as specified
234 in [RFC2865] and [RFC2866], dynamic authorization as specified in
235 [RFC3576], and the Diameter protocol as specified in [RFC3588].
237 2.1. Chargeable-User-Identity (CUI) Attribute
239 The CUI attribute serves as an alias to the user's real identity,
240 representing a chargeable identity as defined and provided by the
241 home network as a supplemental or alternative information to
242 User-Name(1). Typically, the CUI represents the identity of the
243 actual user, but it may also indicate other chargeable identities
244 such as a group of users. RADIUS clients (proxy or NAS) outside the
245 home network MUST NOT modify the CUI attribute.
247 The RADIUS server (a RADIUS proxy, home RADIUS server) may include
248 the CUI attribute in the Access-Accept packet destined to a roaming
249 partner. The CUI support by RADIUS infrastructure is driven by the
250 business requirements between roaming entities. Therefore, a RADIUS
251 server supporting this specification may choose not to send the CUI
252 in response to an Access-Request packet from a given NAS, even if the
253 NAS has indicated that it supports CUI.
255 If an Access-Accept packet without the CUI attribute was received by
256 a RADIUS client that requested the CUI attribute, then the
257 Access-Accept packet MAY be treated as an Access-Reject.
259 If the CUI was included in an Access-Accept packet, RADIUS clients
260 supporting the CUI attribute MUST ensure that the CUI attribute
261 appears in the RADIUS Accounting-Request (Start, Interim, and Stop).
262 This requirement applies regardless of whether the RADIUS client
263 requested the CUI attribute.
265 RFC 2865 includes the following statements about behaviors of RADIUS
266 client and server with respect to unsupported attributes:
268 - "A RADIUS client MAY ignore Attributes with an unknown Type."
269 - "A RADIUS server MAY ignore Attributes with an unknown Type."
271 Therefore, RADIUS clients or servers that do not support the CUI may
272 ignore the attribute.
274 A RADIUS client requesting the CUI attribute in an Access-Accept
275 packet MUST include within the Access-Request packet a CUI attribute.
276 For the initial authentication, the CUI attribute will include a
277 single NUL character (referred to as a nul CUI). And, during
282 Adrangi, et al. Standards Track [Page 5]
284 RFC 4372 Chargeable User Identity January 2006
287 re-authentication, the CUI attribute will include a previously
288 received CUI value (referred to as a non-nul CUI value) in the
291 Upon receiving a non-nul CUI value in an Access-Request, the home
292 RADIUS server MAY verify that the value of CUI matches the CUI from
293 the previous Access-Accept. If the verification fails, then the
294 RADIUS server SHOULD respond with an Access-Reject message.
296 If a home RADIUS server that supports the CUI attribute receives an
297 Access-Request packet containing a CUI (set to nul or otherwise), it
298 MUST include the CUI attribute in the Access-Accept packet.
299 Otherwise, if the Access-Request packet does not contain a CUI, the
300 home RADIUS server SHOULD NOT include the CUI attribute in the
301 Access-Accept packet. The Access-Request may be sent either in the
302 initial authentication or during re-authentication.
304 A NAS that requested the CUI during re-authentication by including
305 the CUI in the Access-Request will receive the CUI in the
306 Access-Accept. The NAS MUST include the value of that CUI in all
311 A summary of the RADIUS CUI attribute is given below.
314 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
315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316 | Type | Length | String...
317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
319 Type: 89 for Chargeable-User-Identity.
325 The string identifies the CUI of the end-user. This string value
326 is a reference to a particular user. The format and content of
327 the string value are determined by the Home RADIUS server. The
328 binding lifetime of the reference to the user is determined based
329 on business agreements. For example, the lifetime can be set to
330 one billing period. RADIUS entities other than the Home RADIUS
331 server MUST treat the CUI content as an opaque token, and SHOULD
332 NOT perform operations on its content other than a binary equality
333 comparison test, between two instances of CUI. In cases where the
338 Adrangi, et al. Standards Track [Page 6]
340 RFC 4372 Chargeable User Identity January 2006
343 attribute is used to indicate the NAS support for the CUI, the
344 string value contains a nul character.
348 The following table provides a guide to which attribute(s) may be
349 found in which kinds of packets, and in what quantity.
351 Request Accept Reject Challenge Accounting # Attribute
353 0-1 0-1 0 0 0-1 89 Chargeable-User-Identity
355 Note: If the Access-Accept packet contains CUI, then the NAS MUST
356 include the CUI in Accounting Requests (Start, Interim, and Stop)
359 4. Diameter Consideration
361 Diameter needs to define an identical attribute with the same Type
362 value. The CUI should be available as part of the NASREQ application
365 5. IANA Considerations
367 This document uses the RADIUS [RFC2865] namespace; see
368 http://www.iana.org/assignments/radius-types. The IANA has assigned
369 a new RADIUS attribute number for the CUI attribute.
373 6. Security Considerations
375 It is strongly recommended that the CUI format used is such that the
376 real user identity is not revealed. Furthermore, where a reference
377 is used to a real user identity, it is recommended that the binding
378 lifetime of that reference to the real user be kept as short as
381 The RADIUS entities (RADIUS proxies and clients) outside the home
382 network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
383 However, there is no way to detect or prevent this.
385 Attempting theft of service, a man-in-the-middle may try to insert,
386 modify, or remove the CUI in the Access-Accept packets and Accounting
387 packets. However, RADIUS Access-Accept and Accounting packets
388 already provide integrity protection.
394 Adrangi, et al. Standards Track [Page 7]
396 RFC 4372 Chargeable User Identity January 2006
399 If the NAS includes CUI in an Access-Request packet, a
400 man-in-the-middle may remove it. This will cause the Access-Accept
401 packet to not include a CUI attribute, which may cause the NAS to
402 reject the session. To prevent such a denial of service (DoS)
403 attack, the NAS SHOULD include a Message-Authenticator(80) attribute
404 within Access-Request packets containing a CUI attribute.
408 The authors would like to thank Jari Arkko, Bernard Aboba, David
409 Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith,
410 David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson for
411 their feedback and guidance.
415 8.1. Normative References
417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
418 Requirement Levels", BCP 14, RFC 2119, March 1997.
420 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
421 "Remote Authentication Dial In User Service (RADIUS)",
424 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
426 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
427 "Diameter Network Access Server Application", RFC 4005,
430 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
431 Network Access Identifier", RFC 4282, December 2005.
433 8.2. Informative References
435 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
436 Aboba, "Dynamic Authorization Extensions to Remote
437 Authentication Dial In User Service (RADIUS)", RFC 3576,
440 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
441 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
450 Adrangi, et al. Standards Track [Page 8]
452 RFC 4372 Chargeable User Identity January 2006
459 2111 N.E. 25th Avenue
463 Phone: +1 503-712-1791
464 EMail: farid.adrangi@intel.com
468 Bridgewater Systems Corporation
470 Ottawa, Ontario K2K 3J1
473 Phone: +1 613-591-9104
474 EMail: avi@bridgewatersystems.com
478 Teliasonera Corporation
484 EMail: jouni.korhonen@teliasonera.com
494 EMail: john.loughney@nokia.com
506 Adrangi, et al. Standards Track [Page 9]
508 RFC 4372 Chargeable User Identity January 2006
511 Full Copyright Statement
513 Copyright (C) The Internet Society (2006).
515 This document is subject to the rights, licenses and restrictions
516 contained in BCP 78, and except as set forth therein, the authors
517 retain all their rights.
519 This document and the information contained herein are provided on an
520 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
521 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
522 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
523 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
524 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
525 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
527 Intellectual Property
529 The IETF takes no position regarding the validity or scope of any
530 Intellectual Property Rights or other rights that might be claimed to
531 pertain to the implementation or use of the technology described in
532 this document or the extent to which any license under such rights
533 might or might not be available; nor does it represent that it has
534 made any independent effort to identify any such rights. Information
535 on the procedures with respect to rights in RFC documents can be
536 found in BCP 78 and BCP 79.
538 Copies of IPR disclosures made to the IETF Secretariat and any
539 assurances of licenses to be made available, or the result of an
540 attempt made to obtain a general license or permission for the use of
541 such proprietary rights by implementers or users of this
542 specification can be obtained from the IETF on-line IPR repository at
543 http://www.ietf.org/ipr.
545 The IETF invites any interested party to bring to its attention any
546 copyrights, patents or patent applications, or other proprietary
547 rights that may cover technology that may be required to implement
548 this standard. Please address the information to the IETF at
553 Funding for the RFC Editor function is provided by the IETF
554 Administrative Support Activity (IASA).
562 Adrangi, et al. Standards Track [Page 10]