802.11 and Alternative Authentication Protocols

1. 802.11 and Alternative Authentication Protocols David Jablon Phoenix Technologies D Jablon/Phoenix

2. Introduction • In a Jan 20 Letter to IETF, TGi identified a range of requirements for authenticated key agreement methods. • TGi has tasked an emerging IETF EAP WG with the job of furthering EAP standards to support 802.11 needs. • This presentation describes some needy areas and relevant work-in-progress. D Jablon/Phoenix

3. Outline • Some classes of Alternative Authentication Methods for 802.11 • Password-authenticated key exchange protocols • Key retrieval protocols • Pairing protocols • Relevant other standards • IEEE 1363, and IETF work • Need for these alternatives in 802.11 environments • Easier and safer ESS, BSS, and IBSS authentication • Fit with current framework • Open issues & next steps D Jablon/Phoenix

4. Some classes of Alternative Authentication Methods for 802.11 • Password-authenticated key exchange protocols • a.k.a. “strong password protocols” • e.g. EKE, SPEKE, SRP • Key retrieval protocols • e.g. Ford & Kaliski • Pairing protocols D Jablon/Phoenix

5. Password authenticated key exchange protocols • Proves password without revealing it • zero knowledge password proof • prevents unconstrained network brute-force attack • Strong cryptography with no PKI, no certs, no keys • just a password • Mutual authentication • Key negotiation • Requirements • Asymmetric cryptography (e.g. variants of DH) • At least two messages, one in each direction • Same minimum of 3 message explicit mutual authentication • Client & server support D Jablon/Phoenix

6. How a PAKE works Enter password PAKE client Password database PAKE protocol PAKE server Session key App. client Encryptsession App. server D Jablon/Phoenix

7. Key Retrieval Protocols • Password-based retrieval of remotely stored credentials • Kick-start for PKI / key / cert methods D Jablon/Phoenix

8. Pairing Protocols • Other neat tricks to “authenticate strangers” • (Don’t ask. It’s not my primary focus today.) D Jablon/Phoenix

9. Password authenticated key exchange Relevant Standards • IEEE P1363.2 • A new standard for password-based cryptography • Focus on Password-based public-key techniques • Product of IEEE 1363 WG • Defines versions of • AMP, PAK, SPEKE, SRP • IETF • RFC 2945: SRP D Jablon/Phoenix

10. P1363.2 Focus • Password-based public-key techniques • Balanced key agreement schemes • Augmented key agreement schemes • Key retrieval schemes • Discrete log and elliptic curve settings D Jablon/Phoenix

11. P1363.2 Rationale • People are useful entities • Passwords are ubiquitous authenticators • People have trouble with high-grade keys • Storage (memorizing) • Input (attention to detail) • Output (typing) • Need for optimal password techniques • Avoid tradeoffs of security for convenience D Jablon/Phoenix

12. P1363 Contact Information • IEEE P1363 Web site • http://grouper.ieee.org/groups/1363 • Publicly accessible research contributions and document submissions • Two mailing lists • General announcements list • Technical discussion list • Open tradition – easy to participate • web site contains subscription information D Jablon/Phoenix

13. Some of the PAKE Internet Drafts • draft-ietf-tls-srp-01.txt Summary • Using SRP for TLS Authentication • draft-ietf-sacred-protocol-bss-02.txt • Securely Available Credentials Protocol • draft-black-ips-iscsi-security-01.txt • iSCSI Security Requirements and SRP-based ESP Keys • draft-ietf-pppext-eap-srp-03.txt • PPP EAP SRP-SHA1 Authentication Protocol • draft-jablon-speke-00.txt • The SPEKE Password-Based Key Agreement Methods D Jablon/Phoenix

14. Differences of SRP-4 vs. SRP-3 • Discussed in draft-jablon-speke-00.txt • Addresses IETF IPStorage WG open IP questions • {?, ?}  {No, Yes} • Extensible to alternate groups • EC settings • No two-for-one guessing • D. Bleichenbacher, M. Scott: SRP-3 limitation D Jablon/Phoenix

15. Need for these alternatives in802.11 environments • Enterprise deployment • Standalone AP deployment • Station-to-station deployment D Jablon/Phoenix

16. Enterprise deployment • PAKE provides end-to-end protection • Client  Authentication server • Password security with fewer requirements • Less dependent on key & certificate deployment • Less dependent on proper user action & attention • Scales to eliminate all password crackable data • No clear or hashed passwords on intermediate nodes. • No client-stored password-crackable keys • Business opportunity: RADIUS upgrades, etc. D Jablon/Phoenix

17. Standalone AP deployment • Asymmetric crypto is essential for security • Needed for secure password-based protocols • e.g. Halevi & Krawczyk ‘99 – one model & proof • Often deployed for same purpose as Enterprise deployment • Standalone deployment occurs within Enterprise networks • Difference in deployment & management model between point solution & workgroup settings is orthogonal to motivations for use. • Scalable security • Rapid deployment, flexibility • Safe environmental succession to Enterprise management D Jablon/Phoenix

18. Station-to-station deployment • Asymmetric crypto seems essential for security & convenience • Different cases favor different methods • Strong password protocols • pre-arranged secret • Ad-hoc connection protocols • no pre-arranged secret D Jablon/Phoenix

19. Fit with EAP framework • EAP-TLS + TLS-SRP, … • EAP-SRP, EAP-SPEKE, … • Potentially simpler alternatives? • Good discussion topic for EAP WG. D Jablon/Phoenix

20. Fit with EAP Framework SPEKE, SRP Method Layer SPEKE, SRP TLS EAP APIs EAP EAP Layer NDIS APIs Media Layer PPP 802.3 802.5 802.11 (Adapted from 11-01-658r0-I-Shared-Use-APs.ppt, Barkley, Moore & Aboba) D Jablon/Phoenix

21. Value of 802.1X approach • Less work for Tgi, of course • No “special status” for specific 802.1X methods • Lets the market decide • Encourages evolution as needed • Process should work fine, IF: • IETF is not overtly hostile to technical goals of specific EAP scenarios, when patents appear to be needed to achieve such goals D Jablon/Phoenix

22. Open questions & next steps • How to insure that EAP methods achieve appropriate objectives? • How to coordinate 802.11, TGi needs and IETF efforts on an ongoing basis? D Jablon/Phoenix

23. Contacts David Jablon david_jablon@phoenix.com+1 508 898 9024 IETF www.ietf.org P1363 Working Group http://grouper.ieee.org/groups/1363 D Jablon/Phoenix