idnits 2.17.1 draft-zorn-radius-keyreq-09.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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 488. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- 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 (February 21, 2008) is 5908 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 (-10) exists of draft-zorn-radius-err-msg-09 -- Possible downref: Normative reference to a draft: ref. 'ERRMSG' == Outdated reference: A later version (-18) exists of draft-zorn-radius-keywrap-13 ** Downref: Normative reference to an Informational draft: draft-zorn-radius-keywrap (ref. 'KEYWRAP') ** Downref: Normative reference to an Informational draft: draft-zorn-radius-logoff (ref. 'LOGOFF') ** Downref: Normative reference to an Informational RFC: RFC 2869 Summary: 4 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 G. Zorn, Ed. 3 Internet-Draft Aruba Networks 4 Updates: 2865 (if approved) H. Zhou 5 Intended status: Standards Track J. Salowey 6 Expires: August 24, 2008 Cisco Systems 7 February 21, 2008 9 Session Key Transport in RADIUS 10 draft-zorn-radius-keyreq-09.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 24, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes an extension to the RADIUS protocol designed 44 to support requests for, and delivery of, session key material 45 between RADIUS clients and servers. 47 The messages described in this document may be used for a wide 48 variety of keying applications. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 54 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Key-Request . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.2. Key-Response . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Intellectual Property and Copyright Statements . . . . . . . . . . 12 64 1. Introduction 66 AAA servers are a central repository of authentication credentials. 67 Since authentication is typically a prerequisite to key distribution, 68 it is natural for AAA servers to be able to deliver keys to clients 69 for various purposes. One example of this is the provisioning of the 70 link layer encryption keys used in IEEE 802.11 and 802.1X. There is a 71 wide variety of additional uses for key distribution in RADIUS. 73 This document describes an extension to the RADIUS protocol designed 74 to support requests for, and delivery of, session key material 75 between RADIUS clients and servers. One example of the applicability 76 of these extensions is the case where the end of a session key's 77 lifetime [KEYWRAP] is approaching, but the messages described in this 78 document may be used for a wide variety of keying applications. 80 Discussion of this draft may be directed to the authors. 82 2. Specification of Requirements 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Packet Format 90 Exactly one RADIUS packet is encapsulated in the UDP Data field 91 [RFC0768] where the UDP Destination Port field indicates 1812 92 (decimal). 94 When a reply is generated, the source and destination ports are 95 reversed. 97 A summary of the RADIUS data format is shown below. The fields are 98 transmitted from left to right. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Code | Identifier | Length | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | | 106 | Authenticator | 107 | | 108 | | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Attributes ... 111 +-+-+-+-+-+-+-+-+-+-+-+-+- 113 Code 115 The Code field is one octet, and identifies the type of RADIUS 116 packet. 118 If a RADIUS server receives a packet with an unrecognized Code 119 field, the server SHOULD respond with an Error-Notification 120 message containing instances of the Error-Code and Unrecognized- 121 Packet-Type Attributes [ERRMSG]; if the server does not support 122 the Error-Notification message, then the invalid packet MUST be 123 silently discarded. 125 If a RADIUS client receives a packet with an unrecognized Code 126 field, the client SHOULD post a RADIUS Accounting-Request message 127 with the Acct-Status-Type Attribute set to Acct-Error-Notification 128 containing instances of the Error-Code and Unrecognized-Packet- 129 Type Attributes [ERRMSG]. The invalid packet MUST be discarded. 131 The RADIUS Codes (decimal) defined in this document are as 132 follows: 134 Key-Request 136 Key-Response 138 Identifier 140 The Identifier field is one octet, and aids in matching requests 141 and replies. The RADIUS server can detect a duplicate request if 142 it has the same client source IP address, source UDP port and 143 Identifier within a short span of time. 145 Length 147 The Length field is two octets. It indicates the length of the 148 packet including the Code, Identifier, Length, Authenticator and 149 Attribute fields. Octets outside the range of the Length field 150 MUST be treated as padding and ignored on reception. If the 151 packet is shorter than the Length field indicates, it MUST be 152 silently discarded. The minimum length is 20 and maximum length 153 is 4096. 155 Authenticator 157 The Authenticator field is sixteen (16) octets. The most 158 significant octet is transmitted first. This value is used to 159 authenticate the reply from the RADIUS server. 161 Since the Message-Authentication-Code Attribute [KEYWRAP] is 162 required to be present in both the Key-Request and the Key- 163 Response messages, the client and server MAY ignore the contents 164 of the Authenticator field. In any case, the validity of the of 165 the Authenticator field MUST NOT affect the evaluation of the 166 integrity of the message. 168 Request Authenticator 170 In Key-Request packets, the Authenticator value is a 16 octet 171 random number, called the Request Authenticator. The value 172 SHOULD be unpredictable and unique over the lifetime of a 173 secret (the password shared between the client and the RADIUS 174 server), since repetition of an authenticator value in 175 conjunction with the same secret would permit an attacker to 176 reply with a previously intercepted response. Since it is 177 expected that the same secret MAY be used to authenticate with 178 servers in disparate geographic regions, the Request 179 Authenticator field SHOULD exhibit global and temporal 180 uniqueness. 182 The Authenticator value in a Key-Request packet SHOULD also be 183 unpredictable, lest an attacker trick a server into responding 184 to a predicted future request, and then use the response to 185 masquerade as that server to a future notification packet. 187 Although protocols such as RADIUS are incapable of protecting 188 against theft of an authenticated session via real-time active 189 wiretapping attacks, generation of unique unpredictable 190 requests can protect against a wide range of active attacks 191 against authentication. 193 Response Authenticator 195 The value of the Authenticator field in the Key-Response packet 196 is called the Response Authenticator, and contains a one-way 197 MD5 hash calculated over a stream of octets consisting of: the 198 RADIUS packet, beginning with the Code field, including the 199 Identifier, the Length, the Request Authenticator field from 200 the Key-Request packet, and the response Attributes, followed 201 by the shared secret. That is, 203 Acknowledgement Auth = 204 MD5(Code+ID+Length+RequestAuth+Attributes+Secret) 206 where '+' denotes concatenation. 208 Administrative Note 210 The secret shared between the client and the RADIUS server SHOULD 211 be at least as large and unguessable as a well- chosen password. 212 It is preferred that the secret be at least 16 octets. This is to 213 ensure a sufficiently large range for the secret to provide 214 protection against exhaustive search attacks. The secret MUST NOT 215 be empty (length 0) since this would allow packets to be trivially 216 forged. 218 A RADIUS server MUST use the source IP address of the RADIUS UDP 219 packet to decide which shared secret to use, so that RADIUS 220 requests can be proxied. 222 When using a forwarding proxy, the proxy must be able to alter the 223 packet as it passes through in each direction - when the proxy 224 forwards the request, the proxy MAY add a Proxy-State Attribute, 225 and when the proxy forwards a response, it MUST remove its Proxy- 226 State Attribute if it added one. Proxy-State is always added or 227 removed after any other Proxy-States, but no other assumptions 228 regarding its location within the list of attributes can be made. 229 Since Key-Response packets are authenticated on the entire packet 230 contents, the stripping of the Proxy-State attribute invalidates 231 the signature in the packet - so the proxy has to re-sign it. 233 Further details of RADIUS proxy implementation are outside the 234 scope of this document. 236 4. Packet Types 238 The RADIUS Packet type is determined by the Code field in the first 239 octet of the Packet. 241 4.1. Key-Request 243 Description 245 Key-Request packets are sent to a RADIUS server to request the 246 delivery of a session key. A RADIUS client wishing to request the 247 delivery of a session key MUST transmit a RADIUS packet with the 248 Code field set to (Key-Request). 250 Upon receipt of an Key-Request packet from a valid client, the 251 server MUST reply using either a Key-Response message or a Error- 252 Notification message [ERRMSG]. 254 A Key-Request message MUST contain either a NAS-IP-Address 255 Attribute [RFC2865] or a NAS-Identifier Attribute [RFC2865] or 256 both. To help defeat spoofing attacks, a Key-Request message MUST 257 contain either a Message-Authenticator Attribute [RFC2869] or a 258 Message-Authentication-Code Attribute [KEYWRAP]. 260 A Key-Request message SHOULD contain a Session-Id Attribute 261 [LOGOFF] if one was returned from the server in the Access-Accept 262 message for the session; if no Session-Id Attribute is included, 263 the packet MUST contain a User-Name Attribute and such additional 264 Attributes as are necessary to positively identify a given user 265 session (e.g., Service-Type [RFC2865], Calling-Station-Id 266 [RFC2865], etc.). 268 A Key-Request packet MAY contain one or more Key Attributes 269 [KEYWRAP] in order to request a key with a particular identifier 270 or encrypted using a particular algorithm. 272 A summary of the Key-Request packet format is shown below. The 273 fields are transmitted from left to right. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Code | Identifier | Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 | Request Authenticator | 282 | | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Attributes ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+- 288 Code 290 for Key-Request 292 Identifier 294 The Identifier field MUST be changed whenever the content of the 295 Attributes field changes, and whenever a valid reply has been 296 received for a previous request. For retransmissions, the 297 Identifier MUST remain unchanged. 299 Request Authenticator 301 The Request Authenticator value MUST be changed each time a new 302 Identifier is used. 304 Implementation Note 306 Since the Message-Authentication-Code Attribute [KEYWRAP] is 307 required to be present in the Key-Request message, the server 308 MAY ignore the contents of the Request Authenticator. In any 309 case, the validity of the of the Request Authenticator field 310 MUST NOT affect the evaluation of the integrity of the request. 312 Attributes 314 The Attribute field is variable in length, and contains the list 315 of required Attributes, as well as any desired optional 316 Attributes. 318 4.2. Key-Response 320 Description 322 A Key-Response packet is sent by a RADIUS server in response to a 323 Key-Request packet. A RADIUS server wishing to transfer keying 324 material to a client in response to a Key-Request packet MUST 325 transmit a RADIUS packet with the Code field set to (Key- 326 Response). 328 At least one Key Attribute [KEYWRAP] MUST be included in a Key- 329 Response packet. 331 A summary of the Key-Response packet format is shown below. The 332 fields are transmitted from left to right. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Code | Identifier | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 | Response Authenticator | 341 | | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Attributes ... 345 +-+-+-+-+-+-+-+-+-+-+-+-+- 347 Code 349 for Key-Response 351 Identifier 353 The Identifier field is a copy of the Identifier field of the Key- 354 Request packet which caused this Key-Response packet to be 355 created. 357 Response Authenticator 359 The Response Authenticator value is calculated from the Key- 360 Request packet, as described above. 362 Implementation Note 364 Since the Message-Authentication-Code Attribute [KEYWRAP] is 365 required to be present in the Key-Response message, the client 366 MAY ignore the contents of the Response Authenticator. In any 367 case, the validity of the of the Response Authenticator field 368 MUST NOT affect the evaluation of the integrity of the message. 370 Attributes 372 The Attribute field is variable in length, and MAY contain any 373 desired optional Attributes in addition to the required 374 Attributes. 376 5. IANA Considerations 378 The criteria to be used by the Internet Assigned Numbers Authority 379 (IANA) for assignment of numbers within namespaces defined within 380 this document are identical to those given in [RFC3575]. 382 6. Security Considerations 384 If the key used in the generation of the Message-Authentication-Code 385 Attribute is compromised, an attacker might be able to modify or 386 replace the keying material. 388 7. Normative References 390 [ERRMSG] Zorn, G., "RADIUS Error Messages", 391 draft-zorn-radius-err-msg-09.txt (work in progress), 392 February 2008. 394 [KEYWRAP] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "RADIUS 395 Attributes for the Delivery of Keying Material", 396 draft-zorn-radius-keywrap-13.txt (work in progress), 397 February 2008. 399 [LOGOFF] Zorn, G. and A. Lior, "User Session Tracking in RADIUS", 400 draft-zorn-radius-logoff-11.txt (work in progress), 401 February 2008. 403 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 404 August 1980. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 410 "Remote Authentication Dial In User Service (RADIUS)", 411 RFC 2865, June 2000. 413 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 414 Extensions", RFC 2869, June 2000. 416 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 417 Authentication Dial In User Service)", RFC 3575, 418 July 2003. 420 Authors' Addresses 422 Glen Zorn (editor) 423 Aruba Networks 424 1322 Crossman Avenue 425 Sunnyvale, CA 94089-1113 426 USA 428 Email: gwz@arubanetworks.com 430 Hao Zhou 431 Cisco Systems 432 4125 Highlander Parkway 433 REQ01/3/ 434 Richfield, OH 44286 435 US 437 Phone: +1 (330) 523-2132 438 Email: hzhou@cisco.com 440 Joseph Salowey 441 Cisco Systems 442 2901 Third Avenue 443 SEA1/6/ 444 Seattle, WA 98121 445 US 447 Phone: +1 (206) 256-3380 448 Email: jsalowey@cisco.com 450 Full Copyright Statement 452 Copyright (C) The IETF Trust (2008). 454 This document is subject to the rights, licenses and restrictions 455 contained in BCP 78, and except as set forth therein, the authors 456 retain all their rights. 458 This document and the information contained herein are provided on an 459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 461 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 462 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 463 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Intellectual Property 468 The IETF takes no position regarding the validity or scope of any 469 Intellectual Property Rights or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; nor does it represent that it has 473 made any independent effort to identify any such rights. Information 474 on the procedures with respect to rights in RFC documents can be 475 found in BCP 78 and BCP 79. 477 Copies of IPR disclosures made to the IETF Secretariat and any 478 assurances of licenses to be made available, or the result of an 479 attempt made to obtain a general license or permission for the use of 480 such proprietary rights by implementers or users of this 481 specification can be obtained from the IETF on-line IPR repository at 482 http://www.ietf.org/ipr. 484 The IETF invites any interested party to bring to its attention any 485 copyrights, patents or patent applications, or other proprietary 486 rights that may cover technology that may be required to implement 487 this standard. Please address the information to the IETF at 488 ietf-ipr@ietf.org. 490 Acknowledgment 492 Funding for the RFC Editor function is provided by the IETF 493 Administrative Support Activity (IASA).