September 2006 doc IEEE 802 11 061348 r

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Security issues with respect to TGn MAC changes Ref: LB 84 CID 116 and 7174 Authors: Date: 2006 -08 -18 Notice: This document has been prepared to assist IEEE 802. 11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) 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. 11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http: // ieee 802. org/guides/bylaws/sb-bylaws. pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard. " Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart. kerry@philips. com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802. 11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee. org>. Submission 1 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 CID 116 – address security interaction 116 Bagby, David Submission 0 General The impacts of TGn and security appear to this reviewer to be unknown as of the time of LB 84. As the reviewer is not specifically a security experts, he would request that the. 11 standing cmtee on security) review the TGn draft - except that. 11 never seems to have actually established the security cmtee. . . 2 Provide an analysis of Tgn impacts on security - the reviewer will consider withdrawing this comment depending on the result of the analysis. Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 TGn impacts on security • HTC field impact on CCMP AAD • Encryption of Qo. S Null DATA with embedded Management Action body • A-MSDU length limits Submission 3 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 HTC Field impact on CCMP AAD Submission 4 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 HT Control Field in MAC Header • HTC field – New for TGn – FOUR more bytes to the MAC header • Conditionally present – Presence signaled by the ORDER bit of the FC field (first two bytes of the MAC header) in all type/subtype frames except non-Qo. S DATA subtypes • HTC contains mostly dynamic bits – Should these four bytes be part of the CCMP AAD calculation? • Or should they be masked? • Or partially masked? Submission 5 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 TGn MAC HEADER Octets: 2 2 6 6 6 2 0 or 6 0 or 2 0 or 4 0 -2324 4 Frame Control Duration /ID Address 1 Address 2 Address 3 Sequence Control Addr ess 4 Qo. S Control HT Control Frame Body FCS MAC Header • HT Control field is present optionally, based on the ORDER bit of the Frame Control field – And some of the Type and Subtype bits of the Frame Control field – Note that HT Control field is NEVER present without Qo. S Control field in a DATA Type (where encryption matters) – HTC position is either bytes: 25 to 30 or 31 to 36 Submission 6 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 TGn HTC control field # B 0 B 15 B 16 17 B 18 19 B 20 B 21 B 22 B 23 B 24 B 25 B 29 B 30 B 31 Link Adaptation Control Calibration Position Calibration Sequence Feed back reque st CSI/ Steering ZLF Announce ment Reser ved AC Cons traint RDG/More PPDU 16 2 2 1 5 1 1 # Bit s • Most of these bits can change per transmission of a given MPDU – E. g. RDG/More PPDU, ZLF announcement Submission 7 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Link adaptation control field (lower 16 bits of HTC) # Bits B 0 B 1 B 2 B 3 MA TRQ MRS/ASI 1 1 1 B 5 B 6 B 8 MFS 3 B 9 B 15 MFB/ASC 3 7 Link Adaptation Control field • MA bit is static (Management Action embedding) • Remainder of bits are potentially dynamic Submission 8 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Is the HTC field presence dynamic? • The HTC field itself might come and go per attempt of a given MPDU – TXOP initiator desires to attempt to deliver an RDG • HTC field is present – Frame exchange fails, and RDG Grantee does NOT take the grant • No other current need for HTC field bits – TXOP initiator performs next attempt of transmission • Either in the same TXOP or in a new TXOP • Decision for RDG has changed – no grant to be made • HTC field no longer needed in the frame – Saves 4 bytes to eliminate it • Suggests that entire HTC field is masked, and ORDER bit – Modifies the AAD CCMP calculation per QOS subtype of DATA Submission 9 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 HTC field possibilities – A) MASK all but the MA bit of the HTC • Note that MA is only defined for use in the Qo. S Null case – B) MASK all of the HTC • Effectively allowing the HTC field to be dynamically present within an MPDU • Example: – STA sends an RDG on an initial attempt which fails – STA decides that not enough time remains in the TXOP for an RDG at retransmission – STA zeroes the RDG in the retransmission, and as a result, has no need for any of the four bytes of the HTC – C) MASK ORDER bit • Could make masking operation conditional on SUBTYPE b 7 (QOS) Submission 10 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 HTC field recommendation • Mask the entire HTC field for CCMP AAD calculation when the HTC field is present – No change to existing standard • Mask the ORDER bit conditionally – Based on the protected B 7 of the subtype field • “QOS bit” of the DATA subtypes • Masked when B 7=1 • Does not collide with legacy equipment – Legacy STA transmitting frames with B 7=1 NEVER set ORDER=1 Submission 11 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Encryption of Qo. S Null DATA with embedded Management Action body Submission 12 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 QOS-Null with Embedded MA frame • The anticipated use of the embedding of action frames within QOS NULL frames is to provide a vehicle for the immediate response of channel state information to the receipt of a request for such information. • Because this information is not generated by an upper layer, it cannot appear within the normal body portion of a non-NULL DATA type. • • Because the frame is temporally located in an immediate response, it should solicit no secondary immediate response. Therefore, it is convenient to use a frame with the ACK policy field set to indicate a NOACK policy. The ACK policy field exists only within the QOS CONTROL field, which is only defined to exist within QOS DATA type frames. QOS-NULL subtype satisfies these requirements. Submission 13 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 The Qo. S Null Embedded MA problem • MA bit of HTC field allows for MGMT Action frame body to be included as body of DATA Qo. S Null frame – Qo. S Null frame has a TID field • TID has no “reserved” value – This frame will appear as though it belongs to some other flow as identified by (AD 2, Priority) • Unless it is specifically called out as not belonging because it is a Qo. S Null frame – But subtype bits 4, 5, 6 are MASKED during CCMP AAD construction and hence, not secure • Nonce does not account for subtype – And subtype is masked in CCMP AAD construction… Submission 14 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Qo. S Null (in general) encryption (or not) • 8. 4. 10 RSNA security association termination c) – NOTE 2—Because the IEEE 802. 11 null data MPDU does not derive from an MA-UNITDATA. request, it is not protected. – But what happens at the RX side? • Does it get shunted to MGMT sublayer before being deleted because it looks like it belongs to some flow, but is not privacy=1? – Implementations seem to key on QOS NULL subtype and always expect them to be unencrypted, but standard is silent on RX behavior. • 7. 1. 3. 1. 9 Protected Frame field – The Protected Frame field is set to 0 in Data frames of subtype Null Function, CF-ACK (no data), CF-Poll (no data), and CF-ACK+CF-Poll (no Data) (see clauses 8. 3. 2. 2 and 8. 3. 3. 1 that show that the frame body must be one octet or longer to apply the encapsulation). Submission 15 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 QOS NULL problems detail • Decryption at the RX side has only A 2 and the QOS TID to determine the NONCE value. If a QOS NULL frame is encrypted, the NONCE for that packet might match the NONCE for some other QOS-DATA frame packet and this could create a problem when examining the PN value. • If the QOS NULL packets were treated as a separate PN space, then there is no collision of the PN space. Obviously, this would have to be stated as part of any QOS NULL encryption description. • But, does this introduce a security hole, since we would now be using an identical nonce value for two different flows with parallel PN numbering which use the same key? If that is a problem, then would it be acceptable to modify the NONCE calculation just for the QOS NULL frames? Or is that a weak solution? Submission 16 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 More QOS NULL problem detail • • • It might be possible to attempt to include the QOS NULL frames as part of the set of DATA frames that share the same A 2 and TID value - however, this is problematic, since the QOS NULL frames have an unused sequence number field. One might propose that they start using a valid sequence number which is associated with the similarly-labeled (QOS TID that is) QOS DATA frames. But this becomes problematic: If Block Ack is NOT being used, then there arises an ordering problem at the receiver between the independently generated DATA and NULL streams which might be sent using different queues - such separation would have to be prohibited. If Block. Ack is being used, then any delay in the arrival of the NULL frames could impact the release of received DATA frames at the receiver side. The transmitter does not generally retry the two types in the same way, and again, different queues for the different frame types might cause generalized arrival synchronization problems. Implementation would be complicated: The TGn intended use of the QOS NULL embedded MA is to provide immediate channel feedback information as a response frame. Such a frame would likely be generated in a matter of microseconds. If DATA frames were already in a queue with assigned sequence numbers (in order to allow early encryption) then the NULL frame would get a later sequence number - for the Block. Ack case, this is probably ok - since getting a later sequence number early is not a problem. But the implementation would still have to set aside one or two sequence numbers from each Block. Ack window to not be used by DATA frames in case a NULL frame transmission was needed. Would the transmitter just leave gaps every 10 or 12 numbers? And what if no NULLs were needed? What would the receiver do in order to release frames when gaps were present? Would everything be stalled at the receiver until the transmitter moved the window forcefully? For the non-Block. Ack case, an immediately-generated NULL frame pretty much forces an implementation that assigns sequence numbers at the last possible moment and also forces encryption to occur at this same last moment. That's quite a restriction to impose on implementations. Submission 17 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Possible solutions • A modified NONCE might avoid these problems. – RX side would use QOS-NULL subtype to note that different NONCE generation is needed, but subtype is not secure… • A fixed sharing of the PN space would avoid these problems – E. g. DATA=EVEN PN, QOS NULL=ODD PN • This potentially clashes with work proposed in TGw • In either of the above two cases, two different classes of RSN STA would have to be noted - those that encrypt QOS NULL and those that do not. – This does not seem problematicalisticifigant. • A new MGMT subtype would avoid these problems – Which includes an ACK policy subfield • “NEVER encrypt QOS-Null” would avoid these problems – Continues current standard policy Submission 18 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Qo. S Null embedded MA recommendation • NEVER encrypt QOS-Null subtype – As per existing standard definition • Might want to clarify RX side behavior Submission 19 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 A-MSDU length limits Submission 20 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 A-MSDU length • A-MSDU allows length up to 7395 bytes – CCMP can protect payloads of up to 65535 octets • But current standard states that maximum length of body of encrypted frame is 2396 bytes – Need to extend maximum length of possible encrypted entity – Just a simple tweak to text, no real impact Submission 21 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 A-MSDU length recommendation • Modify a few lines of text to account for the extended lengths created by the existence of A-MSDU – 8. 3. 3. 3. 5 CCM originator processing c) • Length limit needs to increase for A-MSDU Submission 22 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 802. 11 Security Experts respond • As requested by the TGn LB 84 MAC comment resolution adhoc – Solicited input from various 802. 11 security experts • • Submission Dorothy Stanley Jesse Walker Clint Chaplin Nancy Cam-Winget 23 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Dorothy Stanley responds • The restriction against the use of TKIP is consistent with the current [original] description of its intended applicability to firmware upgrades of fielded devices, none of which are TGn capable. • TKIP and WEP use should be prohibited with all TGn HT links, with or without any type of aggregation. Submission 24 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 More from Dorothy Stanley – Embedded MA frame • “For what purpose are these frames allowed? Is this convoluted transport mechanism truly needed? If we could agree that the embedding wasn't really needed, then the complete HTC field could be masked. ” – CCMP Length Limit change for A-MSDU • Satisfied with the proposed change – WEP is on its way out the door - it is now optional for WFA certification testing. • “I [Dorothy] support prohibiting use of WEP for HT-HT links. ” – TKIP • “Yes, you can add my name [Dorothy] to a proposal indicating that HT -HT links should be barred from using TKIP” Submission 25 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Jesse Walker responds – “TKIP is nearing the end of its useful (and intended) life, and WEP never had one. Also, it is very difficult to adapt TKIP to protect anything beyond the data payload. Making WEP and TKIP out-of -scope for HT is the right decision. ” – Except for Open System authentication, all pre-RSNA security mechanisms have been deprecated, as they fail to meet their security goals. New implementations should support pre-RSNA methods only to aid migration to RSNA methods. • I. e. Jesse expresses agreement with 8. 2 of current standard and the applicability of this statement to TGn standards development efforts – Embedded MA: • There is no security reason for not encrypting this data Submission 26 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Nancy Cam-winget responds – Embedded MA frame • Is not convinced that this is a good idea due to the problems that it creates – is there another way? – WEP and TKIP • Agrees that these should be deprecated Submission 27 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 CID 7174 – security statements are out of scope 7174 Petranovich, James 82 8. 8 Referencing security here is inconsistent with the structure of 802. 11 n, which is otherwise agnostic. The special requirement is driven by the current state of technology and not fundamental. Remove this section. • Text of reference from page 82 of TGn D 1. 0: • 8. 8 Security for HT STA • An HT STA shall not use WEP or TKIP based encryption when sending data within an A-MPDU to an HT peer. Submission 28 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Deprecation of pre-RSNA security methods • 8. 2 Pre-RSNA security methods • Except for Open System authentication, all pre-RSNA security mechanisms have been deprecated, as they fail to meet their security goals. New implementations should support pre-RSNA methods only to aid migration to RSNA methods. * • *P 802. 11 -REVma-D 7. 0 Submission 29 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Explicit restriction of use of WEP • 7. 3. 2. 25. 1 Cipher suites • WEP-40 and WEP-104 shall not be used as cipher suite selector values for PTK in the RSN information element (see Table 33) Submission 30 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Limited intent of TKIP • 8. 3 RSNA data confidentiality protocols • 8. 3. 1 Overview • NOTE—Use of any of the data confidentiality algorithms depends on local policies. The data confidentiality and integrity mechanisms of TKIP are not as robust as those of CCMP. TKIP is designed to operate within the hardware limitations of a broad class of pre-RSNA devices. TKIP is suitable for firmware-only, hardware-compatible upgrade of fielded equipment. RSNA devices should only use TKIP when communicating with devices that are unable or not configured to communicate using CCMP. Submission 31 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 TGn PAR • 5. 2 Scope: The scope of this project is to define an amendment that shall define standardized modifications to both the 802. 11 physical layers (PHY) and the 802. 11 Medium Access Control Layer (MAC) so that modes of operation can be enabled that are capable of much higher throughputs, with a maximum throughput of at least 100 Mbps, as measured at the MAC data service access point (SAP). • Allows modification of MAC layer. – Security is part of MAC layer Submission 32 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 TGi PAR • Project scope: Enhance the 802. 11 Medium Access Control (MAC) to enhance security and authentication mechanisms. • Previous TG dedicated to security enhancements included a PAR which allowed modification to security requirements at the MAC layer. I. e. MAC layer includes security mechanisms. Submission 33 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Possible venues for security modifications necessitated by TGn changes • TGn • • • TGw TGm TG? (i. e. a new TG) • A new security standing committee? – Solve it now Submission 34 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 Dorothy Stanley responds • CID 7174 should be rejected, with a reason along the lines of: – "Changes to security algorithms and security algorith[m] usage are in scope for TGn. The TGn PAR covers MAC and PHY changes, and link layer security is in scope for the MAC. ” Submission 35 Matthew Fischer (Broadcom)

September 2006 doc. : IEEE 802. 11 -06/1348 r 0 References • 11 -06 -0541 -00 -000 n-tgn-d 1 -0 -lb 84. xls • P 802. 11 -REVma-D 7. 0 -redline. pdf Submission 36 Matthew Fischer (Broadcom)