1. May 2013
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Technical Review of KMP transport
Date Submitted: May 13, 2013
Source: Robert Moskowitz, Verizon
Address 1000 Bent Creek Blvd, MechanicsBurg, PA, USA
Voice:+1 (248) ,
Re: Key Management over 4e Multipurpose Frames
Abstract: Technical review of KMP transport
Purpose: To refine our understanding of the transport mechism
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
Slide 1
Robert Moskowitz, Verizon
Page 1

2. Technical Review of KMP Transport
May 2013
Technical Review of KMP Transport
Robert Moskowitz
Waikoloa, HI
May 13, 2013
Slide 2
Robert Moskowitz, Verizon
Page 2

3. Abstract Problem Statement Design Goals Agreements to date Open items
Next steps
Slide 3
Robert Moskowitz, Verizon
Page 3

4. Problem Statement 802.15.4 does not provide for
March 2013
Problem Statement
does not provide for
Differentiation in data traffic
All management left to 'higher layer'
Key Management
For security
Large enough datagrams for Key Management
'Sometimes'
Thus each implementation of needs to solve key management

5. More Problems Extremely constrained systems
March 2013
More Problems
Extremely constrained systems
Little memory
Little computing power
Little power (energy harvesting)
Highly critical applications
Building security
Power control
Traffic control
Critical infrastructure (bridge sensors)

6. Why not higher layer Not everything is
March 2013
Why not higher layer
Not everything is
Zigbee
6lowpan has not addressed this
There are very low end solutions that resist 'higher layers'
Need something for everyone answer

7. March 2013
Design Goals
Add a separate pathway for 'High Layer' command modules independent of the normal data higher layer
Flexible design that can be used by other command modules beyond KMP
EG bridging
No one 'right' KMP, multiple defined
But no negotiation mechanism
Mask packet size limitations from KMP
IE provide fragmentation support

8. Achieve Goals by Leveraging new Information Element
March 2013
Achieve Goals by Leveraging new Information Element
Feature of e
Flexible IE added to headers and data payload
IE model can be adopted by per-4e higher layers
E.G. 6lowpan

9. Agreements to date System View KMP encapsulation data format
KMP payload fragmentation mechanism
State Machines general content
Plus PIBs to control processes
General statements on Security Associations
KMP guidelines general format
Robert Moskowitz, Verizon
Page 9

10. Information Element Shim
System View
DATA higher layer
Other IE processes
KMP
Key Request
Keys
Data Traffic
Information Element Shim
Data MCPS
IE frames
MAC Services
PHY Services
Robert Moskowitz, Verizon
Page 10

11. KMP Transport Use a DATA Frame IE for KMP encapsulation
IE with max size of 2047
IE max size of 255
Multiple IEs per frame an option
Robert Moskowitz, Verizon
Page 11

12. KMP Transport MAC details
Unauthenticated PDUs always use long addresses
e.g. KMP rekeying within authenticated PDUs MAY use short addresses
KMP payload MAY be fragmented over multiple IEs/frames
Use Forced ACK for fragmentation chaining support
Robert Moskowitz, Verizon
Page 12

13. KMP Information Element
Frame format
MAC specific information
ID/Length
= 0xa/max2047
= 0x03/max255
Content
Control Field – 1 byte
Multipurpose field allows for extending to other functions like L2R and EthType support
KMP fragment
Robert Moskowitz, Verizon
Page 13

14. KMP IE Content Octets: 1 Octets: 1-2046 Bits: 1 7 KMP Fragment
Chaining flag
0 = last/only one
1 = yes, chaining
First packet: Multipurpose ID
Other packets: Chain count
Multipurpose ID:
98 = KMP
Chaining count: 2-96
2 = 2nd fragment
3 = 3rd fragment …
96 = 96th fragment
(last possible)
Robert Moskowitz, Verizon
Page 14

15. KMP IE Content KMP fragment KMP ID (1st/last frame only) – 1 byte
802.1X = 1
HIP = 2
IKEv2 = 3
PANA = 4
SAE, etc.
KMP payload
Robert Moskowitz, Verizon
Page 15

16. KMP Content Examples Chaining Flag, MultiID/Count, KMP fragment
0,98,2,<KMP payload> - Single frame for HIP
1,98,2,<KMP payload fragment> - 1st frame for HIP and more to come
1,2,<KMP payload fragment> - 2nd frame for HIP and more to come
0,3,<KMP payload fragment> - 3rd (and last) frame for HIP
Note that 96 fragments provides for 8KB
Assuming 127 MPDU
Robert Moskowitz, Verizon
Page 16

