[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                          D. Potter
INTERNET-DRAFT                                                 J. Zamick
Category: Informational                                    Cisco Systems
                                                            January 2002


                  PPP EAP MS-CHAP-V2 Authentication Protocol
                   <draft-dpotter-pppext-eap-mschap-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. 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 made obsolete 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 may be found at
   http://www.ietf.org/ietf/1id-abstracts.txt

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

1.  Abstract

   This document specifies an Extensible Authentication Protocol (EAP)
   mechanism for authentication using the Microsoft Challenge-Handshake
   Authentication Protocol (Version 2).

   MS-CHAP-v2 provides authentication functionality consistent
   with LAN-based methods including password change sequences. Mutual
   authentication is provided for by the inclusion of an authenticator
   packet returned to the client after a successful server
   authentication.

2.  Introduction

   Prior to EAP [3] network access support for a specific authentication
   protocol had to be engineered in at least three places, the peer,
   the access device (AAA client) and the AAA server. EAP has
   significantly simplified this scheme by making the password protocol
   'opaque' to the access device - support for EAP by an access device
   therefore infers support for all EAP types. The 802.1x protocol which




Potter, Zamick             Expires: July 2002                   [Page 1]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


   facilitates the deployment of user AAA on broadcast media networks
   such as wireless and Ethernet relies upon EAP as its password
   protocol vehicle as there is no point-to-point protocol negotiation
   as with conventional dial-in or VPN clients.

   EAP prescribes mandatory support for EAP-MD5-CHAP and whilst this
   has been used widely in the past, the implementational requirement
   for the back-end server to hold the users password either in clear
   text or a reversible encryption is seen as a potential drawback.

   EAP-TLS [2] is likely to achieve widespread adoption in the future,
   however there are currently issues over the cost and ease of
   deployment into existing network infrastructure.

   Another very widely used authentication protocol that is not
   currently addressed by EAP is MS-CHAP [6]. The lack of support for
   MS-CHAP in EAP significantly reduces the utility of EAP since MS-CHAP
   provides an additional facility for password change and expiry
   notification (aging).

   This document describes a method for encapsulating MS-CHAP v2 in EAP
   and extends MS-CHAP by allowing the peer to request a password change
   after a successful authentication.



2.1.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [4].

2.2   Definitions

   AAA Server
   Authentication, Authorisation and Accounting Server

   Authenticator
   Access device to which client desires connection

   EAP
   Extensible Authentication Protocol [3]

   EAP Server
   For the purpose of this document, see AAA Server

   Peer/Client
   Device (software or hardware) requiring access to/via the
   Authenticator.


Potter, Zamick             Expires: July 2002                   [Page 2]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


3.  Protocol overview

3.1.  Overview of the EAP-MS-CHAP-V2 Authentication

   As described in [3], the EAP-MS-CHAP-V2 conversation will typically
   begin with the authenticator and the peer negotiating EAP.  The
   authenticator will then typically send an EAP-Request/Identity
   packet to the peer, and the peer will respond with an
   EAP-Response/Identity packet to the authenticator, containing the
   clients userId.

   Unless otherwise stated, all EAP challenge/response messages MUST
   have an EAP-Type of EAP-MS-CHAP-V2. EAP Success and Failure messages
   have the EAP Message Code set to one of these values respectively.

   Upon receipt of the users identity the EAP Server MUST respond with
   a EAP-MS-CHAP-V2 Challenge request. The MS-CHAP Challenge as defined
   in [6] should be cryptographically random. The EAP Server remembers
   the challenge for later authentication of the computed MS-CHAP
   Response.

   The EAP Client MUST then reply with the MS-CHAP Response generated
   from the users credentials. The EAP Server re-computes the MS-CHAP
   Response, or devolves this operation to another back-end server. The
   EAP Server MUST then send an EAP Request with either MS-CHAP Success
   or MS-CHAP Failure packets depending on the result of the
   authentication.

   The EAP Server SHOULD ensure the MS-CHAP Response is actually a
   version 2 formatted response and not version 1. In the version 2
   packet the first 16 octets of the response contain a random challenge
   from the the client. The next 8 octets MUST be zero, otherwise the
   EAP Server SHOULD immediately send an EAP Failure message.

3.1.1 Successful Authentication

   If the MS-CHAP Response was valid the EAP Server MAY send the
   MS-CHAP Success packet, however it may apply other local policy
   conditions resulting in a rejection (see 3.1.2)

   To provide mutual authentication the MS-CHAP Success packet MUST be
   validated by the client as per 3.1.5. If the MS-CHAP Success packet
   is valid the client MUST send an EAP Response containing an Ack
   packet.

   The EAP server MUST then send an EAP-Success message to the
   client/peer. The EAP authentication is now complete.




Potter, Zamick             Expires: July 2002                   [Page 3]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


3.1.2 Failed Authentication (or Authorisation)

   If the MS-CHAP Response was invalid the EAP Server MUST send the
   MS-CHAP Failure packet indicating the rejection (MS-CHAP error code
   691 - ERROR_AUTHENTICATION_FAILURE)

   If the MS-CHAP Response was actually valid but the user has failed
   some other authorisation policy then the EAP Server MAY indicate one
   of other MS-CHAP failure codes:

      646 ERROR_RESTRICTED_LOGON_HOURS
      647 ERROR_ACCT_DISABLED
      649 ERROR_NO_DIALIN_PERMISSION

   Upon receipt of the MS-CHAP Failure packet the client MUST send an
   EAP Response containing the MS-CHAP Ack packet. After receiving an
   MS-CHAP Ack to the MS-CHAP Failure packet, the EAP server MUST then
   send an EAP-Failure message to the client/peer.

   The EAP authentication is now complete.

3.1.3 Password Expired

   If the users password has expired, the EAP Server MAY send an MS-CHAP
   Failure packet indicating that the users password has expired
   (MS-CHAP error code 648 - ERROR_PASSWD_EXPIRED). If the EAP Server
   does not support password change then it MUST send a failed
   authentication result instead (MS-CHAP error code 691 -
   ERROR_AUTHENTICATION_FAILURE).

   On receipt of the MS-CHAP Failure packet indicating that a password
   change is required, the client MUST send an EAP Response containing
   the MS-CHAP Ack packet.

   The EAP Server MUST then generate a new random challenge and issue
   an EAP Request containing an MS-CHAP Challenge packet.

   The client will then obtain a new password (in most cases directly
   from the user) and use the algorithms described in [6] to create a
   MS-CHAP Change Password packet. This is then sent in an
   EAP-Response message.

   The EAP Server will then process the MS-CHAP Change Password packet
   and MUST issue an MS-CHAP Success or Failure packet. If the password
   change was unsuccessful, the MS-CHAP Failure packet MUST indicate
   this using MS-CHAP error code 709 (ERROR_CHANGING_PASSWORD). The EAP
   Server MAY start a new password change sequence by formatting the
   MS-CHAP Failure packet to indicate password expiry (MS-CHAP error



Potter, Zamick             Expires: July 2002                   [Page 4]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


   code 648 - ERROR_PASSWD_EXPIRED).

   In response to the MS-CHAP Success or MS-CHAP Failure packets, the
   client MUST send an EAP Response containing the MS-CHAP Ack packet.
   Additionally, an MS-CHAP Success packet must be validated as
   per 3.1.5.

   If the password change sequence was successful, the EAP Server MUST
   then send an EAP-Success message. If the password change sequence was
   unsuccessful the EAP Server MUST send an EAP-Failure message. If the
   EAP Server had decided to start a new password change sequence then
   it MUST generate a new random challenge and issue an EAP Request
   containing an MS-CHAP Challenge packet.

3.1.4 Successful Authentication - Client Wishes to Change Password

   Upon receipt of the MS-CHAP Success packet (following a valid MS-CHAP
   authentication and validation of the Success packet as per 3.1.5) the
   client MAY optionally request that the users password is changed. In
   response to the MS-CHAP Success packet the client MAY send an EAP
   Response containing an MS-CHAP Failure packet indicating a password
   change is required (MS-CHAP error code 648 - ERROR_PASSWD_EXPIRED).

   The EAP Server MAY choose to honour the request, in which case it
   starts a password change sequence by creating a random challenge and
   sending an EAP Request with a MS-CHAP Challenge packet as per 3.1.3.
   This ultimately ends with the EAP Server sending an EAP-Success or
   EAP-Failure message depending on the result of the password change
   sequence.

   If the EAP Server does not support client requested password changes
   it MUST respond with an MS-CHAP Failure packet indicating the
   password change request has not been allowed (MS-CHAP error code
   709 - ERROR_CHANGING_PASSWORD). The Client MUST then respond with an
   Ack packet. Finally the EAP Server SHOULD send an EAP-Success
   message.

3.1.5 Mutual Authentication

   As described in [6] the MS-CHAP Success packet MUST be validated by
   the client in accordance with the algorithms described therein. If
   the Success packet is invalid the client MUST end the session.

3.2.  Fragmentation

   The maximum size of an EAP-MSCHAP-V2 record will be 586 bytes (during
   a password change conversation [6]) and therefore does not require a
   specific fragmentation scheme other than what is provided for in [8]



Potter, Zamick             Expires: July 2002                   [Page 5]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


3.3.  Session Encryption/Compression

   PPP [1] encryption and compression are catered for using MPPE-based
   methods [5,7,9]. In general terms the AAA/EAP server will generate an
   MPPE session key during the MSCHAP-v2 authentication process [7]. The
   MPPE key information is then returned to the Authenticator [5].

3.4.  Examples

   In the case where the EAP-MS-CHAP-V2 authentication is successful,
   the conversation will appear as follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Challenge)
   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Response)->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Success)

   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Ack) ->

                           <- PPP EAP-Success


   In the case where the EAP-MS-CHAP-V2 authentication not successful,
   the conversation will appear as follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Challenge)




