1. Comment Resolution Motions
March 2003
Comment Resolution Motions
Jesse Walker, Intel
Mike Moreton, Synad Technologies
Nancy Cam-Winget, Cisco
Thomas Maufer, NVIDEA
Mike Moreton, Synad Technologies Ltd.

2. <Comment Number> – <Section>
March 2003
doc.: IEEE /xxxr0
March 2003
<Comment Number> – <Section>
<Comment>
<Recommend Change>
<Comment Resolution>
Motion: Accept the comment resolution for comment XXXX in document 03/169r2 and authorise the Editor to make the indicated changes.
The above is the format used through the remainder of this submission.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

3. March 2003
doc.: IEEE /xxxr0
March 2003
1900 – 8.4.3
In the phrase, "• A STA shall ignore OUI values it does not recognize.", it would seem that this leads to a situation where the STA must intepret the entire IE as invalid.
Change requirement to: • A STA shall consider the entire RSN IE invalid if any subfield contains an OUI value it does not recognize.
Rejected: This would prevent the intended use, which is to allow vendor specified suites to be advertised. Suggest rephrasing as "A STA shall ignore suite selectors that it does not recognise. In the case of the Group Key Cipher Suite this means that the STA will be unable to associate using RSNA procedures. In the case of an Authenticated Key Management Suite or Pairwise Key Cipher Suite selector, the STA may still be able to associate due to the presence of other selectors in the list that it does understand." Note this text is now in
Motion: Accept the comment resolution for comment 1900 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

4. March 2003
doc.: IEEE /xxxr0
March 2003
673 –
"…instead it shall use a pre-configured WEP key…" This is probably draconian in two respects. First, we need to allow for proprietary key management schemes (e.g., LEAP), and second we need to permit the STA to operate without any security if that is allowed.
None
Accepted. Delete “; instead, it shall use a pre-configured WEP key to secure its communication “
Motion: Accept the comment resolution for comment 673 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

5. 1902 – 8.4.3.1 An AP operates a BSS, not an ESS.
March 2003
doc.: IEEE /xxxr0
March 2003
1902 –
An AP operates a BSS, not an ESS.
Change "An AP cannot support multiple group key cipher suites simultaneously within an ESS" to "An AP cannot support multiple group key cipher suites simultaneously within a BSS."
Accepted, sort of. Delete "within an ESS". Commenter is OK with this.
Defer this until after Nancy’s submission.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

6. March 2003
doc.: IEEE /xxxr0
March 2003
2019 –
Text specifies potentially non-interoperable behavior. According to the text in , it would be possible for the AP to not include the RSN IE in its Beacons and Probe Responses but still be able to associate with a STA that included the RSN IE in its Association Requests. I don't think this would work since the Association Response from the AP does not include an RSN IE so the STA has no way of knowing whether the AP accepted its proposed RSN IE or not. This could lead to the STA and AP getting out of sync with regard to what ciphers to use.
Change "may" to "shall": "An RSN-capable AP configured to operate in a TSN may include the RSN IE, and shall associate with both RSN and pre-RSN STAs." to "An RSN-capable AP configured to operate in a TSN shall include the RSN IE, and may associate with both RSN and pre-RSN STAs."
Accepted
Motion: Accept the comment resolution for comment 2019 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

7. 1018 – 8.4.3.1 Incomplete description
March 2003
doc.: IEEE /xxxr0
March 2003
1018 –
Incomplete description
"the forgoing applies in a TSN". Not clear what this is referring to.
Accepted. Replace “If the AP includes the RSN IE in its Beacons or Probe Response messages, the forgoing applies in a TSN - RSN STAs shall act as if it is operating in an RSN…“ with “In a TSN, RSN STAs shall act as if operating in an RSN…”.
Motion: Accept the comment resolution for comment 1018 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

8. March 2003
doc.: IEEE /xxxr0
March 2003
675 – 8.4.4
The text talks about using IEEE 802.1X for ciphersuite negotiation. This is misleading, as it is the 4-way handshake that is used.
Note – (RSN policy selection in an IBSS) only applies to IBSS
Accepted. Change "may use IEEE 802.1X to negotiate" to "may use the 4-way handshake to negotiate". Change "The IEEE 802.1X implementations" to "The IEEE 802.1X entities".
Motion: Accept the comment resolution for comment 675 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

9. March 2003
doc.: IEEE /xxxr0
March 2003
676 – 8.4.4
There is an informative note that is directly contradicted by normative text. The informative note explains why it is impossible to rely on beacons and probe responses to negotiate RSN IE characteristics, and then the normative text turns around and says the beacons and probe responses shall be used for this. Sheesh.
Resolve this. Probably the right way is to resolve it to reflect the informative note. Replace the Beacon/Probe response language with appropriate references to the 4-way handshake messages 2 and 3.
Accepted in spirit. The informative note is talking about pairwise cipher suite negotiation, while the normative text is talking about group cipher suite and AKM suite. Suggest changing to informative note to: "Informative note: Pairwise cipher key suite specifiers are not included in beacons as this information may vary from STA to STA within an IBSS. They are not included in Probe Response messages for consistency with beacons."
Motion: Accept the comment resolution for comment 676 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

