idnits 2.17.00 (12 Aug 2021) /tmp/idnits54483/draft-adrangi-radius-attributes-extension-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 22 instances of lines with non-ascii characters in the document. == 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 28 has weird spacing: '... The list ...' == Line 129 has weird spacing: '... modify the ...' == Line 163 has weird spacing: '...as type is co...' == Line 202 has weird spacing: '... There is a...' == Line 281 has weird spacing: '...service provi...' == (1 more instance...) -- 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 (July 16, 2004) is 6518 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 84 -- Looks like a reference, but probably isn't: 'RFC 3588' on line 89 -- Looks like a reference, but probably isn't: 'NASREQ' on line 89 == Missing Reference: '13' is mentioned on line 173, but not defined == Missing Reference: '5' is mentioned on line 205, but not defined == Missing Reference: '7' is mentioned on line 278, but not defined == Missing Reference: '8' is mentioned on line 295, but not defined ** Obsolete normative reference: RFC 3576 (ref. '4') (Obsoleted by RFC 5176) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Farid Adrangi 2 INTERNET DRAFT Intel Corporation 3 Category: Informational Avi Lior 4 Expires: Dec 10, 2004 Bridgewater Systems 5 Jouni Korhonen 6 Teliasonera 7 July 16, 2004 9 RADIUS Attributes Extension 10 draft-adrangi-radius-attributes-extension-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes additional Remote Authentication Dial In 37 User Service (RADIUS) [1] attributes for use of RADIUS AAA 38 (Authentication, Authorization, Accounting) in both Wireless and 39 wired networks. It contains an IPv4 address type control mechanism, 40 mobile IPv4 home agent discovery mechanism, and a RADIUS 41 capabilities discovery mechanism. 43 Table of Contents 45 1. Introduction....................................................2 46 1.1 Requirements language..........................................2 47 2. Operation.......................................................2 48 2.1 RADIUS Support for Specifying User Identity Alias..............3 49 2.2 RADIUS Support for Advertising Application-based capabilities..5 50 2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6 51 2.4 RADIUS Support for Specifying IPv4 Address Type Options........7 52 3. IANA Considerations.............................................9 53 4. Security Considerations.........................................9 54 5. Acknowledgements................................................9 55 6. References......................................................9 56 AuthorsĖ Addresses................................................10 58 1. Introduction 60 Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the 61 dominant Authentication, Authorization, and Accounting (AAA) 62 protocol in use across broadband wireless and wired networks 63 globally. 65 This document describes a number of additional attributes that are 66 needed to enable use of RADIUS AAA in various types of access 67 network in an interoperable manner. 69 This document describes a number of additional attributes 70 for the RADIUS and Diameter AAA protocols. These attributes 71 are needed to provide additional AAA functions for wired and 72 wireless access networks. Some of these functions already 73 exist as vendor-specific solutions, but this draft makes these 74 functions interoperable among different vendors. 76 1.1 Requirements language 78 In this document, several words are used to signify the 79 requirements of the specification. These words are often 80 capitalized. The key words "MUST", "MUST NOT", "REQUIRED", 81 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 82 "MAY", and "OPTIONAL" in this document are to be interpreted as 83 described in [RFC2119]. 85 2. Operation 87 This document assumes that the RADIUS protocol operates as 88 specified in [1, 2] and that the Diameter protocol operates as 89 specified in[RFC 3588, NASREQ]. 91 2.1 RADIUS Support for Specifying User Identity Alias 93 Rationale 95 In certain authentication methods such as, EAP-PEAP or EAP- 96 TTLS, EAP-SIM, and EAP-AKA, the true identity of the subscriber 97 can be hidden from the RADIUS AAA servers outside the 98 subscriberĖs home network. In these methods the User-name(1) 99 attribute contains an anonymous identity (e.g., 100 anonymous@homerealm.com) sufficient to route the RADIUS packets 101 to the home network but otherwise insufficient to identify the 102 subscriber. While this mechanism is good practice there are 103 situations where this creates problems: 105 - In certain roaming situations intermediaries and visited 106 network require to be able to correlate an authentication 107 session with a user identity known to the userĖs home 108 network ķ for example: a broker may require to implement a 109 policy where by only session is allowed per user entity; 110 third party billing brokers may require to match accounting 111 records to a user identity. 112 - NAS may require to match the user session and accounting 113 records to a user identity known to the userĖs home network. 115 The User Identity Alias provides a solution to the above 116 problem. When the home network assigns a value to the User 117 Identity Alias it asserts that this value represents a user in 118 the home network. The assertion should be temporary. Long 119 enough to be useful for the external applications and not too 120 long to such that it can be used to identify the user. 122 Attribute 124 This attribute indicates userĖs identity alias. It is assigned 125 by the home RADIUS server and MAY be sent in Access-Accept 126 message. The NAS or the access network AAA server MUST include 127 this attribute in the Accounting Requests (Start, Interim, and 128 Stop) messages if it was included in the Access Accept message. 129 Intermediaries MUST NOT modify the User Alias Identity 130 attribute. 132 If the RADIUS server includes this attribute in an Access- 133 Accept message it MAY also use this attribute as one of the 134 identity attributes in a Disconnect Message and Change of 135 Authorization message defined by [4]. 137 A summary of the RADIUS User Identity Alias Attribute is shown 138 below. 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | String... 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Name 147 User Identity Alias 149 Type 151 To be assigned by IANA 153 Length 155 >= 6 157 String 159 The string field is six or more octets. This non-NULL 160 terminated string consists of two colon separated parts. The 161 first part determines the User Identity Alias type and the 162 second part is the actual User Identity Alias value. The 163 User-Identity-Alias type is coded as two octet hexadecimal 164 string,. The User Identity Alias value must be at least one 165 octet. 167 The following User-Identity Alias types have been defined: 169 00 ķ reserved 170 01 ķ IMSI 171 02 ķ NAI 172 03 ķ E.164 number 173 04 ķ SIP URL (as defined in [13]) 174 05 ķ Opaque string 176 Opague string is a value that is assigned to the user by the 177 home network where the home network asserts that this value 178 represents a particular user ķ itĖs a handle to the user. 179 The length of time for which this assertion is valid is 180 unspecified by this specification and typically would be 181 long enough to serve some business needs and short enough 182 such that it minimizes the chance of revealing the true 183 identity of the user (either directly or indirectly). 185 Below are examples of User Identity Alias strings with NAI 186 and E.164 Charging Types: 188 ÷02:charging-id@realm.org÷ 189 ÷03:+4689761234÷ 191 Ideally, the real user identity should not be revealed 192 through this attribute. However, the operators will have 193 the final word on the used charging type and its identifier. 195 Additional User Identity Alias types may be assigned in 196 revised versions of this RFC. 198 2.2 RADIUS Support for Advertising Application-based capabilities 200 Rationale 202 There is a need for a home RADIUS server to discover 203 capabilities of a NAS that has initiated a connection to it. 204 The capabilities indicate standard-based applications (e.g., 205 existing dynamic authorization Extension to Remote [5], future 206 prepaid accounting model, etc.) that a NAS supports. This 207 enables the home RADIUS server to decide which application 208 services it can use for the connection, or whether or not it 209 should accept the connection. For example, if the subscriber 210 is a prepaid subscriber, and the NAS does not support the 211 prepaid capability, the RADIUS server may want to reject the 212 connection. 214 Attribute 216 This attribute describes standard-based capabilities that a NAS 217 supports. Zero or more of these attribute are available to be 218 sent in Access-Request. 220 A summary of the capability Attribute is shown below. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | Integer | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Name 232 Generic Capability 234 Type 236 To be assigned by IANA 238 Length 240 = 6 242 Integer 244 The format of this Integer is as follows: 246 0xCCCTSSSS 248 Where: 249 CCC is a 12-bit indicator that identifies the capability ID. 250 CCC = 0x000 and 0xFFF is reserved. 252 T is a 4-bit indicator used for extending the sub-capability 253 space. T = 0xF is reserved. 255 SSSS is 16-bit indicator that identifies the sub-capabilities ID. 256 These are determined by the application writer and may represent a 257 number of mutually exclusive sub-capabilities or mutually 258 inclusive sub-capabilities codes as bits. 260 Extension of sub-capabilities: 262 T=0x0 represents the first 16 bits of sub-capabilities 263 T=0x1 represents the next 16 bits of sub-capabilities 264 T=0xF represents the last 16 bits of sub-capabilities 266 The following Capability Identities are assigned by this RFC. 267 Additional capability ids may be assigned later. See the IANA 268 section. 270 EditorĖs note: we have to assign some capabilities from radius and 271 also sub-capabilities. Candidates would be from RFCs 2865, 2869, 272 2867, 3162, 3576, 3580. 274 2.3 RADIUS Support for Specifying a Mobile IP Home Agent 276 Rationale 278 In Mobile IP [7], a Mobile-IP enabled client registers with its 279 home agent when it attaches to the network for the first time, 280 or when it changes its network point of attachment. In typical 281 service provider deployments, networks are geographically 282 dispersed within a single large administrative domain. In such 283 networks, it is possible to deploy the home agents in each 284 geographical area. When a client authenticates to its home 285 network through a NAS, the home RADIUS server may want to 286 specify the home agent for that client based on the NAS 287 location information. 289 There is a need for an interoperable method by which the home 290 RADIUS server can indicate the Mobile IP home agent that MUST 291 used by the client to the NAS. The home agent address can 292 later be indicated to the client through several means ķ for 293 example, it can be relayed in the ÷home agent address÷ field of 294 a DHCP reply if the client acquires its IP address through DHCP 295 [8]. 297 Attribute (IPv4 version) 299 This attribute indicates the home agent IPv4 Address that can 300 be used by a Mobile-IP enabled client. This attribute is 301 available to be sent in Access-Accept. 303 A summary of the RADIUS Mobile IPv4 home agent Attribute is 304 shown below. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | Address 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Address (cont) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Name 316 Mobile IPv4 Home Agent 318 Type 320 To be assigned by IANA 322 Length 324 6 326 Address 328 The Address filed is four octets. It contains a Mobile IP 329 home agent address. 331 2.4 RADIUS Support for Specifying IPv4 Address Type Options 333 Rationale 335 An access network may have an option of assigning a layer 3 336 public (i.e., routable) or private (i.e., non-routable) address 337 to the authorized clients. If the option is available, the 338 home network may also want to influence which address type 339 (i.e., public or private) should be assigned to the client 340 depending on the clientĖs subscription profile. 342 There is a need for an interoperable method by which a NAS can 343 indicate its currently available IPv4 address type options to a 344 home network for a given client. And then, the home network can 345 specify the desired IPv4 address type option to be used for 346 assigning an IPv4 address to the client. 348 Attribute 350 This attribute indicates IPv4 address type options. In RADIUS, 351 it can be present in Access-Request, and Access-Accept 352 messages. In Diameter, it can be present in AAR, AAA, and RAR 353 commands. In both protocols, it can be present in 354 Accounting-Request messages where the Acc-Status-Type is set to 355 Start or Stop. When it is used in an Access-Accept and 356 Accounting-Request packets, the Address Type value MUST be 1 or 357 2. 359 A NAS includes this attribute in the RADIUS Access-Accept or 360 Diameter AAR to advertise its supported IPv4 address type 361 options. An AAA server includes this attribute in the RADIUS 362 Access-Accept packet or Diameter AAA and RAR commands to 363 specify an IPv4 address type option for the access network 364 client. 366 An AAA server MUST NOT include this attribute in the RADIUS 367 Access-Accept or Diameter AAA and PAR if the IPv4 Address Type 368 options were not advertised by the NAS. If an invalid IPv4 369 Address Type option is received, then the NAS MUST treat it as 370 an RADIUS Access-Reject or Diameter AA-Answer with Result-Code 371 AVP set to ???. Otherwise, the access network MUST assign an 372 IPv4 address according to the specified type option, and the 373 NAS MUST include this attribute in Accounting-Request packets 374 to indicate the used IPv4 address type option. If an IPv4 375 address type option is not specified in the RADIUS Access- 376 Accept or Diameter RAR and AAA commands, the NAS MUST NOT 377 include this attribute in Accounting-Request packets. 379 A summary of the RADIUS IPv4 Address Type Option Attribute is 380 shown below. 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Length |IPv4 Addr. Type| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Name 388 IPv4 Address Type Options 390 Type 392 To be assigned by IANA 394 Length 396 1 398 Address Type 400 1 : Public Address Type 401 2 : Private Address Type 402 3 : Public and Private Type 404 3. IANA Considerations 406 This draft introduces new RADIUS Attributes. Therefore, there is 407 a need for obtaining new attribute TYPE numbers from IANA. 409 New enumerated values within the attributes defined here can be 410 allocated using the policies defined in RFC 3575, i.e., Designated 411 Expert. 413 4. Security Considerations 415 The attributes in this document have no additional security 416 considerations beyond those already identified in [?]. 418 5. Acknowledgements 420 The authors would like to thank Jari Arkko for his extensive 421 contribution and comments in improving the draft. 423 6. References 425 [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 426 Authentication Dial In User Server (RADIUS)", RFC 2865, June 427 2000. 429 [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 431 [3] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", 432 RFC 2869, June 2000. 434 [4] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B., 435 ÷Dynamic Authorization Extensions to Remote Authentication 436 Dial In User Service (RADIUS)÷, RFC 3576, July 2003. 438 AuthorsĖ Addresses 440 Farid Adrangi 441 Email: farid.adrangi@intel.com Phone:+1 503-712-1791 443 Avi Lior 444 Email: avi@bridgewatersystems.com 446 Jouni Korhonen 447 Email: jouni.korhonen@teliasonera.com 449 Full Copyright Statement 451 Copyright (C) The Internet Society (2002). All Rights 452 Reserved. 454 This document and translations of it may be copied and 455 furnished to others, and derivative works that comment on or 456 otherwise explain it or assist in its implementation may be 457 prepared, copied, published and distributed, in whole or in 458 part, without restriction of any kind, provided that the above 459 copyright notice and this paragraph are included on all such 460 copies and derivative works. However, this document itself may 461 not be modified in any way, such as by removing the copyright 462 notice or references to the Internet Society or other Internet 463 organizations, except as needed for the purpose of developing 464 Internet standards in which case the procedures for copyrights 465 defined in the Internet Standards process must be followed, or 466 as required to translate it into languages other than English. 468 The limited permissions granted above are perpetual and will 469 not be revoked by the Internet Society or its successors or 470 assigns. 472 This document and the information contained herein is provided 473 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 474 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 475 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 476 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 477 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 478 PARTICULAR PURPOSE. 480 Acknowledgement 482 Funding for the RFC Editor function is currently provided by 483 the Internet Society.