PLE Comment Resolution

PLE Comment Resolution
March 2007 Date: Authors: 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 < ieee802.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 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 Zhao and Walker, Intel Corp

March 2007 Abstract This submission summarizes the proposed updates to resolve comments from LB93 on Peer Link Establishment protocol Zhao and Walker, Intel Corp

Agenda Protocol overview Comment resolution summary Major updates
March 2007 Agenda Protocol overview Comment resolution summary Major updates Finite State Machine Configuration parameters Randomness of link IDs Interface Reason codes Zhao and Walker, Intel Corp

Protocol Overview March 2007 A B A B Open(A, B, LinkIDA)
Open(B, A, LinkIDB) Confirm(B, A, LinkIDB, LinkIDA) Confirm(A, B, LinkIDA, LinkIDB) Open(B, A, LinkIDB) Open(A, B, LinkIDA) A B Confirm(B, A, LinkIDB, LinkIDA) Confirm(A, B, LinkIDA, LinkIDB) Zhao and Walker, Intel Corp

Protocol Design Overall protocol design is unchanged
March 2007 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 Zhao and Walker, Intel Corp

Summary of PLE comments
March 2007 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 Zhao and Walker, Intel Corp

Comments on Finite State Machine
March 2007 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 Conditional state transition for message processing and retry timer Add a diagram Abbreviations for specification Need a link IDs? (see 07/0237r0) Need 4-message exchange? (see 07/0237r0) Misc issues Zhao and Walker, Intel Corp

Updates to FSM More events
March 2007 Updates to FSM More events Message classification (OPN_ACPT, OPN_RJCT, OPN_IGNR,…) Timeout with MaxRetries (TOR1, TOR2) All states, events, actions are specified using abbreviations Add a diagram Zhao and Walker, Intel Corp

March 2007 Example of Updated FSM Zhao and Walker, Intel Corp

Comments on Configuration Parameters
March 2007 Comments on Configuration Parameters Comments, CIDs 3981, 4355, 4362 Issue: Configuration parameters are not defined No description on how to handle them Zhao and Walker, Intel Corp

Updates Define configuration parameters for message processing
March 2007 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 Zhao and Walker, Intel Corp

Comments on Link IDs Comments Issues
March 2007 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 Zhao and Walker, Intel Corp

Updates Requirement of link IDs
March 2007 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 Zhao and Walker, Intel Corp

Comments on Reason Codes
March 2007 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 Consistent specification on reason code usage Zhao and Walker, Intel Corp

Updates March 2007 46—65 535 Reserved 46
Reason code Meaning 46—65 535 Reserved 46 “MESH-LINK-CANCELLED”. IEEE 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 dot11MeshMaxRetries Peer Link Open messages, without receiving a Peer Link Confirm message. 51 “MESH-CONFIRM-TIMEOUT”. The confirmTimer for the mesh peer link instance times out. 52—65 535 Zhao and Walker, Intel Corp

Comments on Interface Comments Issues
March 2007 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 PassiveOpen, ActiveOpen, CancelLink, SignalStatus primitives are not needed Inconsistency in specification Vague specification on how to use them Incorrect specification on interaction between SME and MAC Zhao and Walker, Intel Corp

Updates Interface is essential for control the behavior of the MP
March 2007 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 MLME-PassivePeerLinkOpen(localLinkID) MLME-ActivePeerLinkOpen (peerMAC, localLinkID) MLME-CancelPeerLink(localLinkID, ReasonCode) MLME-SignalPeerLinkStatus.indication(localLinkID, statusCode) Zhao and Walker, Intel Corp

March 2007 Motion Comment CID 1417: Is an 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 De-authentication shall not be used between MPs.” Zhao and Walker, Intel Corp

Backup Slides Slides from 11-07/237r0 March 2007
Zhao and Walker, Intel Corp

March 2007 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 Zhao and Walker, Intel Corp

Peer Link and Security Handshake
March 2007 Peer Link and Security Handshake Peer Link Establishment Peer Link Establishment Abbreviated Security Handshake Authentication 4-Way Handshake 4-Way Handshake Zhao and Walker, Intel Corp

Peer Link and Security Handshake
March 2007 Peer Link and Security Handshake Peer Link Establishment Peer Link Open (…,SecurityHSIE) Authentication Peer Link Confirm (…,SecurityHSIE) 4-Way Handshake Zhao and Walker, Intel Corp

Protocol Requirements
March 2007 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 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 Zhao and Walker, Intel Corp

