Doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 1 Technical...

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


June 2005


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


June 2005


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


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


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


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


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


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


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


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


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


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


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.

Doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 1 Technical...

Documents

Transcript of Doc.: IEEE 802.11-05/0539r2 Submission June 2005 Bill Marshall, TGr EditorSlide 1 Technical...