idnits 2.17.1 draft-kamath-pppext-eap-mschapv2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1140. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 355 has weird spacing: '...e, then a Fai...' == Line 357 has weird spacing: '... be termina...' == Line 498 has weird spacing: '...e, then the i...' == Line 676 has weird spacing: '...nd Data field...' -- 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 (12 June 2007) is 6160 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1320' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'RFC1994' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC2433' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'RC4' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'IEEE8021X' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'SHA1' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'RFC1570' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'DESMODES' is defined on line 907, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1320 (Obsoleted by RFC 6150) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-08 Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group Ryan Hurst 3 INTERNET-DRAFT Ashwin Palekar 4 Category: Informational Microsoft Corporation 5 Expires: December 25, 2007 12 June 2007 7 Microsoft EAP CHAP Extensions 8 draft-kamath-pppext-eap-mschapv2-02.txt 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 25, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 37 Abstract 39 This document defines the Microsoft EAP CHAP Extensions Protocol, 40 Version 2, which encapsulates the MS-CHAPv2 protocol defined in RFC 41 2759, within EAP as defined in RFC 3748. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Requirements language ........................... 3 47 1.2 Terminology ..................................... 3 48 2. EAP MS-CHAP-v2 Packet Format .......................... 4 49 2.1. Challenge packet ................................ 5 50 2.2. Response packet ................................. 7 51 2.3. Success Request packet .......................... 9 52 2.4. Success Response packet ......................... 11 53 2.5. Failure Request packet .......................... 12 54 2.6. Failure Response packet ......................... 14 55 2.7. Change-Password packet .......................... 15 56 2.8. Alternative failure behavior .................... 17 57 2.9. Known bugs ...................................... 18 58 3. Security claims .......................................... 18 59 4. References ............................................... 19 60 4.1 Normative references ............................ 19 61 4.2 Informative references .......................... 20 62 Appendix A - Examples ........................................ 22 63 Acknowledgments .............................................. 25 64 Author Addresses ............................................. 25 65 Full Copyright Statement ..................................... 25 66 Intellectual Property ........................................ 26 67 1. Introduction 69 The Extensible Authentication Protocol (EAP), described in [RFC3748], 70 provides a standard mechanism for support of multiple authentication 71 methods. Through the use of EAP, support for a number of 72 authentication schemes may be added, including smart cards, Kerberos, 73 Public Key, One Time Passwords, and others. 75 This document defines the Microsoft EAP CHAP Extensions Protocol, 76 Version 2, which encapsulates the MS-CHAP-v2 protocol, defined in 77 [RFC2759], within EAP. As with MS-CHAP-v2, EAP-MSCHAPv2 supports 78 mutual authentication and key derivation. The way EAP-MSCHAPv2 79 derived keys are used with the Microsoft Point to Point Encryption 80 (MPPE) cipher is described in [RFC3079]. 82 EAP MS-CHAP-V2 provides mutual authentication between peers by 83 piggybacking a peer challenge on the Response packet and an 84 authenticator response on the Success packet. 86 1.1. Requirements language 88 In this document, several words are used to signify the requirements 89 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 90 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 91 and "OPTIONAL" in this document are to be interpreted as described in 92 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 94 1.2. Terminology 96 This document frequently uses the following terms: 98 Authenticator 99 The end of the link requiring the authentication. 101 Peer The other end of the point-to-point link; the end which is being 102 authenticated by the authenticator. 104 silently discard 105 This means the implementation discards the packet without further 106 processing. The implementation SHOULD provide the capability of 107 logging the error, including the contents of the silently discarded 108 packet, and SHOULD record the event in a statistics counter. 110 2. EAP MS-CHAP-v2 Packet Format 112 A summary of the EAP MS-CHAP-V2 packet format is shown below. The 113 fields are transmitted from left to right. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Code | Identifier | Length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Type | OpCode | MS-CHAPv2-ID | MS-Length... 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | MS-Length | Data... 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Code 127 1 - Request 128 2 - Response 130 Identifier 132 The Identifier field is one octet and aids in matching responses with 133 requests. 135 Length 137 The Length field is two octets and indicates the length of the EAP 138 packet including the Code, Identifier, Length, Type, OpCode, MS- 139 CHAPv2-ID, MS-Length and Data fields. Octets outside the range of 140 the Length field should be treated as Data Link Layer padding and 141 should be ignored on reception. 143 Type 145 26 - EAP MS-CHAP-V2 147 OpCode 149 The OpCode field is one octet and identifies the type of EAP MS-CHAP- 150 v2 packet. OpCodes are assigned as follows: 152 1 Challenge 153 2 Response 154 3 Success 155 4 Failure 156 7 Change-Password 158 MS-CHAPv2-ID 160 The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 161 responses with requests. Typically, the MS-CHAPv2-ID field is the 162 same as the Identifier field. 164 MS-Length 166 The MS-Length field is two octets and MUST be set to the value of the 167 Length field minus 5. 169 Data 171 The format of the Data field is determined by the OpCode field. 173 2.1. Challenge packet 175 The Challenge packet is used to begin the EAP MS-CHAP-V2 protocol. 176 The authenticator MUST transmit an EAP Request packet with Type=26, 177 and the OpCode field set to 1 (Challenge). The format of the EAP MS- 178 CHAP-v2 Challenge packet is shown below. The fields are transmitted 179 from left to right. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Code | Identifier | Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | OpCode | MS-CHAPv2-ID | MS-Length... 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | MS-Length | Value-Size | Challenge... 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Challenge... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Name... 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Code 197 1 - Request 199 Identifier 201 The Identifier field is one octet. The Identifier field MUST be the 202 same if a Request packet is retransmitted due to a timeout while 203 waiting for a Response. Any new (non-retransmission) Requests MUST 204 modify the Identifier field. If a peer receives a duplicate Request 205 for which it has already sent a Response, it MUST resend it's 206 Response. If a peer receives a duplicate Request before it has sent 207 a Response to the initial Request (i.e. it's waiting for user input), 208 it MUST silently discard the duplicate Request. 210 Length 212 The Length field is two octets and indicates the length of the EAP 213 packet including the Code, Identifier, Length, Type, OpCode, MS- 214 CHAPv2-ID, MS-Length, Value-Size, Challenge, and Name fields. Octets 215 outside the range of the Length field should be treated as Data Link 216 Layer padding and should be ignored on reception. 218 Type 220 26 - EAP MS-CHAP-V2 222 OpCode 224 1 - Challenge 226 MS-CHAPv2-ID 228 The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 229 responses with requests. Typically, the MS-CHAPv2-ID field is the 230 same as the Identifier field. 232 MS-Length 234 The MS-Length field is two octets and MUST be set to the value of the 235 Length field minus 5. 237 Value-Size 239 This field is one octet and indicates the length of the Challenge 240 field. Since EAP MS-CHAPv2 utilizes a 16 octet Challenge field, it 241 is set to 0x10 (16 decimal). 243 Challenge 245 The Challenge field is 16 octets. The most significant octet is 246 transmitted first. The Challenge MUST be changed each time a 247 Challenge is sent. 249 Name 251 The Name field is one or more octets representing the identification 252 of the system transmitting the packet. There are no limitations on 253 the content of this field. The Name should not be NUL or CR/LF 254 terminated. The size of the Name field is equal to Length - Value- 255 Size - 10. 257 2.2. Response packet 259 The format of the EAP MS-CHAP-v2 Response packet is shown below. The 260 fields are transmitted from left to right. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Code | Identifier | Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | OpCode | MS-CHAPv2-ID | MS-Length... 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | MS-Length | Value-Size | Response... 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Response... 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Name... 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Code 278 2 - Response 280 Identifier 282 The Identifier field is one octet and contains the value included in 283 the EAP Request to which it responds. 285 Length 287 The Length field is two octets and indicates the length of the EAP 288 packet including the Code, Identifier, Length, Type, OpCode, MS- 289 CHAPv2-ID, MS-Length, Value-Size, Response, and Name fields. Octets 290 outside the range of the Length field should be treated as Data Link 291 Layer padding and should be ignored on reception. 293 Type 295 26 - EAP MS-CHAP-V2 297 OpCode 299 2 - Response 301 MS-CHAPv2-ID 303 The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 304 responses with requests. Typically, the MS-CHAPv2-ID field is the 305 same as the Identifier field. 307 MS-Length 309 The MS-Length field is two octets and MUST be set to the value of the 310 Length field minus 5. 312 Value-Size 314 This field is one octet and indicates the length of the Response 315 field. It is set to 0x31 (Decimal 49). 317 Response 319 The Response field is 49 octets. The most significant octet is 320 transmitted first. It is sub-formatted as follows: 322 16 octets: Peer-Challenge 323 8 octets: Reserved, must be zero 324 24 octets: NT-Response 325 1 octet : Flags 327 The Peer-Challenge field is a 16-octet random number. As the name 328 implies, it is generated by the peer and is used in the calculation 329 of the NT-Response field, below. Peers need not duplicate 330 Microsoft's algorithm for selecting the 16-octet value, but the 331 standard guidelines on randomness [RFC1750] SHOULD be observed. 333 The NT-Response field is an encoded function of the password, the 334 Name field of the Response packet, the contents of the Peer-Challenge 335 field and the received Challenge as output by the routine 336 GenerateNTResponse() defined in [RFC2759], Section 8.1. 338 The Windows NT password is a string of 0 to (theoretically) 256 case- 339 sensitive Unicode [UNICODE] characters. Current versions of Windows 340 NT limit passwords to 14 characters, mainly for compatibility 341 reasons; this may change in the future. When computing the NT- 342 Response field contents, only the user name is used, without any 343 associated Windows NT domain name. This is true regardless of 344 whether a Windows NT domain name is present in the Name field (see 345 below). 347 The Flag field is reserved for future use and MUST be zero. 349 Whenever a Response packet is received, the authenticator compares 350 the Response Value with its own calculation of the expected value. If 351 the values match, then the authenticator MUST send a Success-Request 352 packet, as described in Section 2.3. If the values do not match, and 353 if the error is retryable, then a Failure-Request packet MUST be sent 354 as described in Section 2.5. If the values do not match, and the 355 error is not retryable, then a Failure-Request packet (described in 356 Section 2.5) SHOULD be sent, or alternatively, the authentication MAY 357 be terminated (as described in Section 2.8) such as by sending an 358 EAP Failure. 360 Name 362 The Name field is a string of 0 to (theoretically) 256 case-sensitive 363 ASCII characters which identifies the peer's user account name. The 364 Windows NT domain name may prefix the user's account name (e.g. 365 BIGCO\johndoe where BIGCO is a Windows NT domain containing the user 366 account johndoe). If a domain is not provided, the backslash should 367 also be omitted, (e.g. johndoe). The Name SHOULD NOT be NUL or CR/LF 368 terminated. The size of the Name field is determined from the Length 369 - Value-Size - 10. 371 2.3. Success Request packet 373 If the value received in the Response field of the EAP MS-CHAP-V2 374 Response packet is equal to the expected value, then the 375 implementation MUST transmit an EAP MS-CHAP-V2 Request packet with 376 the OpCode field set to 3 (Success). 378 The format of the EAP MS-CHAP-v2 Success Request packet is shown 379 below. The fields are transmitted from left to right. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Code | Identifier | Length | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | OpCode | MS-CHAPv2-ID | MS-Length... 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | MS-Length | Message... 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Code 393 1 - Request 395 Identifier 397 The Identifier field is one octet. The Identifier field MUST be the 398 same if a Request packet is retransmitted due to a timeout while 399 waiting for a Response. Any new (non-retransmission) Requests MUST 400 modify the Identifier field. If a peer receives a duplicate Request 401 for which it has already sent a Response, it MUST resend it's 402 Response. If a peer receives a duplicate Request before it has sent 403 a Response to the initial Request (i.e. it's waiting for user input), 404 it MUST silently discard the duplicate Request. 406 Length 408 The Length field is two octets and indicates the length of the EAP 409 packet including the Code, Identifier, Length, Type, OpCode, MS- 410 CHAPv2-ID, MS-Length, and Message fields. Octets outside the range 411 of the Length field should be treated as Data Link Layer padding and 412 should be ignored on reception. 414 Type 416 26 - EAP MS-CHAP-V2 418 OpCode 420 3 - Success 422 MS-CHAPv2-ID 424 The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 425 responses with requests. Typically, the MS-CHAPv2-ID field is the 426 same as the Identifier field. 428 MS-Length 430 The MS-Length field is two octets and MUST be set to the value of the 431 Length field minus 5. 433 Message 435 The Message field contains a 42-octet authenticator response string 436 and a printable message. The format of the message field is 437 illustrated below. 439 "S= M=" 441 The quantity is a 20 octet number encoded in ASCII as 442 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST 443 be uppercase. This number is derived from the challenge from the 444 Challenge packet, the Peer-Challenge and NT-Response fields from the 445 Response packet, and the peer password as output by the routine 446 GenerateAuthenticatorResponse() defined in [RFC2759], Section 8.7. 447 The authenticating peer MUST verify the authenticator response when a 448 Success packet is received. The method for verifying the 449 authenticator is described in [RFC2759], section 8.8. If the 450 authenticator response is either missing or incorrect, the peer MUST 451 end the session without sending a response. 453 The quantity is human-readable text in the appropriate 454 charset and language [RFC2484]. 456 2.4. Success Response packet 458 In the peer successfully validates the EAP MS-CHAP-V2 Success Request 459 packet sent by the authenticator, then it MUST respond with an EAP 460 MS-CHAP-V2 Success Response packet with the OpCode field set to 3 461 (Success). 463 The format of the EAP MS-CHAP-v2 Success Response packet is shown 464 below. The fields are transmitted from left to right. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Code | Identifier | Length | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type | OpCode | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Code 476 2 - Response 478 Identifier 480 The Identifier field is one octet and contains the value included in 481 the EAP Request to which it responds. 483 Length 485 6 487 Type 489 26 - EAP MS-CHAP-V2 491 OpCode 493 3 - Success 495 2.5. Failure Request packet 497 If the Value received in a Response is not equal to the expected 498 value, and the error is retryable, then the implementation MUST 499 transmit an EAP MS-CHAP-v2 Request packet with the OpCode field set 500 to 4 (Failure). If the error is not retryable, then the 501 implementation SHOULD transmit an EAP MS-CHAP-v2 Failure Request 502 packet, or it MAY terminate the authentication (e.g. send an EAP 503 Failure packet). The former approach is preferable, since this 504 enables the cause of the error to be communicated. 506 The format of the EAP MS-CHAP-v2 Failure Request packet is shown 507 below. The fields are transmitted from left to right. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Code | Identifier | Length | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | OpCode | MS-CHAPv2-ID | MS-Length... 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | MS-Length | Message... 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Code 521 1 - Request 523 Identifier 525 The Identifier field is one octet. The Identifier field MUST be the 526 same if a Request packet is retransmitted due to a timeout while 527 waiting for a Response. Any new (non-retransmission) Requests MUST 528 modify the Identifier field. If a peer receives a duplicate Request 529 for which it has already sent a Response, it MUST resend it's 530 Response. If a peer receives a duplicate Request before it has sent 531 a Response to the initial Request (i.e. it's waiting for user input), 532 it MUST silently discard the duplicate Request. 534 Length 536 The Length field is two octets and indicates the length of the EAP 537 packet including the Code, Identifier, Length, Type, OpCode, MS- 538 CHAPv2-ID, MS-Length, and Message fields. Octets outside the range 539 of the Length field should be treated as Data Link Layer padding and 540 should be ignored on reception. 542 Type 544 26 - EAP MS-CHAP-V2 546 OpCode 548 4 - Failure 550 MS-CHAPv2-ID 552 The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 553 responses with requests. Typically, the MS-CHAPv2-ID field is the 554 same as the Identifier field. 556 MS-Length 558 The MS-Length field is two octets and MUST be set to the value of the 559 Length field minus 5. 561 Message 563 The Message field format is: 565 "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv M=" 567 where 569 The "eeeeeeeeee" is the ASCII representation of a decimal error code 570 corresponding to one of those listed below, though implementations 571 should deal with codes not on this list gracefully. The error code 572 need not be 10 digits long. 574 646 ERROR_RESTRICTED_LOGON_HOURS 575 647 ERROR_ACCT_DISABLED 576 648 ERROR_PASSWD_EXPIRED 577 649 ERROR_NO_DIALIN_PERMISSION 578 691 ERROR_AUTHENTICATION_FAILURE 579 709 ERROR_CHANGING_PASSWORD 581 The "r" is a single character ASCII flag set to '1' if a retry is 582 allowed, and '0' if not. Typically, errors 646, 647, and 649 are 583 non-retryable (R=0). When the authenticator sets this flag to '1' it 584 disables short timeouts, expecting the peer to prompt the user for 585 new credentials and resubmit the response. The 586 "cccccccccccccccccccccccccccccccc" is the ASCII representation of a 587 hexadecimal challenge value. This field MUST be exactly 32 octets 588 long and MUST be present. 590 The "vvvvvvvvvv" is the ASCII representation of a decimal version 591 code (need not be 10 digits) indicating the password changing 592 protocol version supported on the server. For EAP MS-CHAP-V2, this 593 value MUSTalways be 3. 595 is human-readable text in the appropriate charset and language 596 [RFC2484]. 598 2.6. Failure Response packet 600 When the peer receives a Failure Request packet that is retryable 601 (R=1), the authentication MAY be retried. For example, a new 602 Response packet, or Change Password packet MAY be sent. In these 603 cases a Failure Response packet is not sent. 605 However, if the EAP MS-CHAPv2 Failure Request is non-retryable (R=0), 606 then the peer SHOULD transmit an EAP MS-CHAP-v2 Response packet with 607 the OpCode field set to 4 (Failure). The format of the EAP MS-CHAP-v2 608 Failure Response packet is shown below. The fields are transmitted 609 from left to right. 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Code | Identifier | Length | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | OpCode | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Code 621 2 - Response 623 Identifier 625 The Identifier field is one octet and contains the value included in 626 the EAP Request to which it responds. 628 Length 630 6 632 Type 634 26 - EAP MS-CHAP-V2 636 OpCode 638 4 - Failure 640 2.7. Change-Password packet 642 The Change-Password packet does not appear in either standard CHAP or 643 MS-CHAP-V1. It allows the peer to change the password on the account 644 specified in the preceding Response packet. The Change-Password 645 packet should be sent only if the authenticator reports 646 ERROR_PASSWD_EXPIRED (E=648) in the Message field of the Failure 647 packet. 649 The format of the EAP MS-CHAP-v2 Change Password packet is shown 650 below. The fields are transmitted from left to right. 652 0 1 2 3 653 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Code | Identifier | Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | OpCode | MS-CHAPv2-ID | MS-Length... 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | MS-Length | Data... 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Code 664 2 - Response 666 Identifier 668 The Identifier field is one octet and aids in matching responses with 669 requests. The value is the Identifier of the received Failure packet 670 to which this packet responds. 672 Length 674 The Length field is two octets and indicates the length of the EAP 675 packet including the Code, Identifier, Length, Type, OpCode, MS- 676 CHAPv2-ID, MS-Length and Data fields. Octets outside the range of 677 the Length field should be treated as Data Link Layer padding and 678 should be ignored on reception. For the Change Password packet, the 679 length = 591. 681 Type 683 26 - EAP MS-CHAP-V2 685 OpCode 687 7 - Change Password 689 MS-CHAPv2-ID 691 The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 692 responses with requests. Typically, the MS-CHAPv2-ID field is the 693 same as the Identifier field. 695 MS-Length 697 The MS-Length field is two octets and MUST be set to the value of the 698 Length field minus 5. 700 Data 702 The Data field is 582 octets in length, and is subdivided as follows: 704 516 octets : Encrypted-Password 705 16 octets : Encrypted-Hash 706 16 octets : Peer-Challenge 707 8 octets : Reserved 708 24 octets : NT-Response 709 2-octet : Flags 711 Encrypted-Password 713 The Encrypted-Password field is 516 octets in length, and contains 714 the PWBLOCK form of the new Windows NT password encrypted with the 715 old Windows NT password hash, as output by the 716 NewPasswordEncryptedWithOldNtPasswordHash() routine defined in 717 [RFC2759], Section 8.9. 719 Encrypted-Hash 721 The Encrypted-Hash field is 16 octets in length and contains the old 722 Windows NT password hash encrypted with the new Windows NT password 723 hash, as output by the 724 OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine, defined in 725 [RFC2759], Section 8.12. 727 Peer-Challenge 729 The Peer-Challenge field is 16 octets in length, and contains a 730 16-octet random quantity, as described in the Response packet 731 description. 733 Reserved 735 8 octets, must be zero. 737 NT-Response 739 The NT-Response field is 24 octets in length and is as described in 740 the Response packet description. However it is calculated on the new 741 password and the challenge received in the Failure packet. 743 Flags 745 The Flags field is two octets in length. It is a bit field of option 746 flags where 0 is the least significant bit of the 16-bit quantity. 747 The format of this field is illustrated in the following diagram: 749 1 750 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Bits 0-15 756 Reserved, always clear (0). 758 2.8. Alternative failure behavior 760 Rather than sending a Failure Request as described in Section 2.5, if 761 the error is non-retryable (e.g. R=0), or if the maximum number of 762 retries has been exhausted, then the Authenticator MAY terminate the 763 authentication conversation. Where EAP MS-CHAP-V2 is running 764 standalone (e.g. without PEAP), this will result in transmission of 765 an EAP Failure message to the authenticator. Since EAP Failure 766 packets do not carry additional data, no error message may be 767 transmitted to the peer. 769 2.9. Known bugs 771 In Windows XP SP1, Failure Request packets are only sent where the 772 error is retryable (R=1). Rather than sending a Failure Request with 773 a non-retryable error (R=0), a Windows XP SP1 authenticator will 774 terminate authentication. This is undesirable, because it prevents 775 non-retryable error messages from being received by the peer. A 776 Windows XP SP1 host, on receiving a Failure Request packet with a 777 non-retryable error (R=0), will silently discard the packet. 779 Since a Windows XP SP1 peer will respond to a retryable (R=1) Failure 780 Request by retrying authentication (such as by sending a Response or 781 Change-Password packet), and non-retryable (R=0) Failure Requests are 782 silently discarded, Windows XP SP1 peers do not send Failure Response 783 packets. If a Windows XP SP1 authenticator receives a Failure 784 Response packet, it will be silently discarded. 786 3. Security Claims 788 EAP security claims are defined in [RFC3748] Section 7.2.1. Using 789 the terms defined there, the security properties of the Microsoft EAP 790 MS-CHAP-v2 protocol are as follows: 792 Auth. mechanism: Password 793 Ciphersuite negotiation: No 794 Mutual authentication: Yes 795 Integrity protection: Yes 796 Replay protection: Yes 797 Confidentiality: No 798 Key derivation: Yes 799 Key strength: Depends on password policy 800 Dictionary attack prot.: No 801 Fast reconnect: No 802 Crypt. binding: N/A 803 Session independence: Depends on password policy 804 Fragmentation: No 805 Channel binding: No 807 The Microsoft EAP MS-CHAP-v2 protocol is based on MS-CHAP-v2 as 808 defined in [RFC2759]. MS-CHAP-v2 is a password-based authentication 809 method that supports mutual authentication. While backward 810 compatibility with MS-CHAP-v1 is supported, this does not really 811 constitute a protected ciphersuite negotiation, since the 812 cryptographic algorithms are largely fixed. 814 Integrity and replay protection are supported. As described in 815 Section 2.2, the NT-Response field is an encoded function of the 816 password, the Name field of the Response packet, the contents of the 817 Peer-Challenge field and the received Challenge. The inclusion of 818 both the Peer-Challenge and received challenge provides replay 819 protection. Fields within the EAP header (Code, Identifier, Length, 820 Type) are not protected. 822 Confidentiality is not supported; the Name field in both the 823 Challenge and Response packets are sent in the clear. 825 While Key Derivation is supported, the key strength is limited by the 826 password policy. As noted in Section 2.2, in practice the password 827 may be limited to 14 octets. If these octets are randomly chosen 828 from the ASCII character set, then an effective key strength of 98 829 bits can be obtained. However, if the octets are only chosen from an 830 English language dictionary, then an effective key strength of 2.2 831 bits per octet or 31 bits will obtain. 833 Session independence also depends on password policy. Where the 834 password is weak, it may be obtained via dictionary attack, in which 835 case future and past keys can be calculated. However, if the 836 password is strong then the inclusion of nonces in both directions 837 provides for session independence, absent invalidation of a 838 cryptographic assumption. 840 As noted in [PPTPv1] and [PPTPv2], the MS-CHAP-v2 protocol is subject 841 to dictionary attack. It is advised that this method only be used 842 when protected from snooping by a tunnel method such as [PEAP]; this 843 will also mask potential key strength issues. 845 As the protocol exchanges fit within the minimum EAP MTU size defined 846 in [RFC3748], there is no need for fragmentation support. Fast 847 reconnect and Channel binding are not supported. 849 4. References 851 4.1. Normative references 853 [RFC1320] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 854 1992. 856 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol 857 (CHAP)", RFC 1994, August 1996. 859 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 860 Recommendations for Security", RFC 1750, December 1994. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997. 865 [RFC2433] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 866 2433, October 1998. 868 [RFC2484] Zorn, G., "PPP LCP Internationalization Configuration Option", 869 RFC 2484, January 1999. 871 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 872 2759, January 2000. 874 [RFC3748] Blunk, L., "Extensible Authentication Protocol (EAP)", RFC 875 3748, April 2004. 877 [RC4] RC4 is a proprietary encryption algorithm available under 878 license from RSA Data Security Inc. For licensing 879 information, contact: 880 RSA Data Security, Inc. 881 100 Marine Parkway 882 Redwood City, CA 94065-1031 884 [IEEE8021X] 885 IEEE Standards for Local and Metropolitan Area Networks: Port 886 Based Network Access Control, IEEE Std 802.1X-2001, June 2001. 888 [SHA1] "Secure Hash Standard", Federal Information Processing 889 Standards Publication 180-1, National Institute of Standards 890 and Technology, April 1995. 892 [UNICODE] "The Unicode Standard, Version 2.0", The Unicode Consortium, 893 Addison-Wesley, 1996. ISBN 0-201-48345-9. 895 4.2. Informative references 897 [RFC1570] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 898 1994. 900 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 901 1661, July 1994. 903 [DES] "Data Encryption Standard (DES)", Federal Information 904 Processing Standard Publication 46-2, National Institute of 905 Standards and Technology, December 1993. 907 [DESMODES] 908 "DES Modes of Operation", Federal Information Processing 909 Standards Publication 81, National Institute of Standards and 910 Technology, December 1980. 912 [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point 913 Encryption (MPPE)", RFC 3079, March 2001. 915 [PEAP] Palekar, A., et al., "Protected EAP Protocol (PEAP) Version 916 2", draft-josefsson-pppext-eap-tls-eap-08.txt, Internet draft 917 (work in progress), April 2004. 919 [PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's Point- 920 to- Point Tunneling Protocol", Proceedings of the 5th ACM 921 Conference on Communications and Computer Security, ACM Press, 922 November 1998. 924 [PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP 925 Authentication Extensions (MS-CHAPv2)", CQRE '99, Springer- 926 Verlag, 1999, pp. 192-203. 928 Appendix A - Examples 930 In the case where the EAP-MS-CHAP-V2 authentication is successful, 931 the conversation will appear as follows: 933 Peer Authenticator 934 ---- ------------- 935 <- EAP-Request/Identity 936 EAP-Response/ 937 Identity (MyID) -> 938 <- EAP-Request/ 939 EAP-Type=EAP MS-CHAP-V2 940 (Challenge) 941 EAP-Response/ 942 EAP-Type=EAP-MS-CHAP-V2 943 (Response)-> 944 <- EAP-Request/ 945 EAP-Type=EAP-MS-CHAP-V2 946 (Success) 947 EAP-Response/ 948 EAP-Type=EAP-MS-CHAP-V2 949 (Success) -> 950 <- EAP-Success 952 In the case where the EAP MS-CHAP-V2 authentication is unsuccessful, 953 due to a retryable error, the conversation will appear as follows 954 (assuming a maximum of two retries): 956 Peer Authenticator 957 ---- ------------- 958 <- EAP-Request/Identity 959 EAP-Response/ 960 Identity (MyID) -> 961 <- EAP-Request/ 962 EAP-Type=EAP MS-CHAP-V2 963 (Challenge) 964 EAP-Response/ 965 EAP-Type=EAP-MS-CHAP-V2 966 (Response)-> 967 <- EAP-Request/ 968 EAP-Type=EAP-MS-CHAP-V2 969 (Failure, R=1) 970 EAP-Response/ 971 EAP-Type=EAP-MS-CHAP-V2 972 (Response) -> 973 <- EAP-Request/ 974 EAP-Type=EAP-MS-CHAP-V2 975 (Failure, R=1) 977 EAP-Response/ 978 EAP-Type=EAP-MS-CHAP-V2 979 (Response) -> 981 <- EAP-Failure 983 In the case where the EAP MS-CHAP-V2 authentication is unsuccessful, 984 due to a non-retryable error, the conversation will appear as follows 985 (Windows XP SP1): 987 Peer Authenticator 988 ---- ------------- 989 <- EAP-Request/Identity 990 EAP-Response/ 991 Identity (MyID) -> 992 <- EAP-Request/ 993 EAP-Type=EAP MS-CHAP-V2 994 (Challenge) 995 EAP-Response/ 996 EAP-Type=EAP-MS-CHAP-V2 997 (Response)-> 998 <- EAP-Failure 1000 In the case where the EAP MS-CHAP-V2 authentication is unsuccessful, 1001 due to a non-retryable error, and a Failure Request packet is sent, 1002 the conversation will appear as follows (behavior not exhibited by 1003 Windows XP SP1): 1005 Peer Authenticator 1006 ---- ------------- 1007 <- EAP-Request/Identity 1008 EAP-Response/ 1009 Identity (MyID) -> 1010 <- EAP-Request/ 1011 EAP-Type=EAP MS-CHAP-V2 1012 (Challenge) 1013 EAP-Response/ 1014 EAP-Type=EAP-MS-CHAP-V2 1015 (Response)-> 1016 <- EAP-Request/ 1017 EAP-Type=EAP MS-CHAP-V2 1018 (Failure, R=0) 1019 EAP-Response/ 1020 EAP-Type=EAP-MS-CHAP-V2 1021 (Failure)-> 1022 <- EAP-Failure 1024 In the case where the EAP MS-CHAP-V2 authentication is initially 1025 unsuccessful due to password expiration, but the subsequent Change 1026 Password operation succeeds, the conversation will appear as follows: 1028 Peer Authenticator 1029 ---- ------------- 1030 <- EAP-Request/Identity 1031 EAP-Response/ 1032 Identity (MyID) -> 1033 <- EAP-Request/ 1034 EAP-Type=EAP MS-CHAP-V2 1035 (Challenge) 1036 EAP-Response/ 1037 EAP-Type=EAP-MS-CHAP-V2 1038 (Response)-> 1039 <- EAP-Request/ 1040 EAP-Type=MS-CHAP-V2 1041 (Failure, R=1, 1042 Message=ERROR_PASSWD_EXPIRED (E=648)) 1043 EAP-Response/ 1044 EAP-Type=EAP-MS-CHAP-V2 1045 (Change-Password) -> 1046 <- EAP-Request/ 1047 EAP-Type=MS-CHAP-V2 1048 (Success) 1049 EAP-Response/ 1050 EAP-Type=EAP-MS-CHAP-V2 1051 (Success) -> 1052 <- EAP-Success 1054 In the case where the EAP MS-CHAP-V2 authentication is unnsuccessful 1055 due to password failure and a successful retry occurs, the 1056 conversation appears as follows: 1058 Peer Authenticator 1059 ---- ------------- 1060 <- EAP-Request/Identity 1061 EAP-Response/ 1062 Identity (MyID) -> 1063 <- EAP-Request/ 1064 EAP-Type=EAP MS-CHAP-V2 1065 (Challenge) 1066 EAP-Response/ 1067 EAP-Type=EAP-MS-CHAP-V2 1068 (Response)-> 1069 <- EAP-Request/ 1070 EAP-Type=MS-CHAP-V2 1071 (Failure, R=1, 1072 Message=ERROR_AUTHENTICATION_FAILURE (E=691) 1074 EAP-Response/ 1075 EAP-Type=EAP-MS-CHAP-V2 1076 (Response)-> 1077 <- EAP-Request/ 1078 EAP-Type=MS-CHAP-V2 1079 (Success) 1080 EAP-Response/ 1081 EAP-Type=EAP-MS-CHAP-V2 1082 (Success) -> 1083 <- EAP-Success 1085 Acknowledgments 1087 Thanks to Vivek Kamath, Mark Wodrich and Narendra Gidwani for 1088 discussions, comments and text relating to this document. 1090 Authors' Addresses 1092 Vivek Kamath 1093 Ashwin Palekar 1094 Microsoft Corporation 1095 One Microsoft Way 1096 Redmond, WA 98052 1098 EMail: {vivek, ashwinp}@microsoft.com 1099 Phone: +1 425 882 8080 1100 Fax: +1 425 936 7329 1102 Full Copyright Statement 1104 Copyright (C) The IETF Trust (2007). 1106 This document is subject to the rights, licenses and restrictions 1107 contained in BCP 78, and except as set forth therein, the authors 1108 retain all their rights. 1110 This document and the information contained herein are provided on an 1111 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1112 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1113 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1114 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1115 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1116 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1118 Intellectual Property 1120 The IETF takes no position regarding the validity or scope of any 1121 Intellectual Property Rights or other rights that might be claimed to 1122 pertain to the implementation or use of the technology described in 1123 this document or the extent to which any license under such rights 1124 might or might not be available; nor does it represent that it has 1125 made any independent effort to identify any such rights. Information 1126 on the procedures with respect to rights in RFC documents can be 1127 found in BCP 78 and BCP 79. 1129 Copies of IPR disclosures made to the IETF Secretariat and any 1130 assurances of licenses to be made available, or the result of an 1131 attempt made to obtain a general license or permission for the use of 1132 such proprietary rights by implementers or users of this 1133 specification can be obtained from the IETF on-line IPR repository at 1134 http://www.ietf.org/ipr. 1136 The IETF invites any interested party to bring to its attention any 1137 copyrights, patents or patent applications, or other proprietary 1138 rights that may cover technology that may be required to implement 1139 this standard. Please address the information to the IETF at ietf- 1140 ipr@ietf.org. 1142 Acknowledgment 1144 Funding for the RFC Editor function is provided by the IETF 1145 Administrative Support Activity (IASA).