    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]