Doc.: IEEE 802.11-02/360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 1 “ARSN” An...

doc.: IEEE 802.11-02/360r0

Submission

May 2002

Carlos Rios, RiosTek LLC

“ARSN” An Adjunct RSN Proposal

Carlos RiosRiosTek LLC

doc.: IEEE 802.11-02/360r0

Submission

May 2002


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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


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 availableThe heavy lifting IS done- draft text is almost ready for incorporation into D2.0

doc.: IEEE 802.11-02/360r0

Submission

May 2002


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 802.11-02/360r0

Submission

May 2002


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 802.11-02/360r0

Submission

May 2002


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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


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 frames

3 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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


Hole Plugging, Continued• Add new Information Elements, Status, Reason Codes

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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


Now, Let’s Tie this All Together

doc.: IEEE 802.11-02/360r0

Submission

May 2002


RSN Pairwise Key Hierarchy

Pairwise Transient Key (PTK) = PRF (PMK, “dot11PTK”, Min(TA,RA) || Max(TA,RA) || PN)

Temporal TKIP/AES Encryption KeyL(PTK, 0, 128)

Temporal TKIP MIC KeyL(PTK, 128, 64)

TKIP Mixing Function

TKIP PP Encryption Key TKIP Michael

AES

IV

RA

TA

RC4

PMK PN RA TA

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 ASFrom AP or IBSS Peer

PKeyID

PSK PMK Infrastructure (ULA) only

Infrastructure (RSKA) and IBSS

doc.: IEEE 802.11-02/360r0

Submission

May 2002


RSN Group Key Hierarchy

Group Transient Key (GTK) = PRF (GMK, “dot11GTK”, GN)

Temporal TKIP/AES Encr KeyL(GTK, 0, 128)

Temporal TKIP MIC KeyL(GTK, 128, 64)

TKIP Mixing FunctionTKIP PPEncryption Key TKIP Michael

AES

IVRA

TA

RC4

GMKGN

First InfrBSS 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 only InfrastructureBSS only

BSS: Random Number generated by APIBSS= 0

doc.: IEEE 802.11-02/360r0

Submission

May 2002


Example 1- BSS, Upper Layer AuthenticationSTA1 credentialed with ASA , ASA services ESSB (APX, APY and APZ )• STA1 powers up in range of APX - Initializes

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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


Example 2- 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, 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- Roams Issues 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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


Example 3- 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 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-> PMKY

STA2 and STA3 already share GMKX and GNA

STA3 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

doc.: IEEE 802.11-02/360r0

Submission

May 2002


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

Doc.: IEEE 802.11-02/360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 1 “ARSN” An...

Documents

Transcript of Doc.: IEEE 802.11-02/360r0 Submission May 2002 Carlos Rios, RiosTek LLC Slide 1 “ARSN” An...