EAP Key Framework Draft-ietf-eap-keying-01.txt IETF 58 Minneapolis, MN Bernard Aboba Microsoft

Document Status Just recently accepted as WG work item Normative statements relating to EAP copied to RFC 2284bis –Result: EAP methods no longer dependent on Key Framework document Substantial revisions in progress –Issue 180: Conversation overview section rewritten (-02) –Rewrites of other sections (e.g. SAs) likely in -02 –Threat model needed Challenges –What threats do we choose to address, which ones will we not address? –Separation of media-specific behavior from general principles

Currently Open Issues Issue 15: Key Distribution Insecure Issue 179: EAP PRF Issue 187: Service SAs

Security Issues Key Scoping “Correctness” in Fast Handoff & Context Transfer The lying NAS problem

Key Scoping AAA context is associated with a key Default scope for a AAA-Key is within a NAS –AAA protocols authenticate at NAS granularity Diameter, RADIUS don’t use the NAS Called- Station-Id as its identity Key is scoped to the physical NAS; can’t assume separate key cache for each “virtual NAS”, Called- station-Id, SSID, etc. –Client may not be able to recognize NAS scope without assistance from the lower layer In IEEE only the BSSID is announced in the Beacon/Probe Response, not the NAS-Identifier

“Correctness” in Fast Handoff & Context Transfer Definition of “Correct”: when the same state results as if the peer had authenticated with the AAA server Examples of “incorrect” transactions: –Peer authenticates with GUEST SSID derives a key, does successful fast handoff within same physical AP to the CARRIER SSID Result: Carrier sees an accounting record for GUEST which either doesn’t have an account, or it bills the wrong user –Peer authenticates to an AP, does fast handoff to same virtual AP in order to cause Session-Time variable to be reset. Clients gains unlimited network access. Solution –Need AAA attributes to allow key scope restriction Authorized SSIDs Authorized Called, Calling-Station-Ids “No Fast Handoff” or “No context transfer” attributes

The Lying NAS Problem NAS can provide different information to the peer and the Authentication Server –Fraud To peer: “I offer access to the Joe’s Hotspot” To AS: “I offer access to the CARRIER network” Fooling user into associating to a “free” network then charging for it –Spoofing To peer: “I’m AP57” To AS: “I’m AP59” Motivation: DoS on neighbor graph calculations

Solutions AAA agent checks –AAA agent (proxy, redirect, etc.) can see if NAS attributes match expected ones –Doesn’t prevent NAS from lying to the peer, only from lying to the AAA Logging –Peer and AS can log information sent by the NAS, if a dispute arises, can verify later –Useful only for forensics Key mixing –Peer and AS include attributes when calculating the AAA-Key –If NAS provides different info to Peer and AS, then Peer and NAS won’t be able to communicate –Only viable if relevant attributes are few and well defined, not easily extensible Method-specific binding –EAP method includes exchange of attributes between the peer and EAP server –Peer and EAP server compare the exchanged values with ones sent by the NAS –Examples: EAP Archie, PEAPv2

Questions?