1. TGr state machines: normative or informative?
January 2006
doc.: IEEE /0xxxr0
Jan 2006
TGr state machines: normative or informative?
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. January 2006
doc.: IEEE /0xxxr0
Jan 2006
Abstract
LB87 comments #1529, #1530, and many others point out severe problems with the normative state machines in TGr 3.0, and propose a remedy that the figures be made informative. This submission supports this view.
Bill Marshall, TGr Editor
Bill Marshall, TGr Editor

3. State machine problems
Jan 2006
State machine problems
Numerous bugs. Bugs are a significant problem in normative text, but can be ignored in informative text
LB87 identified ~200 bugs
How many more? How long to find them? Is TGm/11mb the process for fixing them?
Bill Marshall, TGr Editor

4. Error checking in Key Holders
Jan 2006
Error checking in Key Holders
State machines mandate certain error checking be done at certain places in the key derivation process.
State machines also mandate that no error checking be done at other places in the key derivation process.
This should be left to the implementers to decide.
Bill Marshall, TGr Editor

5. Jan 2006
Error recovery
State machines mandate certain error recovery strategies.
Some of these strategies are in direct conflict with normative behavior specified in base standard.
Normative behavior specified in text should be followed whenever there is a conflict.
Unfortunately this makes the state machines extremely complex, and unreadable
Bill Marshall, TGr Editor

6. Jan 2006
Error recovery
Several error recovery strategies in the state machines introduce denial-of-service attacks.
MIC failure disconnecting other STAs
Message with bad parameters affecting other STAs
Error recovery should be left up to the developer, as long as its consistent with normative behavior specified in the standard.
Bill Marshall, TGr Editor

7. Jan 2006
Mandatory features?
Text, and PICS show several features of TGr to be optional, not mandatory.
Resource request procedures are an example.
State machines show these features.
Normative state machines thus mean the features have become mandatory
Existing text and PICS should apply
Bill Marshall, TGr Editor

8. Access point architecture
Jan 2006
Access point architecture
Architecture diagram (Figure 10 in 5.7) shows RSNA Key Management as a part of the SME.
R1KH is shown in our Figure 158L as part of RSNA Key Management
State diagrams several SME functions as part of R1KH:
Resource Request
Reassociation
These functions certainly do not belong in the Key Management portion of the SME
Bill Marshall, TGr Editor

9. Lost design flexibility
Jan 2006
Lost design flexibility
At the mobile STA, three designs of the 802.1x controlled port portion are possible
Don’t bother, the AP does it.
Single controlled port for the entire STA
Multiple logical controlled ports, one for each AP
All are compatible with the behavior required in the existing standard
State machines in 8A.6 mandate option #3, through the specification of 802.1x interface signals at the beginning of R1KH
802.1x options should be left to vendor
Bill Marshall, TGr Editor

10. Lost design flexibility
Jan 2006
Lost design flexibility
MLME-SETKEYS.request in the R1KH in the STA needs to be done prior to data transfer to the target AP.
Not necessary that this be done prior to a resource request or reassociation request.
Figure 158R mandates that MLME-SETKEYS and MLME-SETPROTECTION be performed far earlier than needed
Bill Marshall, TGr Editor

11. The “magnificant handwave”
Jan 2006
The “magnificant handwave”
Doesn’t exist any more.
State machines specify key distribution, as part of the “Distribute” function in FT-PMK-R1-SA-PUSH in the R0KH authenticator state machine.
Good or bad?
Bill Marshall, TGr Editor

12. Jan 2006
Key lifetime issues
State machines mandate certain places in the procedures to check key lifetime expiration
State machines also prohibit checking key lifetime at other places in the procedures
Key expiration in middle of transition sequence will not be detected
Such error checking and handling should be allowed by the vendor implementations.
Bill Marshall, TGr Editor

13. Abandoned transition attempts
Jan 2006
Abandoned transition attempts
Current specification allows a STA to perform authentication exchange (messages #1 and #2) and resource requests (messages #3 and #4 of 6) with many APs, and then only Reassociation with one of them.
This capability is not allowed by the state machines (see FT-PTK-CALC in R1KH of supplicant)
Bill Marshall, TGr Editor

14. Stated goal of 8A.6 Interoperability Security analysis
Jan 2006
Stated goal of 8A.6
Interoperability
Security analysis
Both can be achieved if the state machines were considered informative.
Security analysis already contains an assumption that the implementation actually implements the standard. One reasonable step further is that an implementation is secure if it implements the suggested implementation.
Bill Marshall, TGr Editor

15. Jan 2006
Normative text?
According to IEEE style guide: “indispensable for the application of this document.” and “information that is required to implement the standard, and is therefore officially part of the standard.”
This just doesn’t qualify
Bill Marshall, TGr Editor

16. Jan 2006
Motion
Motion to resolve comment #1529 as “Accepted”, #1530 (and all others with that proposed resolution) as “Accepted. 8A.6 moved to informative annex”, and instruct the editor to make the changes to the draft.
Bill Marshall, TGr Editor