RFC 6218

Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material

📅 published April 2011, from ietf

Abstract 🎀

okay bestie, let's get into RFC 6218 💖 It defines a set of vendor-specific RADIUS Attributes that do two jobs. They let you send cryptographic keying material securely, and they give you strong authentication for any RADIUS message. The attributes come from the Cisco vendor-specific space, and multiple vendors have implemented them. ✨

Status of This Memo 🦋

this one is not an Internet Standards Track spec. It's published for informational purposes 🌸

It's also an independent contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked it for publication at their discretion and says nothing about how valuable it is to implement or deploy. Documents the RFC Editor approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 🙈

If you want the current status, any errata, or a way to send feedback, check http://www.rfc-editor.org/info/rfc6218.

IESG Note 🍓

the IESG says this work is related to what the RADEXT WG is already doing, but that doesn't stop it from being published 🫶 They also recommend that RADEXT keep going on an interoperable modern key wrap solution that uses attributes from the standard space, as part of its charter ✨

Copyright (c) 2011 IETF Trust and the people listed as the document authors. All rights reserved 💜

This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), which apply on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 📜

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 ✨

okay so the title block first 💅 This RFC is an Independent Submission, and its category is Informational. The ISSN is 2070-1721. It was published in April 2011. The authors are G. Zorn from Network Zen, T. Zhang from Advista Technologies, J. Walker from Intel Corporation, and J. Salowey from Cisco Systems 👑 The header has no Obsoletes or Updates line, so this doc doesn't list anything it obsoletes or updates. The title is "Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material" 🎀

Now the vibe check. This doc defines a set of vendor-specific RADIUS Attributes from the Cisco vendor space. They can securely transfer cryptographic keying material using standard techniques with well-understood security properties 🔐 On top of that, the Message-Authentication-Code Attribute may be used to give strong authentication to any RADIUS message, including the ones for accounting and dynamic authorization 🦋

The whole point is that these attributes offer stronger protection and more flexibility than the existing Vendor-Specific MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes in [RFC2548], and the Message-Authenticator Attribute in [RFC3579] 💜

Here's the context. Lots of remote access setups, like wireless LAN deployments, need keying material to be sent securely from a RADIUS [RFC2865] server to a network access point 🌸 That material is usually a by-product of an Extensible Authentication Protocol (EAP) [RFC3748] authentication, and it comes back in the Access-Accept message after a successful authentication 🍓 The keying material can be used in virtually any cryptographic algorithm once it's processed properly ✨ These attributes can also be used in other cases where an Authentication, Authorization, and Accounting (AAA) server needs to deliver keying material to a network access point 🧚

If you want to talk about this doc, you can direct your questions to the authors 🫶

2. Specification of Requirements 💖

okay the capital-letter key words here are the big deal 🔥 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in [RFC2119] 🎀

3. Attributes 🌈

the next subsections describe sub-attributes that get sent inside 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 layout of the attributes looks like this:

      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...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

here's what each field is, bestie 🧚

  • Type: 26 for Vendor-Specific
  • Length: length of the entire attribute, including the 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
  • Value: value of the sub-attribute

and this spec covers these three sub-attributes 🍓

  • Keying-Material
  • MAC-Randomizer
  • Message-Authentication-Code

more main character energy coming up in part 2 🫶

3.1. Keying-Material 🔑✨

Description

okay so this Attribute is literally the bestie for moving cryptographic keying material from a RADIUS server down to a client 🫶 It MAY be used for that job, and it's giving "main character" energy.

It MAY also show up in request messages (like Access-Request, etc.) 💅 If the Keying-Material (KM) Attribute is in a request, the server SHOULD read it as a hint that the client would rather get its keys this way than any other way 🎀 The server doesn't have to listen to the hint though, so no pressure. When the Keying-Material Attribute rides along in a request, the KM ID, key-encrypting-key (KEK) ID, Lifetime, Initialization Vector (IV), and Key Material Data fields MAY be left out 🌸

when the Keying-Material Attribute is known to be supported, or the client wants to dodge roll-back attacks 👀, the client MAY be set up to REQUIRE it. If the client needs this Attribute for keying material delivery and it's missing from the Access-Accept or Access-Challenge message, the client MAY ignore that message and end the user session 💀 yikes, but iykyk.

Any packet that contains a Keying-Material Attribute MUST also include the Message-Authentication-Code Attribute. No exceptions, bestie 🚫

