1 / 7

EMU BOF

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

tim
Download Presentation

EMU BOF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related