Potter, Zamick             Expires: July 2002                   [Page 6]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Response)->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Failure = failed)

   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Ack) ->

                           <- PPP EAP-Failure


   In the case where the users password has expired, the conversation
   will appear as follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Challenge)
   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Response)->

                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Failure = password expired)

   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Ack) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Challenge)

   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Change Password)->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Success)




Potter, Zamick             Expires: July 2002                   [Page 7]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Ack) ->
                           <- PPP EAP-Success

   Note that the AAA/EAP Server may choose to re-iterate around the
   password change cycle if required, for example if the new password
   did not meet some password validation policy.


   In the case where the EAP-MS-CHAP-V2 authentication was successful,
   and the client wishes to change the users password, the conversation
   will appear as follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Challenge)
   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Response)->

                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Success)

   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Failure = password expired) ->

                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Challenge)

   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Change Password)->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-MS-CHAP-V2
                           (Success)
   PPP EAP-Response/
   EAP-Type=EAP-MS-CHAP-V2
   (Ack) ->
                           <- PPP EAP-Success


Potter, Zamick             Expires: July 2002                   [Page 8]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


4.  Detailed description of the EAP-MS-CHAP-V2 protocol

4.1.  PPP EAP MS-CHAP-V2 Packet Format

   A summary of the PPP EAP MS-CHAP-V2 Request/Response 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      |        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, 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

      29 - EAP MS-CHAP V2

   Data

      The format of the Data field is determined by the Code field.











