1. EMU BOF EAP Method Requirements Bernard Aboba Microsoft Thursday, November 10, 2005 IETF 64, Vancouver, CA

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

3. 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).”

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

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

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

7. Feedback?