idnits 2.17.1 draft-ietf-radius-mschap-attr-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-27) 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. 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 107 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 10 has weird spacing: '...This document...' == Line 11 has weird spacing: '...as, and its...' == Line 16 has weird spacing: '...and may be ...' == Line 17 has weird spacing: '...ference mater...' == Line 20 has weird spacing: '...To learn the...' == (102 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 9660 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: 13 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Zorn 2 Internet-Draft Microsoft Corporation 3 Category: Informational November 1997 4 6 RADIUS Attributes for MS-CHAP Support 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working doc- 13 uments as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as ``work in progress''. 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 This memo provides information for the Internet community. This memo 26 does not specify an Internet standard of any kind. The distribution of 27 this memo is unlimited. It is filed as and expires May 21, 1998. Please send comments to the 29 RADIUS Working Group mailing list (ietf-radius@livingston.com) or 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, the 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 108 11 for MS-CHAP-Challenge. 110 Vendor-Length 111 > 2 113 String 114 The String field contains the MS-CHAP challenge. 116 5.2. MS-CHAP-Response 118 Description 120 This Attribute contains the response value provided by a PPP 121 Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) 122 user in response to the challenge. It is only used in Access- 123 Request packets. 125 A summary of the MS-CHAP-Response Attribute format is shown below. 126 The fields are transmitted from left to right. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Vendor-Type | Vendor-Length | Ident | Flags | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | LM-Response 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 LM-Response (cont) 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 LM-Response (cont) 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 LM-Response (cont) 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 LM-Response (cont) 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 LM-Response(cont) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | NT-Response 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 NT-Response (cont) 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 NT-Response (cont) 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 NT-Response (cont) 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 NT-Response (cont) 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 NT-Response (cont) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Vendor-Type 159 1 for MS-CHAP-Response. 161 Vendor-Length 162 52 164 Ident 165 Identical to the PPP CHAP Identifier. 167 Flags 168 The Flags field is one octet in length. If the Flags field is one 169 (0x01), the NT-Response field is to be used in preference to the 170 LM-Response field for authentication. The LM-Response field MAY 171 still be used (if non-empty), but the NT-Response SHOULD be tried 172 first. If it is zero, the NT-Response field MUST be ignored and 173 the LM-Response field used. 175 LM-Response 176 The LM-Response field is 24 octets in length and holds an encoded 177 function of the password and the received challenge. If this 178 field is empty, it SHOULD be zero-filled. 180 NT-Response 181 The NT-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 5.3. MS-CHAP-Domain 187 Description 189 The MS-CHAP-Domain Attribute indicates the Windows NT domain in 190 which the user was authenticated. It MAY be included in both 191 Access-Accept and Accounting-Request packets. 193 A summary of the MS-CHAP-Domain Attribute format is given below. The 194 fields are transmitted left to right. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Vendor-Type | Vendor-Length | Ident | String... 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Vendor-Type 203 10 for MS-CHAP-Domain. 205 Vendor-Length 206 > 3 208 Ident 209 The Ident field is one octet and aids in matching requests and 210 replies. 212 String 213 This field contains the name in ASCII of the Windows NT domain in 214 which the user was authenticated. 216 5.4. MS-CHAP-Error 218 Description 220 The MS-CHAP-Error Attribute contains error data related to the 221 preceding MS-CHAP exchange. It is only used in Access-Reject 222 packets. 224 A summary of the MS-CHAP-Error Attribute format is given below. The 225 fields are transmitted left to right. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Vendor-Type | Vendor-Length | Ident | String... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Vendor-Type 233 2 for MS-CHAP-Error. 235 Vendor-Length 236 > 3 238 Ident 239 The Ident field is one octet and aids in matching requests and 240 replies. 242 String 243 This field contains up to 48 octets of specially formatted ASCII 244 text, which is interpreted by the authenticating peer. The format 245 of this field is as follows: 247 "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv" 249 where the "eeeeeeeeee" represents an ASCII representation of a 250 decimal error code of up to 10 digits corresponding to one of the 251 following: 253 646 ERROR_RESTRICTED_LOGON_HOURS 254 647 ERROR_ACCT_DISABLED 255 648 ERROR_PASSWD_EXPIRED 256 649 ERROR_NO_DIALIN_PERMISSION 257 691 ERROR_AUTHENTICATION_FAILURE 258 709 ERROR_CHANGING_PASSWORD 260 Implementations should deal with codes not on this list grace- 261 fully, however. Please note that (unlike PPP CHAP), the receipt 262 of some of these error codes (in particular, the 263 ERROR_PASSWD_EXPIRED code) will modify the subsequent operation of 264 the MS-CHAP protocol. The 'r' is a retry flag (set to '1' if a 265 retry is allowed and '0' otherwise), the "cccccccccccccccc" repre- 266 sents 16 hexadecimal digits ('0'-'F') specifying a new challenge 267 value, and the "vvvvvvvvvv" is a decimal version code signifying 268 the version of MS-CHAP supported by the server. 270 5.5. MS-CHAP-CPW-1 272 Description 274 This Attribute allows the user to change their password if it has 275 expired. This Attribute is only used in Access-Request packets, 276 and should only be included if an MS-CHAP-Error attribute was 277 included in the immediately preceding Access-Reject packet, the 278 String field of the MS-CHAP-Error attribute indicated that the 279 user password had expired, and the MS-CHAP version is less than 2. 281 A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The 282 fields are transmitted from left to right. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Vendor-Type | Vendor-Length | Code | Ident | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | LM-Old-Password 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 LM-Old-Password (cont) 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 LM-Old-Password (cont) 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 LM-Old-Password (cont) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | LM-New-Password 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 LM-New-Password (cont) 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 LM-New-Password (cont) 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 LM-New-Password (cont) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | NT-Old-Password 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 NT-Old-Password (cont) 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 NT-Old-Password (cont) 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 NT-Old-Password (cont) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | NT-New-Password 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 NT-New-Password (cont) 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 NT-New-Password (cont) 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 NT-New-Password (cont) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | New-LM-Password-Length | Flags | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Vendor-Type 325 3 for MS-CHAP-PW-1 327 Vendor-Length 328 72 330 Code 331 The Code field is one octet in length. Its value is always 5. 333 Ident 334 The Ident field is one octet and aids in matching requests and 335 replies. 337 LM-Old-Password 338 The LM-Old-Password field is 16 octets in length. It contains the 339 encrypted Lan Manager hash of the old password. 341 LM-New-Password 342 The LM-New-Password field is 16 octets in length. It contains the 343 encrypted Lan Manager hash of the new password. 345 NT-Old-Password 346 The NT-Old-Password field is 16 octets in length. It contains the 347 encrypted Lan Manager hash of the old password. 349 NT-New-Password 350 The NT-New-Password field is 16 octets in length. It contains the 351 encrypted Lan Manager hash of the new password. 353 New-LM-Password-Length 354 The New-LM-Password-Length field is two octets in length and con- 355 tains the length in octets of the new LAN Manager-compatible pass- 356 word. 358 Flags 359 The Flags field is two octets in length. If the least significant 360 bit of the Flags field is one, this indicates that the NT-New- 361 Password and NT-Old-Password fields are valid and SHOULD be used. 362 Otherwise, the LM-New-Password and LM-Old-Password fields MUST be 363 used. 365 5.6. MS-CHAP-CPW-2 367 Description 369 This Attribute allows the user to change their password if it has 370 expired. This Attribute is only used in Access-Request packets, 371 and should only be included if an MS-CHAP-Error attribute was 372 included in the immediately preceding Access-Reject packet, the 373 String field of the MS-CHAP-Error attribute indicated that the 374 user password had expired, and the MS-CHAP version is 2 or 375 greater. 377 A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The 378 fields are transmitted from left to right. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Vendor-Type | Vendor-Length | Code | Ident | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Old-NT-Hash 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Old-NT-Hash (cont) 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Old-NT-Hash (cont) 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Old-NT-Hash (cont) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Old-LM-Hash 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Old-LM-Hash(cont) 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Old-LM-Hash(cont) 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Old-LM-Hash(cont) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | LM-Response 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 LM-Response (cont) 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 LM-Response (cont) 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 LM-Response (cont) 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 LM-Response (cont) 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 LM-Response (cont) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | NT-Response 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 NT-Response (cont) 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 NT-Response (cont) 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 NT-Response (cont) 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 NT-Response (cont) 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 NT-Response (cont) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Flags | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Vendor-Type 430 4 for MS-CHAP-PW-2 432 Vendor-Length 433 86 435 Code 436 6 438 Ident 439 The Ident field is one octet and aids in matching requests and 440 replies. The value of this field MUST be identical to that in the 441 Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT- 442 Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access- 443 Request packet. 445 Old-NT-Hash 446 The Old-NT-Hash field is 16 octets in length. It contains the old 447 Windows NT password hash encrypted with the new Windows NT pass- 448 word hash. 450 Old-LM-Hash 451 The Old-LM-Hash field is 16 octets in length. It contains the old 452 Lan Manager password hash encrypted with the new Windows NT pass- 453 word hash. 455 LM-Response 456 The LM-Response field is 24 octets in length and holds an encoded 457 function of the password and the received challenge. If this 458 field is empty, it SHOULD be zero-filled. 460 NT-Response 461 The NT-Response field is 24 octets in length and holds an encoded 462 function of the password and the received challenge. If this 463 field is empty, it SHOULD be zero-filled. 465 Flags 466 The Flags field is two octets in length. If the least significant 467 bit (bit 0) of this field is one, the NT-Response field is to be 468 used in preference to the LM-Response field for authentication. 469 The LM-Response field MAY still be used (if present), but the NT- 470 Response SHOULD be tried first. If least significant bit of the 471 field is zero, the NT-Response field MUST be ignored and the LM- 472 Response field used instead. If bit 1 of the Flags field is one, 473 the Old-LM-Hash field is valid and SHOULD be used. If this bit is 474 set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST 475 be included in the packet. 477 5.7. MS-CHAP-LM-Enc-PW 479 Description 481 This Attribute contains the new Windows NT password encrypted with 482 the old LAN Manager password hash. The encrypted Windows NT pass- 483 word is 516 octets in length; since this is longer than the maxi- 484 mum lengtth of a RADIUS attribute, the password must be split into 485 several attibutes for transmission. A 2 octet sequence number is 486 included in the attribute to help preserve ordering of the pass- 487 word fragments. 489 This Attribute is only used in Access-Request packets, in conjunc- 490 tion with the MS-CHAP-CPW-2 attribute. It should only be included 491 if an MS-CHAP-Error attribute was included in the immediately pre- 492 ceding Access-Reject packet, the String field of the MS-CHAP-Error 493 attribute indicated that the user password had expired, and the 494 MS-CHAP version is 2 or greater. 496 A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below. 497 The fields are transmitted from left to right. 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Vendor-Type | Vendor-Length | Code | Ident | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Sequence-Number | String ... 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Vendor-Type 508 5 for MS-CHAP-LM-Enc-PW 510 Vendor-Length 511 > 6 513 Code 514 6. Code is the same as for the MS-CHAP-PW-2 attribute. 516 Ident 517 The Ident field is one octet and aids in matching requests and 518 replies. The value of this field MUST be identical in all 519 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 520 PW-2 attributes which are present in the same Access-Request 521 packet. 523 Sequence-Number 524 The Sequence-Number field is two octets in length and indicates 525 which "chunk" of the encrypted password is contained in the fol- 526 lowing String field. 528 String 529 The String field contains a portion of the encrypted password. 531 5.8. MS-CHAP-NT-Enc-PW 533 Description 535 This Attribute contains the new Windows NT password encrypted with 536 the old Windows NT password hash. The encrypted Windows NT pass- 537 word is 516 octets in length; since this is longer than the maxi- 538 mum lengtth of a RADIUS attribute, the password must be split into 539 several attibutes for transmission. A 2 octet sequence number is 540 included in the attribute to help preserve ordering of the pass- 541 word fragments. 543 This Attribute is only used in Access-Request packets, in conjunc- 544 tion with the MS-CHAP-CPW-2 attribute. It should only be included 545 if an MS-CHAP-Error attribute was included in the immediately pre- 546 ceding Access-Reject packet, the String field of the MS-CHAP-Error 547 attribute indicated that the user password had expired, and the 548 MS-CHAP version is 2 or greater. 550 A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. 551 The fields are transmitted from left to right. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Vendor-Type | Vendor-Length | Code | Ident | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Sequence-Number | String ... 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Vendor-Type 562 6 for MS-CHAP-NT-Enc-PW 564 Vendor-Length 565 > 6 567 Code 568 6. Code is the same as for the MS-CHAP-PW-2 attribute. 570 Ident 571 The Ident field is one octet and aids in matching requests and 572 replies. The value of this field MUST be identical in all 573 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 574 PW-2 attributes which are present in the same Access-Request 575 packet. 577 Sequence-Number 578 The Sequence-Number field is two octets in length and indicates 579 which "chunk" of the encrypted password is contained in the fol- 580 lowing String field. 582 String 583 The String field contains a portion of the encrypted password. 585 5.9. MS-CHAP-MPPE-Keys 587 Description 589 The MS-CHAP-MPPE-Keys Attribute contains two session keys for use 590 by the Microsoft Point-to-Point Encryption Protocol (MPPE). This 591 Attribute is only included in Access-Accept packets. Note that 592 the keys are generative session keys; no processing need be done 593 by the RADIUS client before using the keys in the MPPE protocol. 595 A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. 596 The fields are transmitted left to right. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Vendor-Type | Vendor-Length | Keys 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Keys (cont) 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Keys (cont) 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Keys (cont) 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Keys (cont) 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Keys (cont) 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Keys (cont) 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Keys (cont) 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Keys (cont) | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Vendor-Type 622 12 for MS-CHAP-MPPE-Keys. 624 Vendor-Length 625 34 627 Keys 628 The Keys field consists of two logical sub-fields: the LM-Key and 629 the NT-Key. The LM-Key is eight octets in length and is derived 630 from the first eight bytes of the hashed LAN Manager password. 631 The NT-Key sub-field is sixteen octets in length and is derived 632 from the first sixteen octets of the hashed Windows NT password. 633 The format of the plaintext Keys field is illustrated in the fol- 634 lowing diagram: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | LM-Key 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 LM-Key (cont) | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | NT-Key 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 NT-Key (cont) 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 NT-Key (cont) 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 NT-Key (cont) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Padding 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Padding (cont) | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 The Keys field MUST be encrypted by the RADIUS server using the 657 same method defined for the User-Password Attribute [3]. Note 658 that the padding is required because the method referenced above 659 requires the field to be encrypted to be a multiple of sixteen 660 octets in length. 662 6. Table of Attributes 664 The following table provides a guide to which of the above attributes 665 may be found in which kinds of packets, and in what quantity. 667 Request Accept Reject Challenge Acct-Request # Attribute 668 0+ 0 0 0+ 0 11 MS-CHAP-Challenge 669 0+ 0 0 0 0 1 MS-CHAP-Response 670 0 0+ 0 0 0+ 10 MS-CHAP-Domain 671 0 0 0+ 0 0 2 MS-CHAP-Error 672 0+ 0 0 0 0 3 MS-CHAP-CPW-1 673 0+ 0 0 0 0 4 MS-CHAP-CPW-2 674 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW 675 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW 676 0 0+ 0 0 0 12 MS-CHAP-MPPE-Keys 678 The following table defines the meaning of the above table entries. 680 0 This attribute MUST NOT be present in packet. 681 0+ Zero or more instances of this attribute MAY be present in packet. 682 0-1 Zero or one instance of this attribute MAY be present in packet. 684 7. Security Considerations 686 MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User 687 passwords should be chosen with care, and be of sufficient length to 688 deter easy guessing. Although the scheme used to protect the Keys field 689 of the MS-CHAP-MPPE-Keys Attribute is believed to be relatively secure 690 on the wire, RADIUS proxies will decrypt and re-encrypt the field for 691 forwarding. Therefore, the MS-CHAP-MPPE-Keys attribute SHOULD NOT be 692 used on networks where untrusted RADIUS proxies reside. 694 8. Acknowledgements 696 Thanks to Carl Rigney (cdr@livingston.com), Narendra Gidwani 697 (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), Pat Calhoun 698 (pcalhoun@usr.com), Dave Mitton (dmitton@baynetworks.com), Paul Funk 699 (paul@funk.com), Gurdeep Singh Pall (gurdeep@microsoft.com) and Don Rule 700 (donaldr@microsoft.com) for useful suggestions and editorial feedback. 702 9. Expiration Date 704 This document expires May 21, 1998. 706 10. Chair's Address 708 The RADIUS Working Group can be contacted via the current chair: 710 Carl Rigney 711 Livingston Enterprises 712 4464 Willow Road 713 Pleasanton, California 94588 715 Phone: +1 510 426 0770 716 E-Mail: cdr@livingston.com 718 11. Author's Address 720 Questions about this memo can also be directed to: 722 Glen Zorn 723 Microsoft Corporation 724 One Microsoft Way 725 Redmond, Washington 98052 727 Phone: +1 425 703 1559 728 FAX: +1 425 936 7329 729 EMail: glennz@microsoft.com 731 12. References 733 [1] Simpson, W., "PPP Challenge Handshake Authentication Protocol 734 (CHAP)", RFC 1994, August 1996 736 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 737 Levels", RFC 2119, March 1997 739 [3] Rigney, C., et. al., "Remote Access Dial In User Service", RFC 740 2138, April 1997