10. March 2003
doc.: IEEE /xxxr0
March 2003
2032 – 8.4.4
Requiring RSN support for STAs operating in IBSS mode places AS requirements on STAs that support IBSS mode that are (in my mind) an undue burden. Given that most STAs will probably not support a full suite of AS authentication alogrithms, and will likely just use pre-shared keys, there is little real security benefit to forcing all the AP-oriented mechanisms onto STAs operating in IBSS mode. I strongly prefer public-key based techniques, such as were proposed by Russ Housley, et. al., at the September meeing.
Remove all descriptions of RSN in IBSS mode, possibly replacing them with a public key based system.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

11. March 2003
doc.: IEEE /xxxr0
March 2003
2032 – (Continued)
Accepted in spirit. RSN support doesn't place AS requirements on STAs in an IBSS - they can use pre-shared key. However, there are a number of places that imply you can only use PSK in an IBSS, but there appears to be no specific rule. Add "The Authenticated Key Management suite selector value 00:00:00:1 (Unspecified authentication over IEEE 802.1X with IEEE 802.1X key management as defined in 8.5) shall not be used in an IBSS." directly after Table 1. Add "In an Infrastructure BSS" to the beginning of the sentence that used to follow table 1. Add “This is the only value that may be used in an IBSS.” to the end of the paragraph describing the “Pre Shared Key over 802.1X” authentication selector.
Motion: Accept the comment resolution for comment 2032 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

12. March 2003
doc.: IEEE /xxxr0
March 2003
None –
“Authenticated Key Management Suite” should be “Authentication and Key Management Suite” as the suite selector has separate columns for each.
Accept. Make this change globally.
Motion: Direct the editor to replace all instances of “Authenticated Key Management Suite” with “Authentication and Key Management Suite” .
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

13. March 2003
doc.: IEEE /xxxr0
March 2003
70 – 8.4.5
Page 81, Line 20, List Item 1. “received IEEE 802.1X frames”. This must permit only unicast frames to this STA. An associated (but not authenticated) STA, sending a multicast EAPOL-Start is otherwise a significant denial of service attack against multi-AP BSSes and ESSes capable of bring a network down for seconds to minutes with a single packet.
Change “received IEEE 802.1X messages” To “received, unicast IEEE 802.1X frames to this STA”
Accepted
Motion: Accept the comment resolution for comment 70 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

14. March 2003
doc.: IEEE /xxxr0
March 2003
1584 – 8.4.5
Informative Note states "Filtering class 3 MPDUs is not required during pre-authentication". How does an AP know it is in the pre-auth state?
Clarify how an AP determines pre-auth state or remove informative note.
Accept. The note means that the filtering will happen by other mechanisms. Might as well remove this note to avoid confusion.
Motion: Accept the comment resolution for comment 1584 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

15. March 2003
doc.: IEEE /xxxr0
March 2003
687 – 8.4.6
"The AP shall respond to an IEEE 802.1X authentication failure by sending the STA a Disassociation message." Since the Disassociation message can be forged, the STA implementor need guidance on what to do.
Probably the right advice is for the STA to ignore Disassociation messages?
Accepted in spirit. As the STA hasn’t been authenticated then there is no way to authenticate the frame, and some frame must be sent to the STA for error recovery. Change “Disassociation” to “Deauthenticate” as this is used unprotected elsewhere.
Motion: Accept the comment resolution for comment 687 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

16. 1378 – 8.4.6 EAPOL-Start is mispelled, and any EAP-Request will do.
March 2003
doc.: IEEE /xxxr0
March 2003
1378 – 8.4.6
EAPOL-Start is mispelled, and any EAP-Request will do.
Change "EAP-Start" to "EAPOL-Start" in line 18; change "EAP-Request/Identity" to "EAP-Request" in lines 22 and 28.
Accept
Motion: Accept the comment resolution for comment 1378 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.

17. March 2003
doc.: IEEE /xxxr0
March 2003
1532 – 8.4.6
Page 82, lines 30: dot11AuthenticationType set to 802.1X. What does this mean? The MIB variable? There is no enumeration for that.
This is probably left entirely up to the higher layer and there is no need to indicate in that 802.1X will be used. So remove reference to dot11AuthenticationType.
Accept. Change first two paragraphs of this section to "When IEEE 802.1X authentication is in use, the STA shall use Open System Authentication prior to association or reassociation.
Informative Note: Open System Authentication is used, as the authentication of the STA is performed by IEEE 802.1X, not by the MAC."
Motion: Accept the comment resolution for comment 1532 in document 03/169r2 and authorise the Editor to make the indicated changes.
Mike Moreton, Synad Technologies Ltd.
Mike Moreton, Synad Technologies Ltd.