July 2007 doc.: IEEE 802.11-07/0543r5
IEEE P802.11
Wireless LANs
Date: 2007-07-11
Author(s):
Name / Company / Address / Phone / email
Michael Montemurro / Research In Motion / 5090 Commerce Blvd. Mississauga, ON. L4W 5M5 / 905-629-4746
Ext. 4999 /
Wednesday April 11, 2007
11:00am
Attendees:
Clint Chaplin,
Bill Marshall,
Michael Montemurro,
Rajneesh Kumar,
Kapil Sood,
Keith Amann,
Lily Chen.
· Call to order
· Review of IEEE Intellectual Property Policy
· We do not have the official results of the latest letter ballot.
· The latest comment resolution spreadsheet is document 11-07/498r2
· The IEEE SA editorial review has given approval to proceed to sponsor ballots.
· We have to make sure that we have not introduced any trademark references in the specification.
· There are a collection of minor editorial revisions to the document.
· We really need to resolve the carry-over comments before the next ballot and preferably before May.
· Discussion on the comment resolution spreadsheet
· There are 239 new comments
· The comments in group #2 are editorial or trivial technical.
· We need to figure out how to deal with comments that don’t refer to changed text. The CAC is working to determine a policy to deal with these comments.
· We have a number of comments that deal with text that has not changed for a while.
· We have received approximately 20 valid comments for this letter ballot.
· Discussion on issue 56
· We had acknowledged that restricting the cipher suite selection to CCMP was too restrictive.
· One suggestion was to restrict TKIP to be used as the pairwise cipher suite.
· The comment on line 231 suggests “mandatory to implement” rather than “mandatory to advertise”.
· A combination of three things: TKIP should not be selected; CCMP should be mandatory to implement; and CCMP should not be mandatory to advertise.
· Once we formalize the text, the resolution will be clearer.
· The resolution should remove the requirement to advertise CCMP as the unicast cipher suite.
· The standard should not prevent TKIP from being used as a unicast cipher suite for fast BSS-transition.
· There are stations that are incapable of CCMP.
· If a STA is incapable of CCMP, it would not be compliant to TGr. If we were going to allow TKIP as a unicast cipher suite, we should not be specifying any unicast cipher suite.
· There could be deployments that use TKIP where there is a requirement for fast BSS-Transition.
· If TKIP is going to be allowed for TGr, then other parts of the draft would have to be updated with the mechanisms for sending TKIP keys as part of the protocol.
· There is currently text that makes MIC calculations dependent of the unicast cipher suite.
· There is other text that makes EAPoL-Key frames dependent on the unicast cipher suite.
· The cleanest solution would be to mandate the algorithm for all cipher suites.
· TKIP is excluded in TGw because there were hardware implementations on using TKIP for management frames.
· If we allow TKIP, we need to specify the key descriptor for the MIC. We would have to use key descriptor 1 for MIC calculations.
· IEEE 802.11i allows vendor-specific cipher suites and specifies that in that case, the key descriptor is set to 1.
· Our current draft requires the AES-CMAC for the FT case. Therefore the EAPoL MIC must use key descriptor set to 3.
· We will likely need to resolve this at the May meeting. It would be good if we could come up with consensus before the meeting.
· Discussion in issue 52
· There are a number of comments which suggest reducing the size of the fixed input strings in the key derivation.
· There is nothing to be gained by making the string shorter because it still will be 2 blocks.
· For the R1Key Derivation, the string will always be one block.
· For the R0KeyHolder, the NAS ID can be up to 48 blocks.
· There is no security value to the string because it is used in every key derivation.
· The word “derivation” doesn’t help.
· The label should say something about the key and the usage.
· The consensus is to use use “FT-R0” and “FT-R1”
· Adjourn until the next teleconference will be April 18.
Wednesday April 18, 2007
11:00am
Attendees:
Clint Chaplin,
Bill Marshall,
Michael Montemurro,
Dorothy Stanley,
Rajneesh Kumar,
Jouni Malinen,
Henry Ptasinski,
Lily Chen,
Keith Amann,
Kapil Sood.
· Call to order
· Review of IEEE Intellectual Property Policy
· Other groups that have gone to Sponsor Ballot have carried comments forward. We could take that approach for TGr.
· TGma rejected comments having to do with unchanged text and reconsidered the comments on the first Sponsor Ballot.
· We cannot go out to Sponsor Ballot because we had 3 new “no” voters on the last recirculation.
· We have 19 no voters, and 14 added with new comments, 3 carried their no vote forward, and 1 accepted comment resolutions but refused to change their vote.
· Discussion on comment resolution document 11-07/498r3
· Issue 51:
· There are a number of comments that make trival changes in places where we have no changed text. We have to decide what we want to do with these comments.
· Addressing more changed text now could add another re-circulation prior to Sponsor Ballot.
· The comments addressed are not controversial. These will eventually be addressed.
· The right thing to do is to carry over these comments to Sponsor Ballot.
· If we have issues with the draft, we should not go to Sponsor Ballot.
· The TGr draft is at the point where we should be in Sponsor Ballot.
· If we are ready for an outside security review, we are ready for Sponsor Ballot.
· Accepting these comments just makes the quality of the draft much better.
· Sponsor ballot is the ballot process that counts. It is in our best interest to reject these comments and get to Sponsor Ballot quicker.
· Deferring these comments to Sponsor Ballot has been done by other task groups.
· The CAC is discussing this topic and there may be more information that we can use.
· Issue 52:
· There are no issues with using FT-PTK for the PTK derivation.
· Issue 53:
· No where else in the standard is the STA sending a status code to the AP.
· The STA does not use the Status Code field in message 3 for shared-key authentication.
· We would need to explain the AP behaviour if it receieved a non-zero status code.
· The STA giving an attacker more information by providing this status code. An attacker could send an invalid message 2 and disrupt the FT protocol.
· IEEE 802.11i does not provide status codes. In general, security protocols should not include a status code.
· It is acceptable for the STA to send a generic status code.
· If the STA does not like Message 2, it can always initiate Message 1 again.
· This really does not change the behaviour of the AP during the FT protocol.
· In this case the STA would have to send Message 3 and then a Message 1 afterwards. Without the status code, the STA could just send message 1.
· There is not enough benefit, we should reject these comments.
· Issue 54:
· PTKName is not used.
· PTKName is available for debugging.
· There is a valid use for it. However, we need to make sure that devices do not have to implement it.
· We should not be mandating the PTKName.
· Adjourn until the adhoc meeting on April 24
Wednesday May 2, 2007
11:00am
Attendees:
Clint Chaplin,
Bill Marshall,
Michael Montemurro,
Dorothy Stanley,
Jouni Malinen,
Keith Amann,
Kapil Sood.
· Call to order
· Notice was given on the IEEE Intellectual Property Policy and the chair requested for any new patent assurances. None were given.
· Discussion on Issue 99 comments from document 11-07/498r3
· Comment 51 and 52. We are going to need an entry in clause 5.
· We had text in clause 5 but in the course of comment resolution, we removed all the text.
· We need to update the RSN clause updated for clause 5.
· We are addressing BSS Transition with QoS and Security.
· Fast BSS-Transition protocol is setting up services so that they are available at the time of reassociation.
· There is debate whether this issue should be addressed now or at Sponsor Ballot time.
· Clint will propose an agenda which calls out for when certain topics will be discussed.
· Comment 146 – No issues with the comment resolution.
· Comment 247
· The authenticator is defined in the base standard. The FT components are defined sufficiently in the draft now.
· There could be architectural elements which could be defined better.
· Comment 380 is related to this comment.
· The resolution to 380 may address comment 247.
· These comments can be deferred to Sponsor Ballot. We have more time to discuss the text which goes here.
· Comment 588
· We discussed this at the adhoc and added minor wording changes
· Discussion on comment in group 2
· Comment 278
· Concensus was that should accept this comment.
· Comment 342, 343, 351
· Consensus was that we should accept the resolution recorded in the spreadsheet.
· Comment 494 and 502
· Consensus was that we should accept the resolution recorded in the spreadsheet.
· Comment 564
· There would be forward references no matter which way the clauses are ordered.
· Consensus was that we should accept the resolution recorded in the spreadsheet.
· Discussion on comments that were explicity asked to carryover
· These comments warrant further discussion:
· Comment 4
· Comment 3, and 702
· Comment 519 and 619
· Comment 646 and 703
· Comment 239
· Comment 168, 208 and 240
· These comments do not have information
· Comment 21
· Comment 23
· There are approximately 250 comments that we haven’t heard about
· Discussion on comment 646
· We could add a new field to allow the Ethertype
· We could increase the “protocol version” to two octets and fix the fields
· We should defer this comment resolution to sponsor ballot.
· Jouni Malinen will prepare a proposal to address this comment.
· Discussion on comment 703
· An alternative way to do this is to place sub-elements with RIC data elements referring to TSPEC’s.
· Bill Marshall will prepare a submission to update the PICS in this manner.
· Adjourn until the teleconference call on May 9.
Wednesday May 9, 2007
11:00am
Attendees:
Clint Chaplin,
Bill Marshall,
Michael Montemurro,
Keith Amann,
Rajneesh Kumar,
Dorothy Stanley,
Jouni Malinen,
Kapil Sood.
· Call to order
· Notice was given on the IEEE Intellectual Property Policy and the chair requested for any new patent assurances. None were given.
· A preliminary agenda for the May meeting has been uploaded as document 11-07/624r0.
· Discussion on preliminary agenda – the result of the discussion will be updated in document 11-07/624r1.
· Discussion on carryover comments – well have to talk to the individuals with carry-over comments and wait until the result of the next letter ballot.
· Adjourn until the plenary meeting in Montreal.
Wednesday June 13, 2007
11:00am
Attendees:
Clint Chaplin,
Bill Marshall,
Michael Montemurro,
Ran van Chiu,
Jouni Malinen,
Dorothy Stanley,
Henry Ptasinski,
Rajneesh Kumar,
Keith Amann,
Kapil Sood.
· Call to order
· Notice was given on the IEEE Intellectual Property Policy and the chair requested for any new patent assurances. None were given.
· The letter ballot currently has not closed.
· It’s not clear yet whether we need the adhoc.
· We have 5 sessions during the SF meeting for comment resolution.
· We could do work at the adhoc on issues that we know will come up as a result of the first sponsor ballot.
· Straw poll on whether we need an adhoc: 5 – Yes; 5 – No.
· The adhoc will be considered on as of now. The Chair will make a final decision based on the results of the letter ballot.
· Adjourn until the adhoc on June 19.
Wednesday July 11, 2007
11:00am
Attendees:
Clint Chaplin,
Bill Marshall,
Michael Montemurro,
Dorothy Stanley,
Lily Chen,
Kapil Sood.
· Call to order.
· Notice was given on the IEEE Intellectual Property Policy and the chair requested for any new patent assurances. None were given.
· Clint uploaded a new version of the motion slides to the document repository as document 11-07/2064r2.
· The tentative agenda for TGr is uploaded as document 11-07/2064r0.
· Clint has received feedback from one of the security reviewers. Clint will prepare submission(s) that document feedback from the security reviews.
· Adjourn until the plenary session in San Francisco.
Submission page 10 Michael Montemurro