March 2007 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 Zhao and Walker, Intel Corp

March 2007 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 Zhao and Walker, Intel Corp

Agenda Protocol requirements Failure case analysis Protocol detail
March 2007 Agenda Protocol requirements Failure case analysis Protocol detail Basic peer link establishment (maintenance) protocol Abbreviated handshake Zhao and Walker, Intel Corp

What about naïve solutions?
March 2007 What about naïve solutions? Zhao and Walker, Intel Corp

Protocol in Draft 0.4 (1) March 2007 B A Association Request (Ra)
Association Response Subordinate MP Superordinate MP Zhao and Walker, Intel Corp

Protocol in Draft 0.4 (2) March 2007 B A Ra > Rb? Ra > Rb?
Association Request (Ra) Association Request (Rb) Ra > Rb? Ra > Rb? Subordinate MP Superordinate MP Association Response (accept) Association Response (deny) Zhao and Walker, Intel Corp

Example: Transition Over Reboot
March 2007 Example: Transition Over Reboot B A Association Request (R1) R1 reboot 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 Zhao and Walker, Intel Corp

Example: Half-Open Connection
March 2007 B A Association Request (Ra) Association Request (Rb) Ra > Rb? Association Response (accept) Superordinate MP Idle Association Response (deny) Data Frame …. Transmission Failure Disassociate Request Zhao and Walker, Intel Corp

Example: Half-Open Connection
March 2007 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? Superordinate MP Association Response (accept) Idle Association Response (deny) The protocol is responsible for tearing down the link if it’s not functioning correctly Eventually the timer can take care of it However, this design is not robust Push the responsibility to the lower layer Unnecessary communication overhead involved Data Frame …. Transmission Failure Disassociate Request Zhao and Walker, Intel Corp

Example: Tie Break Failure
March 2007 Example: Tie Break Failure Association Request (R1) R1 Association Request (R2) R2 timeout Association Request (R1’) R1’ R1 > R2? Association Response R1’ > R2? Association Response Superordinate MP Superordinate MP Two Superordinate MPs not a valid state in current protocol Root problem: numbers used for tie break are transmitted separately. Zhao and Walker, Intel Corp

Example: Tie Break Failure
March 2007 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 (R1’) belongs to the context Verifiable parameter negotiation Failure cases should not impose undue delay The protocol should handle all possible failure cases 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 (R1’) belongs to the context Verifiable parameter negotiation Failure cases should not impose undue delay The protocol should handle all possible failure cases Zhao and Walker, Intel Corp

Can we simply drop tie-breaking scheme?
March 2007 B A Association Request Association Request pending 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 Zhao and Walker, Intel Corp

March 2007 Agenda Protocol requirements Failure case analysis Protocol detail Basic peer link establishment (maintenance) protocol Design rationale FSM Example execution scenarios Abbreviated handshake Zhao and Walker, Intel Corp

PLE Protocol Design Rationale
March 2007 PLE Protocol Design Rationale Zhao and Walker, Intel Corp

Both MPs Should Respond
March 2007 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 Zhao and Walker, Intel Corp

Call for Instance Identifier
March 2007 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 DoS attacks Requirements Reasonably fresh (not used recently) Guaranteed unique number among active sessions between peer MPs Approach Random link IDs by each MPs (myLinkID, peerLinkID) <myMAC, peerMAC, myLinkID, peerLinkID> uniquely identify the session (statistically) Messages binds with the instance identifier Zhao and Walker, Intel Corp

Call for Peer Link Close Message
March 2007 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 peerLinkID Zhao and Walker, Intel Corp

A “Semi” 4-message Version
March 2007 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 Satisfy Bind fresh context to instance Handle simultaneity Verifiable parameter negotiation Simplicity Efficiency A B Peer Link Open(Rb) Peer Link Open(Ra) Peer Link Confirm(Rb, Ra) Peer Link Confirm(Ra, Rb) Zhao and Walker, Intel Corp

A “Semi” 4-message Version
March 2007 A “Semi” 4-message Version A B Peer Link Open(Rb) Peer Link Confirm(Ra, Rb) Peer Link Confirm(Rb, Ra) Violation Consistency property – does not guarantee both parties will send and receive same messages Matching conversation property Essential requirement for provable security Zhao and Walker, Intel Corp

4-Message Protocol Rules To satisfy requirements
March 2007 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, CancelTimer Retransmission: RetryTimer and MAX_REQ Deadlock avoidance: OpenTimer Zhao and Walker, Intel Corp

