idnits 2.17.1 draft-rfced-info-zorn-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 104 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...This document...' == Line 12 has weird spacing: '...as, and its...' == Line 17 has weird spacing: '...and may be ...' == Line 18 has weird spacing: '...ference mater...' == Line 21 has weird spacing: '...To learn the...' == (99 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9659 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Microsoft Corporation 4 Category: Informational November 1997 5 7 RADIUS Attributes for MS-CHAP Support 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working doc- 14 uments as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. The distribution of 28 this memo is unlimited. It is filed as and expires May 10, 1998. Please send comments to the 30 author (glennz@microsoft.com). 32 2. Abstract 34 This document describes a set of vendor-specific RADIUS attributes 35 designed to support the use of Microsoft's proprietary dialect of PPP 36 CHAP (MS-CHAP) in dial-up networks. MS-CHAP is derived from and (where 37 possible) consistent with PPP CHAP [1]; the differences between PPP CHAP 38 and MS-CHAP are significant enough to warrant the definition of new 39 RADIUS attributes, however. 41 3. Introduction 43 Microsoft created Microsoft Challenge-Handshake Authentication Protocol 44 (MS-CHAP) to authenticate remote Windows workstations, providing the 45 functionality to which LAN-based users are accustomed. Where possible, 46 MS-CHAP is consistent with standard CHAP, and the differences are easily 47 modularized. Briefly, differences between MS-CHAP and standard CHAP 48 are: 50 * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP 51 option 3, Authentication Protocol. 53 * The MS-CHAP Response packet is in a format designed for 54 compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0, 55 Microsoft Windows95, and Microsoft LAN Manager 2.x networking 56 products. The MS-CHAP format does not require the 57 authenticator to store a clear-text or reversibly encrypted 58 password. 60 * MS-CHAP provides an authenticator-controlled authentication 61 retry mechanism. 63 * MS-CHAP provides an authenticator-controlled password changing 64 mechanism. 66 * MS-CHAP defines an extended set of reason-for-failure codes, 67 returned in the Failure packet Message field. 69 The attributes defined in this document reflect these differences. 71 4. Specification of Requirements 73 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 74 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 75 described in [2]. 77 5. Attributes 79 The following sections describe sub-attributes which may be transmitted 80 in one or more RADIUS attributes of type Vendor-Specific [3]. More than 81 one sub-attribute MAY be transmitted in a single Vendor-Specific 82 Attribute; if this is done, the sub-attributes SHOULD be packed as a 83 sequence of Vendor-Type/Vendor-Length/Value triples following the inital 84 Type, Length and Vendor-ID fields. The Length field of the Vendor-Spe- 85 cific Attribute MUST be set equal to the sum of the Vendor-Length fields 86 of the sub-attributes contained in the Vendor-Specific Attribute, plus 87 six. The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be 88 set to decimal 311 (Microsoft). 90 5.1. MS-CHAP-Challenge 92 Description 94 This Attribute contains the challenge sent by a NAS to a Microsoft 95 Challenge-Handshake Authentication Protocol (MS-CHAP) user. It 96 MAY be used in both Access-Request and Access-Challenge packets. 98 A summary of the MS-CHAP-Challenge Attribute format is shown below. 99 The fields are transmitted from left to right. 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Vendor-Type | Vendor-Length | String... 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 Vendor-Type 109 11 for MS-CHAP-Challenge. 111 Vendor-Length 113 > 2 115 String 117 The String field contains the MS-CHAP challenge. 119 5.2. MS-CHAP-Response 121 Description 123 This Attribute contains the response value provided by a PPP 124 Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) 125 user in response to the challenge. It is only used in Access- 126 Request packets. 128 A summary of the MS-CHAP-Response Attribute format is shown below. 129 The fields are transmitted from left to right. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Vendor-Type | Vendor-Length | Ident | Flags | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | LM-Response 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 LM-Response (cont) 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 LM-Response (cont) 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 LM-Response (cont) 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 LM-Response (cont) 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 LM-Response(cont) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | NT-Response 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 NT-Response (cont) 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 NT-Response (cont) 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 NT-Response (cont) 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 NT-Response (cont) 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 NT-Response (cont) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Vendor-Type 163 1 for MS-CHAP-Response. 165 Vendor-Length 167 52 169 Ident 170 Identical to the PPP CHAP Identifier. 172 Flags 173 The Flags field is one octet in length. If the Flags field is one 174 (0x01), the NT-Response field is to be used in preference to the 175 LM-Response field for authentication. The LM-Response field MAY 176 still be used (if non-empty), but the NT-Response SHOULD be tried 177 first. If it is zero, the NT-Response field MUST be ignored and 178 the LM-Response field used. 180 LM-Response 181 The LM-Response field is 24 octets in length and holds an encoded 182 function of the password and the received challenge. If this 183 field is empty, it SHOULD be zero-filled. 185 NT-Response 186 The NT-Response field is 24 octets in length and holds an encoded 187 function of the password and the received challenge. If this 188 field is empty, it SHOULD be zero-filled. 190 5.3. MS-CHAP-Domain 192 Description 194 The MS-CHAP-Domain Attribute indicates the Windows NT domain in 195 which the user was authenticated. It MAY be included in both 196 Access-Accept and Accounting-Request packets. 198 A summary of the MS-CHAP-Domain Attribute format is given below. The 199 fields are transmitted left to right. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Vendor-Type | Vendor-Length | Ident | String... 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Vendor-Type 209 10 for MS-CHAP-Domain. 211 Vendor-Length 213 > 3 215 Ident 217 The Ident field is one octet and aids in matching requests and 218 replies. 220 String 222 This field contains the name in ASCII of the Windows NT domain in 223 which the user was authenticated. 225 5.4. MS-CHAP-Error 227 Description 229 The MS-CHAP-Error Attribute contains error data related to the 230 preceding MS-CHAP exchange. It is only used in Access-Reject 231 packets. 233 A summary of the MS-CHAP-Error Attribute format is given below. The 234 fields are transmitted left to right. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Vendor-Type | Vendor-Length | Ident | String... 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Vendor-Type 244 2 for MS-CHAP-Error. 246 Vendor-Length 248 > 3 250 Ident 252 The Ident field is one octet and aids in matching requests and 253 replies. 255 String 257 This field contains up to 48 octets of specially formatted ASCII 258 text, which is interpreted by the authenticating peer. The format 259 of this field is as follows: 261 "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv" 263 where the "eeeeeeeeee" represents an ASCII representation of a 264 decimal error code of up to 10 digits corresponding to one of the 265 following: 267 646 ERROR_RESTRICTED_LOGON_HOURS 268 647 ERROR_ACCT_DISABLED 269 648 ERROR_PASSWD_EXPIRED 270 649 ERROR_NO_DIALIN_PERMISSION 271 691 ERROR_AUTHENTICATION_FAILURE 272 709 ERROR_CHANGING_PASSWORD 274 Implementations should deal with codes not on this list grace- 275 fully, however. Please note that (unlike PPP CHAP), the receipt 276 of some of these error codes (in particular, the 277 ERROR_PASSWD_EXPIRED code) will modify the subsequent operation of 278 the MS-CHAP protocol. The 'r' is a retry flag (set to '1' if a 279 retry is allowed and '0' otherwise), the "cccccccccccccccc" repre- 280 sents 16 hexadecimal digits ('0'-'F') specifying a new challenge 281 value, and the "vvvvvvvvvv" is a decimal version code signifying 282 the version of MS-CHAP supported by the server. 284 5.5. MS-CHAP-CPW-1 286 Description 288 This Attribute allows the user to change their password if it has 289 expired. This Attribute is only used in Access-Request packets, 290 and should only be included if an MS-CHAP-Error attribute was 291 included in the immediately preceding Access-Reject packet, the 292 String field of the MS-CHAP-Error attribute indicated that the 293 user password had expired, and the MS-CHAP version is less than 2. 295 A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The 296 fields are transmitted from left to right. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Vendor-Type | Vendor-Length | Code | Ident | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | LM-Old-Password 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 LM-Old-Password (cont) 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 LM-Old-Password (cont) 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 LM-Old-Password (cont) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | LM-New-Password 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 LM-New-Password (cont) 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 LM-New-Password (cont) 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 LM-New-Password (cont) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | NT-Old-Password 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 NT-Old-Password (cont) 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 NT-Old-Password (cont) 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 NT-Old-Password (cont) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | NT-New-Password 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 NT-New-Password (cont) 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 NT-New-Password (cont) 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 NT-New-Password (cont) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | New-LM-Password-Length | Flags | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Vendor-Type 341 3 for MS-CHAP-PW-1 343 Vendor-Length 345 72 347 Code 349 The Code field is one octet in length. Its value is always 5. 351 Ident 353 The Ident field is one octet and aids in matching requests and 354 replies. 356 LM-Old-Password 358 The LM-Old-Password field is 16 octets in length. It contains the 359 encrypted Lan Manager hash of the old password. 361 LM-New-Password 363 The LM-New-Password field is 16 octets in length. It contains the 364 encrypted Lan Manager hash of the new password. 366 NT-Old-Password 368 The NT-Old-Password field is 16 octets in length. It contains the 369 encrypted Lan Manager hash of the old password. 371 NT-New-Password 373 The NT-New-Password field is 16 octets in length. It contains the 374 encrypted Lan Manager hash of the new password. 376 New-LM-Password-Length 378 The New-LM-Password-Length field is two octets in length and con- 379 tains the length in octets of the new LAN Manager-compatible pass- 380 word. 382 Flags 384 The Flags field is two octets in length. If the least significant 385 bit of the Flags field is one, this indicates that the NT-New- 386 Password and NT-Old-Password fields are valid and SHOULD be used. 387 Otherwise, the LM-New-Password and LM-Old-Password fields MUST be 388 used. 390 5.6. MS-CHAP-CPW-2 392 Description 394 This Attribute allows the user to change their password if it has 395 expired. This Attribute is only used in Access-Request packets, 396 and should only be included if an MS-CHAP-Error attribute was 397 included in the immediately preceding Access-Reject packet, the 398 String field of the MS-CHAP-Error attribute indicated that the 399 user password had expired, and the MS-CHAP version is 2 or 400 greater. 402 A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The 403 fields are transmitted from left to right. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Vendor-Type | Vendor-Length | Code | Ident | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Old-NT-Hash 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Old-NT-Hash (cont) 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Old-NT-Hash (cont) 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Old-NT-Hash (cont) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Old-LM-Hash 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Old-LM-Hash(cont) 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Old-LM-Hash(cont) 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Old-LM-Hash(cont) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | LM-Response 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 LM-Response (cont) 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 LM-Response (cont) 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 LM-Response (cont) 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 LM-Response (cont) 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 LM-Response (cont) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | NT-Response 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 NT-Response (cont) 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 NT-Response (cont) 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 NT-Response (cont) 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 NT-Response (cont) 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 NT-Response (cont) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Flags | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Vendor-Type 456 4 for MS-CHAP-PW-2 458 Vendor-Length 460 86 462 Code 464 6 466 Ident 468 The Ident field is one octet and aids in matching requests and 469 replies. The value of this field MUST be identical to that in the 470 Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT- 471 Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access- 472 Request packet. 474 Old-NT-Hash 476 The Old-NT-Hash field is 16 octets in length. It contains the old 477 Windows NT password hash encrypted with the new Windows NT pass- 478 word hash. 480 Old-LM-Hash 482 The Old-LM-Hash field is 16 octets in length. It contains the old 483 Lan Manager password hash encrypted with the new Windows NT pass- 484 word hash. 486 LM-Response 488 The LM-Response field is 24 octets in length and holds an encoded 489 function of the password and the received challenge. If this 490 field is empty, it SHOULD be zero-filled. 492 NT-Response 494 The NT-Response field is 24 octets in length and holds an encoded 495 function of the password and the received challenge. If this 496 field is empty, it SHOULD be zero-filled. 498 Flags 499 The Flags field is two octets in length. If the least significant 500 bit (bit 0) of this field is one, the NT-Response field is to be 501 used in preference to the LM-Response field for authentication. 502 The LM-Response field MAY still be used (if present), but the NT- 503 Response SHOULD be tried first. If least significant bit of the 504 field is zero, the NT-Response field MUST be ignored and the LM- 505 Response field used instead. If bit 1 of the Flags field is one, 506 the Old-LM-Hash field is valid and SHOULD be used. If this bit is 507 set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST 508 be included in the packet. 510 5.7. MS-CHAP-LM-Enc-PW 512 Description 514 This Attribute contains the new Windows NT password encrypted with 515 the old LAN Manager password hash. The encrypted Windows NT pass- 516 word is 516 octets in length; since this is longer than the maxi- 517 mum lengtth of a RADIUS attribute, the password must be split into 518 several attibutes for transmission. A 2 octet sequence number is 519 included in the attribute to help preserve ordering of the pass- 520 word fragments. 522 This Attribute is only used in Access-Request packets, in conjunc- 523 tion with the MS-CHAP-CPW-2 attribute. It should only be included 524 if an MS-CHAP-Error attribute was included in the immediately pre- 525 ceding Access-Reject packet, the String field of the MS-CHAP-Error 526 attribute indicated that the user password had expired, and the 527 MS-CHAP version is 2 or greater. 529 A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below. 530 The fields are transmitted from left to right. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Vendor-Type | Vendor-Length | Code | Ident | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Sequence-Number | String ... 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Vendor-Type 542 5 for MS-CHAP-LM-Enc-PW 544 Vendor-Length 546 > 6 548 Code 550 6. Code is the same as for the MS-CHAP-PW-2 attribute. 552 Ident 554 The Ident field is one octet and aids in matching requests and 555 replies. The value of this field MUST be identical in all 556 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 557 PW-2 attributes which are present in the same Access-Request 558 packet. 560 Sequence-Number 562 The Sequence-Number field is two octets in length and indicates 563 which "chunk" of the encrypted password is contained in the fol- 564 lowing String field. 566 String 567 The String field contains a portion of the encrypted password. 569 5.8. MS-CHAP-NT-Enc-PW 571 Description 573 This Attribute contains the new Windows NT password encrypted with 574 the old Windows NT password hash. The encrypted Windows NT pass- 575 word is 516 octets in length; since this is longer than the maxi- 576 mum lengtth of a RADIUS attribute, the password must be split into 577 several attibutes for transmission. A 2 octet sequence number is 578 included in the attribute to help preserve ordering of the pass- 579 word fragments. 581 This Attribute is only used in Access-Request packets, in conjunc- 582 tion with the MS-CHAP-CPW-2 attribute. It should only be included 583 if an MS-CHAP-Error attribute was included in the immediately pre- 584 ceding Access-Reject packet, the String field of the MS-CHAP-Error 585 attribute indicated that the user password had expired, and the 586 MS-CHAP version is 2 or greater. 588 A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. 589 The fields are transmitted from left to right. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Vendor-Type | Vendor-Length | Code | Ident | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Sequence-Number | String ... 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Vendor-Type 601 6 for MS-CHAP-NT-Enc-PW 603 Vendor-Length 605 > 6 607 Code 609 6. Code is the same as for the MS-CHAP-PW-2 attribute. 611 Ident 613 The Ident field is one octet and aids in matching requests and 614 replies. The value of this field MUST be identical in all 615 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 616 PW-2 attributes which are present in the same Access-Request 617 packet. 619 Sequence-Number 621 The Sequence-Number field is two octets in length and indicates 622 which "chunk" of the encrypted password is contained in the fol- 623 lowing String field. 625 String 626 The String field contains a portion of the encrypted password. 628 5.9. MS-CHAP-MPPE-Keys 630 Description 632 The MS-CHAP-MPPE-Keys Attribute contains two session keys for use 633 by the Microsoft Point-to-Point Encryption Protocol (MPPE). This 634 Attribute is only included in Access-Accept packets. 636 A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. 637 The fields are transmitted left to right. 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Vendor-Type | Vendor-Length | Keys 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Keys (cont) 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Keys (cont) 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Keys (cont) 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Keys (cont) 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Keys (cont) 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Keys (cont) 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Keys (cont) 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Keys (cont) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Vendor-Type 662 12 for MS-CHAP-MPPE-Keys. 664 Vendor-Length 666 34 668 Keys 670 The Keys field consists of two logical sub-fields: the LM-Key and 671 the NT-Key. The LM-Key is eight octets in length and contains the 672 first eight bytes of the hashed LAN Manager password. The NT-Key 673 sub-field is sixteen octets in length and contains the first six- 674 teen octets of the hashed Windows NT password. The format of the 675 plaintext Keys field is illustrated in the following diagram: 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | LM-Key 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 LM-Key (cont) | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | NT-Key 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 NT-Key (cont) 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 NT-Key (cont) 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 NT-Key (cont) | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Padding 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Padding (cont) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 The Keys field MUST be encrypted by the RADIUS server using the 698 same method defined for the User-Password Attribute [3]. Note 699 that the padding is required because the method referenced above 700 requires the field to be encrypted to be a multiple of sixteen 701 octets in length. 703 6. Table of Attributes 705 The following table provides a guide to which of the above attributes 706 may be found in which kinds of packets, and in what quantity. 708 Request Accept Reject Challenge Acct-Request # Attribute 709 0+ 0 0 0+ 0 11 MS-CHAP-Challenge 710 0+ 0 0 0 0 1 MS-CHAP-Response 711 0 0+ 0 0 0+ 10 MS-CHAP-Domain 712 0 0 0+ 0 0 2 MS-CHAP-Error 713 0+ 0 0 0 0 3 MS-CHAP-CPW-1 714 0+ 0 0 0 0 4 MS-CHAP-CPW-2 715 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW 716 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW 717 0 0+ 0 0 0 12 MS-CHAP-MPPE-Keys 719 The following table defines the meaning of the above table entries. 721 0 This attribute MUST NOT be present in packet. 722 0+ Zero or more instances of this attribute MAY be present in packet. 723 0-1 Zero or one instance of this attribute MAY be present in packet. 725 7. References 727 [1] Simpson, W., "PPP Challenge Handshake Authentication Protocol 728 (CHAP)", RFC 1994, August 1996 730 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 731 Levels", RFC 2119, March 1997 733 [3] Rigney, C., et. al., "Remote Access Dial In User Service", RFC 734 2138, April 1997 736 8. Security Considerations 738 MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User 739 passwords should be chosen with care, and be of sufficient length to 740 deter easy guessing. Although the scheme used to protect the Keys field 741 of the MS-CHAP-MPPE-Keys Attribute is believed to be relatively secure 742 on the wire, RADIUS proxies will decrypt and re-encrypt the field for 743 forwarding. Therefore, the MS-CHAP-MPPE-Keys attribute SHOULD NOT be 744 used on networks where untrusted RADIUS proxies reside. 746 9. Acknowledgements 748 Thanks to Carl Rigney (cdr@livingston.com), Narendra Gidwani 749 (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), Pat Calhoun 750 (pcalhoun@usr.com), Dave Mitton (dmitton@baynetworks.com), Paul Funk 751 (paul@funk.com), Gurdeep Singh Pall (gurdeep@microsoft.com) and Don Rule 752 (donaldr@microsoft.com) for useful suggestions and editorial feedback. 754 10. Expiration Date 756 This document expires May 10, 1998. 758 11. Author's Address 760 Glen Zorn 761 Microsoft Corporation 762 One Microsoft Way 763 Redmond, Washington 98052 765 Phone: +1 425 703 1559 766 FAX: +1 425 936 7329 767 EMail: glennz@microsoft.com