Any packet that has a Keying-Material Attribute MUST NOT also have any other attribute (like MS-CHAP-MPPE-Keys [RFC2548], Tunnel-Password [RFC2868], etc.) that wraps identical keying material 🙈 no duplicate keys, we don't do that here.

The Keying-Material Attribute MUST NOT be used to move long-lived keys (aka passwords) between RADIUS servers and clients 🔒 passwords stay home, obviously.

Here's the summary of the Keying-Material Attribute format 🦋 The fields go left to right.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field Definitions 🧁

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 tells you which method was used to encrypt the contents of the Data field 🔐 This document only defines 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). Non-negotiable, bestie 💅

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 🔑 separate keys are the whole vibe.

App ID: The App ID field is 4 octets long and tells you what kind of application the key material is for 🦄 This lets multiple keys for different purposes live 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 long. The KEK ID together with the client and server IP addresses uniquely identifies a key shared between the RADIUS client and server 🫧 So the KEK ID doesn't need to be globally unique. The KEK ID MUST refer to an encryption key of a type and length that fits the algorithm named by the Enc Type field (see above). This key protects the contents of the Data field (below) 🔒 The KEK ID is a constant set up through an out-of-band mechanism, and the same value is configured on both the RADIUS client and server. If no KEK ID is configured, the field is set to 0. If only one KEK is configured 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 long and holds an identifier for the contents of the Data field 🪪 Communicating parties MAY use it to identify the material being sent. The combination of App ID and KM ID MUST uniquely identify the keying material between the parties using it. The KM ID is assumed to be known to the parties that derived the keying material 🤝 If the KM ID isn't used, it's 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] that gives the period of time (in seconds) the keying material is valid for ⏳

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 ⏰

IV: The length of the IV field depends on the value of the Enc Type field, but it's fixed for any given value 🧵 When the Enc Type field is 0 (decimal), the IV field MUST be 8 octets long (as drawn above), and its value MUST be as specified in [RFC3394]. If the IV for Enc Type 0 doesn't match [RFC3394], then the receiver MUST NOT use the key material from this attribute 🚨 no sus IVs allowed.

Keying Material Data: The Keying Material Data field is variable length and holds 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] 🎰 randomness is everything, periodt.

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 🌈 order matters, babe.

Here's the summary of the MAC-Randomizer Attribute format 🦋 The fields go left to right.

     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...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field Definitions 🧁

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 🎀

Random: This field MUST contain a 32 octet random number that SHOULD satisfy the requirements of [RFC4086] 🎲✨

3.3. Message-Authentication-Code 🔐

Description

okay bestie, this attribute is how we "sign" messages so nobody can spoof them 💅 It MAY be used for that. If it shows up in a request, the receiver should take it as a hint that the sender prefers this attribute for message authentication 🦋 but the receiver isn't obligated to do it, fr.

The Message-Authentication-Code Attribute MUST be included in any message that contains a Keying-Material Attribute 🎀

If you want both the Message-Authentication-Code and Message-Authenticator Attributes in one message (like for backward compatibility when old and new clients share a network 🧚), the value of the Message-Authentication-Code Attribute MUST be computed first. Order matters, bestie 👑

If any message comes in with a Message-Authentication-Code Attribute, the receiver MUST calculate the correct value of it and silently discard the packet if the computed value doesn't match the one received. Silently. Gone. 💀

If a received message contains a MAC-Randomizer Attribute (Section 3.2), that received MAC-Randomizer Attribute SHOULD be included in the computation of the Message-Authentication-Code Attribute sent in the response, as described below 🌈

Here's the format summary for the Message-Authentication-Code Attribute. Fields go left to right, obviously 🍓

  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 the 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: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). This one is the baseline, no cap 🫶

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).

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 🙈

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. Order, order, ORDER 🎀

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 🗝️

4. Security Considerations 🚨

This is the part where we get serious, bestie 😭 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. Don't be the reason the KEK gets leaked 😤

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 ✨

okay bestie, these are the must-reads 💅 If you're going to implement anything here, you need every one of these open in another tab. no cap 📚

  • [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.
  • [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 🦋

these ones are more like the lore 📖 helpful for context, but not required reading to implement the thing.

  • [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. 💜

Authors' Addresses 🌸

the squad behind this RFC, and how to reach them 🫶

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
📦 where this page comes from