Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-05/1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 1 Proposed PeerKey Handshake Notice: This document has been prepared to assist.

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-05/1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 1 Proposed PeerKey Handshake Notice: This document has been prepared to assist."— Presentation transcript:

1 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 1 Proposed PeerKey Handshake Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// Date:

2 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 2 Abstract This submission proposes normative text suitable for incorporation into REVma. This submission addresses security flaws identified in STAKey key exchange. •Proposal Text Doc#: m-normative- text-peerkey-handshake-proposal

3 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 3 Agenda •Design Goals •Acronyms •PeerKey Handshake •PeerKey Rekeying •PeerKey Error Handling •Proposal Text Walkthrough

4 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 4 Design Goals •Provide Secure Key Exchange method to exchange keys for direct STA-to-STA communication •Keep the Key Exchange Generic –Allow use by DLS now –Allow use by any future STA-to-STA (Infrastructure BSS) protocol •Allow PeerKey enabled and non-PeerKey enabled devices to co-exist •Utilize existing security mechanisms where possible •Provide solution to Security & Definition Flaws –identified by # r0

5 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 5 Definition of PeerKey Security 1.A fresh (i.e., a never-before-used) PeerKey session key between the two STAs should result 2.The Initiator and Peer STA should derive the same session key 3.The derived session key should be known only to the initiator and peer STA if all parties follow the rules 4.Mutually authenticate the initiator and peer STAs 5.Distinguish this session from all other instances of the key distribution protocol 6.The initiator and peer STAs verify that each is alive

6 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 6 Acronyms •STSLStation to station link e.g. DLS •SMKSTSL master key •SMKSASMK security association •STKSTSL transient key •STKSASTK security association •SKEKSTSL key encryption key •SKCKSTSL key confirmation key •MUIMessage unique identifier

7 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 7 PeerKey Handshake •Used to exchange Keys to enable STA-to-STA security –Replaces STAKey (defined in i-2004) •Assumption –AP has establish RSNA with each STA –STAs have established STSL (e.g. DLS) with each other –EAPOL frames are used for this exchange –AP is trusted to forget SMK after SMK Handshake •PeerKey handshake has two key parts, –SMK Handshake (STA-AP-STA) –4-Way STK Handshake (STA-STA)

8 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 8 PeerKey Handshake INonce, MAC I, MAC P, RSNIE_I AP STA I STA P INonce, MAC P, MAC I, RSNIE_I INonce, PNonce, MAC P, MAC I, RSNIE_P SMK, PNonce, Lifetime, INonce, MAC P, MAC I SMK, INonce, Lifetime, PNonce, MAC I, MAC P, RSNIE_P ANonce, SMKID SMKSA Installed SNonce, SMKID, RSNIE_P, Lifetime ANonce, RSNIE_I, Lifetime Ack STKSA Installed SMK Handshake 4-Way STK Handshake

9 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 9 PeerKey Advertisements RSNIE Update •Allocate one bit of the RSN IE Capability field for PeerKey  Used to indicate that device supports PeerKey handshake RSN Capability fieldsBits Pre-auth0 No Pairwise1 PTKSA replay counter2:3 GTKSA replay counter4:5 PeerKey Enabled9 Reserved6:8 & 10:15

10 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 10 PeerKey KDEs SMK KDEUsed for exchanging SMK Key and Nonce of destination STA. It’s used during SMK Handshake Nonce KDEUsed for exchanging Nonce value. It’s used during SMK Handshake for sending Nonce values Lifetime KDEUsed for exchanging Key Lifetime value. It’s used during SMK and STK 4-Way Handshake for sending SMK Key lifetime value Error KDEUsed for providing Error details. Used for sending error information occurred during SMK handshake

11 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 11 EAPOL Frame Change Key Type 0: Group/SMK 1: PTK SMK Message 1: Frame part of SMK Handshake 0: Non-SMK Handshake Error: 1: If SMK Message bit is set, key data field contains Error KDE

