1. Technical corrections to D0.01
January 2002
doc.: IEEE /xxxr0
June 2005
Technical corrections to D0.01
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
Bill Marshall, TGr Editor
John Doe, His Company

2. June 2005
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.
Bill Marshall, TGr Editor

3. 3.124 Authenticator Address
June 2005
3.124 Authenticator Address
No definition given for “AA”, used in key derivations
Should it make reference to BSSID? AP?
“Typically this is the AP’s MAC address (or BSSID)”
Resolution:
Authenticator Address (AA): The Authenticator’s media access control (MAC) address.
Bill Marshall, TGr Editor

4. June 2005
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”
Bill Marshall, TGr Editor

5. June 2005
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
Bill Marshall, TGr Editor

6. 5.7.2 Association Message information contents
June 2005
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, , and
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 and , as that requires more details of the message contents
Bill Marshall, TGr Editor

7. 7.2.3.6 RSN in Reassociation Request frame
June 2005
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 (#1):
Change RSN to optional in the Reassociation request frame, “The RSN information element is only present within Reassociation Request frames generated by STAs that have dot11RSNAEnabled set to TRUE, and which do not have an EAPKIE later in the frame.”
Require the EAPOL-Key message to contain a RSN IE in the Key-Info field
Resolution (#2):
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 resolution #2
Bill Marshall, TGr Editor

8. 7.2.3.7 Reassociation timeout interval in Reassociation Response
June 2005
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
Bill Marshall, TGr Editor

9. 7.2.3.7 Reassociation Response
June 2005
Reassociation Response
JIT-TAP proposal listed several items in the Reassociation Response frame that are not presently in that message in
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.
Bill Marshall, TGr Editor

10. June 2005
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
Bill Marshall, TGr Editor

11. June 2005
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 are “Reserved”
Bill Marshall, TGr Editor

12. June 2005
Length of Count IE
Length of Count IE specified in JIT-TAP section as 0x03
11ma section states that length indicates the length of the information field, not the total length of the element
Resolution:
Length of Count IE is 0x01
Bill Marshall, TGr Editor

13. 7.3.2.39 TRIE advertised by TTAP
June 2005
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”
This is considered an editorial change. Editor to fix as appropriate.
Bill Marshall, TGr Editor

14. June 2005
length of TRIE
JIT-TAP section 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
Bill Marshall, TGr Editor

15. June 2005
Length of SMD-ID
JIT-TAP section (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
Bill Marshall, TGr Editor

16. June 2005
7.4.3 FT Action values
FT Action values are defined as for the four messages
FT Action values used in are !!
Authentication messages are defined as for the four-way handshake
Confusion likely
Resolution:
Change FT Action values to to match the values used in Authentication messages
Bill Marshall, TGr Editor

17. June 2005
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 )
Keep RSN separate from EAPKIE, but within the range of IEs covered by the MIC.
Bill Marshall, TGr Editor

18. 7.4.3.2 FT Response status code
June 2005
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 1-octet status code between TTAP and Count IE
Bill Marshall, TGr Editor

19. June 2005
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.
Bill Marshall, TGr Editor

20. June 2005
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 1-octet status code between TTAP and Count IE
Bill Marshall, TGr Editor

21. 8.5A.2 PMK-R2 naming PMK-R2 is named by the SPA, R0KH, R1KH, and R2KH
June 2005
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
Bill Marshall, TGr Editor

22. June 2005
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 (#1):
Drop all refs to PTKName; it has no name and is never used
Resolution (#2):
Add a definition of PTKName in 8.5A.8
PTKName = HELP!!!
Bill Marshall, TGr Editor

23. June 2005
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”
Bill Marshall, TGr Editor

24. 8.5A.2 PTK formula Formula for PTK in Figure 120B has “SPA || AA”
June 2005
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”
Bill Marshall, TGr Editor

25. June 2005
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
Declare this to be an editorial change.
Bill Marshall, TGr Editor

26. 8A.1.1 Extended Capability bit
June 2005
8A.1.1 Extended Capability bit
Original text in JIT-TAP 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
Bill Marshall, TGr Editor

27. June 2005
8A.1.2 Reassoc Resp SNonce
Figure 121A has ANonce in Reassociation Response
Section says it should be SNonce
Resolution
Fix figure, it should be SNonce
Bill Marshall, TGr Editor

28. 8A.1.2 use of CIE Figures 121A/B/C includes CIESTA and CIEAP.
June 2005
8A.1.2 use of CIE
Figures 121A/B/C includes CIESTA and CIEAP.
Presumed to mean “Count IE”, but unclear and CIE is never defined.
Resolution:
No subscript needed for that IE
Change to “Count” in figure
Bill Marshall, TGr Editor

29. 8A.1.2 ordering of IEs in figure
June 2005
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 decide on a “standard” ordering
Let editor fix the “order” values in frames to match
Bill Marshall, TGr Editor

30. 8A.1.3 Authentication ACK ANonce
June 2005
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
Bill Marshall, TGr Editor

31. 8A.1.3 Reassoc Response ANonce
June 2005
8A.1.3 Reassoc Response ANonce
Figure 121B has Reassociation Response containing ANonce
Section says this frame should contain SNonce
Resolution
Fix figure; it should be SNonce
Bill Marshall, TGr Editor

32. 8A.1.3 Action ACK with ANonce
June 2005
8A.1.3 Action ACK with ANonce
Figure 121C has Action ACK frame with ANonce
Section says it should be SNonce
Resolution
Fix figure; it should be SNonce
Bill Marshall, TGr Editor

33. 8A.1.3 Reassoc Response ANonce
June 2005
8A.1.3 Reassoc Response ANonce
Figure 121C has Reassociation Response containing ANonce
Section says this frame should contain SNonce
Resolution
Fix figure; it should be SNonce
Bill Marshall, TGr Editor

34. June 2005
8A.1.3 use of EAPKeyIE
Figure 121C Action Response frame contains EAPKeyIE
Everywhere else it is EAPKIE
Resolution
Change to EAPKIE in figure
Bill Marshall, TGr Editor

35. 8A.1.4 EAPOL-Key-FT needed? Section 8.5.2.2 (11i) defined EAPOL-Key
June 2005
8A.1.4 EAPOL-Key-FT needed?
Section (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 , referencing RSNIE PMKID (this is the only addition that names something already in the message instead of adding an additional IE to Key-data)
Bill Marshall, TGr Editor

36. June 2005
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
Bill Marshall, TGr Editor

37. 8A.4 Encapsulation for over-the-DS messages between CAP and TTAP
June 2005
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.”
Bill Marshall, TGr Editor

38. 8A.4.1 lack of SC in Auth-FT msg
June 2005
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
Bill Marshall, TGr Editor

39. 8A.4.2 Method for TTAP to retrieve PMK-R2 from infrastructure
June 2005
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”
Bill Marshall, TGr Editor

40. June 2005
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 ( , ) 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
Bill Marshall, TGr Editor

41. 8A.3, 8A.4.1, 8A.4.2 value of MIC in Reassociation Request message
June 2005
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 “TSTA … authenticating the frame by including a valid MIC in the EAPKIE.”
Resolution
Reassociation Request echoes the ANonce
Reassociation Request calculates a MIC
Bill Marshall, TGr Editor

42. Throughout: use of “(Re)-association”
June 2005
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”
Bill Marshall, TGr Editor

43. June 2005
Motion
To instruct the editor to include the resolutions given in this document in the next draft of the 11r amendment.
Bill Marshall, TGr Editor