Potter, Zamick             Expires: July 2002                   [Page 9]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


4.2.  PPP EAP MS-CHAP-V2 Request Packet

   A summary of the PPP EAP MS-CHAP-V2 Request 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      |  MS-CHAP Type |         MS-CHAP Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code

      1

   Identifier

      The Identifier field is one octet and aids in matching responses
      with requests.  The Identifier field MUST be changed on each
      Request packet.

   Length

      The Length field is two octets and indicates the length of the EAP
      packet including the Code, Identifier, Length, Type, MS-CHAP Type
      and MS-CHAP Data fields.

   Type

      29 - EAP MS-CHAP V2

   MS-CHAP Type

      This value defines the content of the MS-CHAP Data defined in [6]
      with the exception of Ack which is added for the purposes of
      synchronisation between the peer and the AAA/EAP Server.

      To aid clarity the RADIUS VSA names from [5] are given in
      parenthesis.

      0 for Ack - length of MS-CHAP data is 0
      1 for Challenge Packet (MS-CHAP-Challenge)
      2 for Success Packet (MS-CHAP2-Success)
      3 for Failure Packet (MS-CHAP-Error)




Potter, Zamick             Expires: July 2002                  [Page 10]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


   MS-CHAP Data

      The MS-CHAP data consists of an encapsulated MS-CHAP-V2 packet as
      defined in [6]

