1 / 8

Addressing Service Identities in EAP: An Authenticated Framework for AAA Servers

This draft presents a comprehensive framework to address the lack of defined service identities in Extensible Authentication Protocol (EAP). It highlights the critical need for authenticated service identities within EAP, allowing clients to securely communicate with services while retrieving keys from an Authentication, Authorization, and Accounting (AAA) server. The draft proposes a method-independent approach, adaptable to various EAP methods, including EAP-TLS, PEAPv2, EAP-SIM, and EAP-AKA. Future discussions will focus on the relevance of these changes and their impact on handover processes.

noam
Télécharger la présentation

Addressing Service Identities in EAP: An Authenticated Framework for AAA Servers

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. Authenticated service identities for EAP (draft-arkko-eap-service-identity-auth-01) Jari ArkkoPasi Eronen EAP WG, IETF 61

  2. Problem Client A B C D ZZZ AAA server EAP WG, IETF 61

  3. Problem Client  A B C D ZZZ AAA server EAP WG, IETF 61

  4. Problem • EAP does not have a concept of “service (or NAS) identity” • All identifiers come from the service itself EAP WG, IETF 61

  5. Solution overview • AAA server tells the client: “I’m sending the AAA-Key to service X” EAP WG, IETF 61

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

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

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

More Related