May 2013 Project: IEEE P802.15 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) 968-9809, e-mail: rgm@labs.htt-consult.com 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 P802.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 P802.15. Slide 1 Robert Moskowitz, Verizon Page 1

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

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

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

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)

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

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

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

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

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

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

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

KMP Information Element Frame format MAC specific information ID/Length 802.15.4 = 0xa/max2047 802.15.7 = 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

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-126 98 = KMP Chaining count: 2-96 2 = 2nd fragment 3 = 3rd fragment … 96 = 96th fragment (last possible) Robert Moskowitz, Verizon Page 14

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

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

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

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

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

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

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

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

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

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

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

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

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

KMP Guidelines KMP Sections General KMP description Use case(s) Sub sections as needed, e.g. backend authentication mechanism Use case(s) 802.15 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

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. 802.1X does not supply link keys. In 802.11 usage, this is done via the 4- Way Handshake Special attention to broadcast keying management Others? Robert Moskowitz, Verizon Page 29

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

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

Next Steps Robert Moskowitz, Verizon Page 32

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