March 2007 doc IEEE 802 11 070357 r

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 PLE Comment Resolution Date: 2007 -03 -14 Authors: Notice: This document has been prepared to assist IEEE 802. 11. 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 802. 11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http: // ieee 802. org/guides/bylaws/sb-bylaws. pdf>, 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 <stuart. kerry@philips. com> 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 802. 11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee. org>. Submission 1 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Abstract This submission summarizes the proposed updates to resolve comments from LB 93 on Peer Link Establishment protocol Submission 2 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Agenda • Protocol overview • Comment resolution summary • Major updates – – – Submission Finite State Machine Configuration parameters Randomness of link IDs Interface Reason codes 3 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Protocol Overview Open(A, B, Link. ID A) Open(B, A, Link. IDB) A B Confirm(B, A, Link. IDB, Link. IDA) Confirm(A, B, Link. IDA, Link. IDB) Open(A, B, L ink. IDA) A Open(B, A, L B, Lin ID k in L , A , (B Confirm k. IDA) B Confirm(A, B, Lin k. IDA, Link. IDB) Submission 4 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Protocol Design • Overall protocol design is unchanged – 4 -message exchange is necessary to satisfy the protocol requirements (see protocol requirements) – Link ID is essential to prevent race conditions (see Link ID issue) • CIDs 12, 1183, 1184, 1185, 1811, 1952, 3835, 4979, 1594, 2427 – Holding state – Timer model • Name change: Peer Link Management protocol – New name represents the protocol functionality better Submission 5 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Summary of PLE comments • Finite state machine – CIDs 1148, 1647, 3624, 3837, 3975, 3976, 4339, 4346, 4347, 4348, 4351, 4353, 4356, 4359, 4360, 4361, 3839, 4216, 4217, 4354, 4363 • Configuration parameters – CIDs 3981, 4355, 4362 • Randomness of link IDs – CIDs 12, 1183, 1184, 1185, 1811, 1952, 3835, 4979, 1594, 2427 • Reason codes – CIDs 203, 1147, 1638, 1811, 2452, 2672, 5301, 5302, 5303, 5304, 5305, 5309, 5312, 5313, 5314, 5315, 5319, 5641 • Interface specification – CIDs 1146, 1209, 2193, 2428, 3980, 4321, 4748, 5264, 5265, 5266, 5267, 5268, 5269, 5272, 5273, 5274, 5275, 5277, 5278, 5279, 5280, 5281, 5282, 5283, 5284, 5286, 5287, 5288, 5292, 5293, 5295, 5296, 5297, 5299, 5300, 5306, 5307, 5308, 5311, 5310, 5311, 5316, 5317, 5318 • Others – CIDs 2325, 3560, 4325, 3623, 4783, 5656, 4805, 1210, 2191, 3833 Submission 6 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Comments on Finite State Machine • Comments – CIDs 1148, 1647, 3624, 3837, 3975, 3976, 4339, 4346, 4347, 4348, 4351, 4353, 4356, 4359, 4360, 4361, 3839, 4216, 4217, 4354 • Issues – – – Submission Conditional state transition for message processing and retry timer Add a diagram Abbreviations for specification Need a link IDs? (see 07/0237 r 0) Need 4 -message exchange? (see 07/0237 r 0) Misc issues 7 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Updates to FSM • More events – Message classification (OPN_ACPT, OPN_RJCT, OPN_IGNR, …) – Timeout with Max. Retries (TOR 1, TOR 2) • All states, events, actions are specified using abbreviations • Add a diagram Submission 8 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Example of Updated FSM Submission 9 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Comments on Configuration Parameters • Comments, CIDs 3981, 4355, 4362 • Issue: – Configuration parameters are not defined – No description on how to handle them Submission 10 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Updates • Define configuration parameters for message processing – Fields in Mesh Capability element • • • “Operating as MP” Supporting Power Save Mode Require Power Save Mode from Peer Supporting Synchronization MDA Active Request in Mesh – Fields in Active Profile Announcement – RSN information element Submission 11 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Comments on Link IDs • Comments – CIDs 12, 1183, 1184, 1185, 1811, 1952, 3835, 4979 • Issues – Why they are random? – What’s the scope of random numbers? – 4 -octet number are too long Submission 12 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Updates • Requirement of link IDs – Unique among all peer links by the MP – Haven’t been used recently to identify a peer link by the MP • Hence, the link IDs can be either random or deterministic • Resolution: – Use deterministic numbers – Clearly specify the requirements – Length: 2 octets Submission 13 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Comments on Reason Codes • Comments – CIDs 203, 1147, 1638, 1811, 2452, 2672, 5301, 5302, 5303, 5304, 5305, 5309, 5312, 5313, 5314, 5315, 5319, 5641 • Issues – Should try to re-use existing reason codes – Define new ones in Clause 7. 3. 17 – Consistent specification on reason code usage Submission 14 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Updates Reason code Meaning 46— 65 535 Reserved 46 “MESH-LINK-CANCELLED”. IEEE 802. 11 SME cancels the link instance with the reason other than reaching the maximum number of neighbors 47 “MESH-MAX-NEIGHBORS”. The Mesh Point has reached the supported maximum number of neighbors 48 “MESH-CAPABILITY-POLICY-VIOLATION”. The received information violates the Mesh Capability policy configured in the Mesh Point profile 49 “MESH-CLOSE-RCVD”. The Mesh Point has received a Peer Link Close message requesting to close the peer link. 50 “MESH-MAX-RETRIES”. The Mesh Point has re-sent dot 11 Mesh. Max. Retries Peer Link Open messages, without receiving a Peer Link Confirm message. 51 “MESH-CONFIRM-TIMEOUT”. The confirm. Timer for the mesh peer link instance times out. 52— 65 535 Submission Reserved 15 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Comments on Interface • Comments – CIDs 1146, 1209, 2193, 2428, 3980, 4321, 4748, 5264, 5265, 5266, 5267, 5268, 5269, 5272, 5273, 5274, 5275, 5277, 5278, 5279, 5280, 5281, 5282, 5283, 5284, 5286, 5287, 5288, 5292, 5293, 5295, 5296, 5297, 5299, 5300, 5306, 5307, 5308, 5311, 5310, 5316, 5317, 5318 • Issues – Passive. Open, Active. Open, Cancel. Link, Signal. Status primitives are not needed – Inconsistency in specification – Vague specification on how to use them – Incorrect specification on interaction between SME and MAC Submission 16 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Updates • Interface is essential for control the behavior of the MP – Control creation and deletion of FSM – Control protocol initiation – Control # peer links • Updated definition – – Submission MLME-Passive. Peer. Link. Open(local. Link. ID) MLME-Active. Peer. Link. Open (peer. MAC, local. Link. ID) MLME-Cancel. Peer. Link(local. Link. ID, Reason. Code) MLME-Signal. Peer. Link. Status. indication(local. Link. ID, status. Code) 17 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Motion • Comment CID 1417: Is an 802. 11 Authentication frame required prior to transmission of link establishment frames? • Motion: – Add the following sentence at the end of the first paragraph of Clause 8. 2: “Open System Authentication and Deauthentication shall not be used between MPs. ” Submission 18 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Backup Slides from 11 -07/237 r 0 Submission 19 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design Motivation • The security synchronization and consistency functions require robust peer link maintenance – Link is necessary prerequisite for security session between MPs – Security handshake must achieve a consistent state between MPs – Tearing down the link needs to be done with substantial care to maintain security – Control protocol variance • Efficiency – Minimum number of message exchange – Minimize communication overhead Submission 20 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Peer Link and Security Handshake Peer Link Establishment Authentication Abbreviated Security Handshake 4 -Way Handshake Submission 21 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Peer Link and Security Handshake Peer Link Establishment Peer Link Open (…, Security. HSIE) Authentication Peer Link Confirm (…, Security. HSIE) 4 -Way Handshake Submission 22 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Protocol Requirements • (At least) 3 Classes of Requirements exist: – Security requirements – Functional requirements – Performance requirements • Security Requirements – Achieve the consistency property • both parties must agree on the protocol state, or else the protocol should fail • Man-in-the-middle attacks are possible if this is violated – Special case 1: Achieve the matching conversation property • • Submission Both parties demonstrably send and receive the same messages Essential for mutual authentication Provable security impossible without it Alternatives: use the Client/Server model or introduce more messages 23 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Protocol Requirements • Security Requirements (Continued) – Special case 2: Bind a fresh security context to the link instance • • Establish a (statistically) unique instance (session) identifier Demonstrate peer liveness (special case of consistency property) Guarantee a fresh session key and bind it to the communicating MPs Synchronize session key use – Make messages fully meaningful within the security context • The instance security context should be sufficient to make a message meaningful • Messages with incomplete information ignored – Maintain secrecy of the link instance key to the communicating MPs Submission 24 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Protocol Requirements • Functional requirements – Handle simultaneity • Either party should be able to initiate a new link instance at any time – Verifiable parameter negotiation • Protect discovery and negotiation from Downgrade attack • Unverifiable parameters enable man-in-the-middle attacks, and slow recovery from protocol failures – Simplicity • Utilize local resource whenever possible; Invoke external protocol only when it’s necessary • Performance requirements – Efficiency • Use as few messages as possible • Minimize communication overhead – Failure cases should not impose undue delay Submission 25 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Agenda • Protocol requirements • Failure case analysis • Protocol detail – Basic peer link establishment (maintenance) protocol – Abbreviated handshake Submission 26 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 What about naïve solutions? Submission 27 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Protocol in Draft 0. 4 (1) A B Association Request (Ra) Association Response Superordinate MP Submission 28 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Protocol in Draft 0. 4 (2) B A Association Request (Ra) Association Request (Rb) Ra > Rb? Subordinate MP Superordinate MP Association Response (accept) Association Response (deny) Submission 29 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Example: Transition Over Reboot B A R 1 reboot Association Request (R 1) Association Response ? ? Superordinate MP Violation: • Consistency property – no guarantee peers achieve the same state • Matching conversation – no matching of sent and received messages • Bind a fresh security context to the link instance – no notion of link instance – messages may not be fresh • Verifiable parameter negotiation • Failure cases should not impose undue delay Submission 30 Zhao and Walker, Intel Corp

