doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 1 “ARSN” An Adjunct RSN Proposal Carlos Rios RiosTek LLC

doc.: IEEE /360r0 Submission May 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 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 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 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

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

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

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 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 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 (as in D2.0), support - Mutual Authentication - Unicast, multicast and broadcast messaging - TKIP and AES Privacy Replay Detection Message Authentication

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 6 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 Multiple sets of Group (multicast) ping, pong keys per (Group Addressed) 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 1 st 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

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 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 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 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 standard Authentication frames with new Information Elements 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

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

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 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 Associations Equivalent 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, GN 0 11 – Group Broadcast pong key derived from GMK, GN 1 –Every Group addressed BSS RA/TA pair supports the following four keys: 00 – Group Multicast ping key derived from GMK, GN 0 01 – Group Multicast pong key derived from GMK, GN Group Broadcast ping key derived from GMK, GN 2 11 – Group Broadcast pong key derived from GMK, GN 3 –Every IBSS RA/TA pair supports the following three keys: 00 – Pairwise-secret key derived from Preshared Pairwise Secret, PN 0 01 – Pairwise group-secret key derived from Preshared Group secret, PN Group Broadcast key derived from Preshared Group Secret 11 – Not Used

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 10 Now, Let’s Tie this All Together

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 11 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 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 /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 12 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, 128, 64) TKIP Mixing Function TKIP PPEncryption KeyTKIP Michael AES IV RA TA RC4 GMK GN 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) GKeyID From AP IBSS GMK IBSS onlyInfrastructure BSS only BSS: Random Number generated by AP IBSS= 0

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 13 Example 1- 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, GK X retrieved and transported Derives PK using PMK 1 and PN 1, uses GK X STA 1 exchanges encrypted unicasts with, receives encrypted broadcasts from AP X STA 1 wanders over into range of AP Y - Roams Issues Probe, Receives Probe Response from AP Y –Detected support for ULA 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 –GK Y in use for some time, transported to STA 1 Derives PK using PMK 1 and PN 2, uses GK Y as is Exchanges encrypted unicasts with, receives encrypted multicasts from AP Y

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 14 Example 2- 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 Performs RSKA Authentication and PTP exchange –STA 1 Authenticated, PMK 1 derived, GK X retrieved and transported Issues Association Request, receives Association Response –Agreed on RSKA ASE, AES UCSE, AES MCSE, Negotiated PN 1 Derives PK using PMK 1 and PN 1, uses GK X as is 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 –GK Y in use for some time, transported to STA 1 Derives PK using PMK 1 and PN 2, uses GK Y as is Exchanges encrypted unicasts with, receives encrypted multicasts from AP Y

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 15 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 issues Beacon –STA 2, STA 3 detect support for RSKA, TKIP 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 PK 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 PK using PMK Y and PN B, STA 2 and STA 3 exchange two-way private unicasts because only they know PMK Y

doc.: IEEE /360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 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 management protocols Still, many little steps produce a big change The 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