idnits 2.17.1 draft-kumar-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 407 has weird spacing: '...gorithm bul...' == Line 572 has weird spacing: '...gorithm bul...' -- The document date (March 09, 2015) is 3335 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: '48' on line 601 -- Looks like a reference, but probably isn't: '32' on line 602 == Unused Reference: 'RFC5116' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC5288' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'RFC6655' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'I-D.dijk-core-groupcomm-misc' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'I-D.mcgrew-aero' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC4785' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'RFC5374' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 832, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Experimental RFC: RFC 7390 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-02 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE Working Group S. Kumar 3 Internet-Draft Philips Research 4 Intended status: Standards Track R. Struik 5 Expires: September 10, 2015 Struik Security Consultancy 6 March 09, 2015 8 Transport-layer Multicast Security for Low-Power and Lossy Networks 9 (LLNs) 10 draft-kumar-dice-multicast-security-00 12 Abstract 14 CoAP and 6LoWPAN are fast emerging as the de-facto protocol standards 15 in the area of resource-constrained devices forming Low-power and 16 Lossy Networks (LLNs). Unicast communication in such networks are 17 secured at the transport layer using DTLS, as mandated by CoAP. For 18 various applications, IP multicast-based group communications in such 19 networks provide clear advantages. However, at this point, CoAP does 20 not specify how to secure group communications in an interoperable 21 way. This draft specifies two methods for securing CoAP-based group 22 communication at the transport layer and targets deployment scenarios 23 that may require group authentication, respectively source 24 authentication. The specification leverages the fact that DTLS is 25 already used as the mechanism of choice to secure unicast 26 communications and allows group communications security to be 27 implemented as an extension of DTLS record layer processing, thereby 28 minimizing incremental implementation cost. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 10, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Group Communication Use Cases . . . . . . . . . . . . . . 5 69 2.2. Security Requirements . . . . . . . . . . . . . . . . . . 6 70 3. Overview of Transport level Secure Multicast . . . . . . . . 7 71 3.1. Setting up Group Security Association . . . . . . . . . . 8 72 3.2. Group Communication packets . . . . . . . . . . . . . . . 8 73 4. Group-level Data Authenticity . . . . . . . . . . . . . . . . 9 74 4.1. Group message format . . . . . . . . . . . . . . . . . . 11 75 4.2. Group message processing . . . . . . . . . . . . . . . . 11 76 4.2.1. Sending Secure Multicast Messages . . . . . . . . . . 11 77 4.2.2. Receiving Secure Multicast Messages . . . . . . . . . 12 78 5. Source-level Data Authenticity . . . . . . . . . . . . . . . 12 79 5.1. Group message format . . . . . . . . . . . . . . . . . . 14 80 5.2. Group message processing . . . . . . . . . . . . . . . . 15 81 5.2.1. Sending Secure Multicast Messages . . . . . . . . . . 15 82 5.2.2. Receiving Secure Multicast Messages . . . . . . . . . 16 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 6.1. Late joiners . . . . . . . . . . . . . . . . . . . . . . 16 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 8.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 There is an ever growing number of electronic devices, sensors and 94 actuators that have become wireless and Internet connected, thus 95 creating a trend towards the Internet-of-Things (IoT). These 96 connected devices are equipped with communication capability based on 97 CoAP [RFC7252] and 6LoWPAN [RFC6347] standards that enables them to 98 interact with each other as well as with the wider Internet services. 99 However, the devices in such wireless networks are characterized by 100 power constraints (as these are usually battery-operated), have 101 limited computational resources (low CPU clock, small RAM and flash 102 storage) and often, the communication bandwidth is limited and 103 unreliable (e.g., IEEE 802.15.4 radio). Hence, such wireless control 104 networks are also known as Low-power and Lossy Networks (LLNs). 106 In addition to the usual device-to-device unicast communication that 107 would allow devices to interact with each other, group communication 108 is an important feature in LLNs. It is more effective in LLNs to 109 convey messages to a group of devices without requiring the sender to 110 perform multiple time and energy consuming unicast transmissions to 111 reach each individual group member. For example, in a lighting 112 control system, lighting devices are often grouped according to the 113 layout of the building, and control commands are issued 114 simultaneously to a group of devices. Group communication for LLNs 115 is based on the CoAP sent over IP- multicast [RFC7390]. 117 Currently, CoAP messages are protected using Datagram Transport Layer 118 Security (DTLS) [RFC6347]. However, DTLS is mainly used to secure a 119 connection between two endpoints and it cannot be used to protect 120 multicast group communication. Group communication in LLNs is 121 equally important and should be secured as it is also vulnerable to 122 the usual attacks over the air (eavesdropping, tampering, message 123 forgery, replay, etc.). Although there have been a lot of efforts in 124 IETF to standardize mechanisms to secure multicast communication 125 [RFC3830] [RFC4082] [RFC3740] [RFC4046] [RFC4535], they are not 126 necessarily suitable for LLNs which have much more limited bandwidth 127 and resources. For example, the MIKEY Architecture [RFC3830] is 128 mainly designed to facilitate multimedia distribution, while TESLA 129 [RFC4082] is proposed as a protocol for broadcast authentication of 130 the source with good time synchronization. [RFC3740] and [RFC4046] 131 provide reference architectures for multicast security. [RFC4535] 132 describes Group Secure Association Key Management Protocol (GSAKMP), 133 a security framework for creating and managing cryptographic groups 134 on a network which can be reused for key management in our context 135 with any needed adaptation for LLNs. 137 An existing IP multicast security protocol could be used after 138 profiling as shown in [I-D.mglt-dice-ipsec-for-application-payload]. 140 However since DTLS is already mandated for CoAP unicast, this would 141 require an additional security protocol to be implemented on 142 constrained devices. This draft describes an alternative transport 143 layer approach by reusing already available functionalities in DTLS. 144 This allows CoAP group communication security to be implemented with 145 minimal additional resources as an extension to the DTLS record layer 146 processing. 148 1.1. Terminology 150 This specification uses the following terminology: 152 o Group Controller: Entity responsible for creating a multicast 153 group and establishing security associations among authorized 154 group members. This entity is also responsible for renewing/ 155 updating multicast group keys and related policies. 157 o Sender: Entity that sends data to the multicast group. In a 158 1-to-N multicast group, only a single sender transmits data to the 159 group; in an M-to-N multicast group (where M and N do not 160 necessarily have the same value), M group members are senders. 162 o Listener: Entity that receives multicast messages when listening 163 to a multicast IP address. 165 o Security Association (SA): Set of policies and cryptographic 166 keying material that together provide security services to network 167 traffic matching this policy [RFC3740]. Here, a Security 168 Association usually includes the following attributes: 170 * selectors, such as source and destination transport addresses; 172 * properties, such as identities; 174 * cryptographic policy, such as the algorithms, modes, key 175 lifetimes, and key lengths used for authentication or 176 confidentiality; 178 * keying material for authentication, encryption and signing. 180 o Group Security Association: A bundling of security associations 181 (SAs) that together define how a group communicates securely 182 [RFC3740]. 184 o Keying material: Data specified as part of the SA that is 185 necessary to establish and maintain a cryptographic security 186 association, such as keys, key pairs, and IVs [RFC4949]. 188 o Group authentication: Evidence that a received group message 189 originated from some member of this group. This provides 190 assurances that this message was not tampered with by an adversary 191 outside this group, but does not pinpoint who precisely in the 192 group originated this message. 194 o Source authentication: Evidence that a received group message 195 originated from a specifically identified group member. This 196 provides assurances that this message was not tampered with by any 197 other group member or an adversary outside this group. 199 1.2. Outline 201 The remainder of this draft is organized as follows. Section 2 202 provides use cases for group communications with LLNs. Section 3 203 provides an overview of transport layer secure multicasting, while 204 Section 4 and Section 5 provide the detailed specifications for 205 securing multicast messaging providing for group authentication and 206 source authentication, respectively. 208 2. Use Cases 210 This section introduces some use cases for group communications in 211 LLNs and identifies a set of security requirements for these use 212 cases. 214 2.1. Group Communication Use Cases 216 "Group Communication for CoAP" [RFC7390] provides the necessary 217 background for multicast-based CoAP communication in LLNs and the 218 interested reader is encouraged to first read this document to 219 understand the non-security related details. This document also 220 lists a few group communication uses cases with detailed 221 descriptions. 223 a. Lighting control: Consider a building equipped with 6LoWPAN IP- 224 connected lighting devices, switches, and 6LoWPAN border routers. 225 The devices are organized in groups according to their physical 226 location in the building, e.g., lighting devices and switches in 227 a room or corridor can be configured as a single multicast group. 228 The switches are then used to control the lighting devices in the 229 group by sending on/off/dimming commands to all lighting devices 230 in the group. 6LoWPAN border routers that are connected to an 231 IPv6 network backbone (which is also multicast-enabled) are used 232 to interconnect 6LoWPANs in the building. Consequently, this 233 would also enable logical multicast groups to be formed even if 234 devices in the lighting group may be physically in different 235 subnets (e.g. on wired and wireless networks). Group 236 communications enables synchronous operation of a group of 237 6LoWPAN connected lights ensuring that the light preset (e.g. 238 dimming level or color) of a large group of luminaires are 239 changed at the same perceived time. This is especially useful 240 for providing a visual synchronicity of light effects to the 241 user. 243 b. Integrated Building control: enabling Building Automation and 244 Control Systems to control multiple heating, ventilation and air- 245 conditioning units to pre-defined presets. 247 c. Software and Firmware updates: software and firmware updates 248 often comprise quite a large amount of data and can, thereby, 249 overload an LLN that is otherwise typically used to communicate 250 only small amounts of data infrequently. Multicasting such 251 updated data to a larger group of devices at once, rather than 252 sending this as unicast messages to each individual device in 253 turn, can significantly reduce the network load and may also 254 decrease the overall time latency for propagating this data to 255 all devices. With updates of relatively large amounts of data, 256 securing the individual messages is important, even if the 257 complete update itself is secured as a whole, since checking 258 individual received data piecemeal for tampering avoids that 259 devices store large amounts of partially corrupted data and may 260 detect tampering hereof only after all data has been received. 262 d. Parameter and Configuration update: settings of a group of 263 similar devices are updated simultaneously and efficiently. 264 Parameters could be, for example, network load management or 265 network access controls 267 e. Commissioning of LLN systems: querying information about the 268 devices in the local network and their capabilities, e.g., by a 269 commissioning device. 271 f. Emergency broadcast: a particular emergency related information 272 (e.g. natural disaster) is relayed to multiple devices. 274 2.2. Security Requirements 276 "Group Communications for CoAP" [RFC7390] already defines a set of 277 security requirements for group communication in LLNs. We re-iterate 278 and further describe those security requirements in this section with 279 respect to the use cases: 281 a. Group communication topology: We consider both 1-to-N (one sender 282 with multiple listeners) and M-to-N (multiple senders with 283 multiple listeners) communication topologies. The 1-to-N 284 communication topology is the simplest group communication 285 scenario that would serve the needs of a typical LLN. For 286 example, in a simple lighting control use case, a switch would be 287 the only entity that is responsible for sending control commands 288 to a group of lighting devices. In more advanced lighting 289 control use cases, an M-to-N communication topology would be 290 required, for example if multiple sensors (presence or day-light) 291 are responsible to trigger events to a group of lighting devices. 293 b. Group-level data confidentiality: Data confidentiality may be 294 required if privacy sensitive data is exchanged in the group. 295 Confidentiality is only required at the group level since any 296 member of the group can decrypt the message. 298 c. Group-level authentication and integrity: In certain use cases, 299 it is sufficient to ensure the weaker group-level authentication 300 of group messages. Such cases include M-to-N communication 301 topology where M senders all perform similar roles and where M is 302 of approximately the same size as group size N. Group-level 303 authentication is achieved by a single group key that is known to 304 all group members and used to provide authenticity to the group 305 messages (e.g., using a Message Authentication Code, MAC). 307 d. Source-level authentication: Certain use-cases require a stronger 308 source-level authentication of group messages. This is 309 especially needed in M-to-N communication topology, where M is 310 closer to 1. Source authentication can be provided using public- 311 key cryptography in which every group message is signed by its 312 sender. 314 3. Overview of Transport level Secure Multicast 316 The IETF CoRE WG has selected DTLS [RFC6347] as the default must- 317 implement security protocol for securing CoAP unicast traffic. The 318 goal of this draft is to secure CoAP Group communication with minimal 319 additional overhead on resource-constrained embedded devices. We 320 propose to reuse some of the functionalities of DTLS such that a 321 transport-layer multicast security solution can be implemented by 322 extending the DTLS implementation (that already exists on these 323 devices) with minimal adaptation. 325 We first give a general overview of how the transport-layer multicast 326 security can be implemented and then provide two variations: one for 327 group authentication and the other for source authentication. 329 3.1. Setting up Group Security Association 331 A group controller in an LLN creates a multicast group. The group 332 controller may be hosted by a remote server, or a border router that 333 creates a new group over the network. In some cases, devices may be 334 configured using a commissioning tool that mediates the communication 335 between the devices and the group controller. The controller in the 336 network can be discovered by the devices using various methods 337 defined in [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and 338 Resource Directory [I-D.ietf-core-resource-directory]. The group 339 controller communicates with individual device in unicast to add them 340 to the new group. This configuration can be done as unicast CoAP 341 based messages sent over a DTLS secured link. The CoAP resource on 342 the devices that is used to configure the group [RFC7390]can also be 343 used to configure the devices with the Group Security Association 344 (GSA) consisting of keying material, security policies security 345 parameters and ciphersuites. [Note: The details of the CoAP based 346 configuration needs further elaboration in a new revision.] 348 3.2. Group Communication packets 350 Senders in the group can authenticate and/or encrypt the CoAP group 351 messages using the keying material in the GSA. The authenticated 352 and/or encrypted message contains a security header which includes a 353 replay counter. This is passed down to the lower layer of the IPv6 354 protocol stack for transmission to the multicast address as depicted 355 in Figure 1. 357 +--------+-+---------------------------------------------+-+ 358 | | +---------------------------------------------+ | 359 | | | | +--------------------------------+ | | 360 | | | | | | +--------------+ | | | 361 | IP | | UDP | | Security | | multicast | | | | 362 | header | | header | | Header | | message | | | | 363 | | | | | | +--------------+ | | | 364 | | | | +--------------------------------+ | | 365 | | +---------------------------------------------+ | 366 +--------+-+---------------------------------------------+-+ 368 Figure 1: Sending a multicast message protected using DTLS Record 369 Layer 371 The listeners when receiving the message, use the multicast IPv6 372 destination address and port (i.e., multicast group identifier) to 373 derive the corresponding GSA needed for that group connection. The 374 received message's authenticity is verified and/or decrypted using 375 the keying material for that connection and the security header. 377 4. Group-level Data Authenticity 379 This section describes in detail the group level authenticity 380 mechanism for transport level secure group messages. We assume that 381 group membership has been configured by the group controller as 382 described in Section 3.1 , and all member devices in the group have 383 the GSA. The group-level authentication GSA contains the following 384 elements: 386 CipherSuite 387 server write MAC key 388 server write encryption key 389 server write IV 390 SenderID 392 The group controller chooses a CipherSuite for the GSA based on 393 knowledge that all devices in the group support the specific 394 CipherSuite. Based on the CipherSuite selected, one or more of the 395 other elements may be empty. For example, if only using authenticity 396 only ciphersuite, the encryption key and IV is not sent, similarly if 397 an AEAD ciphersuite is used then MAC key is not sent. The SenderID 398 is only sent to devices which are senders in the group 400 The GSA is used to instantiate the needed elements of the 401 "SecurityParameters" structure (shown below) as defined in [RFC5246] 402 for all devices. 404 struct { 405 ConnectionEnd entity; 406 PRFAlgorithm prf_algorithm; 407 BulkCipherAlgorithm bulk_cipher_algorithm; 408 CipherType cipher_type; 409 uint8 enc_key_length; 410 uint8 block_length; 411 uint8 fixed_iv_length; 412 uint8 record_iv_length; 413 MACAlgorithm mac_algorithm; 414 uint8 mac_length; 415 uint8 mac_key_length; 416 CompressionMethod compression_algorithm; 417 opaque master_secret[48]; 418 opaque client_random[32]; 419 opaque server_random[32]; 420 } SecurityParameters; 422 a. SecurityParameters.entity is set to ConnectionEnd.server for 423 senders and ConnectionEnd.client for listeners. 425 b. bulk_cipher_algorithm, cipher_type, enc_key_length, block_length, 426 fixed_iv_length, record_iv_length, mac_algorithm, mac_length, and 427 mac_key_length is set based on the ciphersuite present in the 428 GSA. 430 c. cipher_type is CipherType.aead (if confidentiality is needed) 432 d. enc_key_length, block_length are sent in the GSA. 434 e. prf_algorithm, compression_algorithm, master_secret[48], 435 client_random[32], and server_random[32] are not used and 436 therefore not set. 438 The current read and write states are then instantiated for all group 439 members based on the keying material in the GSA and according to 440 their roles: 442 a. Listeners (ConnectionEnd.client) directly use "server write" 443 parameters in the GSA for instantiating the current read state. 444 The write state is not instantiated and not used. 446 b. Senders (ConnectionEnd.server) first pass each of the "server 447 write" parameters in the GSA through a function 448 output=F(SenderID, input) [Note: F needs to be defined later]. 449 The output is then used for instantiating the current write 450 state. 452 If a device is both a sender and listener, then the read and write 453 states are both instantiated as above. Additionally each connection 454 state contains the epoch (set to zero) and sequence number which is 455 incremented for each record sent; the first record sent has the 456 sequence number 0. 458 4.1. Group message format 460 To reuse the DTLS implementation for group message processing, the 461 DTLS Records are used to send messages in the group. 463 The following Figure 2 illustrates the structure of the DTLS record 464 layer header, the epoch and seq_number are used to ensure message 465 freshness and to detect message replays. 467 +---------+---------+--------+--------+--------+------------+-------+ 468 | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | 469 +---------+---------+--------+--------+--------+------------+-------+ 470 | Content | Version | epoch | seq_ | Length | Ciphertext | MAC | 471 | Type | Ma | Mi | | number | | (Enc) | (Enc) | 472 +---------+---------+--------+--------+--------+------------+-------+ 474 Figure 2: The DTLS record layer header to transport group-level 475 authenticated messages 477 The same packet structure is used to transport group messages with 478 the Content Type set to ContentType.application_data, the version set 479 to DTLS version 1.2 (mandated by CoAP) which uses the version {254, 480 253}, epoch is fixed for all devices by the controller and the 481 seq_number based on current connection state. The seq_number is 482 increased by one whenever the sender sends a new group message in the 483 record. Finally, the message is protected (encrypted and 484 authenticated with a MAC) using the session keys in the "server 485 write" parameters. 487 4.2. Group message processing 489 4.2.1. Sending Secure Multicast Messages 491 Senders in the multicast group when sending a CoAP group message from 492 the application, create the DTLS record payload based on the "server 493 write" parameters. It also manages its own epoch and seq_number in 494 the "server write" connection state; the first record sent has the 495 seq_number 0. After creating the DTLS record, the seq_number is 496 incremented in the "server write" connection state. The DTLS record 497 is then passed down to UDP and IPv6 layer for transmission on the 498 multicast IPv6 destination address and port. 500 4.2.2. Receiving Secure Multicast Messages 502 When a listeners receives a protected multicast message from the 503 sender, it looks up the corresponding "client read" connection state 504 based on the multicast IP destination and port of the connection. 505 This is different from standard DTLS logic in that the current 506 "client read" connection state is bound to the source IP address and 507 port. 509 Listener devices in a multiple senders multicast group, need to store 510 multiple "client read" connection states for the different senders 511 linked to the Source IP addresses. The keying material is same for 512 all senders however tracking the epoch and the seq_number of the last 513 received packets needs to be kept different for different senders. 515 The listeners first perform a "server write" keys lookup by using the 516 multicast IPv6 destination address and port of the packet. Then the 517 key is passed through the same F function described above to get 518 specific keys for the particular sender. The listeners decrypt and 519 check the MAC of the message using this key. This guarantees that no 520 one without access to the GSA has spoofed the message. Subsequently, 521 the listeners retrieve the "client read" connection state which 522 contains the last stored epoch and seq_number of the sender, which is 523 used to check the freshness of the message received. The listeners 524 must ensure that the epoch is the same and seq_number in the message 525 received is at least equal to the stored value, otherwise the message 526 is discarded. Alternatively a windowing mechanism can be used to 527 accept genuine out-of-order packets. Once the authenticity and 528 freshness of the message have been checked, the listeners can pass 529 the message to the higher layer protocols. The seq_number in the 530 corresponding "client read" connection state are updated as well. 532 5. Source-level Data Authenticity 534 This section describes in detail the source level authenticity 535 mechanism based on public-key cryptography for transport level secure 536 group messages. We assume that group membership has been configured 537 by the group controller as described in Section 3.1 , and all member 538 devices in the group have the GSA. 540 The source-level authentication GSA contains the following elements: 542 a. For Senders: 544 CipherSuite 545 {SenderID, SenderID Private Key} 546 server write encryption key 547 server write IV 549 b. For Listeners: 551 CipherSuite 552 {SenderID1, SenderID1 Public Key} 553 {SenderID2, SenderID2 Public Key} 554 {SenderID3, SenderID3 Public Key} 555 ... 556 server write encryption key 557 server write IV 559 The group controller chooses a CipherSuite for the GSA for all 560 devices based on knowledge that all devices in the group support the 561 specific CipherSuite. Based on the CipherSuite selected, one or more 562 of the other elements may be empty. For example, if only 563 authenticity is needed then the encryption key and IV is not sent. 565 The GSA is used to instantiate the needed elements of the 566 "SecurityParameters" structure (shown below) as defined in [RFC5246] 567 for all devices. 569 struct { 570 ConnectionEnd entity; 571 PRFAlgorithm prf_algorithm; 572 BulkCipherAlgorithm bulk_cipher_algorithm; 573 CipherType cipher_type; 574 uint8 enc_key_length; 575 uint8 block_length; 576 uint8 fixed_iv_length; 577 uint8 record_iv_length; 578 MACAlgorithm mac_algorithm; 579 uint8 mac_length; 580 uint8 mac_key_length; 581 CompressionMethod compression_algorithm; 582 opaque master_secret[48]; 583 opaque client_random[32]; 584 opaque server_random[32]; 585 } SecurityParameters; 587 a. SecurityParameters.entity is set to ConnectionEnd.server for 588 senders and ConnectionEnd.client for listeners. 590 b. bulk_cipher_algorithm, cipher_type, enc_key_length, block_length, 591 fixed_iv_length, and record_iv_length is set based on the 592 ciphersuite present in the GSA. 594 c. mac_algorithm, mac_length, and mac_key_length are set different 595 to DTLS since we use public key algorithms. The mac here 596 therefore is a public-key based signature. 598 d. enc_key_length, block_length are sent in the GSA if encryption is 599 needed. 601 e. prf_algorithm, compression_algorithm, master_secret[48], 602 client_random[32], and server_random[32] are not used and 603 therefore not set. 605 The current read and write states are then instantiated for all group 606 members based on the keying material in the GSA and according to 607 their roles: 609 a. Listeners (ConnectionEnd.client) use the SenderID's public keys 610 for instantiating the current read state for different senders. 611 If confidentiality is needed, the "server write" parameters in 612 the GSA is also added to the current read state. The write state 613 is not instantiated and not used. 615 b. Senders (ConnectionEnd.server) use the SenderID private key to 616 instantiate the current write state. If confidentiality is used, 617 first pass each of the "server write" parameters in the GSA 618 through a function output=F(SenderID, input) [Note: F needs to be 619 defined later.]. 621 If a device is both a sender and listener, then the read and write 622 states are both instantiated as above. Additionally each connection 623 state contains the epoch (set to zero) and sequence number which is 624 incremented for each record sent; the first record sent has the 625 sequence number 0. 627 5.1. Group message format 629 To reuse the DTLS implementation for group message processing, the 630 DTLS Records are used to send messages in the group with minor 631 changes. 633 The following Figure 2 illustrates the structure of the DTLS record 634 layer header, the epoch and seq_number are used to ensure message 635 freshness and to detect message replays. 637 +---------+---------+--------+--------+--------+------------+-------+ 638 | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | 639 +----------------------------------------------------------------+--+ 640 | Content | Version | epoch | seq_ | Length | Ciphertext | Sig- | 641 | Type | Ma + Mi | | number | | (if enc) | nature| 642 +---------+----+----+--------+--------+--------+------------+-------+ 644 Figure 3: The DTLS record layer header to transport source-level 645 authenticity messages 647 The same packet structure is used to transport group messages with 648 the Content Type set to ContentType.application_data, the version set 649 to DTLS version 1.2 (mandated by CoAP) which uses the version {254, 650 253}, epoch is fixed for all devices by the controller and the 651 seq_number based on current connection state. The seq_number is 652 increased by one whenever the sender sends a new group message in the 653 record. Finally, the message is signed using the SenderID private 654 key and added to the signature field. If confidentiality is needed 655 then data is encrypted using the session keys in the "server write" 656 parameters. 658 5.2. Group message processing 660 5.2.1. Sending Secure Multicast Messages 662 Senders in the multicast group when sending a CoAP group message from 663 the application, create the DTLS record payload based on the current 664 write connection state, i.e. the data (along with the headers) is 665 signed using the private key and if confidentiality is needed, the 666 server write parameters are used to encrypt the data. It also 667 manages its own epoch and seq_number in the current write connection 668 state; the first record sent has the seq_number 0. After creating 669 the DTLS record, the seq_number is incremented in the "server write" 670 connection state. The DTLS record is then passed down to UDP and 671 IPv6 layer for transmission on the multicast IPv6 destination address 672 and port. 674 5.2.2. Receiving Secure Multicast Messages 676 When a listeners receives a protected multicast message from the 677 sender, it looks up the corresponding "client read" connection state 678 based on the source address, source port, multicast IP destination 679 and destination port of the connection. This is different from 680 standard DTLS logic in that the current "client read" connection 681 state is bound only to the source IP address and source port. 683 Listener devices in a multiple senders multicast group, need to store 684 multiple "client read" connection states for the different senders 685 linked to the source IP addresses. Each of these connection states 686 contain the public key of the corresponding sender. Further tracking 687 the epoch and the seq_number of the last received packets needs to be 688 kept different for different senders. 690 The listeners first perform a public key lookup by retrieving the 691 "client read" connection state using the source address, source port, 692 multicast IPv6 destination address and port of the packet. The 693 listeners verifies the signature of the message using this public 694 key. This guarantees that no one without access to the GSA for the 695 specific device has spoofed the message. Subsequently, the listeners 696 retrieve from the "client read" connection state the last stored 697 epoch and seq_number of the sender, which is used to check the 698 freshness of the message received. The listeners must ensure that 699 the epoch is the same and seq_number in the message received is 700 higher than the stored value, otherwise the message is discarded. 701 Alternatively a windowing mechanism can be used to accept genuine 702 out-of-order packets. Once the authenticity and freshness of the 703 message have been checked, the listeners can pass the message to the 704 higher layer protocols. The the seq_number in the corresponding 705 "client read" connection state are updated as well. 707 6. Security Considerations 709 Some of the security issues that should be taken into consideration 710 are discussed below. 712 6.1. Late joiners 714 Listeners who are late joiners to a multicast group, do not know the 715 current epoch and seq_number being used by different senders. When 716 they receive a packet from a sender with a random seq_number in it, 717 it is impossible for the listener to verify if the packet is fresh 718 and has not been replayed by an attacker. To overcome this late 719 joiner security issue, the group controller which can act as a 720 listener in the multicast group can maintain the epoch and seq_number 721 of each sender. When late joiners send a request to the group 722 controller to join the multicast group, the group controller can send 723 the list of epoch and seq_numbers to the late joiner. 725 7. Acknowledgements 727 8. References 729 8.1. Normative References 731 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 732 Encryption", RFC 5116, January 2008. 734 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 735 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 737 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 738 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 739 August 2008. 741 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 742 Security Version 1.2", RFC 6347, January 2012. 744 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 745 Transport Layer Security (TLS)", RFC 6655, July 2012. 747 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 748 Application Protocol (CoAP)", RFC 7252, June 2014. 750 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 751 Constrained Application Protocol (CoAP)", RFC 7390, 752 October 2014. 754 8.2. Informative References 756 [FIPS.180-2.2002] 757 National Institute of Standards and Technology, "Secure 758 Hash Standard", FIPS PUB 180-2, August 2002, 759 . 762 [FIPS.197.2001] 763 National Institute of Standards and Technology, "Advanced 764 Encryption Standard (AES)", FIPS PUB 197, November 2001, 765 . 768 [I-D.dijk-core-groupcomm-misc] 769 Dijk, E. and A. Rahman, "Miscellaneous CoAP Group 770 Communication Topics", draft-dijk-core-groupcomm-misc-06 771 (work in progress), June 2014. 773 [I-D.ietf-core-resource-directory] 774 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 775 draft-ietf-core-resource-directory-02 (work in progress), 776 November 2014. 778 [I-D.mcgrew-aero] 779 McGrew, D. and J. Foley, "Authenticated Encryption with 780 Replay prOtection (AERO)", draft-mcgrew-aero-01 (work in 781 progress), February 2014. 783 [I-D.mglt-dice-ipsec-for-application-payload] 784 Migault, D. and C. Bormann, "IPsec/ESP for Application 785 Payload", draft-mglt-dice-ipsec-for-application-payload-00 786 (work in progress), July 2014. 788 [I-D.vanderstok-core-dna] 789 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 790 Naming, and Addressing", draft-vanderstok-core-dna-02 791 (work in progress), July 2012. 793 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 794 Hashing for Message Authentication", RFC 2104, February 795 1997. 797 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 798 Architecture", RFC 3740, March 2004. 800 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 801 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 802 August 2004. 804 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 805 "Multicast Security (MSEC) Group Key Management 806 Architecture", RFC 4046, April 2005. 808 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 809 Briscoe, "Timed Efficient Stream Loss-Tolerant 810 Authentication (TESLA): Multicast Source Authentication 811 Transform Introduction", RFC 4082, June 2005. 813 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 814 "GSAKMP: Group Secure Association Key Management 815 Protocol", RFC 4535, June 2006. 817 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 818 Ciphersuites with NULL Encryption for Transport Layer 819 Security (TLS)", RFC 4785, January 2007. 821 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 822 "Transmission of IPv6 Packets over IEEE 802.15.4 823 Networks", RFC 4944, September 2007. 825 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 826 4949, August 2007. 828 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 829 Extensions to the Security Architecture for the Internet 830 Protocol", RFC 5374, November 2008. 832 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 833 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 834 September 2011. 836 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 837 Discovery", RFC 6763, February 2013. 839 Authors' Addresses 841 Sandeep S. Kumar 842 Philips Research 843 High Tech Campus 34 844 Eindhoven 5656 AE 845 The Netherlands 847 Email: ietf.author@sandeep-kumar.org 849 Rene Struik 850 Struik Security Consultancy 852 Email: rstruik.ext@gmail.com