idnits 2.17.00 (12 Aug 2021) /tmp/idnits56703/draft-keoh-dice-multicast-security-04.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 (February 5, 2014) is 3026 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 572 -- Looks like a reference, but probably isn't: '8' on line 573 == Outdated reference: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: draft-ietf-core-groupcomm has been published as RFC 7390 ** 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: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: A later version (-01) exists of draft-mcgrew-aero-00 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: August 9, 2014 O. Garcia-Morchon 6 E. Dijk 7 Philips Research 8 A. Rahman 9 InterDigital 10 February 5, 2014 12 DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs) 13 draft-keoh-dice-multicast-security-04 15 Abstract 17 The CoAP and 6LoWPAN standards are fast emerging as key protocols in 18 the area of resource-constrained devices. Such IP-based systems are 19 foreseen to be used for building and lighting control systems where 20 wireless devices interconnect with each other, forming 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 in LLNs based on the DTLS which is already 24 supported for unicast communication for CoAP devices. This draft 25 deals with the adaptation of the DTLS record layer to protect 26 multicast group communication, assuming that all group members 27 already have the group security association parameters in their 28 possession. The adapted DTLS record layer provides message 29 confidentiality, integrity and replay protection to group messages 30 using the group keying material before sending the message via IPv6 31 multicast to the group. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 9, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Use Cases and Requirements . . . . . . . . . . . . . . . . . 5 71 2.1. Group Communication Use Cases . . . . . . . . . . . . . . 5 72 2.2. Security Requirements . . . . . . . . . . . . . . . . . . 6 73 3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . 9 74 3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Securing Multicast in LLNs . . . . . . . . . . . . . . . 10 76 4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 11 77 4.1. SecurityParameter derivation . . . . . . . . . . . . . . 11 78 4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 12 79 4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 14 80 4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14 81 4.5. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 15 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 6.1. Late joiners . . . . . . . . . . . . . . . . . . . . . . 16 85 6.2. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 16 86 6.3. Reduced sequence number space . . . . . . . . . . . . . . 16 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 90 8.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 There is an increased use of wireless control networks in 97 environmental monitoring, industrial automation, lighting controls 98 and building management systems. This is mainly driven by the fact 99 that the independence from physical control wires allows for freedom 100 of placement, portability and for reducing the cost of installation 101 as less cable placement and drilling are required. Consequently, 102 there is an ever growing number of electronic devices, sensors and 103 actuators that have become Internet connected, thus creating a trend 104 towards the Internet-of-Things (IoT). These connected devices are 105 equipped with communication capability that enables them to interact 106 with each other as well as with the wider Internet services. 107 However, the devices in such wireless control networks are 108 characterized by power constraints (as these are usually battery- 109 operated), have limited computational resources (low CPU clock, small 110 RAM and flash storage) and often, the communication bandwidth is 111 limited and unreliable (e.g., IEEE 802.15.4 radio). Hence, such 112 wireless control networks are also known as Low-power and Lossy 113 Networks (LLNs). 115 In addition to the usual device-to-device unicast communication that 116 allow devices to directly interact with each other, group 117 communication is an important feature in LLNs. It is more effective 118 in LLNs to convey messages to a group of devices without requiring 119 the sender to perform multiple time and energy consuming unicast 120 transmissions to reach each individual group member. For example, in 121 a building and lighting control system, the heating, ventilation, 122 air-conditioning and lighting devices are often grouped according to 123 the layout of the building, and control commands are issued 124 simultaneously to a group of devices. Group communication for LLNs 125 is based on the Constrained Application Protocol (CoAP) 126 [I-D.ietf-core-coap] sent over IP- multicast 127 [I-D.ietf-core-groupcomm]. 129 Currently, CoAP messages are protected using Datagram Transport Layer 130 Security (DTLS) [RFC6347]. However, DTLS is currently used to secure 131 a connection between two endpoints and it cannot be used to protect 132 multicast group communication. Group communication in LLNs is 133 equally important and should be secured as it is also vulnerable to 134 the usual attacks over the air (eavesdropping, tampering, message 135 forgery, replay, etc). There have been a lot of previous efforts in 136 IETF to standardize mechanisms to secure multicast communication such 137 as [RFC3830], [RFC4082], [RFC3740], [RFC4046], and [RFC4535]. 138 However, these approaches are not necessarily suitable for LLNs which 139 have much more limited bandwidth and resources. For example, the 140 MIKEY Architecture [RFC3830] is mainly designed to facilitate 141 multimedia distribution, while TESLA [RFC4082] is proposed as a 142 protocol for broadcast authentication of the source and not for 143 protecting the confidentiality of multicast messages. [RFC3740] and 144 [RFC4046] provide reference architectures for multicast security. 145 [RFC4535] describes Group Secure Association Key Management Protocol 146 (GSAKMP), a security framework for creating and managing 147 cryptographic groups on a network which can be reused for key 148 management in our context with any needed adaptation for LLNs. 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 is 180 authorized to transmit data to the group. In an M-to-N multicast 181 group (where M and N are not necessarily the same value), M group 182 members are authorized to be senders. 184 o Listener: The entity that receives multicast messages when 185 listening to a multicast IP address. 187 o Security Association (SA): A set of policy and cryptographic keys 188 that provide security services to network traffic that matches 189 that policy [RFC3740]. A Security Association usually contains 190 the following attributes: 192 * selectors, such as source and destination transport addresses. 194 * properties, such as identities. 196 * cryptographic policy, such as the algorithms, modes, key 197 lifetimes, and key lengths used for authentication or 198 confidentiality. 200 * keying material for authentication, encryption and signing. 202 o Group Security Association (GSA): A bundling of security 203 associations (SAs) that together define how a group communicates 204 securely. [RFC3740] 206 o Keying material: Data that is specified as part of the SA which is 207 needed to establish and maintain a cryptographic security 208 association, such as keys, key pairs, and IVs [RFC4949]. 210 1.2. Outline 212 This draft is structured as follows: Section 2 motivates the proposed 213 solution with group communication use cases in LLNs and derives a set 214 of requirements. Section 3 provides an overview of the proposed 215 DTLS-based multicast security assuming that all devices in the group 216 already have a group security association parameters in their 217 possession. In Section 4, we describe the details of the adaptation 218 of DTLS record layer for confidentiality and integrity protection of 219 the multicast messages. Section 6 presents the security 220 considerations. 222 2. Use Cases and Requirements 224 This section defines the use cases for group communication in LLNs 225 and specifies a set of security requirements for these use cases. 227 2.1. Group Communication Use Cases 229 The "Group Communication for CoAP" draft [I-D.ietf-core-groupcomm] 230 provides the necessary background for multicast based CoAP 231 communication in LLNs and the interested reader is encouraged to 232 first read this document to understand the non-security related 233 details. This document also lists a few multicast group 234 communication uses cases with detailed descriptions and some are 235 listed here briefly: 237 a. Lighting control: enabling synchronous operation of a group of 238 6LoWPAN [RFC4944] [RFC6282] connected lights in a room/floor/ 239 building. This ensures that the light preset of a large group of 240 luminaries are changed at the same time, hence providing a visual 241 synchronicity of light effects to the user. 243 b. Firmware update: firmware of devices in a building control system 244 are updated simultaneously, avoiding an excessive load on the LLN 245 due to unicast firmware updates. 247 c. Parameter update: settings of a group of similar devices are 248 updated simultaneously and efficiently. 250 d. Commissioning of above systems: information about the devices in 251 the local network and their capabilities can be queried and 252 requested, e.g. by a commissioning device. 254 Elaborating on one of the main use cases, Lighting control, consider 255 a building equipped with 6LoWPAN IP-connected lighting devices, 256 switches, and 6LoWPAN border routers; the devices are organized in 257 groups according to their physical location in the building, e.g., 258 lighting devices and switches in a room/floor can be configured as a 259 single multicast group. The switches are then used to control the 260 lighting devices in the group by sending on/off/dimming commands to 261 all lighting devices in the group. 6LoWPAN border routers that are 262 connected to an IPv6 network backbone (which is also multicast 263 enabled) are used to interconnect 6LoWPANs in the building. 264 Consequently, this would also enable multicast groups to be formed 265 across different physical subnets in the entire building. 267 2.2. Security Requirements 269 The "Miscellaneous CoAP Group Communication Topics" draft 270 [I-D.dijk-core-groupcomm-misc] already defines a set of security 271 requirements for group communication in LLNs. We re-iterate and 272 further describe those security requirements in this section with 273 respect to the use cases: 275 a. Multicast communication topology: We consider both 1-to-N (one 276 sender with multiple listeners) and M-to-N (multiple senders with 277 multiple listeners) communication topologies. The 1-to-N 278 communication topology is the simplest group communication 279 scenario that would serve the needs of a typical LLN. For 280 example, in the simple lighting control use case, the switch is 281 the only entity that is responsible for sending control commands 282 to a group of lighting devices. In more advanced lighting 283 control use cases, a N-to-M communication topology would be 284 required, for example if multiple sensors (presence or day-light) 285 are responsible to trigger events to a group of lighting devices. 287 b. Multicast group size: The security solutions should support the 288 typical group sizes that "Group Communication for CoAP" draft 289 [I-D.ietf-core-groupcomm] intends to support. Group size is the 290 combination of the number of Senders and Listeners in a group 291 with possible overlap (a Sender can also be a Listener but need 292 not be always). In typical LLN use cases, the number of Senders 293 (normally the controlling devices) is much smaller than the 294 number of Listeners (the controlled devices). A security 295 solution that supports 1 to 255 Senders would cover the group 296 sizes required for most use cases that are relevant for this 297 document. The number of Listeners can be larger in the range of 298 2 to 5,000 devices. 300 c. Establishment of a GSA: A secure mechanism must be used to 301 distribute keying materials, multicast security policies and 302 security parameters to members of a multicast group. A GSA must 303 be established by the group controller (which manages the 304 multicast group) among the group members. The 6LoWPAN border 305 router, a device in the 6LoWPAN, or a remote server outside the 306 6LoWPAN could play the role of the group controller. However, 307 GSA establishment is outside the scope of this draft, and it is 308 anticipated that an activity in IETF dedicated to the design of a 309 generic key management scheme for the LLN will include this 310 feature preferably based on [RFC3740], [RFC4046] and [RFC4535]. 312 d. Multicast data confidentiality: Multicast message should be 313 encrypted, as some control commands when sent in the clear could 314 pose privacy risks to the users. 316 e. Multicast data replay protection: It must not be possible to 317 replay a multicast message as this would disrupt the operation of 318 the group communication. 320 f. Multicast data group authentication and integrity: It is 321 essential to ensure that a multicast message originated from a 322 member of the group and that messages have not been tampered with 323 by attackers who are not members. The multicast group key which 324 is known to all group members is used to provide authenticity to 325 the multicast messages (e.g., using a Message Authentication 326 Code, MAC). This assumes that all other group members are 327 trusted not to tamper with the multicast message. 329 g. Multicast data security ciphersuite: All group members must use 330 the same ciphersuite to protect the authenticity, integrity and 331 confidentiality of multicast messages. The ciphersuite is part 332 of the GSA. Typically authenticity is more important than 333 confidentiality in LLNs. Therefore the proposed multicast data 334 security protocol must support at least ciphersuites with MAC 335 only (NULL encryption) and AEAD [RFC5116] ciphersuites. Other 336 ciphersuites that are defined for data record security in DTLS 337 should also be preferably supported. 339 h. Multicast data source authentication: Source authenticity is 340 required if the group members are assumed to be untrusted and can 341 tamper with the multicast messages. Source authenticity is not a 342 critical feature to be always enabled in every LLN use case. If 343 source authenticity is required for a specific use case, then it 344 can be typically provided using public-key cryptography in which 345 every multicast message is additionally signed by each sender. 346 This requires much higher computational resources on both the 347 sender and the receivers, thus incurring too much overhead and 348 computational requirements on devices in LLNs. Alternatively, a 349 lightweight broadcast authentication, i.e., TESLA [RFC4082] can 350 be deployed, however it requires devices in the multicast group 351 to have a trusted clock and have the ability to loosely 352 synchronize their clocks with the sender. Consequently, given 353 that the targeted devices have limited resources, and the need 354 for source authenticity is not critical in every use case, source 355 authenticity is not performed by default as part of the proposed 356 data security protocol. However, it can be supported using 357 additional mechanisms which are not specified in this version of 358 the draft. It is important to note that for use cases demanding 359 source authenticity, additional security mechanism is needed to 360 provide such guarantee. 362 i. Forward security: Devices that leave the group should not have 363 access to any future GSAs. This ensures that a past member 364 device cannot continue to decrypt confidential data that is sent 365 in the group. It also ensures that this device cannot send 366 encrypted and/or integrity protected data after it leaves the 367 group. The GSA update mechanism has to be defined as part of the 368 key management scheme. 370 j. Backward confidentiality: A new device joining the group should 371 not have access to any old GSAs. This ensures that a new member 372 device cannot decrypt data sent before it joins the group. The 373 key management scheme should ensure that the GSA is updated to 374 ensure backward confidentiality. 376 3. Overview of DTLS-based Secure Multicast 378 The goal of this draft is to secure CoAP Group communication over 379 6LoWPAN networks, by extending the use of the DTLS security protocol 380 to allow for the use of DTLS record layer with minimal adaptation. 381 The IETF CoRE WG has selected DTLS [RFC6347] as the default must- 382 implement security protocol for securing CoAP, therefore it is 383 desirable that DTLS be extended to facilitate CoAP-based group 384 communication. Reusing DTLS for different purposes while 385 guaranteeing the required security properties can avoid the need to 386 implement multiple security protocols and this is especially 387 beneficial when the target deployment consists of resource- 388 constrained embedded devices. This section first describes group 389 communication based on IP multicast, and subsequently sketches a 390 solution for securing group communication using DTLS. 392 3.1. IP Multicast 394 Devices in the LLN are categorized into two roles, (1) sender and (2) 395 listener. Any node in the LLN may have one of these roles, or both 396 roles. The application(s) running on a device basically determine 397 these roles by the function calls they execute on the IP stack of the 398 device. 400 In principle, a sender or listener does not require any prior access 401 procedures or authentication to send or listen to a multicast message 402 [RFC5374]. A sender to an IPv6 multicast group sets the destination 403 of the packet to an IPv6 address that has been allocated for IPv6 404 multicast. A device becomes a listener by "joining" to the specific 405 IPv6 multicast group by registering with a network routing device, 406 signaling its intent to receive packets sent to that particular IPv6 407 multicast group. Figure 1 depicts a 1-to-N multicast communication 408 and the roles of the nodes. Any device can in principle decide to 409 listen to any IPv6 multicast address. This also means applications 410 on the other devices do not know, or do not get notified, when new 411 listeners join the LLN. More details on the IPv6 multicast and CoAP 412 group communication can be found in [I-D.ietf-core-groupcomm]. This 413 draft does not intend to modify any of the underlying group 414 communication or multicast routing protocols. 416 ++++ 417 |. | 418 --| ++++ 419 ++++ / ++|. | 420 |A |---------| ++++ 421 | | \ ++|B | 422 ++++ \-----| | 423 Sender ++++ 424 Listeners 426 Figure 1: The roles of nodes in a 1-to-N multicast communication 427 topology 429 3.2. Securing Multicast in LLNs 431 A group controller in an LLN creates a multicast group. The group 432 controller may be hosted by a remote server, or a border router that 433 creates a new group over the network. In some cases, devices may be 434 configured using a commissioning tool that mediates the communication 435 between the devices and the group controller. The controller in the 436 network can be discovered by the devices using various methods 437 defined in [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and 438 Resource Directory [I-D.ietf-core-resource-directory]. The group 439 controller communicates with individual device to add them to the new 440 group. Additionally it distributes the GSA consisting of keying 441 material, security policies security parameters and ciphersuites 442 using a standardized key management for LLN which is outside the 443 scope of this draft. Additional ciphersuites may need to be defined 444 to convey the bulk cipher algorithm, MAC algorithm and key lengths 445 within the key management protocol. We provide two examples of 446 ciphersuites (based on the security requirements) that could be 447 defined as part of a future key management mechanism: 449 Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2} 450 Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4} 452 Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide 453 confidentiality, integrity and authenticity to the multicast messages 454 where the encryption algorithm is AES [FIPS.197.2001], key length is 455 128-bit, and the authentication function is CCM [RFC6655] with a 456 Message Authentication Code (MAC) length of 8 octets. Similar to 457 [RFC4785], the ciphersuite MTS_WITH_NULL_SHA is used when 458 confidentiality of multicast messages is not required, it only 459 provides integrity and authenticity protection to the multicast 460 message. When this ciphersuite is used, the message is not encrypted 461 but the MAC must be included in which it is computed using a HMAC 463 [RFC2104] that is based on Secure Hash Function SHA256 464 [FIPS.180-2.2002]. Depending on the future needs, other ciphersuites 465 with different cipher algorithms and MAC length may be supported. 467 Senders in the group can encrypt and authenticate the CoAP group 468 messages from the application using the keying material into the DTLS 469 record. The authenticated encrypted message is passed down to the 470 lower layer of the IPv6 protocol stack for transmission to the 471 multicast address as depicted in Figure 2. The listeners when 472 receiving the message, use the multicast IPv6 destination address and 473 port (i.e., Multicast identifier) to look up the GSA needed for that 474 group connection. The received message is then decrypted and the 475 authenticity is verified using the keying material for that 476 connection. 478 +--------+-------------------------------------------------+ 479 | | +--------+------------------------------------+ | 480 | | | | +-------------+------------------+ | | 481 | | | | | | +--------------+ | | | 482 | IP | | UDP | | DTLS Record | | multicast | | | | 483 | header | | header | | Header | | message | | | | 484 | | | | | | +--------------+ | | | 485 | | | | +-------------+------------------+ | | 486 | | +--------+------------------------------------+ | 487 +--------+-------------------------------------------------+ 489 Figure 2: Sending a multicast message protected using DTLS Record 490 Layer 492 4. Multicast Data Security 494 This section describes in detail the use of DTLS record layer to 495 secure multicast messages. This assumes that group membership has 496 been configured by the group controller, and all member devices in 497 the group have the GSA. 499 4.1. SecurityParameter derivation 501 The GSA is used to derive the same "SecurityParameters" structure as 502 defined in [RFC5246] for all devices. 504 The SecurityParameters.ConnectionEnd should be set to "server" for 505 senders and "client" for listeners. The current read and write 506 states can be derived from SecurityParameters by generating the six 507 keying materials: 509 client write MAC key 510 server write MAC key 511 client write encryption key 512 server write encryption key 513 client write IV 514 server write IV 516 This requires that the client_random and server_random within the 517 SecurityParameters are also set to the same value for all devices as 518 part of the GSA to derive the same keying material for all devices in 519 the group with the PRF function defined in Section 6.3 of [RFC5246] . 520 Alternatively, the GSA could directly include the above six keying 521 material when being configured in all group devices. 523 The current read and write states are instantiated for all group 524 members based on the keying material and according to their roles: 525 senders use "server write" parameters for the write state and 526 listeners use "server write" parameters for the read state. 527 Additionally each connection state contains the sequence number which 528 is incremented for each record sent; the first record sent has the 529 sequence number 0. 531 4.2. Record layer adaptation 533 In this section, we describe in detail the adaptation of the DTLS 534 Record layer to enable multiple senders in the group to securely send 535 information using a common group key, while preserving the 536 confidentiality, integrity and freshness of the messages. 538 The following Figure 3 illustrates the structure of the DTLS record 539 layer header, the epoch and seq_number are used to ensure message 540 freshness and to detect message replays. 542 +---------+---------+--------+--------+--------+------------+-------+ 543 | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | 544 +---------+---------+--------+--------+--------+------------+-------+ 545 | Content | Version | epoch | seq_ | Length | Ciphertext | MAC | 546 | Type | Ma | Mi | | number | | (Enc) | (Enc) | 547 +---------+---------+--------+--------+--------+------------+-------+ 549 Figure 3: The DTLS record layer header and optionally encrypted 550 payload and MAC 552 The epoch is fixed by the DTLS handshake and the seq_number is 553 initialized to 0. The seq_number is increased by one whenever a 554 sender sends a new record message. This is the mechanism of DTLS to 555 detect message replay. Finally, the message is protected (encrypted 556 and authenticated with a MAC) using the session keys in the "server 557 write" parameters. 559 One of the problems with supporting multiple senders is that, the 560 seq_number used by senders need to be synchronized to avoid their 561 reuse, otherwise packets sent by different senders may get discarded 562 as replayed packets. Further, the bigger problem is using a single 563 key in a multiple sender scenario leads to nonce reuse in AEAD cipher 564 suites like AES-CCM [RFC6655] and AES-GCM [RFC5288] as defined in 565 DTLS. Nonce reuse can completely break the security of these cipher 566 suites. 568 According to the AES-CCM for TLS, Section 3 [RFC6655], the CCMNonce 569 is a combination of a salt value and the sequence number. 571 struct { 572 opaque salt[4]; 573 opaque nonce_explicit[8]; 574 } CCMNonce; 576 The salt is the "client write IV" (when the client is sending) or the 577 "server write IV" (when the server is sending) as defined in the 578 "SecurityParameters". Further [RFC6655] requires that the value of 579 the nonce_explicit MUST be distinct for each distinct invocation of 580 the CCM encrypt function for any fixed key. When the nonce_explicit 581 is equal to the sequence number of the TLS packets, the CCMNonce has 582 the structure as below: 584 struct { 585 uint32 client_write_IV; // low order 32-bits 586 uint64 seq_num; // TLS sequence number 587 } CCMClientNonce. 589 struct { 590 uint32 server_write_IV; // low order 32-bits 591 uint64 seq_num; // TLS sequence number 592 } CCMServerNonce. 594 In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated 595 with the 48-bit seq_number. Therefore to prevent that the CCMNonce 596 is reused, either all senders need to synchronize or separate non- 597 overlapping sequence number spaces need to be created for each 598 sender. Synchronization between senders is especially hard in LLN 599 and therefore we go for the second approach of separating the 600 sequence number spaces by embedding a unique sender identifier in the 601 sequence number as suggested in [RFC5288]. 603 Thus in addition to configuring each device in the group with the 604 GSA, the controller needs to assign a unique SenderID to each device 605 which has the sender role in the group. The size of the SenderID is 606 1-octet based on the requirement for the supported group size 607 mentioned in Section 2.2. The list of SenderIDs are then distributed 608 to all the group members by the controller. 610 The existing DTLS record layer header is adapted such that the 611 6-octet seq_number field is split into a 1-octet SenderID field and a 612 5-octet "truncated" trunc_seq_number field. Figure 4 illustrates the 613 adapted DTLS record layer header. 615 +---------+---------+--------+--------+-----------+--------+ 616 | 1 Byte | 2 Byte | 2 Byte | 1 Byte | 5 Byte | 2 Byte | 617 +---------+---------+--------+--------+-----------+--------+ 618 | Content | Version | Epoch | Sender | trunc_seq_| Length | 619 | Type | Ma | Mi | | ID | number | | 620 +---------+---------+--------+--------+-----------+--------+ 622 Figure 4: The adapted DTLS record layer header 624 4.3. Sending Secure Multicast Messages 626 Senders in the multicast group when sending a CoAP group message from 627 the application, create the adapted DTLS record payload based on the 628 "server write" parameters. Each sender in the group uses its own 629 unique SenderID in the DTLS record layer header. It also manages its 630 own epoch and trunc_seq_number in the "server write" connection 631 state; the first record sent has the trunc_seq_number 0. After 632 creating the DTLS record, the trun_seq_number is incremented in the 633 "server write" connection state. The adapted DTLS record is then 634 passed down to UDP and IPv6 layer for transmission on the multicast 635 IPv6 destination address and port. 637 4.4. Receiving Secure Multicast Messages 639 When a listeners receives a protected multicast message from the 640 sender, it looks up the corresponding "client read" connection state 641 based on the multicast IP destination and port of the packet. This 642 is fundamentally different from standard DTLS logic in that the 643 current "client read" connection state is bound to the source IP 644 address and port. 646 Listener devices in a multiple senders multicast group, need to store 647 multiple "client read" connection states for the different senders 648 linked to the SenderIDs. The keying material is same for all senders 649 however the epoch and the trunc_seq_number of the last received 650 packets needs to be kept different for different senders. 652 The listeners first perform a "server write" keys lookup by using the 653 multicast IPv6 destination address and port of the packet. By 654 knowing the keys, the listeners decrypt and check the MAC of the 655 message. This guarantees that no one has spoofed the SenderID, as it 656 is protected by the MAC. Subsequently, by authenticating the 657 SenderID field, the listeners retrieve the "client read" connection 658 state which contains the last stored epoch and trunc_seq_number of 659 the sender, which is used to check the freshness of the message 660 received. The listeners must ensure that the epoch is the same and 661 trunc_seq_number in the message received is higher than the stored 662 value, otherwise the message is discarded. Alternatively a windowing 663 mechanism can be used to accept genuine out-of-order packets. Once 664 the authenticity and freshness of the message have been checked, the 665 listeners can pass the message to the higher layer protocols. The 666 epoch and the trunc_seq_number in the corresponding "client read" 667 connection state are updated as well. 669 4.5. Proxy Operation 671 CoAP allows a client to designate a (forward) proxy to process its 672 CoAP request for both unicast and multicast scenarios as described in 673 Section 2.10 of [I-D.ietf-core-groupcomm]. In this case, the proxy 674 (and not the client) appears as the originating point to the 675 destination server for the CoAP request. 677 As mentioned in Section 11.2 of [I-D.ietf-core-coap], proxies are by 678 their nature men-in-the-middle and break DTLS protection of CoAP 679 message exchanges. Therefore, in a DTLS-based multicast scenario 680 involving a proxy, a two-step approach is required. First, the 681 client will send a unicast DTLS request to the proxy. The proxy will 682 then receive and decrypt the unicast message. The proxy will then 683 take the contents of the received message and create a new multicast 684 message and secure it using DTLS-based multicast before sending it 685 out to the group. For this approach to work properly, the client 686 needs to be able to designate the proxy as an authorized sender. The 687 mechanism for this authorization is outside the scope of this draft. 689 5. IANA Considerations 691 This memo includes no request to IANA. 693 6. Security Considerations 695 Some of the security issues that should be taken into consideration 696 are discussed below. 698 6.1. Late joiners 700 Listeners who are late joiners to a multicast group, do not know the 701 current epoch and trun_seq_number being used by different senders. 702 When they receive a packet from a sender with a random 703 trunc_seq_number in it, it is impossible for the listener to verify 704 if the packet is fresh and has not been replayed by an attacker. To 705 overcome this late joiner security issue, we can use the techniques 706 similar to AERO [I-D.mcgrew-aero] where the late joining listener on 707 receiving the first packet from a particular sender, initialize its 708 last seen epoch and trunc_seq_number in the "client read" state for 709 that sender, however does not pass this packet to the application 710 layer and instead drops it. This provides a reference point to 711 identify if future packets are fresher than the last seen packet. 712 Alternatively, the group controller which can act as a listener in 713 the multicast group can maintain the epoch and trunc_seq_number of 714 each sender. When late joiners send a request to the group 715 controller to join the multicast group, the group controller can send 716 the list of epoch and trunc_seq_numbers as part of the GSA. 718 6.2. Uniqueness of SenderIDs 720 It is important that SenderIDs are unique to maintain the security 721 properties of the DTLS record layer messages. However in the event 722 that two or more senders are configured with the same SenderID, a 723 mechanism needs to be present to avoid a security weakness and 724 recover from the situation. One such mechanism is that all senders 725 of the multicast group are also listeners. This allows a sender 726 which receives a packet from a different device with its own SenderID 727 in the DTLS header to become aware of a clash. Once aware, the 728 sender can inform the controller on a secure channel about the clash 729 along with the source IP address. The controller can then provide a 730 different SenderID to either device or both. 732 6.3. Reduced sequence number space 734 The DTLS record layer seq_number is truncated from 6 octets to 5 735 octets. This reduction of the seq_number space should be taken into 736 account to ensure that epoch is incremented before the 737 trunc_seq_number wraps over. The sender or the controller can 738 increase the epoch number by sending a ChangeCipherSpec message 739 whenever the trunc_seq_number has been exhausted. This should be 740 done as part of the key management mechanism which is not defined in 741 this draft. 743 7. Acknowledgements 745 The authors greatly acknowledge discussion, comments and feedback 746 from Dee Denteneer, Peter van der Stok, Zach Shelby and Michael 747 StJohns. Additionally thank David McGrew for suggesting options for 748 recovering from a SenderID clash, and John Foley for the extensive 749 review and pointing us to the AERO draft. We also appreciate 750 prototyping and implementation efforts by Pedro Moreno Sanchez who 751 worked as an intern at Philips Research. 753 8. References 755 8.1. Normative References 757 [I-D.ietf-core-coap] 758 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 759 Application Protocol (CoAP)", draft-ietf-core-coap-18 760 (work in progress), June 2013. 762 [I-D.ietf-core-groupcomm] 763 Rahman, A. and E. Dijk, "Group Communication for CoAP", 764 draft-ietf-core-groupcomm-18 (work in progress), December 765 2013. 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, March 1997. 770 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 771 Encryption", RFC 5116, January 2008. 773 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 774 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 776 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 777 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 778 August 2008. 780 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 781 Security Version 1.2", RFC 6347, January 2012. 783 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 784 Transport Layer Security (TLS)", RFC 6655, July 2012. 786 8.2. Informative References 788 [FIPS.180-2.2002] 789 National Institute of Standards and Technology, "Secure 790 Hash Standard", FIPS PUB 180-2, August 2002, 791 . 794 [FIPS.197.2001] 795 National Institute of Standards and Technology, "Advanced 796 Encryption Standard (AES)", FIPS PUB 197, November 2001, 797 . 800 [I-D.dijk-core-groupcomm-misc] 801 Dijk, E. and A. Rahman, "Miscellaneous CoAP Group 802 Communication Topics", draft-dijk-core-groupcomm-misc-05 803 (work in progress), December 2013. 805 [I-D.ietf-core-resource-directory] 806 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 807 Directory", draft-ietf-core-resource-directory-01 (work in 808 progress), December 2013. 810 [I-D.mcgrew-aero] 811 McGrew, D. and J. Foley, "Authenticated Encryption with 812 Replay prOtection (AERO)", draft-mcgrew-aero-00 (work in 813 progress), October 2013. 815 [I-D.vanderstok-core-dna] 816 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 817 Naming, and Addressing", draft-vanderstok-core-dna-02 818 (work in progress), July 2012. 820 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 821 Hashing for Message Authentication", RFC 2104, February 822 1997. 824 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 825 Architecture", RFC 3740, March 2004. 827 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 828 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 829 August 2004. 831 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 832 "Multicast Security (MSEC) Group Key Management 833 Architecture", RFC 4046, April 2005. 835 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 836 Briscoe, "Timed Efficient Stream Loss-Tolerant 837 Authentication (TESLA): Multicast Source Authentication 838 Transform Introduction", RFC 4082, June 2005. 840 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 841 "GSAKMP: Group Secure Association Key Management 842 Protocol", RFC 4535, June 2006. 844 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 845 Ciphersuites with NULL Encryption for Transport Layer 846 Security (TLS)", RFC 4785, January 2007. 848 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 849 "Transmission of IPv6 Packets over IEEE 802.15.4 850 Networks", RFC 4944, September 2007. 852 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 853 4949, August 2007. 855 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 856 Extensions to the Security Architecture for the Internet 857 Protocol", RFC 5374, November 2008. 859 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 860 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 861 September 2011. 863 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 864 Discovery", RFC 6763, February 2013. 866 Appendix A. Change Log 868 (To be removed by RFC editor before publication.) 870 Changes from keoh-03 to keoh-04: 872 o Added description of Proxy operation in a DTLS-based multicast 873 scenario in Section 4.5 (Proxy Operation). 875 o Corrected text in Section 2.2 (Security Requirements), item "h", 876 to indicate that multicast source authentication is not specified 877 in this version of the draft. 879 o Clarified that draft is written primarily for securing of CoAP 880 based group communication, but that other protocols may also be 881 supported if they have similar characteristics. See Section 1 882 (Introduction). 884 o Ran IETF spell checker and ID-Nits tools and corrected various 885 issues throughout the document. 887 o Various editorial updates. 889 Authors' Addresses 891 Sye Loong Keoh 892 University of Glasgow Singapore 893 Republic PolyTechnic, 9 Woodlands Ave 9 894 Singapore 838964 895 SG 897 Email: SyeLoong.Keoh@glasgow.ac.uk 899 Sandeep S. Kumar (editor) 900 Philips Research 901 High Tech Campus 34 902 Eindhoven 5656 AE 903 NL 905 Email: sandeep.kumar@philips.com 907 Oscar Garcia-Morchon 908 Philips Research 909 High Tech Campus 34 910 Eindhoven 5656 AE 911 NL 913 Email: oscar.garcia@philips.com 915 Esko Dijk 916 Philips Research 917 High Tech Campus 34 918 Eindhoven 5656 AE 919 NL 921 Email: esko.dijk@philips.com 922 Akbar Rahman 923 InterDigital 924 1000 Sherbrooke Street West 925 Montreal H3A 3G4 926 CA 928 Email: akbar.rahman@interdigital.com