Section8 IEEE Std 802.11 and IEEE Std 802.1X-2004
5.8 IEEE Std 802.11 and IEEE Std 802.1X-2004
IEEE Std 802.11 depends upon IEEE Std 802.1X-2004 and the 4-Way Handshake and Group Key Handshake, described in Clause 8, to establish and change cryptographic keys. Keys are established after authentication has completed. Keys may change for a variety of reasons, including expiration ofan IEEE 802.1X authentication timer, key compromise, danger of compromise, or policy.
5.8.1 IEEE 802.11 usage of IEEE Std 802.1X-2004
- IEEE Std 802.11 depends upon IEEE Std 802.1X-2004 to control the flow of MAC service data units (MSDUs) between the DS and STAs by use of the IEEE 802.1X Controlled/Uncontrolled Port model. IEEE 802.1X authentication frames are transmitted in IEEE 802.11 data frames and passed via the IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is blocked from passing general data traffic between two STAs until an IEEE 802.1X authentication procedure completes successfully over the IEEE 802.1X Uncontrolled Port. It is the responsibility of both the Supplicant and the Authenticator to implement port blocking. Each association between a pair of STAs creates a unique pair of IEEE 802.1X Ports, and authentication takes place relative to those ports alone.
- IEEE Std 802.11 depends upon IEEE Std 802.1X-2004 and the 4-Way Handshake and Group Key Handshake, described in Clause 8, to establish and change cryptographic keys. Keys are established after authentication has completed. Keys may change for a variety of reasons, including expiration of an IEEE 802.1X authentication timer, key compromise, danger of compromise, or policy.
5.8.2 Infrastructure functional model overview
This subclause summarizes the system setup and operation of an RSN, in two cases: when an IEEE 802.1X AS is used and when a PSK is used. For an ESS, the AP includes an Authenticator, and each associated STA includes a Supplicant.
5.8.2.1 AKM operations with AS
- The following AKM operations are carried out when an IEEE 802.1X AS is used:
- a) Prior to any use of IEEE Std 802.1X-2004, IEEE Std 802.11 assumes that the Authenticator and AShave established a secure channel. The security of the channel between the Authenticator and the AS is outside the scope of this standard. Authentication credentials must be distributed to the Supplicant and AS prior to association.
- b) A STA discovers the AP’s security policy through passively monitoring Beacon frames or through active probing (shown in Figure 5-11). If IEEE 802.1X authentication is used, the EAP
authentication process starts when the AP’s Authenticator sends the EAP-Request (shown in
Figure 5-12) or the STA’s Supplicant sends the EAPOL-Start message. EAP authentication frames pass between the Supplicant and AS via the Authenticator and Supplicant’s Uncontrolled Ports. This is shown in Figure 5-12. - c) The Supplicant and AS authenticate each other and generate a PMK. The PMK is sent from the AS to the Authenticator over the secure channel. See Figure 5-12.
- A 4-Way Handshake utilizing EAPOL-Key frames is initiated by the Authenticator to do the following:
— Confirm that a live peer holds the PMK.
— Confirm that the PMK is current.
— Derive a fresh pairwise transient key (PTK) from the PMK.
— Install the pairwise encryption and integrity keys into IEEE Std 802.11.
— Transport the group temporal key (GTK) and GTK sequence number from Authenticator to
Supplicant and install the GTK and GTK sequence number in the STA and, if not already installed,
in the AP.
— Confirm the cipher suite selection.
-
Installing the PTK, and where applicable the GTK keys, causes the MAC to encrypt and decrypt all subsequent MSDUs irrespective of their path through the controlled or uncontrolled ports.
-
Upon successful completion of the 4-Way Handshake, the Authenticator and Supplicant have
authenticated each other; and the IEEE 802.1X Controlled Ports are unblocked to permit general data traffic. See Figure 5-13.
If the Authenticator later changes the GTK, it sends the new GTK and GTK sequnumbertotheSupplicant using the Group Key Handshake to allow the Supplicanttocontinuetoreceivebroadcastmulticmessages and, optionally, to transmit and receive unicastframes. EAPOL-Key frames are used to carry out this exchange. See Figure 5-14.
5.8.2.2 Operations with PSK
The following AKM operations are carried out when the PMK is a PSK:
— A STA discovers the AP’s security policy through passively monitoring Beacon frames or through
active probing (shown in Figure 5-11). A STA associates with an AP and negotiates a security policy. The PMK is the PSK.
— The 4-Way Handshake using EAPOL-Key frames is used, just as with IEEE 802.1X authentication,
when an AS is present. See Figure 5-13.
— The GTK and GTK sequence number are sent from the Authenticator to the Supplicant just as in theAS case. See Figure 5-13 and Figure 5-14.
5.8.2.3 Disassociation
Disassociation initiated by either STA in an RSNA causes the deletion of the PTKSA at both ends and the deletion of the GTKSA in a non-AP STA. The controlled and uncontrolled ports created for this association will also be deleted.
5.8.3 IBSS functional model description
This subclause summarizes the system setup and operation of an RSNA in an IBSS. An IBSS RSNA is specified in 8.4.7.
5.8.3.1 Key usage
- In an IBSS, the unicast data frames between two STAs are protected with a pairwise key. The key ispart of the PTK, which is derived during a 4-Way Handshake. In an IBSS, the 4-Way Handshak may follow IEEE 802.11 authentication of one STA to another. Such authentication may be used by the peer to cause deletion of the PTKSA and Block the Controlled Port thus reseting any previous handshake.
- In an IBSS, the broadcast/multicast data frames are protected by a key, e.g., named B1, that is generated by the STA transmitting the broadcast/multicast frame. To allow other STAs to decrypt broadcast/multicast frames, B1 must be sent to all the other STAs in the IBSS. B1 is sent in an EAPOL-Key frame, encrypted under the EAPOL-Key encryption key (KEK) portion of the PTK, and protected from modification by the EAPOL-Key confirmation key (KCK) portion of the PTK.
- In an IBSS, a STA’s SME responds to Deauthentication frames from a STA by deleting the PTKSA associated with that STA.
5.8.3.2 Sample IBSS 4-Way Handshakes
- In this example (see Figure 5-15), there are three STAs: S1, S2, S3. The broadcast/multicast frames sent by S1 are protected by B1; similarly B2 for S2, and B3 for S3.
- For STAs S2 and S3 to decrypt broadcast/multicast frames from S1, B1 must be 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 broadcast/multicast frames to S2, but does not allow S2 to send broadcast/multicast 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 decryptS2sbroadcast/multicastframes.Similarly, 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 STA 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 STA 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 8.5.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 until both 4-Way Handshakescomplete.
- f 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 STA 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 PSK or IEEE 802.1X authentication) from the Beacon or Probe Response frame. The initiation may 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) A STA’s 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 multicast/ broadcast data frame transmitted by any of the STAs. If the SME wants to set up a security association to the peer STA, but does not know the security policy of the peer, it should 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) A STA’s 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. If a STA received a 4-Way Handshake, wants to set up a security association to the peer STA, but does notknow the security policy of the peer, it should send a Probe Request frame to the peer STA to find its security policy before setting up a security association to the peer STA.
5.8.3.3 IBSS IEEE 802.1X example
- When IEEE 802.1X authentication is used, each STA will need to include an IEEE 802.1X Authenticator and AS. A STA learns that a peer STA is RSNA-enabled and the peer’s security policy (e.g., whether the AKMP is PSK or IEEE 802.1X authentication) from the Beacon or Probe Response frame.
- Each STA’s Supplicant will send an EAPOL-Start message to every other STA to which it wants to authenticate, and each STA’s Authenticator will respond with the identity of the credential it wants to use. The EAPOL-Start and EAP-Request/Identity messages are initiated when a protected data frame (indicated via a MLME-PROTECTEDFRAMEDROPPED.indication primitive), an IEEE 802.1X message, Beacon frame, or Probe Response frame is received from a MAC address with which the STA has not completed IEEE 802.1X authentication. If the SME wants to set up a security association to the peer STA, but does not know the security policy of the peer, it should send a Probe Request frame to the peer STA to find its security policy before setting up a security association to the peer STA.
- Although Figure 5-16 shows the two IEEE 802.1X exchanges serialized, they may occur interleaved.
5.8.4 Authenticator-to-AS protocol
- The Authenticator-to-AS authentication definition is out of the scope of this standard, but, to provide security assurances, the protocol must support the following functions:
- a) Mutual authentication between the Authenticator and AS
b) A channel for the Supplicant/AS authentication
c) The ability to pass the generated key from the AS to the Authenticator in a manner that provides authentication of the key source, ensures integrity of the key transfer, and preserves data confidentiality of the key from all other partie - Suitable protocols include, but are not limited to, remote authentication dial-in user service (RADIUS) (IETF RFC 2865-2000 [B23]) and Diameter (IETF RFC 3588-2003 [B25]).
5.8.5 PMKSA caching
- The Authenticator and Supplicant may cache PMKSAs, which include the IEEE 802.1X state. A PMKSA can be deleted from the cache for any reason and at any time.
- The STA may supply a list of PMK or PSK key identifiers in the (Re)Association Request frame. Each key identifier names a PMKSA; the PMKSA may contain a single PMK. The Authenticator specifies the selected PMK or PSK key identifier in Message 1 of the 4-Way Handshake. The selection of the key dentifiers to be included within the (Re)Association Request frame and Message 1 of the 4-Way Handshake is out of the scope of this standard.
