doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 1 Pre-Shared Key RSN Extensions Enrollment, Authentication and Key Management for IBSS, Simple BSS and Sidechannel Carlos Rios RiosTek LLC

doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 2 I’m Baaack… TGi D2.2 still contains holes and inconsistencies fatal to a comprehensive, robust 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 e 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

doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 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 AS Pairwise-private communications with maximal ease 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

doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 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

doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 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 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 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 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

doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 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, PN 1, if so configured 01 – Pairwise group-secret key derived from Preshared Group secret, PN Group Broadcast key derived from Preshared Group Secret, GN 0 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 -1 st 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, GN 0 11 – Group Broadcast pong key derived from GMK, GN 1 -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, GN 0 11 – Group Broadcast pong key derived from GMK, GN 1

doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 7 Details, Details PSKE implementation requires ONLY minor reworking of existing MAC protocols, frame structures Add new Information Elements, Status, Reason Codes Beacon- IEs: ASE, UCSE, MCSE Probe 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 PMK Disassociation- RCs: Multiple Encryption Failures, Multiple MIC Failures Authentication- 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

doc.: IEEE /431r0 Submission July 2002 Carlos Rios, RiosTek LLC Slide 8 Summary and Recommendations Take 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 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 i D2.2 draft text”