1. TGi Draft 1 Clause 8.2.3.3.1 – 8.5 Comments
May 2001
TGi Draft 1 Clause – 8.5 Comments
Jesse Walker, editor
Jesse Walker, Intel Corporation

2. Agenda Initial Classification Editorial and easily resolved comments
May 2001
Agenda
Initial Classification
Editorial and easily resolved comments
Motion
Comments requiring TG discussion
Review of “ALL” Comments
Jesse Walker, Intel Corporation

3. Classification: Clause 8.2.3.3.1 – 8.5
May 2001
Classification: Clause – 8.5
Records 555 (C1374), 560 (C1414) – IV/KeyID usage, format
Record 557 (C767) – AES changes rules for PDU expansion
Record 562 (C78), 595 (C81), 610 (C1179) – Multicast key usage, definitions, procedures
Record 563 (C612) – Key derivation doesn’t work for ad hoc (ad hoc doesn’t use association)
Jesse Walker, Intel Corporation

4. May 2001
Classification: – 8.5
Record 577 (C770), 591 (C1309) – use whole frame for key derivation?
Record 592 (C1177) – protect MPDU or MSDU?
Record 605 (C399), 606 (C1178) – what does a system do with data while its peer is rekeying?
Record 613 (C775) – need counters
Record 615 (C1182) – Size of replay window arbitrary
Jesse Walker, Intel Corporation

5. May 2001
Classification: – 8.5
Record 617 (C1180) – People don’t understand sequence # associated with key, and key per association
Record 620 (C400) – WEP2 without AES not legal system. What about legacy?
Records 623 (C1183), 624 (C1223), 625 (C1185), 626 (C402), 627 (C83), 629 (C1352), 630 (C1420) – Synchronize key state
Record 615 (C1182): Don’t understand comment.
Jesse Walker, Intel Corporation

6. Agenda Initial Classification Editorial and easily resolved comments
May 2001
Agenda
Initial Classification
Editorial and easily resolved comments
Motion
Comments requiring TG discussion
Review of “ALL” Comments
Jesse Walker, Intel Corporation

7. May 2001
Editorial Comments
C1504, C1375, C1174, C396, C1332, C397, C1415, C1416, C1224, C1333, C1508, C82, C1509, C398, C1003, C1510, C1376, C719, C1512, C1225, C1181, C1419, C401
Jesse Walker, Intel Corporation

8. Recommended Simple Fix (1)
May 2001
Recommended Simple Fix (1)
C1374: Accept Change. Issue: Need to define mapping of derived key into key id, so peers agree on key id.
C76: Reclassified as editorial
C1456: Reclassified as editorial
C1414: Will 0 the 6-bit pad in key id byte
C1307: Reclassified as editorial
C768, C1308: Reclassified as editorial
Jesse Walker, Intel Corporation

9. Recommended Simple Fix (2)
May 2001
Recommended Simple Fix (2)
C395: Reclassified as editorial
C769: Accepted; new status code to be added in appropriate clause
C1175, C1465, C1176, C1221, C583, C1418: Language being objected to is made obsolete by final OCB mode definition; reclassified as editorial
C1222: Reclassified as editorial
C1220: Reclassified as editorial
Jesse Walker, Intel Corporation

10. Recommended Simple Fix (3)
May 2001
Recommended Simple Fix (3)
C1507: Proposed change accepted
C771, C393, C79: Change accepted and reclassified as editorial
C1453, C1454: reclassified as editorial
C773: Suggestion accepted, with following caveat: SeqNum not incremented on retransmission (this would require redoing crypto operation for retransmission)
C1466: Reclassified as editorial
C1178: Comment accepted
Jesse Walker, Intel Corporation

11. Recommended Simple Fix (4)
May 2001
Recommended Simple Fix (4)
C1377: reclassified as editorial
C1179: No requirement for receivers to maintain broadcast sequence number; reclassified as editorial
C775: Comment accepted; counters will be added
C1511: Comment accepted; reclassified as editorial
C1310: Comment accepted; reclassified as editorial
Jesse Walker, Intel Corporation

12. Agenda Initial Classification Editorial and easily resolved comments
May 2001
Agenda
Initial Classification
Editorial and easily resolved comments
Motion
Comments requiring TG discussion
Review of “ALL” Comments
Jesse Walker, Intel Corporation

13. May 2001
Motion
Move that TGi accept recommended resolution of comments 76, 79, 393, 395, 583, 768, 769, 771, 773, 775, 1175, 1176, 1178, 1179, 1220, 1221, 1222, 1374, 1307, 1308, 1310, 1377, 1414, 1418, 1453, 1454, 1456, 1465, 1466, 1507, 1511 as proposed in Slides 5-8 of Document
Jesse Walker, Intel Corporation

14. Agenda Initial Classification Editorial and easily resolved comments
May 2001
Agenda
Initial Classification
Editorial and easily resolved comments
Motion
Comments requiring TG discussion
Review of “ALL” Comments
Jesse Walker, Intel Corporation

15. May 2001
Comments 77, 80, 772
Uniform format for both multicast and unicast desired
Possible solution:
IV ::= SrcMAC || DestMAC || SeqNum. (“||” means concatenation).
Senders need to maintain a SeqNum for multicast as well
Issue: This solution requires multicast key to be replaced whenever any STA’s or AP’s SeqNum reaches 232 – 1. OCB requires is IVs are unique per key. This will always be an AP in a BSS. What about an IBSS?
Jesse Walker, Intel Corporation

