7 Network Working Group G. Zorn
8 Request for Comments: 2548 Microsoft Corporation
9 Category: Informational March 1999
12 Microsoft Vendor-specific RADIUS Attributes
16 This memo provides information for the Internet community. It does
17 not specify an Internet standard of any kind. Distribution of this
22 Copyright (C) The Internet Society (1999). All Rights Reserved.
26 This document describes the set of Microsoft vendor-specific RADIUS
27 attributes. These attributes are designed to support Microsoft
28 proprietary dial-up protocols and/or provide support for features
29 which is not provided by the standard RADIUS attribute set [3]. It
30 is expected that this memo will be updated whenever Microsoft defines
31 a new vendor-specific attribute, since its primary purpose is to
32 provide an open, easily accessible reference for third-parties
33 wishing to interoperate with Microsoft products.
35 1. Specification of Requirements
37 In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
38 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
43 The following sections describe sub-attributes which may be
44 transmitted in one or more RADIUS attributes of type Vendor-Specific
45 [3]. More than one sub-attribute MAY be transmitted in a single
46 Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD
47 be packed as a sequence of Vendor-Type/Vendor-Length/Value triples
48 following the inital Type, Length and Vendor-ID fields. The Length
49 field of the Vendor-Specific Attribute MUST be set equal to the sum
50 of the Vendor-Length fields of the sub-attributes contained in the
51 Vendor-Specific Attribute, plus six. The Vendor-ID field of the
52 Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft).
58 Zorn Informational [Page 1]
60 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
63 2.1. Attributes for Support of MS-CHAP Version 1
67 Microsoft created Microsoft Challenge-Handshake Authentication
68 Protocol (MS-CHAP) [4] to authenticate remote Windows workstations,
69 providing the functionality to which LAN-based users are accustomed.
70 Where possible, MS-CHAP is consistent with standard CHAP [5], and the
71 differences are easily modularized. Briefly, the differences between
72 MS-CHAP and standard CHAP are:
74 * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
75 option 3, Authentication Protocol.
77 * The MS-CHAP Response packet is in a format designed for
78 compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0,
79 Microsoft Windows95, and Microsoft LAN Manager 2.x networking
80 products. The MS-CHAP format does not require the authenticator
81 to store a clear-text or reversibly encrypted password.
83 * MS-CHAP provides an authenticator-controlled authentication
86 * MS-CHAP provides an authenticator-controlled password changing
89 * MS-CHAP defines an extended set of reason-for-failure codes,
90 returned in the Failure packet Message field.
92 The attributes defined in this section reflect these differences.
94 2.1.2. MS-CHAP-Challenge
98 This Attribute contains the challenge sent by a NAS to a Microsoft
99 Challenge-Handshake Authentication Protocol (MS-CHAP) user. It
100 MAY be used in both Access-Request and Access-Challenge packets.
102 A summary of the MS-CHAP-Challenge Attribute format is shown below.
103 The fields are transmitted from left to right.
114 Zorn Informational [Page 2]
116 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
120 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
121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
122 | Vendor-Type | Vendor-Length | String...
123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
126 11 for MS-CHAP-Challenge.
132 The String field contains the MS-CHAP challenge.
134 2.1.3. MS-CHAP-Response
138 This Attribute contains the response value provided by a PPP
139 Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)
140 user in response to the challenge. It is only used in Access-
143 A summary of the MS-CHAP-Response Attribute format is shown below.
144 The fields are transmitted from left to right.
170 Zorn Informational [Page 3]
172 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
176 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
177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
178 | Vendor-Type | Vendor-Length | Ident | Flags |
179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
206 1 for MS-CHAP-Response.
212 Identical to the PPP CHAP Identifier.
215 The Flags field is one octet in length. If the Flags field is one
216 (0x01), the NT-Response field is to be used in preference to the
217 LM-Response field for authentication. The LM-Response field MAY
218 still be used (if non-empty), but the NT-Response SHOULD be tried
219 first. If it is zero, the NT-Response field MUST be ignored and
220 the LM-Response field used.
226 Zorn Informational [Page 4]
228 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
232 The LM-Response field is 24 octets in length and holds an encoded
233 function of the password and the received challenge. If this
234 field is empty, it SHOULD be zero-filled.
238 The NT-Response field is 24 octets in length and holds an encoded
239 function of the password and the received challenge. If this
240 field is empty, it SHOULD be zero-filled.
242 2.1.4. MS-CHAP-Domain
246 The MS-CHAP-Domain Attribute indicates the Windows NT domain in
247 which the user was authenticated. It MAY be included in both
248 Access-Accept and Accounting-Request packets.
250 A summary of the MS-CHAP-Domain Attribute format is given below. The
251 fields are transmitted left to right.
254 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
255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
256 | Vendor-Type | Vendor-Length | Ident | String...
257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260 10 for MS-CHAP-Domain.
266 The Ident field is one octet and aids in matching requests and
270 This field contains the name in ASCII of the Windows NT domain in
271 which the user was authenticated.
282 Zorn Informational [Page 5]
284 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
291 The MS-CHAP-Error Attribute contains error data related to the
292 preceding MS-CHAP exchange. This Attribute may be used in both
293 MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges. It is only used
294 in Access-Reject packets.
296 A summary of the MS-CHAP-Error Attribute format is given below. The
297 fields are transmitted left to right.
300 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
301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
302 | Vendor-Type | Vendor-Length | Ident | String...
303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
312 The Ident field is one octet and aids in matching requests and
316 This field contains specially formatted ASCII text, which is
317 interpreted by the authenticating peer.
323 This Attribute allows the user to change their password if it has
324 expired. This Attribute is only used in Access-Request packets, and
325 should only be included if an MS-CHAP-Error attribute was included in
326 the immediately preceding Access-Reject packet, the String field of
327 the MS-CHAP-Error attribute indicated that the user password had
328 expired, and the MS-CHAP version is less than 2.
330 A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The
331 fields are transmitted from left to right.
338 Zorn Informational [Page 6]
340 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
344 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
345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
346 | Vendor-Type | Vendor-Length | Code | Ident |
347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
350 LM-Old-Password (cont)
351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
352 LM-Old-Password (cont)
353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
354 LM-Old-Password (cont) |
355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
358 LM-New-Password (cont)
359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
360 LM-New-Password (cont)
361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
362 LM-New-Password (cont) |
363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
366 NT-Old-Password (cont)
367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
368 NT-Old-Password (cont)
369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
370 NT-Old-Password (cont) |
371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374 NT-New-Password (cont)
375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376 NT-New-Password (cont)
377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378 NT-New-Password (cont) |
379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
380 | New-LM-Password-Length | Flags |
381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
390 The Code field is one octet in length. Its value is always 5.
394 Zorn Informational [Page 7]
396 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
400 The Ident field is one octet and aids in matching requests and
404 The LM-Old-Password field is 16 octets in length. It contains the
405 encrypted Lan Manager hash of the old password.
408 The LM-New-Password field is 16 octets in length. It contains the
409 encrypted Lan Manager hash of the new password.
412 The NT-Old-Password field is 16 octets in length. It contains the
413 encrypted Lan Manager hash of the old password.
416 The NT-New-Password field is 16 octets in length. It contains the
417 encrypted Lan Manager hash of the new password.
419 New-LM-Password-Length
420 The New-LM-Password-Length field is two octets in length and
421 contains the length in octets of the new LAN Manager-compatible
425 The Flags field is two octets in length. If the least significant
426 bit of the Flags field is one, this indicates that the NT-New-
427 Password and NT-Old-Password fields are valid and SHOULD be used.
428 Otherwise, the LM-New-Password and LM-Old-Password fields MUST be
435 This Attribute allows the user to change their password if it has
436 expired. This Attribute is only used in Access-Request packets,
437 and should only be included if an MS-CHAP-Error attribute was
438 included in the immediately preceding Access-Reject packet, the
439 String field of the MS-CHAP-Error attribute indicated that the
440 user password had expired, and the MS-CHAP version is equal to 2.
442 A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The
443 fields are transmitted from left to right.
450 Zorn Informational [Page 8]
452 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
456 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
457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
458 | Vendor-Type | Vendor-Length | Code | Ident |
459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
506 Zorn Informational [Page 9]
508 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
521 The Ident field is one octet and aids in matching requests and
522 replies. The value of this field MUST be identical to that in the
523 Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-
524 Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access-
528 The Old-NT-Hash field is 16 octets in length. It contains the old
529 Windows NT password hash encrypted with the new Windows NT
533 The Old-LM-Hash field is 16 octets in length. It contains the old
534 Lan Manager password hash encrypted with the new Windows NT
538 The LM-Response field is 24 octets in length and holds an encoded
539 function of the password and the received challenge. If this
540 field is empty, it SHOULD be zero-filled.
543 The NT-Response field is 24 octets in length and holds an encoded
544 function of the password and the received challenge. If this
545 field is empty, it SHOULD be zero-filled.
548 The Flags field is two octets in length. If the least significant
549 bit (bit 0) of this field is one, the NT-Response field is to be
550 used in preference to the LM-Response field for authentication.
551 The LM-Response field MAY still be used (if present), but the NT-
552 Response SHOULD be tried first. If least significant bit of the
553 field is zero, the NT-Response field MUST be ignored and the LM-
554 Response field used instead. If bit 1 of the Flags field is one,
555 the Old-LM-Hash field is valid and SHOULD be used. If this bit is
556 set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST
557 be included in the packet.
562 Zorn Informational [Page 10]
564 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
567 2.1.8. MS-CHAP-LM-Enc-PW
571 This Attribute contains the new Windows NT password encrypted with
572 the old LAN Manager password hash. The encrypted Windows NT
573 password is 516 octets in length; since this is longer than the
574 maximum lengtth of a RADIUS attribute, the password must be split
575 into several attibutes for transmission. A 2 octet sequence
576 number is included in the attribute to help preserve ordering of
577 the password fragments.
579 This Attribute is only used in Access-Request packets, in
580 conjunction with the MS-CHAP-CPW-2 attribute. It should only be
581 included if an MS-CHAP-Error attribute was included in the
582 immediately preceding Access-Reject packet, the String field of
583 the MS-CHAP-Error attribute indicated that the user password had
584 expired, and the MS-CHAP version is 2 or greater.
586 A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below.
587 The fields are transmitted from left to right.
590 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
591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
592 | Vendor-Type | Vendor-Length | Code | Ident |
593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
594 | Sequence-Number | String ...
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
598 5 for MS-CHAP-LM-Enc-PW
603 Code 6. Code is the same as for the MS-CHAP-PW-2 attribute.
606 The Ident field is one octet and aids in matching requests and
607 replies. The value of this field MUST be identical in all
608 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
609 CHAP-PW-2 attributes which are present in the same Access-Request
618 Zorn Informational [Page 11]
620 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
624 The Sequence-Number field is two octets in length and indicates
625 which "chunk" of the encrypted password is contained in the
626 following String field.
628 String The String field contains a portion of the encrypted password.
630 2.2. MS-CHAP-NT-Enc-PW
634 This Attribute contains the new Windows NT password encrypted with
635 the old Windows NT password hash. The encrypted Windows NT
636 password is 516 octets in length; since this is longer than the
637 maximum lengtth of a RADIUS attribute, the password must be split
638 into several attibutes for transmission. A 2 octet sequence
639 number is included in the attribute to help preserve ordering of
640 the password fragments.
642 This Attribute is only used in Access-Request packets, in conjunc-
643 tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It
644 should only be included if an MS-CHAP-Error attribute was included
645 in the immediately preceding Access-Reject packet, the String
646 field of the MS-CHAP-Error attribute indicated that the user
647 password had expired, and the MS-CHAP version is 2 or greater.
649 A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below.
650 The fields are transmitted from left to right.
653 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
654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
655 | Vendor-Type | Vendor-Length | Code | Ident |
656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
657 | Sequence-Number | String ...
658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
661 6 for MS-CHAP-NT-Enc-PW
667 6. Code is the same as for the MS-CHAP-PW-2 attribute.
674 Zorn Informational [Page 12]
676 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
680 The Ident field is one octet and aids in matching requests and
681 replies. The value of this field MUST be identical in all
682 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
683 CHAP-PW-2 attributes which are present in the same Access-Request
687 The Sequence-Number field is two octets in length and indicates
688 which "chunk" of the encrypted password is contained in the
689 following String field.
692 The String field contains a portion of the encrypted password.
694 2.3. Attributes for Support of MS-CHAP Version 2
698 This section describes RADIUS attributes supporting version two of
699 Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is
700 similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1)
701 [4]. Certain protocol fields have been deleted or reused but with
702 different semantics. Where possible, MS-CHAP-V2 is consistent with
703 both MS-CHAP-V1 and standard CHAP [1]. Briefly, the differences
704 between MS-CHAP-V2 and MS-CHAP-V1 are:
706 * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
707 option 3, Authentication Protocol.
709 * MS-CHAP-V2 provides mutual authentication between peers by
710 piggybacking a peer challenge on the Response packet and an
711 authenticator response on the Success packet.
713 * The calculation of the "Windows NT compatible challenge
714 response" sub-field in the Response packet has been changed to
715 include the peer challenge and the user name.
717 * In MS-CHAP-V1, the "LAN Manager compatible challenge response"
718 sub-field was always sent in the Response packet. This field
719 has been replaced in MS-CHAP-V2 by the Peer-Challenge field.
721 * The format of the Message field in the Failure packet has been
724 * The Change Password (version 1) and Change Password (version 2)
725 packets are no longer supported. They have been replaced with a
726 single Change-Password packet.
730 Zorn Informational [Page 13]
732 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
735 The attributes defined in this section reflect these differences.
737 2.3.2. MS-CHAP2-Response
741 This Attribute contains the response value provided by an MS-
742 CHAP-V2 peer in response to the challenge. It is only used in
743 Access-Request packets.
745 A summary of the MS-CHAP2-Response Attribute format is shown below.
746 The fields are transmitted from left to right.
749 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
750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
751 | Vendor-Type | Vendor-Length | Ident | Flags |
752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
755 Peer-Challenge (cont)
756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
757 Peer-Challenge (cont)
758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
759 Peer-Challenge (cont) |
760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
779 25 for MS-CHAP2-Response.
786 Zorn Informational [Page 14]
788 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
792 Identical to the PPP MS-CHAP v2 Identifier.
795 The Flags field is one octet in length. It is reserved for future
796 use and MUST be zero.
799 The Peer-Challenge field is a 16-octet random number.
802 This field is reserved for future use and MUST be zero.
805 The Response field is 24 octets in length and holds an encoded
806 function of the password, the Peer-Challenge field and the
809 2.3.3. MS-CHAP2-Success
813 This Attribute contains a 42-octet authenticator response string.
814 This string MUST be included in the Message field of the MS-CHAP-
815 V2 Success packet sent from the NAS to the peer. This Attribute
816 is only used in Access-Accept packets.
818 A summary of the MS-CHAP2-Success Attribute format is shown below.
819 The fields are transmitted from left to right.
822 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
823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
824 | Vendor-Type | Vendor-Length | Ident | String...
825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
828 26 for MS-CHAP2-Success.
834 Identical to the PPP MS-CHAP v2 Identifier.
837 The 42-octet authenticator string (see above).
842 Zorn Informational [Page 15]
844 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
851 This Attribute allows the user to change their password if it has
852 expired. This Attribute is only used in conjunction with the MS-
853 CHAP-NT-Enc-PW attribute in Access-Request packets, and should
854 only be included if an MS-CHAP-Error attribute was included in the
855 immediately preceding Access-Reject packet, the String field of
856 the MS-CHAP-Error attribute indicated that the user password had
857 expired, and the MS-CHAP version is equal to 3.
859 A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The
860 fields are transmitted from left to right.
898 Zorn Informational [Page 16]
900 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
904 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
905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
906 | Vendor-Type | Vendor-Length | Code | Ident |
907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
910 Encrypted-Hash (cont)
911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
912 Encrypted-Hash (cont)
913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
914 Encrypted-Hash (cont) |
915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918 Peer-Challenge (cont)
919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
920 Peer-Challenge (cont)
921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
922 Peer-Challenge (cont)
923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
924 Peer-Challenge (cont)
925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
926 Peer-Challenge (cont) |
927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
954 Zorn Informational [Page 17]
956 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
960 The Ident field is one octet and aids in matching requests and
961 replies. The value of this field MUST be identical to that in the
962 Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in
963 the Access-Request packet.
966 The Encrypted-Hash field is 16 octets in length. It contains the
967 old Windows NT password hash encrypted with the new Windows NT
971 The NT-Response field is 24 octets in length and holds an encoded
972 function of the new password, the Peer-Challenge field and the
976 The Flags field is two octets in length. This field is reserved
977 for future use and MUST be zero.
979 2.4. Attributes for MPPE Support
981 This section describes a set of Attributes designed to support the
982 use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up
983 networks. MPPE is a means of representing Point to Point Protocol
984 (PPP) [7] packets in a encrypted form. MPPE uses the RSA RC4 [8]
985 algorithm for encryption. The length of the session key to be used
986 for initializing encryption tables can be negotiated; MPPE currently
987 supports 40 bit and 128 bit session keys. MPPE is negotiated within
988 option 18 in the PPP Compression Control Protocol (CCP)[9], [10].
990 2.4.1. MS-CHAP-MPPE-Keys
994 The MS-CHAP-MPPE-Keys Attribute contains two session keys for use
995 by the Microsoft Point-to-Point Encryption Protocol (MPPE). This
996 Attribute is only included in Access-Accept packets.
998 A summary of the MS-CHAP-MPPE-Keys Attribute format is given below.
999 The fields are transmitted left to right.
1010 Zorn Informational [Page 18]
1012 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1016 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
1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1018 | Vendor-Type | Vendor-Length | Keys
1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1038 12 for MS-CHAP-MPPE-Keys.
1044 The Keys field consists of two logical sub-fields: the LM-Key and
1045 the NT-Key. The LM-Key is eight octets in length and contains the
1046 first eight bytes of the output of the function LmPasswordHash(P,
1047 This hash is constructed as follows: let the plain-text password
1048 be represented by P.
1050 The NT-Key sub-field is sixteen octets in length and contains the
1051 first sixteen octets of the hashed Windows NT password. The
1052 format of the plaintext Keys field is illustrated in the following
1066 Zorn Informational [Page 19]
1068 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1072 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
1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1091 The Keys field MUST be encrypted by the RADIUS server using the
1092 same method defined for the User-Password Attribute [3]. Padding
1093 is required because the method referenced above requires the field
1094 to be encrypted to be a multiple of sixteen octets in length.
1097 This attribute should only be returned in response to an
1098 Access-Request packet containing MS-CHAP attributes.
1100 2.4.2. MS-MPPE-Send-Key
1104 The MS-MPPE-Send-Key Attribute contains a session key for use by
1105 the Microsoft Point-to-Point Encryption Protocol (MPPE). As the
1106 name implies, this key is intended for encrypting packets sent
1107 from the NAS to the remote host. This Attribute is only included
1108 in Access-Accept packets.
1110 A summary of the MS-MPPE-Send-Key Attribute format is given below.
1111 The fields are transmitted left to right.
1122 Zorn Informational [Page 20]
1124 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1128 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
1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1130 | Vendor-Type | Vendor-Length | Salt
1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1136 16 for MS-MPPE-Send-Key.
1142 The Salt field is two octets in length and is used to ensure the
1143 uniqueness of the keys used to encrypt each of the encrypted
1144 attributes occurring in a given Access-Accept packet. The most
1145 significant bit (leftmost) of the Salt field MUST be set (1). The
1146 contents of each Salt field in a given Access-Accept packet MUST
1150 The plaintext String field consists of three logical sub-fields:
1151 the Key-Length and Key sub-fields (both of which are required),
1152 and the optional Padding sub-field. The Key-Length sub-field is
1153 one octet in length and contains the length of the unencrypted Key
1154 sub-field. The Key sub-field contains the actual encryption key.
1155 If the combined length (in octets) of the unencrypted Key-Length
1156 and Key sub-fields is not an even multiple of 16, then the Padding
1157 sub-field MUST be present. If it is present, the length of the
1158 Padding sub-field is variable, between 1 and 15 octets. The
1159 String field MUST be encrypted as follows, prior to transmission:
1161 Construct a plaintext version of the String field by concate-
1162 nating the Key-Length and Key sub-fields. If necessary, pad
1163 the resulting string until its length (in octets) is an even
1164 multiple of 16. It is recommended that zero octets (0x00) be
1165 used for padding. Call this plaintext P.
1167 Call the shared secret S, the pseudo-random 128-bit Request
1168 Authenticator (from the corresponding Access-Request packet) R,
1169 and the contents of the Salt field A. Break P into 16 octet
1170 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
1171 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
1172 Intermediate values b(1), b(2)...c(i) are required. Encryption
1173 is performed in the following manner ('+' indicates
1178 Zorn Informational [Page 21]
1180 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1183 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
1184 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
1188 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
1190 The resulting encrypted String field will contain
1193 On receipt, the process is reversed to yield the plaintext String.
1195 Implementation Notes
1196 It is possible that the length of the key returned may be larger
1197 than needed for the encryption scheme in use. In this case, the
1198 RADIUS client is responsible for performing any necessary
1201 This attribute MAY be used to pass a key from an external (e.g.,
1202 EAP [15]) server to the RADIUS server. In this case, it may be
1203 impossible for the external server to correctly encrypt the key,
1204 since the RADIUS shared secret might be unavailable. The external
1205 server SHOULD, however, return the attribute as defined above; the
1206 Salt field SHOULD be zero-filled and padding of the String field
1207 SHOULD be done. When the RADIUS server receives the attribute
1208 from the external server, it MUST correctly set the Salt field and
1209 encrypt the String field before transmitting it to the RADIUS
1210 client. If the channel used to communicate the MS-MPPE-Send-Key
1211 attribute is not secure from eavesdropping, the attribute MUST be
1212 cryptographically protected.
1214 2.4.3. MS-MPPE-Recv-Key
1218 The MS-MPPE-Recv-Key Attribute contains a session key for use by
1219 the Microsoft Point-to-Point Encryption Protocol (MPPE). As the
1220 name implies, this key is intended for encrypting packets received
1221 by the NAS from the remote host. This Attribute is only included
1222 in Access-Accept packets.
1224 A summary of the MS-MPPE-Recv-Key Attribute format is given below.
1225 The fields are transmitted left to right.
1234 Zorn Informational [Page 22]
1236 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1240 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
1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1242 | Vendor-Type | Vendor-Length | Salt
1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1248 17 for MS-MPPE-Recv-Key.
1254 The Salt field is two octets in length and is used to ensure the
1255 uniqueness of the keys used to encrypt each of the encrypted
1256 attributes occurring in a given Access-Accept packet. The most
1257 significant bit (leftmost) of the Salt field MUST be set (1). The
1258 contents of each Salt field in a given Access-Accept packet MUST
1262 The plaintext String field consists of three logical sub-fields:
1263 the Key-Length and Key sub-fields (both of which are required),
1264 and the optional Padding sub-field. The Key-Length sub-field is
1265 one octet in length and contains the length of the unencrypted Key
1266 sub-field. The Key sub-field contains the actual encryption key.
1267 If the combined length (in octets) of the unencrypted Key-Length
1268 and Key sub-fields is not an even multiple of 16, then the Padding
1269 sub-field MUST be present. If it is present, the length of the
1270 Padding sub-field is variable, between 1 and 15 octets. The
1271 String field MUST be encrypted as follows, prior to transmission:
1273 Construct a plaintext version of the String field by
1274 concatenating the Key-Length and Key sub-fields. If necessary,
1275 pad the resulting string until its length (in octets) is an
1276 even multiple of 16. It is recommended that zero octets (0x00)
1277 be used for padding. Call this plaintext P.
1279 Call the shared secret S, the pseudo-random 128-bit Request
1280 Authenticator (from the corresponding Access-Request packet) R,
1281 and the contents of the Salt field A. Break P into 16 octet
1282 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
1283 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
1284 Intermediate values b(1), b(2)...c(i) are required. Encryption
1285 is performed in the following manner ('+' indicates
1290 Zorn Informational [Page 23]
1292 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1295 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
1296 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
1300 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
1302 The resulting encrypted String field will contain
1305 On receipt, the process is reversed to yield the plaintext String.
1307 Implementation Notes
1308 It is possible that the length of the key returned may be larger
1309 than needed for the encryption scheme in use. In this case, the
1310 RADIUS client is responsible for performing any necessary
1313 This attribute MAY be used to pass a key from an external (e.g.,
1314 EAP [15]) server to the RADIUS server. In this case, it may be
1315 impossible for the external server to correctly encrypt the key,
1316 since the RADIUS shared secret might be unavailable. The external
1317 server SHOULD, however, return the attribute as defined above; the
1318 Salt field SHOULD be zero-filled and padding of the String field
1319 SHOULD be done. When the RADIUS server receives the attribute
1320 from the external server, it MUST correctly set the Salt field and
1321 encrypt the String field before transmitting it to the RADIUS
1322 client. If the channel used to communicate the MS-MPPE-Recv-Key
1323 attribute is not secure from eavesdropping, the attribute MUST be
1324 cryptographically protected.
1326 2.4.4. MS-MPPE-Encryption-Policy
1330 The MS-MPPE-Encryption-Policy Attribute may be used to signify
1331 whether the use of encryption is allowed or required. If the
1332 Policy field is equal to 1 (Encryption-Allowed), any or none of
1333 the encryption types specified in the MS-MPPE-Encryption-Types
1334 Attribute MAY be used. If the Policy field is equal to 2
1335 (Encryption-Required), any of the encryption types specified in
1336 the MS-MPPE-Encryption-Types Attribute MAY be used, but at least
1339 A summary of the MS-MPPE-Encryption-Policy Attribute format is given
1340 below. The fields are transmitted left to right.
1346 Zorn Informational [Page 24]
1348 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1352 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
1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1354 | Vendor-Type | Vendor-Length | Policy
1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1360 7 for MS-MPPE-Encryption-Policy.
1366 The Policy field is 4 octets in length. Defined values are:
1368 1 Encryption-Allowed 2 Encryption-Required
1370 2.4.5. MS-MPPE-Encryption-Types
1374 The MS-MPPE-Encryption-Types Attribute is used to signify the
1375 types of encryption available for use with MPPE. It is a four
1376 octet integer that is interpreted as a string of bits.
1378 A summary of the MS-MPPE-Encryption-Policy Attribute format is given
1379 below. The fields are transmitted left to right.
1382 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
1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1384 | Vendor-Type | Vendor-Length | Types
1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1390 8 for MS-MPPE-Encryption-Types.
1396 The Types field is 4 octets in length. The following diagram
1397 illustrates the Types field.
1402 Zorn Informational [Page 25]
1404 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1408 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
1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1413 If the L bit is set, RC4[5] encryption using a 40-bit key is
1414 allowed. If the S bit is set, RC4 encryption using a 128-bit key
1415 is allowed. If both the L and S bits are set, then either 40- or
1416 128-bit keys may be used with the RC4 algorithm.
1418 2.5. Attributes for BAP Support
1420 This section describes a set of vendor-specific RADIUS attributes
1421 designed to support the dynamic control of bandwidth allocation in
1422 multilink PPP [11]. Attributes are defined that specify whether use
1423 of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or
1424 required on incoming calls, the level of line capacity (expressed as
1425 a percentage) below which utilization must fall before a link is
1426 eligible to be dropped, and the length of time (in seconds) that a
1427 link must be under-utilized before it is dropped.
1433 This Attribute describes whether the use of BAP is allowed,
1434 disallowed or required on new multilink calls. It MAY be used in
1435 Access-Accept packets.
1437 A summary of the MS-BAP-Usage Attribute format is shown below. The
1438 fields are transmitted from left to right.
1441 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
1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1443 | Vendor-Type | Vendor-Length | Value
1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1449 13 for MS-BAP-Usage.
1458 Zorn Informational [Page 26]
1460 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1464 The Value field is four octets.
1466 0 BAP usage not allowed
1468 2 BAP usage required
1470 2.5.2. MS-Link-Utilization-Threshold
1474 This Attribute represents the percentage of available bandwidth
1475 utilization below which the link must fall before the link is
1476 eligible for termination. Permissible values for the MS-Link-
1477 Utilization-Threshold Attribute are in the range 1-100, inclusive.
1478 It is only used in Access-Accept packets.
1480 A summary of the MS-Link-Utilization-Threshold Attribute format is
1481 shown below. The fields are transmitted from left to right.
1484 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
1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1486 | Vendor-Type | Vendor-Length | Value
1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1492 14 for MS-Link-Utilization-Threshold
1496 Value The Value field is four octets in length and represents the
1497 percentage of available bandwidth utilization below which the link
1498 must fall before the link is eligible for termination.
1499 Permissible values are in the range 1-100, inclusive.
1501 2.5.3. MS-Link-Drop-Time-Limit
1505 The MS-Link-Drop-Time-Limit Attribute indicates the length of time
1506 (in seconds) that a link must be underutilized before it is
1507 dropped. It MAY only be included in Access-Accept packets.
1509 A summary of the MS-Link-Drop-Time-Limit Attribute format is given
1510 below. The fields are transmitted left to right.
1514 Zorn Informational [Page 27]
1516 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1520 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
1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1522 | Vendor-Type | Vendor-Length | Value
1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1528 15 for MS-Link-Drop-Time-Limit
1534 The Value field represents the number of seconds that a link must
1535 be underutilized (i.e., display bandwidth utilization below the
1536 threshold specified in the MS-Link-Utilization-Threshold
1537 Attribute) before the link is dropped.
1539 2.6. Attributes for ARAP Support
1541 This section describes a set of Attributes designed to support the
1542 Apple Remote Access Protocol (ARAP).
1544 2.6.1. MS-Old-ARAP-Password
1548 The MS-Old-ARAP-Password Attribute is used to transmit the old
1549 ARAP password during an ARAP password change operation. It MAY be
1550 included in Access-Request packets.
1552 A summary of the MS-Old-ARAP-Password Attribute Attribute format is
1553 given below. The fields are transmitted left to right.
1556 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
1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1558 | Vendor-Type | Vendor-Length | String...
1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1562 19 for MS-Old-ARAP-Password Attribute
1570 Zorn Informational [Page 28]
1572 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1576 The String field is one or more octets. It contains the old ARAP
1577 password DES-encrypted using itself as the key.
1579 2.6.2. MS-New-ARAP-Password
1583 The MS-New-ARAP-Password Attribute is used to transmit the new
1584 ARAP password during an ARAP password change operation. It MAY be
1585 included in Access-Request packets.
1587 A summary of the MS-New-ARAP-Password Attribute Attribute format is
1588 given below. The fields are transmitted left to right.
1591 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
1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1593 | Vendor-Type | Vendor-Length | String...
1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1597 20 for MS-New-ARAP-Password Attribute
1603 The String field is one or more octets. It contains the new ARAP
1604 password DES-encrypted using the old ARAP password as the key.
1606 2.6.3. MS-ARAP-Password-Change-Reason
1610 The MS-ARAP-Password-Change-Reason Attribute is used to indicate
1611 reason for a server-initiated password change. It MAY be included
1612 in Access-Challenge packets.
1614 A summary of the MS-ARAP-Password-Change-Reason Attribute format is
1615 given below. The fields are transmitted left to right.
1626 Zorn Informational [Page 29]
1628 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1632 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
1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1634 | Vendor-Type | Vendor-Length | Why
1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1640 21 for MS-ARAP-Password-Change-Reason
1646 The Why field is 4 octets in length. The following values are
1648 Just-Change-Password 1
1650 Admin-Requires-Password-Change 3
1651 Password-Too-Short 4
1653 2.6.4. MS-ARAP-Challenge
1657 This attribute is only present in an Access-Request packet
1658 containing a Framed-Protocol Attribute with the value 3 (ARAP).
1660 A summary of the MS-ARAP-Challenge Attribute format is given below.
1661 The fields are transmitted left to right.
1664 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
1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1666 | Vendor-Type | Vendor-Length | Challenge
1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1674 33 for MS-ARAP-Challenge
1682 Zorn Informational [Page 30]
1684 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1688 The Challenge Field is 8 octets in length. It contains the
1689 challenge (as two 4-octet quantities) sent by the NAS to the peer.
1691 2.7. Miscellaneous Attributes
1693 This section describes attributes which do not fall into any
1694 particular category, but are used in the identification and operation
1695 of Microsoft remote access products.
1697 2.7.1. MS-RAS-Vendor
1701 The MS-RAS-Vendor Attribute is used to indicate the manufacturer
1702 of the RADIUS client machine. It MAY be included in both Access-
1703 Request and Accounting-Request packets.
1705 A summary of the MS-RAS-Vendor Attribute format is given below. The
1706 fields are transmitted left to right.
1709 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
1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1711 | Vendor-Type | Vendor-Length | Vendor-ID
1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1723 The Vendor-ID field is 4 octets in length. The high-order octet
1724 is 0 and the low-order 3 octets are the SMI Network Management
1725 Private Enterprise Code of the Vendor in network byte order, as
1726 defined in the Assigned Numbers RFC [13].
1728 2.7.2. MS-RAS-Version
1732 The MS-RAS-Version Attribute is used to indicate the version of
1733 the RADIUS client software. This attribute SHOULD be included in
1734 packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be
1738 Zorn Informational [Page 31]
1740 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1743 sent in packets which do not contain an MS-RAS-Vendor Attribute.
1744 It MAY be included in both Access-Request and Accounting-Request
1747 A summary of the MS-RAS-Version Attribute format is given below. The
1748 fields are transmitted left to right.
1751 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
1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1753 | Vendor-Type | Vendor-Length | String...
1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1757 18 for MS-RAS-Version
1763 The String field is one or more octets. The actual format of the
1764 information is vendor specific, and a robust implementation SHOULD
1765 support the field as undistinguished octets.
1771 The MS-Filter Attribute is used to transmit traffic filters. It
1772 MAY be included in both Access-Accept and Accounting-Request
1775 If multiple MS-Filter Attributes are contained within a packet,
1776 they MUST be in order and they MUST be consecutive attributes in
1779 A summary of the MS-Filter Attribute format is given below. The
1780 fields are transmitted left to right.
1783 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
1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1785 | Vendor-Type | Vendor-Length | Filter...
1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1789 22 for MS-Filter Attribute
1794 Zorn Informational [Page 32]
1796 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1803 The Filter field is one or more octets. It contains a sequence of
1804 undifferentiated octets.
1806 If multiple MS-Filter Attributes occur in a single Access-Accept
1807 packet, the Filter field from each MUST be concatenated in the
1808 order received to form the actual filter.
1810 2.7.4. MS-Acct-Auth-Type
1814 The MS-Acct-Auth-Type Attribute is used to represent the method
1815 used to authenticate the dial-up user. It MAY be included in
1816 Accounting-Request packets.
1818 A summary of the MS-Acct-Auth-Type Attribute format is given below.
1819 The fields are transmitted left to right.
1822 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
1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1824 | Vendor-Type | Vendor-Length | Auth-Type
1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1830 23 for MS-Acct-Auth-Type
1836 The Auth-Type field is 4 octets in length. The following values
1837 are defined for this field:
1850 Zorn Informational [Page 33]
1852 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1855 2.7.5. MS-Acct-EAP-Type
1859 The MS-Acct-EAP-Type Attribute is used to represent the Extensible
1860 Authentication Protocol (EAP) [15] type used to authenticate the
1861 dial-up user. It MAY be included in Accounting-Request packets.
1863 A summary of the MS-Acct-EAP-Type Attribute format is given below.
1864 The fields are transmitted left to right.
1867 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
1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1869 | Vendor-Type | Vendor-Length | EAP-Type
1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1875 24 for MS-Acct-EAP-Type
1881 The EAP-Type field is 4 octets in length. The following values
1882 are currently defined for this field:
1886 Generic Token Card 6
1889 2.7.6. MS-Primary-DNS-Server
1893 The MS-Primary-DNS-Server Attribute is used to indicate the
1894 address of the primary Domain Name Server (DNS) [16, 17] server to
1895 be used by the PPP peer. It MAY be included in both Access-Accept
1896 and Accounting-Request packets.
1898 A summary of the MS-Primary-DNS-Server Attribute format is given
1899 below. The fields are transmitted left to right.
1906 Zorn Informational [Page 34]
1908 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1912 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
1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1914 | Vendor-Type | Vendor-Length | IP-Address
1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1920 28 for MS-Primary-DNS-Server
1926 The IP-Address field is 4 octets in length. It contains the IP
1927 address of the primary DNS server.
1929 2.7.7. MS-Secondary-DNS-Server
1933 The MS-Secondary-DNS-Server Attribute is used to indicate the
1934 address of the secondary DNS server to be used by the PPP peer.
1935 It MAY be included in both Access-Accept and Accounting-Request
1938 A summary of the MS-Secondary-DNS-Server Attribute format is given
1939 below. The fields are transmitted left to right.
1942 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
1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1944 | Vendor-Type | Vendor-Length | IP-Address
1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1950 29 for MS-Secondary-DNS-Server
1956 The IP-Address field is 4 octets in length. It contains the IP
1957 address of the secondary DNS server.
1962 Zorn Informational [Page 35]
1964 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1967 2.7.8. MS-Primary-NBNS-Server
1971 The MS-Primary-NBNS-Server Attribute is used to indicate the
1972 address of the primary NetBIOS Name Server (NBNS) [18] server to
1973 be used by the PPP peer. It MAY be included in both Access-Accept
1974 and Accounting-Request packets.
1976 A summary of the MS-Primary-MBNS-Server Attribute format is given
1977 below. The fields are transmitted left to right.
1980 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
1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1982 | Vendor-Type | Vendor-Length | IP-Address
1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1988 30 for MS-Primary-NBNS-Server
1994 The IP-Address field is 4 octets in length. It contains the IP
1995 address of the primary NBNS server.
1997 2.7.9. MS-Secondary-NBNS-Server
2001 The MS-Secondary-NBNS-Server Attribute is used to indicate the
2002 address of the secondary DNS server to be used by the PPP peer.
2003 It MAY be included in both Access-Accept and Accounting-Request
2006 A summary of the MS-Secondary-NBNS-Server Attribute format is given
2007 below. The fields are transmitted left to right.
2018 Zorn Informational [Page 36]
2020 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
2024 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
2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2026 | Vendor-Type | Vendor-Length | IP-Address
2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2032 31 for MS-Secondary-NBNS-Server
2038 The IP-Address field is 4 octets in length. It contains the IP
2039 address of the secondary NBNS server.
2041 3. Table of Attributes
2043 The following table provides a guide to which of the above attributes
2044 may be found in which kinds of packets, and in what quantity.
2046 Request Accept Reject Challenge Acct-Request # Attribute
2047 0-1 0 0 0 0 1 MS-CHAP-Response
2048 0 0 0-1 0 0 2 MS-CHAP-Error
2049 0-1 0 0 0 0 3 MS-CHAP-CPW-1
2050 0-1 0 0 0 0 4 MS-CHAP-CPW-2
2051 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW
2052 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW
2053 0 0-1 0 0 0 7 MS-MPPE-Encryption-
2055 0 0-1 0 0 0 8 MS-MPPE-Encryption-Type
2056 0-1 0 0 0 0-1 9 MS-RAS-Vendor
2057 0 0-1 0 0 0-1 10 MS-CHAP-Domain
2058 0-1 0 0 0-1 0 11 MS-CHAP-Challenge
2059 0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys
2060 0 0-1 0 0 0 13 MS-BAP-Usage
2061 0 0-1 0 0 0 14 MS-Link-Utilization-
2063 0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit
2064 0 0-1 0 0 0 16 MS-MPPE-Send-Key
2065 0 0-1 0 0 0 17 MS-MPPE-Recv-Key
2066 0-1 0 0 0 0-1 18 MS-RAS-Version
2067 0-1 0 0 0 0 19 MS-Old-ARAP-Password
2068 0-1 0 0 0 0 20 MS-New-ARAP-Password
2069 0 0 0 0-1 0 21 MS-ARAP-PW-Change-
2074 Zorn Informational [Page 37]
2076 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
2079 0 0+ 0 0 0+ 22 MS-Filter
2080 0 0 0 0 0-1 23 MS-Acct-Auth-Type
2081 0 0 0 0 0-1 24 MS-Acct-EAP-Type
2082 0-1 0 0 0 0 25 MS-CHAP2-Response
2083 0 0-1 0 0 0 26 MS-CHAP2-Success
2084 0-1 0 0 0 0 27 MS-CHAP2-CPW
2085 0 0-1 0 0 0-1 28 MS-Primary-DNS-Server
2086 0 0-1 0 0 0-1 29 MS-Secondary-DNS-Server
2087 0 0-1 0 0 0-1 30 MS-Primary-NBNS-Server
2088 0 0-1 0 0 0-1 31 MS-Secondary-NBNS-
2090 0-1 0 0 0 0 33 MS-ARAP-Challenge
2092 The following table defines the meaning of the above table entries.
2094 0 This attribute MUST NOT be present in packet.
2095 0+ Zero or more instances of this attribute MAY be present in packet.
2096 0-1 Zero or one instance of this attribute MAY be present in packet.
2098 4. Security Considerations
2100 MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User
2101 passwords should be chosen with care, and be of sufficient length to
2102 deter easy guessing.
2104 Although the scheme used to protect the Keys field of the MS-CHAP-
2105 MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is
2106 believed to be relatively secure on the wire, RADIUS proxies will
2107 decrypt and re-encrypt the field for forwarding. Therefore, these
2108 attributes SHOULD NOT be used on networks where untrusted RADIUS
2113 Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash-
2114 winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra
2115 Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com),
2116 Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton
2117 (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh
2118 Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com),
2119 and Don Rule (don-aldr@microsoft.com) for useful suggestions and
2130 Zorn Informational [Page 38]
2132 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
2137 Questions about this memo can be directed to:
2140 Microsoft Corporation
2142 Redmond, Washington 98052
2144 Phone: +1 425 703 1559
2145 Fax: +1 425 936 7329
2146 EMail: glennz@microsoft.com
2150 [1] Simpson, W., "PPP Challenge Handshake Authentication
2151 Protocol (CHAP)", RFC 1994, August 1996.
2153 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
2154 Levels", BCP 14, RFC 2119, March 1997.
2156 [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
2157 Access Dial In User Service", RFC 2138, April 1997.
2159 [4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
2162 [5] Simpson, W., "PPP Challenge Handshake Authentication Protocol
2163 (CHAP)", RFC 1994, August 1996.
2165 [6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption
2166 (MPPE) Protocol", Work in Progress.
2168 [7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
2171 [8] RC4 is a proprietary encryption algorithm available under
2172 license from RSA Data Security Inc. For licensing information,
2174 RSA Data Security, Inc.
2176 Redwood City, CA 94065-1031
2178 [9] Pall, G., "Microsoft Point-to-Point Compression (MPPC)
2179 Protocol", RFC 2118, March 1997.
2181 [10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
2186 Zorn Informational [Page 39]
2188 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
2191 [11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
2192 "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
2194 [12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
2195 Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
2196 (BACP)", RFC 2125, March 1997.
2198 [13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
2201 [14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in
2204 [15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
2205 Protocol (EAP)", RFC 2284, March 1998.
2207 [16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
2208 13, RFC 1034, USC/ISI, November 1987.
2210 [17] Mockapetris, P., "Domain Names - Implementation and
2211 Specification", STD 13, RFC 1035, November 1987.
2213 [18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS
2214 Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,
2242 Zorn Informational [Page 40]
2244 RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
2247 10. Full Copyright Statement
2249 Copyright (C) The Internet Society (1999). All Rights Reserved.
2251 This document and translations of it may be copied and furnished to
2252 others, and derivative works that comment on or otherwise explain it
2253 or assist in its implementation may be prepared, copied, published
2254 and distributed, in whole or in part, without restriction of any
2255 kind, provided that the above copyright notice and this paragraph are
2256 included on all such copies and derivative works. However, this
2257 document itself may not be modified in any way, such as by removing
2258 the copyright notice or references to the Internet Society or other
2259 Internet organizations, except as needed for the purpose of
2260 developing Internet standards in which case the procedures for
2261 copyrights defined in the Internet Standards process must be
2262 followed, or as required to translate it into languages other than
2265 The limited permissions granted above are perpetual and will not be
2266 revoked by the Internet Society or its successors or assigns.
2268 This document and the information contained herein is provided on an
2269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2298 Zorn Informational [Page 41]