idnits 2.17.1 draft-keoh-dice-multicast-security-06.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 date (May 5, 2014) is 3642 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 575 -- Looks like a reference, but probably isn't: '8' on line 576 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-18 ** Downref: Normative reference to an Experimental draft: draft-ietf-core-groupcomm (ref. 'I-D.ietf-core-groupcomm') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-06) exists of draft-dijk-core-groupcomm-misc-05 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-01 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE Working Group S. Keoh 3 Internet-Draft University of Glasgow Singapore 4 Intended status: Standards Track S. Kumar, Ed. 5 Expires: November 6, 2014 O. Garcia-Morchon 6 E. Dijk 7 Philips Research 8 A. Rahman 9 InterDigital 10 May 5, 2014 12 DTLS-based Multicast Security in Constrained Environments 13 draft-keoh-dice-multicast-security-06 15 Abstract 17 The CoAP standard is fast emerging as a key protocol in the area of 18 resource-constrained devices. Such IP-based systems are foreseen to 19 be used for building and lighting control systems where devices 20 interconnect with each other, forming, for example, low-power and 21 lossy networks (LLNs). Both multicast and its security are key needs 22 in these networks. This draft presents a method for securing IPv6 23 multicast communication based on the DTLS which is already supported 24 for unicast communication for CoAP devices. This draft deals with 25 the adaptation of the DTLS record layer to protect multicast group 26 communication, assuming that all group members already have the group 27 security association parameters in their possession. The adapted 28 DTLS record layer provides message confidentiality, integrity and 29 replay protection to group messages using the group keying material 30 before sending the message via IPv6 multicast to the group. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 6, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Use Cases and Requirements . . . . . . . . . . . . . . . . . 5 70 2.1. Group Communication Use Cases . . . . . . . . . . . . . . 5 71 2.2. Security Requirements . . . . . . . . . . . . . . . . . . 6 72 3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . 8 73 3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2. Securing Multicast in Constrained Networks . . . . . . . 10 75 4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 11 76 4.1. SecurityParameter derivation . . . . . . . . . . . . . . 11 77 4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 12 78 4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 14 79 4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14 80 4.5. Unicast Responses to Multicast Messages . . . . . . . . . 15 81 4.6. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 16 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 6.1. Group level security . . . . . . . . . . . . . . . . . . 16 85 6.2. Late joiners . . . . . . . . . . . . . . . . . . . . . . 17 86 6.3. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 17 87 6.4. Reduced sequence number space . . . . . . . . . . . . . . 17 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 8.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 95 1. Introduction 97 There is an increased use of wireless control networks in 98 environmental monitoring, industrial automation, lighting controls 99 and building management systems. This is mainly driven by the fact 100 that the independence from physical control wires allows for freedom 101 of placement, portability and for reducing the cost of installation 102 as less cable placement and drilling are required. Consequently, 103 there is an ever growing number of electronic devices, sensors and 104 actuators that have become Internet connected, thus creating a trend 105 towards the Internet-of-Things (IoT). These connected devices are 106 equipped with communication capability that enables them to interact 107 with each other as well as with the wider Internet services. 108 However, the devices in such wireless control networks are 109 characterized by power constraints (as these are usually battery- 110 operated), have limited computational resources (low CPU clock, small 111 RAM and flash storage) and often, the communication bandwidth is 112 limited and unreliable (e.g., IEEE 802.15.4 radio). Hence, such 113 wireless control networks are also known as Low-power and Lossy 114 Networks (LLNs). 116 In addition to the usual device-to-device unicast communication that 117 allow devices to directly interact with each other, group 118 communication is an important feature in constrained environments. 119 It is more effective in constrained environments to convey messages 120 to a group of devices without requiring the sender to perform 121 multiple time and energy consuming unicast transmissions to reach 122 each individual group member. For example, in a building and 123 lighting control system, the heating, ventilation, air-conditioning 124 and lighting devices are often grouped according to the layout of the 125 building, and control commands are issued simultaneously to a group 126 of devices. Group communication is based on the Constrained 127 Application Protocol (CoAP) [I-D.ietf-core-coap] sent over IP- 128 multicast [I-D.ietf-core-groupcomm]. 130 Currently, CoAP messages are protected using Datagram Transport Layer 131 Security (DTLS) [RFC6347]. However, DTLS is currently used to secure 132 a connection between two endpoints and it cannot be used to protect 133 multicast group communication. Group communication in constrained 134 environments is equally important and should be secured as it is also 135 vulnerable to the usual attacks over the air (eavesdropping, 136 tampering, message forgery, replay, etc). There have been a lot of 137 previous efforts in IETF to standardize mechanisms to secure 138 multicast communication such as [RFC3830], [RFC4082], [RFC3740], 139 [RFC4046], and [RFC4535]. However, these approaches are not 140 necessarily suitable for constrained environments which have much 141 more limited bandwidth and resources. For example, the MIKEY 142 Architecture [RFC3830] is mainly designed to facilitate multimedia 143 distribution, while TESLA [RFC4082] is proposed as a protocol for 144 broadcast authentication of the source and not for protecting the 145 confidentiality of multicast messages. [RFC3740] and [RFC4046] 146 provide reference architectures for multicast security. [RFC4535] 147 describes Group Secure Association Key Management Protocol (GSAKMP), 148 a security framework for creating and managing cryptographic groups 149 on a network which can be reused for key management in our context 150 with any needed adaptation for constrained networks. 152 This draft describes an approach to use DTLS as mandated in CoAP 153 unicast to also support multicast security. We will assume that all 154 devices in the group already have a group security association 155 parameters based on a key management mechanism which is outside the 156 scope of this draft. This draft focuses primarily on the adaptation 157 of the DTLS record layer to protect multicast messages to be sent to 158 the group, and thus providing confidentiality, integrity and replay 159 protection to the CoAP group messages. 161 Lastly, even though this draft is written from the perspective of 162 securing CoAP based group communication, it is important to note that 163 DTLS is a powerful and flexible security protocol. Thus use of DTLS- 164 based multicast for application layer protocols other than CoAP are 165 possible as long as they follow the approach outlined in this draft. 167 1.1. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 This specification uses the following terminology: 175 o Group Controller: The entity that is responsible for creating a 176 multicast group and establishing security associations among 177 authorized group members. It is also responsible for renewing/ 178 updating the multicast group keys. 180 o Sender: The Sender is an entity that sends data to the multicast 181 group. In a 1-to-N multicast group only a single sender is 182 authorized to transmit data to the group. In an M-to-N multicast 183 group (where M and N are not necessarily the same value), M group 184 members are authorized to be senders. 186 o Listener: The entity that receives multicast messages when 187 listening to a multicast IP address. 189 o Security Association (SA): A set of policy and cryptographic keys 190 that provide security services to network traffic that matches 191 that policy [RFC3740]. A Security Association usually contains 192 the following attributes: 194 * selectors, such as source and destination transport addresses. 196 * properties, such as identities. 198 * cryptographic policy, such as the algorithms, modes, key 199 lifetimes, and key lengths used for authentication or 200 confidentiality. 202 * keying material for authentication, encryption and signing. 204 o Group Security Association (GSA): A bundling of security 205 associations (SAs) that together define how a group communicates 206 securely. [RFC3740] 208 o Keying material: Data that is specified as part of the SA which is 209 needed to establish and maintain a cryptographic security 210 association, such as keys, key pairs, and IVs [RFC4949]. 212 1.2. Outline 214 This draft is structured as follows: Section 2 motivates the proposed 215 solution with group communication use cases in LLNs and derives a set 216 of requirements. Section 3 provides an overview of the proposed 217 DTLS-based multicast security assuming that all devices in the group 218 already have a group security association parameters in their 219 possession. In Section 4, we describe the details of the adaptation 220 of DTLS record layer for confidentiality and integrity protection of 221 the multicast messages. Section 6 presents the security 222 considerations. 224 2. Use Cases and Requirements 226 This section defines the use cases for group communication in LLNs 227 and specifies a set of security requirements for these use cases. 229 2.1. Group Communication Use Cases 231 The "Group Communication for CoAP" draft [I-D.ietf-core-groupcomm] 232 provides the necessary background for multicast based CoAP 233 communication in constrained environments (e.g. LLNs). and the 234 interested reader is encouraged to first read this document to 235 understand the non-security related details. This document also 236 lists a few multicast group communication uses cases with detailed 237 descriptions and some are listed here briefly: 239 a. Lighting control: enabling synchronous operation of a group of 240 6LoWPAN [RFC4944] [RFC6282] connected lights in a room/floor/ 241 building. This ensures that the light preset like on/off/dim- 242 level of a large group of luminaries are changed at the same 243 time, hence providing a visual synchronicity of light effects to 244 the user. 246 b. Parameter update: configuration settings of a group of similar 247 devices are updated simultaneously and efficiently. 249 c. Device and Service discovery: information about the devices in 250 the local network and their capabilities can be queried and 251 requested using multicast, e.g. by a commissioning device. The 252 responses are sent back in unicast. 254 Elaborating on one of the main use cases that this document 255 addresses, Lighting control, consider a building equipped with 256 6LoWPAN IP-connected lighting devices, switches, and 6LoWPAN border 257 routers; the devices are organized in groups according to their 258 physical location in the building, e.g., lighting devices and 259 switches in a room/floor can be configured as a single multicast 260 group. The switches are then used to control the lighting devices in 261 the group by sending on/off/dimming commands to all lighting devices 262 in the group. 6LoWPAN border routers that are connected to an IPv6 263 network backbone (which is also multicast enabled) are used to 264 interconnect 6LoWPANs in the building. Consequently, this would also 265 enable multicast groups to be formed across different physical 266 subnets (which may be individually protected with L2 security). In 267 such a multicast group, group messages can traverse from one physical 268 subnet to another physical subnet through a IPv6 backbone which may 269 not be protected. Additionally, other non-lighting devices (like 270 window blind controls) may share the physical subnet for networking. 272 2.2. Security Requirements 274 The "Miscellaneous CoAP Group Communication Topics" draft 275 [I-D.dijk-core-groupcomm-misc] already defines a set of security 276 requirements for CoAP group communications We re-iterate and further 277 describe those security requirements in this section with respect to 278 the use cases: 280 a. Multicast communication topology: We consider both 1-to-N (one 281 sender with multiple listeners) and M-to-N (multiple senders with 282 multiple listeners) communication topologies. The 1-to-N 283 communication topology is the simplest group communication 284 scenario that would serve the needs of a typical LLN. For 285 example, in the simple lighting control use case, the switch is 286 the only entity that is responsible for sending control commands 287 to a group of lighting devices. In more advanced lighting 288 control use cases, a N-to-M communication topology would be 289 required, for example if multiple sensors (presence or day-light) 290 are responsible to trigger events to a group of lighting devices. 292 b. Multicast group size: The security solutions should support the 293 typical group sizes that "Group Communication for CoAP" draft 294 [I-D.ietf-core-groupcomm] intends to support. Group size is the 295 combination of the number of Senders and Listeners in a group 296 with possible overlap (a Sender can also be a Listener but need 297 not be always). In LLN use cases mentioned in the document, the 298 number of Senders (normally the controlling devices) is much 299 smaller than the number of Listeners (the controlled devices). A 300 security solution that supports 1 to 50 Senders would cover the 301 group sizes required for most use cases that are relevant for 302 this document. The total number of group devices must be in the 303 range of 2 to 100 devices. Groups larger than these should be 304 divided into smaller independent multicast groups such as 305 grouping lights of a building per floor. 307 c. Establishment of a GSA: A secure mechanism must be used to 308 distribute keying materials, multicast security policies and 309 security parameters to members of a multicast group. A GSA must 310 be established by the group controller (which manages the 311 multicast group) among the group members. The 6LoWPAN border 312 router, a device in the 6LoWPAN, or a remote server outside the 313 6LoWPAN could play the role of the group controller. However, 314 GSA establishment is outside the scope of this draft, and it is 315 anticipated that an activity in IETF dedicated to the design of a 316 generic key management scheme for the LLN will include this 317 feature preferably based on [RFC3740], [RFC4046] and [RFC4535]. 319 d. Multicast data confidentiality: Multicast message should be 320 encrypted, as some control commands when sent in the clear could 321 pose unforeseen privacy risks to the users of the system. 323 e. Multicast data replay protection: It must not be possible to 324 replay a multicast message as this would disrupt the operation of 325 the group communication. 327 f. Multicast data group authentication and integrity: It is 328 essential to ensure that a multicast message originated from a 329 member of the group and that messages have not been tampered with 330 by attackers who are not members. The multicast group key which 331 is known to all group members is used to provide authenticity to 332 the multicast messages (e.g., using a Message Authentication 333 Code, MAC). This assumes that all other group members are 334 trusted not to tamper with the multicast message. 336 g. Multicast data security ciphersuite: All group members must use 337 the same ciphersuite to protect the authenticity, integrity and 338 confidentiality of multicast messages. The ciphersuite is part 339 of the GSA. Typically authenticity is more important than 340 confidentiality in LLNs. Therefore the proposed multicast data 341 security protocol must support at least ciphersuites with MAC 342 only (NULL encryption) and AEAD [RFC5116] ciphersuites. Other 343 ciphersuites that are defined for data record security in DTLS 344 should also be preferably supported. 346 h. Multicast data source authentication: Source authenticity is 347 required if the group members are assumed to be untrusted and can 348 tamper with the multicast messages. This can happen if nodes of 349 the group can be easily compromised. Source authenticity helps 350 to minimize the risk of any node compromise leading to the 351 compromise of the whole multicast group. Source authenticity can 352 be typically provided using public-key cryptography in which 353 every multicast message is signed by the sender. Alternatively, 354 a lightweight broadcast authentication, i.e., TESLA [RFC4082] can 355 be deployed, however it requires devices in the multicast group 356 to have a trusted clock and have the ability to loosely 357 synchronize their clocks with the sender. Source authenticity 358 mechanisms should be preferably defined at the application layer. 359 The transport layer group level security can provide an 360 additional layer of security for the source authenticity 361 mechanism against DoS attacks. However, even with source 362 authenticity the risk still remains that compromise of a sender 363 can still compromise the whole group. 365 i. Forward security: Devices that leave the group should not have 366 access to any future GSAs. This ensures that a past member 367 device cannot continue to decrypt confidential data that is sent 368 in the group. It also ensures that this device cannot send 369 encrypted and/or integrity protected data after it leaves the 370 group. The GSA update mechanism has to be defined as part of the 371 key management scheme. 373 j. Backward confidentiality: A new device joining the group should 374 not have access to any old GSAs. This ensures that a new member 375 device cannot decrypt data sent before it joins the group. The 376 key management scheme should ensure that the GSA is updated to 377 ensure backward confidentiality. 379 3. Overview of DTLS-based Secure Multicast 381 The goal of this draft is to secure CoAP Group communication by 382 extending the use of the DTLS security protocol to allow for the use 383 of DTLS record layer with minimal adaptation. The IETF CoRE WG has 384 selected DTLS [RFC6347] as the default must-implement security 385 protocol for securing CoAP, therefore it is desirable that DTLS be 386 extended to facilitate CoAP-based group communication. Reusing DTLS 387 for different purposes while guaranteeing the required security 388 properties can avoid the need to implement multiple security 389 protocols and this is especially beneficial when the target 390 deployment consists of resource-constrained embedded devices. This 391 section first describes group communication based on IP multicast, 392 and subsequently sketches a solution for securing group communication 393 using DTLS. 395 3.1. IP Multicast 397 Devices in the network (e.g. LLN) are categorized into two roles, (1) 398 sender and (2) listener. Any node may have one of these roles, or 399 both roles. The application(s) running on a device basically 400 determine these roles by the function calls they execute on the IP 401 stack of the device. 403 In principle, a sender or listener does not require any prior access 404 procedures or authentication to send or listen to a multicast message 405 [RFC5374]. A sender to an IPv6 multicast group sets the destination 406 of the packet to an IPv6 address that has been allocated for IPv6 407 multicast. A device becomes a listener by "joining" to the specific 408 IPv6 multicast group by registering with a network routing device, 409 signaling its intent to receive packets sent to that particular IPv6 410 multicast group. Figure 1 depicts a 1-to-N multicast communication 411 and the roles of the nodes. Any device can in principle decide to 412 listen to any IPv6 multicast address. This also means applications 413 on the other devices do not know, or do not get notified, when new 414 listeners join the network. More details on the IPv6 multicast and 415 CoAP group communication can be found in [I-D.ietf-core-groupcomm]. 416 This draft does not intend to modify any of the underlying group 417 communication or multicast routing protocols. 419 ++++ 420 |. | 421 --| ++++ 422 ++++ / ++|. | 423 |A |---------| ++++ 424 | | \ ++|B | 425 ++++ \-----| | 426 Sender ++++ 427 Listeners 429 Figure 1: The roles of nodes in a 1-to-N multicast communication 430 topology 432 3.2. Securing Multicast in Constrained Networks 434 A group controller in a constrained network creates a multicast 435 group. The group controller may be hosted by a remote server, or a 436 border router that creates a new group over the network. In some 437 cases, devices may be configured using a commissioning tool that 438 mediates the communication between the devices and the group 439 controller. The controller in the network can be discovered by the 440 devices using various methods defined in [I-D.vanderstok-core-dna] 441 such as DNS-SD [RFC6763] and Resource Directory 442 [I-D.ietf-core-resource-directory]. The group controller 443 communicates with individual devices to add them to the new group. 444 Additionally it distributes the GSA consisting of keying material, 445 security policies security parameters and ciphersuites using a 446 standardized key management for constrained networks which is outside 447 the scope of this draft. Additional ciphersuites may need to be 448 defined to convey the bulk cipher algorithm, MAC algorithm and key 449 lengths within the key management protocol. We provide two examples 450 of ciphersuites (based on the security requirements) that could be 451 defined as part of a future key management mechanism: 453 Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2} 454 Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4} 456 Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide 457 confidentiality, integrity and authenticity to the multicast messages 458 where the encryption algorithm is AES [FIPS.197.2001], key length is 459 128-bit, and the authentication function is CCM [RFC6655] with a 460 Message Authentication Code (MAC) length of 8 octets. Similar to 461 [RFC4785], the ciphersuite MTS_WITH_NULL_SHA is used when 462 confidentiality of multicast messages is not required, it only 463 provides integrity and authenticity protection to the multicast 464 message. When this ciphersuite is used, the message is not encrypted 465 but the MAC must be included in which it is computed using a HMAC 466 [RFC2104] that is based on Secure Hash Function SHA256 467 [FIPS.180-2.2002]. Depending on the future needs, other ciphersuites 468 with different cipher algorithms and MAC length may be supported. 470 Senders in the group can encrypt and authenticate the CoAP group 471 messages from the application using the keying material into the DTLS 472 record. The authenticated encrypted message is passed down to the 473 lower layer of the IPv6 protocol stack for transmission to the 474 multicast address as depicted in Figure 2. The listeners when 475 receiving the message, use the multicast IPv6 destination address and 476 port (i.e., Multicast identifier) to look up the GSA needed for that 477 group connection. The received message is then decrypted and the 478 authenticity is verified using the keying material for that 479 connection. 481 +--------+-------------------------------------------------+ 482 | | +--------+------------------------------------+ | 483 | | | | +-------------+------------------+ | | 484 | | | | | | +--------------+ | | | 485 | IP | | UDP | | DTLS Record | | multicast | | | | 486 | header | | header | | Header | | message | | | | 487 | | | | | | +--------------+ | | | 488 | | | | +-------------+------------------+ | | 489 | | +--------+------------------------------------+ | 490 +--------+-------------------------------------------------+ 492 Figure 2: Sending a multicast message protected using DTLS Record 493 Layer 495 4. Multicast Data Security 497 This section describes in detail the use of DTLS record layer to 498 secure multicast messages. This assumes that group membership has 499 been configured by the group controller, and all member devices in 500 the group have the GSA. 502 4.1. SecurityParameter derivation 504 The GSA is used to derive the same "SecurityParameters" structure as 505 defined in [RFC5246] for all devices. 507 The SecurityParameters.ConnectionEnd should be set to "server" for 508 senders and "client" for listeners. The current read and write 509 states can be derived from SecurityParameters by generating the six 510 keying materials: 512 client write MAC key 513 server write MAC key 514 client write encryption key 515 server write encryption key 516 client write IV 517 server write IV 519 This requires that the client_random and server_random within the 520 SecurityParameters are also set to the same value for all devices as 521 part of the GSA to derive the same keying material for all devices in 522 the group with the PRF function defined in Section 6.3 of [RFC5246] . 523 Alternatively, the GSA could directly include the above six keying 524 material when being configured in all group devices. 526 The current read and write states are instantiated for all group 527 members based on the keying material and according to their roles: 528 senders use "server write" parameters for the write state and 529 listeners use "server write" parameters for the read state. 530 Additionally each connection state contains the sequence number which 531 is incremented for each record sent; the first record sent has the 532 sequence number 0. 534 4.2. Record layer adaptation 536 In this section, we describe in detail the adaptation of the DTLS 537 Record layer to enable multiple senders in the group to securely send 538 information using a common group key, while preserving the 539 confidentiality, integrity and freshness of the messages. 541 The following Figure 3 illustrates the structure of the DTLS record 542 layer header, the epoch and seq_number are used to ensure message 543 freshness and to detect message replays. 545 +---------+---------+--------+--------+--------+------------+-------+ 546 | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | 547 +---------+---------+--------+--------+--------+------------+-------+ 548 | Content | Version | epoch | seq_ | Length | Ciphertext | MAC | 549 | Type | Ma | Mi | | number | | (Enc) | (Enc) | 550 +---------+---------+--------+--------+--------+------------+-------+ 552 Figure 3: The DTLS record layer header and optionally encrypted 553 payload and MAC 555 The epoch is fixed by the DTLS handshake and the seq_number is 556 initialized to 0. The seq_number is increased by one whenever a 557 sender sends a new record message. This is the mechanism of DTLS to 558 detect message replay. Finally, the message is protected (encrypted 559 and authenticated with a MAC) using the session keys in the "server 560 write" parameters. 562 One of the problems with supporting multiple senders is that, the 563 seq_number used by senders need to be synchronized to avoid their 564 reuse, otherwise packets sent by different senders may get discarded 565 as replayed packets. Further, the bigger problem is using a single 566 key in a multiple sender scenario leads to nonce reuse in AEAD cipher 567 suites like AES-CCM [RFC6655] and AES-GCM [RFC5288] as defined in 568 DTLS. Nonce reuse can completely break the security of these cipher 569 suites. 571 According to the AES-CCM for TLS, Section 3 [RFC6655], the CCMNonce 572 is a combination of a salt value and the sequence number. 574 struct { 575 opaque salt[4]; 576 opaque nonce_explicit[8]; 577 } CCMNonce; 579 The salt is the "client write IV" (when the client is sending) or the 580 "server write IV" (when the server is sending) as defined in the 581 "SecurityParameters". Further [RFC6655] requires that the value of 582 the nonce_explicit MUST be distinct for each distinct invocation of 583 the CCM encrypt function for any fixed key. When the nonce_explicit 584 is equal to the sequence number of the TLS packets, the CCMNonce has 585 the structure as below: 587 struct { 588 uint32 client_write_IV; // low order 32-bits 589 uint64 seq_num; // TLS sequence number 590 } CCMClientNonce. 592 struct { 593 uint32 server_write_IV; // low order 32-bits 594 uint64 seq_num; // TLS sequence number 595 } CCMServerNonce. 597 In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated 598 with the 48-bit seq_number. Therefore to prevent that the CCMNonce 599 is reused, either all senders need to synchronize or separate non- 600 overlapping sequence number spaces need to be created for each 601 sender. Synchronization between senders is especially hard in 602 constrained networks and therefore we go for the second approach of 603 separating the sequence number spaces by embedding a unique sender 604 identifier in the sequence number as suggested in [RFC5288]. 606 Thus in addition to configuring each device in the group with the 607 GSA, the controller needs to assign a unique SenderID to each device 608 which has the sender role in the group. The size of the SenderID is 609 1-octet based on the requirement for the supported group size 610 mentioned in Section 2.2. The list of SenderIDs are then distributed 611 to all the group members by the controller. 613 The existing DTLS record layer header is adapted such that the 614 6-octet seq_number field is split into a 1-octet SenderID field and a 615 5-octet "truncated" trunc_seq_number field. Figure 4 illustrates the 616 adapted DTLS record layer header. 618 +---------+---------+--------+--------+-----------+--------+ 619 | 1 Byte | 2 Byte | 2 Byte | 1 Byte | 5 Byte | 2 Byte | 620 +---------+---------+--------+--------+-----------+--------+ 621 | Content | Version | Epoch | Sender | trunc_seq_| Length | 622 | Type | Ma | Mi | | ID | number | | 623 +---------+---------+--------+--------+-----------+--------+ 625 Figure 4: The adapted DTLS record layer header 627 4.3. Sending Secure Multicast Messages 629 Senders in the multicast group when sending a CoAP group message from 630 the application, create the adapted DTLS record payload based on the 631 "server write" parameters. Each sender in the group uses its own 632 unique SenderID in the DTLS record layer header. It also manages its 633 own epoch and trunc_seq_number in the "server write" connection 634 state; the first record sent has the trunc_seq_number 0. After 635 creating the DTLS record, the trun_seq_number is incremented in the 636 "server write" connection state. The adapted DTLS record is then 637 passed down to UDP and IPv6 layer for transmission on the multicast 638 IPv6 destination address and port. 640 4.4. Receiving Secure Multicast Messages 642 When a listeners receives a protected multicast message from the 643 sender, it looks up the corresponding "client read" connection state 644 based on the multicast IP destination and port of the packet. This 645 is fundamentally different from standard DTLS logic in that the 646 current "client read" connection state is bound to the source IP 647 address and port. 649 Listener devices in a multiple senders multicast group, need to store 650 multiple "client read" connection states for the different senders 651 linked to the SenderIDs. The keying material is same for all senders 652 however the epoch and the trunc_seq_number of the last received 653 packets needs to be kept different for different senders. 655 The listeners first perform a "server write" keys lookup by using the 656 multicast IPv6 destination address and port of the packet. By 657 knowing the keys, the listeners decrypt and check the MAC of the 658 message. This guarantees that no one outside the group has spoofed 659 the SenderID, as it is protected by the MAC. Subsequently, by 660 authenticating the SenderID field, the listeners retrieve the "client 661 read" connection state which contains the last stored epoch and 662 trunc_seq_number of the sender, which is used to check the freshness 663 of the message received. The listeners must ensure that the epoch is 664 the same and trunc_seq_number in the message received is higher than 665 the stored value, otherwise the message is discarded. Alternatively 666 a windowing mechanism can be used to accept genuine out-of-order 667 packets. Once the authenticity and freshness of the message have 668 been checked, the listeners can pass the message to the higher layer 669 protocols. The epoch and the trunc_seq_number in the corresponding 670 "client read" connection state are updated as well. 672 4.5. Unicast Responses to Multicast Messages 674 In CoAP, responses to multicast messages are always sent back as 675 unicast. That is, the group members that receive a multicast message 676 may individually decide to send (or suppress) a unicast response as 677 described in Section 2.5 of [I-D.ietf-core-groupcomm]. The unicast 678 responses to a DTLS-based multicast message may optionally be secure. 679 Specifically, the unicast response may be sent back as a unicast DTLS 680 as described in Section 9.1 of [I-D.ietf-core-coap]. This requires 681 that a unicast DTLS handshake was previously initiated between the 682 multicast message sender and listener. In the extreme scenario, a 683 multicast sender may attempt to initiate the unicast DTLS handshake 684 with all or a subset of known listeners just before or just after it 685 sends out the DTLS-based multicast message. This may result in the 686 multicast sender (i.e. unicast DTLS client) having to process unicast 687 DTLS handshake messages from multiple multicast listeners (i.e. 688 unicast DTLS servers) in a short period. 690 Note: There is an obvious timing and processing load issue for the 691 multicast sender in the scenario where it attempts to initiate the 692 unicast DTLS handshakes with all/some of its known listeners just 693 after it sends out the DTLS-based multicast message. In this case, 694 the processing load in the multicast sender (i.e. unicast DTLS 695 client) is reduced somewhat by the fact that CoAP requires a back-off 696 and randomization of the unicast response by the Leisure timer 697 mechanism as described in Section 8.2 of [I-D.ietf-core-coap]. 699 4.6. Proxy Operation 701 CoAP allows a client to designate a (forward) proxy to process its 702 CoAP request for both unicast and multicast scenarios as described in 703 Section 2.10 of [I-D.ietf-core-groupcomm]. In this case, the proxy 704 (and not the client) appears as the originating point to the 705 destination server for the CoAP request. 707 As mentioned in Section 11.2 of [I-D.ietf-core-coap], proxies are by 708 their nature men-in-the-middle and break DTLS protection of CoAP 709 message exchanges. Therefore, in a DTLS-based multicast scenario 710 involving a proxy, a two-step approach is required. First, the 711 client will send a unicast DTLS request to the proxy. The proxy will 712 then receive and decrypt the unicast message. The proxy will then 713 take the contents of the received message and create a new multicast 714 message and secure it using DTLS-based multicast before sending it 715 out to the group. For this approach to work properly, the client 716 needs to be able to designate the proxy as an authorized sender. The 717 mechanism for this authorization is outside the scope of this draft. 719 5. IANA Considerations 721 This memo includes no request to IANA. 723 6. Security Considerations 725 Some of the security issues that should be taken into consideration 726 are discussed below. 728 6.1. Group level security 730 This proposal uses a single group key to protect communication within 731 the group. This requires that all group members are trusted, for 732 e.g. they do not forge messages as a different sender in the group. 733 In many use case, the devices in a group belong to a common authority 734 and are configured by a commissioner. In a professional lighting 735 scenario, the roles of the senders and listeners are configured by 736 the lighting commissioner and devices follow those roles. 738 The use of the protocol should take into consideration the risk of 739 compromise of a group device in a deployment scenario. Therefore the 740 group size should be limited to 100 devices unless additional source 741 authenticity mechanisms are implemented at the application layer. 742 Further, the damage due to a compromised key can be limited by 743 increasing the frequency of re-keying based on the unique unicast 744 key-pair shared by each device with the controller. Additionally the 745 risk of compromise is reduced when deployments are in physically 746 secured locations, like lighting inside office buildings. 748 6.2. Late joiners 750 Listeners who are late joiners to a multicast group, do not know the 751 current epoch and trun_seq_number being used by different senders. 752 When they receive a packet from a sender with a random 753 trunc_seq_number in it, it is impossible for the listener to verify 754 if the packet is fresh and has not been replayed by an attacker. To 755 overcome this late joiner security issue, we can use the techniques 756 similar to AERO [I-D.mcgrew-aero] where the late joining listener on 757 receiving the first packet from a particular sender, initialize its 758 last seen epoch and trunc_seq_number in the "client read" state for 759 that sender, however does not pass this packet to the application 760 layer and instead drops it. This provides a reference point to 761 identify if future packets are fresher than the last seen packet. 762 Alternatively, the group controller which can act as a listener in 763 the multicast group can maintain the epoch and trunc_seq_number of 764 each sender. When late joiners send a request to the group 765 controller to join the multicast group, the group controller can send 766 the list of epoch and trunc_seq_numbers as part of the GSA. 768 6.3. Uniqueness of SenderIDs 770 It is important that SenderIDs are unique to maintain the security 771 properties of the DTLS record layer messages. However in the event 772 that two or more senders are configured with the same SenderID, a 773 mechanism needs to be present to avoid a security weakness and 774 recover from the situation. One such mechanism is that all senders 775 of the multicast group are also listeners. This allows a sender 776 which receives a packet from a different device with its own SenderID 777 in the DTLS header to become aware of a clash. Once aware, the 778 sender can inform the controller on a secure channel about the clash 779 along with the source IP address. The controller can then provide a 780 different SenderID to either device or both. 782 6.4. Reduced sequence number space 784 The DTLS record layer seq_number is truncated from 6 octets to 5 785 octets. This reduction of the seq_number space should be taken into 786 account to ensure that epoch is incremented before the 787 trunc_seq_number wraps over. The sender or the controller can 788 increase the epoch number by sending a ChangeCipherSpec message 789 whenever the trunc_seq_number has been exhausted. This should be 790 done as part of the key management mechanism which is not defined in 791 this draft. 793 7. Acknowledgements 795 The authors greatly acknowledge discussion, comments and feedback 796 from Dee Denteneer, Peter van der Stok, Zach Shelby, Michael StJohns 797 and Marco Tiloca. Additionally thanks to David McGrew for suggesting 798 options for recovering from a SenderID clash, and John Foley for the 799 extensive review and pointing us to the AERO draft. We also 800 appreciate prototyping and implementation efforts by Pedro Moreno 801 Sanchez who worked as an intern at Philips Research. 803 8. References 805 8.1. Normative References 807 [I-D.ietf-core-coap] 808 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 809 Application Protocol (CoAP)", draft-ietf-core-coap-18 810 (work in progress), June 2013. 812 [I-D.ietf-core-groupcomm] 813 Rahman, A. and E. Dijk, "Group Communication for CoAP", 814 draft-ietf-core-groupcomm-18 (work in progress), December 815 2013. 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, March 1997. 820 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 821 Encryption", RFC 5116, January 2008. 823 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 824 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 826 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 827 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 828 August 2008. 830 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 831 Security Version 1.2", RFC 6347, January 2012. 833 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 834 Transport Layer Security (TLS)", RFC 6655, July 2012. 836 8.2. Informative References 838 [FIPS.180-2.2002] 839 National Institute of Standards and Technology, "Secure 840 Hash Standard", FIPS PUB 180-2, August 2002, 841 . 844 [FIPS.197.2001] 845 National Institute of Standards and Technology, "Advanced 846 Encryption Standard (AES)", FIPS PUB 197, November 2001, 847 . 850 [I-D.dijk-core-groupcomm-misc] 851 Dijk, E. and A. Rahman, "Miscellaneous CoAP Group 852 Communication Topics", draft-dijk-core-groupcomm-misc-05 853 (work in progress), December 2013. 855 [I-D.ietf-core-resource-directory] 856 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 857 Directory", draft-ietf-core-resource-directory-01 (work in 858 progress), December 2013. 860 [I-D.mcgrew-aero] 861 McGrew, D. and J. Foley, "Authenticated Encryption with 862 Replay prOtection (AERO)", draft-mcgrew-aero-01 (work in 863 progress), February 2014. 865 [I-D.vanderstok-core-dna] 866 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 867 Naming, and Addressing", draft-vanderstok-core-dna-02 868 (work in progress), July 2012. 870 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 871 Hashing for Message Authentication", RFC 2104, February 872 1997. 874 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 875 Architecture", RFC 3740, March 2004. 877 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 878 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 879 August 2004. 881 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 882 "Multicast Security (MSEC) Group Key Management 883 Architecture", RFC 4046, April 2005. 885 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 886 Briscoe, "Timed Efficient Stream Loss-Tolerant 887 Authentication (TESLA): Multicast Source Authentication 888 Transform Introduction", RFC 4082, June 2005. 890 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 891 "GSAKMP: Group Secure Association Key Management 892 Protocol", RFC 4535, June 2006. 894 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 895 Ciphersuites with NULL Encryption for Transport Layer 896 Security (TLS)", RFC 4785, January 2007. 898 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 899 "Transmission of IPv6 Packets over IEEE 802.15.4 900 Networks", RFC 4944, September 2007. 902 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 903 4949, August 2007. 905 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 906 Extensions to the Security Architecture for the Internet 907 Protocol", RFC 5374, November 2008. 909 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 910 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 911 September 2011. 913 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 914 Discovery", RFC 6763, February 2013. 916 Appendix A. Change Log 918 (To be removed by RFC editor before publication.) 920 Changes from keoh-03 to keoh-04: 922 o Added description of Proxy operation in a DTLS-based multicast 923 scenario in Section 4.5 (Proxy Operation). 925 o Corrected text in Section 2.2 (Security Requirements), item "h", 926 to indicate that multicast source authentication is not specified 927 in this version of the draft. 929 o Clarified that draft is written primarily for securing of CoAP 930 based group communication, but that other protocols may also be 931 supported if they have similar characteristics. See Section 1 932 (Introduction). 934 o Ran IETF spell checker and ID-Nits tools and corrected various 935 issues throughout the document. 937 o Various editorial updates. 939 Changes from keoh-04 to keoh-05: 941 o In section 2.1, removed the firmware upgrade usecase and clarified 942 the commissioning use case. The lighting use-case expanded with 943 shared and multiple subnets issues. 945 o In Section 2.2, (b) reduced the group size to 100; (h) clarified 946 data source authenticity 948 o Added new Section 6.1 (Group level security) in security 949 considerations to make clear the risks of the single group key. 951 Changes from keoh-05 to keoh-06: 953 o Added description of protection of unicast responses to multicast 954 request in new Section 4.5 (Unicast Responses to Multicast 955 Messages). 957 o Clarified that CoAP may be run over either LLNs or regular 958 networks. This also included changing the title of the I-D. 960 o Various editorial updates. 962 Authors' Addresses 964 Sye Loong Keoh 965 University of Glasgow Singapore 966 Republic PolyTechnic, 9 Woodlands Ave 9 967 Singapore 838964 968 SG 970 Email: SyeLoong.Keoh@glasgow.ac.uk 972 Sandeep S. Kumar (editor) 973 Philips Research 974 High Tech Campus 34 975 Eindhoven 5656 AE 976 NL 978 Email: sandeep.kumar@philips.com 979 Oscar Garcia-Morchon 980 Philips Research 981 High Tech Campus 34 982 Eindhoven 5656 AE 983 NL 985 Email: oscar.garcia@philips.com 987 Esko Dijk 988 Philips Research 989 High Tech Campus 34 990 Eindhoven 5656 AE 991 NL 993 Email: esko.dijk@philips.com 995 Akbar Rahman 996 InterDigital 997 1000 Sherbrooke Street West 998 Montreal H3A 3G4 999 CA 1001 Email: akbar.rahman@interdigital.com