16. Comment 709 AES has too much overhead
May 2001
Comment 709
AES has too much overhead
Eliminate IV – construct it as per previous slide
Reduce MIC size to 8 bytes – still only 2–64 chance of forgery.
These two changes reduce overhead from 36 to 13 bytes – this is better than WEP2!
Jesse Walker, Intel Corporation

17. May 2001
Comment 767
The AES data expansion changes all of the existing rules that depend on MPDU Max length (currently 2346)
What are the existing rules?
This is probably unavoidable – it’s just the price of security
If we reduce overhead to 13 bytes (4 byte IV, 1 byte key id, 8 byte MIC), then less overhead than WEP2, but this doesn’t address the stated concern
Jesse Walker, Intel Corporation

18. May 2001
Comment 78, 81
There is no description of how keys are serviced or used for multicast frames. (Bob O’Hara)
There are up to four keys used for encrypting multicast frames, identified by the KeyID bits. Also, include the sequence number to eliminate differences in frame handling based on the address.
Need specification of multicast delivery
Need specification of how key is used.
Need map of multicast key to the right keyid.
Q: Is multicast the same thing as broadcast?
Jesse Walker, Intel Corporation

19. May 2001
Comment 612
The key derivation procedure does not account for ad-hoc BSS
TGi needs to decide whether it will change how ad hoc works (require an associate/reassociate request/response?) or instead define a new mechanism for ad hoc networks?
Jesse Walker, Intel Corporation

20. May 2001
Comments 770, 1309
Previous text led me to believe that just the nonce element contents would be used for key derivation. This text seems to imply that the whole frame is used is this caching of the whole frame necessary?
We need to discuss what we want.
At a minimum, the key derivation should include all the associate protocol element fields we want protected from modification
Jesse Walker, Intel Corporation

21. May 2001
Comment 1177
Does "frame" here mean MPDU? I.e. is the counter incremented per MPDU or per MSDU?
The intent was to protect entire frames and then fragment later.
What is the right architecture? Where does encapsulation occur in the MAC processing?
Jesse Walker, Intel Corporation

22. May 2001
Comment 399
… if the sequence number reaches 2^32-1 the association shall be rekeyed. I believe the actions required of the peer who originally initiated the association are clear, but what does the other peer do with any data it might receive from this peer, or be required to send, in the meantime? The actions of the non-initiating peer are not clear when this occurs, but the concern here is that QoS data would stop being sent until a rekey occurs.
Requires discussion; related to key synchronization problem
Jesse Walker, Intel Corporation

23. May 2001
Comment 774
(Reclassified from editorial, to elicit discussion) The peer who originally initiated the association shall initiate the reassociation. Is this not always the STA?
This language was inserted to handle the ad hoc case. We need a model of ad hoc case. Do we use association request/response?
In any event, clean up language to make explicit the intent and the reasons for it.
Jesse Walker, Intel Corporation

24. May 2001
Comment 1182
Is the number "64" normative or advisory in this context? Where did it come from - i.e. what justification that 64 is the right number to use?
This is the size of the replay window
We need to discuss what the right value is.
“Correct” value depends on overall relation of encapsulation/decapsulation with MAC processes that reorder packets.
Jesse Walker, Intel Corporation

25. May 2001
Comment 1180
General comment applies to encapsulation and decapsulation: Does the sequence number need to be replicated for each e (Q) traffic class? What other state of the e (S) modifications is affected by multiple traffic classes and the resulting re-ordering of MSDUS of the MAC UNIDATA service?
People don’t understand sequence number goes with the key; if you have multiple sequence numbers with each QoS service class, this implies LOTs of keys, and this is not the security architecture. We need to have this discussion for political, not technical, reasons.
Jesse Walker, Intel Corporation

26. May 2001
Comment 400
The statement is made that "WEP2 and AES may only be used in an ESN". In clause the statement was made that "Implementation of the AES algorithm is optional, but any implementation claiming to provide ESN support shall implement it". Therefore, it appears to be impossible to implement WEP2 as an upgrade to legacy equipment without also providing AES and full ESN support, and still remain compliant with the standard.
What is the right language? This is more political than technical
Jesse Walker, Intel Corporation

27. May 2001
Comments 1183, 1223, 1185, 402, 83, 1184, 1352, 1420, 1451
Key synchronization at end of authentication needs to be specified and specified correctly
Jesse Walker, Intel Corporation

28. Clarification Required
May 2001
Clarification Required
Comment 613 – Matt Shoemake
Jesse Walker, Intel Corporation

29. Agenda Initial Classification Editorial and easily resolved comments
May 2001
Agenda
Initial Classification
Editorial and easily resolved comments
Motion
Comments requiring TG discussion
Review of “ALL” Comments
Jesse Walker, Intel Corporation

30. Comments on ALL Sections
May 2001
Comments on ALL Sections
1338, 1430: IBSS not addressed
779, 406, 1469, 51: PICS Required
406, 603, 53, 1471: MIB Required
406, 1431, 1470, 52: SLD Required
Jesse Walker, Intel Corporation