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

1. Project: IEEE P802.15 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:[+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 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. 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 Robert Cragie, Jennic Ltd.

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 15-0082-01 Robert Cragie, Jennic Ltd.

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 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 Robert Cragie, Jennic Ltd.

10. Key Source Addressing Mode • Has been effectively replaced by the three new fields Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.

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 Robert Cragie, Jennic Ltd.