1. “ARSN” An Adjunct RSN Proposal Carlos Rios RiosTek 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
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 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

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

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

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, provide - 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 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

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

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

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 BSS RA/TA pair supports three distinct keys, using the 2 bit KeyID within the IV field to indicate: Pairwise key derived from PMK, PN – Not Used Group Broadcast ping key derived from GMK, GN – Group Broadcast pong key derived from GMK, GN1
Every IBSS RA/TA pair supports the following three keys: – Pairwise-secret key derived from Preshared Pairwise Secret, PN – Pairwise group-secret key derived from Preshared Group secret, PN Group Broadcast key derived from Preshared Group Secret – Not Used

10. Now, Let’s Tie this All Together

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

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

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

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

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