Peer Link Establishment Protocol Analysis

Peer Link Establishment Protocol Analysis
February 2007 Peer Link Establishment Protocol Analysis 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 Meiyuan Zhao, Intel Corp, et al.

February 2007 Abstract This submission describes the design rationale of peer link establishment protocol, including protocol requirements, failure case analysis, and protocol detail discussion. Meiyuan Zhao, Intel Corp, et al.

Agenda Protocol requirements Failure case analysis Protocol detail
February 2007 Agenda Protocol requirements Failure case analysis Protocol detail Basic peer link establishment (maintenance) protocol Abbreviated handshake Meiyuan Zhao, Intel Corp, et al.

February 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 Meiyuan Zhao, Intel Corp, et al.

Peer Link and Security Handshake
February 2007 Peer Link and Security Handshake Peer Link Establishment Peer Link Establishment Abbreviated Security Handshake Authentication 4-Way Handshake 4-Way Handshake Meiyuan Zhao, Intel Corp, et al.

Peer Link and Security Handshake
February 2007 Peer Link and Security Handshake Peer Link Establishment Peer Link Open (…,SecurityHSIE) Authentication Peer Link Confirm (…,SecurityHSIE) 4-Way Handshake Meiyuan Zhao, Intel Corp, et al.

Protocol Requirements
February 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 Meiyuan Zhao, Intel Corp, et al.

February 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 Meiyuan Zhao, Intel Corp, et al.

February 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 Meiyuan Zhao, Intel Corp, et al.

What about naïve solutions?
February 2007 What about naïve solutions? Meiyuan Zhao, Intel Corp, et al.

Protocol in Draft 0.4 (1) February 2007 B A Association Request (Ra)
Association Response Subordinate MP Superordinate MP Meiyuan Zhao, Intel Corp, et al.

Protocol in Draft 0.4 (2) February 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) Meiyuan Zhao, Intel Corp, et al.

Example: Transition Over Reboot
February 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 Meiyuan Zhao, Intel Corp, et al.

Example: Half-Open Connection
February 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 Meiyuan Zhao, Intel Corp, et al.

Example: Half-Open Connection
February 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 Meiyuan Zhao, Intel Corp, et al.

Example: Tie Break Failure
February 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. Meiyuan Zhao, Intel Corp, et al.

Example: Tie Break Failure
February 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 Meiyuan Zhao, Intel Corp, et al.

Can we simply drop tie-breaking scheme?
February 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 Meiyuan Zhao, Intel Corp, et al.

February 2007 Agenda Protocol requirements Failure case analysis Protocol detail Basic peer link establishment (maintenance) protocol Design rationale FSM Example execution scenarios Abbreviated handshake Meiyuan Zhao, Intel Corp, et al.

PLE Protocol Design Rationale
February 2007 PLE Protocol Design Rationale Meiyuan Zhao, Intel Corp, et al.

Both MPs Should Respond
February 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 Meiyuan Zhao, Intel Corp, et al.

Call for Instance Identifier
February 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 Meiyuan Zhao, Intel Corp, et al.

Call for Peer Link Close Message
February 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 Meiyuan Zhao, Intel Corp, et al.

A “Semi” 4-message Version
February 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) Meiyuan Zhao, Intel Corp, et al.

A “Semi” 4-message Version
February 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 Meiyuan Zhao, Intel Corp, et al.

4-Message Protocol Rules To satisfy requirements
February 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 Meiyuan Zhao, Intel Corp, et al.

Set Up a Link February 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) Meiyuan Zhao, Intel Corp, et al.

Tear Down a Link Either initiated by SME
February 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 Meiyuan Zhao, Intel Corp, et al.

Finite State Machine States Events Actions February 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) Meiyuan Zhao, Intel Corp, et al.

Summary of Finite State Automaton
February 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 Meiyuan Zhao, Intel Corp, et al.

Finite State Machine State Transitions
February 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 Meiyuan Zhao, Intel Corp, et al.

Sessions over Reboot February 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) Meiyuan Zhao, Intel Corp, et al.

Retries February 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) Meiyuan Zhao, Intel Corp, et al.

Open Timer February 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) Meiyuan Zhao, Intel Corp, et al.

Cancel Timer (holding timer)
February 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 Meiyuan Zhao, Intel Corp, et al.

Abbreviated Handshake
February 2007 Abbreviated Handshake Meiyuan Zhao, Intel Corp, et al.

Design Issues Opportunity Challenges
February 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 Meiyuan Zhao, Intel Corp, et al.

February 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) Meiyuan Zhao, Intel Corp, et al.

Proposed Abbreviated Security Handshake
February 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) Meiyuan Zhao, Intel Corp, et al.

Major Functional Components
February 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 Meiyuan Zhao, Intel Corp, et al.

PMK Usage Negotiation (1)
February 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 Meiyuan Zhao, Intel Corp, et al.

PMK Usage Negotiation (2)
February 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, …) Meiyuan Zhao, Intel Corp, et al.

