Rodaje

RSNA defines four different security associations (SA): a PMKSA, a PTKSA, and optionally, a GTKSA, and a STAkeySA. A SA defines the means — namely secure data transforms, keys, encryption and authentication algorithms, sequence counters, security enforcement, and exception handling policies — to enable secure communication. In the latter two types of SAs (GTKSA and STAkeySA) the AP downloads keys to the STAs, whereas the first two SAs (PMKSA and PTKSA) are established using contributory methods to compute keys.

SA parameter negotiation is the first step in establishing the RSNA. An AP may announce its security capabilities using beacon or probe response messages. STAs negotiate the security parameters, such as encryption and authentication transforms during association or reassociation, and also during the process of establishing the PTKSA, also known as the 4-way exchange.

A PMK known to an AP and a STA proves mutual authentication of the two entities. There are mainly two methods to establish a PMKSA. In the first the AP and STA are configured with a PSK, and the PSK serves as the PMK. Proof of possession of the PSK during the 4-way exchange mutually authenticates the AP and the STA. The desirable method of establishing a PMKSA is for the STA to participate in a 802.1X EAP mutual authentication procedure with an AS. An AS may be a RADIUS or Diameter server; it could be collocated with the AP in some cases. When an AS is a separate entity, it must use a secure channel (for example using IPsec, SSL) to deliver the PMK to the AP. The STA and the AP use the PMK during the 4-way exchange for mutual authentication.

The PTKSA protects the most popular type of communication — between the STA and the distribution system (DS) and beyond, via the AP — within wireless networks. Upon successful completion of an 802.1X authentication of a STA, the AP receives the PMK from the AS. After receiving the PMK, the AP initiates a 4-way exchange with the STA to establish a PTKSA. When a PSK is used for authentication, the AP initiates a 4-way exchange following successful (re)association. The 4-way exchange involves exchange of nonces in the clear, followed by integrity protected RSN IEs for SA parameter negotiation, and

encrypted delivery of a GTK where applicable. Once the PTKSA is established, the AP allows the STA to send (encrypted) data to the DS.

GTKSA establishment is part of either the 4-way exchange or a separate group key handshake. The same group key is sent to all the member STAs associated to the AP. Not all the associated STAs need be members of the secure group. There is no relationship between the PMK and the GMK, since each PMK is a one-to- one secret between a STA and the AP. Thus derivation of the GTK is solely in the control of the AP.

The STAkeySA protects direct communication between two STAs associated to a given AP. A STA requests the AP to set up a STAkeySA with another STA in an RSNA with the AP. The AP sends the same key (this is similar in notion to the group key delivery in establishing a GTKSA) to both STAs. The result is a mutually authenticated relationship between the STAs for direct secure communication. This feature serves latency sensitive applications (voice calls) between STAs in an overloaded BSS.

6.3.2 RSN IE

STAs and APs negotiate RSNA parameters using an RSN information element (IE). APs announce their security capabilities in beacon messages or in probe response messages using RSN IEs. STAs and APs negotiate security association parameters during 802.11 association, and may change them during the 4-way exchange. The parameter negotiation process is in the clear during association, but retroactively protected during the 4-way exchange. An RSN IE contains an element ID, length and version fields, and the following optional fields:

Group key cipher suite. The group key cipher suite field indicates the encryption

and integrity algorithms used to protect multicast traffic within a BSS. This field is 4 octets in length.

Pairwise key cipher suite count (PKSC). An AP may advertise or a STA may

propose multiple pairwise cipher suites (e.g., CCMP and TKIP). The PKSC field holds the number of pairwise key cipher suites advertised or proposed, and is 2 octets in length.

Pairwise key cipher suite list. This field is PKSC×4 octets in length.

Authentication and key management suite count (AKMC). There are mainly two

options for AKM in RSNs: 802.1X authentication, including PMK caching, and preshared key (PSK). Additionally, there is a provision to add vendor- specific AKM mechanisms. The AKMC field holds the number of AKM proposals and is 2 octets in length.

Authentication and key management suite list. This field is AKMC×4 octets in length.

RSN capabilities. This field is 2 octets in length and contains the following

subfields:

Preauthentication. The preauthentication field is relevant in messages orig-

inating from an AP. When set this field indicates that the AP supports preauthentication. This subfield is 1 bit in length.

Replay counters. This field defines number of replay counters supported per

PTKSA. The values 0, 1, 2, and 3 imply that the PTKSA can be used for 1, 2, 4, and 16 replay counters, respectively. This field is 2 bits in length.

PMKID count (PMKC). This field holds the number of PMKIDs in the RSN IE

and is 2 octets in length.

PMKID list. A STA can list PMKSAs that it believes are cached at a particular

AP. PMKs can be cached during a previous association with the AP, or due to preauthentication with the AP. An AP or STA may flush a PMK from its cache for any reason. A STA can choose to not include a PMKID in the RSN IE to indicate that a particular PMKSA is no longer valid. The PMKID list field is PMKC×16 octets in length.

6.4 STEPS IN ESTABLISHING AN RSN ASSOCIATION

Several types of messages and protocols are used to establish an RSN association. Recall that an RSNA contains a PMKSA and a PTKSA and optionally a GTKSA and a STAkeySA. The following protocols assist in security parameter negotiation and SA and key management. Figure 6.1 depicts the steps in RSN parameter negotiation.

