doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 1 A Comprehensive, Simplified Alternative RSN Proposal Carlos Rios RiosTek LLC

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 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 –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 membership

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 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 Comprehensive Simple additions address and resolve key issues not fully visited in D1.8+ –Radically Simplified A “Reductionist Perpective” eliminates unnecessary D1.8+ functionality –It Will Work It’s not really much of a departure from what works now –Readily convertible into D1.9, it COULD be ready for letter ballot this week The heavy lifting IS done- analysis, agreement, text draft and voting CAN BE

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 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

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 5 Enlarge the Tent Expand the RSN security umbrella to cover: - IBSS Group-private communications with maximal ease of setup and use Pairwise-private communications with slightly less ease of setup and use - Simple Infrastructure Networks 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 (as in D1.8+), support - Mutual Authentication - Unicast and broadcast/multicast transmissions - TKIP and AES Privacy Replay Detection Message Authentication

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 6 Repair the Ruptures No Authentication methods exist for IBSS, Simple BSSs- RSN has deprecated legacy Authentication in favor of ULA Incorporate “Robust Shared Key Authentication” (RSKA) RSN roaming is ill-understood and undefined Incorporate “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 transmission Eliminate 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 work Eliminate Rekeying altogether, re-initialize instead!

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 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 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 frames 3 message handshake using 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 standard Authentication frames with new Information Elements

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 8 Hole Plugging, Continued 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 PKH and just start transmitting encrypted packets –Encryption, MIC failures result in STA Disassociation and Deauthentication Add new Information Elements, Status, Reason Codes Beacon- 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 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 /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 9 Trim the Fat Simplify, Simplify, Simplify… Use same key hierarchy structure for Pairwise and Group Keys PMK, PN, RA, TA => PTrK => PMICK, PEK| IV,TA GMK, GN => GTrK => GMICK, GEK| IV,TA AP/Beacon Generator creates and maintains Group Nonces (GNs), broadcasts them as IEs within the Beacons Restrict EAPOL to do what is does best- Authentication Well, OK, let ULA deposit PMKs at AP and STA, but that’s it Distribute PNs, GMKs with existing Management Frames (+ new IEs) Eliminate EAPOL-Key messages and associated encryption and MIC keys Don’t Rekey, Re-Initialize PK, Infr - AP Disassociates STA upon imminent IV exhaustion STA immediately Reassociates, negotiates new PN, derives new PKH GK, Infr – AP generates new GN upon IV exhaustion, transmits in Beacon STAs sense beacon with new GN IE, derive new GKH PK, IBSS - STA Deauthenticates peer upon imminent IV exhaustion STA immediately Re-Authenticates, negotiates new PN, derives new PKH GK, IBSS – Beacon Generator creates new GN upon IV exhaustion, transmits in Beacon STAs sense beacon with new GN IE, derive new GKH

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 10 RSN Reduction, Continued Don’t Make Me Guess Which Key to Use, Tell me Use 2 bit KeyID within the IV field to indicate a packet’s encryption with: 00 - Pairwise key derived from PMK, PN 01 - IBSS Hybrid key derived from GMK, PN 10 - Group key derived from GMK, GN 11 – Group key1 derived from GMK 1, GN Defer consideration of non-essential niceties –“N-party Authentication” 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 –Extended IVs- Have space of 2 30 for TKIP and AES now, 10k a packets/sec will exhaust it in 30 hours, Reassociation/Re-Authentication takes 1 ms. Works for me!

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 11 Now, Let’s Tie this All Together

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 12 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, 192, 64) TKIP Mixing Function TKIP PP Encryption KeyTKIP Michael AES IV RA TA RC4 PMKPN RATA 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 PKeyID PSK PMK Infrastructure (ULA) only Infrastructure (RSKA) and IBSS

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 13 RSN Group Key Hierarchy 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) TKIP Mixing Function TKIP PPEncryption KeyTKIP Michael AES IV RA TA RC4 GMKGN First Infr BSS PMK PRF (PMK, “dot11infrGMK”, 0) Infrastructure Group Master Key (256b) From UI IBSSGroup Secret (IBSSGS) PRF (IBSSGS, “dot11ibssGMK”, 0) IBSS Group Master Key (256b) Beacon Nonce IE Group Nonce (128b) GN, GKeyID From Beacon Generator GKeyID From AP IBSS GMK IBSS onlyInfrastructure BSS only

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 14 Example 1- Infrastructure BSS, Upper Layer Authentication STA 1 credentialed with AS A, AS A services ESS B (AP X, AP Y and AP Z ) STA 1 powers up in range of AP X - Initializes Issues Probe, Receives Probe Response from AP X –Detected support for ULA ASE, AES UCSE, AES MCSE, Received GN X0 Issues Association Request, Receives Association Response –Agreed on ULA ASE, AES UCSE, AES MCSE, Negotiated PN 1 Performs ULA Authentication and PTP exchange –STA 1 Authenticated, PMK 1 derived, GMK X retrieved and transported Derives PKH using PMK 1 and PN 1, GKH using GMK X and GN X0 STA 1 exchanges encrypted unicasts with, receives encrypted multicasts from AP X STA 1 left connected over Xmas Holidays- IV nears exhaustion AP X detects IV near max, issues Disassociation to STA 1 with IVExh Reason code –STA 1 Disassociates, knows to Reassociate immediately STA 1 issues Reassociation Request, receives Reassociation Response –STA 1 and AP X keep PMK 1,, Negotiate PN 2 AP X and STA 1 both derive new PKH using PMK 1 and PN 2 STA 1 exchanges encrypted unicasts with, receives encrypted multicasts from AP X

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 15 Example 2- Infrastructure BSS, RSK Authentication STA 1 shares pairwise secret, PSK 1 with ESS B (AP X, AP Y and AP Z ) STA 1 powers up in range of AP X - Initializes Issues Probe, receives Probe Response from AP X –Detected support for RSKA ASE, AES UCSE, AES MCSE, Received GN X Performs RSKA Authentication and PTP exchange –STA 1 Authenticated, PMK 1 derived, GMK X retrieved and transported Issues Association Request, receives Association Response –Agreed on RSKA ASE, AES UCSE, AES MCSE, Negotiated PN 1 Derives PKH using PMK 1 and PN 1, GKH using GMK X and GN X Exchanges encrypted unicasts with, receives encrypted multicasts from AP X STA 1 wanders over into range of AP Y - Roams Issues Probe, Receives Probe Response from AP Y –Detected support for RSKA ASE, AES UCSE, AES MCSE, Received GN Y Issues Reassociation Request, receives Reassociation Response –Agreed on ULA, AES, Negotiated PN 2, keeps PMK 1,, AP Y uses IAPP to get PMK 1 Initiates PTP exchange –GMK Y in use for some time, transported to STA 1 Derives PKH using PMK 1 and PN 2, GKH using GMK Y and GN Y Exchanges encrypted unicasts with, receives encrypted multicasts from AP Y

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 16 Example 3- IBSS, Group and Pairwise Keying STA 1, STA 2, STA 3 decide to ad-hoc network, exchange common secret X-> GMK X STA 1 establishes IBSS STA 1 generates nonce GN A, issues Beacon –STA 2, STA 3 detect support for RSKA, TKIP, Receive GN A STA 2 prompts RSKA Group Authentication with STA 1 –STA 1 and STA 2 mutually Authenticate, negotiate PN A STA 1 and STA 2 derive Hybrid PKH using GMK X and PN A, GKH using GMK X and GN A STA 3 prompts RSKA Group Authentication with STA 1 –STA 1 and STA 3 mutually Authenticate, negotiate PN B STA 1 and STA 3 derive Hybrid PKH using GMK X and PN B, GKH using GMK X and GN A STA 1 and STA 2, STA 1 and STA 3 can exchange encrypted unicasts using their PKHs, but cannot guarantee two-way privacy because GMK Y is known to all three STA 1, STA 2 and STA 3 can transmit encrypted multicasts using the common GKH STA 2 and STA 3 decide to establish a private link, exchange secret Y-> PMK Y STA 2 and STA 3 already share GMK X and GN A STA 3 prompts RSKA Pairwise Authentication with STA 2 –STA 2 and STA 3 mutually Authenticate, negotiate PN B STA 2 and STA 3 derive PKH using PMK Y and PN B, STA 2 and STA 3 exchange two-way private unicasts because only they know PMK Y

doc: IEEE /202r1 Submission March 2002 Carlos Rios, RiosTek LLC Slide 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 management protocols Still, many little steps produce a big change The ARSN proposal requires mindshare and critical analysis Encourage study of ARSN Description, r0-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