1 / 8

Password Based EAP Method

Password Based EAP Method. Design team Update IETF 68 Prague March, 2007. Design Team Members. Mohamad Badra Ray Bell Charles Clancy Vijay Devarapalli Jouni Malinen Madjid Nakhjiri Joe Salowey Hannes Tschofenig Pascal Urien Hao Zhou . MUST Support/Provide Requirements.

carolynbtaylor
Download Presentation

Password Based EAP Method

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. Password Based EAP Method Design team Update IETF 68 Prague March, 2007

  2. Design Team Members • Mohamad Badra • Ray Bell • Charles Clancy • Vijay Devarapalli • Jouni Malinen • Madjid Nakhjiri • Joe Salowey • Hannes Tschofenig • Pascal Urien • Hao Zhou

  3. MUST Support/Provide Requirements • Transport of encrypted password for support of legacy user data/ password databases • Mutual authentication (Server authentication) • Resistance to offline dictionary attacks, man in the middle attacks, and replay attacks. • RFC 3748, RFC 4017 compliant, compliant with EAP-Keying draft (includes MSK and EMSK generation) • Active User identity confidentiality for the peer • Crypto-agility/ cipher suite negotiation (need to define mandatory supported ciphers) • Session Resumption (No new passwords for resumption) • Fragmentation and reassembly

  4. Requirement Open Issues (MUST vs. Should Support?) • Password/pin change • Other password based protocols (CHAP, MSCHAP, etc) • Cryptographic binding of password exchange keys to keys of the protection layer • Extension Mechanism (data exchanges inside tunnel) • Transport of channel binding data • Protected result indication • OCSP for cert-based “server authentication”

  5. Direction we are leaning towards: Use TLS TLS provides: • Protected data (e.g. password) exchanges • Server authentication • Avoids documented MITM attacks on server-un-authenticated tunnels • OCSP requirement support should provide additional robustness • Cipher suite negotiation capability • Crypto-agility support (TLS 1.2) How to Use TLS? • Approach 1: Use TLS tunnel • Establish a TLS tunnel and exchange password authentication related data within tunnel. • Approach 2: TLS "native" - new TLS cipher suites and key exchanges extensions to allow for use of client passwords (needs TLS WG buy-in)

  6. How to use TLS?DT agrees on TLS tunneled approach, because • Fair amount of previous work available: (PEAPv2/TTLSv1/EAP-FAST) • Easier extensibility, Similar approach can be easily used for other authentication mechanisms (CHAP, MS-CHAP) • Allows use of externally available TLS libraries without interdependency to TLS library developers • Can be done within EMU WG

  7. Data formats alternatives discussed • XDR: external data representation, RFC 1832 • Used in TLS protocol (RFC2246) • AVP: a flat tree structure to represent a list of attributes, • ASN.1: Abstract Syntax Notation One: ISO standard: A structured tree. • Used for X.509, SNMP and LDAP • The team Agrees to use AVPs • XDR and ASN.1 ruled out due to high cost/benefit.

  8. Design Open issues • EAP method type • Use one method type for all non-cert credentials • Requires method negotiation. Inside or outside TLS tunnel? • Use one method type for passwords only • Do we need messaging framework or just TLVs • TLVs for passing PAP data (Username/Password) • More elaborate message exchange (e.g. to support password/ PIN changes)

More Related