1. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 1 Technical corrections to D0.01 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-06-02 Authors:

2. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 2 Abstract Numerous inconsistencies were discovered while generating the initial draft of the 11r amendment. Most appear to be “nearly editorial” in nature, but might possibly be considered technical changes. This presentation lists those discovered, and proposes resolutions to appear in the next draft of the amendment.

3. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 3 Change log of this contribution Changes in R1 –Authenticator address (AA) really is defined in 11ma (I missed it). No new definition is needed. Drop the change to 3.124. –7.2.3.6: Updated resolution to keep RSN IE as a separate IE in the frame, not embedded in the EAPKIE. (this was Resolution #2 in rev0). Changes in R2 –TTAP vs AP, and new term for FBT-enabled AP, to be a separate contribution; no change in 7.3.2.39 from this document –Status code in FT Response and ACK Action frames to be 2 bytes –PTKName to be defined, (Resolution #2 in rev1) –Extended Capability bit resolution to be preempted by contribution 0551. –One more probable typo (“RSTA” should likely be “QSTA”) in 11.3A.3.

4. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 4 3.108 SPA SPA is defined as the address of Supplicant, typically the STA’s MAC address SPA is used throughout as an acronym of an entity that participates in key derivation Resolution: SPA, when used as a key derivation participant, changed to “Supplicant”

5. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 5 3.131 R2KH-ID Pairwise Master Key R2 Key Holder Identifier is defined as the holder of PMK-R1 Resolution: Pairwise Master Key R2 Key Holder Identifier (R2KH-ID): the 16 octet identifier that is advertised as the holder of the PMK-R2

6. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 6 5.7.2 Association Message information contents Figure 121D, for First Contact, shows three additional fields in the Association and Association response (and also in the Reassociation and Reassociation response) messages, TSIE, TRIE, and RSNIE. They are not listed in the Association request nor Association response message. These fields are already shown in Reassociation request and Reassociation response in JIT-TAP proposal, section 5.7.3, 7.2.3.6, and 7.2.3.7. Resolution: Add Information items to the Association request and Association response: –Fast Transition Security information –Fast Transition Resource information –Robust Security Network information No change yet to 7.2.3.4 and 7.2.3.5, as that requires more details of the message contents

7. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 7 7.2.3.6 RSN in Reassociation Request frame RSN IE not included in Reassociation request frame, due to its being included in the EAPOL-Key message in the EAPKIE 11i devices that don’t do 11r will put a RSN IE in the Reassociation request frame, so spec needs to allow it Other frames, specifically FT Action and Auth-FT, include both RSN IE and EAPKIE Resolution: Keep the RSN IE in the Reassociation request frame Don’t put the RSN IE in the EAPKIE Arrange the IEs so that RSN at order 9 is still between the Count and EAPKIE Note: whatever we do here, it should be the same as the FT Action frames and the Auth-FT frames, which seem to follow this resolution

8. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 8 7.2.3.7 Reassociation timeout interval in Reassociation Response Time Interval IE, containing the Reassociation timeout value, is included in the Reassociation Response Doesn’t make much sense, since the reassociation has just been done. Does it only appear in error cases where the STA needs to quickly re-do the reassociation? Resolution: Drop the Time Interval IE from this message

9. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 9 7.2.3.7 Reassociation Response JIT-TAP proposal listed several items in the Reassociation Response frame that are not presently in that message in 802.11 –Listen Interval –Current AP Address –SSID –Power Capability –Supported Channels These all appear in the Reassociation Request, not response. Resolution: Drop them from the list of elements of this frame.

10. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 10 7.2.3.10 Authentication frame Fast Transition Security Information Element shown as ALWAYS appearing in the message, not just in Fast Transition frames Probably a missing ref to footnote 3 in section 4.1 of JIT-TAP proposal Resolution: TSIE is only present in the Fast Transition Authentication frames as defined in Table 14

11. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 11 7.3.2.25.2 AKM suites Suite type value 4 appears both as Authentication type “PSK” and as “Reserved” in JIT-TAP section 4.4.8 Resolution: Value 4 is “PSK” Values 5-255 are “Reserved”

12. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 12 7.3.2.28 Length of Count IE Length of Count IE specified in JIT-TAP section 4.4.1 as 0x03 11ma section 7.3.2 states that length indicates the length of the information field, not the total length of the element Resolution: Length of Count IE is 0x01

13. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 13 7.3.2.39 TRIE advertised by TTAP TRIE can only be advertised by a TTAP TSIE and KeyHolderIE can be advertised by an AP Resolution: TRIE can be advertised by an AP “TTAP” is used many places where it (the AP) likely doesn’t know if it might be a transition target or not. Many should probably be just “AP” Resolution: General consensus that a name is needed for an AP that has the capability to do Fast BSS Transitions, and that TTAP may not be the right term to use. Separate contribution needed to address this.

14. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 14 7.3.2.39 length of TRIE JIT-TAP section 4.4.3 showed “Fast Transition Resource Mechanism” as 3 octets, and the detailed figure of its content showed its length as 17 (bytes 0-16 defined) Resolution: Length field in TRIE must be set to 17

15. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 15 7.3.2.40 Length of SMD-ID JIT-TAP section 4.4.4 (TSIE) shows SMD- ID as bytes 1-15, with byte 0 unassigned. Resolution: SMD-ID is bytes 0-15, for a length of 16 Length field of TSIE is 64

16. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 16 7.4.3 FT Action values FT Action values are defined as 0-1-2-3 for the four messages FT Action values used in 7.4.3.1-4 are 0-1-3-4 !! Authentication messages are defined as 1-2-3-4 for the four-way handshake Confusion likely Resolution: Change FT Action values to 1-2-3-4 to match the values used in Authentication messages

17. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 17 7.4.3.1-4 RSN within EAPKIE? RSN is shown separate from EAPKIE in the FT Action frames RSN is contained within EAPOL-Key according to JIT-TAP section 4.2.1 If RSN is variable length, how can EAPKIE (containing RSN) be fixed length? Resolution: (tied up with issue in 7.2.3.6) Keep RSN separate from EAPKIE, but within the range of IEs covered by the MIC.

18. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 18 7.4.3.2 FT Response status code FT Response message doesn’t include a status code Status code is referenced in section 8A.4.2 Resolution: Add a 2-octet status code between TTAP and Count IE

19. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 19 7.4.3.2 FT Response TIE Time Interval IE in FT Response “used to convey either the reassociation deadline time.” Resolution: Time Interval IE shall be set to the reassociation deadline time.

20. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 20 7.4.3.4 FT ACK status code FT ACK message doesn’t include a status code Status code is referenced in section 8A.4.2 Resolution: Add a 2-octet status code between TTAP and Count IE

21. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 21 8.5A.2 PMK-R2 naming PMK-R2 is named by the SPA, R0KH, R1KH, and R2KH AA is included in the formula in 8.5A.6 Resolution: Add AA to the list in 8.5A.2

22. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 22 8.5A.2 PTKName PTK is named by SNonce, ANonce, SPA, and TTAP (==BSSID? ==AA?) Several refs later to PTKName, 8A.3, 8A.4.1, 8A.4.2; its computed, but is it ever used? No definition of PTKName in 8.5A.8 Resolution: 8.5A.8 to include a definition of PTKName Definition to be provided by separate contribution Add informative text explaining why names are useful – particularly in debugging or trace outputs that should not display keys, but want to know whether the correct key is being used. Editor to add this text.

23. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 23 8.5A.2 PTKey derivation Figure 120B in 8.5A.2 has string for PTK “PTKey derivation” 8.5A.8 has string for PTK “PTK Key derivation” Resolution: String should be “PTK Key derivation”

24. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 24 8.5A.2 PTK formula Formula for PTK in Figure 120B has “SPA || AA” Formula for PTK in 8.5A.8 has “AA || SPA” Resolution: Fix figure, (so it is consistent with PMK-R2) using “AA || SPA”

25. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 25 8.5A.9 Auth frame sequences Currently state that Message type is Management, Message subtype is Authentication Messages are mapped into Authentication/Reassociation frames for base mechanism Messages are mapped into 4 Authentication frames for over-the-air reservation Messages are mapped into 4 Action frames for over-the-ds reservation This could be the primary definition of the authentication message sequence for FBT Resolution: Define these frame sequences as based only on a sequence of IEs, (first) Count, RSN, TRIE, TSIE, (optionally) TIE, (optionally) RIC, (optionally) others, (lastly) EAPKIE; and other information that needs to be given in surrounding parts of messages Need a contribution for the text.

26. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 26 8A.1.1 Extended Capability bit Original text in JIT-TAP 3.1.1 referenced the Extended Capability bit No other definition of that IE is in proposal Resolution: “Fast Transition capability will be advertised in the Beacon and Probe Response frames” Presence of TRIE and TSIE advertises FT Contribution 0551 addresses this and will pre-empt the above text; Editor to keep section 8A.1.1 consistent with the definition of the frame contents.

27. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 27 8A.1.2 Reassoc Resp SNonce Figure 121A has ANonce in Reassociation Response Section 7.2.3.7 says it should be SNonce Resolution Fix figure, it should be SNonce

28. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 28 8A.1.2 use of CIE Figures 121A/B/C includes CIE STA and CIE AP. Presumed to mean “Count IE”, but unclear and CIE is never defined. Resolution: No subscript needed for that IE Change to “Count” in figure

29. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 29 8A.1.2 ordering of IEs in figure Ordering of the IEs used in Fast Transition is inconsistent between figures and text Resolution: Decide this is an editorial change Let editor fix the “order” values in frames to match frame definition

30. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 30 8A.1.3 Authentication ACK ANonce Figure 121B has Authentication ACK containing ANonce Section 8.5A.8.4 claims it should be SNonce Resolution Fix figure to use SNonce

31. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 31 8A.1.3 Reassoc Response ANonce Figure 121B has Reassociation Response containing ANonce Section 7.2.3.7 says this frame should contain SNonce Resolution Fix figure; it should be SNonce

32. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 32 8A.1.3 Action ACK with ANonce Figure 121C has Action ACK frame with ANonce Section 7.4.3.4 says it should be SNonce Resolution Fix figure; it should be SNonce

33. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 33 8A.1.3 Reassoc Response ANonce Figure 121C has Reassociation Response containing ANonce Section 7.2.3.7 says this frame should contain SNonce Resolution Fix figure; it should be SNonce

34. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 34 8A.1.3 use of EAPKeyIE Figure 121C Action Response frame contains EAPKeyIE Everywhere else it is EAPKIE Resolution Change to EAPKIE in figure

35. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 35 8A.1.4 EAPOL-Key-FT needed? Section 8.5.2.2 (11i) defined EAPOL-Key Current definition allows arbitrary IEs to be included as Key-data No reason apparent for a new EAPOL-Key-FT to be defined Resolution: Drop EAPOL-Key-FT; change to EAPOL-Key Define EAPOL-Key like Auth-FT was defined – with “Data: additional information elements carried in the Key-data portion of the message” Add KeyName to 8.5.2.2, referencing RSNIE PMKID (this is the only addition that names something already in the message instead of adding an additional IE to Key-data)

36. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 36 8A.3, 8A.4 Status code in msg#1 Auth-FT message #1 (TSTA->TTAP) shown with SC in 8A.3 Auth-FT message #1 with SC in 8A.4.1 There is no status to report in the first message Resolution Change “SC” to “0” in those two messages

37. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 37 8A.4 Encapsulation for over-the-DS messages between CAP and TTAP Original text said encapsulation was TBD Is it intended to be defined in TGr? ??? Resolution: Change to “encapsulation method beyond the scope of this specification.”

38. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 38 8A.4.1 lack of SC in Auth-FT msg Third and fourth message of authentication sequence not shown with status code value in 8A.4.1 Evidently just a skipped parameter Resolution: Third message, add “0, ” to params Fourth message, add “SC, “ to params

39. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 39 8A.4.2 Method for TTAP to retrieve PMK-R2 from infrastructure Original text said TBD Section 8A.4.1 in similar paragraph said “beyond scope of this specification” Resolution Change to “beyond scope of this specification”

40. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 40 8A.4.2 SC in FT Action frames Section 8A.4.2 mentions a Status code returned by the TTAP in a FT Action frame Definition of FT Action frames (7.4.3.2, 7.4.3.4) do not include a status code Resolution Add a Status Code to FT Action Response Add a Status Code to FT Action Ack And, BTW, there is no reason to add an acronym “SC” when the full word “Status” will do just fine

41. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 41 8A.3, 8A.4.1, 8A.4.2 value of MIC in Reassociation Request message Reassociation Request message “echoes the TTAP’s ANonce and authentication tag in the respective Key Nonce and MIC fields.” Echo of a previous authentication tag doesn’t sound like an algorithm to calculate a MIC Section 7.2.3.6 “TSTA … authenticating the frame by including a valid MIC in the EAPKIE.” Resolution Reassociation Request echoes the ANonce Reassociation Request calculates a MIC

42. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 42 11.3A.3 TS Lifecycle TS successfully created … in case the RSTA in question transitions to it. No definition in 11ma, nor 11e for RSTA Likely typo and should be QSTA Resolution QSTA

43. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 43 Throughout: use of “(Re)-association” 8A.2 “First Contact”, along with Figure 121D, uses “(Re)- association” –Could be either “Association” or “Reassociation” Other uses of (Re)-association (numerous) –Really only mean reassociation –Remember this is a document about BSS transitions, not about initial associations Resolution: Change occurrences of “(Re)-association” to “Reassociation” except in section 8A.2 “First Contact”

44. doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 44 Motion To instruct the editor to include the resolutions given in this document in the next draft of the 11r amendment.