“ARSN” An Adjunct RSN Proposal Carlos Rios RiosTek LLC

TGi, Where We Are, and Where We Seem to be Going Much fine, hard work and excellent accomplishments to date: ULA (802.1x/EAPOL Authentication) has been well-merged into 802.11 Encryption Suites have been defined for legacy (TKIP) and future (AES) equipment Each featuring Replay Detection, Message Authentication and Strong Privacy But, integrating the pieces into a comprehensive, consistent, well-understood and workable whole has been troublesome We didn’t quite understand and did not define well the Key Management, fast roaming, unicast, multicast and broadcast messaging, how the IBSS will work, etc. Bogged down, we tried to punt to the 802.11 membership No dice, LB35 failed resoundingly And at the same time, D2.0 was implemented, and did NOT work And now we’re trying to figure out what to do- D2.x, Louie or something else

Let’s talk about the “Something Else”: ARSN An RSN adjunct (a set of parallel protocols) to D2.0 Works alongside 802.1x/EAPOL mechanisms Provides complete RSN functionality for WLANs that don’t have, need or want 802.1x/EAPOL Comprehensive Simple additions address and resolve key issues not fully visited in D2.0 Radically Simplified A “Minimalist Perspective” eliminates unnecessary complexity It Will Work It’s not really much of a departure from what works now Complete and ready for integration with final, workable and stable 802.1x/EAPOL key management mechanisms when they become available The heavy lifting IS done- draft text is almost ready for incorporation into D2.0

The Adjunct RSN (ARSN) Proposal OK, So What’s the Deal? The Adjunct RSN (ARSN) Proposal What is it? Modifications and Additions to D2.0 What does it do? - Enlarge the Tent - Repair the Ruptures - Plug the Holes - Trim the Fat - Tie it all Together

Enlarge the Tent Expand the RSN security umbrella to cover: - IBSS (not provisioned with a Radius server) Group-private communications with maximal ease of setup and use Pairwise-private communications with slightly less ease of setup and use - Simple Infrastructure Networks (again, no AS) Home, Small Business WLANs not provisioned with EAPOL, 802.1x or AS Pairwise-private communications with maximal ease of setup and use And for both, provide - Mutual Authentication - Unicast, multicast and broadcast messaging - TKIP and AES Privacy Replay Detection Message Authentication

Repair the Ruptures No Authentication methods exist for IBSS or Simple BSSs- Legacy Authentication is deprecated in favor of ULA by itself Incorporate “Robust Shared Key Authentication” (RSKA) Non 802.1x RSN roaming is undefined Incorporate “ARSN Preauthentication” Incorporate (IAPP-transported) PMK transfer between APs Better manage the number and types of keys A set of Pairwise (unicast) ping and Group (broadcast) ping, pong keys per RA/TA pair Use explicit Key Indexing ONLY in order to unambiguously identify the exact key required to decrypt a transmission Eliminate separate Tx and Rx MIC keys, use just one for both directions Better Define Group, Pairwise Keying in non 802.1x BSS, IBSS 48 bit IVs eliminate rekeying due to IV space exhaustion 1st BSS Pairwise key produces sequence of expiring Group Broadcast ping, pong keys External manager determines, sets up multicast groups, enables creation of a sequence of expiring Group Multicast keys Independent Pairwise and Group Keys in the IBSS

Plug the Holes Incorporate RSKA to support non 802.1x IBSS, simple BSS Authenticate by proving knowledge of common secret 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 in the IBSS Incorporate method to distribute Group Keys in non 802.1x BSS “Private Transport Protocol” (PTP), an exchange of management frames 3 message handshake using 802.11 Authentication frames Group Key derived from 1st derived PK (from first associating STA) in the BSS Upon Authentication or roaming, STA requests new AP to send it the Group Key AP retrieves GK, TKIP/AES encrypts using new STA’s PK and sends back For Roaming, add Preauthentication, IAPP PMK transport Preauthentication= Roaming STA and roamed-to AP share same (STA) PMK Roamed-to AP retrieves STA PMK from roamed-from AP using secure IAPP AP, STA derive PK and just start transmitting encrypted packets Encryption, MIC failures result in STA Disassociation and Deauthentication

Hole Plugging, Continued 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

Trim the Fat Expand IV space to 48 explicit bits, in an extended frame Never need to re-key due to IV exhaustion Re-keys occur only upon roaming, and new Associations Equivalent to a re-initialization Don’t Make Me Guess Which Key to Use, Tell me Every BSS RA/TA pair supports three distinct keys, using the 2 bit KeyID within the IV field to indicate: 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 Every IBSS RA/TA pair supports the following three keys: 00 – Pairwise-secret key derived from Preshared Pairwise Secret, PN0 01 – Pairwise group-secret key derived from Preshared Group secret, PN1 10 - Group Broadcast key derived from Preshared Group Secret 11 – Not Used

