idnits 2.17.1 draft-tiloca-ace-oscoap-joining-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2017) is 2487 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) == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-05 ** Downref: Normative reference to an Informational draft: draft-ietf-ace-actors (ref. 'I-D.ietf-ace-actors') == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-00 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-06 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-04 == Outdated reference: A later version (-06) exists of draft-seitz-ace-oscoap-profile-03 == Outdated reference: A later version (-04) exists of draft-tiloca-core-multicast-oscoap-02 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-06 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft RISE SICS AB 4 Intended status: Standards Track J. Park 5 Expires: January 3, 2018 Universitaet Duisburg-Essen 6 July 02, 2017 8 Joining of OSCOAP multicast groups in ACE 9 draft-tiloca-ace-oscoap-joining-00 11 Abstract 13 This document describes a method to join a multicast group where 14 communications are based on CoAP and secured with Object Security of 15 CoAP (OSCOAP). The proposed method delegates the authentication and 16 authorization of client nodes that join a multicast group through a 17 Group Manager server. This approach builds on the ACE framework for 18 Authentication and Authorization, and leverages protocol-specific 19 profiles of ACE to achieve communication security, proof-of- 20 possession and server authentication. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Joining Node to Authorization Server . . . . . . . . . . . . 6 60 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 7 61 5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 8 62 6. Updating Authorization Information . . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 10.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 The Constrained Application Protocol (CoAP) [RFC7252] supports also 74 group communication scenarios, where request messages can be 75 delivered to multiple recipients using CoAP on top of IP multicast 76 [RFC7390]. 78 Object Security of CoAP (OSCOAP) [I-D.ietf-core-object-security] is a 79 method for application layer protection of CoAP messages, using the 80 CBOR Object Signing and Encryption (COSE) [I-D.ietf-cose-msg], and 81 enabling end-to-end security of CoAP payload and options. 83 OSCOAP may also be used to protect group communication for CoAP over 84 IP multicast, as described in [I-D.tiloca-core-multicast-oscoap]. 85 This relies on a Group Manager entity, which is responsible for 86 managing a multicast group where members exchange CoAP messages 87 secured with OSCOAP. In particular, the Group Manager coordinates 88 the join process of new group members and can be responsible for 89 multiple groups. 91 This document builds on the ACE framework for Authentication and 92 Authorization [I-D.ietf-ace-oauth-authz] and specifies how a client 93 joins an OSCOAP multicast group through a resource server acting as 94 Group Manager. The client acting as joining node relies on an Access 95 Token, which is bound to a proof-of-possession key and authorizes the 96 access to a specific join resource at the Group Manager. 98 The client and the Group Manager leverage protocol-specific profiles 99 of ACE such as [I-D.seitz-ace-oscoap-profile] and 100 [I-D.ietf-ace-dtls-authorize], in order to achieve communication 101 security, proof-of-possession and server authentication. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. These 108 words may also appear in this document in lowercase, absent their 109 normative meanings. 111 Readers are expected to be familiar with the terms and concepts 112 described in the ACE framework for authentication and authorization 113 [I-D.ietf-ace-oauth-authz]. Message exchanges are presented as 114 RESTful protocol interactions, for which HTTP [RFC7231] provides 115 useful terminology. 117 The terminology for entities in the considered architecture is 118 defined in OAuth 2.0 [RFC6749] and [I-D.ietf-ace-actors]. In 119 particular, this includes client (C), resource server (RS), and 120 authorization server (AS). Terminology for constrained environments, 121 such as "constrained device" and "constrained-node network", is 122 defined in [RFC7228]. 124 Readers are expected to be familiar with the terms and concepts 125 related to the CoAP protocol described in [RFC7252][RFC7390]. Note 126 that the term "endpoint" is used here following its OAuth definition, 127 aimed at denoting resources such as /token and /introspect at the AS 128 and /authz-info at the RS. This document does not use the CoAP 129 definition of "endpoint", which is "An entity participating in the 130 CoAP protocol". 132 Readers are expected to be familiar with the terms and concepts for 133 protection and processing of CoAP messages through OSCOAP 134 [I-D.ietf-core-object-security] also in group communication contexts 135 [I-D.tiloca-core-multicast-oscoap]; and with the OSCOAP profile of 136 ACE described in [I-D.seitz-ace-oscoap-profile]. 138 Readers are expected to be familiar with the terms and concepts 139 related to the DTLS protocol [RFC6347]; the support for DTLS 140 handshake based on Raw Public Keys (RPK) [RFC7250] and on Pre-Shared 141 Keys (PSK) [RFC4279]; and the CoAP-DTLS profile of ACE 142 [I-D.ietf-ace-dtls-authorize]. 144 This document refers also to the following terminology. 146 o Joining node: a network node intending to join an OSCOAP multicast 147 group, where communication is based on CoAP [RFC7390] and secured 148 with OSCOAP as described in [I-D.tiloca-core-multicast-oscoap]. 150 o Join process: the process through which a joining node becomes a 151 member of a multicast group. The join process is enforced and 152 assisted by the Group Manager responsible for that group. 154 o Join resource: a protected resource hosted by the Group Manager, 155 associated to a multicast group under that Group Manager. A 156 joining node accesses the join resource in order to start the join 157 process and become a member of that group. 159 o Join endpoint: an endpoint hosted by the Group Manager associated 160 to a join resource. 162 2. Protocol Overview 164 Group communication for CoAP over IP multicast has been enabled in 165 [RFC7390] and can be secured with Object Security of CoAP (OSCOAP) 166 [I-D.ietf-core-object-security] as described in 167 [I-D.tiloca-core-multicast-oscoap]. A network node explicitly joins 168 an OSCOAP multicast group, by interacting with the responsible Group 169 Manager. Once registered in the group, the new node can securely 170 exchange (multicast) messages with other group members. 172 This specification describes how a network node joins an OSCOAP 173 multicast group leveraging the ACE framework for authentication and 174 authorization [I-D.ietf-ace-oauth-authz]. With reference to the ACE 175 framework and the terminology defined in OAuth 2.0 [RFC6749]: 177 o The Group Manager acts as Resource Server (RS), and owns one join 178 resource for each OSCOAP multicast group it manages. Each join 179 resource is exported by a distinct join endpoint. 181 o The joining node acts as Client (C), and requests to join an 182 OSCOAP multicast group by accessing the related join endpoint at 183 the Group Manager. 185 o The Authorization Server (AS) enables and enforces the authorized 186 access of joining nodes to join endpoints at the Group Manager. 187 Multiple Group Managers can be associated to the same AS. 189 If authorized to join the multicast group, the joining node receives 190 from the AS an Access Token bound with a proof-of-possession key. 191 After that, the joining node provides the Group Manager with the 192 Access Token. This step involves the opening of a secure 193 communication channel between the joining node and the Group Manager, 194 in case they have not already established one. 196 Finally, the joining node accesses the join endpoint at the Group 197 Manager, so starting the join process to become a member of the 198 multicast group. A same Access Token can authorize the joining node 199 to access multiple groups under the same Group Manager. In such a 200 case, the joining node sequentially performs multiple join processes 201 with the Group Manager, separately for each multicast group to join 202 and by accessing the respective join endpoint. 204 The AS is not necessarily expected to release Access Tokens for any 205 other purpose than accessing join resources on registered Group 206 Managers. In particular, the AS is not necessarily expected to 207 release Access Tokens for accessing protected resources at members of 208 multicast groups. 210 The following steps are performed for joining an OSCOAP multicast 211 group, by leveraging the CoAP-DTLS profile of ACE 212 [I-D.ietf-ace-dtls-authorize] or the OSCOAP profile of ACE 213 [I-D.seitz-ace-oscoap-profile]. 215 1. The joining node retrieves an Access Token from the AS to access 216 a join resource on the Group Manager (Section 3). The response 217 from the AS enables the joining node to start a secure channel 218 with the Group Manager, if not already established. The joining 219 node can also contact the AS for updating a previously released 220 Access Token, in order to access further groups under the same 221 Group Manager (Section 6). 223 2. Authentication and authorization information is transferred 224 between the joining node and the Group Manager, which establish a 225 secure channel in case one is not already set up (Section 4). 226 That is, a joining node MUST establish a secure communication 227 channel with a Group Manager, before joining a multicast group 228 under that Group Manager for the first time. 230 3. The joining node starts the join process to become a member of 231 the multicast group, by accessing the related join resource 232 hosted by the Group Manager (Section 4). 234 All communications between the involved entities rely on the CoAP 235 protocol and MUST be secured. In particular, communications between 236 the joining node and the AS (/token endpoint) and between the Group 237 Manager and the AS (/introspection endpoint) can be secured by 238 different means, e.g. with DTLS [RFC6347] or with OSCOAP (see 239 Sections 3 and 4 of [I-D.seitz-ace-oscoap-profile]). 241 3. Joining Node to Authorization Server 243 This section considers a joining node that intends to contact the 244 Group Manager for the first time. That is, the joining node has 245 never attempted before to join a multicast group under that Group 246 Manager. Also, the joining node and the Group Manager do not have a 247 secure communication channel established. 249 In case the specific AS associated to the Group Manager is unknown to 250 the joining node, the latter can rely on mechanisms like the one 251 described in Section 2.2 of [I-D.ietf-ace-dtls-authorize] to discover 252 the correct AS in charge of the Group Manager. 254 The joining node contacts the AS, in order to request an Access Token 255 for accessing the join resource(s) hosted by the Group Manager. In 256 particular, the Access Token request sent to the /token endpoint 257 specifies the join endpoint(s) of interest at the Group Manager. 259 The AS is responsible for authorizing the joining node, accordingly 260 to group join policies enforced on behalf of the Group Manager. In 261 case of successful authorization, the AS releases an Access Token 262 bound to a proof-of-possession key associated to the joining node. 263 The same Access Token can authorize the joining node to access 264 multiple groups under the same Group Manager. 266 Then, the AS provides the joining node with the Access Token, 267 together with an Access Token response. In particular, the Access 268 Token response indicates how to secure communications with the Group 269 Manager, when accessing the join resource(s) for which the Access 270 Token is valid. Specifically, the Access Token response MUST specify 271 one of the following alternatives: 273 o CoAP over DTLS, i.e. coaps://, indicating to consider the CoAP- 274 DTLS profile of ACE, with asymmetric or symmetric proof-of- 275 possession key (see Section 3 and Section 4 of 276 [I-D.ietf-ace-dtls-authorize], respectively). 278 o OSCOAP, indicating to consider the OSCOAP profile of ACE with 279 asymmetric or symmetric proof-of-possession key, as described in 280 Section 2.2 of [I-D.seitz-ace-oscoap-profile]. 282 Consistently with the profiles of ACE specified in 283 [I-D.ietf-ace-dtls-authorize] and [I-D.seitz-ace-oscoap-profile], a 284 symmetric proof-of-possession key is generated by the AS, which uses 285 it as proof-of-possession key bound to the Access Token, and provides 286 it to the joining node in the Access Token response. Instead, in 287 case of asymmetric proof-of-possession key, the joining node provides 288 its own public key to the AS in the Access Token request. Then, the 289 AS uses it as proof-of-possession key bound to the Access Token, and 290 provides the joining node with the Group Manager's public key in the 291 Access Token response. 293 4. Joining Node to Group Manager 295 First, the joining node establishes a secure channel with the Group 296 Manager, according to what is specified in the Access Token response. 297 In particular: 299 o If the CoAP-DTLS profile of ACE is specified, the joining node 300 MUST upload the Access Token to the /authz-info resource before 301 starting the DTLS handshake. Then, the Group Manager processes 302 the Access Token according to [I-D.ietf-ace-oauth-authz]. If this 303 yields to a positive response, the joining node and the Group 304 Manager establish a DTLS session, as described in Section 3 and 305 Section 4 of [I-D.ietf-ace-dtls-authorize], in case of either 306 asymmetric or symmetric proof-of-possession key, respectively. 308 o If the OSCOAP profile of ACE is specified, the joining node and 309 the Group Manager establish an OSCOAP channel, as described in 310 Section 2.2 of [I-D.seitz-ace-oscoap-profile]. In particular, if 311 the EDHOC protocol [I-D.selander-ace-cose-ecdhe] is used to this 312 end, the joining node MUST include the Access Token in the EDHOC 313 message_1 sent to the /authz-info resource. The Group Manager 314 processes the Access Token as specified in 315 [I-D.ietf-ace-oauth-authz] and proceeds as defined in Section 2.2 316 of [I-D.seitz-ace-oscoap-profile]. 318 Once the secure channel with the Group Manager has been established, 319 the joining node requests to join the OSCOAP multicast groups of 320 interest, by accessing the related join resources at the Group 321 Manager. That is, the joining node performs multiple join processes 322 with the Group Manager, separately for each multicast group to join 323 and by accessing the respective join endpoint. 325 In particular, for each multicast group to join, the joining node 326 sends to the Group Manager a confirmable CoAP request, using the 327 method POST and targeting the join endpoint associated to that 328 multicast group. The request payload specifies the intended role(s) 329 of the joining node in the multicast group, i.e. multicaster and/or 330 (pure) listener [I-D.tiloca-core-multicast-oscoap]. 332 The Group Manager processes the request according to 333 [I-D.ietf-ace-oauth-authz]. If this yields to a positive response, 334 the Group Manager updates the group membership by registering the 335 joining node as a new member of the group. Then, the Group Manager 336 replies to the joining node including the following pieces of 337 information in the CoAP response payload: 339 o An OSCOAP endpoint ID, if the joining node is not configured 340 exclusively as pure listener (see Section 3 of 341 [I-D.tiloca-core-multicast-oscoap]). The Group Manager ensures 342 that each OSCOAP endpoint ID in use is unique within a same 343 multicast group. 345 o The OSCOAP Security Common Context associated to the joined 346 multicast group (see Section 4 of 347 [I-D.tiloca-core-multicast-oscoap]). 349 From then on, the joining node is registered as a member of the 350 multicast group, and can exchange group messages secured with OSCOAP 351 as described in Section 5 of [I-D.tiloca-core-multicast-oscoap]. 353 5. Public Keys of Joining Nodes 355 Source authentication of OSCOAP messages exchanged within the 356 multicast group is ensured by means of digital counter signatures 357 [I-D.tiloca-core-multicast-oscoap]. Therefore, group members must be 358 able to retrieve each other's public key from a trusted key 359 repository, in order to verify the authenticity of incoming group 360 messages. As also discussed in Section 7.4 of 361 [I-D.tiloca-core-multicast-oscoap], the Group Manager can be 362 configured to store public keys of group members and provide them 363 upon request. 365 Upon joining a multicast group, a joining node is expected to make 366 its own public key available to the other group members, either 367 through the Group Manager or through another trusted, publicly 368 available, key repository. However, this is not required, if at 369 least one of the following conditions hold. 371 o The joining node joins a group exclusively as pure listener. 373 o The joining node joins a group where only group authentication of 374 messages is provided (see Appendix C of 375 [I-D.tiloca-core-multicast-oscoap]). 377 In case the Group Manager is not configured to store public keys of 378 group members, a joining node SHOULD specify to the Group Manager the 379 address of a trusted key repository where its own public key is 380 available. In particular, upon performing a join process with a 381 given Group Manager for the first time, the joining node additionally 382 includes this information in the payload of the POST request 383 targeting the join endpoint. The Group Manager can then redirect 384 group members to the correct key repository in case of need. 386 Instead, in case the Group Manager is configured to store public keys 387 of group members, two main cases can occur. 389 o The joining node and the Group Manager have used an asymmetric 390 proof-of-possession key to establish a secure communication 391 channel. In this case, the Group Manager stores the proof-of- 392 possession key conveyed in the Access Token as the public key of 393 the joining node. 395 o The joining node and the Group Manager have used a symmetric 396 proof-of-possession key to establish a secure communication 397 channel. In this case, upon performing a join process with that 398 Group Manager for the first time, the joining node includes its 399 own public key in the payload of the POST request targeting the 400 join endpoint. Then, the Group Manager MUST verify that the 401 joining node actually owns the associated private key, for 402 instance by performing a proof-of-possession challenge-response. 404 Furthermore, if the Group Manager is configured as key repository, it 405 SHOULD provide a joining node with the public keys of the current 406 members in the joined group. In particular, when providing the 407 OSCOAP Endpoint ID and the OSCOAP Security Common Context as 408 described in Section 4, the Group Manager additionally includes the 409 following material in the response to the joining node: 411 o The public keys of the non-pure listeners currently in the joined 412 multicast group, if the joining node is configured (also) as 413 multicaster. 415 o The public keys of the multicasters currently in the joined 416 multicast group, if the joining node is configured (also) as non- 417 pure listener. 419 6. Updating Authorization Information 421 At any point in time, a node might want to join further OSCOAP 422 multicast groups under the same Group Manager. In such a case, the 423 joining node requests from the AS an updated Access Token for 424 accessing the new multicast groups of interest. 426 The joining node uploads the new Access Token to the /authz-info 427 resource at the Group Manager, using the already established secure 428 channel. After that, the joining node performs the joining process 429 described in Section 4, separately for each multicast group to join. 431 Since the joining node and the Group Manager already share a secure 432 communication channel, they are not required to establish a new one. 433 However, according to the specific profile of ACE in use, the joining 434 node and the Group Manager may leverage the new Access Token to 435 establish a new secure communication channel or update the currently 436 existing one. For instance, Section 4.2 of 437 [I-D.ietf-ace-dtls-authorize] describes how the new Access Token can 438 be used to renegotiate an existing DTLS session or to establish a new 439 one by performing a new DTLS handshake. 441 7. Security Considerations 443 This document relies on the security considerations included in 444 Section 7 of [I-D.tiloca-core-multicast-oscoap], as to different 445 management aspects related to OSCOAP multicast groups: 447 o Management of group keying material (Section 7.2). This includes 448 the need to revoke and renew the keying material currently used in 449 the multicast group, upon changes in the group membership. In 450 particular, renewing the keying material is required upon a new 451 node joining the multicast group, in order to preserve backward 452 security. The Group Manager is responsible to enforce rekeying 453 policies and accordingly update the keying material within the 454 multicast groups of its competence. 456 o Synchronization of sequence numbers (Section 7.3). This concerns 457 how a listener node that has just joined a multicast group can 458 synchronize with the sender sequence number of multicasters in the 459 same group. To this end, the new listener node performs a 460 challenge-response with a multicaster node, leveraging the Repeat 461 Option for CoAP [I-D.amsuess-core-repeat-request-tag]. 463 o Provisioning of public keys (Section 7.4). This provides 464 guidelines about how to ensure the availability of group members' 465 public keys, possibly relying on the Group Manager as trusted key 466 repository. Section 5 of this specification leverages and builds 467 on such considerations. 469 Further security considerations are (going to be) inherited from the 470 ACE framework for Authentication and Authorization 471 [I-D.ietf-ace-oauth-authz], as well as from the CoAP-DTLS profile 472 [I-D.ietf-ace-dtls-authorize] and the OSCOAP profile 473 [I-D.seitz-ace-oscoap-profile] of ACE. 475 8. IANA Considerations 477 This document has no actions for IANA. 479 9. Acknowledgments 481 The authors sincerely thank Goeran Selander, Santiago Aragon, Ludwig 482 Seitz and Martin Gunnarsson for their comments and feedback. 484 10. References 486 10.1. Normative References 488 [I-D.ietf-ace-actors] 489 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 490 architecture for authorization in constrained 491 environments", draft-ietf-ace-actors-05 (work in 492 progress), March 2017. 494 [I-D.ietf-ace-dtls-authorize] 495 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 496 L. Seitz, "Datagram Transport Layer Security (DTLS) 497 Profile for Authentication and Authorization for 498 Constrained Environments (ACE)", draft-ietf-ace-dtls- 499 authorize-00 (work in progress), June 2017. 501 [I-D.ietf-ace-oauth-authz] 502 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 503 H. Tschofenig, "Authentication and Authorization for 504 Constrained Environments (ACE)", draft-ietf-ace-oauth- 505 authz-06 (work in progress), March 2017. 507 [I-D.ietf-core-object-security] 508 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 509 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 510 object-security-04 (work in progress), July 2017. 512 [I-D.seitz-ace-oscoap-profile] 513 Seitz, L., Gunnarsson, M., and F. Palombini, "OSCOAP 514 profile of ACE", draft-seitz-ace-oscoap-profile-03 (work 515 in progress), June 2017. 517 [I-D.tiloca-core-multicast-oscoap] 518 Tiloca, M., Selander, G., and F. Palombini, "Secure group 519 communication for CoAP", draft-tiloca-core-multicast- 520 oscoap-02 (work in progress), July 2017. 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 528 Application Protocol (CoAP)", RFC 7252, 529 DOI 10.17487/RFC7252, June 2014, 530 . 532 10.2. Informative References 534 [I-D.amsuess-core-repeat-request-tag] 535 Amsuess, C., Mattsson, J., and G. Selander, "Repeat And 536 Request-Tag", draft-amsuess-core-repeat-request-tag-00 537 (work in progress), July 2017. 539 [I-D.ietf-cose-msg] 540 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 541 draft-ietf-cose-msg-24 (work in progress), November 2016. 543 [I-D.selander-ace-cose-ecdhe] 544 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 545 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 546 cose-ecdhe-06 (work in progress), April 2017. 548 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 549 Ciphersuites for Transport Layer Security (TLS)", 550 RFC 4279, DOI 10.17487/RFC4279, December 2005, 551 . 553 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 554 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 555 January 2012, . 557 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 558 RFC 6749, DOI 10.17487/RFC6749, October 2012, 559 . 561 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 562 Constrained-Node Networks", RFC 7228, 563 DOI 10.17487/RFC7228, May 2014, 564 . 566 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 567 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 568 DOI 10.17487/RFC7231, June 2014, 569 . 571 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 572 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 573 Transport Layer Security (TLS) and Datagram Transport 574 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 575 June 2014, . 577 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 578 the Constrained Application Protocol (CoAP)", RFC 7390, 579 DOI 10.17487/RFC7390, October 2014, 580 . 582 Authors' Addresses 584 Marco Tiloca 585 RISE SICS AB 586 Isafjordsgatan 22 587 Kista SE-164 29 Stockholm 588 Sweden 590 Phone: +46 70 604 65 01 591 Email: marco.tiloca@ri.se 593 Jiye Park 594 Universitaet Duisburg-Essen 595 Schuetzenbahn 70 596 Essen 45127 597 Germany 599 Phone: +49 201 183-7634 600 Email: ji-ye.park@uni-due.de