idnits 2.17.1 draft-ohba-6tsch-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 10, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ZigBeeIP' is mentioned on line 468, but not defined == Missing Reference: 'IEEE802154e' is mentioned on line 456, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 462, but not defined == Unused Reference: 'RFC2119' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-palattella-6tsch-terminology' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-thubert-6tsch-architecture' is defined on line 448, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-12 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 -- Duplicate reference: draft-palattella-6tsch-terminology, mentioned in 'I-D.draft-palattella-6tsch-terminology', was also mentioned in 'I-D.palattella-6tsch-terminology'. == Outdated reference: A later version (-02) exists of draft-thubert-6tsch-architecture-00 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH S. Chasko 3 Internet-Draft L+G 4 Intended status: Informational S. Das 5 Expires: January 11, 2014 ACS 6 R. Marin-Lopez 7 University of Murcia 8 Y. Ohba, Ed. 9 Toshiba 10 P. Thubert 11 cisco 12 A. Yegin 13 Samsung 14 July 10, 2013 16 Security Framework and Key Management Protocol Requirements for 6TSCH 17 draft-ohba-6tsch-security-01 19 Abstract 21 Since 6TSCH forms layer 3 meshes over IPv6, use of key management 22 protocols defined at layer 3 or above matches the target architecture 23 so they can apply for the process by a new device of joining the mesh 24 to extend it. This document details that particular operation within 25 the whole 6TSCH architecture. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 11, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Security Framework . . . . . . . . . . . . . . . . . . . . . 4 64 4. KMP requirements . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Phase-1 KMP requirements . . . . . . . . . . . . . . . . 7 66 4.2. Phase-2 KMP requirements . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . 10 73 8.3. External Informative References . . . . . . . . . . . . . 10 74 Appendix A. KMP candidates . . . . . . . . . . . . . . . . . . . 11 75 A.1. Phase-1 KMP candidates . . . . . . . . . . . . . . . . . 11 76 A.2. Phase-2 KMP candidates . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 The emergence of radio technology enabled a large variety of new 82 types of devices to be interconnected, at a very low marginal cost 83 compared to wire, at any range from Near Field to interplanetary 84 distances, and in circumstances where wiring could be less than 85 practical, for instance rotating devices. 87 At the same time, a new breed of Time Sensitive Networks is being 88 developed to enable traffic that is highly sensitive to jitter and 89 quite sensitive to latency. Such traffic is not limited to voice and 90 video, but also includes command and control operations such as found 91 in industrial automation or in-vehicular sensors and actuators. 93 6TSCH aims at providing an open standard with new capabilities, both 94 in terms of scalability (number of IPv6 devices in a single subnet) 95 and in terms of guarantees (delivery and timeliness). Both the 96 ISA100.11a and Wireless HART protocols are gaining acceptance in the 97 automation industry and demonstrate that a level of determinism can 98 be achieved on a wireless medium with adequate guarantees for low 99 speed control loops, used in mission critical Process Control 100 applications. For industrial applications, security is not an option 101 and a power efficient authentication mechanism is strictly required. 103 For other usages such as rust control, intrusion detection or seismic 104 activity monitoring, the capability to correlate inputs from multiple 105 sources can be critical, and the value of the network directly 106 augments with the number of connected devices. In order to scale to 107 appropriate levels, the need for spatial reuse of the spectrum often 108 implies routing capabilities over short range radios. Proprietary 109 variations demonstrate that RPL can scale to multiple thousands of 110 devices, but at the same time expose a new challenge for security 111 that must enable deployments of any scale with security requirements 112 that may vary widely. If the cost of the security in terms of 113 network operations and system resources depends on that degree of 114 security, then 6TSCH should enable different profiles that can match 115 different requirements and capabilities. 117 Since 6TSCH forms layer 3 meshes over IPv6, key management protocols 118 defined at layer 3 or above can apply for the process by a new device 119 of joining the mesh to extend it. This document details that 120 particular operation within the whole 6TSCH architecture. 122 ZigBee IP [ZigBeeIP] ("ZigBee" is a registered trademark of the 123 ZigBee Alliance) is a standard for IPv6-based wireless mesh networks 124 using PANA for network access authentication and secure distribution 125 of a link-layer group key called Network Key to authenticated mesh 126 nodes formed over unslotted CSMA-CA MAC of 802.15.4. Each mesh node 127 in the same ZigBee IP network derives the same link-layer key from 128 the Network Key to protect IEEE 802.15.4 MAC frames exchanged between 129 adjacent mesh nodes. While sharing the same link-layer key among all 130 mesh nodes can make the required key state maintained by each mesh 131 node compact, a compromise of a mesh node can lead to link-layer key 132 leakage in the entire ZigBee IP network. Also, the cost of updating 133 the link-layer key can be high as the key needs to be updated at all 134 mesh nodes whenever the 4-octet frame counter at any single node 135 wraps or the key is considered to be compromised or weak. 137 In the case of TSCH MAC which uses 5-octet global frame counter 138 referred to as Absolute Slot Number (ASN), the frame counter is not 139 likely to wrap in the expected lifetime of the device, but key update 140 for a common link-layer key is still issue if the key needs to be 141 changed for other reasons. 143 This document introduces a more secure and scalable key management 144 framework for 6TSCH networks and identifies requirements for key 145 management protocols to be used in the framework. 147 2. Acronyms 149 In addition to the acronyms defined in 150 [I-D.palattella-6tsch-terminology], the following acronyms are used 151 in this document. 153 KMP: Key Management Protocol 155 PANA: Protocol for carrying Authentication for Network Access 157 SA: Security Association 159 MAC: Media Access Control 161 3. Security Framework 163 This section describes a security framework consisting of four phases 164 as shown in Figure 1. The architecture is applicable to not only 165 6TSCH networks but also non-time synchronized mesh networks. Each 166 node in a mesh network runs through the following phases: 168 o Phase-0 (Implanting Phase): In this phase, a node installs 169 credentials used for subsequent phases in a physically secure and 170 managed location before the node is placed to where it is expected 171 to operate. Details on Phase-0 is outside the scope of this 172 document. 174 o Phase-1 (Bootstrapping Phase): In this phase, a node (re)installs 175 credentials used for subsequent phases from an authentication 176 server after it is placed to where it is expected to operate. The 177 credentials installed during Phase-1 include Phase-2 credentials 178 and Phase-3 credentials, and may also include long-term Phase-1 179 credentials if the initial Phase-1 credentials are intended for 180 one-time use such as a temporary PIN. An authentication and key 181 establishment protocol called a Phase-1 KMP is conducted between 182 the node and the authentication server using Phase-1 credentials. 183 The Phase-1 credentials have longer lifetime than Phase-2 and 184 Phase-3 credentials so that Phase-2 and Phase-3 credentials can be 185 renewed using the Phase-1 credentials. Both symmetric and 186 asymmetric key credentials can be used as Phase-1 credentials. In 187 Phase-1 KMP, the Phase-2 and Phase-3 credentials are distributed 188 from the authentication server to the node. When the 189 authentication server is multiple hops away from the node, mutual 190 authentication between the node and the authentication server is 191 conducted via a neighboring node acting as an authentication 192 relay. There may be no link-layer security available between the 193 node and its neighboring node in this phase. An authentication 194 server is typically (but is not necessarily) co-located with the 195 coordinator of the mesh network. Phase-1 is optional if Phase-2 196 credentials are installed during Phase-0 and do not need to be 197 updated. 199 o Phase-2 (Link Establishment Phase): In this phase, the node 200 performs mutual authentication with its neighboring node using the 201 Phase-2 credentials to establish SAs between adjacent nodes for 202 protecting 802.15.4 MAC frames. The authentication and key 203 establishment protocol used in this phase is referred as a Phase-2 204 KMP or a link establishment KMP. For highly scalable mesh 205 networks consisting of thousands of mesh nodes, certificates are 206 used as the Phase-2 credentials. The SA of a link between node i 207 and node j maintains link-layer keys, i.e., 128-bit keys used in 208 AES-CCM* mode, a variant of the Counter with Cipher Block Chaining 209 - Message Authentication Code (CBC-MAC) Mode, for encryption, 210 authentication or authenticated encryption of 802.15.4 frames. 211 K_i denotes a link-layer key for protecting broadcast MAC frames 212 originated at node i. K_ij denotes a link-layer key for 213 protecting unicast MAC frames originated at node i and destined 214 for node j. There are several variations of forming link-layer 215 keys. 217 1. K_ij=K_i for all j, K_i!=K_j for all i, j (i!=j) 219 2. K_ij=K_ji, K_i!=K_j for all i,j (i!=j) 221 3. K_ij!=K_ji, K_i!=K_j for all i,j (i!=j) 223 In model 1, unicast and broadcast keys for protecting MAC frames 224 originated at a given node are the same. In models 2 and 3, 225 unicast and broadcast keys originated at a given node are 226 distinct. The difference between models 2 and 3 is that unicast 227 keys are bi-directional in model 2 while they are uni-directional 228 in model 3. One model may be chosen among three depending on the 229 required security level and the number of keys maintained by each 230 node. 232 o Phase-3 (Operational Phase): In this phase, the node is able to 233 run various higher-layer protocols over IP over an established 234 secure link. Additional authentication and key establishment may 235 take place for the higher-layer protocols using Phase-3 236 credentials. A node in Phase-3 is able to process Phase-1 and 237 Phase-2 KMPs. Example use cases are: 239 * A Phase-3 node can initiate a Phase-1 KMP to update its Phase-2 240 or Phase-3 credentials. 242 * A Phase-3 node can forward Phase-1 KMP messages originated from 243 or destined for a Phase-1 node that is joining the mesh network 244 through the Phase-3 node. 246 * A Phase-3 node can initiate a Phase 2 KMP to establish a new 247 link with a newly discovered neighbor node. 249 +---------------------------------+ 250 | Phase-0 (Implanting) | 251 +---------------------------------+ 252 | 253 v 254 +---------------------------------+ 255 | Phase-1 (Bootstrapping) | 256 +---------------------------------+ 257 | 258 v 259 +---------------------------------+ 260 | Phase-2 (Link Establishment) | 261 +---------------------------------+ 262 | 263 v 264 +---------------------------------+ 265 | Phase-3 (Operational) | 266 +---------------------------------+ 268 Figure 1: 4-Phase Key Management Model 270 N)s - Node N is running Phase-1 KMP as a server 271 N)c - Node N is running Phase-1 KMP as a client 272 N)r - Node N is running Phase-1 KMP as a relay 273 N)) - Node N is running Phase-2 KMP 274 . .. ... 275 N, N, N - Node N is in Phase-1, -2 and -3, respectively 277 . . .. ... ... ... 278 A A)s A)) A)s A A 279 / \ / \ / \ / \ / \ 280 . . . . .. .. ... ... ... ... ... ... 281 B C B)c C)c B)) C)) B)r C B)) C)) B C 282 / \ / / \ / / \ / 283 . . . . . . . . .. .. ... ... 284 D E D E D E D)c E)c D)) E)) D E 286 (0) -> (1) -> (2) -> (3) -> (4) -> (5) 288 (0) Initially all nodes are in Phase-1. (1) Nodes B and C run 289 Phase-1 KMP with Node A (i.e., the authentication server) to obtain 290 Phase-2 and Phase-3 credentials. (2) Nodes B and C run Phase-2 KMP 291 with Node A. (3) Nodes D and E run Phase-1 KMP using Node B as an 292 authentication relay. (Alternatively, Node E may use Node C as an 293 authentication relay.) (4) Node D runs Phase-2 KMP with Node B. Node 294 E runs Phase-2 KMP with Nodes B and C. (5) All nodes are 295 operational. 297 Figure 2: Example Sequence 299 Since we already identified PANA as the Phase-1 KMP due to its 300 authentication relay and secure credential distribution capabilities, 301 and Phase-3 KMP requirements would depend on application protocols, 302 we focus on Phase-2 KMP requirements in the next section. 304 4. KMP requirements 306 4.1. Phase-1 KMP requirements 308 Requirements on Phase-1 KMP are listed below. 310 R1-1: Phase-1 KMP MUST support mutual authentication. 312 R1-2: Phase-1 KMP MUST support stateless authentication relay 313 operation. 315 R1-3:s Phase-1 KMP MUST support secure credential distribution. 317 4.2. Phase-2 KMP requirements 319 Requirements on Phase-2 KMP are listed below. 321 R2-1: Phase-2 KMP Nodes MUST mutually authenticate each other before 322 establishing a link and forming a mesh network. No authentication 323 server is involved in the Phase-2 authentication. 325 R2-2: Phase-2 KMP authentication credentials MAY be pre-provisioned 326 or MAY be obtained via Phase-1 KMP. 328 R2-3: Phase-2 KMP authentication credentials MUST have a lifetime. 330 R2-4: Phase-2 KMP MUST support certificates for scalable operation. 332 R2-5: Phase-2 KMP message exchanges MUST be integrity and replay 333 protected after successful authentication. 335 R2-6: Phase-2 KMP MUST have the capability to establish security 336 association and unicast session keys after successful authentication 337 to protect unicast MAC frames between nodes. 339 R2-7: Phase-2 KMP MUST have the capability to establish security 340 association and broadcast session keys after successful 341 authentication to protect broadcast MAC frames between nodes. 343 R2-8: Phase-2 KMP MUST support confidentiality to distribute the 344 broadcast session keys securely. 346 5. Security Considerations 348 In this section, security issues that can potentially impact the 349 operation of IEEE 802.15.4e TSCH MAC are described. 351 In TSCH MAC, time synchronization and channel hopping information are 352 advertised in Enhanced Beacon (EB) frames 353 [I-D.watteyne-6tsch-tsch-lln-context]. The advertised information is 354 used by mesh nodes to determine the timeslots available for 355 transmission and reception of MAC frames. A rogue node can inject 356 forged EB frames and can cause replay and DoS attacks to TSCH MAC 357 operation. To mitigate such attacks, all EB frames MUST be integrity 358 protected. While it is possible to use a pre-installed static key 359 for protecting EB frames to every node, the static key becomes 360 vulnerable when the associated MAC frame counter continues to be used 361 after the frame counter wraps. Therefore, the 6TSCH solution MUST 362 provide a mechanism by which mesh nodes can use the available time 363 slots to run Phase-1 and Phase-2 KMPs and provide integrity 364 protection to EB frames. 366 6. IANA Considerations 368 There is no IANA action required for this document. 370 7. Acknowledgments 372 We would like to thank Thomas Watteyne, Jonathan Simon, Maria Rita 373 Palattella and Rene Struik for their valuable comments. 375 8. References 377 8.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 383 Yegin, "Protocol for Carrying Authentication for Network 384 Access (PANA)", RFC 5191, May 2008. 386 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 387 Yegin, "Protocol for Carrying Authentication for Network 388 Access (PANA) Relay Element", RFC 6345, August 2011. 390 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 391 Security Version 1.2", RFC 6347, January 2012. 393 [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for 394 Carrying Authentication for Network Access (PANA) 395 Attribute-Value Pairs", RFC 6786, November 2012. 397 [I-D.palattella-6tsch-terminology] 398 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 399 "Terminology in IPv6 over Time Slotted Channel Hopping", 400 draft-palattella-6tsch-terminology-00 (work in progress), 401 March 2013. 403 [I-D.watteyne-6tsch-tsch-lln-context] 404 Watteyne, T., Palattella, M., and L. Grieco, "Using 405 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 406 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 407 context-02 (work in progress), May 2013. 409 [I-D.moskowitz-hip-rg-dex] 410 Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- 411 hip-rg-dex-06 (work in progress), May 2012. 413 8.2. Informative References 415 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 416 "State Machines for Extensible Authentication Protocol 417 (EAP) Peer and Authenticator", RFC 4137, August 2005. 419 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 420 "Transmission of IPv6 Packets over IEEE 802.15.4 421 Networks", RFC 4944, September 2007. 423 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 424 Layer Security (TLS)", RFC 5705, March 2010. 426 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 427 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 428 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 429 Lossy Networks", RFC 6550, March 2012. 431 [I-D.keoh-tls-multicast-security] 432 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 433 Security for Low-Power and Lossy Networks (LLNs)", draft- 434 keoh-tls-multicast-security-00 (work in progress), October 435 2012. 437 [I-D.ietf-hip-rfc5201-bis] 438 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 439 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 440 hip-rfc5201-bis-12 (work in progress), June 2013. 442 [I-D.draft-palattella-6tsch-terminology] 443 Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. 444 Wang, "Terminology in IPv6 over Time Slotted Channel 445 Hopping. draft-palattella-6tsch-terminology-00 (work in 446 progress) ", March 2013. 448 [I-D.draft-thubert-6tsch-architecture] 449 Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An 450 Architecture for IPv6 over Time Synchronized Channel 451 Hopping. draft-thubert-6tsch-architecture-00 (work in 452 progress) ", March 2013. 454 8.3. External Informative References 456 [IEEE802154e] 457 IEEE standard for Information Technology, "IEEE std. 458 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 459 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 460 2012. 462 [IEEE802154] 463 IEEE standard for Information Technology, "IEEE std. 464 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 465 and Physical Layer (PHY) Specifications for Low-Rate 466 Wireless Personal Area Networks", June 2011. 468 [ZigBeeIP] 469 ZigBee Public Document 15-002r00, "ZigBee IP 470 Specification", 2013. 472 Appendix A. KMP candidates 474 A.1. Phase-1 KMP candidates 476 PANA [RFC5191] is the Phase-1 KMP candidate since it supports mutual 477 authentication, stateless authentication relay function [RFC6345] and 478 encrypted distribution of attributes [RFC6786]. The PANA 479 Authentication Agent (PAA) is located in the coordinator of the mesh 480 network. 482 A.2. Phase-2 KMP candidates 484 Once Phase-1 is complete by using PANA, it is assumed that node will 485 have a certified public key (and associated private key). A 486 candidate Phase 2 KMP must use this certified public key to perform 487 an authentication process. As a consequence of a successful 488 authentication some cryptographic material for unicast and multicast 489 link protection between nodes must be generated. 491 A list of candidate protocols may provide the requirements defined in 492 Section 4.2 (this is a preliminary list that may be extended in the 493 future): 495 o HIP DEX [I-D.moskowitz-hip-rg-dex]. The Host Identity Protocol 496 Diet EXchange (HIP DEX) is a lighter version of the HIP Base 497 Exchange (HIP BEX) [I-D.ietf-hip-rfc5201-bis] specifically 498 designed to be used in constrained devices (e.g., sensor 499 networks). In particular, HIP DEX may be used to authenticate two 500 IEEE 802.15.4 nodes and provide key material for a MAC layer 501 security protocol as supported in IEEE 802.15.4. However, by just 502 using the value of the public key and the private key is not 503 enough to carry out the authentication between nodes. In 504 particular, a node A and node B should not be able to successfully 505 finish HIP DEX execution if they both have not been authenticated 506 in Phase-1. Thus, HIP DEX will require the inclusion of the 507 certificate of each node to achieve full mutual authentication. 508 The information in the certificate must ensure that the node was 509 authenticated in Phase-1. In consequence, HIP DEX must include a 510 CERT parameter for carrying this certificate. Once the HIP DEX 511 protocol has successfully finished a Pair-Wise Key SA is derived. 512 This SA is used to secure and authenticate user data, thus it can 513 be used to provide the required keys for protecting IEEE 802.15.4 514 unicast MAC frames. The same message is used to refresh the Pair- 515 Wise Key SA. So far HIP DEX only specifies how this key material 516 is used for protecting data traffic with ESP. To distribute 517 multicast keys HIP DEX may also use UPDATE message. For less 518 resource-constrained devices, HIP-BEX (Basic Exchange) is more 519 suitable than HIP-DEX since HIP-BEX has better security properties 520 (such as use of ephemeral Diffie-Hellman) than HIP-DEX at the cost 521 of increased complexity. 523 o PANA [RFC5191] and some certificate-based EAP method. Another 524 candidate is to use PANA between node A and node B. In this case, 525 one of the nodes (e.g. node A) acts as PaC while the other (e.g. 526 node B) is acting as PAA. Moreover the PAA will operate in 527 standalone mode [RFC4137]. That is, the EAP server is placed on 528 the PAA and not in a backend authentication server. Finally, the 529 selected EAP method must work with public key/private key 530 cryptography. Once the PAA authentication is complete, the PaC 531 and PAA can derive cryptographic material (for instance, from the 532 MSK) which can be used to protect unicast MAC frames. 533 Furthermore, by using the extension defined in [RFC6345] is 534 possible to distribute a multicast key encrypted with the PANA SA. 535 It is worth noting that, though this candidate solution leverages 536 the PaC implementation from Phase-1, each node needs to deploy a 537 PAA implementation, an EAP server and a specific EAP method, which 538 may be different from the one used for Phase-1. 540 o DTLS [RFC6347]. Datagram Transport Layer Security (DTLS) is being 541 considered in constrained devices for protecting application data 542 traffic (e.g. CoAP). It is not only being considered for unicast 543 application data traffic but also for multicast data traffic 544 [I-D.keoh-tls-multicast-security]. In particular, a multicast key 545 is distributed over an unicast DTLS channel established between 546 two nodes (node A and node B). This multicast key is used to 547 protect multicast traffic by using TLS records. The Phase2-KMP 548 should be able to export this key material to the IEEE 802.15.4 549 MAC layer so that the protection is carried out at link layer. In 550 [RFC5705], a mechanism for exporting key material after a TLS/DTLS 551 execution is defined. Nevertheless, the exported key material is 552 intended to be used in unicast communications for upper layers or 553 protocols at upper layers. However, a mechanism for exporting 554 multicast key is not specified. In principle, this exported key 555 material may be used for protecting unicast IEEE 802.15.4 MAC 556 frames. However, this usage and multicast key management using 557 DTLS for multicast IEEE 802.15.4 protection need further 558 investigation. 560 Authors' Addresses 562 Stephen Chasko 563 Landis+Gyr 564 3000 Mill Creek Ave. 565 Alpharetta, GA 30022 566 USA 568 Email: Stephen.Chasko@landisgyr.com 570 Subir Das 571 Applied Communication Sciences 572 1 Telcordia Drive 573 Piscataway, NJ 08854 574 USA 576 Email: sdas@appcomsci.com 578 Rafa Marin-Lopez 579 University of Murcia 580 Campus de Espinardo S/N, Faculty of Computer Science 581 Murcia 30100 582 Spain 584 Phone: +34 868 88 85 01 585 Email: rafa@um.es 586 Yoshihiro Ohba (editor) 587 Toshiba Corporate Research and Development Center 588 1 Komukai-Toshiba-cho 589 Saiwai-ku, Kawasaki, Kanagawa 212-8582 590 Japan 592 Phone: +81 44 549 2127 593 Email: yoshihiro.ohba@toshiba.co.jp 595 Pascal Thubert 596 Cisco Systems, Inc 597 Village d'Entreprises Green Side 598 400, Avenue de Roumanille 599 Batiment T3 600 Biot - Sophia Antipolis 06410 601 FRANCE 603 Phone: +33 497 23 26 34 604 Email: pthubert@cisco.com 606 Alper Yegin 607 Samsung 608 Istanbul 609 Turkey 611 Email: alper.yegin@yegin.org