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

doc.: IEEE /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 needs. This presentation describes some needy areas and relevant work-in-progress.

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

doc.: IEEE /213r0 Submission March 2002 D Jablon/Phoenix Some classes of Alternative Authentication Methods for 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

doc.: IEEE /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

doc.: IEEE /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

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

doc.: IEEE /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.)

doc.: IEEE /213r0 Submission March 2002 D Jablon/Phoenix Password authenticated key exchange Relevant Standards IEEE P –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

doc.: IEEE /213r0 Submission March 2002 D Jablon/Phoenix P Focus Password-based public-key techniques –Balanced key agreement schemes –Augmented key agreement schemes –Key retrieval schemes Discrete log and elliptic curve settings

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

doc.: IEEE /213r0 Submission March 2002 D Jablon/Phoenix P1363 Contact Information IEEE P1363 Web site – –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

doc.: IEEE /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

doc.: IEEE /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

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

doc.: IEEE /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.

doc.: IEEE /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

doc.: IEEE /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

doc.: IEEE /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.

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

doc.: IEEE /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

doc.: IEEE /213r0 Submission March 2002 D Jablon/Phoenix Open questions & next steps How to insure that EAP methods achieve appropriate objectives? How to coordinate , TGi needs and IETF efforts on an ongoing basis?

doc.: IEEE /213r0 Submission March 2002 D Jablon/Phoenix Contacts David Jablon IETF P1363 Working Group