PMK Negotiation Cases Case 1 Case 2 Case 3 February 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 Meiyuan Zhao, Intel Corp, et al.

Pairwise Cipher Suite Negotiation (1)
February 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 Meiyuan Zhao, Intel Corp, et al.

Pairwise Cipher Suite Negotiation (2)
February 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 Meiyuan Zhao, Intel Corp, et al.

Motivation for an Updated Key Derivation Algorithm
February 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 Meiyuan Zhao, Intel Corp, et al.

Peer Link Key Derivation
February 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) Meiyuan Zhao, Intel Corp, et al.

Key Derivation Analysis
February 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. Meiyuan Zhao, Intel Corp, et al.

Changes to Finite State Machine
February 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) Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements
February 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 Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements – cont.
February 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 Meiyuan Zhao, Intel Corp, et al.

February 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 Meiyuan Zhao, Intel Corp, et al.

February 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 Meiyuan Zhao, Intel Corp, et al.

February 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 Meiyuan Zhao, Intel Corp, et al.

February 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 Meiyuan Zhao, Intel Corp, et al.

Conclusion on Abbreviated Handshake
February 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 Meiyuan Zhao, Intel Corp, et al.

Backup – Abbreviated Handshake
February 2007 Backup – Abbreviated Handshake Meiyuan Zhao, Intel Corp, et al.

Rationale: GTK distribution
February 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. Meiyuan Zhao, Intel Corp, et al.

Detail: GTK wrapping Wrap {LocalNonce||GTK} using KEK Rationale:
February 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 Meiyuan Zhao, Intel Corp, et al.

Detail: Enabling Abbreviated Handshake
February 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 Meiyuan Zhao, Intel Corp, et al.

Detail: PMKID negotiation
February 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 Meiyuan Zhao, Intel Corp, et al.

Detail: MIC Computation
February 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) Meiyuan Zhao, Intel Corp, et al.

Finite State Machine Actions February 2007 States Events
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) Meiyuan Zhao, Intel Corp, et al.

Finite State Machine State Transitions
February 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 Meiyuan Zhao, Intel Corp, et al.

Summary of Finite State Automaton
February 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 Meiyuan Zhao, Intel Corp, et al.

February 2007 Backup Slides Meiyuan Zhao, Intel Corp, et al.

Call for Instance Identifier
February 2007 Call for Instance Identifier Need to name the session to bind necessary resource with link instance 802.11i uses different keys for different sessions Implicit binding doesn’t have instance identifier Lock-out problem STA loses states (including keys) and comes back, it CANNOT rejoin the network 802.11i is subject to trivial denial of service attacks 802.11w and r suffers too Meiyuan Zhao, Intel Corp, et al.

The difficult question
February 2007 The difficult question If AP has an authenticated station ‘X’.... and it receives an (unprotected) association request from station claiming to be ‘X’.... Should it: (a) Ignore the request (b) Fail the request (c) accept the request If the answer is (a) or (b) then we have a lockout problem since a station that loses its key state cannot rejoin the network. Let’s explore the consequences of answer (c) Meiyuan Zhao, Intel Corp, et al.

Answer ‘C’: accept association
February 2007 Answer ‘C’: accept association The idea is to enable the existing authenticated station to continue un-interrupted while allowing the new station to complete the authentication phase. If the new station succeeds, the state for the existing connection will be deleted. AP AP AP existing new X X X X X X Association Authenticating (802.1X) Authenticated Meiyuan Zhao, Intel Corp, et al.

Can Answer ‘C’ really work?
February 2007 Can Answer ‘C’ really work? Requires maintaining state for two stations with the same MAC address - differentiated by context Requires de-multiplexing incoming messages to deliver to the correct instance of the station - even though destination address is the same! Meiyuan Zhao, Intel Corp, et al.

Analysis Consider an attack where:
February 2007 Analysis Consider an attack where: STA ‘X’ is authenticated and protected STA ‘Z’ is attacker using MAC address of ‘X’ AP AP can only see one STA ‘X’ Forges messages from ‘X’ X Z Meiyuan Zhao, Intel Corp, et al.

February 2007 AP Multi-State AP receives unprotected messages that are inappropriate for a protected station: open authenticate associate request AP assumes this is caused by either: STA ‘X’ that has lost it’s key state, or... A forgery attempt by unknown STA AP decides to accept unprotected messages from “aspirant station” pending authentication This means: New entry in STA table but with same MAC address as an existing entry New 802.1X port and authenticator - but with same MAC address as existing port. Old port is closed, new port is open MAC state very confused because of possible sequence number errors. Mayhem if one is in power save mode and the other not! Meiyuan Zhao, Intel Corp, et al.

Peer Link Establishment Protocol Analysis

Similar presentations

Presentation on theme: "Peer Link Establishment Protocol Analysis"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Peer Link Establishment Protocol Analysis

Similar presentations

Presentation on theme: "Peer Link Establishment Protocol Analysis"— Presentation transcript:

Similar presentations

About project

Feedback