idnits 2.17.00 (12 Aug 2021) /tmp/idnits60271/draft-adrangi-radius-chargeable-user-identity-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 402. ** 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: ---------------------------------------------------------------------------- == There are 15 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 8) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 148 has weird spacing: '...include this...' == Line 149 has weird spacing: '...tribute in t...' == Line 191 has weird spacing: '...and the secon...' == Line 200 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 (October 25, 2004) is 6417 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 248, but not defined == Missing Reference: 'Note 2' is mentioned on line 255, 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) == Outdated reference: draft-ietf-aaa-diameter-cc has been published as RFC 4006 Summary: 6 errors (**), 0 flaws (~~), 12 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: April 25, 2005 A. Lior 4 Bridgewater Systems 5 J. Korhonen 6 Teliasonera 7 October 25, 2004 9 Chargeable User Identity 10 draft-adrangi-radius-chargeable-user-identity-02 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 25, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document describes a new RADIUS attribute used by a home RADIUS 46 to indicate Chargeable User Identity to all parties involved in the 47 roaming transaction outside the home network. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1 Chargeable User Identity Attribute (CUI) . . . . . . . . . 4 55 3. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 7 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 57 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 8 61 7.2 Informative references . . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 63 Intellectual Property and Copyright Statements . . . . . . . . 10 65 1. Introduction 67 In certain authentication methods such as, EAP-PEAP or EAP-TTLS, 68 EAP-SIM, and EAP-AKA, the true identity of the subscriber can be 69 hidden from the RADIUS AAA servers outside the subscriberÆs home 70 network. In these methods the UserName(1) attribute contains an 71 anonymous identity (e.g., @example.com) sufficient to route the 72 RADIUS packets to the home network but otherwise insufficient to 73 identify the subscriber. While this mechanism is good practice there 74 could be problems. Because Local and intermediate networks may 75 require a user identity in order to enforce usage policies. For 76 example, local or intermediate networks may wish to implement a limit 77 on simultaneous sessions, and/or may require a billable user identity 78 in order to demonstrate willingness to pay and limit the potential 79 for fraud. 81 This basically implies that a unique identity known by the home 82 network needs to be conveyed to all parties involved in the roaming 83 transaction for correlating the authentication and accounting 84 packets. 86 Providing a unique identity to intermediaries is therefore a 87 requirement to fulfill certain business needs. This fulfillment need 88 not undermine the need to protect the anonymity of the user. The 89 mechanism provided by this draft allows the home operator to meet 90 these business requirements by providing a temporal identity 91 representing the subscriber and at the same time protecting the 92 anonymity of the subscriber. 94 Standard RADIUS Class(25) or UserName(1) attributes could be used to 95 indicate the unique identity - hereafter it is referred to as the 96 Chargeable User Identity (CUI). However, in a complex global roaming 97 environment where there could be one or more intermediary between the 98 NAS and the home RADIUS server, the use of aforementioned attributes 99 could lead to problems as described below. 101 - On use of RADIUS Class(25) attribute, [RFC2865] states ôThis 102 Attribute is available to be sent by the server to the client in 103 an Access-Accept and SHOULD be sent unmodified by the client to 104 the accounting server as part of the Accounting-Request packet if 105 accounting is supported. The client MUST NOT interpret the 106 attribute locally.ö So RADIUS clients for intermediaries MUST NOT 107 interpret the Class(25) attribute, which precludes determining 108 whether it contains a CUI. Furthermore, there could be multiple 109 class attributes in a RADIUS packet with unspecified ordering, 110 which makes it hard to the entities outside home network to 111 determine which one contains the CUI. 113 - On use of RADIUS UserName(1), the home network could use 114 UserName(1) in the Access-Accept message to convey the CUI to 115 intermediaries and the NAS. However, as the Access-Accept packet 116 is routed to the NAS, the UserName(1) attribute could be 117 (completely) rewritten by an intermediary and therefore the NAS or 118 other intermediaries along the way will not have access to the 119 CUI. Furthermore, the NAS may use the original value of the 120 UserName(1) attribute ( the one sent in the Access-Request packet) 121 in the Accounting-Request packets to ensure the billing follows 122 the same path as authentication packets. 124 The CUI attribute provides a solution to the above problem and avoids 125 overloading the use of current RADIUS attributes (e.g., UserName(1) 126 re-write). When the home network assigns a value to the CUI it 127 asserts that this value represents a user in the home network. The 128 assertion should be temporary. Long enough to be useful for the 129 external applications and not too long to such that it can be used to 130 identify the user. 132 1.1 Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Operation 140 This document assumes that the RADIUS protocol operates as specified 141 in [RFC2865], [RFC2866], and the Diameter protocol as specified in 142 [RFC3588]. 144 2.1 Chargeable User Identity Attribute (CUI) 146 This attribute serves as an alias to the userÆs identity. It is 147 assigned by the home RADIUS server and MAY be sent in Access-Accept 148 message. The NAS or the access network AAA server MUST include this 149 attribute in the Accounting Requests (Start, Interim, and Stop) 150 messages if it was included in the Access Accept message and 151 supported by the NAS. Entities (e.g., NASes, proxies) outside the 152 home network MUST NOT modify the CUI attribute. 154 The NAS SHOULD include the CUI attribute with a nul character for its 155 data field in the Access-Request message to indicate its support for 156 this attribute to the home RADIUS server. In cases where the CUI is 157 required for proper billing and the home RADIUS server cannot 158 determine the NAS support for the CUI, the home RADIUS server MUST 159 reject the request by sending an Access-Reject message containing a 160 Reply-Message(18) attribute indicating the failure text: "Support for 161 CUI is required. [Author's notes: indicating the text error message 162 via Reply-Message may not be useful to the NAS - we may want to use 163 the error codes specifed in draft-zorn-radius-err-msg-01.txt.] 165 if the CUI attribute is not included in the Access-Accept after the 166 CUI support was indicated to the home RADIUS server in the 167 Access-Request, the NAS MAY treat the Access-Accept as an 168 Access-Reject. [Author's notes: I am sure there will be some 169 reaction to this statement, so let's discuss!] 171 If the RADIUS server includes this attribute in an Access-Accept 172 message it MAY also use this attribute as one of the identity 173 attributes in a Disconnect Message and Change of Authorization 174 message defined by [RFC3576]. 176 A summary of the RADIUS CUI Attribute is given below. 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type | Length | String... 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Type: TBD for Chargeable User Identity. 185 Length: >= 3 187 String: 189 The string identifies the CUI of the end-user and is of type 190 UTF8String. It consists of two colon separated parts. The first 191 part determines the CUI type and the second part is the 192 actual Chargeable User Identity value. The CUI type is coded as 193 two octet string representing a hexadecimal number. The CUI value 194 must be at least one octet. In cases where the attribute is used 195 to indicate the NAS support for the CUI, the string value contain 196 a nul character. 197 The following User-Identity types have been defined: 199 00 ¡ E.164 number 200 The identifier is in international E.164 format (e.g. 201 MSISDN, according to the ITU-T E.164 numbering plan as defined 202 in [E164] and [CE164]). 204 01 ¡ IMSI 205 The is in international IMSI format according to the ITU-T 206 E.212 numbering plan as defined in [E212] and [CE212]). 208 02 ¡ SIP URI 209 The identifier is in the form of a SIP URI as defined (as 210 defined in [RFC3261]). 212 03 ¡ NAI 213 The identifier is in the form of a Network Access Identifier as 214 defined in [rfc2486bis]. 216 04 ¡ Opaque string 217 Opaque string is a value that is assigned to the user by the 218 home network in an unspecified format. where the home network 219 asserts that this value represents a particular user ¡ itÆs a 220 handle to the user. 222 05 ¡ reserved 224 The length of time for which the CUI is valid is unspecified by 225 this specification and typically would be long enough to serve 226 some business needs and short enough such that it minimizes the 227 chance of revealing the true identity of the user (either directly 228 or indirectly). 230 Below are examples of CUI strings with NAI and E.164 Charging 231 Types: 233 ö02:charging-id@realm.orgö 234 ö03:+4689761234ö 235 ö05:charging-idö 237 Ideally, the real user identity should not be revealed through 238 this attribute. However, the operators will have the final word 239 on the used charging type and its identifier. 241 The following table provides a guide to which attribute(s) may be 242 found in which kinds of packets, and in what quantity. 244 Request Accept Reject Challenge Accounting # Attribute 245 Request 246 0 0-1 0 0 0-1 TBD Chargeable User ID 248 [Note 1] If the Access-Accept contains CUI then the NAS MUST include 249 the CUI in Accounting Requests (Start, Interim and Stop) packets. 251 Change of Authorization and Disconnect-Request 252 Request ACK NAK # Attribute 253 0-1 0 0 TBD Chargeable User 255 [Note 2] Where CUI attribute is included in Disconnect-Request or 256 CoA-Request messages, it is used for session identification purposes 257 only. This attribute MUST NOT be used for purposes other than 258 identification (e.g. within CoA-Request messages to request 259 authorization changes). 261 3. Diameter RADIUS Interoperability 263 In deployments where both RADIUS clients talking with Diameter 264 Servers or Diameter Client talking with RADIUS server then a 265 translation agent will be deployed and operate in accordance to the 266 NASREQ specification. A counterpart Diameter AVP with a similar 267 content to CUI is Diameter Credit-Control ApplicationÆs 268 Subscription-ID AVP [DiameterCC]. 270 4. IANA Considerations 272 This document requires the assignment of a new RADIUS attribute 273 number for the CUI attribute. 275 5. Security considerations 277 The CUI attribute must be protected against Man-in-the-Middle 278 attacks. The CUI appears in Access-Accept and Accounting Requests 279 packets and is protected by the mechanisms that are defined for 280 RADIUS [RFC2865] and [RFC2866]. Therefore there are no additional 281 security considerations beyond those already identified in [RFC2865] 282 and [RFC2866]. 284 Message-Authenticator(80) and Event-Timestamp can be used to further 285 protect against Man-in-the-middle attacks. 287 In this document we require that entities outside the home network 288 not modify the value of this attribute yet there are no provisions 289 for protecting against or detecting that a RADIUS Proxy has modified 290 the attribute. 292 6. Acknowledgements 294 The authors would like to thank Jari Arkko (of Ericsson), Bernard 295 Aboba (of Microsoft), Blair Bullock (of iPass), Sami Ala-luukko (of 296 Teliasonera), Eugene Chang (of Funk), Mark Grayson (of Cisco), David 297 Mariblanca (of Ericsson), and Greg Weber (of Cisco) for their 298 feedback and guidance. 300 7. References 302 7.1 Normative references 304 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 305 "Remote Authentication Dial In User Service (RADIUS)", RFC 306 2865, June 2000. 308 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [rfc2486bis] 314 Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 315 Network Access Identifier", 316 draft-arkko-roamops-rfc2486bis-02 (work in progress), July 317 2004. 319 [E164] "The International Public Telecommunication Numbering 320 Plan", , May 1997. 322 [CE164] "List of ITU-T Recommendation E.164 assigned country 323 codes", , June 2000. 325 [E212] "The international identification plan for mobile 326 terminals and mobile users", , November 1998. 328 [CE212] "List of mobile country or geographical area codes", , 329 February 1999. 331 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 332 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 333 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 335 7.2 Informative references 337 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 338 Aboba, "Dynamic Authorization Extensions to Remote 339 Authentication Dial In User Service (RADIUS)", RFC 3576, 340 July 2003. 342 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 343 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 345 [DiameterCC] 346 Hakala, H., Koskinen, j., Stura, M. and J. Loughney, "The 347 Network Access Identifier", 348 draft-ietf-aaa-diameter-cc-06.txt (work in progress), 349 July 2004. 351 Authors' Addresses 353 Farid Adrangi 354 Intel Corporation 355 2111 N.E. 25th Avenue 356 Hillsboro, OR 97124 357 USA 359 Phone: +1 503-712-1791 360 EMail: farid.adrangi@intel.com 362 Avi Lior 363 Bridgewater Systems Corporation 364 303 Terry Fox Drive 365 Ottawa, Ontario K2K 3J1 366 Canada 368 Phone: +1 613-591-9104 369 EMail: avi@bridgewatersystems.com 371 Jouni Korhonen 372 Teliasonera Corporation 373 P.O.Box 970 374 FIN-00051, Sonera 375 Finland 377 Phone: +3 58405344455 378 EMail: jouni.korhonen@teliasonera.com 380 Intellectual Property Statement 382 The IETF takes no position regarding the validity or scope of any 383 Intellectual Property Rights or other rights that might be claimed to 384 pertain to the implementation or use of the technology described in 385 this document or the extent to which any license under such rights 386 might or might not be available; nor does it represent that it has 387 made any independent effort to identify any such rights. Information 388 on the procedures with respect to rights in RFC documents can be 389 found in BCP 78 and BCP 79. 391 Copies of IPR disclosures made to the IETF Secretariat and any 392 assurances of licenses to be made available, or the result of an 393 attempt made to obtain a general license or permission for the use of 394 such proprietary rights by implementers or users of this 395 specification can be obtained from the IETF on-line IPR repository at 396 http://www.ietf.org/ipr. 398 The IETF invites any interested party to bring to its attention any 399 copyrights, patents or patent applications, or other proprietary 400 rights that may cover technology that may be required to implement 401 this standard. Please address the information to the IETF at 402 ietf-ipr@ietf.org. 404 Disclaimer of Validity 406 This document and the information contained herein are provided on an 407 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 408 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 409 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 410 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 411 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 412 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 414 Copyright Statement 416 Copyright (C) The Internet Society (2004). This document is subject 417 to the rights, licenses and restrictions contained in BCP 78, and 418 except as set forth therein, the authors retain all their rights. 420 Acknowledgment 422 Funding for the RFC Editor function is currently provided by the 423 Internet Society.