1. Technical corrections to D0.01
June 2005
doc.: IEEE /0539r4
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
Bill Marshall, TGr Editor

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. Change log of this contribution
June 2005
doc.: IEEE /0539r4
June 2005
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
: 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 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.
Changes in R3
Change proposed resolution in slide #29 for IE ordering in figures.
Auth-FT in First Contact sequence, isn’t an Authentication with FT alg; change to Open System Authentication Request/Authentication Response
Add parameters to (Re)Association Response in First Contact sequence
Changes in R4
ANonce vs SNonce in msg#4 to be resolved by a separate contribution, not here
EAPOL-Key-FT notation to be resolved by a separate contribution, not here
Encapsulation for “over-the-DS” to be TBD, separate contribution for text.
QSTA in 11.3A.3 should be TSTA
Reversal of resolution of slide #45 – uses of “reassociation” will be changed to “(re)-association”
Changes in R5
Size of Time Interval 32 bits, not 16
Figure 121D in Section 8A.2 inconsistent with text
Bill Marshall, TGr Editor
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:
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
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
doc.: IEEE /0539r4
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
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”
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.
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 2-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 2-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:
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.
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
Need a contribution for the text.
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
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.
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 to be provided by separate contribution by Kapil/Jesse
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, that the figures are informative and the text/tables in 7.2 are normative.
Let editor fix the “order” values in frames to match the normative frame definitions
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 to be provided by separate contribution by Kapil/Jesse
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 to be provided by separate contribution by Kapil/Jesse
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 to be provided by separate contribution by Kapil/Jesse
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 to be provided by separate contribution by Kapil/Jesse
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
Proposal:
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)
Resolution:
Separate contribution
Bill Marshall, TGr Editor

36. 8A.2 Auth msg in first contact
June 2005
8A.2 Auth msg in first contact
Figure 121D shows first messages being Authentication Request and Response
Text says they are Authentication using the Open System Authentication Algorithm
But shows few lines later as TSTA->TTAP Auth-FT(0,0,0,0) and TTAP->TSTA Auth-Ft(0,1,SC,0)
Resolution
Change TSTA->TTAP and TTAP->TSTA to say “Authentication Request (Open System Authentication Algorithm)” and “Authentication Response (Open System Authentication Algorithm, SC)”
Bill Marshall, TGr Editor

37. 8A.2 (Re)Association Response
June 2005
8A.2 (Re)Association Response
Figure 121D shows TSIE, TRIE, RSNIE present in the (Re)Association Response
Text later shows no parameters to this message
Resolution:
Add TRIEAP, TSIEAP, and RSNIEAP to TTAP->TSTA Reassociation Response()
Bill Marshall, TGr Editor

38. 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

39. 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 TBD.”
Contribution by Mike Montemurro to address this further (and preempt the “TBD”)
Bill Marshall, TGr Editor

40. 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

41. 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

42. 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

43. 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

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

45. Throughout: use of “(Re)-association”
June 2005
doc.: IEEE /0539r4
June 2005
Throughout: use of “(Re)-association”
Most of document uses “(Re)-association”
Could be either “Association” or “Reassociation”
Several occurrences of “Reassociation” remain
Resolution:
Change occurrences of “Reassociation” to “(Re)-association”
Bill Marshall, TGr Editor
Bill Marshall, TGr Editor

46. June 2005
Time Interval IE
Section shows Interval Value of 2 octets (16 bits), containing an interval in milliseconds
Section (MLME-Reservation.Confirm) shows KeyLifetime as 32 bits
Key Lifetime of 1.09 second (65,535 milliseconds) is probably too short.
Resolution:
It should be 32 bits
Figure 80AC: change Interval Value to be 4 octets
Change length of TIE in to be 5 octets
Line under Table 30K: Interval Value to be unsigned 32-bit integer
Bill Marshall, TGr Editor

47. 8A.2 Figure 121D Message Contents
June 2005
8A.2 Figure 121D Message Contents
Figure 121D shows msg#1 containing TRIE, and TSIE, but text does not
Figure 121D shows msg#2 with TSIE followed by TRIE, reversed from text
Figure 121D shows msg#3 with TIE (unspecified type), without TRIE nor TSIE
Resolution:
Make figure match text
Msg#1: drop TRIE, drop TSIE
Msg#2: reverse TRIE and TSIE
Msg#3: change TIE to “TRIEAP, TSIEAP”
Bill Marshall, TGr Editor

48. 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