Set Up a Link March 2007 A B A B Open(A, B, Ra) Open(B, A, Rb)
Confirm(B, A, Rb, Ra) Confirm(A, B, Ra, Rb) Open(A, B, Ra) Open(B, A, Rb) A B Confirm(B, A, Rb, Ra) Confirm(A, B, Ra, Rb) Zhao and Walker, Intel Corp

Tear Down a Link Either initiated by SME
March 2007 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 Zhao and Walker, Intel Corp

Finite State Machine States Events Actions March 2007 0. IDLE
1. LISTEN 2. OPEN_SENT 3. CONFIRM_RCVD 4. CONFIRM_SENT 5. ESTABLISHED 6. HOLDING Events CancelPeerLink (CNCL) PassivePeerLinkOpen (PAS) ActivePeerLinkOpen (ACT) CloseReceived (CLR) OpenReceived (OPR) ConfirmReceived (CNR) Timeout (RetryTimer) (TOR) Timeout (OpenTimer) (TOO) Timeout(CancelTimer) (TOC) Actions SendClose (SCL) SendOpen (SOP) SendConfirm (SCN) Zhao and Walker, Intel Corp

Summary of Finite State Automaton
March 2007 Summary of Finite State Automaton Legend Close / - transition CancelLink or *Timeout Timeout(RetryTimer) / SendOpen Event / Action (RetryTimer) / SendClose CancelLink or 3 Confirm / - ActiveOpen / SendOpen 2 Timeout(OpenTimer) / Close ActiveOpen / SendOpen Open / Confirm Close/- Open / SendConfirm Open / SendConfirm PassivOpen / - CancelLink / Close 1 5 6 CancelLink / - Confirm / - Open / Send Open + Confirm Open / Close Confirm / Close Close / - 4 Close / - Close / Close Close / - Timeout(RetryTimer) / SendOpen CancelLink (RetryTimer) / SendClose or *Timeout CancelLink or Timeout(CancelTimer) / SendClose 0: IDLE 1: LISTEN : OPEN_SENT : CONFIRM_RCVD : CONFIRM_SENT 5: ESTABLISHED : HOLDING Zhao and Walker, Intel Corp

Finite State Machine State Transitions
March 2007 1 2 3 4 5 6 CNCL - → 0 SCL → 6 - → 6 PAS - → 1 - → 2 - → 3 - → 4 - → 5 ACT SOP → 2 CLR or - → 2 or - → 3 or - → 4 - → 6 or OPR SOP, SCN → 4 or SCL → 1 SCN → 4 or SCL → 6 SCN → 5 or - → 5 or - → 6 CNR SCN → 5 or TOR SOP → 2 or SOP → 4 or TOO TOC SCL → 0 0: IDLE 1: LISTEN : OPEN_SENT : CONFIRM_RCVD : CONFIRM_SENT 5: ESTABLISHED : HOLDING Zhao and Walker, Intel Corp

Sessions over Reboot March 2007 Reboot A B Ignore Holding Close
Peer Link Open(Rb1) Reboot Peer Link Confirm(Ra1, Rb1) Peer Link Open(Rb2) Ignore Peer Link Close(Ra2, Rb2) Holding Close Peer Link Close(Rb2, Ra2) Zhao and Walker, Intel Corp

Retries March 2007 retryTimerA retryTimerB A B MAX_REQ … MAX_REQ
Peer Link Open(Ra) B Peer Link Open (Rb) retryTimerA Peer Link Confirm (Rb, Ra) retryTimerB Peer Link Open(Ra) Peer Link Confirm (Rb, Ra) Peer Link Open (Rb) MAX_REQ … MAX_REQ Peer Link Close (Ra, null) Peer Link Close (Rb, Ra) Zhao and Walker, Intel Corp

Open Timer March 2007 retryTimerB A B openTimerA MAX_REQ …
Peer Link Open(Ra) B Peer Link Open (Rb) Peer Link Confirm (Rb, Ra) retryTimerB Peer Link Open (Rb) openTimerA MAX_REQ … Peer Link Close (Rb, Ra) Peer Link Close (Ra, Rb) Zhao and Walker, Intel Corp

Cancel Timer (holding timer)
March 2007 Cancel Timer (holding timer) A B Peer Link Open(Ra) Peer Link Open (Rb) Peer Link Confirm (Rb, Ra) Peer Link Close(Ra, Rb) cancelLink Peer Link Close(Ra, Rb) cancelTimer Holding … Idle cancelTimer Idle Zhao and Walker, Intel Corp