March 2007 A doc. : IEEE 802. 11 -07/0357 r 1 Example: Half-Open Connection B Association Request (Ra) Association Request (Rb) Ra > Rb? Association Response (accept) Idle Superordinate MP Association Response (deny) Data Frame …. Transmission Failure Disassociate Request Submission 31 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Example: Half-Open Connection Violation: • Consistency property – peers not guaranteed to achieve the same state • Bind a fresh security context to the link instance – no notion of link instance – messages may not be fresh • Verifiable parameter negotiation • Failure cases should not impose undue delay A B Association Request (Ra) Association Request (Rb) Ra > Rb? Association Response (accept) Idle Superordinate MP Association Response (deny) Data Frame …. Transmission Failure Disassociate Request Submission 32 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Example: Tie Break Failure R 1 Association Request (R 1) Association Request (R 2) R 2 timeout R 1’ Association Request (R 1’) R 1 > R 2? Association Response R 1’ > R 2? Association Response Superordinate MP Two Superordinate MPs not a valid state in current protocol Root problem: numbers used for tie break are transmitted separately. Submission 33 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Example: Tie Break Failure Root problem • numbers used for tie break are transmitted separately. Violation: • Consistency property – no guarantee to achieve the same states • Matching conversation – no matching of sent and received messages • Bind a fresh security context to the link instance – no notion of link instance – messages do not confirm the random numbers for tie breaking • Messages are fully meaningful to the context • Don’t know whether association request (R 1’) belongs to the context • Verifiable parameter negotiation • Failure cases should not impose undue delay • The protocol should handle all possible failure cases Submission 34 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Can we simply drop tie-breaking scheme? B A Association Request pending Association Response (accept) Established Authenticator: waits for supplicant to initiate authentication Violation: • • • Handle simultaneity Consistency property – no guarantee to achieve the same states Matching conversation – no matching of sent and received messages Verifiable parameter negotiation Failure cases should not impose undue delay Submission 35 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Agenda • Protocol requirements • Failure case analysis • Protocol detail – Basic peer link establishment (maintenance) protocol • Design rationale • FSM • Example execution scenarios – Abbreviated handshake Submission 36 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 PLE Protocol Design Rationale Submission 37 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Both MPs Should Respond • Consistency property – Each MP needs to confirm the states of the link – Each MP needs to know when the protocol succeeds • Verifiable parameter negotiation – Each MP should confirm that it agrees with the parameters • Handle simultaneity – No requirement on who responds to request • Control failure variance – Response is expected or it’s a failure case Submission 38 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Call for Instance Identifier • Instance Identifier is necessary for – – – – • Identify one instance of the connection between two MPs Avoid livelock and deadlock Message binding with the session Guarantee liveness of the MPs Support key session binding Orderly close the session Defend against simple Do. S attacks Requirements – Reasonably fresh (not used recently) – Guaranteed unique number among active sessions between peer MPs • Approach – Random link IDs by each MPs (my. Link. ID, peer. Link. ID) – <my. MAC, peer. MAC, my. Link. ID, peer. Link. ID> uniquely identify the session (statistically) – Messages binds with the instance identifier Submission 39 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Call for Peer Link Close Message • Close messages are necessary for – – – Avoid deadlocks and livelocks Bound the protocol variance Efficiency in closing a connection Support key session binding Defend against simple replay attack • Requirement – Close message binds with instance identifier • Approach – Include link IDs in the message – Optimization: can include only peer. Link. ID Submission 40 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 A “Semi” 4 -message Version • Design Rule – Both MPs shall send Peer Link Confirm – Both MPs shall receive Peer Link Confirm – MPs shall agree on (Ra, Rb) for this session b) k Open(R Peer Link Open(R a) A • Satisfy – Bind fresh context to instance – Handle simultaneity – Verifiable parameter negotiation – Simplicity – Efficiency Submission (Rb, Ra) P Confirm eer Link Peer Link Confir m(Ra, Rb) 41 Zhao and Walker, Intel Corp B

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 A “Semi” 4 -message Version (Rb) en Peer Link Op Peer Link Confir A m(Ra, Rb) B rm(Rb, Ra) nfi Peer Link Co • Violation – Consistency property – does not guarantee both parties will send and receive same messages – Matching conversation property • Essential requirement for provable security Submission 42 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 4 -Message Protocol • Rules – Both MPs shall send both Open and Confirm messages – Both MPs shall receive both Open and Confirm messages – Both MPs shall agree on (Ra, Rb) for link instance • To satisfy requirements – Handle all failure cases • Finite State Machine – Bound failure variance • Close message, holding state, Cancel. Timer • Retransmission: Retry. Timer and MAX_REQ • Deadlock avoidance: Open. Timer Submission 43 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Set Up a Link Open(A, B, Ra) Open(B, A, Rb) A B Confirm(B, A, Rb, Ra) Confirm(A, B, Ra, Rb) Open(A, B, R b) Open(B, A, R a) A Submission Confirm(B, A, Confirm(A, B, Ra , Rb) 44 Rb, Ra) B Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Tear Down a Link • Either initiated by SME • Or caused by receipt of Peer Link Close • Rule: – Close message provides binding with the session – Use grace period to handle messages in flight – Timer controls grace period • Advantages – Satisfy all protocol requirements for both security and non-security cases – Ease of implementation: implement only one finite state machine for security and non-security cases Submission 45 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Agenda • Protocol requirements • Failure case analysis • Protocol detail – Basic peer link establishment (maintenance) protocol • Design rationale • FSM • Example execution scenarios – Abbreviated handshake Submission 46 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Finite State Machine • • States – – – – – 0. IDLE 1. LISTEN 2. OPEN_SENT 3. CONFIRM_RCVD 4. CONFIRM_SENT 5. ESTABLISHED 6. HOLDING • Events Actions Cancel. Peer. Link (CNCL) Passive. Peer. Link. Open (PAS) Active. Peer. Link. Open (ACT) Close. Received (CLR) Open. Received (OPR) Confirm. Received (CNR) Timeout (Retry. Timer) (TOR) Timeout (Open. Timer) (TOO) Timeout(Cancel. Timer) (TOC) – Send. Close (SCL) – Send. Open (SOP) – Send. Confirm (SCN) Submission 47 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Summary of Finite State Automaton Close / - Legend transition end. Open Active. Open / S 2 Op 1 Op en / S end O pen + C Close / Close onfir m C 4 Timeout(Retry. Timer) / Send. Open 5 m/onfir firm Cancel. Link / - O d. Con 0 Passiv. Open / - /S / Sen ve ti Ac n pe Open d en rm onfi n/C Ope en Cancel. Link or *Timeout (Retr y. Time r) / Se Cance nd. Clo l. Link se or. T im eo 3 Confirm / ut( Op en Cl Tim os e e/- r ) /C los e Open / Send. Confirm Close / - Can cel Lin k Cancel. Link / Close or *Timeout (Retry 6 Open / Close Confirm / Close / - Event / Action Timeout(Retry. Timer) / Send. Open se d. Clo n e S r) / Time Cancel. Link or Timeout(Cancel. Timer) / Send. Close 0: IDLE 1: LISTEN Submission 2: OPEN_SENT 3: CONFIRM_RCVD 48 5: ESTABLISHED 4: CONFIRM_SENT 6: HOLDING Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Finite State Machine State Transitions 0 1 2 3 4 5 6 CNCL -→ 0 SCL → 6 -→ 6 PAS -→ 1 -→ 2 -→ 3 -→ 4 -→ 5 -→ 6 ACT SOP → 2 -→ 3 -→ 4 -→ 5 -→ 6 CLR -→ 0 -→ 1 -→ 6 or - → 2 -→ 6 or - → 3 -→ 6 or - → 4 - → 6 or -→ 5 -→ 6 OPR -→ 0 SOP, SCN → 4 or SCL → 1 SCN → 4 or SCL → 6 SCN → 5 or - → 3 SCN → 4 or - → 4 SCN → 5 or - → 5 SCL → 6 or - → 6 CNR -→ 0 -→ 1 -→ 3 or SCL → 6 -→ 3 SCN → 5 or SCL → 6 -→ 5 SCL → 6 or - → 6 TOR -→ 0 -→ 1 SOP → 2 or SCL → 6 -→ 3 SOP → 4 or SCL → 6 -→ 5 -→ 6 TOO -→ 0 -→ 1 -→ 2 SCL → 6 -→ 4 -→ 5 -→ 6 TOC -→ 0 -→ 1 -→ 2 -→ 3 -→ 4 -→ 5 SCL → 0 0: IDLE 1: LISTEN Submission 2: OPEN_SENT 3: CONFIRM_RCVD 5: ESTABLISHED 6: HOLDING 49 4: CONFIRM_SENT Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Agenda • Protocol requirements • Failure case analysis • Protocol detail – Basic peer link establishment (maintenance) protocol • Design rationale • FSM • Example execution scenarios – Abbreviated handshake Submission 50 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Sessions over Reboot (Rb 1) en Peer Link Op Peer Link Confirm (Ra 1, Rb 1) A Holding Peer Link Close(R Reboot en Peer Link Op (Rb 2) B Ignore a 2, Rb 2) Ra 2) k Close(Rb 2, Close Peer Lin Submission 51 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Retries retry. Timer. A Peer Link Open(Ra) retry. Timer. B en (Rb) Peer Link Op ) nfirm (Rb, Ra Peer Link Co Peer Link Open(Ra) en (Rb) Peer Link Op … Peer Link Close (Ra, null) Peer Link Close (Rb, Ra) Submission 52 B MAX_REQ A rm (Rb, Ra) nfi Peer Link Co Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Open Timer Peer Link Open(Ra) (Rb) eer Link Open P … Peer Link Close (Rb, Ra) B MAX_REQ open. Timer. A A retry. Timer. B en (Rb) Peer Link Op ) nfirm (Rb, Ra Peer Link Co Peer Link Close (Ra, Rb) Submission 53 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Cancel Timer (holding timer) en Peer Link Open(Ra) Peer Link Close(Ra, Rb) A B … Holding cancel. Timer ) nfirm (Rb, Ra o C k in L r e e P Peer Link Close(Ra, Rb) cancel. Link (Rb) Idle Submission 54 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Agenda • Protocol requirements • Failure case analysis • Protocol detail – Basic peer link establishment (maintenance) protocol – Abbreviated handshake Submission 55 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Abbreviated Handshake Submission 56 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design Issues • Opportunity – Overlay security handshake with the basic peer link establishment protocol – Better efficiency—less than 8 messages to establish a secure peer link between MPs • Challenges – Design a most efficient protocol – Maintain the robustness of peer link establishment – Maintain the security of peer MP authentication and key management Submission 57 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Peer Link Messages • Peer Link Open(my. MAC, peer. MAC, ANonce, PMK, Ciphersuite, GTK, MIC) • Peer Link Confirm(my. MAC, peer. MAC, ANonce, BNonce, PMK, Ciphersuite, MIC) • Peer Link Close(my. MAC, peer. MAC, ANonce, BNonce, MIC) Submission 58 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Proposed Abbreviated Security Handshake Beacon/Probe Response PMK Usage Negotiation Beacon/Probe Response Cipher Suite Negotiation Open(ANonce, PMKInfo, Cipher Suite Info, GTK 1, MIC) Open(BNonce, PMKInfo, Cipher Suite Info, GTK 2, MIC) A B Using Derived Keys Confirm(BNonce, ANonce, PMKInfo, Cipher Suite Info, MIC) Confirm(ANonce, BNonce, PMKInfo, Cipher Suite Info, MIC) Submission 59 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Major Functional Components • PMK Usage Negotiation – Both MPs have established their EMSA key hierarchies – Decide the one PMK to use based on local cache information • Pairwise Cipher Suite Negotiation – Decide the pairwise cipher suite supported by both MPs • Key Derivation Algorithms – Information in Peer Link Open has to be protected – Relevant keys should be ready when sending Peer Link Open message – Some keys may not depend upon the nonces Submission 60 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 PMK Usage Negotiation (1) • PMK Negotiation is needed – Both MPs have their own key hierarchy – Both, one, or neither of them has the peer MP’s PMK-MA • Requirements – Efficiency • Speed: Completed using at most two messages • Resource: Only execute key transport protocol when necessary – Minimize the impact by Do. S attacks • Protocol always succeeds if a shared PMK exists • Avoid unnecessary key transport protocol executions Submission 61 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 PMK Usage Negotiation (2) • MPs announce their PMK-MKDName in the beacons and probe responses • Rule: Try the peer MP’s PMK-MA • Peer Link Open message contains the corresponding PMKMAName • MIC is computed to prove the knowledge of the chosen PMK – KCK is derived from the chosen PMK-MA Peer Link Open(…, PMK-MAName 1, …) A Submission Peer Link Open (…, PMK-MAName 2, …) 62 B Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 PMK Negotiation Cases Case 1 ? Case 2 PMKB Case 3 Peer Link Open (…, PMKA, …) A Peer Link Open (…, PMKB, …) B ? Peer Link Open (…, PMKB, …) PMKB PMKA A Peer Link Open (…, PMKA, …) B Peer Link Open (…, PMKA, …) Higher MAC address Submission 63 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Pairwise Cipher Suite Negotiation (1) • MPs announce the supported pairwise cipher suites in beacons and probe responses • The master MP makes the choice (if more than one choices available) • Both MP should confirm the pairwise cipher suite list heard from the peer MP • Protect against RSN IE forgery attack Terminology: Master MP (MMP): the MP with higher MAC address Slave MP (SMP): the MP with lower MAC address Submission 64 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Pairwise Cipher Suite Negotiation (2) Peer Link Open(…, C, LLA, PLA, …) Peer Link Open (…, _, LLB, PLB, …) A Peer Link Confirm (…, C, LLB, PLB, …) B Peer Link Confirm(…, C, LLA, PLA, …) • The protocol proceeds iff Submission 65 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Motivation for an Updated Key Derivation Algorithm • Peer Link Open messages need protection – It is used for PMK negotiation – It is used for Security Policy negotiation (prevent the discovery and negotiation from downgrade attack) • GTK delivery should be confirmed – Only send encrypted broadcast traffic after the MP has received a confirm that the GTK is delivered to the neighbor MP – Send GTK in the Peer Link Open message – Peer Link Confirm message is used as delivery confirmation – Against replay attack: GTK is sent in both Open and Confirm messages • Need KCK and KEK ready when sending Peer Link Open message Submission 66 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Peer Link Key Derivation PMK-MA 0 x 00, PMK-MA KCK 0 x 01, PMK-MA KEK KTK KCK || KEK = KDF-256(PMK-MA, “Mesh KECK derivation”, 0 x 00 || MMP-ID || SMP-ID || PMK-MAName) MNonce SNonce temporal key KTK = KDF-256(PMK-MA, “Mesh KTK derivation”, 0 x 01 || MMP-ID || SMP-ID || PMK-MAName) Temporal key = KDF-TKlength(KTK, “Mesh TK derivation”, MNonce || SNonce || MMP-ID || SMP-ID || PMK-MAName) Submission 67 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Key Derivation Analysis • KCK can be static to PMK-MA – The freshness of the communication is proved by the repetition of random nonce from the received message – The MIC is used only for message integrity • KEK can be static to PMK-MA – Security of GTK wrapping is provided by authenticated encryption algorithm* • Freshness of the temporal key is guaranteed by the MNonce and SNonce • Advantage – KCK and KEK are generated only once for each PMK-MA • Assumption: A good PMK * P. Rogaway and T. Shrimpton, “Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem”, Eurocrypt 2006. Submission 68 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Changes to Finite State Machine • Verify the MIC first, before processing the message – Silently drop the message if MIC failure • Close the session, when security policy negotiation fails • Close the session, when PMK negotiation fails • Close the session, if security parameters mismatch in Peer Link Open and Peer Link Confirm messages (but the MIC validation succeeds) Submission 69 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design features meet requirements • At this point in our analysis, we believe the proposal satisfies all protocol requirements for secure peer link maintenance • Security Requirements – Achieve the consistency property • Both MPs reaches established state when both send and receive (process) both peer link open and confirm messages • When the link is established, both MPs agree on protocol states, or there’s no security – – – Submission Both MPs agree on the same Group Cipher Suite Both MPs agree on the same Pairwise Cipher Suite Both MPs agree on the PMK-MA to be used for key management Both MPs agree on Mesh Capability configuration parameters Both MPs derive the same session key Both MPs receive the confirm that the peer MP has installed the GTK correctly 70 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design features meet requirements – cont. • Security Requirements – Achieve the matching conversation property • • • Sent messages by MP A matches received messages by MP B We don’t have the proof yet It’s the prerequisite to provable security – Bind a fresh security context to the link instance – – Protocol establishes (statistically) unique security context for the link local. Nonce and peer. Nonce contribute to a (statistically) unique instance identifier Session key is freshly generated using local. Nonce and peer. Nonce Confirm messages contains peer. Nonce received in an earlier Open message – demonstrate liveness of peer MP 1. Open messages are protected by MIC 2. demonstrate the possession of the PMK by the peer MP – Defend against man-in-the-middle attack; bind session key to the communicating MPs – All keys are properly installed when transitioning to established state – Knows when the GTK is installed by the peer MP; therefore when to start using the GTK – GTK is wrapped with local. Nonce to defend against cut-and-paste attack Submission 71 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design features meet requirements – cont. • Security Requirements – The design maintains the session key as a secret between the peers only – Messages are fully meaningful to the security context • Open messages are protected by MIC computed using KCK derived from the decided PMK in the context • Confirm messages are protected by MIC, and specifies local. Nonce and peer. Nonce in the context • Close messages are protected by the MIC, and specifies local. Nonce and peer. Nonce in the context • MIC computation specifies the message sending direction – against reflection attack • Messages with incorrect MIC are ignored – they are considered as forgery • Messages with incomplete info can’t be interpreted correctly – they don’t belong to the security context and should be ignored Submission 72 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design features meet requirements – cont. • Functional Requirements – Handle simultaneity • Both parties can initiate the protocol • No pre-determined roles – Verifiable security parameter negotiation • Both MPs verify that announced pairwise cipher suite list is used for policy negotiation • Changes of parameters (from beacon/probe response) are made by authentic peer MP – messages are all MIC-protected Submission 73 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design features meet requirements – cont. • Functional Requirements – Simplicity • Whenever there is a shared PMK, the MPs can use it – No need to execute extra protocol – No need to switch roles (roles are not defined; they are only for client/server model) • Complexity is only necessary when it comes tie-breaking • Execute key transport protocol or authentication protocol only when there’s no shared PMK available • No need to enforce repetition of info in RSNIE or MKDDIE; changed info are protected by MIC Submission 74 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Design features meet requirements – cont. • Performance Requirements – Efficiency • • • Protocol initiation is not delayed by the beacons / probe responses Establish the secure link using 4 messages Messages only repeat info when it’s necessary No addition protocols are invoked unless it’s necessary Only generate and send meaningful messages in the security context (messages with incomplete info are ignored) – Failure cases do not impose undue delay • All parameters are verified, so failure to deliver a message does not cause one end to wait indefinitely after the other peer has decided the protocol has completed successfully Submission 75 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Conclusion on Abbreviated Handshake • A new abbreviated security handshake: integrates the peer link establishment with security handshake • There are three major new components – PMK Usage Negotiation – Security Policy Negotiation – Key Derivation Algorithm • Work in progress – Proving security • Bellare & Rogaway or Canetti & Krawczyk model – Welcome comments and suggestions to help improve the protocol Submission 76 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Backup – Abbreviated Handshake Submission 77 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Rationale: GTK distribution • Send GTK only in Open messages • Rationale: – Confirm is received to confirm the delivery of GTK in earlier Open message – In case earlier Open is lost, the sender will send the Open again until either receiving a confirm or reach MAX retries – Therefore, sending my GTK with my confirm doesn’t help to reduce messages. Submission 78 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Detail: GTK wrapping • Wrap {Local. Nonce||GTK} using KEK • Rationale: – If only wrap GTK, the wrapped material has no binding with the message – Attacker can send someone else’s GTK in the message, and still computes MIC correctly. – Wrapping GTK with local. Nonce, allow the sender to binding the GTK with this particular message Submission 79 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Detail: Enabling Abbreviated Handshake • How does the MP know that it might share a PMK with the potential neighbor candidate? – Has the key either from previous contact or from the key delivery – The neighbor is a Mesh Authenticator? – The neighbor has connection to MKD? • Approach: rely on the MA bit in Beacon/Probe response • Neither is an MA: not enabled • At least one of them is an MA: – Negotiation succeeds if only one of them has the neighbor’s PMK. – Failure: neither or both have the neighbor’s PMK Submission 80 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Detail: PMKID negotiation • When both have each other’s PMK, simultaneous Open would cause a mismatch in the PMK negotiation • The state machine should stop, then start over with new instnace, then change the choice PMK as the result of previously failed negotiation • Rationale: – First two Open messages are computed using different PMKs, which cannot help providing security – We are seeking to prove security assuming both parties use the same PMK during the protocol Submission 81 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Detail: MIC Computation • What if A reflect a message sent by B to A earlier? • Message should provide some information indicating direction of the message • Solution: – MIC = HMAC(KCK, sender. MAC||receiver. MAC||contents) Submission 82 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Finite State Machine • • States – – – 0. IDLE 1. LISTEN 2. OPEN_SENT 3. CONFIRM_RCVD 4. CONFIRM_SENT 5. ESTABLISHED 6. HOLDING • Actions – Send. Close (SCL) – Send. Open (SOP) – Send. Confirm (SCN) Submission Events 83 Cancel. Peer. Link (CNCL) Passive. Peer. Link. Open (PAS) Active. Peer. Link. Open (ACT) Close. Received (CLR) Open. Received (OPR) Confirm. Received (CNR) Timeout (Retry. Timer) (TOR) Timeout (Open. Timer) (TOO) Timeout(Cancel. Timer) (TOC) MICFailure (MIC) Negotiation. Failure (NF) Security. Parameter. Mismatch(SPM) Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Finite State Machine State Transitions 0 1 2 3 4 5 6 CNCL -→ 0 SCL → 6 -→ 6 PAS -→ 1 -→ 2 -→ 3 -→ 4 -→ 5 -→ 6 ACT SOP → 2 -→ 3 -→ 4 -→ 5 -→ 6 CLR -→ 0 -→ 1 -→ 6 or - → 2 -→ 6 or - → 3 -→ 6 or - → 4 - → 6 or -→ 5 -→ 6 -→ 0 SOP, SCN → 4 or SCL → 1 SCN → 4 or SCL → 6 or - → 2 SCN → 5 or - → 3 or SCL → 6 SCN → 4 or - → 4 or SCL → 6 SCN → 5 or - → 5 or SCL→ 6 SCL → 6 or - → 6 -→ 3 or SCL → 6 SCN → 5 or SCL → 6 or - → 4 -→ 5 or SCL→ 6 SCL → 6 or - → 6 OPR CNR -→ 0 -→ 1 -→ 3 or SCL → 6 or - → 2 TOR -→ 0 -→ 1 SOP → 2 or SCL → 6 -→ 3 SOP → 4 or SCL → 6 -→ 5 -→ 6 TOO -→ 0 -→ 1 -→ 2 SCL → 6 -→ 4 -→ 5 -→ 6 TOC -→ 0 -→ 1 -→ 2 -→ 3 -→ 4 -→ 5 SCL → 0 0: IDLE Submission 1: LISTEN 2: OPEN_SENT 3: CONFIRM_RCVD 5: ESTABLISHED 84 4: CONFIRM_SENT 6: HOLDING Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0357 r 1 Summary of Finite State Automaton Close / -, NF/Close, SPM /Close Legend transition end. Open Active. Open / S 2 Op 1 Op en / S end O pen + C Close / Close onfir m C 4 Timeout(Retry. Timer) / Send. Open MIC/- 5 m/onfir firm Cancel. Link / - O d. Con 0 Passiv. Open / - /S / Sen ve ti Ac n pe Open d en rm onfi n/C Ope en Cancel. Link or *Timeout (Retr y. Time r) / Se Cance nd. Clo l. Link se or. T im C eo 3 Confirm / SP lose ut(O M /-, /C NF pen los /C Tim e los er )/ e, C Open / Send. Confirm lose MIC/- Close / - Event / Action Timeout(Retry. Timer) / Send. Open MIC/- Cancel. Link / Close SPM / Close / SPM/Close, NF/Close Can cel Lin k or *Timeout (Retry 6 Open / Close Confirm / Close / - se d. Clo n e S r) / Time Cancel. Link or Timeout(Cancel. Timer) / Send. Close 0: IDLE 1: LISTEN Submission 2: OPEN_SENT 3: CONFIRM_RCVD 85 5: ESTABLISHED 4: CONFIRM_SENT 6: HOLDING Zhao and Walker, Intel Corp