January 2005 doc IEEE 802 15 05 0082

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security clarifications] Date Submitted: [19 January, 2005] Source: [Robert Cragie] Company [Jennic Ltd. ] Address [Furnival Street, Sheffield, S 1 4 QT, 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. 4 b, Security enhancements] Abstract: [Discussion for several potential enhancements for current IEEE 802. 15. 4 MAC] Purpose: [For the discussion at IEEE 802. 15. 4 b Study Group] Notice: This document has been prepared to assist the IEEE P 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 P 802. 15. Submission 1 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Security Clarifications Robert Cragie Jennic Limited Submission 2 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Introduction • • Submission Proposes data structures for enhancements to security Companion document in 15 -04 -0539 3 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Outgoing frame security parameters • • Key Nonce – – – • Where the authentication data ends and where the encrypted data starts – Submission Frame Counter Source Extended Address Security Control Dependent on frame type and security level 4 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Security Material classes • Two classes of Security Material – – • Submission Link Key Network Key The names may not be entirely appropriate but are familiar to the security subgroup 5 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Link key • • Key shared between two devices only Point-to-point frame (source to destination) Implicit lookup information at destination Source address could also be transported (see also Device Lookup table optimisations) Source: • – – • Destination – – Submission Key Lookup: Destination address Device Lookup: Source address (i. e. self) Key Lookup: Source address Device Lookup: Source address 6 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Network key (1) • • • Submission Key sequence shared across multiple devices Owner is Key Source, which has an Identifier (e. g. a Trust Centre combined with a Key Sequence Number) The Key Source Identifier is unique over the lifetime of the system There is a notion of ‘current Key Source Identifier’, which is always used by the source device to lookup key Current Key Source Identifier is always transported in frame to provide explicit lookup information at destination 7 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Network key (2) • Source address could also be transported (see also Device Lookup table optimisations) Point-to-point, broadcast or group address frame (source to destination(s)) Source: • • – – • Destination – – Submission Key Lookup: Key Source Identifier Device Lookup: Source address (i. e. self) Key Lookup: Key Source Identifier Device Lookup: Source address 8 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Key sequence • • Submission Network Key is infact a sequence of keys The current yey being used is indicated by the Key Sequence Number When a particular key in a sequence cannot be used any more, e. g. due to frame counter wrapping, it is ‘retired’ and never used again The Key Sequence Number is then incremented, indicating that the next key in the sequence is then used 9 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b MAC PIB tables for security Key Table lookup Key Filter Table Destination Filter Table Key Table entry Device Table lookup Device. Filter Table Destination Filter Table Device Table entry Source Filter Table lookup Source Filter Table Destination Filter Source Filter Table entry Destination Filter Table lookup Destination. Filter. Table Destination Filter Table entry MAC PIB Submission 10 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Key Table • Submission A table of keys which can be matched to to retrieve the key information for the unsecuring process 11 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Device Table • A table of devices which can be matched to to retrieve – – – Submission Nonce extended address Frame counter for freshness checking Security level for checking 12 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Source Filter Table • • • Submission A table of source addresses which can be matched to to allow limiting of devices you wish to receive from ‘backwards group addressing’ Perhaps should not be considered as part of security but frame filtering process 13 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Destination Filter Table • • • Submission A table of destination addresses which can be matched to to allow group addressing Perhaps should not be considered as part of security but frame filtering process Already done in a fashion; broadcast address and self-address matching already specified in 802. 15. 4 -2003 14 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Lookup method • • Submission As tables are used, there must be some sort of lookup method; Idea is to capture only what data and class of data can be used for the lookup Data used to lookup can conceptually be anything up to 8 octets (i. e. extended address) It may be possible to have more than one matching method per table entry (e. g. short address and extended address matching) How the lookup list and matching method is implemented is deliberately not specified and left to the implementer (e. g. could be hash table, relational database etc. ) 15 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Key Table entry • • Key Device List – Submission A list of devices using this key, including whether they are blacklisted 16 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Key Table lookup • Lookup List – • • Submission A list of Lookup Descriptors which are used to match to PAN ID and short address pair Extended address Trust centre number and key sequence number pair In the most generic case, a variable length number which needs to be bitwise matched with another number of the same length 17 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Device Table entry • Extended Address – • Frame Counter – • – Submission Used for freshness checking Minimum Security Level – • Used for nonce Used to discard frames which do not meet minimum security level Depends on frame type as well There is one entry for yourself and one entry for each device you are in communication with 18 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Device Table lookup • Lookup Entry – • • • Submission A Lookup Descriptor which is used to match to Can only be PAN ID and short address pair Device Table entry’s Extended Address can always be used to match to In the most generic case, a variable length number which needs to be bitwise matched with another number of the same length 19 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Device Table lookup optimisations • If the extended address can always be implied from the frame, there is no need to store an extended address in a Device Table entry This means: • – – • Tradeoff: ↓ ↑ Submission Either explicitly transporting the extended address Or always using source address mode equal to 3 Longer frames or less room for payload Less storage requirement 20 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Source Filter Table entry • Submission No data – purely used for membership testing 21 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Source Filter Table lookup • Lookup Entry – • • • Submission A Lookup Descriptor which is used to match to PAN ID and Short Address Extended Address In the most generic case, a variable length number which needs to be bitwise matched with another number of the same length 22 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b ACL mode • • • Submission Simply implemented Device table is used If matched in Device Table, can be considered to be pass filtering 23 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Restricting mandates • Propose not use any text which implies: – – • • Submission Sharing of MAC PIB with higher layers Single-threaded operation These are entirely implementation-specific issues and have no place in a specification This categorically does not preclude an implementation from implementing it in this fashion should it so choose. 24 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Frame counters • • • Submission Propose to not use compressed form, as wraparound can occur quite quickly Propose to have a Frame Counter protocol stack level, e. g. the one used at the MAC level is independent from the one used at a network layer level This is because essentially the frame counter is changes on every frame secured at that particular stack level. 25 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Group addressing • • Submission Simply a form of packet filtering using the Destination Filter Table Network Key essentially becomes a ‘Group Key’, i. e. is distributed only to nodes in the group Propose to base it on bitmap and mask No further implication as destination address of frame is never used for Network Key lookup. 26 Robert Cragie, Jennic Ltd.

January 2005 doc. : IEEE 802. 15 -05 -0082 -00 -004 b Automatic Device Table entry addition • • Submission A method to prevent having to preconfigure the Device Table If you receive a frame and it successfully looks up the key, then allocate a temporary Device Table entry for it If the unsecuring process passes, install the Device Table entry into the Device Table Need a PIB attribute to allow this or not 27 Robert Cragie, Jennic Ltd.