EAP Working Group INTERNET-DRAFT H. Mancini Bridgewater Systems Expires: December 23, 2003 June 2003 EAP-LDAP Protocol 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. This Internet-Draft will expire on December 23, 2003. Abstract This document specifies an Extensible Authentication Protocol (EAP) mechanism for a challenge-based authentication using MD5 in conjunction with the hash algorithm used to store the password within an identity store. This document defines the EAP-LDAP method, which provides one-way authentication and MD5 key generation. As a result, the EAP-LDAP method, when used by it self, is only appropriate for use on networks where physical security can be assumed. These methods SHOULD NOT be used on wireless networks, or over the Internet, unless the EAP conversation is protected. This can be accomplished using technologies such as IPsec or TLS. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................1 Overview...........................................................2 Introduction.......................................................2 Mancini Internet Draft [page 1] EAP-LDAP Protocol June 2003 Requirements language..............................................3 Terminology........................................................3 Protocol Overview..................................................3 Overview of the EAP-LDAP Authentication............................3 Examples...........................................................4 Security Considerations............................................4 References.........................................................5 IANA Considerations................................................6 Intellectual Property Right Notices................................6 Acknowledgements...................................................6 Authors Addresses..................................................6 Expiration Date....................................................7 Overview EAP, defined in [RFC2284], is an authentication protocol, which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. While EAP was originally developed for use with PPP [RFC1661], it is also now in use with IEEE 802 [IEEE802]. The encapsulation of EAP on IEEE 802 link layers is defined in [IEEE8021X]. This document defines the EAP-LDAP method. Introduction EAP-LEAP and EAP-MD5-Challenge, among other EAP implementations, require the back-end server to hold the users password either in clear text or a reversible encryption. This is a major drawback in particular for LDAP directories where the user password may be stored in SHA or CRYPT, for example. The EAP-LDAP method provides a means for supporting other EAP methods when the EAP server has no knowledge of or access to the users cleartext password. For any unseeded method of encryption/hashing, this EAP method SHALL allow the user passwords to remain in their encrypted format and SHALL allow for validation of the LDAP user without passing the cleartext password or the value stored in the LDAP directory. This document describes a method for encapsulating the password encryption method used in the LDAP directory within EAP, while using EAP-MD5-Challenge as the final security measure. It is recommended that EAP-LDAP be used in conjunction with a tunneled authentication method, such as PEAP, to provide integrity protection, mutual authentication, and address most security vulnerabilities listed in the Security Considerations section. Mancini Internet Draft [page 2] EAP-LDAP Protocol June 2003 Requirements language 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 RFC-2119. Terminology AAA Server Authentication, Authorization 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 LDAP Lightweight Directory Access Protocol Peer/Client Device (software or hardware) requiring access to/via the Authenticator. Protocol Overview Overview of the EAP-LDAP Authentication The EAP-LDAP 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-LDAP. Upon receipt of the users identity the EAP Server MUST respond with an EAP-LDAP request. The EAP-LDAP request MUST contain an EAP-LDAP attribute that identifies the LDAP encryption type, such as SHA, CRYPT, NTLM, or PLAIN. The peer SHOULD then reply with an EAP-Response/EAP-Type=LDAP or NAK. Upon receipt of the EAP-Response/EAP-Type=LDAP the EAP Server SHALL send an EAP-MD5 challenge request. The challenge should be cryptographically random. The EAP Server remembers the challenge for later authentication of the computed MD5-Challenge Response. The EAP Client MUST then apply the LDAP encryption type to the users password and followed by applying the MD5 challenge. The EAP Client MUST then reply with the MD5-Challenge Response generated from the users encrypted credentials. Mancini Internet Draft [page 3] EAP-LDAP Protocol June 2003 The EAP Server then re-computes the MD5-Challenge Response using the users encrypted password. The EAP Server MUST then send an EAP Request with either MD5-Challenge Success or MD5-Challenge Failure packets depending on the result of the authentication. Examples In the case where the EAP-LDAP 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-LDAP (Challenge) PPP EAP-Response/ EAP-Type=EAP-LDAP (Response)-> <- PPP EAP-Request/ EAP-Type=EAP-LDAP (Success) PPP EAP-Response/ EAP-Type=EAP-LDAP (Ack) -> <- PPP EAP-Success In the case where the EAP-LDAP authentication is 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-LDAP (Challenge) PPP EAP-Response/ EAP-Type=EAP- LDAP (Response)-> <- PPP EAP-Request/ EAP-Type=EAP-LDAP (Failure = failed) PPP EAP-Response/ EAP-Type=EAP-LDAP (Ack) -> <- PPP EAP-Failure Security Considerations The revised EAP base protocol [RVC 2284bis] highlights several attacks that are possible against the EAP. This section discusses the claimed security properties of EAP-LDAP as well as vulnerabilities and security recommendations. It is recommended that Mancini Internet Draft [page 4] EAP-LDAP Protocol June 2003 EAP-LDAP be used in conjunction with a tunneled authentication method, such as PEAP. Intended use: EAP-LDAP is intended for use over both physically insecure networks and physically or otherwise secure networks. It is recommended that EAP-LDAP be used in conjunction with a tunneled authentication method, such as PEAP. Applicable media include but are not limited to PPP, IEEE 802 wired networks and IEEE 802.11. Mechanism: Double-encrypted password. EAP-LDAP is based on a primary password hash/encryption method, followed by a secondary MD5 challenge/response authentication. The primary password hash/encryption methods include but are not limited to SHA and CRYPT. Security claims. Identity Protection: No If the client and server cannot guarantee that the identity will be maintained reliably and identity privacy is required then additional protection from an external security mechanism such as Protected Extensible Authentication Protocol (PEAP) [PEAP] may be used. Mutual Authentication: No Key Derivation: No Key Strength: N/A Key Hierarchy: N/A Dictionary Attack Protection: Yes. The password is encrypted twice, first using an irreversible encryption method, and then secondly using MD5. Credentials Reuse: Yes Integrity Protection, Replay Protection and Confidentiality: No Negotiation Attacks Fast Reconnect: No Acknowledged Result Indications: No Man-in-the-middle Resistance: No Generating Random Numbers: No References [RFC2026]Bradner, S., ôThe Internet Standards Process -- Revision 3ö, RFC 2026, October 1996. [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [RFC2284bis] Blunk L., Vollbrecht, J., Aboba, B., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", draft-ietf-eap- rfc2284bis-02.txt (work-in-progress), January 2003. [PEAP] Andersson, H., Josefsson, S., Zorn, G., Simon, D., and A. Palekar, "Protected EAP Protocol (PEAP)", draft-josefsson-pppext- eap- tls-eap-05.txt, work-in-progress, September 2002. Mancini Internet Draft [page 5] EAP-LDAP Protocol June 2003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support For Extensible Authentication Protocol (EAP)", draft-aboba-radius- rfc2869bis-09 (work in progress), February 2003. IANA Considerations An application to IANA should be made for a new PPP Extensible Authentication Protocol (EAP) Type: EAP-LDAP Acknowledgements Thanks to Yong Li and Avi Lior (Bridgewater Systems) for their comments and help. Authors Addresses Helena Mancini Bridgewater Systems Corporation 303 Terry Fox Drive, Suite 100 Kanata, ON. Canada Email: helena.mancini@bridgewatersystems.com Intellectual Property Right Notices On IPR related issues, Bridgewater Systems Corporation and/or its affiliates hereby declare that they are in conformity with Section 10 of RFC 2026. Bridgewater Systems contributions may contain one or more patents or patent applications. To the extent Bridgewater Systems contribution is adopted to the specification, Bridgewater Systems undertakes to license patents technically necessary to implement the specification on fair, reasonable and nondiscriminatory terms based on reciprocity. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 Mancini Internet Draft [page 6] EAP-LDAP Protocol June 2003 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." Expiration Date This memo is filed as , and expires December 23, 2003. Mancini Internet Draft [page 7]