Sample IBSS 4-Way Handshakes

4.10.4.3 Sample IBSS 4-Way Handshakes

In this example (see Figure 4-22), there are three STAs: S1, S2, S3. The group addressed frames sent by S1
are protected by B1; similarly B2 for S2, and B3 for S3.
For STAs S2 and S3 to decrypt group addressed frames from S1, B1 is sent to S2 and S3. This is done using
the 4-Way Handshake initially and using the Group Key Handshake for GTK updates.
The 4-Way Handshake from S1 to S2 allows S1 to send group addressed frames to S2, but does not allow S2
to send group addressed frames to S1 because S2 has a different transmit GTK. Therefore, S2 needs to
initiate a 4-Way Handshake to S1 to allow S1 to decrypt S2’s group addressed frames. Similarly, S2 also
needs to initiate a 4-Way Handshake to S3 to enable S3 to receive group addressed messages from S2.
In a similar manner S3 needs to complete the 4-Way Handshake with S1 and S2 to deliver B3 to S1 and S2.
In this example, there are six 4-Way Handshakes. In general, N Supplicants require N(N–1) 4-Way
Handshakes.

NOTE—In principle the KCK and KEK from a single 4-Way Handshake can be used for the Group Key Handshake in
both directions, but using two 4-Way Handshakes means the Authenticator key state machine does not need to be
different between IBSS and ESS.
The Group Key Handshake can be used to send the GTKs to the correct STAs. The 4-Way Handshake is
used to derive the pairwise key and to send the initial GTK. Because in an IBSS there are two 4-Way
Handshakes between any two Supplicants and Authenticators, the pairwise key used between any two STAs
is from the 4-Way Handshake initiated by the STA Authenticator with the higher MAC address (see 11.6.1
for the notion of address comparison). The KCK and KEK used for a Group Key Handshake are the KCK
and KEK derived by the 4-Way Handshake initiated by the same Authenticator that is initiating the Group
Key Handshake.
In an IBSS a secure link exists between two STAs when both 4-Way Handshakes have completed
successfully. The Supplicant and Authenticator 4-Way Handshake state machines interact so the IEEE
802.1X variable portValid is not set to 1 until both 4-Way Handshakes complete.
If a fourth STA comes within range and its SME decides to initiate a security association with the three
peers, its Authenticator initiates 4-Way Handshakes with each of the other three Supplicants. Similarly, the
original three STA Authenticators in the IBSS need to initiate 4-Way Handshakes to the fourth STA
Supplicant. A STA learns that a peer STA is RSNA-enabled and the peer’s security policy (e.g., whether the
Authentication and Key Management Protocol (AKMP) is SAE, PSK, or IEEE 802.1X authentication) from
the Beacon or Probe Response frame. The initiation might start for a number of reasons:
a) The fourth STA receives a Beacon or Probe Response frame from a MAC address with which it has
not completed a 4-Way Handshake.
b) An SME receives a MLME-PROTECTEDFRAMEDROPPED.indication primitive from a MAC
address with which it has not completed a 4-Way Handshake. This could be a group addressed data
frame transmitted by any of the STAs. In order to set up a security association to the peer STA, an
SME that does not know the security policy of the peer can send a Probe Request frame to the peer
STA to find its security policy before setting up a security association to the peer STA.
c) An SME receives Message 1 of the 4-Way Handshake sent to a STA because the initiator received a
broadcast data frame, Beacon frame, or Probe Response frame from that STA. In order to set up a
security association to the peer STA, a STA that received a 4-Way Handshake but does not know the
security policy of the peer can send a Probe Request frame to the peer STA to find its security policy
before setting up a security association to the peer STA.