idnits 2.17.00 (12 Aug 2021) /tmp/idnits44366/draft-ohba-6tisch-security-00.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 (October 21, 2013) is 3134 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ZigBeeIP' is mentioned on line 470, but not defined == Missing Reference: 'IEEE802154e' is mentioned on line 458, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 464, but not defined == Unused Reference: 'RFC2119' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-palattella-6tisch-terminology' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-thubert-6tisch-architecture' is defined on line 450, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-hip-rfc5201-bis has been published as RFC 7401 -- Duplicate reference: draft-palattella-6tisch-terminology, mentioned in 'I-D.draft-palattella-6tisch-terminology', was also mentioned in 'I-D.palattella-6tisch-terminology'. == Outdated reference: A later version (-01) exists of draft-thubert-6tisch-architecture-00 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH S. Chasko 3 Internet-Draft L+G 4 Intended status: Informational S. Das 5 Expires: April 24, 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 October 21, 2013 16 Security Framework and Key Management Protocol Requirements for 6TiSCH 17 draft-ohba-6tisch-security-00 19 Abstract 21 Since 6TiSCH 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 6TiSCH 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 April 24, 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 6TiSCH 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 6TiSCH should enable different profiles that can match 115 different requirements and capabilities. 117 Since 6TiSCH 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 6TiSCH 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 6TiSCH 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-6tisch-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 6TiSCH 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 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. K_i and K_j may or may 225 not be the same in model 1, and when K_i=K_j=K forall i and j, 226 then such K is considered as a common network key. In models 2 227 and 3, unicast and broadcast keys originated at a given node are 228 distinct. The difference between models 2 and 3 is that unicast 229 keys are bi-directional in model 2 while they are uni-directional 230 in model 3. One model may be chosen among three depending on the 231 required security level and the number of keys maintained by each 232 node. 234 o Phase-3 (Operational Phase): In this phase, the node is able to 235 run various higher-layer protocols over IP over an established 236 secure link. Additional authentication and key establishment may 237 take place for the higher-layer protocols using Phase-3 238 credentials. A node in Phase-3 is able to process Phase-1 and 239 Phase-2 KMPs. Example use cases are: 241 * A Phase-3 node can initiate a Phase-1 KMP to update its Phase-2 242 or Phase-3 credentials. 244 * A Phase-3 node can forward Phase-1 KMP messages originated from 245 or destined for a Phase-1 node that is joining the mesh network 246 through the Phase-3 node. 248 * A Phase-3 node can initiate a Phase 2 KMP to establish a new 249 link with a newly discovered neighbor node. 251 +---------------------------------+ 252 | Phase-0 (Implanting) | 253 +---------------------------------+ 254 | 255 v 256 +---------------------------------+ 257 | Phase-1 (Bootstrapping) | 258 +---------------------------------+ 259 | 260 v 261 +---------------------------------+ 262 | Phase-2 (Link Establishment) | 263 +---------------------------------+ 264 | 265 v 266 +---------------------------------+ 267 | Phase-3 (Operational) | 268 +---------------------------------+ 270 Figure 1: 4-Phase Key Management Model 272 N)s - Node N is running Phase-1 KMP as a server 273 N)c - Node N is running Phase-1 KMP as a client 274 N)r - Node N is running Phase-1 KMP as a relay 275 N)) - Node N is running Phase-2 KMP 276 . .. ... 277 N, N, N - Node N is in Phase-1, -2 and -3, respectively 279 . . .. ... ... ... 280 A A)s A)) A)s A A 281 / \ / \ / \ / \ / \ 282 . . . . .. .. ... ... ... ... ... ... 283 B C B)c C)c B)) C)) B)r C B)) C)) B C 284 / \ / / \ / / \ / 285 . . . . . . . . .. .. ... ... 286 D E D E D E D)c E)c D)) E)) D E 288 (0) -> (1) -> (2) -> (3) -> (4) -> (5) 290 (0) Initially all nodes are in Phase-1. (1) Nodes B and C run 291 Phase-1 KMP with Node A (i.e., the authentication server) to obtain 292 Phase-2 and Phase-3 credentials. (2) Nodes B and C run Phase-2 KMP 293 with Node A. (3) Nodes D and E run Phase-1 KMP using Node B as an 294 authentication relay. (Alternatively, Node E may use Node C as an 295 authentication relay.) (4) Node D runs Phase-2 KMP with Node B. Node 296 E runs Phase-2 KMP with Nodes B and C. (5) All nodes are 297 operational. 299 Figure 2: Example Sequence 301 Since we already identified PANA as the Phase-1 KMP due to its 302 authentication relay and secure credential distribution capabilities, 303 and Phase-3 KMP requirements would depend on application protocols, 304 we focus on Phase-2 KMP requirements in the next section. 306 4. KMP requirements 308 4.1. Phase-1 KMP requirements 310 Requirements on Phase-1 KMP are listed below. 312 R1-1: Phase-1 KMP MUST support mutual authentication. 314 R1-2: Phase-1 KMP MUST support stateless authentication relay 315 operation. 317 R1-3:s Phase-1 KMP MUST support secure credential distribution. 319 4.2. Phase-2 KMP requirements 321 Requirements on Phase-2 KMP are listed below. 323 R2-1: Phase-2 KMP Nodes MUST mutually authenticate each other before 324 establishing a link and forming a mesh network. No authentication 325 server is involved in the Phase-2 authentication. 327 R2-2: Phase-2 KMP authentication credentials MAY be pre-provisioned 328 or MAY be obtained via Phase-1 KMP. 330 R2-3: Phase-2 KMP authentication credentials MUST have a lifetime. 332 R2-4: Phase-2 KMP MUST support certificates for scalable operation. 334 R2-5: Phase-2 KMP message exchanges MUST be integrity and replay 335 protected after successful authentication. 337 R2-6: Phase-2 KMP MUST have the capability to establish security 338 association and unicast session keys after successful authentication 339 to protect unicast MAC frames between nodes. 341 R2-7: Phase-2 KMP MUST have the capability to establish security 342 association and broadcast session keys after successful 343 authentication to protect broadcast MAC frames between nodes. 345 R2-8: Phase-2 KMP MUST support confidentiality to distribute the 346 broadcast session keys securely. 348 5. Security Considerations 350 In this section, security issues that can potentially impact the 351 operation of IEEE 802.15.4e TSCH MAC are described. 353 In TSCH MAC, time synchronization and channel hopping information are 354 advertised in Enhanced Beacon (EB) frames 355 [I-D.watteyne-6tsch-tsch-lln-context]. The advertised information is 356 used by mesh nodes to determine the timeslots available for 357 transmission and reception of MAC frames. A rogue node can inject 358 forged EB frames and can cause replay and DoS attacks to TSCH MAC 359 operation. To mitigate such attacks, all EB frames MUST be integrity 360 protected. While it is possible to use a pre-installed static key 361 for protecting EB frames to every node, the static key becomes 362 vulnerable when the associated MAC frame counter continues to be used 363 after the frame counter wraps. Therefore, the 6TiSCH solution MUST 364 provide a mechanism by which mesh nodes can use the available time 365 slots to run Phase-1 and Phase-2 KMPs and provide integrity 366 protection to EB frames. 368 6. IANA Considerations 370 There is no IANA action required for this document. 372 7. Acknowledgments 374 We would like to thank Thomas Watteyne, Jonathan Simon, Maria Rita 375 Palattella and Rene Struik for their valuable comments. 377 8. References 379 8.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 385 Yegin, "Protocol for Carrying Authentication for Network 386 Access (PANA)", RFC 5191, May 2008. 388 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 389 Yegin, "Protocol for Carrying Authentication for Network 390 Access (PANA) Relay Element", RFC 6345, August 2011. 392 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 393 Security Version 1.2", RFC 6347, January 2012. 395 [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for 396 Carrying Authentication for Network Access (PANA) 397 Attribute-Value Pairs", RFC 6786, November 2012. 399 [I-D.palattella-6tisch-terminology] 400 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 401 "Terminology in IPv6 over the TSCH mode of IEEE 402 802.15.4e", draft-palattella-6tisch-terminology-00 (work 403 in progress), October 2013. 405 [I-D.watteyne-6tsch-tsch-lln-context] 406 Watteyne, T., Palattella, M., and L. Grieco, "Using 407 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 408 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 409 context-02 (work in progress), May 2013. 411 [I-D.moskowitz-hip-rg-dex] 412 Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- 413 hip-rg-dex-06 (work in progress), May 2012. 415 8.2. Informative References 417 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 418 "State Machines for Extensible Authentication Protocol 419 (EAP) Peer and Authenticator", RFC 4137, August 2005. 421 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 422 "Transmission of IPv6 Packets over IEEE 802.15.4 423 Networks", RFC 4944, September 2007. 425 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 426 Layer Security (TLS)", RFC 5705, March 2010. 428 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 429 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 430 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 431 Lossy Networks", RFC 6550, March 2012. 433 [I-D.keoh-tls-multicast-security] 434 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 435 Security for Low-Power and Lossy Networks (LLNs)", draft- 436 keoh-tls-multicast-security-00 (work in progress), October 437 2012. 439 [I-D.ietf-hip-rfc5201-bis] 440 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 441 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 442 hip-rfc5201-bis-14 (work in progress), October 2013. 444 [I-D.draft-palattella-6tisch-terminology] 445 Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. 446 Wang, "Terminology in IPv6 over Time Slotted Channel 447 Hopping. draft-palattella-6tisch-terminology-00 (work in 448 progress) ", March 2013. 450 [I-D.draft-thubert-6tisch-architecture] 451 Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An 452 Architecture for IPv6 over Time Synchronized Channel 453 Hopping. draft-thubert-6tisch-architecture-00 (work in 454 progress) ", March 2013. 456 8.3. External Informative References 458 [IEEE802154e] 459 IEEE standard for Information Technology, "IEEE std. 460 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 461 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 462 2012. 464 [IEEE802154] 465 IEEE standard for Information Technology, "IEEE std. 466 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 467 and Physical Layer (PHY) Specifications for Low-Rate 468 Wireless Personal Area Networks", June 2011. 470 [ZigBeeIP] 471 ZigBee Public Document 15-002r00, "ZigBee IP 472 Specification", 2013. 474 Appendix A. KMP candidates 476 A.1. Phase-1 KMP candidates 478 PANA [RFC5191] is the Phase-1 KMP candidate since it supports mutual 479 authentication, stateless authentication relay function [RFC6345] and 480 encrypted distribution of attributes [RFC6786]. The PANA 481 Authentication Agent (PAA) is located in the coordinator of the mesh 482 network. 484 A.2. Phase-2 KMP candidates 486 Once Phase-1 is complete by using PANA, it is assumed that node will 487 have a certified public key (and associated private key). A 488 candidate Phase 2 KMP must use this certified public key to perform 489 an authentication process. As a consequence of a successful 490 authentication some cryptographic material for unicast and multicast 491 link protection between nodes must be generated. 493 A list of candidate protocols may provide the requirements defined in 494 Section 4.2 (this is a preliminary list that may be extended in the 495 future): 497 o HIP DEX [I-D.moskowitz-hip-rg-dex]. The Host Identity Protocol 498 Diet EXchange (HIP DEX) is a lighter version of the HIP Base 499 Exchange (HIP BEX) [I-D.ietf-hip-rfc5201-bis] specifically 500 designed to be used in constrained devices (e.g., sensor 501 networks). In particular, HIP DEX may be used to authenticate two 502 IEEE 802.15.4 nodes and provide key material for a MAC layer 503 security protocol as supported in IEEE 802.15.4. However, by just 504 using the value of the public key and the private key is not 505 enough to carry out the authentication between nodes. In 506 particular, a node A and node B should not be able to successfully 507 finish HIP DEX execution if they both have not been authenticated 508 in Phase-1. Thus, HIP DEX will require the inclusion of the 509 certificate of each node to achieve full mutual authentication. 510 The information in the certificate must ensure that the node was 511 authenticated in Phase-1. In consequence, HIP DEX must include a 512 CERT parameter for carrying this certificate. Once the HIP DEX 513 protocol has successfully finished a Pair-Wise Key SA is derived. 514 This SA is used to secure and authenticate user data, thus it can 515 be used to provide the required keys for protecting IEEE 802.15.4 516 unicast MAC frames. The same message is used to refresh the Pair- 517 Wise Key SA. So far HIP DEX only specifies how this key material 518 is used for protecting data traffic with ESP. To distribute 519 multicast keys HIP DEX may also use UPDATE message. For less 520 resource-constrained devices, HIP-BEX (Basic Exchange) is more 521 suitable than HIP-DEX since HIP-BEX has better security properties 522 (such as use of ephemeral Diffie-Hellman) than HIP-DEX at the cost 523 of increased complexity. 525 o PANA [RFC5191] and some certificate-based EAP method. Another 526 candidate is to use PANA between node A and node B. In this case, 527 one of the nodes (e.g. node A) acts as PaC while the other (e.g. 528 node B) is acting as PAA. Moreover the PAA will operate in 529 standalone mode [RFC4137]. That is, the EAP server is placed on 530 the PAA and not in a backend authentication server. Finally, the 531 selected EAP method must work with public key/private key 532 cryptography. Once the PAA authentication is complete, the PaC 533 and PAA can derive cryptographic material (for instance, from the 534 MSK) which can be used to protect unicast MAC frames. 535 Furthermore, by using the extension defined in [RFC6345] is 536 possible to distribute a multicast key encrypted with the PANA SA. 537 It is worth noting that, though this candidate solution leverages 538 the PaC implementation from Phase-1, each node needs to deploy a 539 PAA implementation, an EAP server and a specific EAP method, which 540 may be different from the one used for Phase-1. 542 o DTLS [RFC6347]. Datagram Transport Layer Security (DTLS) is being 543 considered in constrained devices for protecting application data 544 traffic (e.g. CoAP). It is not only being considered for unicast 545 application data traffic but also for multicast data traffic 546 [I-D.keoh-tls-multicast-security]. In particular, a multicast key 547 is distributed over an unicast DTLS channel established between 548 two nodes (node A and node B). This multicast key is used to 549 protect multicast traffic by using TLS records. The Phase2-KMP 550 should be able to export this key material to the IEEE 802.15.4 551 MAC layer so that the protection is carried out at link layer. In 552 [RFC5705], a mechanism for exporting key material after a TLS/DTLS 553 execution is defined. Nevertheless, the exported key material is 554 intended to be used in unicast communications for upper layers or 555 protocols at upper layers. However, a mechanism for exporting 556 multicast key is not specified. In principle, this exported key 557 material may be used for protecting unicast IEEE 802.15.4 MAC 558 frames. However, this usage and multicast key management using 559 DTLS for multicast IEEE 802.15.4 protection need further 560 investigation. 562 Authors' Addresses 564 Stephen Chasko 565 Landis+Gyr 566 3000 Mill Creek Ave. 567 Alpharetta, GA 30022 568 USA 570 Email: Stephen.Chasko@landisgyr.com 572 Subir Das 573 Applied Communication Sciences 574 1 Telcordia Drive 575 Piscataway, NJ 08854 576 USA 578 Email: sdas@appcomsci.com 580 Rafa Marin-Lopez 581 University of Murcia 582 Campus de Espinardo S/N, Faculty of Computer Science 583 Murcia 30100 584 Spain 586 Phone: +34 868 88 85 01 587 Email: rafa@um.es 588 Yoshihiro Ohba (editor) 589 Toshiba Corporate Research and Development Center 590 1 Komukai-Toshiba-cho 591 Saiwai-ku, Kawasaki, Kanagawa 212-8582 592 Japan 594 Phone: +81 44 549 2127 595 Email: yoshihiro.ohba@toshiba.co.jp 597 Pascal Thubert 598 Cisco Systems, Inc 599 Village d'Entreprises Green Side 600 400, Avenue de Roumanille 601 Batiment T3 602 Biot - Sophia Antipolis 06410 603 FRANCE 605 Phone: +33 497 23 26 34 606 Email: pthubert@cisco.com 608 Alper Yegin 609 Samsung 610 Istanbul 611 Turkey 613 Email: alper.yegin@yegin.org