RFC 2548

Microsoft Vendor-specific RADIUS Attributes

📅 published March 1999, from ietf

RFC 2548: Microsoft Vendor-specific RADIUS Attributes ✨

Okay bestie, this one is from the Network Working Group 🌸, written by G. Zorn of Microsoft Corporation 💼. It's marked Category: Informational, dated March 1999. The title block doesn't list anything it obsoletes or updates, so it's a standalone doc 🦋.

Status of this Memo

Okay, the vibe here is "just sharing info, not a standard" 💅. This memo gives information to the Internet community and does not specify an Internet standard of any kind. Distribution is unlimited, so share it freely 🫶.

Copyright Notice

Abstract

So this doc is all about the set of Microsoft vendor-specific RADIUS attributes 🎀. These exist to support Microsoft's proprietary dial-up protocols and to add features the standard RADIUS attribute set [3] doesn't cover 🧚. The memo is expected to get updated whenever Microsoft defines a new vendor-specific attribute, because its whole purpose is to be an open, easy-to-find reference for third parties who want to interoperate with Microsoft products 💖. Main character energy for interop 👑.

1. Specification of Requirements

Quick key-word check 🔑. In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2]. Those are the words that carry the weight, so read them carefully 💜.

2. Attributes

These sections describe sub-attributes that can be sent inside one or more RADIUS attributes of type Vendor-Specific [3] 🌈. You MAY send more than one sub-attribute in a single Vendor-Specific Attribute ✨. If you do, the sub-attributes SHOULD be packed as a sequence of Vendor-Type/Vendor-Length/Value triples, sitting after the initial Type, Length and Vendor-ID fields 🍓.

Now the strict part 🙈. The Length field of the Vendor-Specific Attribute MUST be set equal to the sum of the Vendor-Length fields of the sub-attributes inside it, plus six. And the Vendor-ID field of the Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft) 🔥.

2.1. Attributes for Support of MS-CHAP Version 1

2.1.1. Introduction

Microsoft made MS-CHAP [4] to authenticate remote Windows workstations, giving them the same experience LAN-based users are used to 💻. Where possible, MS-CHAP matches standard CHAP [5], and the differences are easy to modularize 🧩. Here's the tea on how MS-CHAP differs from standard CHAP ☕:

MS-CHAP is turned on by negotiating CHAP Algorithm 0x80 in LCP option 3, Authentication Protocol 🔐.
The MS-CHAP Response packet uses a format built for compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0, Microsoft Windows95, and Microsoft LAN Manager 2.x networking products 🪟. The MS-CHAP format does NOT require the authenticator to store a clear-text or reversibly encrypted password 🙅‍♀️. (Keep in mind the key word rules: this one is plain prose, so no requirement force here.)
MS-CHAP gives the authenticator control over a retry mechanism for authentication 🔁.
MS-CHAP gives the authenticator control over a password changing mechanism 🗝️.
MS-CHAP defines an extended set of reason-for-failure codes, returned in the Failure packet Message field 🚨.

The attributes in this section reflect all of these differences 💅.

2.1.2. MS-CHAP-Challenge

Description

This Attribute holds the challenge a NAS sends to a Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) user 🎯. It MAY be used in both Access-Request and Access-Challenge packets 💫.

Here's the layout of the MS-CHAP-Challenge Attribute, read 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type is 11 for MS-CHAP-Challenge 🏷️.

Vendor-Length is > 2 📏.

String holds the MS-CHAP challenge 🧾.

2.1.3. MS-CHAP-Response

Description

This Attribute holds the response value a PPP Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) user sends back for the challenge 🔄. It is only used in Access-Request packets 📨.

Here's the layout of the MS-CHAP-Response Attribute, read 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Ident     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            LM-Response
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             LM-Response(cont)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           NT-Response
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             NT-Response (cont)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type is 1 for MS-CHAP-Response 🔢.

Vendor-Length is 52 📐.

Ident is identical to the PPP CHAP Identifier 🪪.

