idnits 2.17.1 draft-halwasia-radext-capability-negotiation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2012) is 4215 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) == Outdated reference: A later version (-13) exists of draft-ietf-radext-radius-extensions-06 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. DeKok 3 Internet-Draft FreeRADIUS 4 Intended status: Standards Track G. Halwasia 5 Expires: April 11, 2013 S. Danda 6 M. Kumar 7 Cisco Systems 8 October 8, 2012 10 Capability Negotiation in RADIUS 11 draft-halwasia-radext-capability-negotiation-01 13 Abstract 15 This document describes procedure and mechanism to exchange and 16 negotiate capabilities between RADIUS client and RADIUS server. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 RADIUS-specific terminology is borrowed from [RFC2865] and [RFC2866]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 11, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Solution Description . . . . . . . . . . . . . . . . . . . 3 62 2. RADIUS Packets . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Capability-Request RADIUS Packet . . . . . . . . . . . . . 3 64 2.2. Capability-Response RADIUS Packet . . . . . . . . . . . . 4 65 3. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Capability-Add Attribute . . . . . . . . . . . . . . . . . 6 67 3.2. Capability-Withdraw Attribute . . . . . . . . . . . . . . 6 68 3.3. Capability-Ack Attribute . . . . . . . . . . . . . . . . . 7 69 4. RADIUS Capability-Id . . . . . . . . . . . . . . . . . . . . . 8 70 5. RADIUS Client Behavior . . . . . . . . . . . . . . . . . . . . 8 71 6. RADIUS Server Behavior . . . . . . . . . . . . . . . . . . . . 9 72 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. New Registry: Capability-Identifier . . . . . . . . . . . 10 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Remote Authentication Dial In User Service (RADIUS) [RFC2865] and 85 [RFC2866] is widely used protocol for Authentication, Authorization 86 and Accounting. There are quite a lot of extensions which are being 87 done on RADIUS protocol and considering that RADIUS is being deployed 88 quite extensively, it would be nice if RADIUS Client and Server can 89 negotiate the capability to support those extensions. This 90 specification recommends and envision each proposed capability to be 91 as precise and narrowly defined as possible and having said that we 92 envision fairly large number of capabilities rather than few broadly 93 defined ones. For example [I-D.ietf-radext-radius-extensions] 94 proposes extended attributes space along with few other extensions 95 and it would be nice if RADIUS Client and Server can signal and 96 negotiate support for 'extended attributes'. This document describes 97 procedure and mechanism to exchange and negotiate capabilities 98 between RADIUS client and RADIUS server. 100 1.1. Solution Description 102 This specification proposes to define two new RADIUS packet types to 103 negotiate capabilities between RADIUS client and RADIUS server as 104 defined in section 2. It also proposes to define 3 new attributes to 105 be carried inside new RADIUS packet types. New RADIUS packets to 106 negotiate capability has been chosen as it has minimal impact on the 107 RADIUS security model and existing implementations. Following 108 sections describes the new RADIUS packet types and attributes and 109 describes their usage in negotiating capabilities. As per this 110 specification Capability-Request RADIUS packets MUST NOT be proxied. 112 2. RADIUS Packets 114 This document defines following new RADIUS packet type to enable 115 capability negotiation between RADIUS client and server. 117 2.1. Capability-Request RADIUS Packet 118 Capability-Request RADIUS Packets are sent to a RADIUS server to 119 convey the capabilities RADIUS client intends to add and withdraw. 121 A summary of the Capability-Request packet format is shown below. 122 The fields are transmitted from left to right. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Code | Identifier | Length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 | Request Authenticator | 131 | | 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Attributes ... 135 +-+-+-+-+-+-+-+-+-+-+-+-+- 137 Code 139 TBA1 - Capability-Request. 141 Identifier 143 The Identifier field MUST be changed whenever the content of the 144 Attributes field changes, and whenever a valid reply has been 145 received for a previous request. For retransmissions, the 146 Identifier MUST remain unchanged. 148 Request Authenticator 150 The Request Authenticator value MUST be changed each time a new 151 Identifier is used. It is calculated the same way as calculated 152 for Access-Request RADIUS Packet as described in section 3 of 153 RFC2865. 155 Attributes 157 The Attribute field is variable in length, and contains the list 158 of Attributes that are required. 160 2.2. Capability-Response RADIUS Packet 161 Capability-Withdraw RADIUS Packets are sent to a RADIUS client in 162 response to Capability-Request packet from RADIUS client. 164 A summary of the Capability-Withdraw packet format is shown below. 165 The fields are transmitted from left to right. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Code | Identifier | Length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 | Response Authenticator | 174 | | 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Attributes ... 178 +-+-+-+-+-+-+-+-+-+-+-+-+- 180 Code 182 TBA2 - Capability-Response. 184 Identifier 186 The Identifier field is a copy of the Identifier field of the 187 Capability-Request which caused this Capability-Response. 189 Response Authenticator 191 The Response Authenticator value is calculated from the 192 Capability-Request value. It is calculated the same way 193 as calculated for Access-Accept RADIUS Packet similar to 194 as described in section 3 of RFC2865. 196 Attributes 198 The Attribute field is variable in length, and contains the list 199 of Attributes that are required. 201 3. RADIUS Attributes 203 This document defines following new RADIUS attributes to enable 204 capability negotiation between RADIUS client and server. 206 3.1. Capability-Add Attribute 208 This attribute indicates the capability which the client wants to add. 210 The format of the Capability-Add Attribute is: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type | Length | Value | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Value (cont.) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Type 222 TBA3 - Capability-Add 224 Length 226 6 228 Value 230 Enumerated Data Type in 4-Octet unsigned integer defined in 231 [RFC6158]. This field contains the capability-id as specified 232 in section 4 of this document. 234 3.2. Capability-Withdraw Attribute 235 This attribute indicates the capability which the client wants to 236 withdraw. 238 The format of the Capability-Withdraw Attribute is: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type | Length | Value | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Value (cont.) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Type 250 TBA4 - Capability-Withdraw 252 Length 254 6 256 Value 258 Enumerated Data Type in 4-Octet unsigned integer defined in 259 [RFC6158]. This field contains the capability-id as specified 260 in section 4 of this document. 262 3.3. Capability-Ack Attribute 263 This attribute indicates the capability which the server wants to 264 Acknowledge. 266 The format of the Capability-Ack Attribute is: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Length | Value | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Value (cont.) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Type 278 TBA5 - Capability-Ack 280 Length 282 6 284 Value 286 Enumerated Data Type in 4-Octet unsigned integer defined in 287 [RFC6158]. This field contains the capability-id as specified 288 in section 4 of this document. 290 4. RADIUS Capability-Id 292 Value field of Capability-Add and Capability-Withdraw attributes 293 defined above contains the Capability-Id of the capability RADIUS 294 client wants to negotiate with RADIUS server. This document does not 295 define any new capability and it's associated Capability-Id. Any 296 specification which wants to use this mechanism of capability 297 negotiation MUST define a new capability. Each new capability MUST 298 be registered with IANA to get a capability-id from capability-id 299 registry. 301 5. RADIUS Client Behavior 303 RADIUS Client willing to negotiate capabilities SHOULD send 304 Capability-Request RADIUS Packet (defined in section 2) towards the 305 RADIUS Server. RADIUS Client MUST include Capability-Add Attribute 306 in Capability-Request RADIUS Packet for the capability client wants 307 to add/negotiate. Client can also include Capability-Withdraw 308 Attribute in the RADIUS packet in case it wants to withdraw the 309 capability it has negotiated earlier. Client MUST NOT add the 310 Capability-Withdraw Attribute in the Capability-Request RADIUS Packet 311 in case it has not negotiated the corresponding attribute earlier. 312 Client can include multiple Capability-Add and/or Capability-Withdraw 313 Attributes in the same Capability-Request RADIUS Packet. RADIUS 314 client MUST add atleast one Capability-Add and/or Capability-Withdraw 315 Attribute in Capability-Request RADIUS Packet. Client MUST NOT 316 include the Capability-Add and Capability-Withdraw Attribute for the 317 same capability in the same Capability-Request RADIUS Packet. 319 Apart from including Capability-Add and/or Capability-Withdraw 320 Attributes in the Capability-Request RADIUS Packet, Client can 321 include NAS-Identifier [RFC2865] or one of the NAS-IP- 322 Address[RFC2865]/NAS-IPv6-Address [RFC3162] for the porpose of RADIUS 323 server to identify client. 325 6. RADIUS Server Behavior 327 RADIUS Server implementing this specification MUST respond back with 328 Capability-Response RADIUS Packet after receiving a valid Capability- 329 Request RADIUS Packet from the RADIUS Client. As specified in 330 section 5, Client will advertise it's capabilities by including 331 Capability-Add and/or Capability-Withdraw Attributes in the same 332 Capability-Request RADIUS Packet. RADIUS Server will find out the 333 common set of agreed upon capabilities based upon the intersection in 334 between capabilities received from client and it's own capabilities. 335 RADIUS Server MUST include a Capability-Ack Attribute for each of the 336 agreed upon capabilities in the Capability-Response RADIUS Packet. 337 RADIUS Server MUST NOT include Capability-Ack attributes for all 338 those capabilities which is does not want to support/share with 339 RADIUS Client. If the RADIUS Server does not support any of the 340 capabilities specified in Capability-Request RADIUS Packet, it SHOULD 341 send back a empty Capability-Response RADIUS Packet without including 342 any Capability-Ack attribute. 344 RADIUS Server implementation which does not support capability 345 negotiation specified in this specification MUST silently discard 346 Capability-Request RADIUS Packet received from RADIUS Client. 348 7. Example 350 Following example figure shows the sequence of message exchanges 351 which happens between RADIUS Client and RADIUS Server to negotiate a 352 capabilities. 354 +-+-+-+-+-+ +-+-+-+-+-+ 355 | CLIENT | | SERVER | 356 +-+-+-+-+-+ +-+-+-+-+-+ 357 | | 358 | Capability-Request(Capability-Add(X),Capability-Add(Y), | 359 | NAS-IP-Address) | 360 |-------------------------------------------------------->| 361 | | 362 | Capability-Response(Capability-Ack(Y)) | 363 |<--------------------------------------------------------| 365 Figure 1: Capability Negotiation between Client and Server 367 Capability X = 'Understands 64-Bit Integers' 369 Capability Y = 'Supports Larger than 4K RADIUS packets' 371 8. IANA Considerations 373 The authors request that Packet Type, Attribute Types and Attribute 374 Values defined in this document be registered by by the Internet 375 Assigned Numbers Authority (IANA) from the RADIUS namespaces as 376 described in the "IANA Considerations" section of RFC 3575 [RFC3575], 377 in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes 378 and registries created by this document IANA is requested to place 379 them at http://www.iana.org/assignments/radius-types. 381 This document defines the following RADIUS messages: 382 - Capability-Request 384 - Capability-Response 386 This document defines the following attributes: 387 - Capability-Add 389 - Capability-Withdraw 391 - Capability-Ack 393 Additionally, IANA is requested to create the following new 394 registries listed in the subsections below. 396 8.1. New Registry: Capability-Identifier 398 This document also defines an Capabality-Identifier registry (used in 399 the value field of Capability-Add, Capability-Withdraw and 400 Capability-Ack Attributes). IANA is requested to just allocate space 401 for this registry and this document does not request IANA to allocate 402 any value from this registry. 404 Requests to IANA for a new value for a Capability Identifier will be 405 approved by Expert Review. A designated expert will be appointed by 406 the IESG. 408 9. Security Considerations 410 This document defines new RADIUS message types and new Attribute 411 types, but otherwise makes no changes to the security of the RADIUS 412 protocol. 414 10. Acknowledgements 416 11. References 418 11.1. Normative References 420 [I-D.ietf-radext-radius-extensions] 421 DeKok, A. and A. Lior, "Remote Authentication Dial In User 422 Service (RADIUS) Protocol Extensions", 423 draft-ietf-radext-radius-extensions-06 (work in progress), 424 June 2012. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 430 "Remote Authentication Dial In User Service (RADIUS)", 431 RFC 2865, June 2000. 433 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 434 RFC 3162, August 2001. 436 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 437 Authentication Dial In User Service)", RFC 3575, 438 July 2003. 440 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 441 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 442 May 2008. 444 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", 445 BCP 158, RFC 6158, March 2011. 447 11.2. Informative References 449 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 451 Authors' Addresses 453 Alan DeKok 454 FreeRADIUS 456 Phone: 457 Email: aland@deployingradius.com 459 Gaurav Halwasia 460 Cisco Systems 461 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 462 Bangalore, KARNATAKA 560 087 463 India 465 Phone: +91 80 4429 2703 466 Email: ghalwasi@cisco.com 468 Satyanarayana Danda 469 Cisco Systems 470 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 471 Bangalore, KARNATAKA 560 087 472 India 474 Phone: +91 80 4429 2684 475 Email: sdanda@cisco.com 477 Manoj Kumar 478 Cisco Systems 479 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 480 Bangalore, KARNATAKA 560 087 481 India 483 Phone: +91 80 4429 2635 484 Email: magoyal@cisco.com