1. Robert Moskowitz, Verizon
July 2011
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Key Management over 4e Multipurpose Frames
Date Submitted: May 20, 2011
Source: Robert Moskowitz, Verizon
Address 1000 Bent Creek Blvd, MechanicsBurg, PA, USA
Voice:+1 (248) ,
Re: Key Managementn over 4e Multipurpose Frames
Abstract: Using 4e 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 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
Robert Moskowitz, Verizon

2. Key Management over 15.4e Multipurpose Frames
July 2011
Key Management over 15.4e Multipurpose Frames
Robert Moskowitz
San Francisco
July 20, 2011
Robert Moskowitz, Verizon

3. Abstract To provide for a Key Management Protocol for 802.15.4
July 2011
Abstract
To provide for a Key Management Protocol for
KMP agnostic
Support: HIP, IKEv2, 802.1X, ...
Provide recommended functionality for KMPs
Use Information Elements
in the new Multipurpose and existing Comand Frames added via 15.4e for the transport of the KMP frames
Robert Moskowitz, Verizon

4. Discussion Functionality needed
July 2011
Discussion
Functionality needed
Manage keying variables in security
Security mode, key value,key rollover, ...
Manage long-lived PMK and key- lifetime PTK (including key refresh)
Distribute GTK for broadcast/multicast
Provide authentication
Manage short addresses and collisions
Robert Moskowitz, Verizon

5. Discussion 4e Multipurpose Frame 4e Information Elements
July 2011
Discussion
4e Multipurpose Frame
Adds flexibilty to 15.4
New functions without major standards revisions
4e Information Elements
Available in Multipurpose and Command frames
Basic TLV – Type/Length/Value
Robert Moskowitz, Verizon

6. Discussion KMP Information Element
July 2011
Discussion
KMP Information Element
Type value assigned from reserved range
2 Byte KMP info field
KMP type 5bits (HIP, IKEv2, 802.1X, SAE, 4-Way-Handshake, vendor )
Chaining flag 1 bit (yes, last)
Chaining REQUIRES frame ack
Chain count 8bits (multiple frames per KMP packet)
Robert Moskowitz, Verizon

7. Discussion KMP Information Element KMP payload July 2011
Guidelines provided for 15.4 specific use
Robert Moskowitz, Verizon

8. Discussion Short address for KMP frames
July 2011
Discussion
Short address for KMP frames
Need general collision handling
What if multiple KMPs in a PAN?
When HIP is KMP
I1 always uses long addresses
HITs used derive short addresses
Low order 16 bits?
Include short addresses in R1 over long addresses, THEN I2 over short addresses to handle collisions?
Robert Moskowitz, Verizon

9. July 2011
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.
These frames can contain IEs so they would be used for KMP transport.
Robert Moskowitz, Verizon

10. July 2011
HIP KMP Discussion
HIT discovery and defense from Diffie- Hellman MITM attacks
Assume Initiator has no knowledge of Responders HIT for I1, so use I1 opportunistic mode (no Responder HIT)
Responder authenticates Initiator HIT
Pre-configured ACL
Restricted time window
Robert Moskowitz, Verizon

11. July 2011
Moving Forward
Create Recommended Practice document for KMP support as outlined
Include HIP DEX, IKEv2, 802.1X, SAE, and 4-Way-Handshake guidelines
Allow for other KMPs defined elsewhere
Robert Moskowitz, Verizon

12. Moving Forward Address issues raised for 15.4f support
July 2011
Moving Forward
Address issues raised for 15.4f support
KMP REQUIRES bi-directional data flows
Research Blink frames
Robert Moskowitz, Verizon

13. Moving Forward Use by other 802.15 MACs (e.g. .3, .6, .7)
July 2011
Moving Forward
Use by other MACs (e.g. .3, .6, .7)
They will need Information Element support and Multipurpose frame
Common Type value for IE?
Short address collision detection
Need general solution or KMP will be forced to long addresses only
Robert Moskowitz, Verizon

14. July 2011
Moving Forward
Work with IETF with 'mess under' to support KMP within a 15.4 mess?
E.G. to protect IPv6 Neighbor Discovery
Robert Moskowitz, Verizon