1. Abbreviated Handshake Protocol Requirements
May 2007
Abbreviated Handshake Protocol Requirements
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.

2. May 2007
Abstract
This submission describes the protocol requirements and design rationale of the Abbreviated Handshake Protocol that overlays the security handshake using the PLM protocol
Meiyuan Zhao, Intel Corp, et al.

3. May 2007
Motivations
Abbreviated Handshake – overlay security handshake using PLM
Challenges
Achieve security in peer-to-peer environment
Achieve security using four messages
Questions
What are the security goals?
What are the protocol requirements to satisfy security goals?
What is the key protocol design rationale?
Goal of this presentation
Explain our vision of the problem
Demonstrate our design philosophy
Report current status
Receive feedbacks from TGs
Meiyuan Zhao, Intel Corp, et al.

4. Agenda Analyze initial MSA authentication Design challenges
May 2007
Agenda
Analyze initial MSA authentication
Design challenges
Protocol requirements
Key protocol design rationale
Current status
Meiyuan Zhao, Intel Corp, et al.

5. Peer Links in Mesh Goal of establishing a peer link Peer to peer model
May 2007
Peer Links in Mesh
Goal of establishing a peer link
Synchronize the start of routing and data transmission
Negotiate parameters for routing, data transmission, and security
Control the resource usage (may not want to communicate to all MPs in the neighborhood)
Peer to peer model
Either MP may initiate the PLM protocol at any time
No prior decision on who should initiate, or the protocol won’t work
No prior decision on who should respond first, or the protocol won’t work
Peer links may also be secured, however it doesn’t change the peer to peer nature
Peer to peer nature changes the security design
Meiyuan Zhao, Intel Corp, et al.

6. Using 802.11i Model for Initial Security Handshake
May 2007
Using i Model for Initial Security Handshake
Establish a peer link
Security Capability Discovery
Security Capability Negotiation
Role negotiation
EAP authentication Request
EAP authentication Response
……..
4-Way Handshake
Meiyuan Zhao, Intel Corp, et al.

7. May 2007
Rationale of Using i
802.11i was designed for the infrastructure model
Service providers announce available service
Clients search for service and initiate the protocol
Classical client/server model
Community wants to re-use EAP for authentication where possible
Need to temporarily change P2P model to C/S model
4-Way handshake
Achieves mutual authentication
Synchronizes key usage
Rationale
Achieve security with existing authentication mechanisms where possible
Define a flexible architecture adaptable to different deployment models
Meiyuan Zhao, Intel Corp, et al.

8. TGs Security Handshake with a PMK
May 2007
TGs Security Handshake with a PMK
Peer Link Establishment
Peer Link Management
Abbreviated Security Handshake
Authentication
4-Way Handshake
4-Way Handshake
Meiyuan Zhao, Intel Corp, et al.

9. TGs Security Handshake with PMK
May 2007
TGs Security Handshake with PMK
Peer Link Establishment
Peer Link Open (…,SecurityHSIE)
Authentication
Peer Link Confirm (…,SecurityHSIE)
4-Way Handshake
Two MPs have an equal opportunity to initiate and execute the protocol
Meiyuan Zhao, Intel Corp, et al.

10. Challenges Security challenge Functional challenge
May 2007
Challenges
Security challenge
Achieve mutual authentication—both parties know that the peer agrees to the state of the link
Consistency of the state of the link
Identities, keys, agreed security parameters, other agreed parameters
Possible attacks exploited by inconsistent view of link state
Functional challenge
Support simultaneity – any party should initiate the protocol any time
Each party should be able to respond once receiving the request
Performance challenge
Minimize number of messages
> 2, since each party should be able to make its request (and parameter announcement) and then the confirm of the parameter agreement
4 messages may work, but no security proof yet
Meiyuan Zhao, Intel Corp, et al.

11. Protocol Requirements
May 2007
Protocol Requirements
(At least) 3 Classes of Requirements exist:
Security requirements
Functional requirements
Performance requirements
Enumerate detailed requirements in each class
Meiyuan Zhao, Intel Corp, et al.

12. Security Requirements (1)
May 2007
Security Requirements (1)
Achieve the consistency property (essential for mutual authentication)
On protocol completion, both parties must agree on the protocol state, or else the protocol should fail
On protocol completion, both parties know the other party agrees with them 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 message set property
Both parties demonstrably send and receive the same set of messages
Any model defining mutual authentication achieves consistency property
Alternatives: use the Client/Server model or introduce more messages
Special case 2: Authenticated key exchange
Both parties demonstrably agree on the keys and ciphersuites being used
Meiyuan Zhao, Intel Corp, et al.

13. Security Requirements (2)
May 2007
Security Requirements (2)
Special case 3: 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.

14. Functional Requirements
May 2007
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
Decision on parameter based on verifiable announcements
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
Reuse the PLM protocol already defined in the TGs draft instead of introducing a radically new protocol for security
Meiyuan Zhao, Intel Corp, et al.

15. Performance Requirements
May 2007
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.

16. May 2007
Key Design Rationale
Last message cannot be used to announce any new parameters related to the link’s security context
If sending them, never knows the peer MP agrees with the sent parameters
Violate consistency property
GTK must be delivered in Peer Link Open message
Both parties send GTK in Open, since they shouldn’t decide who talks first
Confirm messages are used to confirm the correct receipt of GTKs
KEK available before sending the Open message
Meiyuan Zhao, Intel Corp, et al.