17. KMP State Machines Two State Machines KMP Outbound Frame Processing
KMP Inbound Frame Processing
Robert Moskowitz, Verizon
Page 17

18. Outbound Frame Processing
Fragment MPDU-MHR -IE-KMP
>= 0
Send
Failure
< 0
Success
Send frag
Failure
Success
Send middle frags
Failure
Success last - 1
Send last frag
Failure
Per Dest addr
Success
Success
Robert Moskowitz, Verizon
Page 18

19. KMP Outbound frame processing
Fragmentation support
KMP payload divided to fit MPDU
Fragment sent with Forced ACK
Robert Moskowitz, Verizon
Page 19

20. Inbound Frame Processing
Yes
Dup to prior Src Addr, Seq, IE
Drop No
Error 1 98
Start KMP assembly
Chaining flag
Multi-purpose
2 to 95
Error 98
Complete KMP
Multi-purpose
Append KMP
2 to 96
2 to 96
Per Src addr
Append to list and complete
Robert Moskowitz, Verizon
Page 20

21. KMP Inbound frame processing
Determine packet type
Time out OK on Incomplete KMP
Fragmentation support
Duplicates possible due to lost ACK
Requires KMP buffer & coordinators with N buffers
Deliver payload to KMP on completion
Robert Moskowitz, Verizon
Page 21

22. KMP Transport Mechanism
State machine to handle triggers to/from KMP higher layer
Pass through for KMP payloads
Triggers from MAC events to KMP
Security Enabled to start KMP
Frame Counter watch to trigger rekey
Robert Moskowitz, Verizon
Page 22

23. KMP Transport PIBs Security enabled trigger MacSecurityEnabled
Set to true by KMP process after keys in place
When initially set to true
MacFrameCounter set to 0
MacSecurityRekey set to false
MacSecurityRequired
Set by 'Higher Layer' to trigger KMP start
Robert Moskowitz, Verizon
Page 23

24. KMP Transport PIBs Security enabled trigger MacSecurityRekey
True is set whenMacFrameCounter = 0xffffffff – n
Triggers rekey on next MLME Data Send
Since many secured COMMAND frames could be sent prior to data, n MUST be much greater than 1. e.g. 100
Robert Moskowitz, Verizon
Page 24

25. More on KMP Transport PIBs
macFrameCounter = 0xffffffff – n
Counter for sending, thus sending party triggers rekeying
ASSUMPTION: Only coordinators send with group keys and rekey as needed
Robert Moskowitz, Verizon
Page 25

26. KMP Guidelines Initial list of KMPs 802.1X
Needs to include an actual key exchange like the i 4-way handshake
HIP – R. Moskowitz/J. Haapola
IKEv2 – T. Kivinen
PANA – Yoshihiro Ohba
SAE
Robert Moskowitz, Verizon
Page 26

27. KMP Guidelines KMP use cases Why this KMP? Practical examples
Code size, CPU/battery demand
Multi-layer code reuse
Practical examples
Deployment advice
Identity installation and registration
When performed
Life-cycle management
Rekeying
Robert Moskowitz, Verizon
Page 27

28. KMP Guidelines KMP Sections General KMP description Use case(s)
Sub sections as needed, e.g. backend authentication mechanism
Use case(s)
Profile
References to defining documents
Parameter specifics, e.g. in HIP, K=0
SA definition
E.G. Tie into security PID
Robert Moskowitz, Verizon
Page 28

29. KMP Guidelines KMP Profiling for 15.9 usage Change in encapsulation
e.g. IKEv2 specified to run over UDP
Additions for SA management
e.g X does not supply link keys. In usage, this is done via the 4- Way Handshake
Special attention to broadcast keying management
Others?
Robert Moskowitz, Verizon
Page 29

30. KMP Security Associations
Security Association content
What keys? PTK, GTK, etc.
Counters, lifetimes, etc.
This is the realm of the KMP
Robert Moskowitz, Verizon
Page 30

31. 15.4 Specifics Pre 15.4e device support For 6lowpan PANs
Develop a submission to the IETF using the Dispatch Type in RFC 4944
PDUs with the KMP Dispatch Type a length field will be equivalent to the 15.4e KMP IE
A 6lowpan device that supports 15.4e SHOULD also support this pre-15.4e mode of operation
Who wants to author this?
Robert Moskowitz, Verizon
Page 31

32. Next Steps
Robert Moskowitz, Verizon
Page 32

33. Next Steps Continue adding KMP content Work out issues with 802.15.7
Is the limit of IEs to command frames only with commands present a showstopper
Will 15.7 need an addendum to support KMP?
Document ready for TG review July 2013
Robert Moskowitz, Verizon
Page 33