May 2011 doc IEEE 802 15 11 0381

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Key Management over 4 e Multipurpose Frames Date Submitted: May 20, 2011 Source: Robert Moskowitz, Verizon Address 1000 Bent Creek Blvd, Mechanics. Burg, PA, USA Voice: +1 (248) 968 -9809, e-mail: rgm@labs. htt-consult. com Re: Key Managementn over 4 e Multipurpose Frames Abstract: Using 4 e Multipurpose Frames to provide for Key Mangement Purpose: To add Key Management capabilities to 15. 4 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 Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Key Management over 15. 4 e Multipurpose Frames Robert Moskowitz San Francisco July 20, 2011 Submission 2 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Abstract To provide for a Key Management Protocol for 802. 15. 4 KMP agnostic Support: HIP, IKEv 2, 802. 1 X, . . . Provide recommended functionality for KMPs Use Information Elements – Submission in the new Multipurpose and existing Comand Frames added via 15. 4 e for the transport of the KMP frames 3 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Discussion Functionality needed – Manage keying variables in 802. 15. 4 security • – Submission – – – Security mode, key value, key rollover, . . . Manage long-lived PMK and keylifetime PTK (including key refresh) Distribute GTK for broadcast/multicast Provide authentication Manage short 4 addresses Robertand Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Discussion 4 e Multipurpose Frame – – Adds flexibilty to 15. 4 New functions without major standards revisions 4 e Information Elements – – Submission Available in Multipurpose and Command frames Basic TLV – Type/Length/Value 5 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Discussion KMP Information Element – – Type value assigned from 802. 15. 4 reserved range 2 Byte KMP info field • • KMP type 5 bits (HIP, IKEv 2, 802. 1 X, SAE, 4 -Way-Handshake, vendor ) Chaining flag 1 bit (yes, last) – • Submission Chaining REQUIRES frame ack Chain count 8 bits (multiple frames per KMP packet) 6 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Discussion KMP Information Element – KMP payload • Submission Guidelines provided for 15. 4 specific use 7 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Discussion Short address for KMP frames – Need general collision handling • – What if multiple KMPs in a PAN? When HIP is KMP • • I 1 always uses long addresses HITs used derive short addresses – – Submission Low order 16 bits? Include short addresses in R 1 over long addresses, THEN I 2 over short addresses to handle collisions? 8 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Discussion BEACONLESS PANs are commonly deployed and thus first step in participation would be to KMP over Multipurpose frames. BEACON PANs use ASSOCIATE Command Frames to start participation. – Submission These frames can contain IEs so they would be used for KMP transport. 9 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip HIP KMP Discussion HIT discovery and defense from Diffie. Hellman MITM attacks – – Assume Initiator has no knowledge of Responders HIT for I 1, so use I 1 opportunistic mode (no Responder HIT) Responder authenticates Initiator HIT • • Submission Pre-configured ACL Restricted time window 10 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Moving Forward Create 802. 15. 4 Recommended Practice document for KMP support as outlined – – Submission Include HIP DEX, IKEv 2, 802. 1 X, SAE, and 4 -Way-Handshake guidelines Allow for other KMPs defined elsewhere 11 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Moving Forward Address issues raised for 15. 4 f support – – Submission KMP REQUIRES bi-directional data flows Research Blink frames 12 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Moving Forward Use by other 802. 15 MACs (e. g. . 3, . 6, . 7) – – They will need Information Element support and Multipurpose frame Common Type value for IE? Short address collision detection – Submission Need general solution or KMP will be forced to long addresses only 13 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0381 -03 -0 hip Moving Forward Work with IETF with 'mess under' to support KMP within a 15. 4 mess? – Submission E. G. to protect IPv 6 Neighbor Discovery 14 Robert Moskowitz,