doc.: IEEE /1145r1 Submission August WG Slide 1 Mutual Authentication Date: Authors: Slide 1

doc.: IEEE /1145r1 Submission August WG This document provides a statement from the IEEE Working Group on the topic of mutual authentication Abstract Slide 2

doc.: IEEE /1145r1 Submission August 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 Slide 3

doc.: IEEE /1145r1 Submission August WG 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 CCMP EAP 802.1x PMK disclosure bulk data protection PTK Client AP AAA 4wayHS RADIUS/ Diameter 4wayHS PMK “the network” Slide 4

doc.: IEEE /1145r1 Submission August WG 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 ClientAP CCMP EAP PTK 4wayHS PMK CCMP EAP PTK 4wayHS PMK 802.1x bulk data protection “the network” Slide 5

doc.: IEEE /1145r1 Submission August WG 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 Slide 6

doc.: IEEE /1145r1 Submission August WG 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 WPI WAI DH+DSA + UKE certificate validation bulk data protection USK Client/ASUEAP/AEASE Slide 7

doc.: IEEE /1145r1 Submission August WG 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 WPI WAI Client/ASUE AE ASE WAI WPI DH+DSA + UKE bulk data protection USK certificate validation Slide 8

doc.: IEEE /1145r1 Submission August WG “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 Slide 9

doc.: IEEE /1145r1 Submission August WG 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”? Slide 10

doc.: IEEE /1145r1 Submission August WG “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! Slide 11

doc.: IEEE /1145r1 Submission August WG 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”. Slide 12

doc.: IEEE /1145r1 Submission August WG Slide 13 References s-p802-11s-sponsor-ballot-4 th -recirc-comments.xls Slide 13