1. September 2006
doc.: IEEE /1348r1
September 2006
Security issues with respect to TGn MAC changes Ref: LB84 CID 116 and 7174
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Matthew Fischer (Broadcom)
Matthew Fischer (Broadcom)

2. CID 116 – address security interaction
September 2006
CID 116 – address security interaction
116
Bagby, David
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...
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)

3. TGn impacts on security
September 2006
TGn impacts on security
HTC field impact on CCMP AAD
Encryption of QoS Null DATA with embedded Management Action body
A-MSDU length limits
Matthew Fischer (Broadcom)

4. HTC Field impact on CCMP AAD
September 2006
HTC Field impact on CCMP AAD
Matthew Fischer (Broadcom)

5. HT Control Field in MAC Header
September 2006
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-QoS 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?
Matthew Fischer (Broadcom)

6. September 2006
TGn MAC HEADER
Octets: 2 2 6
0 or 6
0 or 2
0 or 4
0-2324 4
Frame Control
Duration /ID
Address 1
Address 2
Address 3
Sequence Control
Address 4
QoS 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 QoS Control field in a DATA Type (where encryption matters)
HTC position is either bytes: 25 to 30 or 31 to 36
Matthew Fischer (Broadcom)

7. September 2006
TGn HTC control field #
B B15 B B
B20 B21
B22B23
B24
B25 B29
B30
B31
Link Adaptation Control
Calibration
Position
Sequence
Feedback request
CSI/
Steering
ZLF Announcement
Reserved
AC Constraint
RDG/More PPDU
# Bits 16 2 1 5
Most of these bits can change per transmission of a given MPDU
E.g. RDG/More PPDU, ZLF announcement
Matthew Fischer (Broadcom)

8. Link adaptation control field (lower 16 bits of HTC)
September 2006
Link adaptation control field (lower 16 bits of HTC) B0 B1 B2
B B5
B6 B8
B B15 MA
TRQ
MRQ
MRS/ASI
MFS
MFB/ASC
# Bits 1 3 7
Link Adaptation Control field
MA bit is static (Management Action embedding)
Remainder of bits are potentially dynamic
Matthew Fischer (Broadcom)

9. Is the HTC field presence dynamic?
September 2006
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
Matthew Fischer (Broadcom)

10. HTC field possibilities
September 2006
HTC field possibilities
A) MASK all but the MA bit of the HTC
Note that MA is only defined for use in the QoS 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 b7 (QOS)
Matthew Fischer (Broadcom)

11. HTC field recommendation
September 2006
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 B7 of the subtype field
“QOS bit” of the DATA subtypes
Masked when B7=1
Does not collide with legacy equipment
Legacy STA transmitting frames with B7=1 NEVER set ORDER=1
Matthew Fischer (Broadcom)

12. Encryption of QoS Null DATA with embedded Management Action body
September 2006
Encryption of QoS Null DATA with embedded Management Action body
Matthew Fischer (Broadcom)

13. QOS-Null with Embedded MA frame
September 2006
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 NO-ACK 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.
Matthew Fischer (Broadcom)

14. The QoS Null Embedded MA problem
September 2006
The QoS Null Embedded MA problem
MA bit of HTC field allows for MGMT Action frame body to be included as body of DATA QoS Null frame
QoS 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 (AD2, Priority)
Unless it is specifically called out as not belonging because it is a QoS 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…
Matthew Fischer (Broadcom)

15. QoS Null (in general) encryption (or not)
September 2006
QoS Null (in general) encryption (or not)
RSNA security association termination c)
NOTE 2—Because the IEEE 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.
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 and that show that the frame body must be one octet or longer to apply the encapsulation).
Matthew Fischer (Broadcom)

16. QOS NULL problems detail
September 2006
QOS NULL problems detail
Decryption at the RX side has only A2 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?
Matthew Fischer (Broadcom)

17. More QOS NULL problem detail
September 2006
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 A2 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 BlockAck 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 BlockAck 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 BlockAck 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-BlockAck 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.
Matthew Fischer (Broadcom)

18. Possible solutions A modified NONCE might avoid these problems.
September 2006
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
Matthew Fischer (Broadcom)

19. QoS Null embedded MA recommendation
September 2006
QoS Null embedded MA recommendation
NEVER encrypt QOS-Null subtype
As per existing standard definition
Might want to clarify RX side behavior
Matthew Fischer (Broadcom)

20. September 2006
A-MSDU length limits
Matthew Fischer (Broadcom)

21. A-MSDU length A-MSDU allows length up to 7395 bytes
September 2006
A-MSDU length
A-MSDU allows length up to 7395 bytes
CCMP can protect payloads of up to 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
Matthew Fischer (Broadcom)

22. A-MSDU length recommendation
September 2006
A-MSDU length recommendation
Modify a few lines of text to account for the extended lengths created by the existence of A-MSDU
CCM originator processing c)
Length limit needs to increase for A-MSDU
Matthew Fischer (Broadcom)

23. 802.11 Security Experts respond
September 2006
Security Experts respond
As requested by the TGn LB84 MAC comment resolution adhoc
Solicited input from various security experts
Dorothy Stanley
Jesse Walker
Clint Chaplin
Nancy Cam-Winget
Matthew Fischer (Broadcom)

24. Dorothy Stanley responds
September 2006
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.
Matthew Fischer (Broadcom)

25. More from Dorothy Stanley
September 2006
doc.: IEEE /1348r1
September 2006
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
“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”
Matthew Fischer (Broadcom)
Matthew Fischer (Broadcom)

26. September 2006
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
Matthew Fischer (Broadcom)

27. Nancy Cam-winget responds
September 2006
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
Matthew Fischer (Broadcom)

28. CID 7174 – security statements are out of scope
September 2006
CID 7174 – security statements are out of scope
7174
Petranovich, James 82
8.8
Referencing security here is inconsistent with the structure of 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 D1.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.
Matthew Fischer (Broadcom)

29. Deprecation of pre-RSNA security methods
September 2006
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 REVma-D7.0
Matthew Fischer (Broadcom)

30. Explicit restriction of use of WEP
September 2006
Explicit restriction of use of WEP
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)
Matthew Fischer (Broadcom)

31. Limited intent of TKIP 8.3 RSNA data confidentiality protocols
September 2006
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.
Matthew Fischer (Broadcom)

32. September 2006
TGn PAR
5.2 Scope: The scope of this project is to define an amendment that shall define standardized modifications to both the physical layers (PHY) and the 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 100Mbps, as measured at the MAC data service access point (SAP).
Allows modification of MAC layer.
Security is part of MAC layer
Matthew Fischer (Broadcom)

33. September 2006
TGi PAR
Project scope: Enhance the 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.
Matthew Fischer (Broadcom)

34. Possible venues for security modifications necessitated by TGn changes
September 2006
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
Matthew Fischer (Broadcom)

35. Dorothy Stanley responds
September 2006
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.”
Matthew Fischer (Broadcom)

36. References 11-06-0541-00-000n-tgn-d1-0-lb84.xls
September 2006
References
n-tgn-d1-0-lb84.xls
P REVma-D7.0-redline.pdf
Matthew Fischer (Broadcom)