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

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

Classification: Clause 8.2.3.3.1 – 8.5 May 2001 Classification: Clause 8.2.3.3.1 – 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

May 2001 Classification: 8.2.3.3.1 – 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

May 2001 Classification: 8.2.3.3.1 – 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

May 2001 Comment 1180 General comment applies to encapsulation and decapsulation: Does the sequence number need to be replicated for each 802.11e (Q) traffic class? What other state of the 802.11e (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

May 2001 Comment 400 The statement is made that "WEP2 and AES may only be used in an ESN". In clause 8.2.3.1 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

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

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

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

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