📄 draft-kamath-pppext-eap-mschapv2-00.txt
字号:
PPPEXT Working Group Vivek KamathINTERNET-DRAFT Ashwin PalekarCategory: Informational Microsoft<draft-kamath-pppext-eap-mschapv2-00.txt>2 September 2002 Microsoft EAP CHAP ExtensionsThis document is an Internet-Draft and is in full conformance with allprovisions of Section 10 of RFC 2026.Internet-Drafts are working documents of the Internet Engineering TaskForce (IETF), its areas, and its working groups. Note that other groupsmay also distribute working documents as Internet- Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as reference materialor to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txtThe list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.Copyright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved.AbstractThis document defines the Microsoft EAP CHAP Extensions Protocol,Version 2, which encapsulates the MS-CHAP-v2 protocol, defined in[RFC2759], within EAP.Kamath & Palekar Informational [Page 1]INTERNET-DRAFT EAP MS-CHAPv2 2 September 2002Table of Contents1. Introduction .......................................... 3 1.1 Requirements language ........................... 3 1.2 Terminology ..................................... 32. EAP MS-CHAP-v2 Packet Format .......................... 4 2.1. Challenge packet ................................ 5 2.2. Response packet ................................. 7 2.3. Success Request packet .......................... 9 2.4. Success Response packet ......................... 11 2.5. Failure Request packet .......................... 12 2.6. Failure Response packet ......................... 14 2.7. Change-Password packet .......................... 15 2.8. Alternative failure behavior .................... 17 2.9. Known bugs ...................................... 173. Normative references ..................................... 184. Informative references ................................... 19Appendix A - Examples ........................................ 20Acknowledgments .............................................. 23Author Addresses ............................................. 23Full copyright statement ..................................... 23Kamath & Palekar Informational [Page 2]INTERNET-DRAFT EAP MS-CHAPv2 2 September 20021. IntroductionThe Extensible Authentication Protocol (EAP), described in [RFC2284],provides a standard mechanism for support of multiple authenticationmethods. Through the use of EAP, support for a number of authenticationschemes may be added, including smart cards, Kerberos, Public Key, OneTime Passwords, and others.This document defines the Microsoft EAP CHAP Extensions Protocol,Version 2, which encapsulates the MS-CHAP-v2 protocol, defined in[RFC2759], within EAP. As with MS-CHAP-v2, EAP-MSCHAPv2 supportsmutual authentication and key derivation. The way EAP-MSCHAPv2 derivedkeys are used with the Microsoft Point to Point Encryption (MPPE) cipheris described in [RFC3079].EAP MS-CHAP-V2 provides mutual authentication between peers bypiggybacking a peer challenge on the Response packet and anauthenticator response on the Success packet.1.1. Requirements languageIn this document, several words are used to signify the requirements ofthe specification. These words are often capitalized. The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to beinterpreted as described in [RFC2119].1.2. TerminologyThis document frequently uses the following terms:Authenticator The end of the link requiring the authentication.Peer The other end of the point-to-point link; the end which is being authenticated by the authenticator.silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.Kamath & Palekar Informational [Page 3]INTERNET-DRAFT EAP MS-CHAPv2 2 September 20022. EAP MS-CHAP-v2 Packet FormatA summary of the EAP MS-CHAP-V2 packet format is shown below. Thefields are transmitted from left to right. 0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | OpCode | MS-CHAPv2-ID | MS-Length...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| MS-Length | Data...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 1 - Request 2 - ResponseIdentifier The Identifier field is one octet and aids in matching responses with requests.Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, OpCode, MS- CHAPv2-ID, MS-Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.Type 26 - EAP MS-CHAP-V2OpCode The OpCode field is one octet and identifies the type of EAP MS-CHAP- v2 packet. OpCodes are assigned as follows: 1 Challenge 2 Response 3 Success 4 Failure 7 Change-PasswordKamath & Palekar Informational [Page 4]INTERNET-DRAFT EAP MS-CHAPv2 2 September 2002MS-CHAPv2-ID The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 responses with requests. Typically, the MS-CHAPv2-ID field is the same as the Identifier field.MS-Length The MS-Length field is two octets and MUST be set to the value of the Length field minus 5.Data The format of the Data field is determined by the OpCode field.2.1. Challenge packetThe Challenge packet is used to begin the EAP MS-CHAP-V2 protocol. Theauthenticator MUST transmit an EAP Request packet with Type=26, and theOpCode field set to 1 (Challenge). The format of the EAP MS-CHAP-v2Challenge packet is shown below. The fields are transmitted from leftto right. 0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | OpCode | MS-CHAPv2-ID | MS-Length...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| MS-Length | Value-Size | Challenge...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Challenge...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Name...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 1 - RequestIdentifier The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. If a peer receives a duplicate Request for which it has already sent a Response, it MUST resend it'sKamath & Palekar Informational [Page 5]INTERNET-DRAFT EAP MS-CHAPv2 2 September 2002 Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request.Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, OpCode, MS- CHAPv2-ID, MS-Length, Value-Size, Challenge, and Name fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.Type 26 - EAP MS-CHAP-V2OpCode 1 - ChallengeMS-CHAPv2-ID The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 responses with requests. Typically, the MS-CHAPv2-ID field is the same as the Identifier field.MS-Length The MS-Length field is two octets and MUST be set to the value of the Length field minus 5.Value-Size This field is one octet and indicates the length of the Challenge field. Since EAP MS-CHAPv2 utilizes a 16 octet Challenge field, it is set to 0x10 (16 decimal).Challenge The Challenge field is 16 octets. The most significant octet is transmitted first. The Challenge MUST be changed each time a Challenge is sent.Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. The Name should not be NUL or CR/LFKamath & Palekar Informational [Page 6]INTERNET-DRAFT EAP MS-CHAPv2 2 September 2002 terminated. The size of the Name field is equal to Length - Value- Size - 10.2.2. Response packetThe format of the EAP MS-CHAP-v2 Response packet is shown below. Thefields are transmitted from left to right. 0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | OpCode | MS-CHAPv2-ID | MS-Length...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| MS-Length | Value-Size | Response...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Response...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Name...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 2 - ResponseIdentifier The Identifier field is one octet and contains the value included in the EAP Request to which it responds.Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, OpCode, MS- CHAPv2-ID, MS-Length, Value-Size, Response, and Name fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.Type 26 - EAP MS-CHAP-V2OpCode 2 - ResponseKamath & Palekar Informational [Page 7]INTERNET-DRAFT EAP MS-CHAPv2 2 September 2002MS-CHAPv2-ID The MS-CHAPv2-ID field is one octet and aids in matching MSCHAP-v2 responses with requests. Typically, the MS-CHAPv2-ID field is the same as the Identifier field.MS-Length The MS-Length field is two octets and MUST be set to the value of the Length field minus 5.Value-Size This field is one octet and indicates the length of the Response field. It is set to 0x31 (Decimal 49).Response The Response field is 49 octets. The most significant octet is transmitted first. It is sub-formatted as follows: 16 octets: Peer-Challenge 8 octets: Reserved, must be zero 24 octets: NT-Response 1 octet : Flags The Peer-Challenge field is a 16-octet random number. As the name implies, it is generated by the peer and is used in the calculation of the NT-Response field, below. Peers need not duplicate Microsoft's algorithm for selecting the 16-octet value, but the standard guidelines on randomness [RFC1750] SHOULD be observed. The NT-Response field is an encoded function of the password, the Name field of the Response packet, the contents of the Peer-Challenge field and the received Challenge as output by the routine GenerateNTResponse() defined in [RFC2759], Section 8.1. The Windows NT password is a string of 0 to (theoretically) 256 case- sensitive Unicode [UNICODE] characters. Current versions of Windows NT limit passwords to 14 characters, mainly for compatibility reasons; this may change in the future. When computing the NT- Response field contents, only the user name is used, without any associated Windows NT domain name. This is true regardless of whether a Windows NT domain name is present in the Name field (see below). The Flag field is reserved for future use and MUST be zero.Kamath & Palekar Informational [Page 8]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -