Download presentation
Presentation is loading. Please wait.
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)
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.