doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 1 Summary of Security and Link Establishment Protocols 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, 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. Date: Authors:

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 2 Abstract This submission provides a status report on two independent submissions planned for the September meeting.

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 3 Agenda Status of Security Proposal (doc ) Status of Link Establishment Proposal (doc )

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 4 Status of

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 5 Goals of Develop a security architecture for Mesh Transport function Reuse i with minimal change Do not preclude further security proposals –e.g., alternate authentication mechanisms –e.g., mechanisms to enhance performance

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide Overview Use Mesh link state discovery and maintenance (11A.1) to establish links between MPs When establishing the link, negotiate i Supplicant and Authenticator roles –This is a new phase we introduce in order to allow using i authentication and key management protocols relatively unchanged Finally, initiate authentication and key management protocols as defined in i (with minor changes) –Insert the Supplicant’s GTK into 4-Way Handshake message 2 Both parties’ control ports are blocked once starting link establishment, until the end of 4-way handshake

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 7 Some Topics Not Addressed by Non-802.1X authentication –The document was written to not preclude this r-like key caching –New mechanisms to provision pairwise keys between different peers is not addressed by , but not precluded either Optimized session establishment by overlaying 4-Way Handshake on top of mesh Link establishment –We are working on another submission to do this Routing security –We will present what we know about this in November and determine whether there is sufficient support to move forward

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide Status 1001 has been merged with , which TGs rejected in San Diego –The main objection raised was we split 1088 from 1001 to address the extensibility issue Added text suggested by Jan Kruys to make the use of i key caching more explicit Added Jan and Kalyan Dharanipragada as co-authors Renumbered clause 11A.5 as Clause 8.8 in the Security Chapter The document will be posted this week. We plan to have TGs vote on this proposal in Melbourne

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 9 Status of

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 10 Link Establishment Problems (11A.1) Unreliable communication –Deadlock possible because of message loss –In current design, it is not well defined Poor performance and livelock possible due to lack of instance identifiers –The design does not bound the connect time variance, because peers can get into an Open/Close Request/Response loop without instance identifiers Link establishment specification is incomplete Use random numbers for tie break –Collision will still happen with some frequency given the 32 bit size of the identifiers – about once every 2 16 link establishment attempts

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 11 Example Specification Problem Association Response Superordinate MP Association Request (R1) R1 reboot Current protocol doesn’t fully specify what to do ??

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 12 Protocol Design Goals Deal with the unreliable communication channel No deadlock or livelock Bind peers to link instances to –Enhance performance by bounding the variation in the link establishment time –Remove race conditions inherent in the association design Allow functions provided by 4-Way Handshake to be overlaid on top of link establishment with no loss of security

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 13 Peer Link Establishment Overview Three messages –Peer Link Open, Peer Link Confirm, Peer Link Close Rules –Both peers can initiate the link establishment protocol –The peer link is established if and only if both peers send and receive Open and Confirm messages Link instance –Identifier –myId and peerId: MAC addresses –myRa and peerRb: random numbers generated for this link instance –Enforce binding between link instance and messages Peer Link Open (myId, peerId, Ra) Peer Link Confirm (myId, peerId, Ra, Rb) Peer Link Close (myId, peerId, Ra, Rb)

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 14 0: IDLE 1: LISTEN 2: OPEN_SENT 3: CONFIRM_SENT 4: ESTABLISHED 5: HOLDING State Machine PassivOpen / - CancelLink / - ActiveOpen / Open Open / Confirm Confirm / Confirm Confirm / - CancelLink / Close Close / - Exceed MAX-REQS / Close CancelLink or Close or CancelTimer expires / - RetryTimer expire / Open Open / Close Confirm / Close CancelLink or Open / Confirm

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 15 Relationship to Today there is no relationship –Link establishment is link establishment, and security is security – assumes that some link establishment mechanism exists, but not necessarily this one Future relationship –If is adopted, we intend to propose an overlay of the 4- Way Handshake functions on top of the protocol, which would provide link establishment and security when keys are cached

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide Status Working on Revision 3 of the document Still in dialog with other TGs participants We plan to submit next week, incorporating input from other TGs participants We plan to introduce for a vote in Melbourne

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 17 Next Steps Post later this week Post next week Incorporate feedback and suggestions into both documents prior to Melbourne

doc.: IEEE /1353r0 Submission September 2006 J. Walker, M. Zhao, and S. Conner (Intel) Slide 18 Feedback?