Password Based EAP Method

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)