12 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 12 PeerKey Key Hierarchy SMKID = HMAC-SHA1-128(SMK, "SMK Name" || PNonce || MAC_P || INonce || MAC_I)

13 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 13 EAPOL-Key Frame Notation EAPOL-Key(S, M, A, I, K, SM, KeyRSC, ANonce/SNonce, MIC, DataKDs) SSecure bit of the Key Information field. MMIC is available in Key Information field. Ameans a response is required to this message IInstall bit: Install/Not install bit of the Key Information field Kkey type: P (Pairwise), G (Group/SMK) SMSMK Message bit: is part of SMK handshake KeyRSCKey RSC field. ANonce/SNonceAuthenticator/Supplicant nonce MICintegrity check, generated using the KCK or SKCK DataKDssequence of zero or more Information Elements and KDEs

14 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 14 SMK Handshake •Message 1: Initiator STA  AP –EAPOL-Key(1,1,0,0,0,1,0, INonce, MIC, RSNIE_I, MAC_P KDE) •Message 2: AP  Peer STA –EAPOL-Key(1,1,1,0,0,1,0, INonce, MIC, RSNIE_I, MAC_I KDE) •Message 3: Peer STA  AP –EAPOL-Key(1,1,0,0,0,1,0, PNonce, MIC, RSNIE_P, MAC_I KDE, INonce KDE) •Message 4: AP  Peer STA –EAPOL-Key(1,1,0,1,0,1,0, PNonce, MIC, MAC_I KDE, INonce KDE, SMK KDE, Lifetime KDE) •Message 5: AP  Initiator STA –EAPOL-Key(1,1,0,0,0,1,0, INonce, MIC, RSNIE_P, MAC_P KDE, PNonce KDE, SMK KDE, Lifetime KDE)

15 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 15 4-Way STK Handshake •Message 1. Initiator STA → Peer STA: –EAPOL-Key(0,0,1,0,P,0,0,ANonce, SMKID KDE) •Message 2. Peer STA → Initiator STA: –EAPOL-Key(0,1,0,0,P,0,0,SNonce,MIC, RSNIE_P, Lifetime KDE, SMKID KDE) •Message 3. Initiator STA → Peer STA: –EAPOL-Key(1,1,1,1,P,0,0,ANonce,MIC, RSNIE_I, Lifetime KDE) •Message 4. Peer STA → Initiator STA: –EAPOL-Key(1,1,0,0,P,0,0,0,MIC,0)

16 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 16 PeerKey Rekeying •Always initiated by Initiator STA (STA I) •If Peer STA (STA P) wants to initiate rekeying, it sends EAPOL request message to Initiator STA •Two possible method of rekeying –If SMK timer has not expired, STA I will initiate 4-way handshake to create new STK. –If the SMK has expired, STA I will start from scratch and start the SMK handshake followed by 4-way handshake to create new keys.

17 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 17 PeerKey Error Handling •Errors are reported during PeerKey Handshake –EAPOL-Key frames are used for this purpose •Error ERR_STA_NR: AP finds destination STA is not reachable –Sent to other STA –After receiving frame STA shall tear down STSL & clear all the STK states •Error ERR_STA_NRSN: AP finds no RSNA with destination STA –Sent to other STA –After receiving frame STA shall tear down STSL & clear all the STK states •Error ERR_CPHR_NS: STA doesn’t support proposed Cipher suites –Sent to other STA (through AP) –After receiving frame STA shall tear down STSL & clear all the STK states •Error ERR_NO_STSL: STA doesn’t have existing STSL with other STA –Sent to other STA (through AP) –After receiving frame STA shall tear down STSL & clear all the STK states

18 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 18 Proposal Text Walkthrough •Open Proposal Text Doc#: m-normative-text- peerkey-handshake-proposal

19 doc.: IEEE /1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 19 Feedback?


Download ppt "Doc.: IEEE 802.11-05/1264r0 Submission Jan 2006 STAKey Ad-hoc Group.Slide 1 Proposed PeerKey Handshake Notice: This document has been prepared to assist."

Similar presentations


Ads by Google