diff options
Diffstat (limited to 'rfc/rfc2548.txt')
| -rw-r--r-- | rfc/rfc2548.txt | 2299 |
1 files changed, 2299 insertions, 0 deletions
diff --git a/rfc/rfc2548.txt b/rfc/rfc2548.txt new file mode 100644 index 0000000..35c83c3 --- /dev/null +++ b/rfc/rfc2548.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2548 Microsoft Corporation +Category: Informational March 1999 + + + Microsoft Vendor-specific RADIUS Attributes + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document describes the set of Microsoft vendor-specific RADIUS + attributes. These attributes are designed to support Microsoft + proprietary dial-up protocols and/or provide support for features + which is not provided by the standard RADIUS attribute set [3]. It + is expected that this memo will be updated whenever Microsoft defines + a new vendor-specific attribute, since its primary purpose is to + provide an open, easily accessible reference for third-parties + wishing to interoperate with Microsoft products. + +1. Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [2]. + +2. Attributes + + The following sections describe sub-attributes which may be + transmitted in one or more RADIUS attributes of type Vendor-Specific + [3]. More than one sub-attribute MAY be transmitted in a single + Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD + be packed as a sequence of Vendor-Type/Vendor-Length/Value triples + following the inital Type, Length and Vendor-ID fields. The Length + field of the Vendor-Specific Attribute MUST be set equal to the sum + of the Vendor-Length fields of the sub-attributes contained in the + Vendor-Specific Attribute, plus six. The Vendor-ID field of the + Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft). + + + + + +Zorn Informational [Page 1] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1. Attributes for Support of MS-CHAP Version 1 + +2.1.1. Introduction + + Microsoft created Microsoft Challenge-Handshake Authentication + Protocol (MS-CHAP) [4] to authenticate remote Windows workstations, + providing the functionality to which LAN-based users are accustomed. + Where possible, MS-CHAP is consistent with standard CHAP [5], and the + differences are easily modularized. Briefly, the differences between + MS-CHAP and standard CHAP are: + + * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP + option 3, Authentication Protocol. + + * The MS-CHAP Response packet is in a format designed 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. + + * MS-CHAP provides an authenticator-controlled authentication + retry mechanism. + + * MS-CHAP provides an authenticator-controlled password changing + mechanism. + + * MS-CHAP defines an extended set of reason-for-failure codes, + returned in the Failure packet Message field. + + The attributes defined in this section reflect these differences. + +2.1.2. MS-CHAP-Challenge + + Description + + This Attribute contains the challenge sent by a NAS to a Microsoft + Challenge-Handshake Authentication Protocol (MS-CHAP) user. It + MAY be used in both Access-Request and Access-Challenge packets. + + A summary of the MS-CHAP-Challenge Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + +Zorn Informational [Page 2] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + 11 for MS-CHAP-Challenge. + + Vendor-Length + > 2 + + String + The String field contains the MS-CHAP challenge. + +2.1.3. MS-CHAP-Response + + Description + + This Attribute contains the response value provided by a PPP + Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) + user in response to the challenge. It is only used in Access- + Request packets. + + A summary of the MS-CHAP-Response Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 3] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + 1 for MS-CHAP-Response. + + Vendor-Length + 52 + + Ident + Identical to the PPP CHAP Identifier. + + Flags + The Flags field is one octet in length. 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 non-empty), but the NT-Response SHOULD be tried + first. If it is zero, the NT-Response field MUST be ignored and + the LM-Response field used. + + + + + +Zorn Informational [Page 4] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + LM-Response + The LM-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + NT-Response + + The NT-Response field is 24 octets in length 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 indicates the Windows NT domain in + which the user was authenticated. It MAY be included in both + Access-Accept and Accounting-Request packets. + + A summary of the MS-CHAP-Domain Attribute format is given below. The + fields are transmitted 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 + 10 for MS-CHAP-Domain. + + Vendor-Length + > 3 + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + String + This field contains the name in ASCII of the Windows NT domain in + which the user was authenticated. + + + + + + + + + + +Zorn Informational [Page 5] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1.5. MS-CHAP-Error + + Description + + The MS-CHAP-Error Attribute contains error data related to the + preceding MS-CHAP exchange. 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. + + A summary of the MS-CHAP-Error Attribute format is given below. The + fields are transmitted 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 + 2 for MS-CHAP-Error. + + Vendor-Length + > 3 + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + String + This field contains specially formatted ASCII text, which is + interpreted by the authenticating peer. + +2.1.6. MS-CHAP-CPW-1 + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used 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 less than 2. + + A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Zorn Informational [Page 6] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + The Code field is one octet in length. Its value is always 5. + + + +Zorn Informational [Page 7] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + LM-Old-Password + The LM-Old-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the old password. + + LM-New-Password + The LM-New-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the new password. + + NT-Old-Password + The NT-Old-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the old password. + + NT-New-Password + The NT-New-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the new password. + + New-LM-Password-Length + The New-LM-Password-Length field is two octets in length and + contains the length in octets of the new LAN Manager-compatible + password. + + Flags + The Flags field is two octets in length. If the least significant + bit of the Flags field is one, this indicates that 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. + +2.1.7. MS-CHAP-CPW-2 + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used 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 2. + + A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Zorn Informational [Page 8] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Zorn Informational [Page 9] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Vendor-Type + 4 for MS-CHAP-PW-2 + + Vendor-Length + 86 + + Code + 6 + + 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-LM-Enc-PW, MS-CHAP-NT- + Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access- + Request packet. + + Old-NT-Hash + The Old-NT-Hash field is 16 octets in length. It contains the old + Windows NT password hash encrypted with the new Windows NT + password hash. + + Old-LM-Hash + The Old-LM-Hash field is 16 octets in length. It contains the old + Lan Manager password hash encrypted with the new Windows NT + password hash. + + LM-Response + The LM-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + NT-Response + The NT-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + Flags + The Flags field is two octets in length. If the least significant + bit (bit 0) of this field 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 least significant bit of the + field is zero, the NT-Response field MUST be ignored and the LM- + Response field used instead. If bit 1 of the Flags field 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. + + + + +Zorn Informational [Page 10] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1.8. MS-CHAP-LM-Enc-PW + + Description + + This Attribute contains the new Windows NT password encrypted with + the old LAN Manager password hash. The encrypted Windows NT + password is 516 octets in length; since this is longer than the + maximum lengtth of a RADIUS attribute, the password must be split + into several attibutes for transmission. A 2 octet sequence + number is included in the attribute to help preserve ordering of + the password fragments. + + This Attribute is only used in Access-Request packets, in + conjunction with the MS-CHAP-CPW-2 attribute. It 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 2 or greater. + + A summary of the MS-CHAP-LM-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 + 5 for MS-CHAP-LM-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. + + + + + + + +Zorn Informational [Page 11] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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.2. MS-CHAP-NT-Enc-PW + + Description + + This Attribute contains the new Windows NT password encrypted with + the old Windows NT password hash. The encrypted Windows NT + password is 516 octets in length; since this is longer than the + maximum lengtth of a RADIUS attribute, the password must be split + into several attibutes for transmission. A 2 octet sequence + number is included in the attribute to help preserve ordering of + the password fragments. + + This Attribute is only used in Access-Request packets, in conjunc- + tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It + 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 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. + + + + + + +Zorn Informational [Page 12] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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. + + + +Zorn Informational [Page 13] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + + + +Zorn Informational [Page 14] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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). + + + + +Zorn Informational [Page 15] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 16] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + + + +Zorn Informational [Page 17] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 a 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 + + The MS-CHAP-MPPE-Keys Attribute contains two session keys for use + by the Microsoft Point-to-Point Encryption Protocol (MPPE). This + Attribute is only included in Access-Accept packets. + + A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 18] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 consists of two logical sub-fields: the LM-Key and + the NT-Key. The LM-Key is eight octets in length and contains 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. + + The NT-Key sub-field is sixteen octets in length and contains the + first sixteen octets of the hashed Windows NT password. The + format of the plaintext Keys field is illustrated in the following + diagram: + + + + + + + + + + + + +Zorn Informational [Page 19] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 the method referenced above requires the field + to be encrypted 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 + + The MS-MPPE-Send-Key Attribute contains a session key for use by + the Microsoft Point-to-Point Encryption Protocol (MPPE). As the + name implies, this key is intended for encrypting packets sent + from the NAS to the remote host. This Attribute is only included + in Access-Accept packets. + + A summary of the MS-MPPE-Send-Key Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 20] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 in length and is used to ensure the + uniqueness of the keys used to encrypt each of the encrypted + attributes occurring in a given Access-Accept packet. 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. + + String + The plaintext String field consists of 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 in length and contains the length of the unencrypted Key + sub-field. The Key sub-field contains 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 is present, the length of the + Padding sub-field is variable, between 1 and 15 octets. The + String field MUST be encrypted as follows, prior to transmission: + + 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): + + + +Zorn Informational [Page 21] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 is reversed to yield the plaintext String. + + Implementation Notes + It is possible that the length of the key returned may be larger + than needed for the encryption scheme in use. In this case, the + RADIUS client is responsible for performing any necessary + truncation. + + This attribute MAY be used to pass a key from an external (e.g., + EAP [15]) server to the RADIUS server. In this case, it may be + impossible for the external server to correctly encrypt the key, + since the RADIUS shared secret might 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 receives the attribute + from the external server, it MUST correctly set the Salt field and + encrypt the String field before transmitting 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. + +2.4.3. MS-MPPE-Recv-Key + + Description + + The MS-MPPE-Recv-Key Attribute contains a session key for use by + the Microsoft Point-to-Point Encryption Protocol (MPPE). As the + name implies, this key is intended for encrypting packets received + by the NAS from the remote host. This Attribute is only included + in Access-Accept packets. + + A summary of the MS-MPPE-Recv-Key Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + +Zorn Informational [Page 22] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + 17 for MS-MPPE-Recv-Key. + + Vendor-Length + > 4 + + Salt + The Salt field is two octets in length and is used to ensure the + uniqueness of the keys used to encrypt each of the encrypted + attributes occurring in a given Access-Accept packet. 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. + + String + The plaintext String field consists of 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 in length and contains the length of the unencrypted Key + sub-field. The Key sub-field contains 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 is present, the length of the + Padding sub-field is variable, between 1 and 15 octets. The + String field MUST be encrypted as follows, prior to transmission: + + Construct a plaintext version of the String field by + concatenating 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): + + + +Zorn Informational [Page 23] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 is reversed to yield the plaintext String. + + Implementation Notes + It is possible that the length of the key returned may be larger + than needed for the encryption scheme in use. In this case, the + RADIUS client is responsible for performing any necessary + truncation. + + This attribute MAY be used to pass a key from an external (e.g., + EAP [15]) server to the RADIUS server. In this case, it may be + impossible for the external server to correctly encrypt the key, + since the RADIUS shared secret might 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 receives the attribute + from the external server, it MUST correctly set the Salt field and + encrypt the String field before transmitting it to the RADIUS + client. If the channel used to communicate the MS-MPPE-Recv-Key + attribute is not secure from eavesdropping, the attribute MUST be + cryptographically protected. + +2.4.4. MS-MPPE-Encryption-Policy + + Description + + The MS-MPPE-Encryption-Policy Attribute may be used to signify + whether the use of encryption is allowed or required. If the + Policy field is equal to 1 (Encryption-Allowed), any or none of + the encryption types specified in the MS-MPPE-Encryption-Types + Attribute MAY be used. If the Policy field is equal to 2 + (Encryption-Required), any of the encryption types specified in + the MS-MPPE-Encryption-Types Attribute MAY be used, but at least + one MUST be used. + + A summary of the MS-MPPE-Encryption-Policy Attribute format is given + below. The fields are transmitted left to right. + + + + + +Zorn Informational [Page 24] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + 7 for MS-MPPE-Encryption-Policy. + + Vendor-Length + 6 + + Policy + The Policy field is 4 octets in length. Defined values are: + + 1 Encryption-Allowed 2 Encryption-Required + +2.4.5. MS-MPPE-Encryption-Types + + Description + + The MS-MPPE-Encryption-Types Attribute is used to signify the + types of encryption available for use with MPPE. It is a four + octet integer that is interpreted as a string of bits. + + A summary of the MS-MPPE-Encryption-Policy Attribute format is given + below. The fields are transmitted 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 + 8 for MS-MPPE-Encryption-Types. + + Vendor-Length + 6 + + Policy + The Types field is 4 octets in length. The following diagram + illustrates the Types field. + + + + +Zorn Informational [Page 25] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 describes a set of vendor-specific RADIUS attributes + designed to support the dynamic control of bandwidth allocation in + multilink PPP [11]. Attributes are defined that specify whether use + of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or + required on incoming calls, the level of line capacity (expressed as + a percentage) below which utilization must fall before a link is + eligible to be dropped, and the length of time (in seconds) that a + link must be under-utilized before it is dropped. + +2.5.1. MS-BAP-Usage + + Description + + This Attribute describes whether the use of BAP is allowed, + disallowed or required on new multilink calls. It MAY be used in + Access-Accept packets. + + A summary of the MS-BAP-Usage 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 13 for MS-BAP-Usage. + + Vendor-Length + 6 + + + + + +Zorn Informational [Page 26] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Value + The Value field is four octets. + + 0 BAP usage not allowed + 1 BAP usage allowed + 2 BAP usage required + +2.5.2. MS-Link-Utilization-Threshold + + Description + + This Attribute represents the percentage of available bandwidth + utilization below which the link must fall before the link is + eligible for termination. Permissible values for the MS-Link- + Utilization-Threshold Attribute are in the range 1-100, inclusive. + It is only used in Access-Accept packets. + + A summary of the MS-Link-Utilization-Threshold 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 14 for MS-Link-Utilization-Threshold + + Vendor-Length 6 + + Value The Value field is four octets in length and represents the + percentage of available bandwidth utilization below which the link + must fall before the link is 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 indicates the length of time + (in seconds) that a link must be underutilized before it is + dropped. It MAY only be included in Access-Accept packets. + + A summary of the MS-Link-Drop-Time-Limit Attribute format is given + below. The fields are transmitted left to right. + + + +Zorn Informational [Page 27] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + 15 for MS-Link-Drop-Time-Limit + + Vendor-Length + 6 + + Value + The Value field represents 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 + + The MS-Old-ARAP-Password Attribute is used to transmit the old + ARAP password during an ARAP password change operation. It MAY be + included in Access-Request packets. + + A summary of the MS-Old-ARAP-Password Attribute Attribute format is + given below. The fields are transmitted 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 + 19 for MS-Old-ARAP-Password Attribute + + Vendor-Length + > 3 + + + + +Zorn Informational [Page 28] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + String + The String field is one or more octets. It contains the old ARAP + password DES-encrypted using itself as the key. + +2.6.2. MS-New-ARAP-Password + + Description + + The MS-New-ARAP-Password Attribute is used to transmit the new + ARAP password during an ARAP password change operation. It MAY be + included in Access-Request packets. + + A summary of the MS-New-ARAP-Password Attribute Attribute format is + given below. The fields are transmitted 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 + 20 for MS-New-ARAP-Password Attribute + + Vendor-Length + > 3 + + String + The String field is one or more octets. It contains the new ARAP + password DES-encrypted using the old ARAP password as the key. + +2.6.3. MS-ARAP-Password-Change-Reason + + Description + + The MS-ARAP-Password-Change-Reason Attribute is used to indicate + reason for a server-initiated password change. It MAY be included + in Access-Challenge packets. + + A summary of the MS-ARAP-Password-Change-Reason Attribute format is + given below. The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 29] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 in length. The following values are + defined: + Just-Change-Password 1 + Expired-Password 2 + Admin-Requires-Password-Change 3 + Password-Too-Short 4 + +2.6.4. MS-ARAP-Challenge + + Description + + This attribute is only present in an Access-Request packet + containing a Framed-Protocol Attribute with the value 3 (ARAP). + + A summary of the MS-ARAP-Challenge Attribute format is given below. + The fields are transmitted 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 | Challenge + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 33 for MS-ARAP-Challenge + + Vendor-Length + 10 + + + + +Zorn Informational [Page 30] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Value + The Challenge Field is 8 octets in length. It contains the + challenge (as two 4-octet quantities) sent by the NAS to the peer. + +2.7. Miscellaneous Attributes + + This section describes attributes which do not fall into any + particular category, but are used in the identification and operation + of Microsoft remote access products. + +2.7.1. MS-RAS-Vendor + + Description + + The MS-RAS-Vendor Attribute is used to indicate the manufacturer + of the RADIUS client machine. It MAY be included in both Access- + Request and Accounting-Request packets. + + A summary of the MS-RAS-Vendor Attribute format is given below. The + fields are transmitted 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 | Vendor-ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-ID (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 9 for MS-RAS-Vendor + + Vendor-Length + 6 + + Vendor-ID + The Vendor-ID field is 4 octets in length. 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 + + The MS-RAS-Version Attribute is used to indicate the version of + the RADIUS client software. This attribute SHOULD be included in + packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be + + + +Zorn Informational [Page 31] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + sent in packets which do not contain an MS-RAS-Vendor Attribute. + It MAY be included in both Access-Request and Accounting-Request + packets. + + A summary of the MS-RAS-Version Attribute format is given below. The + fields are transmitted 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 + 18 for MS-RAS-Version + + Vendor-Length + > 3 + + String + The String field is one or more octets. The actual format of the + information is vendor specific, and a robust implementation SHOULD + support the field as undistinguished octets. + +2.7.3. MS-Filter + + Description + + The MS-Filter Attribute is used to transmit traffic filters. It + MAY be included in both Access-Accept and Accounting-Request + packets. + + If multiple MS-Filter Attributes are contained within a packet, + they MUST be in order and they MUST be consecutive attributes in + the packet. + + A summary of the MS-Filter Attribute format is given below. The + fields are transmitted 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 | Filter... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 22 for MS-Filter Attribute + + + + +Zorn Informational [Page 32] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Vendor-Length + > 3 + + Filter + The Filter field is one or more octets. It contains a sequence of + undifferentiated octets. + + If multiple MS-Filter Attributes occur in a single Access-Accept + packet, the Filter field from each MUST be concatenated in the + order received to form the actual filter. + +2.7.4. MS-Acct-Auth-Type + + Description + + The MS-Acct-Auth-Type Attribute is used to represent the method + used to authenticate the dial-up user. It MAY be included in + Accounting-Request packets. + + A summary of the MS-Acct-Auth-Type Attribute format is given below. + The fields are transmitted 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 | 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 in length. The following values + are defined for this field: + + PAP 1 + CHAP 2 + MS-CHAP-1 3 + MS-CHAP-2 4 + EAP 5 + + + + + + +Zorn Informational [Page 33] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.7.5. MS-Acct-EAP-Type + + Description + + The MS-Acct-EAP-Type Attribute is used to represent the Extensible + Authentication Protocol (EAP) [15] type used to authenticate the + dial-up user. It MAY be included in Accounting-Request packets. + + A summary of the MS-Acct-EAP-Type Attribute format is given below. + The fields are transmitted 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 | 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 in length. The following values + are currently defined for this field: + + MD5 4 + OTP 5 + Generic Token Card 6 + TLS 13 + +2.7.6. MS-Primary-DNS-Server + + Description + + The MS-Primary-DNS-Server Attribute is used to indicate the + address of the primary Domain Name Server (DNS) [16, 17] server to + be used by the PPP peer. It MAY be included in both Access-Accept + and Accounting-Request packets. + + A summary of the MS-Primary-DNS-Server Attribute format is given + below. The fields are transmitted left to right. + + + + + + +Zorn Informational [Page 34] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 in length. It contains the IP + address of the primary DNS server. + +2.7.7. MS-Secondary-DNS-Server + + Description + + The MS-Secondary-DNS-Server Attribute is used to indicate the + address of the secondary DNS server to be used by the PPP peer. + It MAY be included in both Access-Accept and Accounting-Request + packets. + + A summary of the MS-Secondary-DNS-Server Attribute format is given + below. The fields are transmitted 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 | 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 in length. It contains the IP + address of the secondary DNS server. + + + + +Zorn Informational [Page 35] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.7.8. MS-Primary-NBNS-Server + + Description + + The MS-Primary-NBNS-Server Attribute is used to indicate the + address of the primary NetBIOS Name Server (NBNS) [18] server to + be used by the PPP peer. It MAY be included in both Access-Accept + and Accounting-Request packets. + + A summary of the MS-Primary-MBNS-Server Attribute format is given + below. The fields are transmitted 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 | 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 + + Description + + The MS-Secondary-NBNS-Server Attribute is used to indicate the + address of the secondary DNS server to be used by the PPP peer. + It MAY be included in both Access-Accept and Accounting-Request + packets. + + A summary of the MS-Secondary-NBNS-Server Attribute format is given + below. The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 36] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + + The following table provides a guide to which of the above attributes + may be found in which kinds of packets, and in what quantity. + + 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 + + + +Zorn Informational [Page 37] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +The following table defines the meaning of the above table entries. + +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 + + MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User + passwords should be chosen with care, and be of sufficient length to + deter easy guessing. + + Although the scheme used to protect 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, RADIUS proxies will + decrypt and re-encrypt the field for forwarding. Therefore, these + attributes SHOULD NOT be used on networks where untrusted RADIUS + proxies reside. + +5. Acknowledgements + + Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash- + winp@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) for useful suggestions and + editorial feedback. + + + + + + + + + +Zorn Informational [Page 38] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +6. Editor's Address + + Questions about this memo can be directed to: + + 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. + + + +Zorn Informational [Page 39] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 40] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 41] + |