“ARSN” An Adjunct RSN Proposal Carlos Rios RiosTek LLC

1. “ARSN” An Adjunct 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 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 don’t quite understand and have not defined 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, the key management mechanisms presented therein were implemented, and did NOT work • And now we’re trying to figure out what to do- • D2.x, Louie or something else

3. 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 • ComprehensiveSimple additions address and resolve key issues not fully visited in D2.0 • Radically SimplifiedA “Minimalist Perspective” eliminates unnecessary complexity • It Will WorkIt’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 availableThe heavy lifting IS done- draft text is almost ready for incorporation into D2.0

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

5. 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 lessease of setup and use- Simple Infrastructure Networks (again, no AS)Home, Small Business WLANs not provisioned with EAPOL, 802.1x or ASPairwise-private communications with maximalease of setup and use • And for both (as in D2.0), support - Mutual Authentication- Unicast, multicast and broadcast messaging- TKIP and AES Privacy Replay Detection Message Authentication

6. Repair the Ruptures • No Authentication methods exist for IBSS or Simple BSSs-Legacy Authentication is deprecated in favor of ULA by itselfIncorporate “Robust Shared Key Authentication” (RSKA) • Non 802.1x RSN roaming is undefinedIncorporate “ARSN Preauthentication” Incorporate (IAPP-transported) PMK transfer between APs • Better manage the number and types of keysA set of Pairwise (unicast) ping and Group (broadcast) ping, pong keys per RA/TA pairMultiple sets of Group (multicast) ping, pong keys per (Group Addressed) RA/TA pairUse explicit Key Indexing ONLY in order to unambiguously identify the exact key required to decrypt a transmissionEliminate 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 rekeyingdue to IV space exhaustion1st BSS Pairwise key produces sequence of expiring Group Broadcast ping, pong keysExternal manager determines, sets up multicast groups, enables creation of a sequence of expiring Group Multicast keysIndependent Pairwise and Group Keys in the IBSS

7. 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 frames3 message handshake using 802.11 Authentication frames • Group Key derived from 1st derived PMK (from first associating STA) in the BSS • Upon Authentication or roaming, new STA requests AP to send it the Group Key • AP retrieves GK, TKIP/AES encrypts using new STA’s PK and sends back • Uses 802.11-99 standard Authentication frames with new Information Elements • 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 PK and just start transmitting encrypted packets • Encryption, MIC failures result in STA Disassociation and Deauthentication

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

9. 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 AssociationsEquivalent to a re-initialization • Don’t Make Me Guess Which Key to Use, Tell me • Every Pairwise addressed 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 Group addressed BSS RA/TA pair supports the following four keys: 00 – Group Multicast ping key derived from GMK, GN0 01 – Group Multicast pong key derived from GMK, GN1 10 - Group Broadcast ping key derived from GMK, GN2 11 – Group Broadcast pong key derived from GMK, GN3 • 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

10. Now, Let’s Tie this All Together

11. 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, 128, 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

12. IBSSGroup Secret (IBSSGS) First Infr BSS PMK TKIP Michael AES RC4 RSN Group Key Hierarchy From AP From UI PRF (IBSSGS, “dot11ibssGMK”, 0) PRF (PMK, “dot11infrGMK”, 0) Infrastructure Group Master Key (256b) IBSS Group Master Key (256b) IBSS GMK IBSS only Infrastructure BSS only GN GMK BSS: Random Number generated by AP IBSS= 0 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

13. Example 1- 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, GKX retrieved and transported Derives PK using PMK1 and PN1, uses GKX STA1 exchanges encrypted unicasts with, receives encrypted broadcasts from APX • STA1 wanders over into range of APY- RoamsIssues Probe, Receives Probe Response from APY • Detected support for ULA 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 • GKY 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

14. Example 2- 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 Performs RSKA Authentication and PTP exchange • STA1 Authenticated, PMK1 derived, GKX 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- 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 • GKY 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

15. Example 3- IBSS, Group and Pairwise Keying STA1, STA2 , STA3 decide to ad-hoc network, exchange common secret X-> GMKX • STA1 establishes IBSSSTA1issues 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 PK 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 PK using PMKY and PNB, STA2 and STA3 exchange two-way private unicasts because only they know PMKY

16. 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’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 Draft Text, 02/xxxr0, available 6/15 • Propose further ARSN discussion, and motions to adopt in whole or in part in Vancouver