• Beacons and probe messages. APs announce their RSN capabilities via RSN IEs included in beacon messages. Alternatively, a STA may send a probe request message to an AP. The AP responds with a probe response message containing an RSN IE. In most cases, an AP announces the same RSN IE (i.e., same security parameters) in beacons and probe response messages. If beacon and probe response messages differ, the STA uses the probe response message as the correct version of the AP’s capabilities. Beacons are single messages from APs, whereas probing is a 2-way exchange initiated by a STA.

• Open-system authentication. After learning an AP’s RSN capabilities, a STA uses open-system authentication to assert its identity to an AP. There is no cryptographic protection on these messages and therefore the AP validates any open system authentication request. Open-system authentication is a 2- way exchange.

• 802.11 association. Security parameter negotiation occurs during 802.11 as- sociation or reassociation. The STA selects security parameters that it imple- ments from the target AP’s RSN IE in the beacon or probe response message; it selects one pairwise cipher suite and one authentication mechanism, and the group cipher suite, if specified. The STA then constructs an RSN IE with the selected parameters, adds any PMKIDs it believes to have with the target AP, and includes the constructed RSN IE as part of the association request. The AP may include the RSN IE in the association request message or choose to send another RSN IE in the third message of the 4-way handshake for SA establishment. Note that some security parameters cannot be changed during the 4-way exchange; for example, AKM method is no longer negotiable. • Mutual authentication. PSKs or 802.1X and EAP-based authentication are

two methods specified in 802.11i for mutual authentication. In 802.1X EAP- based authentication, the AP prompts the STA to start the authentication process; the AP then forwards all the 802.1X EAP messages to a backend AS. After successful authentication, the STA and AS derive a PMK, which the AS delivers to the AP. Proof of possession of the PMK or PSK during the 4-way exchange is proof of authentication.

• 4-way exchange. The ensuing 4-way exchange to derive a PTK for traffic protection and to authenticate the RSN parameter negotiation during the as- sociation phase completes the RSNA establishment process. The AP initiates the 4-way exchange, during which the AP and STA exchange nonces used to generate a PTK from the PMK. Some of the key material generated in this process is used to protect the 4-way exchange itself. Specifically, Messages 2–4 are integrity protected, thus the nonces themselves and the RSN IE sent earlier cannot be altered in transit without detection.

The AP may send a GTK as part of the 4-way exchange; in that case, the GTK is encrypted with the key encryption key derived during the earlier phase of the 4-way exchange.

• Group key exchange. The AP may also send the encrypted GTK as part of a separate 2-way group key exchange. The GTK is accompanied by a sequence number for replay protection of multicast data from the AP to the member STAs. This exchange and GTKSA establishment itself are optional.

• STAkeySA establishment. Following the 4-way exchange — irrespective of a group key exchange — a STA may request the AP to establish a STAkeySA with another STA associated with the AP. If the AP has already completed a 4-way exchange with the other STA, it will download the STAkeySA to the peer first, and then to the requester.

802.11 Association Request: RSNIEselected 802.11 Association Response

Beacon: RSNIEannounce

AP STA

Probe Request:

Probe Response: RSNIEannounce Open System Authentication Request: SA

Open System Authentication Response

Figure 6.1 Steps in RSN security parameter negotiation.

6.5 MUTUAL AUTHENTICATION IN RSNAS

Once parameter negotiation is complete, and if 802.1X is the agreed upon authenti- cation mechanism, the STA and AS engage in 802.1X EAP exchange via the AP.

6.5.1 802.1X and EAP-Based Authentication

AS-supported mutual authentication is the recommended method to establishing a PMK in RSNs. When the AS is a third-party entity, that creates a vulnerability in enforcing authorized access to the wired network. The vulnerability is mitigated by securing the AS to AP PMK delivery (e.g., using an IPsec or SSL protected channel for secure delivery), and by the 4-way exchange between the AP and STAs. The STA engages in a 802.1X/EAP supported authentication with the AS. 802.11 recommends that asymmetrical EAP methods be used. Note that if the same

secret is used to authenticate the server and client, that method reduces in effect to PSK-based authentication. It is recommended that a tunneled EAP method (e.g., PEAP, TTLS) where the server is authenticated using certificates be used and that client authentication be carried out under the protection of the secure tunnel. A less preferred method of client and server authentication using certificates may also be used. Note, however, that in this approach the client identity is exposed to eavesdropping.

6.5.2 PMK Caching

802.1X and EAP-based authentication typically involves SSL/TLS tunnel establish- ment between the STA and AS and potential use of an IPsec SSL/TLS tunnel be- tween the AS and the AP for PMK delivery. For an actively roaming STA, repeating this computationally intensive procedure frequently may be prohibitively expensive. Recall that PDAs and low-end STAs have computational and power resource con- straints. Thus, it is beneficial to cache and reuse a PMKSA. Each PMKSA has an ID, which the STA would include in Message 1 of the 4-way exchange to estab- lish a PTKSA. There are several restrictions to PMK caching, however. A cached PMKSA’s parameters (e.g., pairwise cipher, group cipher) cannot be changed. Fur- thermore, the AP can flush a PMK from its cache for any reason; in that case the STA has to reengage in full authentication using 802.1X/EAP authentication, followed by the 4-way exchange. Each cached PMKSA is identified by a PMKID, a random value derived using the following formula:

PMKID = HMAC-SHA1-128(PMK, “PMK Name” || AA || SA), where AA is the AP’s MAC address and SA is the STA’s MAC address.