1 / 12

TG3 Security Exorcism for WPANs | Removing Public Key Authentication in 802.15.3 Draft

This submission provides guidance on removing public key authentication to align with 802.15.3's objective of being a layer 1 & 2 specification. Recommendations for addressing security concerns within IEEE 802.15 Working Group are discussed.

julieward
Download Presentation

TG3 Security Exorcism for WPANs | Removing Public Key Authentication in 802.15.3 Draft

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3 Security Exorcism] Date Submitted: [16January03] Source: [John Barr] Company [Motorola] Address [1303 E. Golf Road, Schuamburg, IL 60196] Voice:[+1 847 576-8706], FAX: [+1 847 576-6758], E-Mail:[John.Barr@Motorola.com] Re: [D15, SB1 comments, and email from Paul Nikolich] Abstract: [TG3 Chair Summary of Major Security Issue] Purpose: [Provide direction on how to remove public key authentication from 802.15.3 draft in order to satisfy requirement that this should only be a layer 1 & 2 specification.] Notice: This document has been prepared to assist the IEEE 802.15. 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by 802.15. Dr. John R. Barr, Motorola

  2. Email from Paul Nikolich (1 of 3) First, I would like to clarify that when I indicated to Bob Heile security suites were out of scope for the 802.15.3 PAR I was speaking as a member of 802, not as the Chairman of 802. I understand that some 802 WGs have included security suites in their documents and hence have been creeping towards developing specifications that are more like 'product specifications' as opposed to 'layer specifications'. Yet the mission of 802 is to develop high quality layer 1 and 2 specifications. In an ideal world the 802.15 WG would reference a suitable existing higher layer protocol (HLP) that vendors use to design and implement products. Yet, to your point, there may not be an suitable HLP to reference--then what does a vendor do? Good question. A question that 802 as a whole should take up. Maybe 802 can sponsor HLP development in another SA project. Maybe the WG specific HLP development can be done in 802.1, similar to what is done for 802.1D. Maybe the work should stay within the WG. Maybe 802 should develop a recommended practice. I'm not sure what the best approach is at this time. I do know 802 as a whole needs dedicate resources to figuring out what is the best way forward. Dr. John R. Barr, Motorola

  3. Email from Paul Nikolich (2 of 3) Second, I got the sense (perhaps incorrectly) that you expect me to declare a specific direction as the Chairman of 802---that is clearly out of scope of the 802 chair's authority. However, as Chairman of 802, I will commit to putting this '802 scope' issue on the agenda for discussion among the SEC members at the March Plenary Session with the intent that we put a process in place to resolve the issue as quickly as possible. The security work in 802.15.3 can be used as an example of the issue that needs to be resolved. My expectation is that 802.1, the Overview and Architecture WG, may take this issue up as a work item. Indeed, they have already been working closely with the Executive Committee Study Group on 802 Security and will most likely take ownership for the Security Study Group after the March Plenary Session. The 802.15.3 security seems to be yet another component of the overall issue the Security Study Group is working on. Dr. John R. Barr, Motorola

  4. Email from Paul Nikolich (3 of 3) You and those interested parties in 802.15.3 going forward should be to engage in the above discussion at the March plenary to help drive it toward an acceptable resolution as quickly as possible.. I have explored this issue with the 802 Vice Chairs (Geoff Thompson and Mat Sherman), Tony Jeffree (802.1 Chair) and Bob Heile and I have copied them on this email so they can see what my perspective is on this issue and perhaps provide their viewpoints as well. Dr. John R. Barr, Motorola

  5. 802.15 WG AC – January 16 • TG3 Chair brought up email from Paul for short discussion regarding our progress. • 802.15 Chair related his discussion with Paul stating that “Paul clearly felt that authentication portion of security should be left to higher layers.” • TG3 Chair directed to remove functionality not considered appropriate for layers 1 and 2. Dr. John R. Barr, Motorola

  6. Phone call with Paul – January 16 • Concerned that sponsor balloters would object to having level of security specified in 802.15.3. • Given that we do have a comment suggesting that public key suites be removed from the standard, suggests that the task group write a separate document containing public key authentication specification as a companion to 802.15.3. • Work with Security Study Group to determine how authentication should be defined for WPANs. Dr. John R. Barr, Motorola

  7. Moving Forward • We have CID 19 and supporting document (03/041r1) to remove definition of public key security suites from the standard and provide for 802.1x support. • This document does part of what is required and may also do items that are out of scope for a strict layer 1&2 specification. Dr. John R. Barr, Motorola

  8. What is required in the MAC? (1 of 2) • Symmetric key processing for payload protection • Ability to determine which DEVs are acceptable peers and members of a piconet. • Ability to obtain and update symmetric keys. • Provide security events to upper layer security manager. • Processing of security events required to update how the MAC operates in a secure mode. • Selective processing of commands and acceptance of frames based on security mode and state (which DEVs are authenticated). Dr. John R. Barr, Motorola

  9. What is required in the MAC? (2 of 2) • Definition of parameters used within the MAC that depend on a particular authentication security suite specification. • Other? Dr. John R. Barr, Motorola

  10. What is not required in the MAC? • ACL – The MAC should not maintain a separate list of authenticatable DEVs as this will be done in a higher layer. • Any informative annex on possible security suites. • Any protocol for authenticating peer or membership relationships. • Any references to specific security suites. • Other? Dr. John R. Barr, Motorola

  11. What we should not do? • Define unique OIDs for security suites. • Define or modify key exchange protocols. • Define or modify authentication protocols. • Specify parameters for a public key security suite used for authentication. • Other? Dr. John R. Barr, Motorola

  12. Justify Inclusion of the Following • Request/Distribute Keys – If this is a higher layer responsibility, why is it done in the MAC? Dr. John R. Barr, Motorola

More Related