March 2007 Agenda Protocol requirements Failure case analysis Protocol detail Basic peer link establishment (maintenance) protocol Abbreviated handshake Zhao and Walker, Intel Corp

Abbreviated Handshake
March 2007 Abbreviated Handshake Zhao and Walker, Intel Corp

Design Issues Opportunity Challenges
March 2007 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 Zhao and Walker, Intel Corp

March 2007 Peer Link Messages Peer Link Open(myMAC, peerMAC, ANonce, PMK, Ciphersuite, GTK, MIC) Peer Link Confirm(myMAC, peerMAC, ANonce, BNonce, PMK, Ciphersuite, MIC) Peer Link Close(myMAC, peerMAC, ANonce, BNonce, MIC) Zhao and Walker, Intel Corp

Proposed Abbreviated Security Handshake
March 2007 Proposed Abbreviated Security Handshake Beacon/Probe Response A Beacon/Probe Response B Cipher Suite Negotiation PMK Usage Negotiation Using Derived Keys Open(ANonce, PMKInfo, Cipher Suite Info, GTK1, MIC) Open(BNonce, PMKInfo, Cipher Suite Info, GTK2, MIC) Confirm(BNonce, ANonce, PMKInfo, Cipher Suite Info, MIC) Confirm(ANonce, BNonce, PMKInfo, Cipher Suite Info, MIC) Zhao and Walker, Intel Corp

Major Functional Components
March 2007 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 Zhao and Walker, Intel Corp

PMK Usage Negotiation (1)
March 2007 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 DoS attacks Protocol always succeeds if a shared PMK exists Avoid unnecessary key transport protocol executions Zhao and Walker, Intel Corp

PMK Usage Negotiation (2)
March 2007 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 PMK-MAName MIC is computed to prove the knowledge of the chosen PMK KCK is derived from the chosen PMK-MA Peer Link Open(…, PMK-MAName1, …) A B Peer Link Open (…, PMK-MAName2, …) Zhao and Walker, Intel Corp

PMK Negotiation Cases Case 1 Case 2 Case 3 March 2007 A B A B A B ? ?
Peer Link Open (…, PMKA, …) ? A B ? Peer Link Open (…, PMKB, …) Peer Link Open (…, PMKB, …) PMKB A B ? Peer Link Open (…, PMKB, …) Peer Link Open (…, PMKB, …) PMKB A B PMKA Peer Link Open (…, PMKA, …) Peer Link Open (…, PMKA, …) Higher MAC address Zhao and Walker, Intel Corp

Pairwise Cipher Suite Negotiation (1)
March 2007 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 Zhao and Walker, Intel Corp

Pairwise Cipher Suite Negotiation (2)
March 2007 Pairwise Cipher Suite Negotiation (2) A B Peer Link Open(…, C, LLA, PLA, …) Peer Link Open (…, _, LLB, PLB, …) Peer Link Confirm (…, C, LLB, PLB, …) Peer Link Confirm(…, C, LLA, PLA, …) The protocol proceeds iff Zhao and Walker, Intel Corp

Motivation for an Updated Key Derivation Algorithm
March 2007 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 Zhao and Walker, Intel Corp

Peer Link Key Derivation
March 2007 Peer Link Key Derivation PMK-MA 0x00, PMK-MA 0x01, PMK-MA KCK KEK KTK MNonce SNonce KCK || KEK = KDF-256(PMK-MA, “Mesh KECK derivation”, 0x00 || MMP-ID || SMP-ID || PMK-MAName) temporal key KTK = KDF-256(PMK-MA, “Mesh KTK derivation”, 0x01 || MMP-ID || SMP-ID || PMK-MAName) Temporal key = KDF-TKlength(KTK, “Mesh TK derivation”, MNonce || SNonce || MMP-ID || SMP-ID || PMK-MAName) Zhao and Walker, Intel Corp

Key Derivation Analysis
March 2007 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. Zhao and Walker, Intel Corp

Changes to Finite State Machine
March 2007 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) Zhao and Walker, Intel Corp

Design features meet requirements
March 2007 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 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 Zhao and Walker, Intel Corp

Design features meet requirements – cont.
March 2007 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 localNonce and peerNonce contribute to a (statistically) unique instance identifier Session key is freshly generated using localNonce and peerNonce Confirm messages contains peerNonce received in an earlier Open message – demonstrate liveness of peer MP Open messages are protected by MIC 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 localNonce to defend against cut-and-paste attack Zhao and Walker, Intel Corp

