idnits 2.17.1 draft-ietf-radext-chargeable-user-id-04.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.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 421. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. ** There is 1 instance of lines with control characters in the document. 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 (March 22, 2005) is 6975 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 287, 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: 8 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: September 23, 2005 A. Lior 5 Bridgewater Systems 6 J. Korhonen 7 Teliasonera 8 J. Loughney 9 Nokia 10 March 22, 2005 12 Chargeable User Identity 13 draft-ietf-radext-chargeable-user-id-04 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 23, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document describes a new RADIUS attribute, 49 Chargeable-User-Identity. This attribute can be used by a home 50 network to identify a user for the purpose of roaming transactions 51 that occur outside of the home network. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1 Chargeable-User-Identity (CUI) Attribute . . . . . . . . . 5 60 2.2 CUI Attribute . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Diameter Consideration . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1 Normative references . . . . . . . . . . . . . . . . . . . 8 68 8.2 Informative references . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 70 Intellectual Property and Copyright Statements . . . . . . . . 10 72 1. Introduction 74 Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM 75 and EAP-AKA, can hide the true identity of the user from RADIUS 76 servers outside of the user's home network. In these methods, the 77 User-Name(1) attribute contains an anonymous identity (e.g., 78 @example.com) sufficient to route the RADIUS packets to the home 79 network but otherwise insufficient to identify the user. While this 80 mechanism is good practice in some circumstances, there are problems 81 if local and intermediate networks require a surrogate identity to 82 bind the current session. 84 This document introduces an attribute that serves as an alias or 85 handle (hereafter, it is called Chargeable-User-Identity) to the real 86 user's identity. Chargeable-User-Identity can be used outside the 87 home network in scenarios that traditionaly relied on User-Name(1) to 88 correlate a session to a user. 90 For example, local or intermediate networks may limit the number of 91 simultaneous sessions for specific users; they may require a 92 Chargeable-User-Identity in order to demonstrate willingness to pay 93 or otherwise limit the potential for fraud. 95 This implies that a unique identity provided by the home network 96 should be able to be conveyed to all parties involved in the roaming 97 transaction for correlating the authentication and accounting 98 packets. 100 Providing a unique identity, Chargeable-User-Identity (CUI), to 101 intermediaries, is necessary to fulfill certain business needs. This 102 should not undermine the anonymity of the user. The mechanism 103 provided by this draft allows the home operator to meet these 104 business requirements by providing a temporary identity representing 105 the subscriber and at the same time protecting the anonymity of the 106 subscriber. 108 When the home network assigns a value to the CUI, it asserts that 109 this value represents a user in the home network. The assertion 110 should be temporary. Long enough to be useful for the external 111 applications and not too long such that it can be used to identify 112 the user. 114 Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, 115 IRAP, have been studying mechanisms to provide roaming services, 116 using RADIUS. Missing elements include mechanisms for billing and 117 fraud prevention. 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. 126 1.1 Motivation 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 and the home RADIUS server, the 134 use of aforementioned attributes could lead to problems as described 135 below. 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 to the entities outside 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 158 unmodified. 159 On the other hand, rewriting of a User-Name(1) attribute sent 160 within an Access-Accept packet occurs more rarely, since a 161 Proxy-State(33) attribute can be used to route the Access-Accept 162 packet without parsing the User-Name(1) attribute. As a result, a 163 RADIUS server cannot assume that a proxy stripping routing 164 information from a User-Name(1) attribute within an Access-Request 165 packet will add this information to a User-Name(1) attribute 166 included within an Access-Accept packet. The result is that when 167 a User-Name(1) attribute is sent in an Access-Accept packet it is 168 possible that the Access-Request packet and Accounting-Request 169 packets will follow different paths. Where this outcome is 170 undesirable, the RADIUS client should use the original 171 User-Name(1) in accounting packets. Therfore, another mechanism 172 is required to convey a CUI within an Access-Accept packet to the 173 RADIUS client, so that the CUI can be included in the accounting 174 packets. 176 The CUI attribute provides a solution to the above problems and 177 avoids overloading RADIUS User-Name(1) attribute or changing the 178 usage of existing RADIUS Class(25) attribute. The CUI therefore 179 provides a standard approach to billing and fraud prevention when EAP 180 methods supporting privacy are used. It does not solve all related 181 problems, but does provide for billing and fraud prevention. 183 1.2 Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 3GPP - Third Generation Partnership Program 190 AAA - Authentication, Authorization and Accounting 191 CUI - Chargeable-User-Identity 192 GSMA - GSM Association 193 IRAP - International Roaming Access Protocols Program 194 NAS - Network Access Server 195 PEAP - Protected Extensible Authentication Protocol 196 TTLS - Tunneled Transport Layer Security 197 WISPr - Wireless ISP Roaming 198 WPA - Wi-Fi Protected Access 200 2. Operation 202 This document assumes that the RADIUS protocol operates as specified 203 in [RFC2865], [RFC2866], dynamic authorization as specified in 204 [RFC3576], and the Diameter protocol as specified in [RFC3588]. 206 2.1 Chargeable-User-Identity (CUI) Attribute 208 The CUI attribute serves as an alias to the user's real identity, 209 representing a chargeable identity as defined and provided by the 210 home network as a supplemental or alternative information to 211 User-Name(1). Typically the CUI represents the identity of the 212 actual user but it may also indicate other chargeable identities such 213 as a group of users. RADIUS clients (proxy or NAS) outside the home 214 network MUST NOT modify the CUI attribute. 216 The RADIUS server (a RADIUS proxy, home RADIUS server) may include 217 the CUI attribute in the Access-Accept packet destined to a roaming 218 partner. The CUI support by RADIUS infrastructure is driven by the 219 business requirements between roaming entities. Therefore a RADIUS 220 server supporting this specification may not choose to send the CUI 221 in response to an Access-Request packet from a given NAS, even if the 222 NAS has indicated that it supports CUI. 224 If an Access-Accept packet without the CUI attribute was received by 225 a RADIUS client that requested the CUI attribute, then the 226 Access-Accept packet MAY be treated as an Access-Reject. 228 If the CUI was included in an Access-Accept packet, RADIUS clients 229 supporting the CUI attribute MUST ensure that the CUI attribute 230 appears in the RADIUS Accounting-Request (Start, Interim, and Stop). 232 RFC 2865 includes the following statements about behaviors of RADIUS 233 client and server with respect to unsupported attributes: 235 - "A RADIUS client MAY ignore Attributes with an unknown Type." 236 - "A RADIUS server MAY ignore Attributes with an unknown Type." 238 Therefore, RADIUS clients or servers that do not support the CUI may 239 ignore the attribute. A RADIUS client requesting the CUI attribute 240 in an Access-Accept packet MUST include within the Access-Request 241 packet a CUI attribute with a single NUL character (referred to as a 242 nul CUI). 244 If a home RADIUS server that supports the CUI attribute receives an 245 Access-Request packet containing a CUI (set to nul or otherwise), it 246 MUST include the CUI attribute in the Access-Accept packet. 247 Otherwise, if the Access-Request packet does not contain a CUI, the 248 home RADIUS server MUST NOT include the CUI attribute in the 249 Access-Accept packet. 251 2.2 CUI Attribute 253 A summary of the RADIUS CUI Attribute is given below. 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type | Length | String... 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Type: TBD for Chargeable-User-Identity. 262 Length: >= 3 263 String: 265 The string identifies the CUI of the end-user and is of type 266 UTF8String. This string value is a reference to a particular 267 user. The format and content of the string value is determined by 268 the Home RADIUS server. The binding lifetime of the reference to 269 the user is determined based on business agreements. For example, 270 the lifetime can be set to one billing period. RADIUS entities 271 other than the Home RADIUS server MUST treat the CUI content as an 272 opaque token, and SHOULD NOT perform operations on its content 273 other than a binary equality comparison test, between two 274 instances of CUI. In cases where the attribute is used to 275 indicate the NAS support for the CUI, the string value contains a 276 nul character. 278 3. Attribute Table 280 The following table provides a guide to which attribute(s) may be 281 found in which kinds of packets, and in what quantity. 283 Request Accept Reject Challenge Accounting # Attribute 284 Request 285 0-1 0-1 0 0 0-1 TBD Chargeable-User-identity 287 [Note 1] If the Access-Accept packet contains CUI then the NAS MUST 288 include the CUI in Accounting Requests (Start, Interim and Stop) 289 packets. 291 4. Diameter Consideration 293 Diameter needs to define an identical attribute with the same Type 294 value. The CUI should be available as part of the NASREQ 295 application. 297 5. IANA Considerations 299 This document uses the RADIUS [RFC2865] namespace, see 300 "http://www.iana.org/assignments/radius-types". This document 301 instructs IANA to assign a new RADIUS attribute number for the CUI 302 attribute. 304 CUI TBA 306 6. Security considerations 308 It is strongly recommended that the CUI format used is such that the 309 real user identity is not revealed. Furthermore, where a reference 310 is used to a real user identity, the binding lifetime of that 311 reference to the real user be kept as short as possible. 313 The RADIUS entities (RADIUS proxies and clients)outside the home 314 netowrk MUST NOT modify the CUI. However, there is no way to detect 315 or prevent this. 317 If the NAS includes CUI in an Access-Request packet, a 318 man-in-the-middle may remove it. This will cause the Access-Accept 319 packet to not include a CUI attribute, which may cause the NAS to 320 reject the session. To prevent such a DoS attack, the NAS SHOULD 321 include a Message-Authenticator(80) attribute within Access-Request 322 packets containing a CUI attribute. 324 7. Acknowledgements 326 The authors would like to thank Jari Arkko, Bernard Aboba, David 327 Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith, 328 David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson, for 329 their feedback and guidance. 331 8. References 333 8.1 Normative references 335 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 336 "Remote Authentication Dial In User Service (RADIUS)", 337 RFC 2865, June 2000. 339 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [rfc2486bis] 345 Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 346 Network Access Identifier", 347 Internet-Draft draft-arkko-roamops-rfc2486bis-02, July 348 2004. 350 8.2 Informative references 352 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 353 Aboba, "Dynamic Authorization Extensions to Remote 354 Authentication Dial In User Service (RADIUS)", RFC 3576, 355 July 2003. 357 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 359 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 361 Authors' Addresses 363 Farid Adrangi 364 Intel Corporation 365 2111 N.E. 25th Avenue 366 Hillsboro, OR 97124 367 USA 369 Phone: +1 503-712-1791 370 Email: farid.adrangi@intel.com 372 Avi Lior 373 Bridgewater Systems Corporation 374 303 Terry Fox Drive 375 Ottawa, Ontario K2K 3J1 376 Canada 378 Phone: +1 613-591-9104 379 Email: avi@bridgewatersystems.com 381 Jouni Korhonen 382 Teliasonera Corporation 383 P.O.Box 970 384 FIN-00051, Sonera 385 Finland 387 Phone: +358405344455 388 Email: jouni.korhonen@teliasonera.com 390 John Loughney 391 Nokia 392 Itamerenkatu 11-13 393 FIN-00180, Helsinki 394 Finland 396 Phone: +358504836342 397 Email: john.loughney@nokia.com 399 Intellectual Property Statement 401 The IETF takes no position regarding the validity or scope of any 402 Intellectual Property Rights or other rights that might be claimed to 403 pertain to the implementation or use of the technology described in 404 this document or the extent to which any license under such rights 405 might or might not be available; nor does it represent that it has 406 made any independent effort to identify any such rights. Information 407 on the procedures with respect to rights in RFC documents can be 408 found in BCP 78 and BCP 79. 410 Copies of IPR disclosures made to the IETF Secretariat and any 411 assurances of licenses to be made available, or the result of an 412 attempt made to obtain a general license or permission for the use of 413 such proprietary rights by implementers or users of this 414 specification can be obtained from the IETF on-line IPR repository at 415 http://www.ietf.org/ipr. 417 The IETF invites any interested party to bring to its attention any 418 copyrights, patents or patent applications, or other proprietary 419 rights that may cover technology that may be required to implement 420 this standard. Please address the information to the IETF at 421 ietf-ipr@ietf.org. 423 Disclaimer of Validity 425 This document and the information contained herein are provided on an 426 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 427 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 428 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 429 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 430 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 431 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 433 Copyright Statement 435 Copyright (C) The Internet Society (2005). This document is subject 436 to the rights, licenses and restrictions contained in BCP 78, and 437 except as set forth therein, the authors retain all their rights. 439 Acknowledgment 441 Funding for the RFC Editor function is currently provided by the 442 Internet Society.