Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.15-05-0134-00-004b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area.

Similar presentations


Presentation on theme: "Doc.: IEEE 802.15-05-0134-00-004b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area."— Presentation transcript:

1 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Draft 1 security change proposal] Date Submitted: [09 March, 2005] Source: [Robert Cragie] Company [Jennic Ltd.] Address [Furnival Street, Sheffield, S1 4QT, UK] Voice:[ ], FAX: [ ], Re: [Response to the call for proposal of IEEE b, Security enhancements] Abstract:[Discussion for several potential enhancements for current IEEE MAC] Purpose:[For the discussion at IEEE b Study Group] Notice:This document has been prepared to assist the IEEE P 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 P

2 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 2 Draft 1 Security Change Proposal Robert Cragie Jennic Limited

3 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 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

4 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 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

5 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 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

6 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 6 Source Extended Address There is currently no means of explicitly specifying the source extended address in the ASH Adding this could eliminate device table at remote end if freshness checking is made optional

7 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 7 KI subfield’s Key Source Address At the moment, it is currently based on implicit rules and addresses Would be more flexible if it were just a variable length number used for lookup This is more in line with

8 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 8 Proposed Security Control subfield Unchanged fields: –Security Level Removed fields: –Minimum Security Level –Key Source Addressing Mode New fields: –Explicit Source Extended Address –Key Sequence Number Present –Key Identifier Length

9 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 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

10 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 10 Key Source Addressing Mode Has been effectively replaced by the three new fields

11 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 11 Explicit Source Extended Address Boolean field Negated: –There is no source extended address explicitly specified in the ASH Asserted: –The source extended address is explicitly specified in the ASH. Adding the ability to explicitly specify source extended address in the ASH means that short addressing can be used for source address in MHR and device table is not necessarily required at remote end (assuming freshness checking becomes optional). Explicit Source Extended Address is always used for the nonce at recipient

12 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 12 Freshness checking If there is a device table entry for the originator of the frame, freshness checking is done, as there will be a corresponding saved frame counter If there is no device table entry, no freshness checking will be done and it will be assumed that all keying material can be obtained from the frame and key lookup

13 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 13 Key Sequence Number present Boolean field Negated: –There is no Key Sequence Number present in the KI Asserted: –The Key Sequence Number is present in the KI. This may be redundant as if an explicit Key Identifier is used, the KSN may always need to be present

14 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 14 Key Identifier Length Enumerated field: –0x00: The Key Identifier is 0 octets long; the Key Identifier is implicit –0x01: The Key Identifier is 4 octets long –0x02: The Key Identifier is 8 octets long –0x03: Reserved This, combined with the Key Sequence Number present field, gives the same options as currently in Draft 1 Generalise the Key Identifier to be just a number, not necessarily an address

15 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 15 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

16 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 16 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 Explicit Source Extended address would also need to be indicated somehow. The originator may need to know capabilities of recipient to determine this

17 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 17 Proposed Auxiliary Security Header Unchanged fields: –Frame Counter –Security Control New fields: –Source Extended Address (optional) Optional Key Sequence Number explicitly shown at this level

18 doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 18 Proposed Auxiliary Security Header (2) The Source Extended Address is only present if the Security Control subfield’s Explicit Source Extended address field is asserted The Key Identifier is only present if the Security Control subfield’s Key Identifier Length field is 0x01 or 0x02. The Key Sequence Number is only present if the Security Control subfield’s Key Sequence Number Present field is asserted


Download ppt "Doc.: IEEE 802.15-05-0134-00-004b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area."

Similar presentations


Ads by Google