1 / 5

EAP-LDAP draft-mancini-pppext-eap-ldap-00.txt

EAP-LDAP draft-mancini-pppext-eap-ldap-00.txt. IETF 57 Avi Lior & Helena Mancini Bridgewater Systems. Background. Challenge-based authentication methods require the back-end server to hold the user’s password either in clear text or reversible encryption

cwelsh
Télécharger la présentation

EAP-LDAP draft-mancini-pppext-eap-ldap-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EAP-LDAPdraft-mancini-pppext-eap-ldap-00.txt IETF 57 Avi Lior & Helena Mancini Bridgewater Systems

  2. Background • Challenge-based authentication methods require the back-end server to hold the user’s password either in clear text or reversible encryption • Major drawback in particular for LDAP directories where the user password may be stored in SHA or CRYPT, for example • Need a means for supporting EAP challenge-based methods when the EAP server has no knowledge of, or access to, the user’s cleartext password

  3. Goals & Objectives • Allow for LDAP directories to maintain and continue provisioning one-way encrypted passwords • Allow for validation of the LDAP user without passing the cleartext password or the value stored in the LDAP directory • EAP-LDAPis a challenge-based authentication using MD5, in conjunction with the encryption algorithm used to store the password within the LDAP identity store • Recommend using EAP-LDAP in conjunction with tunneling EAP methods such as PEAP

  4. How it works • During EAP negotiation, upon receipt of user’s identity, EAP Server responds with EAP-LDAP request which specifies primary encryption type (the method used in the datastore to store passwords) and a challenge • EAP Client applies primary encryption type* to user’s password & replies with a challenge Response generated by applying MD5 on the user’s encrypted password and challenge (secondary encryption type, implicitly MD5) • EAP Server re-computes MD5-Challenge Response using user’s encrypted password and challenge

  5. Moving forward • Data Stores: This could be extended to any data store that is storing one-way encrypted passwords. Should this be generalized beyond LDAP directories? • Primary Encryption Method: Current algorithm, only speaks to unseeded methods (for example, SHA). Should seeded methods be dealt with? Can/Should the seed safely be communicated or known? • Secondary Encryption Method: Beyond using MD5 implicitly, is there a need to provide a means of negotiating other secondary types? • Proposal: We’d like to have the draft taken on as an EAP WG item

More Related