80 likes | 85 Views
This draft proposes a solution to authenticate service identities in EAP, preventing NAS impersonation and enhancing security in authentication protocols. It introduces channel bindings and a method-independent container for identifiers.
E N D
Authenticated service identities for EAP (draft-arkko-eap-service-identity-auth-00) Jari ArkkoPasi Eronen EAP WG, IETF 60
Background • EAP does not have a concept of service (NAS) identity (identifier) • Since there’s no identitifier, it’s not authenticated to the client • This leads to a ”2.5 party protocol” • Client is talking to some NAS trusted by the AAA server • Trivial consequence: compromised NAS can impersonate any other NAS EAP WG, IETF 60
Solution • Part 1: Channel bindings • Send integrity-protected identifier inside EAP method • Part 2: AAA server verifies that this identifier “belongs” to the node it’s sending MSK to EAP WG, IETF 60
Questions • What identifier? • SSID • BSSID • AP IP address • AP DNS name • Human-readable “network name” • Which direction? EAP WG, IETF 60
This draft • Method-independent, extensible container for service identifiers • Identifiers for some EAP lower layers • 802.11, PPP, PANA, IKEv2 • AVPs to send this container in some EAP methods • EAP-TLS, PEAPv2, EAP-SIM, EAP-AKA EAP WG, IETF 60
Example: Identifiers for 802.11 • Service_Type = IEEE 802.11i • Service_Provider = “Joe’s Coffee Shop, Heathrow airport, London, UK” • 802_11_SSID = joecoffee • 802_11_BSSID = 11:22:33:44:55:66 • 802_11_Protection_Mechanism = 802.11i EAP WG, IETF 60
Example: EAP-TLS • Add extension to ClientHello & ServerHello messages EAP WG, IETF 60
What next? • Comment welcome! EAP WG, IETF 60