80 likes | 220 Views
Pre-Shared Key RSN Extensions Enrollment, Authentication and Key Management for IBSS, Simple BSS and Sidechannel Carlos Rios RiosTek LLC. I’m Baaack…. TGi D2.2 still contains holes and inconsistencies fatal to a comprehensive, robust 802.11 enhanced security solution
E N D
Pre-Shared Key RSN ExtensionsEnrollment, Authentication and Key Management for IBSS, Simple BSS and Sidechannel Carlos RiosRiosTek LLC
I’m Baaack… • TGi D2.2 still contains holes and inconsistencies fatal to a comprehensive, robust 802.11 enhanced security solution • Specifically, 802.1x based mechanisms do not adequately address some extremely important shortcomings: • IBSS enrollment/authorization, authentication and key management • Ditto for the Simple BSS (i.e., the WLAN not provisioned with an Authentication Server) • Also for Sidechannel, per 802.11e D3.0 (for example, for “Guest” support in the Enterprise) • This document proposes Pre-Shared Key Extensions (PSKE) to the RSN address these shortcomings • PSKE is specifically structured as a simple, inexpensive, minimalist, lowest-common denominator complement to 802.1x based RSN protocols
Enlarging the RSN Tent • Extend the RSN security umbrella to cover:- IBSS Group-private communications with maximal ease of use (enrollment) Pairwise-private communications with slightly more hassle- Simple BSS (no RADIUS Server)Home, Small Business WLANs not provisioned with EAPOL, 802.1x and/or ASPairwise-private communications with maximalease of use- Sidechannel (Direct Frame Transfer)Home, Small Business WLANs not provisioned with EAPOL, 802.1x and/or AS Enterprise “Guests” not authorized access to the DS • Support the above with- User-friendly enrollment/authorization- Mutual Authentication- Unicast, multicast and broadcast messaging- TKIP and AES Privacy, Replay Detection and Message Authentication
Let’s Talk About Enrollment • Enrollment is the authorized process of enabling a STA to join a WLAN -Securely binds the STA MAC address with an authorization token, and provides the bound information to the WLAN for future authentication, key management and private session establishment-Analogous to the issuing of credentials/certs by the IT folk in the 802.1x case-Enrollment is not “initial setup”, as it can occur at any time with any given network, multiple times with multiple networks, and remains in effect until positively revoked -In the Simple BSS, IBSS and Sidechannel, Enrollment may need to be done by the user • PSKE Enrollment is a one-time manual entry of information at each STA (or AP), for every desired link -Simple BSS, performed by a STA with every AP in the ESS At STA: BSSID, AP alias (in lieu of AP MAC Address) and pairwise Pre-Shared Secret At AP: BSSID, STA alias (in lieu of STA MAC Address), pairwise Pre-Shared Secret-Simple BSS Sidechannel, performed at each STA desiring the DFT At STA1: STA2 alias, STA1-STA2 Pairwise PSK At STA1: STA2 alias, STA1-STA2 Pairwise PSK -IBSS, performed by every STA, assume only STA2 and STA3 desire mutual private link At STA1: BSSID, Group PSK At STA2: BSSID, Group PSK, STA3 alias and STA2-STA3 Pairwise PSK At STA2: BSSID, Group PSK, STA2 alias and STA2-STA3 Pairwise PSK
PSKE Authentication and Key Management • IBSS, Simple BSS, Sidechannel need non-802.1x authentication-Incorporate “Robust Shared Key Authentication” (RSKA)-RSKA consists of two-way challenge-response exchanges using TKIP/AES with key(s) derived from the Pre-Shared secret and a mutually negotiated nonce-5 message handshake based on Shared Key Authentication • Mutual Authentication of both stations • TKIP or AES used to cipher challenge texts • Uses 802.11-99 standard Authentication frames with new Information Elements -Negotiates, exchanges the PN between STAs to generate fresh encryption, MIC keys • Incorporate method to distribute Group Keys in the SBSS -“Private Transport Protocol” (PTP), an exchange of management frames-3 message handshake using 802.11 Authentication frames • Each AP has its own Group Key derived from 1st derived PK (from first associating STA) in the SBSS • Upon Authentication or roaming, STA requests new AP to send it the operative Group Key within an (encrypted) authentication frame • Uses 802.11-99 standard Authentication frames with new Information Elements • BTW, PSKE fast roaming is easily supported in the SBSS-APs in Home, SOHO WLAN ESS all share STA PSKs by virtue of enrollment -Full RSKA authentication (2 ms) performed upon a roaming reassociation
More PSKE Key Management • Better manage Pairwise and Group Keys in the IBSS-IBSS Group and Pairwise keys are best derived from separate group and pairwise secrets manually entered at the respective STA UIs -However, pairwise ordered but not pairwise-secret keys are easiest derived from the common group secret, to service those who can’t be bothered to enter pairwise secrets-IBSS RA/TA pairs support the following keys, each bound to a specific KeyID:00 – Pairwise-secret key derived from Preshared Pairwise Secret, PN1, if so configured 01 – Pairwise group-secret key derived from Preshared Group secret, PN0 10 - Group Broadcast key derived from Preshared Group Secret, GN0 11 – Not Used • Better manage Pairwise and Group Keys in the SBSS-SBSS Pairwise keys are derived from pre-shared secrets at AP and STA-Every SBSS RA/TA pair supports a Pairwise (unicast) ping key and Group (broadcast) ping and pong keys, each unambiguously bound to a specific KeyID -1st SBSS Pairwise key produces sequence of expiring Group (broadcast)ping, pong keys 00 - Pairwise key derived from PMK, PN 01 – Not Used 10 - Group Broadcast ping key derived from GMK, GN0 11 – Group Broadcast pong key derived from GMK, GN1-External SBSS manager determines, sets up multicast groups and group RAs, enables creation of expiring Group Multicast ping and pong keys (and NO pairwise key):00 – Not Used 01 – Not Used 10 - Group Broadcast ping key derived from GMK, GN0 11 – Group Broadcast pong key derived from GMK, GN1
Details, Details • PSKE implementation requires ONLY minor reworking of existing 802.11-1999 MAC protocols, frame structures • Add new Information Elements, Status, Reason CodesBeacon- IEs: ASE, UCSE, MCSEProbe Response- IEs: ASE, UCSE, MCSE Association Request- IEs: ASE, UCSE, Pairwise Nonce Element (PNE)Association Response- IEs: ASE, UCSE, MCSE, PNE Reassociation Request- IEs: ASE, UCSE, PNE Reassociation Response- IEs: ASE, UCSE, MCSE, PNE SC: Unable to Retrieve PMKDisassociation- RCs: Multiple Encryption Failures, Multiple MIC FailuresAuthentication- IEs: Authentication CSE (ACSE), Authentication NE (ANE), Station ID (StaID), PNE, Transport CSE (TCSE), Payload Descriptor (PD), Payload (P) SCs: Can’t Support ACSE, Can’t Support TCSE, Don’t Recognize PD Deauthentication- RCs: Multiple Encryption Failures, Multiple MIC Failures
Summary and Recommendations • Take 802.11-1999 and D2.2, add a little, subtract a little, rethink what’s left a little, and you get PSKE RSN • PSKE consists of slightly retooling what already exists • The heavy lifting (802.1x/EAPOL/ULA, TKIP, AES) has been done • Add some Information Elements, and Status, Reason Codes • Re-spin some existing 802.11 management protocols • All the gory details are contained in the PSKE Description, 02/432r0 • Propose the following motion: “Move to instruct the Technical Editor to work with the interested parties and incorporate the Pre-Shared Key RSN Extension protocols as presented in 02/431r0 and 02/432r0 into the successor revision of the 802.11i D2.2 draft text”