August 2011 doc IEEE 802 11 -11 1145

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 Mutual Authentication Date: 2011 -08 -28 Authors: Submission Slide 1 802. 11 WG

August 2011 Abstract doc. : IEEE 802. 11 -11/1145 r 1 This document provides a statement from the IEEE 802. 11 Working Group on the topic of mutual authentication Submission Slide 2 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 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 Submission Slide 3 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 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 4 way. HS • AP protects bulk data using CCMP • Properties of EAP and 4 way. HS ensure mutual authentication Client 802. 1 x EAP PMK CCMP Submission AAA EAP 4 way. HS PTK RADIUS/ Diameter AP bulk data protection PMK PTK disclosure CCMP Slide 4 “the network” 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 RSN Networks • A different deployment –Client authenticates to network via AP using EAP method –AP does 4 way. HS –AP protects bulk data using CCMP –Properties of EAP and 4 way. HS ensure mutual authentication Client AP 802. 1 x EAP PMK 4 way. HS PTK CCMP Submission PTK bulk data protection “the network” CCMP Slide 5 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 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 Submission Slide 6 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 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 AP/AE protection using USK data Client/ASUE ASE WAI USK WPI Submission DH+DSA + UKE WAI certificate validation WAI USK bulk data protection WPI Slide 7 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 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 WAI WPI Submission ASE WPI DH+DSA + UKE bulk data protection WAI WPI certificate validation WAI USK WPI Slide 8 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 “Split MAC” WAPI • How does it work? – Controller/AE and ASUE have certificates, AP does not – The AP passes all traffic with ethertype 0 x 88 b 4 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 Submission Slide 9 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 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”? Submission Slide 10 802. 11 WG

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

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 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”. Submission Slide 12 802. 11 WG

August 2011 doc. : IEEE 802. 11 -11/1145 r 1 References 11 -11 -0703 -06 -000 s-p 802 -11 s-sponsor-ballot-4 th-recirc-comments. xls Submission Slide 13 802. 11 WG