17. May 2007
Key Design Rationale
Open messages must be protected for the protocol to consist of fewer than six messages
Open messages must announce all parameters negotiated, or else extra messages needed later
To achieve the consistency property, the open message parameters must be protected
Or else either more than 4 message or protocol is subject to man-in-the-middle attacks
Efficiency requirement—We want no more than 4 messages
Either protect the first messages or require 2 more protected messages, leave the first open messages unprotected.
Committing the sender to a PMK in message 1 enables a 4 message exchange; committing later requires more than 4 messages in the peer-to-peer case
Meiyuan Zhao, Intel Corp, et al.

18. Current Status Protocol requirements defined
May 2007
Current Status
Protocol requirements defined
Basic protocol design finished
Improving the design on
Pairwise ciphersuite
Key derivation
Developing normative text
Plan to present in July
Protocol analysis and security proof (summer 2007)
Plan to present the analysis result in September
Meiyuan Zhao, Intel Corp, et al.

19. May 2007
Backup Slides
Meiyuan Zhao, Intel Corp, et al.

20. Two-Army Problem vs. Consistency Requirement
May 2007
Two-Army Problem vs. Consistency Requirement
Two-army problem
The protocol can never succeed with the agreement
The best the parties can do is to send redundant messages to increase the confidence
Retry mechanism is needed for robustness
Consistency property is the security requirement
If the protocol succeeds, the parties are required to know that the peer party agrees the protocol state
Key difference
Two-army problem worries about the protocol never succeed
Consistency property is the property that holds when the protocol succeeds
Meiyuan Zhao, Intel Corp, et al.

21. May 2007
Link State
Link state – A set of parameters that both parties need to agree on in order to achieve success in protocol execution
The parameter only sent for informative purpose do NOT belong to the link state
For abbreviated handshake, link state includes
Link instance identifier (linkID, Nonce)
Security parameters
Agreed AKM
Agreed pairwise ciphersuite
Agree to support the peer’s group ciphersuite
Keys
PMK, therefore KEK, KCK, temporal key
MP A’s GTK
MP B’s GTK
Other agreed mesh capabilities
Mutual authentication: demonstrate to each other the agreement on the link state
Meiyuan Zhao, Intel Corp, et al.

22. Agreement on Link State
May 2007
Agreement on Link State
Both MPs agree on the same link instance identifier
Both MPs agree to use the same AKM, pairwise ciphersuite
MP A agrees to use ciphersuite X and MP B’s GTK to decrypt broadcast/multicast traffic sent by MP B
This requires correct reception of MP B’s GTK
MP B agrees to use ciphersuite Y and MP A’s GTK to decrypt broadcast/multicast traffic sent by MP A
This requires correct reception of MP A’s GTK
Both MPs agree to use the same PMK to derive keys that protect this link instance
Both MPs agree on the same KEK, KCK, and temporal key
This depends on the agreement on PMK, key derivation function, link instance, and pairwise ciphersuite
Meiyuan Zhao, Intel Corp, et al.

23. PLM Basic Protocol Design Issues
May 2007
PLM Basic Protocol Design Issues
Meiyuan Zhao, Intel Corp, et al.

24. 4-Message Protocol Rules To satisfy requirements
May 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.

25. Set Up a Link May 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.

26. Tear Down a Link Either initiated by SME
May 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.

27. Sessions over Reboot May 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.

28. Retries May 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.

29. Open Timer May 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.

30. Cancel Timer (holding timer)
May 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.

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

32. Abbreviated Handshake
May 2007
Abbreviated Handshake
Meiyuan Zhao, Intel Corp, et al.

33. Proposed Abbreviated Security Handshake
May 2007
Proposed Abbreviated Security Handshake A 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.

34. Major Functional Components
May 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 from two lists announced by the 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.

35. PMK Usage Negotiation (1)
May 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.

36. PMK Usage Negotiation (2)
May 2007
PMK Usage Negotiation (2)
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.

37. PMK Negotiation Cases Case 1 Case 2 Case 3 May 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.

38. Motivation for an Updated Key Derivation Algorithm
May 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.

39. Peer Link Key Derivation
May 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.

40. Key Derivation Analysis
May 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.

41. Changes to Finite State Machine
May 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 PMK negotiation fails
Close the session, when the GTK unwrapping fails
Meiyuan Zhao, Intel Corp, et al.

42. Design features meet requirements
May 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.

43. Design features meet requirements – cont.
May 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.

44. Design features meet requirements – cont.
May 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.

45. Design features meet requirements – cont.
May 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.

46. Design features meet requirements – cont.
May 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.

47. Design features meet requirements – cont.
May 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.

48. Conclusion on Abbreviated Handshake
May 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.

49. May 2007
More details
Meiyuan Zhao, Intel Corp, et al.

50. Rationale: GTK distribution
May 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.

51. Detail: GTK wrapping Wrap {GTK||MAC address||LocalNonce} using KEK
May 2007
Detail: GTK wrapping
Wrap {GTK||MAC address||LocalNonce} using KEK
Rationale:
If only wrap GTK, the wrapped material has no binding with the sender and 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.

52. Detail: PMKID negotiation
May 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 instance, 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.

53. Detail: MIC Computation
May 2007
Detail: MIC Computation
What if A reflects 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.