DÉCIMO INTENTO (LA LÍNEA DEL TIEMPO DE LAS LECTURAS LITERARIAS

STAkeySAs protect direct communication between two STAs that are associated with the same AP. Generally speaking communication between two such STAs is via the AP. But, for better quality of service, it is more efficient to use direct link layer communication between the two STAs. This feature is especially useful when an AP is busy forwarding other traffic, or in case of latency-sensitive applications such as voice over IP.

The initiating STA controls security parameter selection in this case. It sends an EAPOL-key request message with the request flag set and with a MAC address IE (containing the target STA’s address) in the key data field. The key description version field indicates the pairwise cipher: 1 for TKIP and 2 for CCMP.

The AP sends a STAkey message 1 containing the initiator’s MAC address and the STAkey to the target STA. The target STA responds with STAkey message 2 as an acknowledgment. The AP then sends another STAkey message 1 to the initiator STA with the target’s MAC address and the STAkey as part of the Data field of the EAPOL-key frame. The initiator STA acknowledges the message.

The AP derives the STAkey in a similar fashion as the GTK. The two keys must be cryptographically different, however. Thus, STAMK must be generated independent of the GMK. The EAPOL-key frames are protected using the EAPOL KEK and KCK derived as part of the PTK.

6.8 SUMMARY

RSNAs consist of strong security parameter negotiation SA establishment to sup- port secure STA-to-DS communication via the AP, STA-to-STA communication

independent of the AP, and AP-to-STA group communication. After security param- eter negotiation, the STA authenticates itself to an AS using 802.1X/EAP protocol. After successful authentication, the STA and AS agree on a PMK, which the AS delivers to the AP. Proof of possession of the PMK is proof of mutual authentication. A 4-way key management exchange is used to derive a PTKSA to protect the key management frames, authenticate the security parameter negotiation, and to protect data MPDUs between the STA and the DS. The PTKSA also protects downloading GTK as well as STAkeys.

This chapter provides a high-level summary of the RSNA protocols and SAs for a quick review of the security properties and the protocol details. It is not a substitute for the 802.11i specification.

References

[1] B. Aboba and D. Simon, “PPP EAP TLS Authentication Protocol.” RFC 2716 (Experimental), Oct. 1999.

[2] P. Funk and S. Blake-Wilson, “EAP Tunneled TLS Authentication Protocol (EAP-TTLS),” draft- ietf-pppext-eap-ttls-00 (work in progress), Internet Engineering Task Force, Aug. 2001.

[3] A. Palekar, D. Simon, G. Zorn, J. Salowey, H. Zhou, and S. Josefsson, “Protected EAP Protocol (PEAP) Version 2,” draft-josefsson-pppext-eap-tls-eap-07 (work in progress), Internet Engineering Task Force, Oct. 2003.

[4] F. Bersani and T. Tschofenig, “The EAP-PSK Protocol: a Pre-Shared Key EAP Method,” draft- bersani-eap-psk-01 (work in progress), Internet Engineering Task Force, Feb. 2004.

[5] F. Bersani, “EAP Shared Key Methods: A Tentative Synthesis of Those Proposed So Far,” draft- bersani-eap-psk-01 (work in progress), Internet Engineering Task Force, Apr. 2004.

[6] D. Stanley, J. Walker, and B. Aboba, “EAP Method Requirements for Wireless LANs,” draft- walker-ieee802-req-04 (work in progress), Internet Engineering Task Force, Aug. 2004. [7] N. Asokan, V. Niemi, and K. Nyberg, “Man-in-the-Middle in Tunnelled Authentication Protocols.”

Cryptology ePrint Archive, Report 2002/163, 2002, http://eprint.iacr.org.

[8] M. Bellare and P. Rogaway, “Entity Authentication and Key Distribution,” Advances in Cryptology — Crypto, Springer-Verlag, Aug. 1994. LNCS 773.

[9] H. Krawczyk, “The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?),” Advances in Cryptology — Crypto, (Santa Barbara, CA), pp. 310–331, Springer-Verlag, Aug. 2001. LNCS 2139.

[10] D. Eastlake III, S. Crocker, and J. Schiller, “Randomness Recommendations for Security.” RFC 1750 (Informational), Dec. 1994.

[11] C. He and J. C. Mitchell, “Security Analysis and Improvements for IEEE 802.11i,” Proceedings of Network and Distributed System Security Symposium (NDSS), (San Diego, CA), Feb. 2005.

CCMP