Flags is one octet long 🚩. If the Flags field is one (0x01), the NT-Response field is to be used in preference to the LM-Response field for authentication 🥇. The LM-Response field MAY still be used (if it's non-empty), but the NT-Response SHOULD be tried first 🤞. If it's zero, the NT-Response field MUST be ignored and the LM-Response field used 🙅‍♀️.

LM-Response is 24 octets long and holds an encoded function of the password and the received challenge 🔐. If this field is empty, it SHOULD be zero-filled 🌱.

NT-Response is 24 octets long and holds an encoded function of the password and the received challenge 🔐. If this field is empty, it SHOULD be zero-filled 🌱.

2.1.4. MS-CHAP-Domain

Description

The MS-CHAP-Domain Attribute tells you the Windows NT domain the user was authenticated in 🏰. It MAY be included in both Access-Accept and Accounting-Request packets 📬.

Here's the layout of the MS-CHAP-Domain Attribute, read 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Ident     |    String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type is 10 for MS-CHAP-Domain 🏷️.

Vendor-Length is > 3 📏.

Ident is one octet and helps match requests with replies 🧲.

String is the name, in ASCII, of the Windows NT domain the user was authenticated in 🗺️.

2.1.5. MS-CHAP-Error

Description

The MS-CHAP-Error Attribute carries error data from the MS-CHAP exchange that came just before it 🚧. This Attribute may be used in both MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges 🔁. It is only used in Access-Reject packets ❌.

Here's the layout of the MS-CHAP-Error Attribute, read 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Ident     |    String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type is 2 for MS-CHAP-Error 🏷️.

Vendor-Length is > 3 📏.

Ident is one octet and helps match requests with replies 🧲.

String holds specially formatted ASCII text, which the authenticating peer interprets 🤖.

2.1.6. MS-CHAP-CPW-1 ✨

Description 🔑

okay so this one is the password-changer for when your password has expired 😭 it's only used in Access-Request packets, and you only include it if the Access-Reject packet right before it had an MS-CHAP-Error attribute whose String field said the password expired, AND the MS-CHAP version is less than 2. very specific, very iconic 💅

Here's the layout of the MS-CHAP-CPW-1 Attribute. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       LM-Old-Password
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         LM-Old-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         LM-Old-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         LM-Old-Password (cont)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       LM-New-Password
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         LM-New-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         LM-New-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         LM-New-Password (cont)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NT-Old-Password
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         NT-Old-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         NT-Old-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         NT-Old-Password (cont)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       NT-New-Password
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         NT-New-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         NT-New-Password (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         NT-New-Password (cont)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     New-LM-Password-Length    |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type: 3 for MS-CHAP-PW-1 🎀
Vendor-Length: 72
Code: one octet, and it's always 5 🍓
Ident: one octet that helps match requests with replies 🫶
LM-Old-Password: 16 octets, holding the encrypted Lan Manager hash of the old password 🔐
LM-New-Password: 16 octets, holding the encrypted Lan Manager hash of the new password 🔐
NT-Old-Password: 16 octets, holding the encrypted Lan Manager hash of the old password 🔐
NT-New-Password: 16 octets, holding the encrypted Lan Manager hash of the new password 🔐
New-LM-Password-Length: two octets, giving the length in octets of the new LAN Manager-compatible password 📏
Flags: two octets. If the least significant bit is one, the NT-New-Password and NT-Old-Password fields are valid and SHOULD be used. Otherwise, the LM-New-Password and LM-Old-Password fields MUST be used. main character energy, the bit decides everything 👑

2.1.7. MS-CHAP-CPW-2 🦋

Description 💖

this is the MS-CHAP version 2 sibling of CPW-1, same goal of letting someone change an expired password 🌸 it's also only in Access-Request packets, and it only shows up if the Access-Reject right before had an MS-CHAP-Error attribute saying the password expired, AND the MS-CHAP version is equal to 2.

Here's how the MS-CHAP-CPW-2 Attribute is laid out. The fields are sent 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Old-NT-Hash
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Old-NT-Hash (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Old-NT-Hash (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Old-NT-Hash (cont)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Old-LM-Hash
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Old-LM-Hash(cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Old-LM-Hash(cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Old-LM-Hash(cont)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         LM-Response
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           LM-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           LM-Response (cont)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          NT-Response
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type: 4 for MS-CHAP-PW-2 🌷
Vendor-Length: 86
Code: 6 🍓
Ident: one octet that helps match requests with replies. Its value MUST be identical to the Ident value in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP-PW-2 attributes inside a single Access-Request packet. these have to match, bestie 🫶
Old-NT-Hash: 16 octets, holding the old Windows NT password hash, encrypted with the new Windows NT password hash 🔐
Old-LM-Hash: 16 octets, holding the old Lan Manager password hash, encrypted with the new Windows NT password hash 🔐
LM-Response: 24 octets, holding an encoded function of the password and the received challenge. If this field is empty, it SHOULD be zero-filled 🧩
NT-Response: 24 octets, holding an encoded function of the password and the received challenge. If this field is empty, it SHOULD be zero-filled 🧩
Flags: two octets. If the least significant bit (bit 0) is one, the NT-Response field is to be used in preference to the LM-Response field for authentication. The LM-Response field MAY still be used (if present), but the NT-Response SHOULD be tried first. If the least significant bit is zero, the NT-Response field MUST be ignored and the LM-Response field is used instead. If bit 1 is one, the Old-LM-Hash field is valid and SHOULD be used. If this bit is set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST be included in the packet. bit 0 and bit 1 are doing a lot of work here 🤯

2.1.8. MS-CHAP-LM-Enc-PW 🌈

Description 🎀

this attribute carries the new Windows NT password, encrypted with the old LAN Manager password hash 🔒 the encrypted NT password is 516 octets long, and that's way longer than the max length of a RADIUS attribute, so the password has to get split up across several attributes for transmission 🧩 each one carries a 2 octet sequence number so the pieces can be put back in order. ordering matters, periodt 💅

This attribute is only used in Access-Request packets, together with the MS-CHAP-CPW-2 attribute. It only shows up if the Access-Reject right before had an MS-CHAP-Error attribute saying the password expired, AND the MS-CHAP version is 2 or greater ✨

Here's the MS-CHAP-LM-Enc-PW Attribute layout. The fields are sent 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |      Code     |     Ident     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Sequence-Number         |          String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type: 5 for MS-CHAP-LM-Enc-PW 🌸
Vendor-Length: > 6
Code: 6. It's the same as the Code for the MS-CHAP-PW-2 attribute 🍓
Ident: one octet that helps match requests with replies. Its value MUST be identical in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP-PW-2 attributes present in the same Access-Request packet 🫶
Sequence-Number: two octets, showing which "chunk" of the encrypted password is in the String field that follows 🧩
String: a portion of the encrypted password 🔐

2.2. MS-CHAP-NT-Enc-PW 💅

Description

okay so this Attribute carries the new Windows NT password, encrypted with the old Windows NT password hash 🔐. The encrypted password is 516 octets long, and that's way longer than the max length of a RADIUS attribute, so the password has to be split across several attributes for transmission ✂️. A 2 octet sequence number rides along in each one to help keep the password fragments in order 🧩.

This Attribute is only used in Access-Request packets, together with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It should only be included if an MS-CHAP-Error attribute was in the immediately preceding Access-Reject packet, the String field of that MS-CHAP-Error said the user password had expired, and the MS-CHAP version is 2 or greater 🌸

A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. The fields are transmitted from 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |      Code     |     Ident     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Sequence-Number        |           String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type: 6 for MS-CHAP-NT-Enc-PW

Vendor-Length: > 6

Code: 6. Code is the same as for the MS-CHAP-PW-2 attribute.

Ident: The Ident field is one octet and aids in matching requests and replies. The value of this field MUST be identical in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP-PW-2 attributes which are present in the same Access-Request packet 🎀

Sequence-Number: The Sequence-Number field is two octets in length and indicates which "chunk" of the encrypted password is contained in the following String field.

String: The String field contains a portion of the encrypted password.

2.3. Attributes for Support of MS-CHAP Version 2 🦋

2.3.1. Introduction

This section describes RADIUS attributes supporting version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1) [4]. Certain protocol fields have been deleted or reused but with different semantics. Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and standard CHAP [1]. Briefly, the differences between MS-CHAP-V2 and MS-CHAP-V1 are:

MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP option 3, Authentication Protocol.
MS-CHAP-V2 provides mutual authentication between peers by piggybacking a peer challenge on the Response packet and an authenticator response on the Success packet.
The calculation of the "Windows NT compatible challenge response" sub-field in the Response packet has been changed to include the peer challenge and the user name.
In MS-CHAP-V1, the "LAN Manager compatible challenge response" sub-field was always sent in the Response packet. This field has been replaced in MS-CHAP-V2 by the Peer-Challenge field.
The format of the Message field in the Failure packet has been changed.
The Change Password (version 1) and Change Password (version 2) packets are no longer supported. They have been replaced with a single Change-Password packet.

The attributes defined in this section reflect these differences 💜

2.3.2. MS-CHAP2-Response 💖

Description

This Attribute contains the response value provided by an MS-CHAP-V2 peer in response to the challenge. It is only used in Access-Request packets.

A summary of the MS-CHAP2-Response Attribute format is shown below. The fields are transmitted from 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Ident     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Peer-Challenge
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Peer-Challenge (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Peer-Challenge (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Peer-Challenge (cont)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Reserved
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               Reserved (cont)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Response
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               Response (cont)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type: 25 for MS-CHAP2-Response.

Vendor-Length: 52

Ident: Identical to the PPP MS-CHAP v2 Identifier.

Flags: The Flags field is one octet in length. It is reserved for future use and MUST be zero.

Peer-Challenge: The Peer-Challenge field is a 16-octet random number.

Reserved: This field is reserved for future use and MUST be zero.

Response: The Response field is 24 octets in length and holds an encoded function of the password, the Peer-Challenge field and the received challenge.

2.3.3. MS-CHAP2-Success ✨

Description

This Attribute contains a 42-octet authenticator response string. This string MUST be included in the Message field of the MS-CHAP-V2 Success packet sent from the NAS to the peer. This Attribute is only used in Access-Accept packets 🎉

A summary of the MS-CHAP2-Success Attribute format is shown below. The fields are transmitted from 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Ident     |   String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type: 26 for MS-CHAP2-Success.

Vendor-Length: 45

Ident: Identical to the PPP MS-CHAP v2 Identifier.

String: The 42-octet authenticator string (see above).

2.3.4. MS-CHAP2-CPW 🍓

Description

This Attribute allows the user to change their password if it has expired. This Attribute is only used in conjunction with the MS-CHAP-NT-Enc-PW attribute in Access-Request packets, and should only be included if an MS-CHAP-Error attribute was included in the immediately preceding Access-Reject packet, the String field of the MS-CHAP-Error attribute indicated that the user password had expired, and the MS-CHAP version is equal to 3 💅

A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The fields are transmitted from 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encrypted-Hash
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Encrypted-Hash (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Encrypted-Hash (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Encrypted-Hash (cont)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Peer-Challenge
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Peer-Challenge (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Peer-Challenge (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Peer-Challenge (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Peer-Challenge (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Peer-Challenge (cont)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          NT-Response
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           NT-Response (cont)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type: 27 for MS-CHAP2-PW

Vendor-Length: 70

Code: 7

Ident: The Ident field is one octet and aids in matching requests and replies. The value of this field MUST be identical to that in the Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in the Access-Request packet.

Encrypted-Hash: The Encrypted-Hash field is 16 octets in length. It contains the old Windows NT password hash encrypted with the new Windows NT password hash.

NT-Response: The NT-Response field is 24 octets in length and holds an encoded function of the new password, the Peer-Challenge field and the received challenge.

Flags: The Flags field is two octets in length. This field is reserved for future use and MUST be zero.

2.4. Attributes for MPPE Support 🧚

This section describes a set of Attributes designed to support the use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up networks. MPPE is a means of representing Point to Point Protocol (PPP) [7] packets in an encrypted form. MPPE uses the RSA RC4 [8] algorithm for encryption. The length of the session key to be used for initializing encryption tables can be negotiated; MPPE currently supports 40 bit and 128 bit session keys. MPPE is negotiated within option 18 in the PPP Compression Control Protocol (CCP)[9], [10] 💖

2.4.1. MS-CHAP-MPPE-Keys

Description

okay so this Attribute is the one carrying two session keys for MPPE (Microsoft Point-to-Point Encryption) 💜 it's only ever sent back inside Access-Accept packets, so it's basically the VIP pass 🎀

here's the vibe of the format, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           Keys
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Keys (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Keys (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Keys (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Keys (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Keys (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Keys (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Keys (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Keys (cont)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

12 for MS-CHAP-MPPE-Keys. ✨

Vendor-Length

34 🌸

Keys

the Keys field is two logical sub-fields chillin' together: the LM-Key and the NT-Key 🫶

the LM-Key is eight octets long and holds the first eight bytes of the output of the function LmPasswordHash(P, This hash is constructed as follows: let the plain-text password be represented by P. (yes, the sentence is cut off in the original, we're keeping it exactly like that 🙈)

the NT-Key sub-field is sixteen octets long and holds the first sixteen octets of the hashed Windows NT password. the plaintext Keys field 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           LM-Key
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               LM-Key (cont)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           NT-Key
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               NT-Key (cont)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               NT-Key (cont)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               NT-Key (cont)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Padding
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              Padding (cont)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the Keys field MUST be encrypted by the RADIUS server using the same method defined for the User-Password Attribute [3]. padding is required because that method needs the field to be a multiple of sixteen octets in length 🔐

Implementation Note

this attribute should only be returned in response to an Access-Request packet containing MS-CHAP attributes 💅

2.4.2. MS-MPPE-Send-Key

Description

this Attribute carries a session key for MPPE, and as the name gives away, it's for encrypting packets sent from the NAS to the remote host 📤 it's also only included in Access-Accept packets 🦋

the format, left to right again 👀

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

16 for MS-MPPE-Send-Key. 🧚

Vendor-Length

> 4 🍓

Salt

the Salt field is two octets long and keeps every encrypted attribute in a given Access-Accept packet unique, since each one gets its own key 🔑 the most significant bit (leftmost) of the Salt field MUST be set (1). the contents of each Salt field in a given Access-Accept packet MUST be unique. no repeats allowed, bestie 🙅‍♀️

String

the plaintext String field is three logical sub-fields: the Key-Length and Key sub-fields (both are required), and the optional Padding sub-field 🎀 the Key-Length sub-field is one octet and holds the length of the unencrypted Key sub-field. the Key sub-field holds the actual encryption key. if the combined length (in octets) of the unencrypted Key-Length and Key sub-fields is not an even multiple of 16, then the Padding sub-field MUST be present. if it's present, its length is variable, between 1 and 15 octets.

the String field MUST be encrypted like this before it's sent 🔐

Construct a plaintext version of the String field by concate- nating the Key-Length and Key sub-fields. If necessary, pad the resulting string until its length (in octets) is an even multiple of 16. It is recommended that zero octets (0x00) be used for padding. Call this plaintext P.

Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation):

   b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
   b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
               .                      .
               .                      .
               .                      .
   b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

the resulting encrypted String field will contain c(1)+c(2)+...+c(i). ✨

on receipt, the process gets reversed to get the plaintext String back 🔄

Implementation Notes

it's possible the key returned is longer than the encryption scheme in use needs 🤷‍♀️ in that case, the RADIUS client is responsible for doing any necessary truncation ✂️

this attribute MAY be used to pass a key from an external (e.g., EAP [15]) server to the RADIUS server. the catch: the external server might not be able to encrypt the key properly, since the RADIUS shared secret could be unavailable 😬 the external server SHOULD, however, return the attribute as defined above; the Salt field SHOULD be zero-filled and padding of the String field SHOULD be done. when the RADIUS server gets the attribute from the external server, it MUST correctly set the Salt field and encrypt the String field before sending it to the RADIUS client 💖

⚠️ if the channel used to communicate the MS-MPPE-Send-Key attribute is not secure from eavesdropping, the attribute MUST be cryptographically protected. no shortcuts, periodt 💀

2.4.3. MS-MPPE-Recv-Key 🔑

Description

Okay bestie, MS-MPPE-Recv-Key is a session key for MPPE (Microsoft Point-to-Point Encryption) 🔐. The name literally tells you the job: this key is for encrypting packets the NAS gets from the remote host. It's only included in Access-Accept packets, so that's the only place it shows up 💅.

A quick look at the MS-MPPE-Recv-Key Attribute format is below. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

It's 17 for MS-MPPE-Recv-Key 🎀.

Vendor-Length

It's > 4 🌸.

Salt

The Salt field is two octets long, and its whole purpose is keeping the keys used to encrypt each encrypted attribute in a given Access-Accept packet unique 🧚. The most significant bit (the leftmost one) of the Salt field MUST be set (1). Also, the contents of each Salt field in a given Access-Accept packet MUST be unique. No copy-pasting salts, babe 🙈.

String

The plaintext String field has three logical sub-fields: the Key-Length and Key sub-fields (both of which are required), and the optional Padding sub-field 🍓. The Key-Length sub-field is one octet and holds the length of the unencrypted Key sub-field. The Key sub-field holds the actual encryption key 🔑. If the combined length (in octets) of the unencrypted Key-Length and Key sub-fields is not an even multiple of 16, then the Padding sub-field MUST be present. If it's there, its length is variable, anywhere from 1 to 15 octets ✨.

The String field MUST be encrypted before it's sent, and here's the recipe 👩‍🍳:

Make a plaintext version of the String field by concatenating the Key-Length and Key sub-fields. If needed, pad the result until its length (in octets) is an even multiple of 16. Zero octets (0x00) are recommended for padding. Call this plaintext P.
Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the matching Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption goes like this ('+' means concatenation):

b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
            .                      .
            .                      .
            .                      .
b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

The resulting encrypted String field will contain c(1)+c(2)+...+c(i) 💖. On receipt, the process gets reversed to get back the plaintext String 🔄.

Implementation Notes

It's possible the key that comes back is longer than what the encryption scheme in use needs. If so, the RADIUS client is responsible for doing any necessary truncation ✂️.

This attribute MAY be used to pass a key from an external server (e.g., EAP [15]) to the RADIUS server 🛰️. The tricky bit is that the external server might not be able to encrypt the key properly, since the RADIUS shared secret might be unavailable 😭. The external server SHOULD, however, still return the attribute as defined above. The Salt field SHOULD be zero-filled, and padding of the String field SHOULD be done. When the RADIUS server gets the attribute from the external server, it MUST correctly set the Salt field and encrypt the String field before sending it to the RADIUS client 🔐. And if the channel used to carry the MS-MPPE-Recv-Key attribute isn't secure from eavesdropping, the attribute MUST be cryptographically protected. No peeking allowed 👀🚫.

2.4.4. MS-MPPE-Encryption-Policy 🛡️

Description

The MS-MPPE-Encryption-Policy Attribute is how you signal whether encryption is allowed or required 💜. If the Policy field is 1 (Encryption-Allowed), any or none of the encryption types listed in the MS-MPPE-Encryption-Types Attribute MAY be used. If the Policy field is 2 (Encryption-Required), any of the encryption types listed in the MS-MPPE-Encryption-Types Attribute MAY be used, but at least one MUST be used. Very strict, very iconic 👑.

Here's the format summary. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Policy
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Policy (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

It's 7 for MS-MPPE-Encryption-Policy 🎀.

Vendor-Length

It's 6 🌸.

Policy

The Policy field is 4 octets long. The defined values are:

1      Encryption-Allowed 2      Encryption-Required

2.4.5. MS-MPPE-Encryption-Types 🧁

Description

The MS-MPPE-Encryption-Types Attribute tells you which types of encryption are available for use with MPPE 🔐. It's a four octet integer that gets read as a string of bits, so every bit is its own little yes or no 🤓.

Here's the format summary. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Types
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Types (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

It's 8 for MS-MPPE-Encryption-Types 🎀.

Vendor-Length

It's 6 🌸.

Policy

The Types field is 4 octets long. Here's how the Types field looks:

     3                   2                   1
   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                         |S|L| |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If the L bit is set, RC4[5] encryption using a 40-bit key is allowed. If the S bit is set, RC4 encryption using a 128-bit key is allowed. If both the L and S bits are set, then either 40- or 128-bit keys may be used with the RC4 algorithm 🌈.

2.5. Attributes for BAP Support 📞

This section is all about a set of vendor-specific RADIUS attributes that help control bandwidth allocation dynamically in multilink PPP [11] 🎛️. The attributes say whether the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or required on incoming calls. They also set the level of line capacity (as a percentage) that utilization must drop below before a link is eligible to be dropped, plus how long (in seconds) a link has to be under-utilized before it actually gets dropped ⏱️.

2.5.1. MS-BAP-Usage 📶

Description

This Attribute describes whether BAP usage is allowed, disallowed or required on new multilink calls. It MAY be used in Access-Accept packets.

Here's the format summary. The fields go from 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

It's 13 for MS-BAP-Usage 🎀.

Vendor-Length

It's 6 🌸.

Value

The Value field is four octets. The options are:

0      BAP usage not allowed
1      BAP usage allowed
2      BAP usage required

2.5.2. MS-Link-Utilization-Threshold 📉

Description

This Attribute is the percentage of available bandwidth utilization that a link has to fall below before it becomes eligible for termination 💅. Permissible values for the MS-Link-Utilization-Threshold Attribute are in the range 1-100, inclusive. It's only used in Access-Accept packets.

Here's the format summary. The fields go from 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

It's 14 for MS-Link-Utilization-Threshold 🎀.

Vendor-Length

It's 6 🌸.

Value

The Value field is four octets long, and it holds the percentage of available bandwidth utilization below which the link must fall before it's eligible for termination. Permissible values are in the range 1-100, inclusive 💯.

2.5.3. MS-Link-Drop-Time-Limit ⏳

Description

The MS-Link-Drop-Time-Limit Attribute says how long (in seconds) a link must be underutilized before it gets dropped. It MAY only be included in Access-Accept packets.

Here's the format summary. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Value (cont)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

It's 15 for MS-Link-Drop-Time-Limit 🎀.

Vendor-Length

It's 6 🌸.

Value

The Value field is the number of seconds that a link must be underutilized (i.e., display bandwidth utilization below the threshold specified in the MS-Link-Utilization-Threshold Attribute) before the link is dropped 🫶.

2.6. Attributes for ARAP Support 🍎

This section describes a set of Attributes designed to support the Apple Remote Access Protocol (ARAP) ✨.

2.6.1. MS-Old-ARAP-Password 🌸

Description

Okay so this one carries your OLD ARAP password during an ARAP password change 🔐 It MAY show up in Access-Request packets.

Here's the layout (fields go left to right, bestie 🎀):

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |          String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

It's 19, which means MS-Old-ARAP-Password 💜

Vendor-Length

> 3

String

The String field is one or more octets. It holds the old ARAP password, DES-encrypted using itself as the key 🔑

2.6.2. MS-New-ARAP-Password ✨

Description

This is the NEW ARAP password, sent during that same password change 🦋 It MAY show up in Access-Request packets too.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |          String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

20 for MS-New-ARAP-Password. Iconic 👑

Vendor-Length

> 3

String

One or more octets. It's the new ARAP password, DES-encrypted using the old ARAP password as the key 🔐✨

2.6.3. MS-ARAP-Password-Change-Reason 🎀

Description

This one explains WHY the server is asking for a password change 🙈 It MAY show up in Access-Challenge packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |             Why
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Why (cont)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

21 for MS-ARAP-Password-Change-Reason

Vendor-Length

6

Why

The Why field is 4 octets long. These are the defined values:

Just-Change-Password            1
Expired-Password                2
Admin-Requires-Password-Change  3
Password-Too-Short              4

2.6.4. MS-ARAP-Challenge 🧚

Description

Only shows up in an Access-Request packet that has a Framed-Protocol Attribute with the value 3 (ARAP) 💖

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           Challenge
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Challenge (cont)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Challenge (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

33 for MS-ARAP-Challenge

Vendor-Length

10

Value

The Challenge field is 8 octets long. It holds the challenge, as two 4-octet quantities, that the NAS sent to the peer 🫶

2.7. Miscellaneous Attributes 💅

This section covers attributes that don't fit neatly into any category, but they're still used to identify and run Microsoft remote access products 🌈

2.7.1. MS-RAS-Vendor 🦋

Description

This tells you which manufacturer made the RADIUS client machine 🏭 It MAY show up in both Access-Request and Accounting-Request packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           Vendor-ID
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-ID (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

9 for MS-RAS-Vendor

Vendor-Length

6

Vendor-ID

The Vendor-ID field is 4 octets long. The high-order octet is 0, and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor, in network byte order, as defined in the Assigned Numbers RFC [13].

2.7.2. MS-RAS-Version 🎀

Description

This one shares the version of the RADIUS client software 💜 A robust implementation SHOULD include it in packets that contain an MS-RAS-Vendor Attribute, and it SHOULD NOT be sent in packets that don't contain an MS-RAS-Vendor Attribute. It MAY show up in both Access-Request and Accounting-Request packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |          String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

18 for MS-RAS-Version

Vendor-Length

> 3

String

The String field is one or more octets. The actual format of the info is vendor specific, and a robust implementation SHOULD support the field as undistinguished octets 🤓

2.7.3. MS-Filter 🔥

Description

This one transmits traffic filters 🚦 It MAY show up in both Access-Accept and Accounting-Request packets.

If there are multiple MS-Filter Attributes in one packet, they MUST be in order, and they MUST be consecutive attributes in the packet. Don't skip this one bestie 😭

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           Filter...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

22 for MS-Filter Attribute

Vendor-Length

> 3

Filter

The Filter field is one or more octets. It's a sequence of undifferentiated octets 🧩

If several MS-Filter Attributes show up in a single Access-Accept packet, the Filter field from each one MUST be concatenated in the order received to form the actual filter. Main character energy 👑

2.7.4. MS-Acct-Auth-Type 🌸

Description

This tells you how the dial-up user was authenticated 🔐 It MAY show up in Accounting-Request packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           Auth-Type
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Auth-Type (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

23 for MS-Acct-Auth-Type

Vendor-Length

6

Auth-Type

The Auth-Type field is 4 octets long. These values are defined for it:

PAP               1
CHAP              2
MS-CHAP-1         3
MS-CHAP-2         4
EAP               5

2.7.5. MS-Acct-EAP-Type ✨

Description

This one tells you which Extensible Authentication Protocol (EAP) [15] type was used to authenticate the dial-up user 🧚 It MAY show up in Accounting-Request packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           EAP-Type
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             EAP-Type (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

24 for MS-Acct-EAP-Type

Vendor-Length

6

Auth-Type

The EAP-Type field is 4 octets long. These values are currently defined for it:

MD5                    4
OTP                    5
Generic Token Card     6
TLS                    13

2.7.6. MS-Primary-DNS-Server 💖

Description

This one says which primary Domain Name Server (DNS) [16, 17] server the PPP peer should use 🌐 It MAY show up in both Access-Accept and Accounting-Request packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           IP-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           IP-Address (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

28 for MS-Primary-DNS-Server

Vendor-Length

6

IP-Address

The IP-Address field is 4 octets long. It holds the IP address of the primary DNS server 🫶

2.7.7. MS-Secondary-DNS-Server 🦋

Description

Same vibe as the primary one, but for the backup 🎀 It tells the PPP peer which secondary DNS server to use. It MAY show up in both Access-Accept and Accounting-Request packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           IP-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           IP-Address (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

29 for MS-Secondary-DNS-Server

Vendor-Length

6

IP-Address

The IP-Address field is 4 octets long. It holds the IP address of the secondary DNS server 💜

2.7.8. MS-Primary-NBNS-Server ✨

Okay so this attribute tells the PPP peer where its primary NetBIOS Name Server (NBNS) [18] lives 🖧. It MAY be included in both Access-Accept and Accounting-Request packets 🎀.

Here's the layout of the MS-Primary-NBNS-Server attribute. The 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           IP-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           IP-Address (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 30 for MS-Primary-NBNS-Server 🍓

Vendor-Length 6 🌸

IP-Address The IP-Address field is 4 octets in length. It contains the IP address of the primary NBNS server 🧚

2.7.9. MS-Secondary-NBNS-Server 🦋

So this is the sidekick version. The MS-Secondary-NBNS-Server attribute tells the PPP peer where its secondary server is. It MAY be included in both Access-Accept and Accounting-Request packets 🫶

Heads up bestie 🙈: the original text literally says "secondary DNS server" in this description, so I kept it word for word. The rest of the attribute is all about NBNS.

Format time! Fields go left to right, same as before 💜

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |           IP-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           IP-Address (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 31 for MS-Secondary-NBNS-Server 🎀

Vendor-Length 6 ✨

IP-Address The IP-Address field is 4 octets in length. It contains the IP address of the secondary NBNS server 💖

3. Table of Attributes 📋

Okay this table is the cheat sheet 🤩 It shows which attributes can show up in which kinds of packets, and how many of each you're allowed to have.

 Request Accept Reject Challenge Acct-Request #  Attribute
 0-1     0      0      0         0             1 MS-CHAP-Response
 0       0      0-1    0         0             2 MS-CHAP-Error
 0-1     0      0      0         0             3 MS-CHAP-CPW-1
 0-1     0      0      0         0             4 MS-CHAP-CPW-2
 0+      0      0      0         0             5 MS-CHAP-LM-Enc-PW
 0+      0      0      0         0             6 MS-CHAP-NT-Enc-PW
 0       0-1    0      0         0             7 MS-MPPE-Encryption-
                                                 Policy
 0       0-1    0      0         0             8 MS-MPPE-Encryption-Type
 0-1     0      0      0         0-1           9 MS-RAS-Vendor
 0       0-1    0      0         0-1          10 MS-CHAP-Domain
 0-1     0      0      0-1       0            11 MS-CHAP-Challenge
 0       0-1    0      0         0            12 MS-CHAP-MPPE-Keys
 0       0-1    0      0         0            13 MS-BAP-Usage
 0       0-1    0      0         0            14 MS-Link-Utilization-
                                                 Threshold
 0       0-1    0      0         0            15 MS-Link-Drop-Time-Limit
 0       0-1    0      0         0            16 MS-MPPE-Send-Key
 0       0-1    0      0         0            17 MS-MPPE-Recv-Key
 0-1     0      0      0         0-1          18 MS-RAS-Version
 0-1     0      0      0         0            19 MS-Old-ARAP-Password
 0-1     0      0      0         0            20 MS-New-ARAP-Password
 0       0      0      0-1       0            21 MS-ARAP-PW-Change-
                                                 Reason

 0       0+     0      0         0+           22 MS-Filter
 0       0      0      0         0-1          23 MS-Acct-Auth-Type
 0       0      0      0         0-1          24 MS-Acct-EAP-Type
 0-1     0      0      0         0            25 MS-CHAP2-Response
 0       0-1    0      0         0            26 MS-CHAP2-Success
 0-1     0      0      0         0            27 MS-CHAP2-CPW
 0       0-1    0      0         0-1          28 MS-Primary-DNS-Server
 0       0-1    0      0         0-1          29 MS-Secondary-DNS-Server
 0       0-1    0      0         0-1          30 MS-Primary-NBNS-Server
 0       0-1    0      0         0-1          31 MS-Secondary-NBNS-
                                                 Server
 0-1     0      0      0         0            33 MS-ARAP-Challenge

Now the legend, so you know what the numbers mean 🔍

0     This attribute MUST NOT be present in packet.
0+    Zero or more instances of this attribute MAY be present in packet.
0-1   Zero or one instance of this attribute MAY be present in packet.

4. Security Considerations 🔒

Real talk, this part is serious 😭 MS-CHAP, just like PPP CHAP, is susceptible to dictionary attacks. So users need to pick their passwords with care and make them long enough that nobody can easily guess them 🔐

Also, the scheme that protects the Keys field of the MS-CHAP-MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is believed to be relatively secure on the wire. BUT, and this is the big plot twist 💀, RADIUS proxies will decrypt and re-encrypt the field for forwarding. So these attributes SHOULD NOT be used on networks where untrusted RADIUS proxies reside 🚫

Don't let untrusted proxies near these keys, periodt 👑

5. Acknowledgements 🫶

Huge thanks to these legends for useful suggestions and editorial feedback 💖 Carl Rigney (cdr@livingston.com), Ashwin Palekar (ashwinp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com), and Don Rule (don-aldr@microsoft.com). Iconic team 👑

6. Editor's Address 📫

Got questions about this memo? Here's where to send them 💌

Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052

Phone: +1 425 703 1559
Fax:   +1 425 936 7329
EMail: glennz@microsoft.com

7. References 📚

[1] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Access Dial In User Service", RFC 2138, April 1997.

[4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.

[5] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption (MPPE) Protocol", Work in Progress.

[7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[8] RC4 is a proprietary encryption algorithm available under license from RSA Data Security Inc. For licensing information, contact: RSA Data Security, Inc. 100 Marine Parkway Redwood City, CA 94065-1031

[9] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", RFC 2118, March 1997.

[10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.

[11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

[12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)", RFC 2125, March 1997.

[13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

[14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in Progress.

[15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.

[16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/ISI, November 1987.

[17] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002, March 1987.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🦋

📦 where this page comes from

ietf: rfc2548 1999-03
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 2548

RFC 2548: Microsoft Vendor-specific RADIUS Attributes ✨

Status of this Memo

Copyright Notice

Abstract

1. Specification of Requirements

2. Attributes

2.1. Attributes for Support of MS-CHAP Version 1

2.1.1. Introduction

2.1.2. MS-CHAP-Challenge

2.1.3. MS-CHAP-Response

2.1.4. MS-CHAP-Domain

2.1.5. MS-CHAP-Error

2.1.6. MS-CHAP-CPW-1 ✨

2.1.7. MS-CHAP-CPW-2 🦋

2.1.8. MS-CHAP-LM-Enc-PW 🌈

2.2. MS-CHAP-NT-Enc-PW 💅

2.3. Attributes for Support of MS-CHAP Version 2 🦋

2.3.1. Introduction

2.3.2. MS-CHAP2-Response 💖

2.3.3. MS-CHAP2-Success ✨

2.3.4. MS-CHAP2-CPW 🍓

2.4. Attributes for MPPE Support 🧚

2.4.1. MS-CHAP-MPPE-Keys

2.4.2. MS-MPPE-Send-Key

2.4.3. MS-MPPE-Recv-Key 🔑

2.4.4. MS-MPPE-Encryption-Policy 🛡️

2.4.5. MS-MPPE-Encryption-Types 🧁

2.5. Attributes for BAP Support 📞

2.5.1. MS-BAP-Usage 📶

2.5.2. MS-Link-Utilization-Threshold 📉

2.5.3. MS-Link-Drop-Time-Limit ⏳

2.6. Attributes for ARAP Support 🍎

2.6.1. MS-Old-ARAP-Password 🌸

2.6.2. MS-New-ARAP-Password ✨

2.6.3. MS-ARAP-Password-Change-Reason 🎀

2.6.4. MS-ARAP-Challenge 🧚

2.7. Miscellaneous Attributes 💅

2.7.1. MS-RAS-Vendor 🦋

2.7.2. MS-RAS-Version 🎀

2.7.3. MS-Filter 🔥

2.7.4. MS-Acct-Auth-Type 🌸

2.7.5. MS-Acct-EAP-Type ✨

2.7.6. MS-Primary-DNS-Server 💖

2.7.7. MS-Secondary-DNS-Server 🦋

2.7.8. MS-Primary-NBNS-Server ✨

2.7.9. MS-Secondary-NBNS-Server 🦋

3. Table of Attributes 📋

4. Security Considerations 🔒

5. Acknowledgements 🫶

6. Editor's Address 📫

7. References 📚

10. Full Copyright Statement ©