idnits 2.17.1 draft-keoh-dice-multicast-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 17, 2013) is 3843 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) == Unused Reference: 'I-D.ietf-tls-oob-pubkey' is defined on line 708, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** 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-04 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-16 == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-00 Summary: 4 errors (**), 0 flaws (~~), 7 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 4 Intended status: Standards Track S.S. Kumar, Ed. 5 Expires: April 20, 2014 O. Garcia-Morchon 6 E. Dijk 7 Philips Research 8 October 17, 2013 10 DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs) 11 draft-keoh-dice-multicast-security-00 13 Abstract 15 Wireless IP-based systems will be increasingly used for building 16 control systems in the future where wireless devices interconnect 17 with each other, forming low-power and lossy networks (LLNs). The 18 CoAP/6LoWPAN standards are emerging as the de-facto protocols in this 19 area for resource-constrained devices. Both multicast and security 20 are key needs in these networks. This draft presents a method for 21 securing multicast communication in LLNs based on the DTLS which is 22 already available in CoAP devices. This draft deals with the 23 adaptation of the DTLS record layer to protect multicast group 24 communication, assuming that all group member devices are already 25 configured with the group security association. The DTLS record 26 layer implementation is used to encrypt and provide authentication to 27 multicast messages using the group keying material before sending the 28 message via IP multicast to the group. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 20, 2014. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 4 74 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.2. Security Requirements . . . . . . . . . . . . . . . . . . 5 76 3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . 7 77 3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2. Securing Multicast in LLNs . . . . . . . . . . . . . . . . 8 79 4. Multicast Data Security . . . . . . . . . . . . . . . . . . . 9 80 4.1. Sending Secure Multicast Messages . . . . . . . . . . . . 10 81 4.1.1. One Sender, Multiple Listeners Multicast Group . . . . 11 82 4.1.2. Multiple Senders, Multiple Listeners Multicast Group . 12 83 4.2. Receiving Secure Multicast Messages . . . . . . . . . . . 13 84 4.2.1. One Sender, Multiple Listeners Multicast Group . . . . 13 85 4.2.2. Multiple Senders, Multiple Listeners Multicast Group . 13 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 There is an increased use of wireless control networks in city 97 infrastructure, environmental monitoring, industrial automation, and 98 building management systems. This is mainly driven by the fact that 99 the independence from physical control wires allows for freedom of 100 placement, portability and for reducing the cost of installation as 101 less cable placement and drilling are required. Consequently, there 102 is an ever growing number of electronic devices, sensors and 103 actuators that have become Internet connected, thus creating a trend 104 towards 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 Internet services at anytime and 107 anyplace. However, the devices in such wireless control networks are 108 usually battery-operated or powered by scavenged energy, they have 109 limited computational resources (low CPU clock, small RAM and flash 110 storage) and often, the communication bandwidth is limited (e.g., 111 IEEE 802.15.4 radio), and also the transmission is unreliable. Hence, 112 such 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 would allow devices to interact with each other, group communication 117 is an important feature in LLNs that can be effectively used to 118 convey messages to a group of devices without requiring the sender to 119 perform time- and energy-consuming multiple unicast transmissions to 120 reach group members. For example, in a building control management 121 system, Heating, Ventilation and Air-Conditioning (HVAC) and lighting 122 devices can be grouped according to the layout of the building, and 123 control commands can be issued to a group of devices. Group 124 communication for LLNs has been made possible using the Constrained 125 Application Protocol (CoAP) [I-D.ietf-core-coap] based on IP- 126 multicast. 128 Currently, CoAP can be protected using Datagram Transport Layer 129 Security (DTLS) [RFC6347]. However, DTLS is mainly used to secure a 130 connection between two endpoints and it cannot be used to protect 131 multicast group communication. We believe that group communication 132 in LLNs 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). Although there have been a 135 lot of efforts in IETF to standardize mechanisms to secure multicast 136 communication, they are not necessarily suitable for LLNs which have 137 much more limited bandwidth and resources. For example, the MIKEY 138 Architecture [RFC3830] is mainly designed to facilitate multimedia 139 distribution, while TESLA [RFC4082] is proposed as a protocol for 140 broadcast authentication of the source and not for protecting the 141 confidentiality of multicast messages. 143 This draft describes an approach to use DTLS as mandated in CoAP to 144 support multicast security. It assumes that all devices in the group 145 share a security parameters and keying material, for e.g., it can be 146 distributed by a controller in the network through a DTLS unicast 147 secure channel to each device in the group. This draft focuses only 148 on the use of DTLS record layer to protect multicast messages to be 149 sent to the group, and thus providing integrity, confidentiality and 150 authenticity to the IP multicast messages in the LLN. 152 1.1. Terminology 154 This specification defines the following terminology: 156 Controller: The entity that is responsible for creating a multicast 157 group, adding members, and distributing keying material to members of 158 the group. It is also responsible for renewing/updating the 159 multicast group keying material. It is not necessarily the sender in 160 the multicast group. 162 Sender: The entity that sends multicast messages to the multicast 163 group. 165 Listener: The entity that receives multicast messages when listening 166 to a multicast IP address. 168 1.2. Outline 170 This draft is structured as follows: Section 2 motivates the proposed 171 solution with multicast use cases in LLNs and derives a set of 172 requirements. Section 3 provides an overview of the DTLS-based 173 multicast security. In Section 4, we describe the use of DTLS record 174 layer to encrypt and integrity protect multicast messages assuming 175 that all devices in the group already have a security parameters and 176 group keying material in possession. Section 5 and Section 6 describe 177 Security and IANA considerations. 179 2. Use Cases and Requirements 181 This section defines the use cases for multicast and specifies a set 182 of security requirements for these use cases. 184 2.1. Use Cases 186 As stated in the Group Communication for CoAP Internet Draft 187 [I-D.ietf-core-groupcomm] in the IETF CoRE WG, multicast is essential 188 in several application use cases. Consider a building equipped with 189 6LoWPAN [RFC4944] IP-connected lighting devices, switches, and 190 6LoWPAN border routers; the devices are organized as groups according 191 to their location in the building, e.g., lighting devices and 192 switches in a room/floor can be configured as a multicast group, the 193 switches are then used to control the lighting devices in the group 194 by sending on/off/dimming commands to the group. 6LoWPAN border 195 routers that are connected to an IPv6 network backbone (which is also 196 multicast enabled) are used to interconnect 6LoWPANs in the building. 197 Consequently, this would also enable multicast groups to be formed 198 across different subnets in the entire building. The following lists 199 a few multicast group communication uses cases in a building 200 management system; a detailed description of each use case can be 201 found in Group Communication for CoAP Internet Draft 202 [I-D.ietf-core-groupcomm]. 204 a. Lighting control: enabling synchronous operation of a group of 205 6LoWPAN connected lights in a room/floor/building. This ensures 206 that the light preset of a large group of luminaries are changed 207 at the same time, hence providing a visual synchronicity of light 208 effects to the user. 210 b. Firmware update: firmware of devices in a building or a campus 211 control application are updated simultaneously, avoiding an 212 excessive load on the LLN due to unicast firmware updates. 214 c. Parameter update: settings of devices are updated simultaneously 215 and efficiently. 217 d. Commissioning of above systems: information about the devices in 218 the local network and their capabilities can be queried and 219 requested, e.g. by a commissioning device. 221 2.2. Security Requirements 223 The Miscellaneous CoAP Group Communication Topics Internet Draft 224 [I-D.dijk-core-groupcomm-misc] has defined a set of security 225 requirements for group communication in LLNs. We re-iterate and 226 further describe those security requirements in this section with 227 respect to the use cases as presented in Section 2.1: 229 a. Multicast communication topology: We consider both one-to-many 230 and many-to-many communication topologies in this draft. The 231 one-to-many communication topology is the simplest group 232 communication scenario that would serve the needs of a typical 233 LLN. For example, in the lighting control use case, the switch 234 is the only entity that is responsible for sending control 235 commands to a group of lighting devices. These lighting devices 236 are actuators that do not issue commands to each other. In other 237 use cases, a many-to-many multicast communication topology would 238 be required, in particular multiple sensors and actuators are 239 part of a multicast group and these sensors will trigger events 240 to the group in order to notify the interested parties. Devices 241 in the group could also send commands in order to trigger some 242 actions on other devices in the group. 244 b. Establishment of a Group Security Association (GSA) [RFC3740]: A 245 secure channel must be used to distribute keying material, 246 multicast security policy and security parameters to members of a 247 multicast group. A GSA must be established between the 248 controller (which manages the multicast group and may be a 249 different device than the sender) and the group members. The 250 6LoWPAN border router, a device in the 6LoWPAN, or a remote 251 server outside the 6LoWPAN could play the role of controller for 252 distributing keying materials. Since the keying material is used 253 to derive subsequent group keys to protect multicast messages, it 254 is important that it is encrypted, integrity protected and 255 authenticated when it is distributed. However, this is out of 256 scope of this draft, and it is anticipated that an activity in 257 IETF dedicated to the design of a generic key management scheme 258 for the LLN will be started in the future. 260 c. Multicast security policy: All group members must use the same 261 ciphersuite to protect the authenticity, integrity and 262 confidentiality of multicast messages. The ciphersuite can 263 either be negotiated or set by the controller and then 264 distributed to the group members. It is generally very complex 265 and difficult to require all devices to negotiate and agree with 266 each other on the ciphersuite to be used, it is therefore more 267 effective that the multicast security policy is set by the 268 controller. 270 d. Multicast data group authentication: It is essential to ensure 271 that a multicast message is originated from a member of the 272 group. The multicast group key which is known to all group 273 members is used to provide authenticity to the multicast messages 274 (e.g., using a Message Authentication Code, MAC). This assumes 275 that only the sender of the multicast group is sending the 276 message, and that all other group members are trusted not to 277 tamper with the multicast message. 279 e. Multicast data source authentication: Source authenticity is 280 optional. It can typically be provided using public-key 281 cryptography in which every multicast message is signed by the 282 sender. This requires much higher computational resources on 283 both the sender and the receivers, thus incurring too much 284 overhead and computational requirements on devices in LLNs. 285 Alternatively, a lightweight broadcast authentication, i.e., 286 TESLA [RFC4082] can be deployed, however it requires devices in 287 the multicast group to have a trusted clock and have the ability 288 to loosely synchronize their clocks with the sender. 289 Consequently, given that the targeted devices have limited 290 resources, and the need for source authenticity is not critical, 291 it is advocated that source authenticity is made optional. 293 f. Multicast data integrity: A group level integrity is required to 294 ensure that messages have not been tampered with by attackers who 295 are not members of the multicast group. 297 g. Multicast data confidentiality: Multicast message may be 298 encrypted, as some control commands when sent in the clear could 299 pose privacy risks to the users. 301 h. Multicast data replay protection: It must not be possible to 302 replay a multicast message as this would disrupt the operation of 303 the group communication. 305 i. Multicast key management: Group keys used to protect the 306 multicast communication must be renewed periodically. When 307 members have left the multicast group, the group keys might be 308 leaked; and when a device is detected to have been compromised, 309 this also implies that the group keys could have been compromised 310 too. In these situations, the controller must perform a re-key 311 protocol to renew the group keys. This work will be addressed as 312 part of the key management for LLN in the future based on 313 [RFC3740] and [RFC4046]. 315 3. Overview of DTLS-based Secure Multicast 317 The goal of this draft is to secure COAP group communication over 318 6LoWPAN networks, by extending the use of the DTLS security protocol 319 to allow for the use of DTLS record layer to provide protection to 320 multicast messages. The IETF CoRE WG has selected DTLS [RFC6347] as 321 the default must-implement security protocol for securing CoAP, 322 therefore it is conceivable that DTLS can be extended to facilitate 323 CoAP-based group communication. Reusing DTLS for different purposes 324 while guaranteeing the required security properties can avoid the 325 need to implement multiple security protocols and this is especially 326 beneficial when the target deployment consists of 327 resource-constrained embedded devices. This section first describes 328 group communication based on IP multicast, and subsequently sketches 329 a solution for securing group communication using DTLS. 331 3.1. IP Multicast 333 Devices in the LLN are categorized into two roles, (1) sender and (2) 334 listener. Any node in the LLN may have one of these roles, or both 335 roles. The application(s) running on a device basically determine 336 these roles by the function calls they execute on the IP stack of the 337 device. 339 In principle, a sender or listener does not require any prior access 340 procedures or authentication to send or listen to a multicast message 341 [RFC5374]. A sender to an IP multicast group sets the destination of 342 the packet to an IP address that has been allocated for IP multicast. 343 A device becomes a listener by "joining" to the specific IP multicast 344 group by registering with a network routing device, signaling its 345 intent to receive packets sent to that particular IP multicast group. 346 Any device can in principle decide to listen to any IP multicast 347 address. This also means applications on the other devices do not 348 know, or do not get notified, of new senders or listeners in the LLN. 350 ++++ 351 |. | 352 --| ++++ 353 ++++ / ++|. | 354 |A |---------| ++++ 355 | | \ ++|B | 356 ++++ \-----| | 357 Sender ++++ 358 Listeners 360 Figure 3.1: The roles of nodes in a one-to-many multicast 361 communication topology 363 3.2. Securing Multicast in LLNs 365 A controller in an LLN creates a multicast group. The controller may 366 be hosted by a remote server, or a border router that creates a new 367 group over the network. In some cases, devices may be configured 368 using a commissioning tool that mediates the communication between 369 the devices and the controller. The controller in the network can be 370 discovered by the devices using various methods defined in 371 [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and Resource 372 Directory [I-D.ietf-core-resource-directory]. The controller 373 communicates with individual device to add them to the new group. 374 Additionally, the controller can distribute a Group Security 375 Association (GSA) consisting of keying material, security policies 376 and security parameters to use, to all the member devices in the 377 group, e.g., by establishing a secure DTLS channel with each device. 378 As mentioned previously, a standardized way of performing key 379 management for LLN is out of scope of this draft, and we assumes that 380 each device in the group has been configured with a GSA using a. 382 Senders in the group can encrypt and authenticate application 383 messages using the keying material in the DTLS record layer before it 384 is sent using IP multicast. For example, a CoAP message addressed to 385 a multicast group is protected using DTLS record layer and then sent 386 to a multicast group. The listeners when receiving the message, use 387 the multicast IP destination address (i.e., Multicast identifier) to 388 look up the GSA needed for that connection. The received message is 389 decrypted and the authenticity is verified using the keying material 390 for that connection. 392 4. Multicast Data Security 394 This section describes in detail the use of DTLS record layer to 395 secure multicast messages. This assumes that group membership has 396 been configured by the controller, and all devices in the group have 397 been configured with the GSA. Since the exact details of the group 398 key management are outside the scope of this draft, we assume that 399 the GSA can be used to derive the same SecurityParameters structure 400 as defined in [RFC5246] for all devices. Additional ciphersuites may 401 need to be defined to convey the bulk cipher algorithm, MAC algorithm 402 and key lengths within the key management protocol. We provide two 403 such examples of ciphersuites that could be defined as part of a 404 future key management mechanism: 406 Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2} 407 Ciphersuite MTS_WITH_NULL_SHA256 = {TBD3, TBD4} 409 Ciphersuite MTS_WITH_AES_128_CCM_8 is used to provide 410 confidentiality, integrity and authenticity to the multicast messages 411 where the encryption algorithm is AES [AES], key length is 128-bit, 412 and the authentication function is CCM [RFC6655] with a Message 413 Authentication Code (MAC) length of 8 bytes. Similar to RFC4785 414 [RFC4785], the ciphersuite MTS_WITH_NULL_SHA is used when 415 confidentiality of multicast messages is not required, it only 416 provides integrity and authenticity protection to the multicast 417 message. When this ciphersuite is used, the message is not encrypted 418 but the MAC must be included in which it is computed using a HMAC 419 [RFC2104] that is based on Secure Hash Function SHA256 [SHA]. 420 Depending on the future needs, other ciphersuites with different 421 cipher algorithms and MAC length may be supported. 423 The SecurityParameters.ConnectionEnd should be set to "server" for 424 senders and "client" for listeners. The current read and write states 425 can be derived from SecurityParameters by generating the six key 426 material items: 428 client write MAC key 429 server write MAC key 430 client write encryption key 431 server write encryption key 432 client write IV 433 server write IV 435 This requires that the client_random and server_random within the 436 SecurityParameters are set same for all devices as part of the key 437 management protocol to derive the same keying material for all 438 devices in the group with the PRF function defined in Section 6.3 of 439 [RFC5246] . Alternatively, the key management protocol could directly 440 provide the above six key material to all group devices as part of 441 the GSA. 443 The current read and write states are instantiated for all group 444 members based on the keying material; senders use "server write" 445 parameters for the write state and listeners use "server write" 446 parameters for the read state. Additionally each connection state 447 contains the sequence number which is incremented for each record 448 sent; the first record sent has the sequence number 0. 450 For the optional multicast data source authentication, the sender can 451 sign the message using public key cryptography at the application 452 layer and send it as the multicast message in the DTLS record 453 payload. This option is independent of the DTLS layer and outside the 454 scope of this draft. 456 4.1. Sending Secure Multicast Messages 458 All messages addressed to the multicast group must be secured using 459 "server write" parameters. Using the DTLS record layer, multicast 460 messages are encrypted and protected using a Message Authentication 461 Code (MAC) according to the chosen ciphersuite. The authenticated 462 encrypted message is passed down to the lower layer of the IP 463 protocol stack for transmission to the multicast address. 465 As described in the previous section, the example ciphersuite 466 MTS_WITH_AES_128_CCM_8 defines that the multicast message must be 467 encrypted using AES with a 128-bit "server write encryption key". 468 Since the CCM mode of operation is used for authenticated encryption, 469 the same key is used to compute the MAC. As for the ciphersuite 470 example MTS_WITH_NULL_SHA, the multicast message must not be 471 encrypted, but a MAC must be computed using the "server write MAC 472 key". 474 +--------+-------------------------------------------------+ 475 | | +--------+------------------------------------+ | 476 | | | | +-------------+------------------+ | | 477 | | | | | | +--------------+ | | | 478 | IP | | UDP | | DTLS Record | | multicast | | | | 479 | header | | header | | Header | | message | | | | 480 | | | | | | +--------------+ | | | 481 | | | | +-------------+------------------+ | | 482 | | +--------+------------------------------------+ | 483 +--------+-------------------------------------------------+ 484 Figure 4.1: Sending a multicast message protected using DTLS Record 485 Layer 487 4.1.1. One Sender, Multiple Listeners Multicast Group 489 This section describes the use of DTLS record layer to protect a one- 490 sender, multiple-listeners multicast group communication. In this 491 setting, it is the responsibility of the controller which configures 492 the group membership to ensure that there is only one sender in a 493 multicast group and other devices never send multicast messages to 494 the same group in order to ensure the security properties of the 495 multicast messages. This is especially a concern in AEAD cipher 496 suites if multiple senders reuse the same nonce for encryption as 497 described in Section 5.1.1 in [RFC5116]. 499 The following illustrates the structure of the DTLS record layer 500 header, the epoch and sequence number are used to ensure message 501 freshness and to detect message replays. As there is only one sender 502 in the multicast group, the sender is responsible for maintaining and 503 manipulating the epoch and sequence number when sending multicast 504 messages. The receivers in the group are "trusted" not to tamper 505 with these parameters. 507 +---------+---------+--------+--------+--------+------------+-------+ 508 | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | 509 +---------+---------+--------+--------+--------+------------+-------+ 510 | Content | Version | Epoch | Seq | Length | Ciphertext | MAC | 511 | Type | Ma | Mi | | Number | | (Enc) | | 512 +---------+---------+--------+--------+--------+------------+-------+ 514 Figure 4.2: The DTLS record layer header and optionally encrypted 515 payload and MAC 517 The sequence number is initialized to 0, and it is increased by one 518 whenever the sender sends a new multicast record message. This is 519 the standard behavior of the current DTLS in order to detect message 520 replay. The sender or the controller can increase the epoch number 521 by sending a ChangeCipherSpec message whenever the sequence number 522 has been exhausted, or whenever the ciphersuite has been changed in 523 order to reset the sequence number. Finally, the multicast message 524 is protected (encrypted if needed, and authenticated with a MAC) 525 using the "server write" parameters. 527 4.1.2. Multiple Senders, Multiple Listeners Multicast Group 529 There is a need to support multi-senders in group communication. In 530 particular, in a lighting network there are multiple presence sensors 531 that would be assigned the sender role as they are responsible for 532 multicasting the presence information to the luminaries in the group. 533 In this section, we outline an approach to enable all senders in the 534 group to securely send information using a common group key, while 535 preserving the freshness and integrity of the messages. 537 In addition to configuring each device in the group with the GSA, the 538 controller can assign a unique SenderID (represented as two octets) 539 to each device which has the sender role in the group. The list of 540 SenderIDs are then distributed to all the group members by the 541 controller. This is an additional group setup procedure that should 542 be performed to ensure that each sender in the group can be uniquely 543 identified by the group members. Alternatively, this setup procedure 544 can be eliminated by allowing senders to derive their SenderIDs 545 themselves based on the device's IPv6 or MAC address, or even 546 randomly. The specific method to be used is not defined here, except 547 care should be taken that it would lead to a high probability of 548 unique SenderIDs for all senders within the specific multicast group. 549 To overcome potential clash in SenderIDs, a back-off mechanism is 550 defined in the Security Considerations section. 552 The existing DTLS record layer header is adapted such that the 6-byte 553 sequence number field is split into a 2-byte SenderID field and a 4- 554 byte "truncated" sequence number field. Each sender in the group uses 555 its own unique SenderID in the DTLS record layer header when sending 556 a multicast message to the group. It also manages its own epoch and 557 "truncated" sequence number in the "server write" connection state, 558 hence they do not need to synchronize them with other senders in the 559 group. Figure 4.3 illustrates the adapted DTLS record layer header. 561 +---------+---------+--------+--------+----------+--------+ 562 | 1 Byte | 2 Byte | 2 Byte | 2 Byte | 4 Byte | 2 Byte | 563 +---------+---------+--------+--------+----------+--------+ 564 | Content | Version | Epoch | Sender | "T." Seq | Length | 565 | Type | Ma | Mi | | ID | Number | | 566 +---------+---------+--------+--------+----------+--------+ 568 Figure 4.3: The adapted DTLS record layer header 570 4.2. Receiving Secure Multicast Messages 572 4.2.1. One Sender, Multiple Listeners Multicast Group 574 When a listeners receives a protected multicast message from the 575 sender, it looks up the corresponding "client read" connection state 576 based on the multicast IP destination of the packet. This is 577 fundamentally different from standard DTLS logic in that the current 578 "client read" connection state is bound to the source IP address. 579 However, given that this is a one sender- multiple listeners 580 communication topology, it is possible to bind the current "client 581 read" connection state to the source IP address if it is already 582 known to all listeners. Therefore a lookup based on the source IP 583 address is also possible in this case. 585 The listeners authenticate and decrypt the multicast message using 586 the "server write" keys. The verification of MAC ensures that the 587 payload and the DTLS Record Layer header have not been tampered with. 588 As there is only one sender, and all other group members are 589 "trusted", only the sender is able to manipulate the epoch and the 590 sequence number, hence once the DTLS header has been authenticated, 591 the epoch and the sequence number can be sufficiently trusted to 592 detect any message replay. 594 4.2.2. Multiple Senders, Multiple Listeners Multicast Group 596 Listener devices in a multi-senders multicast group, need to store 597 multiple "client read" connection states for the different senders 598 linked to the SenderIDs. The keying material is same for all senders 599 however the epoch and the "truncated" sequence number of the last 600 received packets needs to be kept different for different senders. 601 The listeners first perform a "server write" keys lookup by using the 602 multicast IP destination address of the packet. By knowing the keys, 603 the listeners decrypt and check the MAC of the message. This 604 guarantees that no one has spoofed the SenderID, as it is protected 605 by the MAC. Subsequently, by authenticating the SenderID field, the 606 listeners retrieve the "client read" connection state which contains 607 the last stored epoch and "truncated" sequence number of the sender, 608 which is used to check the freshness of the message received. The 609 listeners must ensure that the epoch is the same and "truncated" 610 sequence number in the message received is higher than the stored 611 value, otherwise the message is discarded. As each sender manages 612 its own epoch and sequence number, receivers are confident that these 613 values are reliable. Once the authenticity and freshness of the 614 message have been checked, the listeners can pass the message to the 615 higher layer protocols. The epoch and the sequence number in the 616 corresponding "client read" connection state are updated as well. 618 5. IANA Considerations 620 tbd 622 Note to RFC Editor: this section may be removed on publication as an 623 RFC. 625 6. Security Considerations 627 This document discusses various design aspects for multicast security 628 in LLNs. As such this document, in entirety, concerns security. 630 Section 4.1.2 with multiple senders require that SenderIDs are unique 631 to maintain the security properties of the DTLS record layer 632 messages. However in the event that two or more senders are 633 configured with the same SenderID, a mechanism needs to be present to 634 avoid a security weakness and recover from the situation. One such 635 mechanism is that all senders of the mutlicast group are also 636 listeners. This allows a sender which receives a packet from a 637 different device with its own SenderID in the DTLS header to be aware 638 of a clash in SenderID. Once aware, the sender can inform the 639 controller on a secure channel about the clash along with the source 640 IP address. The controller can then provide a different SenderID to 641 either device or both. 643 Section 4.1.2 additionally truncates the sequence number from 6 644 octets to 4 octets. This reduction of the sequence number space 645 should be taken into account to ensure that epoch is incremented 646 before the "truncated" sequence number wraps over. This should be 647 done with an appropriate key management mechanism which is not 648 defined in this draft. 649 7. Acknowledgements 651 The authors greatly acknowledge discussion, comments and feedback 652 from Dee Denteneer, Peter van der Stok and Zach Shelby. Additionally 653 thank David McGrew for suggesting options for recovering from a 654 SenderID clash. We also appreciate prototyping and implementation 655 efforts by Pedro Moreno Sanchez who worked as an intern at Philips 656 Research. 658 8. References 660 8.1. Normative References 662 [AES] National Institute of Standards and Technology, , 663 "Specification for the Advanced Encryption Statndard 664 (AES)", FIPS 197, Nov 2001. 666 [SHA] National Institute of Standards and Technology, , "Secure 667 Hash Standard", FIPS 180-2, Aug 2002. 669 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 670 Hashing for Message Authentication", RFC 2104, February 671 1997. 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 677 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 678 August 2004. 680 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 681 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 683 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 684 Security Version 1.2", RFC 6347, January 2012. 686 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 687 Transport Layer Security (TLS)", RFC 6655, July 2012. 689 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 690 Encryption", RFC 5116, January 2008. 692 8.2. Informative References 694 [I-D.dijk-core-groupcomm-misc] 695 Dijk, E. and A. Rahman, "Miscellaneous CoAP Group 696 Communication Topics", draft-dijk-core-groupcomm-misc-04 697 (work in progress), June 2013. 699 [I-D.ietf-core-coap] 700 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 701 Application Protocol (CoAP)", draft-ietf-core-coap-18 702 (work in progress), June 2013. 704 [I-D.ietf-core-groupcomm] 705 Rahman, A. and E. Dijk, "Group Communication for CoAP", 706 draft-ietf-core-groupcomm-16 (work in progress), October 2013. 708 [I-D.ietf-tls-oob-pubkey] 709 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 710 T. Kivinen, "Out-of-Band Public Key Validation for 711 Transport Layer Security (TLS)", draft-ietf-tls-oob- 712 pubkey-09 (work in progress), July 2013. 714 [I-D.ietf-core-resource-directory] 715 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 716 Directory", draft-ietf-core-resource-directory-00 (work 717 in progress), June 2013. 719 [I-D.vanderstok-core-dna] 720 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 721 Naming, and Addressing", draft-vanderstok-core-dna-02 722 (work in progress), July 2012. 724 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 725 Briscoe, "Timed Efficient Stream Loss-Tolerant 726 Authentication (TESLA): Multicast Source Authentication 727 Transform Introduction", RFC 4082, June 2005. 729 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 730 Ciphersuites with NULL Encryption for Transport Layer 731 Security (TLS)", RFC 4785, January 2007. 733 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 734 "Transmission of IPv6 Packets over IEEE 802.15.4 735 Networks", RFC 4944, September 2007. 737 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 738 Discovery", RFC 6763, February 2013. 740 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 741 Architecture", RFC 3740, March 2004. 743 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 744 Extensions to the Security Architecture for the Internet 745 Protocol", RFC 5374, November 2008. 747 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 748 "Multicast Security (MSEC) Group Key Management 749 Architecture", RFC 4046, April 2005. 751 Authors' Addresses 753 Sye Loong Keoh 754 University of Glasgow Singapore 755 Republic PolyTechnic, 9 Woodlands Ave 9 756 Singapore 838964 757 SG 759 Email: SyeLoong.Keoh@glasgow.ac.uk 761 Sandeep S. Kumar 762 Philips Research 763 High Tech Campus 34 764 Eindhoven 5656 AE 765 NL 767 Email: sandeep.kumar@philips.com 769 Oscar Garcia-Morchon 770 Philips Research 771 High Tech Campus 34 772 Eindhoven 5656 AE 773 NL 775 Email: oscar.garcia@philips.com 777 Esko Dijk 778 Philips Research 779 High Tech Campus 34 780 Eindhoven 5656 AE 781 NL 783 Email: esko.dijk@philips.com