802.11w - Management Frame Protection

802.11w - Management Frame Protection

By CWNP On 09/10/2007 - 14 Comments

The 802.11w amendment offers three new security pieces: Data Origin Authenticity, Replay Detection, and Robust Management Frame Protection.  

The data origin authenticity mechanism defines a means by which a station that receives a data or robust management frame can determine which station transmitted the data or management frame.  This feature is required in an RSNA to prevent one station from masquerading as a different station.  Data origin authenticity is only applicable to unicast data frames, or unicast Robust Management frames, and Deauthenticate or Disassociate frames with Robust Management protection.  The protocols do not guarantee data origin authenticity for broadcast/multicast (bc/mc) data frames or broadcast/multicast Robust Management frames.

 

The replay detection mechanism defines a means by which a station that receives a data or Robust Management Frame from another station can detect whether the received data frame is an unauthorized retransmission.  This replay protection mechanism is provided for data frames for stations that use the CCMP or TKIP cipher suites.  The replay protection mechanism is also provided for robust management frames for stations that use CCMP and the Broadcast/Multicast Integrity Protocol (BIP).

Management frame protection is required in an RSNA to protect against forgery and eavesdropping on robust unicast management frames, and against forgery on robust bc/mc management frames.  Management frame protection extends the CCMP data frame protection to provide data confidentiality (already in place), replay protection, and data origin authenticity for robust unicast management frames.  The Robust Management Frames are Action, Disassociate, and Deauthenticate frames.  Forgery protection for robust bc/mc management frames is provided through BIP, using AES-128-CMAC for message integrity.  The BIP protocol also provides replay protection.  Management frame protection protocols apply to Robust Management frames after the RSNA PTK key establishment for protection of unicast frames is completed and after the GTKs to protect bc/mc frames that have been delivered.  All management frames sent or received by a station before keys are installed are unprotected.

As you might've guessed from that last couple of statements, the 4-Way Handshake has been modified.  We now have an Integrity GTK (IGTK) being generated on the authenticator and delivered to each supplicant as part of the 4-Way Handshake and/or Group Handshake, alongside the GTK.  The IGTK is encrypted with the KEK as would be expected.  The IGTK is a single key that provides integrity protection for robust bc/mc management frames.

- Broadcast/Multicast Integrity Protocol (BIP) -

When Robust Management frame support has been enabled, all robust bc/mc management frames (Action frames) are submitted for encapsulation to the bc/mc frame protection service which protects the frame using BIP.

* BIP Data Integrity *

BIP provides data integrity and replay protection, using AES-128 in CMAC Mode.  BIP uses the IGTK to compute a bc/mc MMPDU MIC.  The authenticator distributes one new IGTK and IGTK Packet Number (PN) whenever it distributes a new GTK.  The IGTK is identified by the MAC address of the station transmitting it, plus a non-zero 12-bit key identifier that is encoded in the Management MIC Information Element (MMIE) Key ID field.

In a management frame using BIP, the MMPDU format is:  Header > Frame Body > MMIE > FCS

We've referenced the MMIE multiple times now, so let's dig into it a little further.

The MMIE is structured as follows:

Element ID (1), Length (1), Key ID (2), Replay (6), MIC (8)

...where all numbers are in octets.  The MMIE is used to protect robust broadcast/multicast management frames from forgery and replay.  It also provides message integrity for bc/mc Robust Management Frames.  The Length field denotes the number of octets in the information element and has a value of 16.  The Key ID field identifies the bc/mc key used to compute the MIC.  Bits 0-11 defines a value in the range 0-4095.  Bits 12 - 15 are reserved and set to 0 on transmission and ignored on reception.  By convention, the IGTK Key ID is either 4 or 5.  The remaining Key IDs are reserved for future multicast extensions.  The Replay field value is 6 octets, interpreted as a 48-bit unsigned integer and used as a sequence number.  The MIC field contains a message integrity code calculated over the Robust Management Frame.

* BIP Replay Protection *

The transmitter inserts an increasing value into the MMIE Replay field.  The receiver maintains a 48-bit replay counter for each IGTK.  The replay counter, provided in either the 4-Way or Group Key handshakes, is set to the value provided by the Authenticator.  The receiver interprets the MMIE Replay field in an incoming frame as a 48 bit integer and compares this integer value against the replay counter for the IGTK identified by the MMIE Key ID field.  If the integer value from the received MMIE Replay field is less than or equal to the replay counter value for the IGTK, the receiver silently discards the frame and increments its "replay" counter.

- Protection of Unicast/Broadcast/Multicast Management Frames -

When Robust Management Frame protection is enabled and the 4-Way Handshake is completed, all transmissions of Robust Management (Action) frames are protected.  Unicast Action frames have integrity and confidentiality protection using pairwise keys.  BC/MC Action, Disassociate, and Deauthenticate frames (sent by the AP) are integrity protected only using BIP.  BIP does not provide protection against forgery by authenticated and associated non-AP stations.

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.