1. Lightweight Authentication Mode with Header Authentication IEEE 802.16 Presentation Submission Template (Rev. 9) Document Number: IEEE S802.16m-08/907r1 Date Submitted: 2008-09-14 Source: Susan Hartman Intel CorporationE-mail: susan.hartman@intel.comsusan.hartman@intel.com David Johnston Intel CorporationE-mail:dj.johnston@intel.comdj.johnston@intel.com Venue: Call for Contributions, IEEE 802.16m-08/033 Base Contribution: Re: MAC: Security Purpose: To improve the signaling overhead in management traffic introduced by integrity protection mechanisms. Notice: This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16. Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: and.http://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/guides/opman/sect6.html#6.3 Further information is located at and.http://standards.ieee.org/board/pat/pat-material.htmlhttp://standards.ieee.org/board/pat

2. Lightweight Authentication Mode with Header Authentication Susan Hartman, Intel Corporation David Johnston, Intel Corporation Background and Motivation: Security in 16m is necessary but has cost (bandwidth usage). In particular, the CMAC TLV provides authentication but adds 15 bytes to most management messages. In 16e the signaling headers do not include CMAC for authentication, thus leaving the system open to Denial-of- Service attacks. The minimum 16e radio resource allocation for MAC messages is 6 bytes leaving no room for CMAC. MAC Signalling headers are employed with no integrity protection. This creates a number of serious DoS opportunities. E.G. by spoofing incorrect information on the channel quality. From a security standpoint there are essentially two system operating modes: Under Attack Not Under Attack This proposal has two related security ideas: 1.Take advantage of the two operating modes and use a Partial CMAC TLV when Not Under Attack. When Under Attack, use the full CMAC TLV. 2.Add a CMAC TLV or Partial CMAC TLV to the MAC signaling headers. The necessary details are explained in the following text.

3. Reminder: the 16e CMAC Tuple Value Notice that there is a small terminology issue here with the term “CMAC Value”. Table 603 shows “Value” portion of Type, Length, Value, and the last item in the table is also called “CMAC Value”.

4. Proposed Partial CMAC Tuple Type and Value, omit LengthType and Value, omit Length Include partial (12 bits) CMAC Value in messageInclude partial (12 bits) CMAC Value in message (BSID never needed)(BSID never needed) Could also possibly shorten Packet Number CounterCould also possibly shorten Packet Number Counter Total length of TV: 7 bytesTotal length of TV: 7 bytes

5. PARTIAL CMAC TV IN SIGNALING HEADERS Assume that the 16m MAC signaling headers provide 12 data bytes: The proposed 16m Physical Resource Unit (PRU) has 18 subcarriers x 6 symbols. 6 subcarriers are pilots, which are allocated per stream. Assuming 2 streams for the baseline, there are 12 pilot subcarriers per PRU. As a result there are 18*6 = 108 subcarriers in a PRU and (18- 2)*6=96 data subcarriers per PRU. Using QPSK(1/2) as the Modulation and Coding Scheme (MCS) for transmission, then each subcarrier effectively carries 1 bit. The PRU carries 96 bits or 12 bytes. 12-7 = 5,  there are 5 bytes available for signaling header

6. SIGNALING AND OPERATION Security Operating Mode is indicated in BCH Under Attack: Full CMAC TV (Type, Value) MAC signaling headers are 2 PRUs (24 bytes) and have full CMAC TV Not Under Attack: Partial CMAC TV (Type, Value) – different type is used MAC signaling headers are 1 PRU (12 bytes) and have Partial CMAC TV Detecting Attacks: In management messages: if CRC is valid but Partial CMAC TV is invalid. In signaling headers: HCS is valid but Partial CMAC TV is invalid. BS can periodically check for continuing attack and resume Not Under Attack when it finds that attack does not continue.

7. SDD TEXT - Security Insert the following text into Medium Access Control Security section (Chapter 12): ------------------------------- Text Start --------------------------------------------------- 12.x System Security Operating Modes IEEE 802.16m has two system security operating modes: –Under Attack –Not Under Attack An authentication field is required in some MAC management messages (FFS) and all MAC signaling headers. IEEE802.16m provides an authentication field to use when under attack and a shorter version of the same authentication field to use when not under attack. BSs and MSs determines if an attack is in progress by noticing messages with correct CRC but incorrect authentication field. Similarly, BSs notices MS signaling headers with correct HCS but incorrect authentication field. MS informs BS about attack in progress and BS determines which authentication field shall be used. BS periodically tests to see if the attack has stopped and if it is OK to return to not under attack operation. BS includes logic so that it does not change back to not under attack such that the system constantly switches back and forth between the modes. BS indicates the security operating mode in the BCH. When not under attack, MAC signaling headers use partial CMAC tuple ; when under attack, MAC signaling headers use full CMAC tuple. A station may always choose to use the full CMAC tuple, even if the BS is signaling the Not Under Attack mode. The compressed message authentication tuple is as follows: ------------------------------- Text End ---------------------------------------------------