1 / 8

I’m Baaack…

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

finnea
Download Presentation

I’m Baaack…

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Pre-Shared Key RSN ExtensionsEnrollment, Authentication and Key Management for IBSS, Simple BSS and Sidechannel Carlos RiosRiosTek LLC

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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”

More Related