1. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 802.11 and Alternative Authentication Protocols David Jablon Phoenix Technologies

2. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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.

3. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

4. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

5. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

6. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix How a PAKE works PAKE server Enter password Password database App. server Encrypt session Session key App. client PAKE protocol PAKE client

7. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix Key Retrieval Protocols Password-based retrieval of remotely stored credentials Kick-start for PKI / key / cert methods

8. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix Pairing Protocols Other neat tricks to “authenticate strangers” –(Don’t ask. It’s not my primary focus today.)

9. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

10. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

11. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

12. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

13. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

14. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

15. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix Need for these alternatives in 802.11 environments Enterprise deployment Standalone AP deployment Station-to-station deployment

16. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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.

17. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

18. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

19. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix Fit with EAP framework EAP-TLS + TLS-SRP, … EAP-SRP, EAP-SPEKE, … Potentially simpler alternatives? Good discussion topic for EAP WG.

20. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix SPEKE, SRP Fit with EAP Framework EAPLayer MethodLayer EAPEAP TLSTLS MediaLayer NDISAPIs EAPAPIs PPP802.3802.5802.11 SPEKE, SRP (Adapted from 11-01-658r0-I-Shared-Use-APs.ppt, Barkley, Moore & Aboba)

21. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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

22. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 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?

23. doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix Contacts David Jablon david_jablon@phoenix.com +1 508 898 9024 IETF www.ietf.org P1363 Working Group http://grouper.ieee.org/groups/1363