Doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 802.11 and Alternative...
-
Upload
gladys-goodman -
Category
Documents
-
view
215 -
download
0
Transcript of Doc.: IEEE 802.11-02/213r0 Submission March 2002 D Jablon/Phoenix 802.11 and Alternative...
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
802.11 and Alternative Authentication Protocols
David JablonPhoenix Technologies
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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.
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
How a PAKE works
PAKE server
Enter passwordPassword
database
App. serverEncrypt
session
Session key
App. client
PAKE protocolPAKE
client
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
Key Retrieval Protocols
• Password-based retrieval of remotely stored credentials
• Kick-start for PKI / key / cert methods
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
Pairing Protocols
• Other neat tricks to “authenticate strangers”– (Don’t ask. It’s not my primary focus today.)
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
Need for these alternatives in802.11 environments
• Enterprise deployment• Standalone AP deployment• Station-to-station deployment
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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.
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
Fit with EAP framework
• EAP-TLS + TLS-SRP, …• EAP-SRP, EAP-SPEKE, …• Potentially simpler alternatives?• Good discussion topic for EAP WG.
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
SPEKE, SRPSPEKE, SRPSPEKE, SRPSPEKE, SRP
Fit with EAP Framework
EAPEAPLayerLayer
MethodMethodLayerLayer
EAPEAPEAPEAP
TLSTLSTLSTLS
MediaMediaLayerLayer
NDISNDIS
APIsAPIs
EAP EAP
APIsAPIs
PPPPPP 802.3802.3 802.5802.5 802.11802.11
SPEKE, SRPSPEKE, SRPSPEKE, SRPSPEKE, SRP
(Adapted from 11-01-658r0-I-Shared-Use-APs.ppt, Barkley, Moore & Aboba)
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
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?
March 2002
D Jablon/Phoenix
doc.: IEEE 802.11-02/213r0
Submission
Contacts
David Jablon
[email protected]+1 508 898 9024
IETF
www.ietf.org
P1363 Working Group
http://grouper.ieee.org/groups/1363