1. Robert Moskowitz, Verizon
September 2011
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Key Management over 4e Multipurpose Frames
Date Submitted: September 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
September 2011
Key Management over 15.4e Multipurpose Frames
Robert Moskowitz
Okinawa
September 20, 2011
Robert Moskowitz, Verizon

3. Abstract To provide for a Key Management Protocol for 802.15.4
September 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
September 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
Robert Moskowitz, Verizon

5. Discussion Functionality needed Provide authentication Manage
September 2011
Discussion
Functionality needed
Provide authentication
Manage
Short addresses
Collisions
Duplicate transmissions
Robert Moskowitz, Verizon

6. Discussion 4e Multipurpose Frame Pre 4e usage Adds flexibilty to 15.4
September 2011
Discussion
4e Multipurpose Frame
Adds flexibilty to 15.4
New functions without major standards revisions
Pre 4e usage
Recommendation on equivalent method
Should be 'easy' for 6lowpan
Robert Moskowitz, Verizon

7. Discussion 4e Information Elements
September 2011
Discussion
4e Information Elements
Available in Multipurpose and Command frames
Basic TLV – Type/Length/Value
Robert Moskowitz, Verizon

8. Discussion KMP Information Element
September 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

9. Discussion Duplicate transmission management KMP Information Element
September 2011
Discussion
Duplicate transmission management
Keep last frame received to determine if duplicate
Duplicates result of lost ACKs. Other reasons?
KMP Information Element
KMP payload
Guidelines provided for 15.4 specific use
Robert Moskowitz, Verizon

10. Discussion Short address for KMP frames
September 2011
Discussion
Short address for KMP frames
Need general collision handling
Or NO short address support?
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

11. Discussion If no short address for initial KMP frames
September 2011
Discussion
If no short address for initial KMP frames
KMP update frames MAY use short addresses established by other higher layers
E.G. 6lowpan
Robert Moskowitz, Verizon

12. September 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

13. Discussion What options for TX only devices? BLINK frames
September 2011
Discussion
What options for TX only devices?
BLINK frames
Open for presentations
Robert Moskowitz, Verizon

14. Discussion What about 802.15.7 and 15.6?
September 2011
Discussion
What about and 15.6?
KMP transport in 15.4 built on following:
Information Elements for encapsulation
Non-data frame (multipurpose in 15.4) for transport
Forced ACK mechanism to simplify reassembly
Session key hierarchy to populate
Similar features in .6 and .7?
Robert Moskowitz, Verizon

15. September 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

16. September 2011
Moving Forward
Create Recommended Practice document for KMP support as outlined
Separate from 15.4, with section on implementation in 15.4
Include HIP DEX, IKEv2, 802.1X, SAE, and 4-Way-Handshake guidelines
Allow for other KMPs defined elsewhere
Robert Moskowitz, Verizon

17. Moving Forward Address issues raised for 15.4f support
September 2011
Moving Forward
Address issues raised for 15.4f support
KMP REQUIRES bi-directional data flows
Research Blink frames
May need to explicitly exclude TX- RFD only devices
Robert Moskowitz, Verizon

18. Moving Forward Use by other 802.15 MACs (e.g. .3, .6, .7)
September 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?
Section for each
Short address collision detection
Need general solution or KMP will be forced to long addresses only
Robert Moskowitz, Verizon

19. September 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