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

david_jablon@phoenix.com+1 508 898 9024

IETF

www.ietf.org

P1363 Working Group

http://grouper.ieee.org/groups/1363