diff options
Diffstat (limited to 'doc/rfc/rfc6218.txt')
| -rw-r--r-- | doc/rfc/rfc6218.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc6218.txt b/doc/rfc/rfc6218.txt new file mode 100644 index 0000000..66a6e08 --- /dev/null +++ b/doc/rfc/rfc6218.txt @@ -0,0 +1,1011 @@ + + + + + + +Independent Submission G. Zorn +Request for Comments: 6218 Network Zen +Category: Informational T. Zhang +ISSN: 2070-1721 Advista Technologies + J. Walker + Intel Corporation + J. Salowey + Cisco Systems + April 2011 + + + Cisco Vendor-Specific RADIUS Attributes for + the Delivery of Keying Material + +Abstract + + This document defines a set of vendor-specific RADIUS Attributes + designed to allow both the secure transmission of cryptographic + keying material and strong authentication of any RADIUS message. + These attributes have been allocated from the Cisco vendor-specific + space and have been implemented by multiple vendors. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6218. + +IESG Note + + The IESG has concluded that this work is related to IETF work done in + the RADEXT WG, but this relationship does not prevent publishing. + The IESG recommends that the RADEXT WG proceed with the work for an + interoperable modern key wrap solution using attributes from the + standard space as part of its charter. + + + + + + +Zorn, et al. Informational [Page 1] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Specification of Requirements ...................................3 + 3. Attributes ......................................................3 + 3.1. Keying-Material ............................................4 + 3.2. MAC-Randomizer .............................................9 + 3.3. Message-Authentication-Code ...............................11 + 4. Security Considerations ........................................16 + 5. Contributors ...................................................16 + 6. Acknowledgements ...............................................16 + 7. References .....................................................16 + 7.1. Normative References ......................................16 + 7.2. Informative References ....................................17 + +1. Introduction + + This document defines a set of vendor-specific RADIUS Attributes, + allocated from the Cisco vendor space, that can be used to securely + transfer cryptographic keying material using standard techniques with + well-understood security properties. In addition, the Message- + Authentication-Code Attribute may be used to provide strong + authentication for any RADIUS message, including those used for + accounting and dynamic authorization. + + These attributes were designed to provide stronger protection and + more flexibility than the currently defined Vendor-Specific + MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes in [RFC2548] and the + Message-Authenticator Attribute in [RFC3579]. + + Many remote access deployments (for example, deployments utilizing + wireless LAN technology) require the secure transmission of + cryptographic keying material from a RADIUS [RFC2865] server to a + network access point. This material is usually produced as a + by-product of an Extensible Authentication Protocol (EAP) [RFC3748] + authentication and returned in the Access-Accept message following a + + + +Zorn, et al. Informational [Page 2] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + successful authentication process. The keying material is of a form + that may be used in virtually any cryptographic algorithm after + appropriate processing. These attributes may also be used in other + cases where an Authentication, Authorization, and Accounting (AAA) + server needs to deliver keying material to a network access point. + + Discussion of this document may be directed to the authors. + +2. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Attributes + + The following subsections describe sub-attributes that are + transmitted in RADIUS Attributes of type Vendor-Specific [RFC2865]. + The Vendor ID field of the Vendor-Specific Attribute(s) MUST be set + to decimal 9 (Cisco). The general format of the attributes is: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (26) | Length | Vendor ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor ID (cont'd) | Sub-type (1)| Sub-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 26 for Vendor-Specific + + Length + + Length of entire attribute including type and length fields + + Vendor ID + + 4 octets encoding the Cisco Vendor ID of 9 + + Sub-type + + Attribute sub-type of 1 + + + + + +Zorn, et al. Informational [Page 3] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + Sub-length + + Length of the sub-attribute including the sub-type and sub-length + fields + + Value + + Value of the sub-attribute + + This specification concerns the following sub-attributes: + + o Keying-Material + + o MAC-Randomizer + + o Message-Authentication-Code + +3.1. Keying-Material + + Description + + This Attribute MAY be used to transfer cryptographic keying + material from a RADIUS server to a client. + + It MAY be sent in request messages (e.g., Access-Request, etc.), + as well; if the Keying-Material (KM) Attribute is present in a + request, it SHOULD be taken as a hint by the server that the + client prefers this method of key delivery over others. The + server is not obligated to honor the hint, however. When the + Keying-Material Attribute is included in a request message, the KM + ID, key-encrypting-key (KEK) ID, Lifetime, Initialization Vector + (IV), and Key Material Data fields MAY be omitted. + + In environments where the Keying-Material Attribute is known to be + supported or in cases where the client wants to avoid roll-back + attacks, the client MAY be configured to require the use of the + Keying-Material Attribute. If the client requires the use of the + Keying-Material Attribute for keying material delivery and it is + not present in the Access-Accept or Access-Challenge message, the + client MAY ignore the message in question and end the user + session. + + + + + + + + + + +Zorn, et al. Informational [Page 4] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + Any packet that contains a Keying-Material Attribute MUST also + include the Message-Authentication-Code Attribute. + + Any packet that contains an instance of the Keying-Material + Attribute MUST NOT contain an instance of any other attribute + (e.g., MS-CHAP-MPPE-Keys [RFC2548], Tunnel-Password [RFC2868], + etc.) encapsulating identical keying material. + + The Keying-Material Attribute MUST NOT be used to transfer long- + lived keys (i.e., passwords) between RADIUS servers and clients. + + A summary of the Keying-Material Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn, et al. Informational [Page 5] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (26) | Length | Vendor ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor ID (cont'd) | Sub-type (1)| Sub-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | String ID ("radius:app-key=") + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) | Enc Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | App ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEK ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + KEK ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + KEK ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + KEK ID (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KM ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + KM ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + KM ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + KM ID (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IV + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IV (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Keying Material Data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + +Zorn, et al. Informational [Page 6] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + Type + + 26 for Vendor-Specific + + Length + + Length of entire attribute including type and length fields + + Vendor ID + + 4 octets encoding the Cisco Vendor ID of 9 + + Sub-type + + Attribute sub-type of 1 + + Sub-length + + Length of the sub-attribute including the sub-type and sub-length + fields + + String-ID + + The ASCII characters "radius:app-key=" without quotes or null + termination + + Enc Type + + The Enc Type field indicates the method used to encrypt the + contents of the Data field. This document defines only one value + (decimal) for this field: + + 0 AES Key Wrap with 128-bit KEK [RFC3394] + + Implementations MUST support Enc Type 0 (AES Key Wrap with 128-bit + KEK). + + Implementation Note + + A shared secret is used as the key-encrypting-key (KEK) for the + AES key wrap algorithm. Implementations SHOULD provide a means + to provision a key (cryptographically separate from the normal + RADIUS shared secret) to be used exclusively as a KEK. + + + + + + + + +Zorn, et al. Informational [Page 7] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + App ID + + The App ID field is 4 octets in length and identifies the type of + application for which the key material is to be used. This allows + for multiple keys for different purposes to be present in the same + message. This document defines two values for the App ID: + + 0 Reserved + + 1 EAP MSK + + KEK ID + + The KEK ID field is 16 octets in length. The combination of the + KEK ID and the client and server IP addresses together uniquely + identify a key shared between the RADIUS client and server. As a + result, the KEK ID need not be globally unique. The KEK ID MUST + refer to an encryption key of a type and length appropriate for + use with the algorithm specified by the Enc Type field (see + above). This key is used to protect the contents of the Data + field (below). The KEK ID is a constant that is configured + through an out-of-band mechanism. The same value is configured on + both the RADIUS client and server. If no KEK ID is configured, + then the field is set to 0. If only a single KEK is configured + for use between a given RADIUS client and server, then 0 can be + used as the default value. + + KM ID + + The KM ID field is 16 octets in length and contains an identifier + for the contents of the Data field. The KM ID MAY be used by + communicating parties to identify the material being transmitted. + The combination of App ID and KM ID MUST uniquely identify the + keying material between the parties utilizing it. The KM ID is + assumed to be known to the parties that derived the keying + material. If the KM ID is not used, it is set to 0. The KM ID + for the EAP Master Session Key (MSK) application is set to 0. + Another application that uses the KM ID field can be defined in + the future. + + Lifetime + + The Lifetime field is an integer [RFC2865] representing the period + of time (in seconds) for which the keying material is valid. + + Note: Applications using this value SHOULD consider the beginning + of the lifetime to be the point in time when the keying material + is first used. + + + +Zorn, et al. Informational [Page 8] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + IV + + The length of the IV field depends upon the value of the Enc Type + field, but is fixed for any given value thereof. When the value + of the Enc Type field is 0 (decimal), the IV field MUST be 8 + octets in length (as illustrated above), and the value of the IV + field MUST be as specified in [RFC3394]. If the IV for Enc Type 0 + does not match [RFC3394], then the receiver MUST NOT use the key + material from this attribute. + + Keying Material Data + + The Keying Material Data field is of variable length and contains + the actual encrypted keying material. + +3.2. MAC-Randomizer + + Description + + The MAC-Randomizer Attribute MUST be present in any message that + includes an instance of the Message-Authentication-Code Attribute. + The Random field MUST contain a 32-octet random number that SHOULD + satisfy the requirements of [RFC4086]. + + Implementation Note + + The Random field MUST be filled in before the Message + Authentication Code (MAC) is computed. The MAC-Randomizer + Attribute SHOULD be placed at the beginning of the RADIUS + message if possible. + + A summary of the MAC-Randomizer Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + + + + + +Zorn, et al. Informational [Page 9] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (26) | Length | Vendor ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor ID (cont'd) | Sub-type (1)| Sub-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | String ID ("radius:random-nonce=") + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Random... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 26 for Vendor-Specific + + Length + + Length of entire attribute including type and length fields + + Vendor ID + + 4 octets encoding the Cisco Vendor ID of 9 + + Sub-type + + Attribute sub-type of 1 + + Sub-length + + Length of the sub-attribute including the sub-type and + sub-length fields + + String-ID + + The ASCII characters "radius:random-nonce=" without quotes or + null termination + + + + + + +Zorn, et al. Informational [Page 10] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + Random + + This field MUST contain a 32 octet random number that SHOULD + satisfy the requirements of [RFC4086]. + +3.3. Message-Authentication-Code + + Description + + This Attribute MAY be used to "sign" messages to prevent spoofing. + If it is present in a request, the receiver should take this as a + hint that the sender prefers the use of this Attribute for message + authentication; the receiver is not obligated to do so, however. + + The Message-Authentication-Code Attribute MUST be included in any + message that contains a Keying-Material Attribute. + + If both the Message-Authentication-Code and Message-Authenticator + Attributes are to be included in a message (e.g., for backward + compatibility in a network containing both old and new clients), + the value of the Message-Authentication-Code Attribute MUST be + computed first. + + If any message is received containing an instance of the Message- + Authentication-Code Attribute, the receiver MUST calculate the + correct value of the Message-Authentication-Code and silently + discard the packet if the computed value does not match the value + received. + + If a received message contains an instance of the MAC-Randomizer + Attribute (Section 3.2), the received MAC-Randomizer Attribute + SHOULD be included in the computation of the Message- + Authentication-Code Attribute sent in the response, as described + below. + + A summary of the Message-Authentication-Code Attribute format is + shown below. The fields are transmitted from left to right. + + + + + + + + + + + + + + +Zorn, et al. Informational [Page 11] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (26) | Length | Vendor ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor ID (cont'd) | Sub-type (1)| Sub-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | String ID ("radius:message-authenticator-code=") + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String ID (cont'd) | MAC Type | MAC Key ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Key ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + MAC Key ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + MAC Key ID (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + MAC Key ID (cont'd) | MAC + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC (cont'd) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 26 for Vendor-Specific + + Length + + Length of entire attribute including type and length fields + + Vendor ID + + 4 octets encoding the Cisco Vendor ID of 9 + + + + +Zorn, et al. Informational [Page 12] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + Sub-type + + Attribute sub-type of 1 + + Sub-length + + Length of the sub-attribute including the sub-type and + sub-length fields + + String-ID + + The ASCII characters "radius:message-authenticator-code=" + without quotes or null termination + + MAC Type + + The MAC Type field specifies the algorithm used to create the + value in the MAC field. This document defines six values for + the MAC Type field: + + 0 HMAC-SHA-1 [FIPS] [RFC2104] + + 1 HMAC-SHA-256 [FIPS] [RFC4231] + + 2 HMAC-SHA-512 [FIPS] [RFC4231] + + 3 CMAC-AES-128 [NIST] + + 4 CMAC-AES-192 [NIST] + + 5 CMAC-AES-256 [NIST] + + Implementations MUST support MAC Type 0 (HMAC-SHA-1). + + MAC Key ID + + The MAC Key ID field is 16 octets in length and contains an + identifier for the key. The combination of the MAC Key ID and + the client and server IP addresses together uniquely identify a + key shared between the RADIUS client and server. As a result, + the MAC Key ID need not be globally unique. The MAC Key ID + MUST refer to a key of a type and length appropriate for use + with the algorithm specified by the MAC Type field (see above). + + + + + + + + +Zorn, et al. Informational [Page 13] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + The MAC Key ID is a constant that is configured through an out- + of-band mechanism. The same value is configured on both the + RADIUS client and server. If no MAC Key ID is configured, then + the field is set to 0. If only a single MAC Key ID is + configured for use between a given RADIUS client and server, + then 0 can be used as the default value. + + MAC + + Both the length and value of the MAC field depend upon the + algorithm specified by the value of the MAC Type field. If the + algorithm specified is HMAC-SHA-1, HMAC-SHA-256, or + HMAC-SHA-512, the MAC field MUST be 20, 32, or 64 octets in + length, respectively. If the algorithm specified is + CMAC-AES-128, CMAC-AES-192, or CMAC-AES-256, the MAC field + SHOULD be 64 octets in length. The derivation of the MAC field + value for all the algorithms specified in this document is + identical, except for the algorithm used. There are + differences, however, depending upon whether the MAC is being + computed for a request message or a response. These + differences are detailed below, with the free variable HASH-ALG + representing the actual algorithm used. + + Request Messages + + For requests (e.g., CoA-Request [RFC5176], Accounting- + Request [RFC2866], etc.), the value of the MAC field is a + hash of the entire packet except the Request Authenticator + in the header of the RADIUS packet, using a shared secret as + the key, as follows. + + MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes) + where '+' represents concatenation + + The MAC-Randomizer Attribute (Section 3.2) MUST be included + in any request in which the Message-Authentication-Code + Attribute is used. The Random field of the MAC-Randomizer + Attribute MUST be filled in before the value of the MAC + field is computed. + + If the Message-Authenticator-Code Attribute is included in a + client request, the server SHOULD ignore the contents of the + Request Authenticator. + + + + + + + + +Zorn, et al. Informational [Page 14] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + Implementation Notes + + When the hash is calculated, both the MAC field of the + Message-Authenticator-Code Attribute and the String field + of the Message-Authenticator Attribute (if any) MUST be + considered to be zero-filled. + + Implementations SHOULD provide a means to provision a key + (cryptographically separate from the normal RADIUS shared + secret) to be used exclusively in the generation of the + Message-Authentication-Code. + + Response Messages + + For responses (e.g., CoA-ACK [RFC5176], Accounting-Response + [RFC2866], etc.), the value of the MAC field is a hash of + the entire packet except the Response Authenticator in the + header of the RADIUS packet using a shared secret as the + key, as follows. + + MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes) + where '+' represents concatenation + + If the request contained an instance of the MAC-Randomizer + Attribute and the responder wishes to include an instance of + the Message-Authentication-Code Attribute in the + corresponding response, then the MAC-Randomizer Attribute + from the request MUST be included in the response. + + If the Message-Authenticator-Code Attribute is included in a + server response, the client SHOULD ignore the contents of + the Response Authenticator. + + Implementation Notes + + When the hash is calculated, both the MAC field of the + Message-Authenticator-Code Attribute and the String field + of the Message-Authenticator Attribute (if any) MUST be + considered to be zero-filled. + + The Message-Authentication-Code Attribute MUST be created + and inserted in the packet before the Response + Authenticator is calculated. + + Implementations SHOULD provide a means to provision a key + (cryptographically separate from the normal RADIUS shared + secret) to be used exclusively in the generation of the + Message-Authentication-Code. + + + +Zorn, et al. Informational [Page 15] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + +4. Security Considerations + + It is RECOMMENDED in this memo that two new keys, a key encrypting + key and a message authentication key, be shared by the RADIUS client + and server. If implemented, these two keys MUST be different from + each other and SHOULD NOT be based on a password. These two keys + MUST be cryptographically independent of the RADIUS shared secret + used in calculating the Response Authenticator [RFC2865], Request + Authenticator [RFC2866] [RFC5176], and Message-Authenticator + Attribute [RFC3579]; otherwise, if the shared secret is broken, all + is lost. + + To avoid the possibility of collisions, the same MAC key SHOULD NOT + be used with more than 2^(n/2) messages, where 'n' is the length of + the MAC value in octets. + + If a packet that contains an instance of the Keying-Material + Attribute also contains an instance of another, weaker key transport + attribute (e.g., MS-MPPE-Recv-Key [RFC2548]) encapsulating identical + keying material, then breaking the weaker attribute might facilitate + a known-plaintext attack against the KEK. + +5. Contributors + + Hao Zhou, Nancy Cam-Winget, Alex Lam, Paul Funk, and John Fossaceca + all contributed to this document. + +6. Acknowledgements + + Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan, + Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun, + Joel Halpern, Jim Schaad, Greg Weber, and Bernard Aboba for useful + feedback. + +7. References + +7.1. Normative References + + [FIPS] National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", FIPS PUB 180-3, October 2008. + + [NIST] Dworkin, M., "Recommendation for Block Cipher Modes of + Operation: The CMAC Mode for Authentication", NIST SP800- + 38B, May 2005. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + + +Zorn, et al. Informational [Page 16] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, + M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol + Support", RFC 2868, June 2000. + + [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard + (AES) Key Wrap Algorithm", RFC 3394, September 2002. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication + Dial In User Service) Support For Extensible + Authentication Protocol (EAP)", RFC 3579, September 2003. + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + June 2005. + + [RFC4231] Nystrom, M., "Identifiers and Test Vectors for + HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and + HMAC-SHA-512", RFC 4231, December 2005. + + [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", RFC 5176, + January 2008. + +7.2. Informative References + + [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", + RFC 2548, March 1999. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, Ed., "Extensible Authentication Protocol + (EAP)", RFC 3748, June 2004. + + + + + + + + + + +Zorn, et al. Informational [Page 17] + +RFC 6218 RADIUS Keying Material Transfer VSA April 2011 + + +Authors' Addresses + + Glen Zorn + Network Zen + 227/358 Thanon Sanphawut + Bang Na, Bangkok 10260 + Thailand + + Phone: +66 (0) 87 040 4617 + EMail: gwz@net-zen.net + + + Tiebing Zhang + Advista Technologies + 5252 Orange Ave., Suite 106 + Cypress, CA 90630 + US + + Phone: +1 (949) 242 0391 + EMail: tzhang@advistatech.com + + + Jesse Walker + Intel Corporation + JF2-55 + 2111 N.E. 25th Ave. + Hillsboro, OR 97214-5961 + US + + Phone: +1 (503) 712-1849 + EMail: jesse.walker@intel.com + + + Joseph Salowey + Cisco Systems + 2901 Third Avenue + SEA1/6/ + Seattle, WA 98121 + US + + Phone: +1 (206) 256-3380 + EMail: jsalowey@cisco.com + + + + + + + + + +Zorn, et al. Informational [Page 18] + |