summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2548.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2548.txt')
-rw-r--r--doc/rfc/rfc2548.txt2299
1 files changed, 2299 insertions, 0 deletions
diff --git a/doc/rfc/rfc2548.txt b/doc/rfc/rfc2548.txt
new file mode 100644
index 0000000..35c83c3
--- /dev/null
+++ b/doc/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]
+