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