MPDU Encapsulation and Decapsulation

We conclude Section 7.4 with a discussion on CCMP encapsulation and decapsu- lation of 802.11 MPDUs. CCMP transforms MPDUs to provide confidentiality of the frame body, and integrity and replay protection for the MAC header as well as the frame body itself. The FCS within each MPDU is left intact by the encapsu- lation protocol. The AAD is derived entirely from the MAC header. The nonce is constructed using the second address field from the MAC header, the priority field, and a monotonically increasing counter. Recall that the counter also serves as a PN for MPDU replay protection.

The 6-octet PN is included in the transformed MPDU (see Figure 7.6). The encrypted MIC derived using the CCM mode is also included to add 8 more octets to the MPDU. In addition to these 14 octets, 2 more octets — one octet containing 0 and reserved for future use, and another containing 5 reserved bits, an extIV flag occupying 1 bit, and a key ID field requiring 2 bits — are also added, to result in a total MPDU expansion of 16 octets due to CCMP encapsulation. The extIV bit is always set for CCMP and the key ID identifies the PSK used.

CCMP decapsulation follows the encapsulation process in constructing the AAD, nonce, and PN fields. First, the AAD can be constructed exclusively from the

MAC hdr 30 octets >= 1 octet Frame body CRC−32 4 octets MIC 8 octets PN5 PN4 PN3 PN2 PN0 PN1

MAC protocol data unit (MPDU)

CCM decapsulation 8 octets CCM encapsulation 1 bit 1 octet Reserved 5 bits ext IV Reserved key ID 2 bits MAC hdr 30 octets CRC−32 4 octets >= 1 octet Frame body Figure 7.6 CCMP headers.

received MAC header. Next, the nonce is built using fields from the received MAC header and the received PN. Finally, the PN field is part of the CCMP header. The recipient uses the AAD and the nonce to compute the MIC of the received message and compares it to the received MIC. If the MICs are identical, it then verifies that the PN is greater than or equal to the expected PN corresponding to the SA and the MPDU priority. After that the recipient proceeds to decrypt the entire MPDU.

7.5 SUMMARY

This chapter provided a brief description of the CCMP protocol and its base AES mode known as the CCM mode. The underlying block cipher uses a 128-bit key, which is used for both integrity protection as well as encryption by the CCM mode. In addition to the security properties of the CCM mode, CCMP provides MPDU replay protection. Furthermore, CCMP fortifies some of the weaker points of the CCM mode by using a strong nonce construction mechanism, and appropriate parameter selection such as nonce length and MIC size.

References

[1] IEEE, “IEEE Std 802.11i-2004, Amendment to IEEE Std 802.11, 1999 Edition (Reaff 2003),” Amendment 6: Medium Access Control (MAC) Security Enhancements Part 11, IEEE Press, New York, Apr. 2004.

[2] D. Whiting, R. Housley, and N. Ferguson, “Counter with CBC-MAC.” RFC 3610 (Informational), Aug. 2003.

[3] IEEE, “Draft IEEE Standard for Local and Metropolitan Area Networks; IEEE802.16-Revd/D5- 2004,” Tech. Rep. Part 16, IEEE Press, New York, 2004.

[4] “Draft IEEE Standard for Local and Metropolitan Area Networks; IEEE802.16e/D5a,” Tech. Rep. Part 16, IEEE Press, New York, Dec. 2004.

[5] R. Housley, “Using AES CCM Mode with IPsec ESP,” draft-ietf-ipsec-ciph-aes-ccm-05 (work in progress), Internet Engineering Task Force, Nov. 2003.

[6] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, “The Secure Real-Time Transport Protocol (SRTP).” RFC 3711 (Standards Track), Mar. 2004.

[7] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401 (Proposed Standard), Internet Engineering Task Force, Nov. 1998.

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

[9] J. Jonsson, “On the Security of CTR + CBC-MAC,” Proceedings of the Ninth Annual Workshop on Selected Areas of Cryptography SAC 2002; LNCS, (St. John’s, NF, Canada), Springer, Aug. 2002.

[10] D. McGrew, “Counter Mode Security: Analysis and Recommendations.”

TKIP

8.1 INTRODUCTION

TKIP is a stop-gap protocol for secure encapsulation of 802.11 frames in legacy 802.11 devices. In brief, TKIP attempts to patch the many vulnerabilities of WEP using an assortment of techniques. TKIP design includes a per-MSDU fresh key generation scheme required to properly use RC4, a longer IV, a new lightweight integrity protection scheme known as Michael, and a counter-based replay protec- tion mechanism. Design choices favor legacy hardware support and thus this is not a long-term solution. For instance, Michael as a MIC is limited in the protection it offers, requiring attack throttling mechanisms as an integral part of the solution. The advantage of the design is that TKIP can be implemented with only a firmware upgrade to allow enterprise and home networks to gradually phase out the legacy WLAN devices in favor of CCMP (see Chapter 7) capable devices. Thus, legacy WLANs implementing TKIP are known as transition security networks (TSN).

The rest of this chapter is organized as follows. In the first section, we will discuss TKIP design — including motivation, design goals, constraints, and choices — in detail. Next, we will discuss each of the TKIP design components. Section 8.3 describes the first component, the specially designed MIC algorithm, Michael, and its application to WLAN MSDUs. The second component — the design of temporal key computation and WEP encapsulation and decapsulation processes — is the topic of Section 8.6. The third component of TKIP design is the per-MPDU sequence counter for replay protection, discussed in Section 8.5. TKIP design constraints translate to use of less than perfect encryption and integrity algorithms. Thus, TKIP employs noncryptographic countermeasures to throttle such attacks. TKIP countermeasures are the topic of discussion of Section 8.6.1. We conclude the chapter with a summary of TKIP in Section 8.7.