EAP Working Group
INTERNET-DRAFT H. Mancini
<draft-mancini-pppext-eap-ldap-00.txt> 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 <draft-mancini-pppext-eap-ldap-00.txt>, and
expires December 23, 2003.
Mancini Internet Draft [page 7]