idnits 2.17.1 draft-ietf-radius-mschap-attr-00.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 103 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...' == (98 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 RADIUS Working Group mailing list (ietf-radius@livingston.com) or to the 31 author (glennz@microsoft.com). 33 2. Abstract 35 This document describes a set of vendor-specific RADIUS attributes 36 designed to support the use of Microsoft's proprietary dialect of PPP 37 CHAP (MS-CHAP) in dial-up networks. MS-CHAP is derived from and (where 38 possible) consistent with PPP CHAP [1]; the differences between PPP CHAP 39 and MS-CHAP are significant enough to warrant the definition of new 40 RADIUS attributes, however. 42 3. Introduction 44 Microsoft created Microsoft Challenge-Handshake Authentication Protocol 45 (MS-CHAP) to authenticate remote Windows workstations, providing the 46 functionality to which LAN-based users are accustomed. Where possible, 47 MS-CHAP is consistent with standard CHAP, and the differences are easily 48 modularized. Briefly, the differences between MS-CHAP and standard CHAP 49 are: 51 * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP 52 option 3, Authentication Protocol. 54 * The MS-CHAP Response packet is in a format designed for 55 compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0, 56 Microsoft Windows95, and Microsoft LAN Manager 2.x networking 57 products. The MS-CHAP format does not require the 58 authenticator to store a clear-text or reversibly encrypted 59 password. 61 * MS-CHAP provides an authenticator-controlled authentication 62 retry mechanism. 64 * MS-CHAP provides an authenticator-controlled password changing 65 mechanism. 67 * MS-CHAP defines an extended set of reason-for-failure codes, 68 returned in the Failure packet Message field. 70 The attributes defined in this document reflect these differences. 72 4. Specification of Requirements 74 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 75 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 76 described in [2]. 78 5. Attributes 80 The following sections describe sub-attributes which may be transmitted 81 in one or more RADIUS attributes of type Vendor-Specific [3]. More than 82 one sub-attribute MAY be transmitted in a single Vendor-Specific 83 Attribute; if this is done, the sub-attributes SHOULD be packed as a 84 sequence of Vendor-Type/Vendor-Length/Value triples following the inital 85 Type, Length and Vendor-ID fields. The Length field of the Vendor-Spe- 86 cific Attribute MUST be set equal to the sum of the Vendor-Length fields 87 of the sub-attributes contained in the Vendor-Specific Attribute, plus 88 six. The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be 89 set to decimal 311 (Microsoft). 91 5.1. MS-CHAP-Challenge 93 Description 95 This Attribute contains the challenge sent by a NAS to a Microsoft 96 Challenge-Handshake Authentication Protocol (MS-CHAP) user. It 97 MAY be used in both Access-Request and Access-Challenge packets. 99 A summary of the MS-CHAP-Challenge Attribute format is shown below. 100 The fields are transmitted from left to right. 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Vendor-Type | Vendor-Length | String... 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 Vendor-Type 110 11 for MS-CHAP-Challenge. 112 Vendor-Length 114 > 2 116 String 118 The String field contains the MS-CHAP challenge. 120 5.2. MS-CHAP-Response 122 Description 124 This Attribute contains the response value provided by a PPP 125 Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) 126 user in response to the challenge. It is only used in Access- 127 Request packets. 129 A summary of the MS-CHAP-Response Attribute format is shown below. 130 The fields are transmitted from left to right. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Vendor-Type | Vendor-Length | Ident | Flags | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | LM-Response 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 LM-Response (cont) 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 LM-Response (cont) 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 LM-Response (cont) 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 LM-Response (cont) 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 LM-Response(cont) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | NT-Response 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 NT-Response (cont) 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 NT-Response (cont) 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 NT-Response (cont) 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 NT-Response (cont) 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 NT-Response (cont) | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Vendor-Type 164 1 for MS-CHAP-Response. 166 Vendor-Length 168 52 170 Ident 171 Identical to the PPP CHAP Identifier. 173 Flags 174 The Flags field is one octet in length. If the Flags field is one 175 (0x01), the NT-Response field is to be used in preference to the 176 LM-Response field for authentication. The LM-Response field MAY 177 still be used (if non-empty), but the NT-Response SHOULD be tried 178 first. If it is zero, the NT-Response field MUST be ignored and 179 the LM-Response field used. 181 LM-Response 182 The LM-Response field is 24 octets in length and holds an encoded 183 function of the password and the received challenge. If this 184 field is empty, it SHOULD be zero-filled. 186 NT-Response 187 The NT-Response field is 24 octets in length and holds an encoded 188 function of the password and the received challenge. If this 189 field is empty, it SHOULD be zero-filled. 191 5.3. MS-CHAP-Domain 193 Description 195 The MS-CHAP-Domain Attribute indicates the Windows NT domain in 196 which the user was authenticated. It MAY be included in both 197 Access-Accept and Accounting-Request packets. 199 A summary of the MS-CHAP-Domain Attribute format is given below. The 200 fields are transmitted left to right. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Vendor-Type | Vendor-Length | Ident | String... 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Vendor-Type 210 10 for MS-CHAP-Domain. 212 Vendor-Length 214 > 3 216 Ident 218 The Ident field is one octet and aids in matching requests and 219 replies. 221 String 223 This field contains the name in ASCII of the Windows NT domain in 224 which the user was authenticated. 226 5.4. MS-CHAP-Error 228 Description 230 The MS-CHAP-Error Attribute contains error data related to the 231 preceding MS-CHAP exchange. It is only used in Access-Reject 232 packets. 234 A summary of the MS-CHAP-Error Attribute format is given below. The 235 fields are transmitted left to right. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Vendor-Type | Vendor-Length | Ident | String... 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Vendor-Type 245 2 for MS-CHAP-Error. 247 Vendor-Length 249 > 3 251 Ident 253 The Ident field is one octet and aids in matching requests and 254 replies. 256 String 258 This field contains up to 48 octets of specially formatted ASCII 259 text, which is interpreted by the authenticating peer. The format 260 of this field is as follows: 262 "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv" 264 where the "eeeeeeeeee" represents an ASCII representation of a 265 decimal error code of up to 10 digits corresponding to one of the 266 following: 268 646 ERROR_RESTRICTED_LOGON_HOURS 269 647 ERROR_ACCT_DISABLED 270 648 ERROR_PASSWD_EXPIRED 271 649 ERROR_NO_DIALIN_PERMISSION 272 691 ERROR_AUTHENTICATION_FAILURE 273 709 ERROR_CHANGING_PASSWORD 275 Implementations should deal with codes not on this list grace- 276 fully, however. Please note that (unlike PPP CHAP), the receipt 277 of some of these error codes (in particular, the 278 ERROR_PASSWD_EXPIRED code) will modify the subsequent operation of 279 the MS-CHAP protocol. The 'r' is a retry flag (set to '1' if a 280 retry is allowed and '0' otherwise), the "cccccccccccccccc" repre- 281 sents 16 hexadecimal digits ('0'-'F') specifying a new challenge 282 value, and the "vvvvvvvvvv" is a decimal version code signifying 283 the version of MS-CHAP supported by the server. 285 5.5. MS-CHAP-CPW-1 287 Description 289 This Attribute allows the user to change their password if it has 290 expired. This Attribute is only used in Access-Request packets, 291 and should only be included if an MS-CHAP-Error attribute was 292 included in the immediately preceding Access-Reject packet, the 293 String field of the MS-CHAP-Error attribute indicated that the 294 user password had expired, and the MS-CHAP version is less than 2. 296 A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The 297 fields are transmitted from left to right. 299 0 1 2 3 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 | Code | Ident | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | LM-Old-Password 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 LM-Old-Password (cont) 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 LM-Old-Password (cont) 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 LM-Old-Password (cont) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | LM-New-Password 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 LM-New-Password (cont) 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 LM-New-Password (cont) 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 LM-New-Password (cont) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | NT-Old-Password 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 NT-Old-Password (cont) 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 NT-Old-Password (cont) 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 NT-Old-Password (cont) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | NT-New-Password 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 NT-New-Password (cont) 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 NT-New-Password (cont) 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 NT-New-Password (cont) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | New-LM-Password-Length | Flags | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Vendor-Type 342 3 for MS-CHAP-PW-1 344 Vendor-Length 346 72 348 Code 350 The Code field is one octet in length. Its value is always 5. 352 Ident 354 The Ident field is one octet and aids in matching requests and 355 replies. 357 LM-Old-Password 359 The LM-Old-Password field is 16 octets in length. It contains the 360 encrypted Lan Manager hash of the old password. 362 LM-New-Password 364 The LM-New-Password field is 16 octets in length. It contains the 365 encrypted Lan Manager hash of the new password. 367 NT-Old-Password 369 The NT-Old-Password field is 16 octets in length. It contains the 370 encrypted Lan Manager hash of the old password. 372 NT-New-Password 374 The NT-New-Password field is 16 octets in length. It contains the 375 encrypted Lan Manager hash of the new password. 377 New-LM-Password-Length 379 The New-LM-Password-Length field is two octets in length and con- 380 tains the length in octets of the new LAN Manager-compatible pass- 381 word. 383 Flags 385 The Flags field is two octets in length. If the least significant 386 bit of the Flags field is one, this indicates that the NT-New- 387 Password and NT-Old-Password fields are valid and SHOULD be used. 388 Otherwise, the LM-New-Password and LM-Old-Password fields MUST be 389 used. 391 5.6. MS-CHAP-CPW-2 393 Description 395 This Attribute allows the user to change their password if it has 396 expired. This Attribute is only used in Access-Request packets, 397 and should only be included if an MS-CHAP-Error attribute was 398 included in the immediately preceding Access-Reject packet, the 399 String field of the MS-CHAP-Error attribute indicated that the 400 user password had expired, and the MS-CHAP version is 2 or 401 greater. 403 A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The 404 fields are transmitted from left to right. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Vendor-Type | Vendor-Length | Code | Ident | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Old-NT-Hash 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Old-NT-Hash (cont) 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Old-NT-Hash (cont) 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Old-NT-Hash (cont) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Old-LM-Hash 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Old-LM-Hash(cont) 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Old-LM-Hash(cont) 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Old-LM-Hash(cont) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | LM-Response 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 LM-Response (cont) 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 LM-Response (cont) 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 LM-Response (cont) 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 LM-Response (cont) 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 LM-Response (cont) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | NT-Response 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 NT-Response (cont) 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 NT-Response (cont) 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 NT-Response (cont) 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 NT-Response (cont) 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 NT-Response (cont) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Flags | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Vendor-Type 457 4 for MS-CHAP-PW-2 459 Vendor-Length 461 86 463 Code 465 6 467 Ident 469 The Ident field is one octet and aids in matching requests and 470 replies. The value of this field MUST be identical to that in the 471 Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT- 472 Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access- 473 Request packet. 475 Old-NT-Hash 477 The Old-NT-Hash field is 16 octets in length. It contains the old 478 Windows NT password hash encrypted with the new Windows NT pass- 479 word hash. 481 Old-LM-Hash 483 The Old-LM-Hash field is 16 octets in length. It contains the old 484 Lan Manager password hash encrypted with the new Windows NT pass- 485 word hash. 487 LM-Response 489 The LM-Response field is 24 octets in length and holds an encoded 490 function of the password and the received challenge. If this 491 field is empty, it SHOULD be zero-filled. 493 NT-Response 495 The NT-Response field is 24 octets in length and holds an encoded 496 function of the password and the received challenge. If this 497 field is empty, it SHOULD be zero-filled. 499 Flags 500 The Flags field is two octets in length. If the least significant 501 bit (bit 0) of this field is one, the NT-Response field is to be 502 used in preference to the LM-Response field for authentication. 503 The LM-Response field MAY still be used (if present), but the NT- 504 Response SHOULD be tried first. If least significant bit of the 505 field is zero, the NT-Response field MUST be ignored and the LM- 506 Response field used instead. If bit 1 of the Flags field is one, 507 the Old-LM-Hash field is valid and SHOULD be used. If this bit is 508 set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST 509 be included in the packet. 511 5.7. MS-CHAP-LM-Enc-PW 513 Description 515 This Attribute contains the new Windows NT password encrypted with 516 the old LAN Manager password hash. The encrypted Windows NT pass- 517 word is 516 octets in length; since this is longer than the maxi- 518 mum lengtth of a RADIUS attribute, the password must be split into 519 several attibutes for transmission. A 2 octet sequence number is 520 included in the attribute to help preserve ordering of the pass- 521 word fragments. 523 This Attribute is only used in Access-Request packets, in conjunc- 524 tion with the MS-CHAP-CPW-2 attribute. It should only be included 525 if an MS-CHAP-Error attribute was included in the immediately pre- 526 ceding Access-Reject packet, the String field of the MS-CHAP-Error 527 attribute indicated that the user password had expired, and the 528 MS-CHAP version is 2 or greater. 530 A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below. 531 The fields are transmitted from left to right. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Vendor-Type | Vendor-Length | Code | Ident | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Sequence-Number | String ... 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Vendor-Type 543 5 for MS-CHAP-LM-Enc-PW 545 Vendor-Length 547 > 6 549 Code 551 6. Code is the same as for the MS-CHAP-PW-2 attribute. 553 Ident 555 The Ident field is one octet and aids in matching requests and 556 replies. The value of this field MUST be identical in all 557 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 558 PW-2 attributes which are present in the same Access-Request 559 packet. 561 Sequence-Number 563 The Sequence-Number field is two octets in length and indicates 564 which "chunk" of the encrypted password is contained in the fol- 565 lowing String field. 567 String 568 The String field contains a portion of the encrypted password. 570 5.8. MS-CHAP-NT-Enc-PW 572 Description 574 This Attribute contains the new Windows NT password encrypted with 575 the old Windows NT password hash. The encrypted Windows NT pass- 576 word is 516 octets in length; since this is longer than the maxi- 577 mum lengtth of a RADIUS attribute, the password must be split into 578 several attibutes for transmission. A 2 octet sequence number is 579 included in the attribute to help preserve ordering of the pass- 580 word fragments. 582 This Attribute is only used in Access-Request packets, in conjunc- 583 tion with the MS-CHAP-CPW-2 attribute. It should only be included 584 if an MS-CHAP-Error attribute was included in the immediately pre- 585 ceding Access-Reject packet, the String field of the MS-CHAP-Error 586 attribute indicated that the user password had expired, and the 587 MS-CHAP version is 2 or greater. 589 A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. 590 The fields are transmitted from left to right. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Vendor-Type | Vendor-Length | Code | Ident | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Sequence-Number | String ... 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Vendor-Type 602 6 for MS-CHAP-NT-Enc-PW 604 Vendor-Length 606 > 6 608 Code 610 6. Code is the same as for the MS-CHAP-PW-2 attribute. 612 Ident 614 The Ident field is one octet and aids in matching requests and 615 replies. The value of this field MUST be identical in all 616 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 617 PW-2 attributes which are present in the same Access-Request 618 packet. 620 Sequence-Number 622 The Sequence-Number field is two octets in length and indicates 623 which "chunk" of the encrypted password is contained in the fol- 624 lowing String field. 626 String 627 The String field contains a portion of the encrypted password. 629 5.9. MS-CHAP-MPPE-Keys 631 Description 633 The MS-CHAP-MPPE-Keys Attribute contains two session keys for use 634 by the Microsoft Point-to-Point Encryption Protocol (MPPE). This 635 Attribute is only included in Access-Accept packets. 637 A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. 638 The fields are transmitted left to right. 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Vendor-Type | Vendor-Length | Keys 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Keys (cont) 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Keys (cont) 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Keys (cont) 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Keys (cont) 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Keys (cont) 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Keys (cont) 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Keys (cont) 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Keys (cont) | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Vendor-Type 663 12 for MS-CHAP-MPPE-Keys. 665 Vendor-Length 667 34 669 Keys 671 The Keys field consists of two logical sub-fields: the LM-Key and 672 the NT-Key. The LM-Key is eight octets in length and contains the 673 first eight bytes of the hashed LAN Manager password. The NT-Key 674 sub-field is sixteen octets in length and contains the first six- 675 teen octets of the hashed Windows NT password. The format of the 676 plaintext Keys field is illustrated in the following diagram: 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | LM-Key 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 LM-Key (cont) | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | NT-Key 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 NT-Key (cont) 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 NT-Key (cont) 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 NT-Key (cont) | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Padding 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Padding (cont) | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 The Keys field MUST be encrypted by the RADIUS server using the 699 same method defined for the User-Password Attribute [3]. Note 700 that the padding is required because the method referenced above 701 requires the field to be encrypted to be a multiple of sixteen 702 octets in length. 704 6. Table of Attributes 706 The following table provides a guide to which of the above attributes 707 may be found in which kinds of packets, and in what quantity. 709 Request Accept Reject Challenge Acct-Request # Attribute 710 0+ 0 0 0+ 0 11 MS-CHAP-Challenge 711 0+ 0 0 0 0 1 MS-CHAP-Response 712 0 0+ 0 0 0+ 10 MS-CHAP-Domain 713 0 0 0+ 0 0 2 MS-CHAP-Error 714 0+ 0 0 0 0 3 MS-CHAP-CPW-1 715 0+ 0 0 0 0 4 MS-CHAP-CPW-2 716 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW 717 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW 718 0 0+ 0 0 0 12 MS-CHAP-MPPE-Keys 720 The following table defines the meaning of the above table entries. 722 0 This attribute MUST NOT be present in packet. 723 0+ Zero or more instances of this attribute MAY be present in packet. 724 0-1 Zero or one instance of this attribute MAY be present in packet. 726 7. Security Considerations 728 MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User 729 passwords should be chosen with care, and be of sufficient length to 730 deter easy guessing. Although the scheme used to protect the Keys field 731 of the MS-CHAP-MPPE-Keys Attribute is believed to be relatively secure 732 on the wire, RADIUS proxies will decrypt and re-encrypt the field for 733 forwarding. Therefore, the MS-CHAP-MPPE-Keys attribute SHOULD NOT be 734 used on networks where untrusted RADIUS proxies reside. 736 8. Acknowledgements 738 Thanks to Carl Rigney (cdr@livingston.com), Narendra Gidwani 739 (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), Pat Calhoun 740 (pcalhoun@usr.com), Dave Mitton (dmitton@baynetworks.com), Paul Funk 741 (paul@funk.com), Gurdeep Singh Pall (gurdeep@microsoft.com) and Don Rule 742 (donaldr@microsoft.com) for useful suggestions and editorial feedback. 744 9. Expiration Date 746 This document expires May 10, 1998. 748 10. Chair's Address 750 The RADIUS Working Group can be contacted via the current chair: 752 Carl Rigney 753 Livingston Enterprises 754 4464 Willow Road 755 Pleasanton, California 94588 757 Phone: +1 510 426 0770 758 E-Mail: cdr@livingston.com 760 11. Author's Address 762 Questions about this memo can also be directed to: 764 Glen Zorn 765 Microsoft Corporation 766 One Microsoft Way 767 Redmond, Washington 98052 769 Phone: +1 425 703 1559 770 FAX: +1 425 936 7329 771 EMail: glennz@microsoft.com 773 12. References 775 [1] Simpson, W., "PPP Challenge Handshake Authentication Protocol 776 (CHAP)", RFC 1994, August 1996 778 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 779 Levels", RFC 2119, March 1997 781 [3] Rigney, C., et. al., "Remote Access Dial In User Service", RFC 782 2138, April 1997