1 / 15

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ Draft 1 security change proposal ] Date Submitted: [ 11 May, 2005 ] Source: [ Robert Cragie ] Company [ Jennic Ltd. ] Address [ Furnival Street, Sheffield, S1 4QT, UK ]

Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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 P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Draft 1 security change proposal] Date Submitted: [11 May, 2005] Source: [Robert Cragie] Company [Jennic Ltd.] Address [Furnival Street, Sheffield, S1 4QT, UK] Voice:[+44 114 281 4512], FAX: [+44 114 281 2951], EMail:[rcc@jennic.com] Re: [Response to the call for proposal of IEEE 802.15.4b, Security enhancements] Abstract: [Discussion for several potential enhancements for current IEEE 802.15.4 MAC] Purpose: [For the discussion at IEEE 802.15.4b Study Group] Notice: This document has been prepared to assist the IEEE P802.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 P802.15. Robert Cragie, Jennic Ltd.

  2. Draft 1 Security Change Proposal Robert Cragie Jennic Limited Robert Cragie, Jennic Ltd.

  3. Introduction • There are limitations in the changed security proposals in TG4b draft 1 • This proposal is an attempt to resolve some of the problems based on discussions between the security subgroup members • Also includes resolutions from TG4b ad-hoc, 2-3 May 2005. Robert Cragie, Jennic Ltd.

  4. Auxiliary Security Header (ASH) • Consists of • Frame Counter subfield • Security Control subfield • Key Identification subfield (optional) • Key Identification subfield only present if Security Control subfield’s key source addressing mode is 0x01 to 0x03 Robert Cragie, Jennic Ltd.

  5. Key Identification (KI) subfield • Currently consists of: • Key Source Address (0/4/8 octets) • Key Sequence Number (1 octet) • Key Source Address is limited to: • PAN ID/Short address pair • Extended address Robert Cragie, Jennic Ltd.

  6. KI subfield’s Key Source Address • At the moment, it is currently based on implicit rules and addresses • Key Sequence number is an explicit extra but for lookup purposes is really just an appendix. It is no longer part of the nonce • Would be more flexible if it were just a variable length number used for lookup • This is more in line with 15-0082-01 Robert Cragie, Jennic Ltd.

  7. Proposed Security Control subfield • Unchanged fields: • Security Level • Removed fields: • Minimum Security Level • Key Source Addressing Mode • New fields: • Key Identifier Length Robert Cragie, Jennic Ltd.

  8. Source Extended Address • There is currently no means of explicitly specifying the source extended address in the ASH • However, this has not been included as there are other ways of conveying this information, e.g: • Device Table set up a priori • Using source address mode 3 • See comments #458 and #1129 Robert Cragie, Jennic Ltd.

  9. Minimum Security Level • Contains the minimum security level for the frame type from macSecurityLevelTableOut • Removed as it is arguable how useful it is; it is not used within the MAC and passed up to the higher layer only • There was some case where it may have been useful for association but this is often done unsecured as it is part of link establishment • macSecurityLevelTableOut can also be removed • If minimum security level cannot be removed, will need an additional octet in the ASH to carry Key Identifier length • See comments #145, #150, #457, #863, #944, #1080/32 and #1095/47 Robert Cragie, Jennic Ltd.

  10. Key Source Addressing Mode • Has been effectively replaced by the Key Identifier Length Robert Cragie, Jennic Ltd.

  11. Key Identifier Length • Enumerated field: • 0x00: The Key Identifier is 0 octets long; the Key Identifier is implicit • 0x01: The Key Identifier is 1 octet long • 0x02: The Key Identifier is 5 octets long • 0x03: The Key Identifier is 9 octets long • The Key Sequence Number (now a higher level concept) has been amalgamated into the Key Identifier • Generalise the Key Identifier to be just a number, not necessarily an address • See comments #455, #1075/27 and #1147/99 Robert Cragie, Jennic Ltd.

  12. Implicit Key Identifier • If Key Identifier length is 0, the Key Identifier is determined as follows: • Non-group addressed PDUs: • Source address is implicitly used as the Key Identifier at originator and destination address is used as the Key Identifier at recipient. This is because it is a link key, and keying material is a function of both source and destination address. • Group-addressed PDUs: • Destination address is implicitly used for as the Key Identifier at both originator and recipient. This is because it is a group/network key and keying material is a function of an identifier only; in this case it happens to be the destination address Robert Cragie, Jennic Ltd.

  13. Explicit Key Identifier • If Key Identifier length is not 0, the Key Identifier is used to lookup the keying material • A typical arrangement of keying material data could be: • A sequence of up to 256 keys for a single default keying material sequence looked up by 1 octet Key Identifier • A sequence of up to 256 keys for a number of 4-octet based keying material sequences looked up by 5-octet Key Identifier • A sequence of up to 256 keys for a number of 8-octet based keying material sequences looked up by 9-octet Key Identifier Robert Cragie, Jennic Ltd.

  14. Source of ASH data • The source of the ASH data could either come from primitive parameters or ‘current’ PIB values • Draft 1 favours passing parameters in the primitives, e.g. in MCPS-DATA.request, KeyIdAddrMode and KeyIdAddress are passed. The advantages of this is that they are specified on a per-frame basis and could still be derived from the next higher layer’s ‘current’ information base Robert Cragie, Jennic Ltd.

  15. Proposed Auxiliary Security Header • Security Control and Frame Counter fields swapped round (comment #1038) • Key Sequence Number amalgamated into Key Identifier (comments • The Key Identifier is only present if the Security Control subfield’s Key Identifier Length field is not 0x00 Robert Cragie, Jennic Ltd.

More Related