March 2005 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Draft 1 security change proposal] Date Submitted: [15 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.

Draft 1 Security Change Proposal <month year> doc.: IEEE 802.15-<doc#> March 2005 Draft 1 Security Change Proposal Robert Cragie Jennic Limited Robert Cragie, Jennic Ltd. <author>, <company>

March 2005 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.

Auxiliary Security Header (ASH) March 2005 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.

Key Identification (KI) subfield March 2005 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.

Source Extended Address March 2005 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.

KI subfield’s Key Source Address March 2005 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.

Proposed Security Control subfield <month year> doc.: IEEE 802.15-<doc#> March 2005 Proposed Security Control subfield Unchanged fields: Security Level Removed fields: Minimum Security Level Key Source Addressing Mode New fields: Explicit Source Extended Address Key Identifier Length Robert Cragie, Jennic Ltd. <author>, <company>

Minimum Security Level March 2005 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.

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

Explicit Source Extended Address March 2005 Explicit Source Extended Address Boolean field False: There is no source extended address explicitly specified in the ASH True: 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.

March 2005 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.

Key Identifier Length Enumerated field: March 2005 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 Robert Cragie, Jennic Ltd.

Implicit Key Identifier March 2005 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.

March 2005 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.

Proposed Auxiliary Security Header <month year> doc.: IEEE 802.15-<doc#> March 2005 Proposed Auxiliary Security Header Unchanged fields: Frame Counter Security Control New fields: Source Extended Address (optional) Key Sequence Number amalgamated into Key Identifier Robert Cragie, Jennic Ltd. <author>, <company>

Proposed Auxiliary Security Header (2) March 2005 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 not 0x00. Robert Cragie, Jennic Ltd.