doc.: ieee 802.11-05/0539r2 submission june 2005 bill marshall, tgr editorslide 1 technical...
TRANSCRIPT
June 2005
Bill Marshall, TGr Editor
Slide 1
doc.: IEEE 802.11-05/0539r2
Submission
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 <http:// 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 <[email protected]> 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 <[email protected]>.
Date: 2005-06-02
Name Company Address Phone email Bill Marshall TGr Editor 180 Park Ave,
Florham Park, NJ 07932
973-360-8718 [email protected]
Authors:
June 2005
Bill Marshall, TGr Editor
Slide 2
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 3
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 4
doc.: IEEE 802.11-05/0539r2
Submission
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”
June 2005
Bill Marshall, TGr Editor
Slide 5
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 6
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 7
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 8
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 9
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 10
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 11
doc.: IEEE 802.11-05/0539r2
Submission
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”
June 2005
Bill Marshall, TGr Editor
Slide 12
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 13
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 14
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 15
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 16
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 17
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 18
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 19
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 20
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 21
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 22
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 23
doc.: IEEE 802.11-05/0539r2
Submission
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”
June 2005
Bill Marshall, TGr Editor
Slide 24
doc.: IEEE 802.11-05/0539r2
Submission
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”
June 2005
Bill Marshall, TGr Editor
Slide 25
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 26
doc.: IEEE 802.11-05/0539r2
Submission
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.
June 2005
Bill Marshall, TGr Editor
Slide 27
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 28
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 29
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 30
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 31
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 32
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 33
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 34
doc.: IEEE 802.11-05/0539r2
Submission
8A.1.3 use of EAPKeyIE
• Figure 121C Action Response frame contains EAPKeyIE
• Everywhere else it is EAPKIE
• Resolution
• Change to EAPKIE in figure
June 2005
Bill Marshall, TGr Editor
Slide 35
doc.: IEEE 802.11-05/0539r2
Submission
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)
June 2005
Bill Marshall, TGr Editor
Slide 36
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 37
doc.: IEEE 802.11-05/0539r2
Submission
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.”
June 2005
Bill Marshall, TGr Editor
Slide 38
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 39
doc.: IEEE 802.11-05/0539r2
Submission
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”
June 2005
Bill Marshall, TGr Editor
Slide 40
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 41
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 42
doc.: IEEE 802.11-05/0539r2
Submission
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
June 2005
Bill Marshall, TGr Editor
Slide 43
doc.: IEEE 802.11-05/0539r2
Submission
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”
June 2005
Bill Marshall, TGr Editor
Slide 44
doc.: IEEE 802.11-05/0539r2
Submission
Motion
• To instruct the editor to include the resolutions given in this document in the next draft of the 11r amendment.