A Comprehensive, Simplified Alternative RSN Proposal Carlos Rios RiosTek LLC

1. A Comprehensive, Simplified Alternative RSN ProposalCarlos RiosRiosTek LLC

2. TGi, Where We Are, and Where We Seem to be Going • Much fine, hard work and excellent accomplishments to date: • ULA (802.1x/EAPOL-TLS 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’re bogged down with understanding and defining Re-keying, fast roaming, secure roaming, n-way authentication, extended IVs, how the IBSS will work, etc., etc. • And we’re tired, cranky and anxious to get something out • We’re poised to take D1.8, add latest clause 8 mods (let’s call it all “D1.8+”), vote to go to letter ballot, and punt to the 802.11 membership

3. One Man’s Opinion • Not a good idea- D1.8+ is NOT Ready for Prime Time • D1.8+ has significant flaws • It’s incomplete • Parts of it flat out don’t work • Other parts are so complex that few, if any, will be able to make them work • Following is an alternative RSN proposal: • Purportedly ComprehensiveSimple additions address and resolve key issues not fully visited in D1.8+ • Radically SimplifiedA “Reductionist Perpective” eliminates unnecessary D1.8+ functionality • It Will WorkIt’s not really much of a departure from what works now • Readily convertible into D1.9, it COULD be ready for letter ballot this weekThe heavy lifting IS done- analysis, agreement, text draft and voting CAN BE

4. OK, So What’s the Deal? The Alternative RSN (ARSN) Proposal • What is it?A major reconstruction of D1.8+ • What does it do?- Enlarge the Tent- Repair the Ruptures- Plug the Holes- Trim the Fat- Tie it all Together

5. Enlarge the Tent • Expand the RSN security umbrella to cover:- IBSSGroup-private communications with maximal ease of setup and use Pairwise-private communications with slightly lessease of setup and use- Simple Infrastructure NetworksHome, Small Business WLANs not provisioned with EAPOL, 802.1x or ASPairwise-private communications with maximalease of setup and use • And for both (as in D1.8+), support - Mutual Authentication- Unicast and broadcast/multicast transmissions- TKIP and AES Privacy Replay Detection Message Authentication

6. Repair the Ruptures • No Authentication methods exist for IBSS, Simple BSSs-RSN has deprecated legacy Authentication in favor of ULAIncorporate “Robust Shared Key Authentication” (RSKA) • RSN roaming is ill-understood and undefinedIncorporate “RSN Preauthentication” Incorporate (IAPP-transported) PMK transfer between APs • Can’t keep track of all the keys running around- ping and pong, Pairwise and Group, pre-calculated, EAPOL-Key, etc. Eliminate ping and pong keys, and key pre-calculation Eliminate separate Tx and Rx MIC keys, use just one for both directions Incorporate Explicit Key Indexing into each packet to unambiguously identify the exact key required to decrypt a transmissionEliminate EAPOL-Key Keys- by eliminating EAPOL-Key messages • Group Rekeying depends on an undefined global GMK update, Pairwise Rekeying is too complicated to ever be made to workEliminate Rekeying altogether, re-initialize instead!

7. Plug the Holes • Incorporate RSKA to support IBSS, simple Infrastructure RSNs Authenticate by proving knowledge of common secret (Pairwise or Group PSK) 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 GMKs in Infrastructure BSS “Private Transport Protocol” (PTP), an exchange of management frames3 message handshake using 802.11 Authentication frames • GMK is derived from first derived PMK (from first associating STA) in the BSS • Upon Authentication or roaming, new STA requests AP to send it the GMK • AP retrieves GMK, TKIP/AES encrypts using new STA’s PKH and sends back • Uses 802.11-99 standard Authentication frames with new Information Elements

8. Hole Plugging, Continued • For Roaming, add Preauthentication, IAPP PMK transport Preauthentication= Roaming STA and roamed-to AP share same (STA) PMKRoamed-to AP retrieves STA PMK from roamed-from AP using secure IAPP • AP, STA derive PKH and just start transmitting encrypted packets • Encryption, MIC failures result in STA Disassociation and Deauthentication • Add new Information Elements, Status, Reason CodesBeacon- IEs: ASE, UCSE, MCSE, Group NE (GNE)Probe Response- IEs: ASE, UCSE, MCSE, GNE Association Request- IEs: ASE, UCSE, Pairwise NE (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

9. Trim the Fat Simplify, Simplify, Simplify… • Use same key hierarchy structure for Pairwise and Group KeysPMK, PN, RA, TA => PTrK => PMICK, PEK|IV,TA GMK, GN => GTrK => GMICK, GEK|IV,TAAP/Beacon Generator creates and maintains Group Nonces (GNs), broadcasts them as IEs within the Beacons • Restrict EAPOL to do what is does best- AuthenticationWell, OK, let ULA deposit PMKs at AP and STA, but that’s it DistributePNs, GMKs with existing 802.11 Management Frames (+ new IEs) Eliminate EAPOL-Key messages and associated encryption and MIC keys • Don’t Rekey, Re-InitializePK, Infr - AP Disassociates STAupon imminent IV exhaustion STA immediately Reassociates, negotiates new PN, derives new PKHGK, Infr – AP generates new GN upon IV exhaustion, transmits in Beacon STAs sense beacon with new GN IE, derive new GKHPK, IBSS - STA Deauthenticates peer upon imminent IV exhaustion STA immediately Re-Authenticates, negotiates new PN, derives new PKHGK, IBSS – Beacon Generator creates new GN upon IV exhaustion, transmits in Beacon STAs sense beacon with new GN IE, derive new GKH

10. RSN Reduction, Continued • Don’t Make Me Guess Which Key to Use, Tell meUse 2 bit KeyID within the IV field to indicate a packet’s encryption with: 00 - Pairwise key derived from PMK, PN 01 - Pairwise Key (used in RSKA) derived from PMK, “Authentication” PN 10 - Group key derived from GMK, GN 11 – IBSS Hybrid key derived from GMK, PN • Defer consideration of non-essential niceties • “N-party Authentication”- 802.11 security is only concerned with AP-STA or STA- STA interactions, the infrastructure is deemed secure (Wired Equivalent Privacy) • “Secure Roaming”- See comment immediately above • Management Frame MICs- “Nonce Disruption”attacks, etc, are just DOS • IBSS “Security Association”- Seems OK without it, Let’s not break 802.11 • Extended IVs- Have space of 230for TKIP and AESnow, 10k 802.11a packets/sec will exhaust it in 30 hours, Reassociation/Re-Authentication takes 1 ms. Works for me!

11. Now, Let’s Tie this All Together

12. From UI From AS From AP or IBSS Peer EAPOL Authentication (STA)/ RADIUS Attribute (AP) EAPOL Pairwise Master Key (256b) Management Frame Exchange Infrastructure (ULA) only Pairwise Nonce (128b) PSK PMK Infrastructure (RSKA) and IBSS 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, 192, 64) PKeyID IV RA TA PRF (PSKPS, “dot11pskPMK”, 0) TKIP Mixing Function TKIP PP Encryption Key PSK Pairwise Master Key (256b) PN, PKeyID TA EAPOL Master Key RA PN PMK PSK Pairwise Secret (PSKPS) RC4 AES TKIP Michael RSN Pairwise Key Hierarchy

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

14. Example 1- Infrastructure BSS, Upper Layer Authentication STA1 credentialed with ASA , ASA services ESSB (APX, APY and APZ ) • STA1 powers up in range of APX - InitializesIssues Probe, Receives Probe Response from APX • Detected support for ULA ASE, AES UCSE, AES MCSE, Received GNX0 Issues Association Request, Receives Association Response • Agreed on ULA ASE, AES UCSE, AES MCSE, Negotiated PN1 Performs ULA Authentication and PTP exchange • STA1 Authenticated, PMK1 derived, GMKX retrieved and transported Derives PKH using PMK1 and PN1, GKH using GMKX and GNX0 STA1 exchanges encrypted unicasts with, receives encrypted multicasts from APX • STA1 left connected over Xmas Holidays- IV nears exhaustionAPX detects IV near max, issues Disassociation to STA1 with IVExh Reason code • STA1 Disassociates, knows to Reassociate immediately STA1 issues Reassociation Request, receives Reassociation Response • STA1 and APX keep PMK1,, Negotiate PN2 APX and STA1 both derive new PKH using PMK1 and PN2 STA1 exchanges encrypted unicasts with, receives encrypted multicasts from APX

15. Example 2- Infrastructure BSS, RSK Authentication STA1 shares pairwise secret, PSK1 with ESSB (APX, APY and APZ) • STA1 powers up in range of APX - InitializesIssues Probe, receives Probe Response from APX • Detected support for RSKA ASE, AES UCSE, AES MCSE, Received GNX Performs RSKA Authentication and PTP exchange • STA1 Authenticated, PMK1 derived, GMKX retrieved and transported Issues Association Request, receives Association Response • Agreed on RSKA ASE, AES UCSE, AES MCSE, Negotiated PN1 Derives PKH using PMK1 and PN1, GKH using GMKX and GNX Exchanges encrypted unicasts with, receives encrypted multicasts from APX • STA1 wanders over into range of APY- RoamsIssues Probe, Receives Probe Response from APY • Detected support for RSKA ASE, AES UCSE, AES MCSE, Received GNY Issues Reassociation Request, receives Reassociation Response • Agreed on ULA, AES, Negotiated PN2, keeps PMK1,, APY uses IAPP to get PMK1 Initiates PTP exchange • GMKY in use for some time, transported to STA1 Derives PKH using PMK1 and PN2, GKH using GMKY and GNY Exchanges encrypted unicasts with, receives encrypted multicasts from APY

16. Example 3- IBSS, Group and Pairwise Keying STA1, STA2 , STA3 decide to ad-hoc network, exchange common secret X-> GMKX • STA1 establishes IBSSSTA1generates nonce GNA, issues Beacon • STA2 , STA3 detect support for RSKA, TKIP, Receive GNA STA2 prompts RSKA Group Authentication with STA1 • STA1 and STA2 mutually Authenticate, negotiate PNA STA1 and STA2 derive Hybrid PKH using GMKX and PNA, GKH using GMKX and GNA STA3 prompts RSKA Group Authentication with STA1 • STA1 and STA3 mutually Authenticate, negotiate PNB STA1 and STA3 derive Hybrid PKH using GMKX and PNB, GKH using GMKX and GNA STA1 and STA2, STA1 and STA3 can exchange encrypted unicasts using their PKHs, but cannot guarantee two-way privacy because GMKY is known to all three STA1, STA2 and STA3 can transmit encrypted multicasts using the common GKH • STA2 and STA3 decide to establish a private link, exchange secret Y-> PMKYSTA2 and STA3 already share GMKX and GNASTA3 prompts RSKA Pairwise Authentication with STA2 • STA2 and STA3 mutually Authenticate, negotiate PNB STA2 and STA3 derive PKH using PMKY and PNB, STA2 and STA3 exchange two-way private unicasts because only they know PMKY

17. Summary and Recommendations • Take D1.8+, add a little, subtract a little, rethink what’s left a little, and you get ARSN • ARSN consists of retooling what’s already there • 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 changeThe ARSN proposal requires mindshare and critical analysis • Encourage study of ARSN Description, 11-02-204r0-I • Propose further ARSN discussion tomorrow, and motions to adopt in whole or in part • Draft text could be assembled by Thursday, for vote to go to LB • Then we can give everyone a 40 day respite from TGI CCs