idnits 2.17.1 draft-ietf-radext-chargeable-user-id-00.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 456. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 191 has weird spacing: '...include this...' == Line 192 has weird spacing: '...tribute in t...' == Line 234 has weird spacing: '...and the secon...' == Line 244 has weird spacing: '... The ident...' -- 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 (December 9, 2004) is 7078 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 292, but not defined == Missing Reference: 'Note 2' is mentioned on line 299, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2866 -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE164' -- Possible downref: Non-RFC (?) normative reference: ref. 'E212' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE212' -- 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: 6 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Adrangi 2 Internet-Draft Intel 3 Expires: June 9, 2005 A. Lior 4 Bridgewater Systems 5 J. Korhonen 6 Teliasonera 7 J. Loughney 8 Nokia 9 December 9, 2004 11 Chargeable User Identity 12 draft-ietf-radext-chargeable-user-id-00 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on June 9, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 This document describes a new RADIUS attribute, Chargeable User 48 Identity. This attribute can be used by a home network to identity a 49 user for the purpose of roaming transactions that occur outside of 50 the home network. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1 Chargeable User Identity (CUI) Attribute . . . . . . . . . 5 59 3. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 8 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1 Normative references . . . . . . . . . . . . . . . . . . . 8 65 7.2 Informative references . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . . 11 69 1. Introduction 71 Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM 72 and EAP-AKA, can hide the true identity of the user from RADIUS 73 servers outside of the user's home network. In these methods, the 74 User-Name(1) attribute contains an anonymous identity (e.g., 75 @example.com) sufficient to route the RADIUS packets to the home 76 network but otherwise insufficient to identify the user. While this 77 mechanism is good practice in some circumstances, there are problems 78 if local and intermediate networks require a user identity in order 79 to enforce usage policies. 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 an authenticated and unique identity provided by 87 the home network should be able to be conveyed to all parties 88 involved in the roaming transaction for correlating the 89 authentication and accounting packets. 91 Providing a unique identity, called the Chargeable User Identity 92 (CUI) to intermediaries, is necessary to fulfill certain business 93 needs. This should not undermine the anonymity of the user. The 94 mechanism provided by this draft allows the home operator to meet 95 these business requirements by providing a temporal identity 96 representing the subscriber and at the same time protecting the 97 anonymity of the subscriber. 99 1.1 Motivation 101 Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, 102 IRAP, have been studying mechanisms to provide roaming services, 103 using RADIUS. A mechanism for providing the current deployments with 104 the capacity to deploy, bill and oversee WPA networks against fraud. 106 The CUI attribute has been designed to close operational loopholes in 107 RADIUS specifications that have impacted roaming solutions 108 negatively, especially when tunneled protocols with multiple 109 identities, such as PEAP or TTLS, are used. A chargeable identity 110 reflecting the user profile authenticated by the home network is 111 needed in such roaming scenarios. 113 Existing RADIUS servers that do not understand the CUI attribute 114 SHOULD silently discard the attribute. Use of the CUI is geared to 115 multi-identity EAP authentications which are, for the most part, 116 recent deployments. 118 Some other mechanisms have been proposed in place of the CUI 119 attribute. These mechanisms are insufficient or cause other 120 problems. It has been suggested that standard RADIUS Class(25) or 121 User-Name(1) attributes could be used to indicate the Chargeable User 122 Identity. However, in a complex global roaming environment where 123 there could be one or more intermediaries between the NAS and the 124 home RADIUS server, the use of aforementioned attributes could lead 125 to problems as described below. 127 - On use of RADIUS Class(25) attribute: 129 [RFC2865] states "This Attribute is available to be sent by the 130 server to the client in an Access-Accept and SHOULD be sent 131 unmodified by the client to the accounting server as part of the 132 Accounting-Request packet if accounting is supported. The client 133 MUST NOT interpret the attribute locally." So RADIUS clients for 134 intermediaries MUST NOT interpret the Class(25) attribute, which 135 precludes determining whether it contains a CUI. Additionally, 136 there could be multiple class attributes in a RADIUS packet with 137 unspecified ordering, which makes it hard to the entities outside 138 home network to determine which one contains the CUI. 140 - On use of RADIUS User-Name(1) 142 The home network could use User-Name(1) in the Access-Accept 143 message to convey the CUI to intermediaries and the NAS. However, 144 as the Access-Accept packet is routed to the NAS, the User-Name(1) 145 attribute could be (completely) rewritten by an intermediary and 146 therefore the NAS or other intermediaries along the way will not 147 have access to the CUI. Furthermore, the NAS may use the original 148 value of the User-Name(1) attribute (the one sent in the 149 Access-Request packet) in the Accounting-Request packets to ensure 150 the billing follows the same path as authentication packets. 152 The CUI attribute provides a solution to the above problem and avoids 153 overloading the use of current RADIUS attributes (e.g., User-Name(1) 154 re-write). CUI is the correct standards-based approach to fixing the 155 problems which have arisen with multiple-identity RADIUS 156 authorization and accounting methods. It does not solve all related 157 problems, but does provide networks the ability to bill and oversee 158 WPA networks against fraud. When the home network assigns a value to 159 the CUI, it asserts that this value represents a user in the home 160 network. The assertion should be temporary. Long enough to be 161 useful for the external applications and not too long to such that it 162 can be used to identify the user. 164 1.2 Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 3GPP - Third Generation Partnership Program 171 AAA - Authentication, Authorization and Accounting 172 CUI - Chargeable User Identity 173 GSMA - GSM Association 174 IRAP - International Roaming Access Protocols Program 175 NAS - Network Access Server 176 PEAP - Protected Extensible Authentication Protocol 177 TTLS - Tunneled Transport Layer Security 178 WISPr - Wireless ISP Roaming 179 WPA - Wi-Fi Protected Access 181 2. Operation 183 This document assumes that the RADIUS protocol operates as specified 184 in [RFC2865], [RFC2866], and the Diameter protocol as specified in 185 [RFC3588]. 187 2.1 Chargeable User Identity (CUI) Attribute 189 This attribute serves as an alias to the user's identity. It is 190 assigned by the home RADIUS server and MAY be sent in Access-Accept 191 message. The NAS or the access network AAA server MUST include this 192 attribute in the Accounting Requests (Start, Interim, and Stop) 193 messages if it was included in the Access Accept message and 194 supported by the NAS. Entities (e.g., NASes, proxies) outside the 195 home network MUST NOT modify the CUI attribute. Servers which do not 196 understand the CUI attribute SHOULD silently discard the attribute. 198 The NAS MAY include the CUI attribute with a null character for its 199 data field in the Access-Request message to indicate its support for 200 this attribute to the home RADIUS server. In cases where the home 201 RADIUS server cannot determine the NAS support for the CUI, if the 202 home RADIUS server requires the NAS support for CUI for any reason 203 (e.g., for billing or charging purposes), the home RADIUS server MUST 204 reject the request by sending an Access-Reject message including an 205 Error-Cause attribute [RFC3576] with value (to-be-defined) (decimal), 206 "CUI-Support-Undetermined". Otherwise, if the authentication is 207 successful, the home RADIUS server MUST send both the User-Name (1) 208 attribute and the CUI attribute, with the understanding that if the 209 NAS supports the CUI attribute the CUI attribute will override the 210 identity portion the User-Name (1) attribute. That is, the 211 User-Name(1) attribute will be used for routing and the CUI attribute 212 will be used for identity purposes. 214 If the RADIUS server includes this attribute in an Access-Accept 215 message it MAY also use this attribute as one of the identity 216 attributes in a Disconnect Message and Change of Authorization 217 message defined by [RFC3576]. 219 A summary of the RADIUS CUI Attribute is given below. 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type | Length | String... 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Type: TBD for Chargeable User Identity. 228 Length: >= 3 230 String: 232 The string identifies the CUI of the end-user and is of type 233 UTF8String. It consists two parts separated by a colon, ':'. The 234 first part determines the CUI type and the second part is the 235 actual Chargeable User Identity value. The CUI type is coded as 236 two octet strings representing a hexadecimal number. The CUI 237 value must be at least one octet. In cases where the attribute is 238 used to indicate the NAS support for the CUI, the string value 239 contains a null character. 241 The following User-Identity types have been defined: 243 00 - E.164 number 244 The identifier is in international E.164 format (e.g. 245 MSISDN, according to the ITU-T E.164 numbering plan as defined 246 in [E164] and [CE164]). 248 01 - IMSI 249 The is in international IMSI format according to the ITU-T 250 E.212 numbering plan as defined in [E212] and [CE212]). 252 02 - SIP URI 253 The identifier is in the form of a SIP URI as defined in 254 [RFC3261]. 256 03 - NAI 257 The identifier is in the form of a Network Access Identifier as 258 defined in [rfc2486bis]. 260 04 - Opaque string 261 Opaque string is a value that is assigned to the user by the 262 home network in an unspecified format, where the home network 263 asserts that this value represents a particular user. 265 05 - reserved 267 The length of time for which the CUI is valid is outside of the 268 scope of this specification. It is assumed to be deployment 269 related. It should typically be long enough to serve some 270 business needs and short enough such that it minimizes the chance 271 of revealing the true identity of the user (either directly or 272 indirectly). 274 Below are examples of CUI strings with NAI and E.164 Charging 275 Types: 277 "03:charging-id@realm.org" 278 "00:+4689761234" 279 "04:charging-id" 281 The real user identity SHOULD NOT be revealed through this 282 attribute. However, the value of this attribute is determined by 283 the service provider. 285 The following table provides a guide to which attribute(s) may be 286 found in which kinds of packets, and in what quantity. 288 Request Accept Reject Challenge Accounting # Attribute 289 Request 290 0-1 0-1 0 0 0-1 TBD Chargeable User ID 292 [Note 1] If the Access-Accept contains CUI then the NAS MUST include 293 the CUI in Accounting Requests (Start, Interim and Stop) packets. 295 Change of Authorization and Disconnect-Request 296 Request ACK NAK # Attribute 297 0-1 0 0 TBD Chargeable User 299 [Note 2] Where CUI attribute is included in Disconnect-Request or 300 CoA-Request messages, it is used for session identification purposes 301 only. This attribute MUST NOT be used for purposes other than 302 identification (e.g. within CoA-Request messages to request 303 authorization changes). 305 3. Diameter RADIUS Interoperability 307 In deployments with both RADIUS and Diameter interworking, a 308 translation agent will be deployed and operate in accordance to the 309 NASREQ specification. The Diameter Credit-Control Application's 310 specifies a similar concept, the Subscription-ID AVP [DiameterCC]. 312 4. IANA Considerations 314 This document instructs IANA to assign a new RADIUS attribute number 315 for the CUI attribute. 317 5. Security considerations 319 The CUI attribute must be protected against Man-in-the-Middle 320 attacks. The CUI appears in Access-Accept and Accounting Requests 321 packets and is protected by the mechanisms that are defined for 322 RADIUS [RFC2865] and [RFC2866]. Therefore there are no additional 323 security considerations beyond those already identified in [RFC2865] 324 and [RFC2866]. 326 Message-Authenticator(80) and Event-Timestamp can be used to further 327 protect against Man-in-the-middle attacks. 329 In this document, entities outside the home network are required not 330 to modify the value of this attribute, however there are no 331 provisions for protecting against or detecting that a RADIUS Proxy 332 has modified the attribute. 334 As the CUI contains an identity that can be used for authorizing and 335 accounting of services, this attribute must be protected against 336 snooping. 338 6. Acknowledgements 340 The authors would like to thank Jari Arkko, Bernard Aboba, David 341 Nelson, Blair Bullock, Sami Ala-Luukko, Lothar Reith, David 342 Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson, for their 343 feedback and guidance. 345 7. References 347 7.1 Normative references 349 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 350 "Remote Authentication Dial In User Service (RADIUS)", RFC 351 2865, June 2000. 353 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [rfc2486bis] 359 Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 360 Network Access Identifier", 361 draft-arkko-roamops-rfc2486bis-02 (work in progress), July 362 2004. 364 [E164] "The International Public Telecommunication Numbering 365 Plan", , May 1997. 367 [CE164] "List of ITU-T Recommendation E.164 assigned country 368 codes", , June 2000. 370 [E212] "The international identification plan for mobile 371 terminals and mobile users", , November 1998. 373 [CE212] "List of mobile country or geographical area codes", , 374 February 1999. 376 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 377 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 378 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 380 7.2 Informative references 382 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 383 Aboba, "Dynamic Authorization Extensions to Remote 384 Authentication Dial In User Service (RADIUS)", RFC 3576, 385 July 2003. 387 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 388 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 390 [DiameterCC] 391 Hakala, H., Koskinen, j., Stura, M. and J. Loughney, "The 392 Network Access Identifier", 393 draft-ietf-aaa-diameter-cc-06.txt (work in progress), 394 July 2004. 396 Authors' Addresses 398 Farid Adrangi 399 Intel Corporation 400 2111 N.E. 25th Avenue 401 Hillsboro, OR 97124 402 USA 404 Phone: +1 503-712-1791 405 EMail: farid.adrangi@intel.com 407 Avi Lior 408 Bridgewater Systems Corporation 409 303 Terry Fox Drive 410 Ottawa, Ontario K2K 3J1 411 Canada 413 Phone: +1 613-591-9104 414 EMail: avi@bridgewatersystems.com 416 Jouni Korhonen 417 Teliasonera Corporation 418 P.O.Box 970 419 FIN-00051, Sonera 420 Finland 422 Phone: +358405344455 423 EMail: jouni.korhonen@teliasonera.com 425 John Loughney 426 Nokia 427 Itamerenkatu 11-13 428 FIN-00180, Helsinki 429 Finland 431 Phone: +358504836342 432 EMail: john.loughney@nokia.com 434 Intellectual Property Statement 436 The IETF takes no position regarding the validity or scope of any 437 Intellectual Property Rights or other rights that might be claimed to 438 pertain to the implementation or use of the technology described in 439 this document or the extent to which any license under such rights 440 might or might not be available; nor does it represent that it has 441 made any independent effort to identify any such rights. Information 442 on the procedures with respect to rights in RFC documents can be 443 found in BCP 78 and BCP 79. 445 Copies of IPR disclosures made to the IETF Secretariat and any 446 assurances of licenses to be made available, or the result of an 447 attempt made to obtain a general license or permission for the use of 448 such proprietary rights by implementers or users of this 449 specification can be obtained from the IETF on-line IPR repository at 450 http://www.ietf.org/ipr. 452 The IETF invites any interested party to bring to its attention any 453 copyrights, patents or patent applications, or other proprietary 454 rights that may cover technology that may be required to implement 455 this standard. Please address the information to the IETF at 456 ietf-ipr@ietf.org. 458 Disclaimer of Validity 460 This document and the information contained herein are provided on an 461 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 462 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 463 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 464 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 465 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 466 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 468 Copyright Statement 470 Copyright (C) The Internet Society (2004). This document is subject 471 to the rights, licenses and restrictions contained in BCP 78, and 472 except as set forth therein, the authors retain all their rights. 474 Acknowledgment 476 Funding for the RFC Editor function is currently provided by the 477 Internet Society.