idnits 2.17.1 draft-ietf-radext-chargeable-user-id-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 439. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2005) is 6764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Note 1' is mentioned on line 301, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2866 -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Adrangi 3 Internet-Draft Intel 4 Expires: April 15, 2006 A. Lior 5 Bridgewater Systems 6 J. Korhonen 7 Teliasonera 8 J. Loughney 9 Nokia 10 October 12, 2005 12 Chargeable User Identity 13 draft-ietf-radext-chargeable-user-id-06 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 15, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document describes a new RADIUS attribute, Chargeable-User- 47 Identity. This attribute can be used by a home network to identify a 48 user for the purpose of roaming transactions that occur outside of 49 the home network. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 56 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Chargeable-User-Identity (CUI) Attribute . . . . . . . . . 5 58 2.2. CUI Attribute . . . . . . . . . . . . . . . . . . . . . . 7 59 3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Diameter Consideration . . . . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 66 8.2. Informative references . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . . . . 11 70 1. Introduction 72 Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM 73 and EAP-AKA, can hide the true identity of the user from RADIUS 74 servers outside of the user's home network. In these methods, the 75 User-Name(1) attribute contains an anonymous identity (e.g., 76 @example.com) sufficient to route the RADIUS packets to the home 77 network but otherwise insufficient to identify the user. While this 78 mechanism is good practice in some circumstances, there are problems 79 if local and intermediate networks require a surrogate identity to 80 bind the current session. 82 This document introduces an attribute that serves as an alias or 83 handle (hereafter, it is called Chargeable-User-Identity) to the real 84 user's identity. Chargeable-User-Identity can be used outside the 85 home network in scenarios that traditionaly relied on User-Name(1) to 86 correlate a session to a user. 88 For example, local or intermediate networks may limit the number of 89 simultaneous sessions for specific users; they may require a 90 Chargeable-User-Identity in order to demonstrate willingness to pay 91 or otherwise limit the potential for fraud. 93 This implies that a unique identity provided by the home network 94 should be able to be conveyed to all parties involved in the roaming 95 transaction for correlating the authentication and accounting 96 packets. 98 Providing a unique identity, Chargeable-User-Identity (CUI), to 99 intermediaries, is necessary to fulfill certain business needs. This 100 should not undermine the anonymity of the user. The mechanism 101 provided by this draft allows the home operator to meet these 102 business requirements by providing a temporary identity representing 103 the user and at the same time protecting the anonymity of the user. 105 When the home network assigns a value to the CUI, it asserts that 106 this value represents a user in the home network. The assertion 107 should be temporary. Long enough to be useful for the external 108 applications and not too long such that it can be used to identify 109 the user. 111 Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, 112 IRAP, have been studying mechanisms to provide roaming services, 113 using RADIUS. Missing elements include mechanisms for billing and 114 fraud prevention. 116 The CUI attribute is intended to close operational loopholes in 117 RADIUS specifications that have impacted roaming solutions 118 negatively. Use of the CUI is geared toward EAP methods supporting 119 privacy (such as PEAP and EAP-TTLS), which are, for the most part, 120 recent deployments. A chargeable identity reflecting the user 121 profile by the home network is needed in such roaming scenarios. 123 1.1. Motivation 125 Some other mechanisms have been proposed in place of the CUI 126 attribute. These mechanisms are insufficient or cause other 127 problems. It has been suggested that standard RADIUS Class(25) or 128 User-Name(1) attributes could be used to indicate the CUI. However, 129 in a complex global roaming environment where there could be one or 130 more intermediaries between the NAS and the home RADIUS server, the 131 use of aforementioned attributes could lead to problems as described 132 below. 134 - On the use of RADIUS Class(25) attribute: 136 [RFC2865] states: "This Attribute is available to be sent by the 137 server to the client in an Access-Accept packet and SHOULD be sent 138 unmodified by the client to the accounting server as part of the 139 Accounting-Request packet if accounting is supported. The client 140 MUST NOT interpret the attribute locally." So RADIUS clients or 141 intermediaries MUST NOT interpret the Class(25) attribute, which 142 precludes determining whether it contains a CUI. Additionally, 143 there could be multiple class attributes in a RADIUS packet, and 144 since the contents of Class(25) attribute is not to be interpreted 145 by clients, this makes it hard to the entities outside home 146 network to determine which one contains the CUI. 148 - On the use of RADIUS User-Name(1) attribute: 150 The User-Name(1) attribute included in the Access-Request packet 151 may be used for the purpose of routing the Access-Request packet, 152 and in the process may be rewritten by intermediaries. As a 153 result, a RADIUS server receiving an Access-Request packet relayed 154 by a proxy cannot assume that the User-Name(1) attribute remained 155 unmodified. 156 On the other hand, rewriting of a User-Name(1) attribute sent 157 within an Access-Accept packet occurs more rarely, since a Proxy- 158 State(33) attribute can be used to route the Access-Accept packet 159 without parsing the User-Name(1) attribute. As a result, a RADIUS 160 server cannot assume that a proxy stripping routing information 161 from a User-Name(1) attribute within an Access-Request packet will 162 add this information to a User-Name(1) attribute included within 163 an Access-Accept packet. The result is that when a User-Name(1) 164 attribute is sent in an Access-Accept packet it is possible that 165 the Access-Request packet and Accounting-Request packets will 166 follow different paths. Where this outcome is undesirable, the 167 RADIUS client should use the original User-Name(1) in accounting 168 packets. Therefore, another mechanism is required to convey a CUI 169 within an Access-Accept packet to the RADIUS client, so that the 170 CUI can be included in the accounting packets. 172 The CUI attribute provides a solution to the above problems and 173 avoids overloading RADIUS User-Name(1) attribute or changing the 174 usage of existing RADIUS Class(25) attribute. The CUI therefore 175 provides a standard approach to billing and fraud prevention when EAP 176 methods supporting privacy are used. It does not solve all related 177 problems, but does provide for billing and fraud prevention. 179 1.2. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 3GPP - Third Generation Partnership Program 186 AAA - Authentication, Authorization and Accounting 187 CUI - Chargeable-User-Identity 188 GSMA - GSM Association 189 IRAP - International Roaming Access Protocols Program 190 NAS - Network Access Server 191 PEAP - Protected Extensible Authentication Protocol 192 TTLS - Tunneled Transport Layer Security 193 WISPr - Wireless ISP Roaming 194 WPA - Wi-Fi Protected Access 196 2. Operation 198 This document assumes that the RADIUS protocol operates as specified 199 in [RFC2865], [RFC2866], dynamic authorization as specified in 200 [RFC3576], and the Diameter protocol as specified in [RFC3588]. 202 2.1. Chargeable-User-Identity (CUI) Attribute 204 The CUI attribute serves as an alias to the user's real identity, 205 representing a chargeable identity as defined and provided by the 206 home network as a supplemental or alternative information to User- 207 Name(1). Typically the CUI represents the identity of the actual 208 user but it may also indicate other chargeable identities such as a 209 group of users. RADIUS clients (proxy or NAS) outside the home 210 network MUST NOT modify the CUI attribute. 212 The RADIUS server (a RADIUS proxy, home RADIUS server) may include 213 the CUI attribute in the Access-Accept packet destined to a roaming 214 partner. The CUI support by RADIUS infrastructure is driven by the 215 business requirements between roaming entities. Therefore a RADIUS 216 server supporting this specification may choose not to send the CUI 217 in response to an Access-Request packet from a given NAS, even if the 218 NAS has indicated that it supports CUI. 220 If an Access-Accept packet without the CUI attribute was received by 221 a RADIUS client that requested the CUI attribute, then the Access- 222 Accept packet MAY be treated as an Access-Reject. 224 If the CUI was included in an Access-Accept packet, RADIUS clients 225 supporting the CUI attribute MUST ensure that the CUI attribute 226 appears in the RADIUS Accounting-Request (Start, Interim, and Stop). 227 This requirement applies regardless of whether the RADIUS client 228 requested the CUI attribute. 230 RFC 2865 includes the following statements about behaviors of RADIUS 231 client and server with respect to unsupported attributes: 233 - "A RADIUS client MAY ignore Attributes with an unknown Type." 234 - "A RADIUS server MAY ignore Attributes with an unknown Type." 236 Therefore, RADIUS clients or servers that do not support the CUI may 237 ignore the attribute. 239 A RADIUS client requesting the CUI attribute in an Access-Accept 240 packet MUST include within the Access-Request packet a CUI attribute. 241 For the initial authentication, the CUI attribute will include a 242 single NUL character (referred to as a nul CUI). And, during re- 243 authentication, the CUI attribute will include a previously received 244 CUI value (referred as a non-nul CUI value) in the Access-Accept. 246 Upon receiving a non-nul CUI value in an Access-Request the home 247 RADIUS server MAY verify that the value of CUI matches the CUI from 248 the previous Access-Accept. If the verification fails, then the 249 RADIUS server SHOULD respond with an Access-Reject message. 251 If a home RADIUS server that supports the CUI attribute receives an 252 Access-Request packet containing a CUI (set to nul or otherwise), it 253 MUST include the CUI attribute in the Access-Accept packet. 254 Otherwise, if the Access-Request packet does not contain a CUI, the 255 home RADIUS server SHOULD NOT include the CUI attribute in the 256 Access-Accept packet. The Access-Request may be sent either in the 257 initial authentication or during re-authentication. 259 A NAS that requested the CUI during re-authentication by including 260 the CUI in the Access-Request, will receive the CUI in the Access- 261 Accept. The NAS MUST include the value of that CUI in all Accounting 262 Messages. 264 2.2. CUI Attribute 266 A summary of the RADIUS CUI Attribute is given below. 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Length | String... 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Type: TBD for Chargeable-User-Identity. 275 Length: >= 3 277 String: 279 The string identifies the CUI of the end-user and is of type 280 UTF8String. This string value is a reference to a particular 281 user. The format and content of the string value is determined by 282 the Home RADIUS server. The binding lifetime of the reference to 283 the user is determined based on business agreements. For example, 284 the lifetime can be set to one billing period. RADIUS entities 285 other than the Home RADIUS server MUST treat the CUI content as an 286 opaque token, and SHOULD NOT perform operations on its content 287 other than a binary equality comparison test, between two 288 instances of CUI. In cases where the attribute is used to 289 indicate the NAS support for the CUI, the string value contains a 290 nul character. 292 3. Attribute Table 294 The following table provides a guide to which attribute(s) may be 295 found in which kinds of packets, and in what quantity. 297 Request Accept Reject Challenge Accounting # Attribute 298 Request 299 0-1 0-1 0 0 0-1 TBD Chargeable-User-identity 301 [Note 1] If the Access-Accept packet contains CUI then the NAS MUST 302 include the CUI in Accounting Requests (Start, Interim and Stop) 303 packets. 305 4. Diameter Consideration 307 Diameter needs to define an identical attribute with the same Type 308 value. The CUI should be available as part of the NASREQ 309 application. 311 5. IANA Considerations 313 This document uses the RADIUS [RFC2865] namespace, see 314 "http://www.iana.org/assignments/radius-types". This document 315 instructs IANA to assign a new RADIUS attribute number for the CUI 316 attribute. 318 CUI TBA 320 6. Security considerations 322 It is strongly recommended that the CUI format used is such that the 323 real user identity is not revealed. Furthermore, where a reference 324 is used to a real user identity, the binding lifetime of that 325 reference to the real user be kept as short as possible. 327 The RADIUS entities (RADIUS proxies and clients) outside the home 328 network MUST NOT modify the CUI or insert a CUI in an Access-Accept. 329 However, there is no way to detect or prevent this. 331 Attempting theft of service, A man-in-the-middle may try to insert, 332 modify or remove the CUI in the Access-Accept packets and Accounting 333 packets. However, RADIUS Access-Accept and Accounting packets 334 already provide integrity protection. 336 If the NAS includes CUI in an Access-Request packet, a man-in-the- 337 middle may remove it. This will cause the Access-Accept packet to 338 not include a CUI attribute, which may cause the NAS to reject the 339 session. To prevent such a DoS attack, the NAS SHOULD include a 340 Message-Authenticator(80) attribute within Access-Request packets 341 containing a CUI attribute. 343 7. Acknowledgements 345 The authors would like to thank Jari Arkko, Bernard Aboba, David 346 Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith, 347 David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson, for 348 their feedback and guidance. 350 8. References 352 8.1. Normative references 354 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 355 "Remote Authentication Dial In User Service (RADIUS)", 356 RFC 2865, June 2000. 358 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [rfc2486bis] 364 Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 365 Network Access Identifier", 366 draft-arkko-roamops-rfc2486bis-02 (work in progress), 367 July 2004. 369 8.2. Informative references 371 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 372 Aboba, "Dynamic Authorization Extensions to Remote 373 Authentication Dial In User Service (RADIUS)", RFC 3576, 374 July 2003. 376 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 377 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 379 Authors' Addresses 381 Farid Adrangi 382 Intel Corporation 383 2111 N.E. 25th Avenue 384 Hillsboro, OR 97124 385 USA 387 Phone: +1 503-712-1791 388 Email: farid.adrangi@intel.com 390 Avi Lior 391 Bridgewater Systems Corporation 392 303 Terry Fox Drive 393 Ottawa, Ontario K2K 3J1 394 Canada 396 Phone: +1 613-591-9104 397 Email: avi@bridgewatersystems.com 399 Jouni Korhonen 400 Teliasonera Corporation 401 P.O.Box 970 402 FIN-00051, Sonera 403 Finland 405 Phone: +358405344455 406 Email: jouni.korhonen@teliasonera.com 408 John Loughney 409 Nokia 410 Itamerenkatu 11-13 411 FIN-00180, Helsinki 412 Finland 414 Phone: +358504836342 415 Email: john.loughney@nokia.com 417 Intellectual Property Statement 419 The IETF takes no position regarding the validity or scope of any 420 Intellectual Property Rights or other rights that might be claimed to 421 pertain to the implementation or use of the technology described in 422 this document or the extent to which any license under such rights 423 might or might not be available; nor does it represent that it has 424 made any independent effort to identify any such rights. Information 425 on the procedures with respect to rights in RFC documents can be 426 found in BCP 78 and BCP 79. 428 Copies of IPR disclosures made to the IETF Secretariat and any 429 assurances of licenses to be made available, or the result of an 430 attempt made to obtain a general license or permission for the use of 431 such proprietary rights by implementers or users of this 432 specification can be obtained from the IETF on-line IPR repository at 433 http://www.ietf.org/ipr. 435 The IETF invites any interested party to bring to its attention any 436 copyrights, patents or patent applications, or other proprietary 437 rights that may cover technology that may be required to implement 438 this standard. Please address the information to the IETF at 439 ietf-ipr@ietf.org. 441 Disclaimer of Validity 443 This document and the information contained herein are provided on an 444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 446 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 447 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 448 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 451 Copyright Statement 453 Copyright (C) The Internet Society (2005). This document is subject 454 to the rights, licenses and restrictions contained in BCP 78, and 455 except as set forth therein, the authors retain all their rights. 457 Acknowledgment 459 Funding for the RFC Editor function is currently provided by the 460 Internet Society.