idnits 2.17.1 draft-zorn-radius-keywrap-18.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2011) is 4853 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Informational T. Zhang 5 Expires: July 16, 2011 Advista Technologies 6 J. Walker 7 Intel Corporation 8 J. Salowey 9 Cisco Systems 10 January 12, 2011 12 Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying 13 Material 14 draft-zorn-radius-keywrap-18.txt 16 Abstract 18 This document defines a set of vendor specific RADIUS Attributes 19 designed to allow both the secure transmission of cryptographic 20 keying material and strong authentication of any RADIUS message. 21 This attributes have been allocated from the Cisco vendor specific 22 space and have been implemented by multiple vendors. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 16, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 72 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. Keying-Material . . . . . . . . . . . . . . . . . . . . . 6 74 3.2. MAC-Randomizer . . . . . . . . . . . . . . . . . . . . . . 10 75 3.3. Message-Authentication-Code . . . . . . . . . . . . . . . 11 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 This document defines a set of vendor specific RADIUS Attributes, 88 allocated from the Cisco vendor space, that can be used to securely 89 transfer cryptographic keying material using standard techniques with 90 well understood security properties. In addition, the Message- 91 Authentication-Code Attribute may be used to provide strong 92 authentication for any RADIUS message, including those used for 93 accounting and dynamic authorization. 95 These attributes were designed to provide stronger protection and 96 more flexibility than the currently defined Vendor Specific MS-MPPE- 97 Send-Key and MS-MPPE-Recv-Key attributes in [RFC2548] and the 98 Message-Authenticator attribute in [RFC3579]. 100 Many remote access deployments (for example, deployments utilizing 101 wireless LAN technology) require the secure transmission of 102 cryptographic keying material from a RADIUS [RFC2865] server to a 103 network access point. This material is usually produced as a by- 104 product of an EAP [RFC3748] authentication and returned in the 105 Access-Accept message following a successful authentication process. 106 The keying material is of a form that may be used in virtually any 107 cryptographic algorithm after appropriate processing. These 108 attributes may also be used in other cases where a AAA server needs 109 to deliver keying material to a network access point. 111 Discussion of this document may be directed to the authors. 113 2. Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Attributes 121 The following subsections describe sub-attributes which are 122 transmitted in RADIUS attributes of type Vendor-Specific [RFC2865]. 123 The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be set 124 to decimal 9 (Cisco). The general format of the attributes is: 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type (26) | Length | Vendor ID 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Vendor ID (cont'd) | Sub-type (1)| Sub-length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Value... 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Type 138 26 for vendor specific 140 Length 142 Length of entire attribute including type and length field 144 Vendor ID 146 4 octets encoding the Cisco Vendor ID of 9 148 Sub-type 150 Attribute sub-type of 1 152 Sub-length 154 Length of the sub attribute including the sub-type and sub- 155 length fields 157 Value 159 Value of the sub attribute. 161 This specification concerns the following sub-attributes: 163 o Keying-Material 165 o MAC-Randomizer 167 o Message-Authentication-Code 169 3.1. Keying-Material 171 Description 173 This Attribute MAY be used to transfer cryptographic keying 174 material from a RADIUS server to a client. 176 It MAY be sent in request messages (e.g., Access-Request, etc.), 177 as well; if the Keying-Material Attribute is present in a request, 178 it SHOULD be taken as a hint by the server that the client prefers 179 this method of key delivery over others, the server is not 180 obligated to honor the hint, however. When the Keying-Material 181 Attribute is included in a request message the KM ID, KEK ID, 182 Lifetime, IV and Key Material Data fields MAY be omitted. 184 In environments where the the Keying-Material attribute is known 185 to be supported or in cases where the client wants to avoid roll- 186 back attacks the client MAY be configured to require the use of 187 the Keying-Material Attribute. If the client requires the use of 188 the Keying-Material Attribute for keying material delivery and it 189 is not present in the Access-Accept or Access-Challenge message, 190 the client MAY ignore the message in question and end the user 191 session. 193 Any packet that contains a Keying-Material Attribute MUST also 194 include the Message-Authentication-Code Attribute. 196 Any packet that contains an instance of the Keying-Material 197 Attribute MUST NOT contain an instance of any other attribute 198 (e.g., MS-CHAP-MPPE-Keys [RFC2548], Tunnel-Password [RFC2868], 199 etc.) encapsulating identical keying material. 201 The Keying-Material Attribute MUST NOT be used to transfer long- 202 lived keys (i.e., passwords) between RADIUS servers and clients. 204 A summary of the Keying-Material attribute format is shown below. 205 The fields are transmitted from left to right. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type (26) | Length | Vendor ID 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Vendor ID (cont'd) | Sub-type (1)| Sub-length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | String ID ("radius:app-key=") 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 String ID (cont'd) 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 String ID (cont'd) 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 String ID (cont'd) | Enc Type | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | App ID | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | KEK ID 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 KEK ID (cont'd) 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 KEK ID (cont'd) 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 KEK ID (cont'd) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | KM ID 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 KM ID (cont'd) 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 KM ID (cont'd) 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 KM ID (cont'd) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Lifetime | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | IV 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 IV (cont'd) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Keying Material Data 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Type 251 26 for vendor specific 253 Length 255 Length of entire attribute including type and length field 257 Vendor ID 259 4 octets encoding the Cisco Vendor ID of 9 261 Sub-type 263 Attribute sub-type of 1 265 Sub-length 267 Length of the sub attribute including the sub-type and sub- 268 length fields 270 String-ID 272 The ASCII characters "radius:app-key=" without quotes or null 273 termination. 275 Enc Type 277 The Enc Type field indicates the method used to encrypt the 278 contents of the Data field. This document defines only one 279 value (decimal) for this field: 281 0 AES Key Wrap with 128-bit KEK [RFC3394] 283 Implementations MUST support Enc Type 0 (AES Key Wrap with 128- 284 bit KEK). 286 Implementation Note 288 A shared secret is used as the key-encrypting-key (KEK) for 289 the AES key wrap algorithm. Implementations SHOULD provide 290 a means to provision a key (cryptographically separate from 291 the normal RADIUS shared secret) to be used exclusively as a 292 KEK. 294 App ID 296 The App ID field is 4 octets in length and identifies the type 297 of application for which the key material is to be used. This 298 allows for multiple keys for different purposes to be present 299 in the same message. This document defines two values for the 300 App ID: 302 0 Reserved 304 1 EAP MSK 306 KEK ID 308 The KEK ID field is 16 octets in length. The combination of 309 the KEK ID and the client and server IP addresses together 310 uniquely identify a key shared between the RADIUS client and 311 server. As a result, the KEK ID need not be globally unique. 312 The KEK ID MUST refer to an encryption key of a type and length 313 appropriate for use with the algorithm specified by the Enc 314 Type field (see above). This key is used to protect the 315 contents of the Data field (below). The KEK ID is a constant 316 that is configured through an out-of-band mechanism. The same 317 value is configured on both the RADIUS client and server. If 318 no KEK ID is configured then the field is set to 0. If only a 319 single KEK is configured for use between a given RADIUS client 320 and server, then 0 can be used as the default value. 322 KM ID 324 The KM ID field is 16 octets in length and contains an 325 identifier for the contents of the Data field. The KM ID MAY 326 be used by communicating parties to identify the material being 327 transmitted. The combination of App ID and KM ID MUST uniquely 328 identify the keying material between the parties utilizing it. 329 The KM ID is assumed to be known to the parties that derived 330 the keying material. If the KM ID is not used it is set to 0. 331 The KM ID for the EAP MSK application is set to 0. Another 332 application can be defined in the future which uses the KM ID 333 field. 335 Lifetime 337 The Lifetime field is an integer [RFC2865] representing the 338 period of time (in seconds) for which the keying material is 339 valid. 341 Note: Applications using this value SHOULD consider the 342 beginning of the lifetime to be the point in time when the 343 keying material is first used. 345 IV 347 The length of the IV field depends upon the value of the Enc 348 Type field, but is fixed for any given value thereof. When the 349 value of the Enc Type field is 0 (decimal), the IV field MUST 350 be 8 octets in length (as illustrated above) and the value of 351 the IV field MUST be as specified in [RFC3394]. If the IV for 352 Enc Type 0 does not match [RFC3394] then the receiver MUST NOT 353 use the key material from this attribute. 355 Keying Material Data 357 The Keying Material Data field is variable length and contains 358 the actual encrypted keying material. 360 3.2. MAC-Randomizer 362 Description 364 The MAC-Randomizer Attribute MUST be present in any message that 365 includes an instance of the Message-Authentication-Code Attribute. 366 The Random field MUST contain a 32 octet random number which 367 SHOULD satisfy the requirements of [RFC4086]. 369 Implementation Note 371 The Random field MUST be filled in before the MAC is computed. 372 The MAC-Randomizer Attribute SHOULD be placed at the beginning 373 of the RADIUS message if possible. 375 A summary of the MAC-Randomizer attribute format is shown below. 376 The fields are transmitted from left to right. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type (26) | Length | Vendor ID 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Vendor ID (cont'd) | Sub-type (1)| Sub-length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | String ID ("radius:random-nonce=") 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 String ID (cont'd) 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 String ID (cont'd) 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 String ID (cont'd) 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 String ID (cont'd) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Random... 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Type 399 26 for vendor specific 401 Length 403 Length of entire attribute including type and length field 405 Vendor ID 407 4 octets encoding the Cisco Vendor ID of 9 409 Sub-type 411 Attribute sub-type of 1 413 Sub-length 415 Length of the sub attribute including the sub-type and sub- 416 length fields 418 String-ID 420 The ASCII characters "radius:random-nonce=" without quotes or 421 null termination. 423 Random 425 This field MUST contain a 32 octet random number which SHOULD 426 satisfy the requirements of [RFC4086]. 428 3.3. Message-Authentication-Code 430 Description 432 This Attribute MAY be used to "sign" messages to prevent spoofing. 433 If it is present in a request, the receiver should take this a 434 hint that the sender prefers the use of this Attribute for message 435 authentication; the receiver is not obligated to do so, however. 437 The Message-Authentication-Code Attribute MUST be included in any 438 message that contains a Keying-Material attribute. 440 If both the Message-Authentication-Code and Message-Authenticator 441 Attributes are to be included in a message (e.g., for backward 442 compatibility in a network containing both old and new clients), 443 the value of the Message-Authentication-Code Attribute MUST be 444 computed first. 446 If any message is received containing an instance of the Message- 447 Authentication-Code Attribute, the receiver MUST calculate the 448 correct value of the Message-Authentication-Code and silently 449 discard the packet if the computed value does not match the value 450 received. 452 If a received message contains an instance of the MAC-Randomizer 453 Attribute (Section 3.2), the received MAC-Randomizer Attribute 454 SHOULD be included in the computation of the Message- 455 Authentication-Code Attribute sent in the response, as described 456 below. 458 A summary of the Message-Authentication-Code attribute format is 459 shown below. The fields are transmitted from left to right. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type (26) | Length | Vendor ID 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Vendor ID (cont'd) | Sub-type (1)| Sub-length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | String ID ("radius:message-authenticator-code=") 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 String ID (cont'd) 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 String ID (cont'd) 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 String ID (cont'd) 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 String ID (cont'd) 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 String ID (cont'd) 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 String ID (cont'd) 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 String ID (cont'd) 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 String ID (cont'd) | MAC Type | MAC Key ID 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | MAC Key ID (cont'd) 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 MAC Key ID (cont'd) 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 MAC Key ID (cont'd) 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 MAC Key ID (cont'd) | MAC 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | MAC (cont'd) ... 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Type 499 26 for vendor specific 501 Length 503 Length of entire attribute including type and length field 505 Vendor ID 507 4 octets encoding the Cisco Vendor ID of 9 509 Sub-type 511 Attribute sub-type of 1 513 Sub-length 515 Length of the sub attribute including the sub-type and sub- 516 length fields 518 String-ID 520 The ASCII characters "radius:message-authenticator-code=" 521 without quotes or null termination. 523 MAC Type 525 The MAC Type field specifies the algorithm used to create the 526 value in the MAC field. This document defines six values for 527 the MAC Type field: 529 0 HMAC-SHA-1 [FIPS.180-2.2002] [RFC2104] 531 1 HMAC-SHA-256 [FIPS.180-2.2002] [RFC4231] 533 2 HMAC-SHA-512 [FIPS.180-2.2002] [RFC4231] 535 3 CMAC-AES-128 [NIST.SP800-38B] 537 4 CMAC-AES-192 [NIST.SP800-38B] 539 5 CMAC-AES-256 [NIST.SP800-38B] 541 Implementations MUST support MAC Type 0 (HMAC-SHA-1). 543 MAC Key ID 545 The MAC Key ID field is 16 octets in length and contains an 546 identifier for the key. The combination of the MAC Key ID and 547 the client and server IP addresses together uniquely identify a 548 key shared between the RADIUS client and server. As a result, 549 the MAC Key ID need not be globally unique. The MAC Key ID 550 MUST refer to a key of a type and length appropriate for use 551 with the algorithm specified by the MAC Type field (see above). 552 The MAC Key ID is a constant that is configured through an out- 553 of-band mechanism. The same value is configured on both the 554 RADIUS client and server. If no MAC Key ID is configured, then 555 the field is set to 0. If only a single MAC Key ID is 556 configured for use between a given RADIUS client and server, 557 then 0 can be used as the default value. 559 MAC 561 Both the length and value of the MAC field depend upon the 562 algorithm specified by the value of the MAC Type field. If the 563 algorithm specified is HMAC-SHA-1, HMAC-SHA-256 or HMAC-SHA- 564 512, the MAC field MUST be 20, 32 or 64 octets in length, 565 respectively. If the algorithm specified is CMAC-AES-128, 566 CMAC-AES-192 or CMAC-AES-256, the MAC field SHOULD be 64 octets 567 in length. The derivation of the MAC field value for all the 568 algorithms specified in this document is identical, except for 569 the algorithm used. There are differences, however, depending 570 upon whether the MAC is being computed for a request message or 571 a response. These differences are detailed below, with the 572 free variable HASH-ALG representing the actual algorithm used. 574 Request Messages 576 For requests (e.g., CoA-Request [RFC5176], Accounting- 577 Request [RFC2866], etc.), the value of the MAC field is a 578 hash of the entire packet except the Request Authenticator 579 in the header of the RADIUS packet, using a shared secret as 580 the key, as follows. 582 MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes) 583 where '+' represents concatenation 585 The MAC-Randomizer Attribute (Section 3.2) MUST be included 586 in any request in which the Message-Authentication-Code 587 Attribute is used. The Random field of the MAC-Randomizer 588 Attribute MUST be filled in before the value of the MAC 589 field is computed. 591 If the Message-Authenticator-Code Attribute is included in a 592 client request, the server SHOULD ignore the contents of the 593 Request Authenticator. 595 Implementation Notes 597 When the hash is calculated, both the MAC field of the 598 Message-Authenticator-Code attribute and the String field 599 of the Message-Authenticator Attribute (if any) MUST be 600 considered to be zero-filled. 602 Implementations SHOULD provide a means to provision a key 603 (cryptographically separate from the normal RADIUS shared 604 secret) to be used exclusively in the generation of the 605 Message-Authentication-Code. 607 Response Messages 609 For responses (e.g., CoA-ACK [RFC5176], Accounting-Response 610 [RFC2866], etc.), the value of the MAC field is a hash of 611 the entire packet except the Response Authenticator in the 612 header of the RADIUS packet using a shared secret as the 613 key, as follows. 615 MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes) 616 where '+ ' represents concatenation 618 If the request contained an instance of the MAC-Randomizer 619 Attribute and the responder wishes to include an instance of 620 the Message-Authentication-Code Attribute in the 621 corresponding response, then the MAC-Randomizer Attribute 622 from the request MUST be included in the response. 624 If the Message-Authenticator-Code Attribute is included in a 625 server response, the client SHOULD ignore the contents of 626 the Response Authenticator. 628 Implementation Notes 630 When the hash is calculated, both the MAC field of the 631 Message-Authenticator-Code attribute and the String field 632 of the Message-Authenticator Attribute (if any) MUST be 633 considered to be zero-filled. 635 The Message-Authentication-Code Attribute MUST be created 636 and inserted in the packet before the Response 637 Authenticator is calculated. 639 Implementations SHOULD provide a means to provision a key 640 (cryptographically separate from the normal RADIUS shared 641 secret) to be used exclusively in the generation of the 642 Message-Authentication-Code. 644 4. IANA Considerations 646 This document does not define any actions for IANA. 648 5. Security Considerations 650 It is RECOMMENDED in this memo that two new keys, a key encrypting 651 key and a message authentication key, be shared by the RADIUS client 652 and server. If implemented, these two keys MUST be different from 653 each other and SHOULD NOT be based on a password. These two keys 654 MUST be cryptographically independent of the RADIUS shared secret 655 used in calculating the Response Authenticator [RFC2865], Request 656 Authenticator [RFC2866] [RFC5176] and Message-Authenticator Attribute 657 [RFC3579]; otherwise if the shared secret is broken, all is lost. 659 To avoid the possibility of collisions, the same MAC key SHOULD NOT 660 be used with more than 2^(n/2) messages, where 'n' is the length of 661 the MAC value in octets. 663 If a packet that contains an instance of the Keying-Material 664 Attribute also contains an instance of another, weaker key transport 665 attribute (e.g., MS-MPPE-Recv-Key [RFC2548]) encapsulating identical 666 keying material, then breaking the weaker attribute might facilitate 667 a known-plaintext attack against the KEK. 669 6. Contributors 671 Hao Zhou, Nancy Cam-Winget, Alex Lam, Paul Funk and John Fossaceca 672 all contributed to this document. 674 7. Acknowledgements 676 Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan, 677 Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun, 678 Joel Halpern, Jim Schaad, Greg Weber and Bernard Aboba for useful 679 feedback. 681 8. References 683 8.1. Normative References 685 [FIPS.180-2.2002] 686 National Institute of Standards and Technology, "Secure 687 Hash Standard", FIPS PUB 180-2, August 2002. 689 [NIST.SP800-38B] 690 Dworkin, M., "Recommendation for Block Cipher Modes of 691 Operation: The CMAC Mode for Authentication", May 2005. 693 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 694 Hashing for Message Authentication", RFC 2104, 695 February 1997. 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, March 1997. 700 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 701 "Remote Authentication Dial In User Service (RADIUS)", 702 RFC 2865, June 2000. 704 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 706 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 707 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 708 Support", RFC 2868, June 2000. 710 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 711 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 713 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 714 Dial In User Service) Support For Extensible 715 Authentication Protocol (EAP)", RFC 3579, September 2003. 717 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 718 Requirements for Security", BCP 106, RFC 4086, June 2005. 720 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 721 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 722 RFC 4231, December 2005. 724 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 725 Aboba, "Dynamic Authorization Extensions to Remote 726 Authentication Dial In User Service (RADIUS)", RFC 5176, 727 January 2008. 729 8.2. Informative References 731 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 732 RFC 2548, March 1999. 734 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 735 Levkowetz, "Extensible Authentication Protocol (EAP)", 736 RFC 3748, June 2004. 738 Authors' Addresses 740 Glen Zorn 741 Network Zen 742 1463 East Republican Street 743 #358 744 Seattle, WA 98112 745 US 747 Email: gwz@net-zen.net 749 Tiebing Zhang 750 Advista Technologies 751 5252 Orange Ave, Suite 108 752 Cypress, CA 90630 753 US 755 Phone: +1 (949) 242 0391 756 Email: tzhang@advistatech.com 758 Jesse Walker 759 Intel Corporation 760 JF3-206 761 2111 N.E. 25th Ave 762 Hillsboro, OR 97214-5961 763 US 765 Phone: +1 (503) 712-1849 766 Email: jesse.walker@intel.com 768 Joseph Salowey 769 Cisco Systems 770 2901 Third Avenue 771 SEA1/6/ 772 Seattle, WA 98121 773 US 775 Phone: +1 (206) 256-3380 776 Email: jsalowey@cisco.com