1 / 23

802.11 and Alternative Authentication Protocols

802.11 and Alternative Authentication Protocols. David Jablon Phoenix Technologies. Introduction. In a Jan 20 Letter to IETF, TGi identified a range of requirements for authenticated key agreement methods.

bernie
Télécharger la présentation

802.11 and Alternative Authentication Protocols

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. 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

More Related