80 likes | 190 Views
Authenticated service identities for EAP (draft-arkko-eap-service-identity-auth-01). Jari Arkko Pasi Eronen. Problem. Client. A. B. C. D. ZZZ. AAA server. Problem. Client. . A. B. C. D. ZZZ. AAA server. Problem. EAP does not have a concept of “service (or NAS) identity”
E N D
Authenticated service identities for EAP (draft-arkko-eap-service-identity-auth-01) Jari ArkkoPasi Eronen EAP WG, IETF 61
Problem Client A B C D ZZZ AAA server EAP WG, IETF 61
Problem Client A B C D ZZZ AAA server EAP WG, IETF 61
Problem • EAP does not have a concept of “service (or NAS) identity” • All identifiers come from the service itself EAP WG, IETF 61
Solution overview • AAA server tells the client: “I’m sending the AAA-Key to service X” EAP WG, IETF 61
Channel bindings? • Channel bindings (w/o authentication) • “I’m sending the AAA-Key to a box that claims to be X” • Authenticated service identities • “I’m sending the AAA-Key to a box I believe to be X” EAP WG, IETF 61
This draft • Method-independent, extensible framework for service identifiers • Identifiers for some EAP lower layers • Currently 802.11i and IKEv2 • No single right identifier; more can be added later • AVPs to send this container in some EAP methods • EAP-TLS, PEAPv2, EAP-SIM, EAP-AKA EAP WG, IETF 61
Next steps • Is this a relevant problem? • Relationship to handovers? • If the client wants to tell X and Y apart, both have to get their keys from the AAA server • And not from each other via some context transfer protocol EAP WG, IETF 61