4.3.  PPP EAP MS-CHAP-V2 Response Packet

   A summary of the PPP EAP MS-CHAP-V2 Response 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      | MS-CHAP Type  |         MS-CHAP Data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code

      2

   Identifier

      The Identifier field is one octet and MUST match the Identifier
      field from the corresponding request.

   Length

      The Length field is two octets and indicates the length of the
      EAP packet including the Code, Identifier, Length, Type, MS-CHAP
      Type and MS-CHAP Data fields.

   Type

      29 - EAP MS-CHAP V2

   MS-CHAP Type

      This value defines the content of the MS-CHAP Data defined in [6].
      To aid clarity the RADIUS VSA names from [5] are given in
      parenthesis.

      1 for Response Packet (MS-CHAP2-Response)
      2 for Change Password Packet (MS-CHAP-CPW + MS-CHAP-NT-Enc-PW)
      3 for Failure Packet (MS-CHAP-Error)




Potter, Zamick             Expires: July 2002                  [Page 11]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


5.  Security Considerations

   Various cryptanalysis have been published on MS-CHAP versions 1 and 2
   and most conclude that version 2 has overcome most of the weaknesses
   originally found in version 1. As noted in [6] a major issue is the
   use of weak passwords making the protocol more vulnerable to
   dictionary based attacks.

   Version rollback (to MSCHAP v1) is avoided by the EAP/AAA Server
   ensuring the format of the MS-CHAP response matches that defined
   in [6].

   Using a toolkit to generate cryptographically random challenges
   should also increase the overall security of the protocol.

   The use of MPPE for session keys will not be as strong as those
   generated by some other EAP protocols such as EAP-TLS.

6.  References

   [1]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, July 1994.

   [2]  Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol"
        RFC 2716, October 1999.

   [3]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
        RFC 2548, March 1999.

   [6]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
        RFC 2759, January 2000.

   [7]  Zorn, G., "MPPE Key Derivation",
        draft-ietf-pppext-mppe-keys-03, October 2000.

   [8]  Rigney, C, et al, "RADIUS Extensions",
        RFC 2869, June 2000.

   [9]  Zorn, G., Pall G., "Microsoft Point-To-Point Encryption (MPPE)
        Protocol", draft-ietf-pppext-mppe-04, October 1999.





Potter, Zamick             Expires: July 2002                  [Page 12]


INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002



7.  Acknowledgments

   Thanks to Chris Murray, Ilan Frenkel, John Schnizlein and Glen Zorn
   for their comments and help.

8.  Authors' Addresses

   Darran Potter
   Cisco Systems Ltd
   New Square Park
   Bedfont Lakes
   Middlesex, TW14 8HA
   UK

   EMail: dpotter@cisco.com


   John Zamick
   Cisco Systems Ltd
   New Square Park
   Bedfont Lakes
   Middlesex, TW14 8HA
   UK

   EMail: jzamick@cisco.com

























Potter, Zamick             Expires: July 2002                  [Page 13]

INTERNET-DRAFT               EAP MS-CHAP-V2                 January 2002


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/