Internet DRAFT - draft-dpotter-pppext-eap-mschap
draft-dpotter-pppext-eap-mschap
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.
