Mutual Authentication Month Year doc.: IEEE 802.11-yy/xxxxr0 Mutual Authentication Date: 2011-08-28 Authors: Slide 1 Page 1 John Doe, Some Company

August 2011 doc.: IEEE 802.11-11/1145r2 Abstract This document provides a statement from the IEEE 802.11 Working Group on the topic of mutual authentication IEEE 802.11 WG

What is “Mutual Authentication” Process where each side is assured of the other side’s identity Each side possesses a credential (an uniquely identifying piece of information plus an identity) that is trusted, or can be trusted by the other Does not require that each side use the same credential as the other Authentication is accomplished by verification that the side claiming some identity possesses the unique information for that identity Thwarts man-in-the-middle attacks Typical (but not required) properties of mutual authentication protocols Non-repudiation Key generation

RSN Networks The common view of an RSN network involves 3 parties: a client, an AP, and a AAA server that speaks EAP Client authenticates to network via AAA server using EAP method AAA server sends resulting PMK to AP, AP does 4wayHS AP protects bulk data using CCMP Properties of EAP and 4wayHS ensure mutual authentication Client AAA AP RADIUS/ Diameter 802.1x EAP EAP PMK 4wayHS 4wayHS PMK disclosure PTK PTK bulk data protection CCMP CCMP “the network”

RSN Networks A different deployment Client authenticates to network via AP using EAP method AP does 4wayHS AP protects bulk data using CCMP Properties of EAP and 4wayHS ensure mutual authentication Client AP 802.1x EAP EAP PMK PMK 4wayHS 4wayHS PTK PTK “the network” bulk data protection CCMP CCMP

Different Deployments Represent Network Optimization Deployment of RSN scales better when using a stand-alone EAP server Network credentials in one place instead of many Expanding coverage and adding users is simpler AAA server represents multi-homed network The RSN protocol remains the same regardless of deployment Client is completely unaware of network deployment Both deployments provide “mutual authentication” Threat model for network access is unchanged

WAPI = WAI + WPI The players: ASUE is a client device, performs ECDH and ECDSA The AE is an access point, performs ECDH and ECDSA The ASE is a clearing house for the ASUE’s and AE’s certificates ASUE and AE do authenticated Diffie-Hellman (WAI) using ASE for certificate validation followed by Unicast Key Exchange ASUE and AE do WPI for bulk data protection using USK Client/ASUE AP/AE ASE DH+DSA + UKE certificate validation WAI WAI WAI USK USK bulk data protection WPI WPI

A “Split MAC” Architecture for WAPI The “real time” aspects of the MAC remain in each AP, the “non real time” aspects of all APs are aggregated into a single controller For WAPI, that means moving WAI to controller, leaving WPI in AP AE WPI Client/ASUE ASE WPI DH+DSA + UKE certificate validation WAI WAI WAI WPI USK WPI bulk data protection WPI

“Split MAC” WAPI How does it work? Controller/AE and ASUE have certificates, AP does not The AP passes all traffic with ethertype 0x88b4 to the controller/AE, all other ASUE traffic is blocked Controller/AE performs ECDH and ECDSA, talks to ASE Controller/AE authenticates ASUE, and derives BK Controller/AE performs UKE and derives USK Controller sends USK to AP AP unblocks ASUE traffic filter AP performs WPI using the USK An alternate form involves splitting WAI functionality, leaving part of it in the AP Controller/AE sends BK to AP AP performs Unicast Key Exchange and derives USK

A “Split MAC” Architecture A “split MAC” deployment scales better Less devices to provision APs do not contain long-term secrets for network access Increasing coverage is as easy as adding new “thin” APs 100% WAPI compliant! The WAPI protocol is not changed ASUE does not know that there is a “split MAC” architecture Authentication is still between ASUE and AE but… AP does not derive BK and is not a party to the WAI exchange USK (or BK) needs to be transferred from AE/controller to AP What about “mutual authentication”?

“Mutual Authentication”? Two Views A “split MAC” architecture is merely a deployment optimization The location in which the components of the MAC layer protocol are spoken change, but the MAC layer protocol does not change WAPI still performs “mutual authentication” Or is it? WAPI is insecure because AP is not authenticated WAPI lacks “mutual authentication” Secret key (USK/BK) is disclosed to AP by AE!

The Conclusion… This logic leads us to conclude that: Either both WAPI and RSN provide “mutual authentication”; or, Neither WAPI nor RSN provide “mutual authentication”.

References 11-11-0703-06-000s-p802-11s-sponsor-ballot-4th-recirc-comments.xls Slide 13