EMU BOF

EAP Method Requirements

Bernard Aboba

Microsoft

Thursday, November 10, 2005

IETF 64, Vancouver, CA

EAP Method Requirements Input received

Liaison requests received from 3GPP, IEEE 802.11 3GPP dependencies on EAP SIM, AKA EAP SIM, AKA now in RFC Editor Queue IEEE 802.11 liaison request written up as RFC 4017

Work in progress Discussion of potential use of EAP in peer-to-peer

scenarios (IEEE 802.1af, IEEE 802.11s) Not clear that EAP will be used in these scenarios or that

new requests/requirements will come out of them

EAP Method Requirements for WLANs (RFC 4017)

Credential types (Section 2.1) “Wireless LAN deployments are expected to use

different credential types, including digital certificates, user-names and passwords, existing secure tokens, and mobile network credentials (GSM and UMTS secrets). Other credential types that may be used include public/private key (without necessarily requiring certificates) and asymmetric credential support (such as password on one side, public/private key on the other).”

RFC 4017 (cont’d) Mandatory Requirements

Key generation Key strength Mutual authentication Shared state equivalence Dictionary attack resistance Man-in-the-middle attack protection Protected ciphersuite negotiation

Recommended Requirements Fragmentation support Identity hiding

Optional Features Channel Binding Fast reconnect

RFC 4017 Progress Report Core mechanisms

Certificates EAP-TLS (RFC 2716) deployed

Usernames & Passwords – no widely deployed methods Secure Tokens

Several incompatible methods deployed (GTC, RSA, POTP) Mobile Network Credentials

EAP SIM, AKA in RFC Editor Queue Other mechanisms

Public/Private key (no certificates) – no widely deployed methods Asymmetric credentials (password/public key)

Several incompatible proposals (PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, etc.)

Not mentioned Usernames & Pre-shared keys

Multiple proposals, none widely deployed

Some Thoughts Basic usage scenarios still unsolved

Secure, small footprint mechanisms needed Likely to be deployed in consumer, small office scenarios

Single NAS deployments with no AAA server AAA servers targeted to small business EAP peer on embedded devices

EMU must resist draining the swamp Standardization of mechanisms in areas with many existing

proposals and IPR disclosures is seductive, but dangerous Likely to result in endless bickering, slow progress Yet anOther Method Absent MotivAtion (YOMAMA)

Doing one thing well better than trying everything, but failing

Feedback?