draft-kamath-pppext-eap-mschapv2-00.txt

来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,441 行 · 第 1/3 页

PPPEXT Working Group                                        Vivek Kamath
INTERNET-DRAFT                                            Ashwin Palekar
Category: Informational                                        Microsoft
<draft-kamath-pppext-eap-mschapv2-00.txt>
2 September 2002


                     Microsoft EAP CHAP Extensions

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

This 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 2002


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements language ...........................    3
   1.2       Terminology .....................................    3
2.     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 ......................................   17
3.  Normative references .....................................   18
4.  Informative references ...................................   19
Appendix A - Examples ........................................   20
Acknowledgments ..............................................   23
Author Addresses .............................................   23
Full copyright statement .....................................   23






























Kamath & Palekar              Informational                     [Page 2]





INTERNET-DRAFT                EAP MS-CHAPv2             2 September 2002


1.  Introduction

The Extensible Authentication Protocol (EAP), described in [RFC2284],
provides a standard mechanism for support of multiple authentication
methods.  Through the use of EAP, support for a number of authentication
schemes may be added, including smart cards, Kerberos, Public Key, One
Time 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 supports
mutual authentication and key derivation.  The way EAP-MSCHAPv2 derived
keys are used with the Microsoft Point to Point Encryption (MPPE) cipher
is described in [RFC3079].

EAP MS-CHAP-V2 provides mutual authentication between peers by
piggybacking a peer challenge on the Response packet and an
authenticator response on the Success packet.

1.1.  Requirements language

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].

1.2.  Terminology

This 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 2002


2.  EAP MS-CHAP-v2 Packet Format

A summary of the EAP MS-CHAP-V2 packet format is shown below.  The
fields 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 - Response

Identifier

   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-V2

OpCode

   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-Password




Kamath & Palekar              Informational                     [Page 4]





INTERNET-DRAFT                EAP MS-CHAPv2             2 September 2002


MS-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 packet

The Challenge packet is used to begin the EAP MS-CHAP-V2 protocol.  The
authenticator MUST transmit an EAP Request packet with Type=26, and the
OpCode field set to 1 (Challenge).  The format of the EAP MS-CHAP-v2
Challenge packet is shown below.  The fields 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   |  Challenge...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Challenge...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   1 - Request

Identifier

   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's



Kamath & 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-V2

OpCode

   1 - Challenge

MS-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/LF



Kamath & 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 packet

The format of the EAP MS-CHAP-v2 Response packet is shown below.  The
fields 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 - Response

Identifier

   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-V2

OpCode

   2 - Response





Kamath & Palekar              Informational                     [Page 7]





INTERNET-DRAFT                EAP MS-CHAPv2             2 September 2002


MS-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]