160 likes | 355 Views
Mutual Authentication. Date: 2011-08-28. Authors:. Slide 1. Abstract. This document provides a statement from the IEEE 802.11 Working Group on the topic of mutual authentication. What is “Mutual Authentication”. Process where each side is assured of the other side’s identity
E N D
Mutual Authentication Date: 2011-08-28 Authors: Slide 1
Abstract • This document provides a statement from the IEEE 802.11 Working Group on the topic of mutual authentication
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 RADIUS/ Diameter AP 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 certificate validation DH+DSA + UKE 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 certificate validation DH+DSA + UKE 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