March 2007 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 localNonce and peerNonce in the context Close messages are protected by the MIC, and specifies localNonce and peerNonce 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 Zhao and Walker, Intel Corp

March 2007 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 Zhao and Walker, Intel Corp

March 2007 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 Zhao and Walker, Intel Corp

March 2007 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 Zhao and Walker, Intel Corp

Conclusion on Abbreviated Handshake
March 2007 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 Zhao and Walker, Intel Corp

Backup – Abbreviated Handshake
March 2007 Backup – Abbreviated Handshake Zhao and Walker, Intel Corp

Rationale: GTK distribution
March 2007 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. Zhao and Walker, Intel Corp

Detail: GTK wrapping Wrap {LocalNonce||GTK} using KEK Rationale:
March 2007 Detail: GTK wrapping Wrap {LocalNonce||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 localNonce, allow the sender to binding the GTK with this particular message Zhao and Walker, Intel Corp

Detail: Enabling Abbreviated Handshake
March 2007 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 Zhao and Walker, Intel Corp

Detail: PMKID negotiation
March 2007 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 Zhao and Walker, Intel Corp

Detail: MIC Computation
March 2007 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, senderMAC||receiverMAC||contents) Zhao and Walker, Intel Corp

Finite State Machine Actions March 2007 States Events SendClose (SCL)
0. IDLE 1. LISTEN 2. OPEN_SENT 3. CONFIRM_RCVD 4. CONFIRM_SENT 5. ESTABLISHED 6. HOLDING Events CancelPeerLink (CNCL) PassivePeerLinkOpen (PAS) ActivePeerLinkOpen (ACT) CloseReceived (CLR) OpenReceived (OPR) ConfirmReceived (CNR) Timeout (RetryTimer) (TOR) Timeout (OpenTimer) (TOO) Timeout(CancelTimer) (TOC) MICFailure (MIC) NegotiationFailure (NF) SecurityParameterMismatch(SPM) Actions SendClose (SCL) SendOpen (SOP) SendConfirm (SCN) Zhao and Walker, Intel Corp

Finite State Machine State Transitions
March 2007 1 2 3 4 5 6 CNCL - → 0 SCL → 6 - → 6 PAS - → 1 - → 2 - → 3 - → 4 - → 5 ACT SOP → 2 CLR or - → 2 or - → 3 or - → 4 - → 6 or OPR SOP, SCN → 4 or SCL → 1 SCN → 4 or SCL → 6 SCN → 5 or - → 5 or SCL→6 or - → 6 CNR or - →2 or SCL →6 SCN → 5 or SCL → 6 or - →4 TOR SOP → 2 or SOP → 4 or TOO TOC SCL → 0 0: IDLE 1: LISTEN : OPEN_SENT : CONFIRM_RCVD : CONFIRM_SENT 5: ESTABLISHED : HOLDING Zhao and Walker, Intel Corp

Summary of Finite State Automaton
March 2007 Summary of Finite State Automaton Legend Close / -, NF/Close, SPM/Close transition CancelLink or *Timeout Timeout(RetryTimer) / SendOpen MIC/- Event / Action (RetryTimer) / SendClose CancelLink or 3 Confirm / - ActiveOpen / SendOpen 2 Timeout(OpenTimer) / Close Close/-, NF/Close, SPM/Close ActiveOpen / SendOpen Open / Confirm Open / SendConfirm MIC/- Open / SendConfirm PassivOpen / - CancelLink / Close 1 5 6 CancelLink / - Confirm / - SPM / Close Open / Send Open + Confirm Open / Close Confirm / Close Close / - 4 Close / - Close / Close Close / - SPM/Close, NF/Close Timeout(RetryTimer) / SendOpen MIC/- CancelLink (RetryTimer) / SendClose or *Timeout CancelLink or Timeout(CancelTimer) / SendClose 0: IDLE 1: LISTEN : OPEN_SENT : CONFIRM_RCVD : CONFIRM_SENT 5: ESTABLISHED : HOLDING Zhao and Walker, Intel Corp

PLE Comment Resolution

Similar presentations

Presentation on theme: "PLE Comment Resolution"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

PLE Comment Resolution

Similar presentations

Presentation on theme: "PLE Comment Resolution"— Presentation transcript:

Similar presentations

About project

Feedback