7.1 INTRODUCTION

RSNs provide data protection and enforce network access control. An RSNA consists of a PTKSA and optionally a GTKSA, and zero or more STAkeySAs. Each SA contains one or more secret keys for data encapsulation, and policy that specifies the encapsulation protocol, SA endpoints’ addresses, and so forth (see Chapter 6). The 802.11i [1] specification lists WEP, TKIP, and CCMP as the data encapsulation protocols with a requirement that RSN devices implement CCMP.

CCMP includes the use of AES counter mode (CTR) for encryption and AES cipher block chaining (CBC) based message integrity code (MIC) for the integrity protection of MPDUs, with a single 128-bit key. Another new data encapsulation protocol known as the temporal key integrity protocol (TKIP), with RC4 as the encryption protocol and Michael as the message integrity algorithm, is to be implemented for legacy hardware based transition security networks (TSN) (see Chapter 8).

Counter mode for encryption, in conjunction with CBC-MAC for message integrity, developed first for use in WLANs and proposed to NIST as a general mode for data protection, is generally known by its short form, CCM (Counter mode with CBC-MAC) [2] mode. CCM is an authenticated encryption mode and can be used in a wide variety of networks including 802.11 RSNs, 802.16 [3, 4] networks (see Chapter 12), and with IPsec [5] in IP networks.

In RSNs, the CCM protocol (CCMP) provides cryptographic protection for MPDUs being transmitted via shared WLANs. In addition to the confidentiality and integrity protection provided by CCM, the protocol provides replay protection, and in summary, supports controlled access to the wired network.

Since CCM is common to 802.11 RSNs as well as 802.16 networks (discussed in Chapters 11 and 12), we separate the discussion on CCMP into two parts. First,

in Section 7.2 we discuss AES CCM mode in detail. Section 7.4 discusses CCM parameter selection for 802.11 RSNs and other pertinent protocol specific details.

7.2 AES CCM MODE

CCM is an authenticated encryption mode using a 128-bit key with AES as the underlying block cipher. Other block lengths are possible, but they are not part of the current description. CCM belongs to a class of modes known as combined modes where the same key is used for encryption as well as authentication.

In the rest of this section we describe the CCM mode in detail and explain how it gets around various potential pitfalls. CCMP is an instantiation of the CCM mode that builds on CCM, making the best design choices for WLAN environments; it includes additional techniques to strengthen the mode, and provides more security properties. CCM uses AES-CTR mode for encryption and CBC-MAC for message integrity. It first computes the message integrity code (MIC) using CBC-MAC, and encrypts the message and the MIC using CTR mode encryption.

7.2.1 CCM Parameters

We first describe some terminology that helps us understand the CCM mode. • A single 128-bit key, K, is used for message integrity as well as encryption. • There is a provision to authenticate message headers, if any. While this is

desirable, some of the fields in message headers may need to be changed in transit or during retransmission. CCM mode is flexible enough to allow selective authentication of the headers. In general terms, the CCM mode includes additional authentication data (AAD) in computing the integrity checksum. In the balance of this chapter, we use AAD to indicate portions of message headers to be authenticated, and l(AAD)to indicate the length of AAD in octets; 0≤l(AAD)<264.

• L denotes the number of octets in the length of the message, m, to be encapsulated using CCM; l(m)denotes the number of octets in the message to be encapsulated, where, 0≤l(m)<28L. The length field may occupy 2 to 8 octets in CCM.

• The CTR mode encryption requires a nonce. CCM mode uses a nonce of length 15−L. The nonce, length of the message protected with a given nonce,

and flags encoding the nonce length and length of the message length fit in a single 16-octet block (size of the block in the underlying cipher).

• M is the number of octets in the MIC. M is encoded as (M-2)/2, and authenticated by being included in the MIC computation.

7.2.2 MIC Computation Using AES-CBC-MAC

CCM supports MICs of length in even numbers between 4 and 16 octets. A 4-octet MIC is too small for most applications, although SRTP [6] allows use of a 4-octet MIC for packet transmission over low bandwidth links, with the caveat that the integrity protection thus afforded is suspect at best. IPsec ESP [7] specifies the use of a 12-octet MIC and TLS [8], a 16-octet MIC. While a short MIC provides little or no integrity protection, a longer MIC would result in excessive per packet/frame overhead.

CCM MIC is computed over a sequence of blocks Bi,0≤i≤n, where • B0contains the nonce, message length, and a flag indicating the presence of