Now, Let’s Tie this All Together

RSN Pairwise Key Hierarchy Pairwise Transient Key (PTK) = PRF (PMK, “dot11PTK”, Min(TA,RA) || Max(TA,RA) || PN) Temporal TKIP/AES Encryption Key L(PTK, 0, 128) Temporal TKIP MIC Key L(PTK, 128, 64) TKIP Mixing Function TKIP PP Encryption Key TKIP Michael AES IV RA TA RC4 PMK PN EAPOL Master Key EAPOL Authentication (STA)/ RADIUS Attribute (AP) EAPOL Pairwise Master Key (256b) From UI PSK Pairwise Secret (PSKPS) PRF (PSKPS, “dot11pskPMK”, 0) PSK Pairwise Master Key (256b) Management Frame Exchange Pairwise Nonce (128b) PN, PKeyID From AS From AP or IBSS Peer PSK PMK Infrastructure (ULA) only Infrastructure (RSKA) and IBSS

RSN Group Key Hierarchy First Infr BSS PMK IBSSGroup Secret (IBSSGS) From AP From UI PRF (IBSSGS, “dot11ibssGMK”, 0) PRF (PMK, “dot11infrGMK”, 0) IBSS Group Master Key (256b) Infrastructure Group Master Key (256b) IBSS GMK IBSS only Infrastructure BSS only GN GMK BSS: Incrementing Count generated by AP IBSS= FFFFFFFFFFFFFFF Group Transient Key (GTK) = PRF (GMK, “dot11GTK”, GN) Temporal TKIP/AES Encr Key L(GTK, 0, 128) Temporal TKIP MIC Key L(GTK, 128, 64) GKeyID IV RA TA TKIP Mixing Function TKIP PPEncryption Key TKIP Michael AES RC4

Example 1- BSS, RSK Authentication STA1 shares pairwise secret, PSK1 with ESSB (APX, APY and APZ) STA1 powers up in range of APX - Initializes Issues Probe, receives Probe Response from APX Detected support for RSKA ASE, AES UCSE, AES MCSE Performs RSKA Authentication and PTP exchange STA1 Authenticated, PMK1 derived, GTKX retrieved and transported Issues Association Request, receives Association Response Agreed on RSKA ASE, AES UCSE, AES MCSE, Negotiated PN1 Derives PK using PMK1 and PN1, uses GKX as is Exchanges encrypted unicasts with, receives encrypted multicasts from APX STA1 wanders over into range of APY- Roams Issues Probe, Receives Probe Response from APY Issues Reassociation Request, receives Reassociation Response Agreed on ULA, AES, Negotiated PN2, keeps PMK1,, APY uses IAPP to get PMK1 Initiates PTP exchange GTKY in use for some time, transported to STA1 Derives PK using PMK1 and PN2, uses GKY as is Exchanges encrypted unicasts with, receives encrypted multicasts from APY

Example 2- IBSS, Group and Pairwise Keying STA1, STA2 , STA3 decide to ad-hoc network, exchange common secret X-> GMKX STA1 establishes IBSS STA1 issues Beacon STA2 , STA3 detect support for RSKA, TKIP STA2 prompts RSKA Group Authentication with STA1 STA1 and STA2 mutually Authenticate, negotiate PNA STA1 and STA2 derive hybrid PK using GMKX and PNA, GK using GMKX STA3 prompts RSKA Group Authentication with STA1 STA1 and STA3 mutually Authenticate, negotiate PNB STA1 and STA3 derive hybrid PK using GMKX and PNB, GK using GMKX STA1 and STA2, STA1 and STA3 can exchange encrypted unicasts using their PKs, but cannot guarantee two-way privacy because GMKY is known to all three STA1, STA2 and STA3 can transmit encrypted broadcasts using the common GK STA2 and STA3 decide to establish a private link, enter secret Y-> PMKY STA3 prompts RSKA Authentication with STA2 STA2 and STA3 mutually Authenticate, negotiate PNB STA2 and STA3 derive PK using PMKY and PNB, STA2 and STA3 exchange two-way private unicasts because only they know PMKY

Summary and Recommendations Take D2.0, add a little, subtract a little, rethink what’s left a little, and you get ARSN ARSN consists of 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 Still, many little steps produce a big change The ARSN proposal requires mindshare and critical analysis Encourage study of ARSN Description, 02/370 Propose further ARSN discussion, and motions to adopt in whole or in part in Vancouver