idnits 2.17.1 draft-ietf-radext-chargeable-user-id-02.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 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 436. ** 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 (January 2005) is 7034 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 296, 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: July 5, 2005 A. Lior 5 Bridgewater Systems 6 J. Korhonen 7 Teliasonera 8 J. Loughney 9 Nokia 10 January 2005 12 Chargeable User Identity 13 draft-ietf-radext-chargeable-user-id-02 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 July 5, 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 3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Diameter Consideration . . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5.1 CUI RADIUS Attribute . . . . . . . . . . . . . . . . . . . 7 64 5.2 Error-Cause Attribute . . . . . . . . . . . . . . . . . . 8 65 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1 Normative references . . . . . . . . . . . . . . . . . . . 8 69 8.2 Informative references . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . 11 73 1. Introduction 75 Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM 76 and EAP-AKA, can hide the true identity of the user from RADIUS 77 servers outside of the user's home network. In these methods, the 78 User-Name(1) attribute contains an anonymous identity (e.g., 79 @example.com) sufficient to route the RADIUS packets to the home 80 network but otherwise insufficient to identify the user. While this 81 mechanism is good practice in some circumstances, there are problems 82 if local and intermediate networks require a user identity. 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 an authenticated and unique identity provided by 96 the home network should be able to be conveyed to all parties 97 involved in the roaming transaction for correlating the 98 authentication and accounting 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. One missing element is a mechanism for providing the 117 current deployments with the capacity to deploy, bill and oversee WPA 118 networks against fraud. 120 The CUI attribute is intended to close operational loopholes in 121 RADIUS specifications that have impacted roaming solutions 122 negatively, especially when tunneled protocols with multiple 123 identities, such as PEAP or TTLS, are used. Use of the CUI is geared 124 to multi-identity EAP authentications which are, for the most part, 125 recent deployments. A chargeable identity reflecting the user 126 profile authenticated by the home network is needed in such roaming 127 scenarios. 129 1.1 Motivation 131 Some other mechanisms have been proposed in place of the CUI 132 attribute. These mechanisms are insufficient or cause other 133 problems. It has been suggested that standard RADIUS Class(25) or 134 User-Name(1) attributes could be used to indicate the CUI. However, 135 in a complex global roaming environment where there could be one or 136 more intermediaries between the NAS and the home RADIUS server, the 137 use of aforementioned attributes could lead to problems as described 138 below. 140 - On the use of RADIUS Class(25) attribute: 142 [RFC2865] states: "This Attribute is available to be sent by the 143 server to the client in an Access-Accept and SHOULD be sent 144 unmodified by the client to the accounting server as part of the 145 Accounting-Request packet if accounting is supported. The client 146 MUST NOT interpret the attribute locally." So RADIUS clients or 147 intermediaries MUST NOT interpret the Class(25) attribute, which 148 precludes determining whether it contains a CUI. Additionally, 149 there could be multiple class attributes in a RADIUS packet, and 150 since the contents of Class(25) attribute is not to be interpreted 151 by clients, this makes it hard to the entities outside home 152 network to determine which one contains the CUI. 154 - On the use of RADIUS User-Name(1) attribute: 156 The User-Name(1) attribute included in the Access-Request may be 157 used for the purpose of routing the Access-Request packet, and in 158 the process may be rewritten by intermediaries. As a result, a 159 RADIUS server receiving an Access-Request packet relayed by a 160 proxy cannot assume that the User-Name(1) attribute remained 161 unmodified. 162 On the other hand, rewriting of a User-Name(1) attribute sent 163 within an Access-Accept packet occurs more rarely, since a 164 Proxy-State(33) attribute can be used to route the Access-Accept 165 packet without parsing the User-Name(1) attribute. As a result, a 166 RADIUS server cannot assume that a proxy stripping routing 167 information from a User-Name(1) attribute within an Access-Request 168 will add this information to a User-Name(1) attribute included 169 within an Access-Accept. The result is that when a User-Name(1) 170 attribute is sent in an Access-Accept it is possible that the 171 Access-Request and Accounting-Request packets will follow 172 different paths. Where this outcome is undesirable, the RADIUS 173 client should use the original User-Name(1) in accounting packets. 174 Therfore, another mechanism is required to convey a CUI within an 175 Access-Accept packet to the RADIUS client, so that the CUI can be 176 included in the accounting packets. 178 The CUI attribute provides a solution to the above problem and avoids 179 overloading the use of current RADIUS attributes (e.g., User-Name(1) 180 re-write). The CUI is the correct standards-based approach to fixing 181 the problems which have arisen with multiple-identity RADIUS 182 authorization and accounting methods. It does not solve all related 183 problems, but does provide networks the ability to bill and oversee 184 WPA networks against fraud. 186 1.2 Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 3GPP - Third Generation Partnership Program 193 AAA - Authentication, Authorization and Accounting 194 CUI - Chargeable-User-Identity 195 GSMA - GSM Association 196 IRAP - International Roaming Access Protocols Program 197 NAS - Network Access Server 198 PEAP - Protected Extensible Authentication Protocol 199 TTLS - Tunneled Transport Layer Security 200 WISPr - Wireless ISP Roaming 201 WPA - Wi-Fi Protected Access 203 2. Operation 205 This document assumes that the RADIUS protocol operates as specified 206 in [RFC2865], [RFC2866], dynamic authorization as specified in 207 [RFC3576], and the Diameter protocol as specified in [RFC3588]. 209 2.1 Chargeable-User-Identity (CUI) Attribute 211 The CUI attribute serves as an alias to the user's real identity, 212 representing a chargeable identity as defined and provided by the 213 home network as a supplemental or alternative information to 214 User-Name(1). Typically the CUI represents the identity of the 215 actual user but it may also indicate other chargeable identities such 216 as a group of users. RADIUS clients (proxy or NAS) outside the home 217 network MUST NOT modify the CUI attribute. 219 The RADIUS server (a RADIUS proxy, home RADIUS server) may include 220 the CUI attribute in the Access-Accept packet destined to a roaming 221 partner. The CUI support by RADIUS infrastructure is driven by the 222 business requirements between roaming entities. Therefore whether a 223 RADIUS server/proxy or client accepts or rejects the presence or lack 224 of presence of the CUI attribute is a matter of business policy. 226 If an Access-Accept packet without the CUI attribute was received by 227 a RADIUS client (NAS or Proxy) that requires the presence of the CUI 228 attribute, then the Access-Accept packet MAY be treated as an 229 Access-Reject packet based on local policies. 231 If the CUI was included in the Access-Accept packet, RADIUS client 232 (Proxy or NAS) that supports the CUI attribute MUST ensure that the 233 CUI attribute appears in the RADIUS Accounting-Request (Start, 234 Interim, and Stop). 236 RFC 2865 includes the following statements about behaviors of RADIUS 237 client and server with respect to unsupported attributes: 239 - "A RADIUS client MAY ignore Attributes with an unknown Type." 240 - "A RADIUS server MAY ignore Attributes with an unknown Type." 242 Therefore, RADIUS client or server that does not support the CUI 243 attribute MAY ignore this attribute. 245 If RADIUS client (Proxy or NAS) requires the presence of the CUI 246 attribute in the Access-Accept, it MUST indicate its requirement by 247 including the CUI attribute in the Access-Request packet with a value 248 set to the nul character (hereafter, it is also referred to as a nul 249 CUI). 251 If a home RADIUS server that supports the CUI attribute receives an 252 Access-Request containing a CUI (set to nul or otherwise), it MUST 253 include the CUI attribute in the Access-Accept. Otherwise, if the 254 Access-Request does not contain a CUI, the home RADIUS server MUST 255 NOT include the CUI attribute in the Access-Accept. 257 A RADIUS server (a RADIUS proxy or the home RADIUS server) that 258 requires the presence of the CUI in the Accounting-Request packets 259 (Start, Stop, Interims) MAY respond with an Access-Reject packet if 260 it receives an Access-Request messsage from a RADIUS client, that 261 does not support the CUI attribute. The Access-Reject packet MUST 262 include Error-Cause attribute [RFC3576] with value (to-be-defined) 263 (decimal), "CUI-Support-Required". 265 A summary of the RADIUS CUI Attribute is given below. 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length | String... 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type: TBD for Chargeable-User-Identity. 274 Length: >= 3 276 String: 278 The string identifies the CUI of the end-user and is of type 279 UTF8String. This string value is a reference to a particular 280 user. The format and the interpretation of the string value , and 281 the binding lifetime of the reference to the user is determined 282 based on business agreements. For example, the lifetime can be 283 set to one billing period. In cases where the attribute is used 284 to indicate the NAS support for the CUI, the string value contains 285 a nul character. 287 3. Attribute Table 289 The following table provides a guide to which attribute(s) may be 290 found in which kinds of packets, and in what quantity. 292 Request Accept Reject Challenge Accounting # Attribute 293 Request 294 0-1 0-1 0 0 0-1 TBD Chargeable-User-identity 296 [Note 1] If the Access-Accept contains CUI then the NAS MUST include 297 the CUI in Accounting Requests (Start, Interim and Stop) packets. 299 4. Diameter Consideration 301 Diameter needs to define an identical attribute with the same Type 302 value. The CUI should be available as part of the NASREQ 303 application. 305 5. IANA Considerations 307 5.1 CUI RADIUS Attribute 309 This document uses the RADIUS [RFC2865] namespace, see 310 "http://www.iana.org/assignments/radius-types". This document 311 instructs IANA to assign a new RADIUS attribute number for the CUI 312 attribute. 314 CUI TBA 316 5.2 Error-Cause Attribute 318 This document instructs IANA to assign a new value for Error-Cause 319 attribute [RFC3576], 321 "CUI-Support-Required" TBA 323 6. Security considerations 325 It is strongly recommended that the CUI format used is such that the 326 real user identity is not revealed. Furthermore, where a reference 327 is used to a real user identity, the binding lifetime of that 328 reference to the real user be kept as short as possible. 330 The RADIUS entities (RADIUS proxies and clients)outside the home 331 netowrk MUST NOT modify the CUI. However, there is no way to detect 332 or prevent this. 334 If the NAS includes CUI in an Access-Request. A man in the middle 335 may remove the CUI attribute from the Access-Request. The result is 336 that the Access-Accept will not have a CUI which will cause the NAS 337 to reject the session resulting in a DOS attack. To prevent this 338 attack, the NAS SHOULD include Message-Authenticator(80) in the 339 Access-Request packets that contain a CUI. 341 7. Acknowledgements 343 The authors would like to thank Jari Arkko, Bernard Aboba, David 344 Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith, 345 David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson, for 346 their feedback and guidance. 348 8. References 350 8.1 Normative references 352 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 353 "Remote Authentication Dial In User Service (RADIUS)", 354 RFC 2865, June 2000. 356 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [rfc2486bis] 362 Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 363 Network Access Identifier", 364 Internet-Draft draft-arkko-roamops-rfc2486bis-02, July 365 2004. 367 8.2 Informative references 369 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 370 Aboba, "Dynamic Authorization Extensions to Remote 371 Authentication Dial In User Service (RADIUS)", RFC 3576, 372 July 2003. 374 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 375 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 377 Authors' Addresses 379 Farid Adrangi 380 Intel Corporation 381 2111 N.E. 25th Avenue 382 Hillsboro, OR 97124 383 USA 385 Phone: +1 503-712-1791 386 Email: farid.adrangi@intel.com 388 Avi Lior 389 Bridgewater Systems Corporation 390 303 Terry Fox Drive 391 Ottawa, Ontario K2K 3J1 392 Canada 394 Phone: +1 613-591-9104 395 Email: avi@bridgewatersystems.com 396 Jouni Korhonen 397 Teliasonera Corporation 398 P.O.Box 970 399 FIN-00051, Sonera 400 Finland 402 Phone: +358405344455 403 Email: jouni.korhonen@teliasonera.com 405 John Loughney 406 Nokia 407 Itamerenkatu 11-13 408 FIN-00180, Helsinki 409 Finland 411 Phone: +358504836342 412 Email: john.loughney@nokia.com 414 Intellectual Property Statement 416 The IETF takes no position regarding the validity or scope of any 417 Intellectual Property Rights or other rights that might be claimed to 418 pertain to the implementation or use of the technology described in 419 this document or the extent to which any license under such rights 420 might or might not be available; nor does it represent that it has 421 made any independent effort to identify any such rights. Information 422 on the procedures with respect to rights in RFC documents can be 423 found in BCP 78 and BCP 79. 425 Copies of IPR disclosures made to the IETF Secretariat and any 426 assurances of licenses to be made available, or the result of an 427 attempt made to obtain a general license or permission for the use of 428 such proprietary rights by implementers or users of this 429 specification can be obtained from the IETF on-line IPR repository at 430 http://www.ietf.org/ipr. 432 The IETF invites any interested party to bring to its attention any 433 copyrights, patents or patent applications, or other proprietary 434 rights that may cover technology that may be required to implement 435 this standard. Please address the information to the IETF at 436 ietf-ipr@ietf.org. 438 Disclaimer of Validity 440 This document and the information contained herein are provided on an 441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 443 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 444 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 445 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 448 Copyright Statement 450 Copyright (C) The Internet Society (2005). This document is subject 451 to the rights, licenses and restrictions contained in BCP 78, and 452 except as set forth therein, the authors retain all their rights. 454 Acknowledgment 456 Funding for the RFC Editor function is currently provided by the 457 Internet Society.