additional authentication data, nonce length, and the length of the message length.

• Bi, i>0 contains the length of AAD, if present, followed by the AAD itself. • The message m divided into 16-octet blocks follows the AAD.

7.2.2.1 Components of B0

The first octet of B0consists of a flag named Adata, which indicates whether AAD is present or not; bit 6 if set, indicates that an AAD is part of the MIC computation. Bit 7 is reserved and must be zero. Bits 5, 4, and 3 contain the length of the MIC encoded as(M−2)/2, where M is the length of the MIC in octets. The value of

(M−2)/2 must not be zero, for it has two implications: a MIC of length 2 octets is not allowed, and more importantly the nonzero value is a precondition for the security of the CCM mode. The final three bits, 2, 1, and 0, represent the number of octets in the length of the message, encoded as L−1.

The next octets, from 1 to 15−L contain the nonce. The last L octets contain

the message length in octets. Figure 7.1 illustrates the composition of B0.

7.2.2.2 Composition of Bi, i > 0

If the Adata flag is set, Bis contain l(AAD)followed by the AAD. Depending on the length of the AAD, l(AAD)is encoded as follows [2]:

• If 0<l(AAD)<(216₋₂8_{), l(AAD)occupies two octets with values 0x0001} to 0xFEFF.

Reserved 0 Bit(s): 7 Adata 6 (M−2)/2 L−1 M: Length of MIC, 4, 6, 8, 10, 12, 14, 16 5−3 2−0 Flags (Octet 0)

L: Number of octets in the length field, 2−8 l(m): length of message; 0 <= l(m) < 28L

Nonce N (Octets 1 ... 15−L) l(m) (Octets 16−L ... 15) 16 octets

Figure 7.1 Contents of B0in CCM MIC computation.

• If 216−28≤l(AAD)<232, l(AAD)is encoded as 0xFFFE in the first two octets, and the the value l(AAD)in the next four octets.

• If 232≤l(AAD)<264, l(AAD)is encoded as 0xFFFF in the first two octets, and the the value l(AAD)in the next eight octets.

In summary, l(AAD) occupies two, six, or eight octets. The l(AAD) thus formed is prepended to AAD to form one or more 16-octet blocks, Bi, i>0, padding the excess bits of the last block with zeros if necessary.

The final step in forming the Biblocks is to split the message m into 16-octet blocks, once again padding the excess bits of the last block with zero as necessary. Recall that l(m)is part of block B0.

7.2.2.3 MIC Computation

The 16-octet blocks, Bi, are used in the following expression to compute the MIC.

X1=EAES−CBC−128(K,B0)

Xi=EAES−CBC−128(K,XiXOR Bi)1≤i≤n MIC = first-M-octets-of(Xn+1)

7.2.3 AES-CTR Mode Encryption in CCM

For encryption, the CCM specification defines a different set of blocks Ai, i≥0. Considering that CCM uses the same key for both integrity protection as well as encryption, A0 and B0 must be different for this mode to be secure. Thus, A0 is different from B0by design; specifically bits 7 through 3 in the first octet of A0must be zero. Contrast this to the first octet in B0, where the combined value represented by bits 5 through 3 cannot be zero. Bits 2, 1, 0 in A0are identical to those in B0. Similarly, A0also contains the nonce in octets 1 through 15−L; however, the last L octets contain the value of a counter starting at 0, instead of l(m)as in B0. Thus, in

A0, the counter value is 0, since i=0. The first 16−L octets of Ai, i>0 are identical to those in A0, whereas the last L octets contain a counter equal to i, occupying L octets. Figure 7.2 illustrates the composition of Ai, i≥0.

16 octets 0 Bit(s): 7 6 0 L−1 5−3 2−0 Flags (Octet 0) Reserved Reserved 0 Nonce N (Octets 1 ... 15−L) Counter i (Octets 16−L ... 15) i = 0, 1, 2, ...

L: Number of octets in the length field, 2−8

Figure 7.2 Components of blocks Aifor AES counter mode encryption in CCM.

Using the 16-octet blocks Ai, CTR mode message and MIC encryption in

CCM are defined as follows:

Si=EAES−128(K,Ai),i≥0

Encrypted-MIC = MIC XOR first-M-octets-of(S0) cipher-text c = m XOR(S1|| S2||...|| S₂l(m)/16)

The output of the CCM encapsulation of a message m would be the cipher text c obtained following the CTR mode encryption, appended by the encrypted MIC calculated following the procedure described above.