idnits 2.17.1 draft-tiloca-ace-oscoap-joining-03.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 (March 05, 2018) is 2243 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 (-18) exists of draft-ietf-ace-dtls-authorize-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-10 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-08 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-01 == Outdated reference: A later version (-02) exists of draft-palombini-ace-key-groupcomm-00 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-06 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-12 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: September 6, 2018 Universitaet Duisburg-Essen 6 March 05, 2018 8 Joining OSCORE groups in ACE 9 draft-tiloca-ace-oscoap-joining-03 11 Abstract 13 This document describes a method to join a group where communications 14 are based on CoAP and secured with Object Security for Constrained 15 RESTful Environments (OSCORE). The proposed method delegates the 16 authentication and authorization of client nodes that join an OSCORE 17 group through a Group Manager server. This approach builds on the 18 ACE framework for Authentication and Authorization, and leverages 19 protocol-specific profiles of ACE to achieve communication security, 20 proof-of-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 https://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 September 6, 2018. 39 Copyright Notice 41 Copyright (c) 2018 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 (https://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 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 61 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 62 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 7 63 4.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 9.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 Object Security for Constrained RESTful Environments (OSCORE) 77 [I-D.ietf-core-object-security] is a method for application-layer 78 protection of the Constrained Application Protocol (CoAP) [RFC7252], 79 using CBOR Object Signing and Encryption (COSE) [RFC8152] and 80 enabling end-to-end security of CoAP payload and options. 82 As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used 83 also to protect CoAP group communication over IP multicast [RFC7390]. 84 This relies on a Group Manager entity, which is responsible for 85 managing an OSCORE group, where members exchange CoAP messages 86 secured with OSCORE. In particular, the Group Manager coordinates 87 the join process of new group members and can be responsible for 88 multiple groups. 90 This specification builds on the ACE framework for Authentication and 91 Authorization [I-D.ietf-ace-oauth-authz] and defines how a client 92 joins an OSCORE group through a resource server acting as Group 93 Manager. The client acting as joining node relies on an Access 94 Token, which is bound to a proof-of-possession key and authorizes the 95 access to a specific join resource at the Group Manager. Messages 96 exchanged among the participants follow the formats defined in 98 [I-D.palombini-ace-key-groupcomm] for provisioning keying material in 99 group communication scenarios. 101 In order to achieve communication security, proof-of-possession and 102 server authentication, the client and the Group Manager leverage 103 protocol-specific profiles of ACE. These include 104 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile], as 105 well as possible forthcoming profiles that comply with the 106 requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119][RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 Readers are expected to be familiar with the terms and concepts 117 described in the ACE framework for authentication and authorization 118 [I-D.ietf-ace-oauth-authz]. Message exchanges are presented as 119 RESTful protocol interactions, for which HTTP [RFC7231] provides 120 useful terminology. 122 The terminology for entities in the considered architecture is 123 defined in OAuth 2.0 [RFC6749] and [I-D.ietf-ace-actors]. In 124 particular, this includes Client (C), Resource Server (RS), and 125 Authorization Server (AS). 127 Readers are expected to be familiar with the terms and concepts 128 related to the CoAP protocol described in [RFC7252] [RFC7390]. Note 129 that, unless otherwise indicated, the term "endpoint" is used here 130 following its OAuth definition, aimed at denoting resources such as 131 /token and /introspect at the AS and /authz-info at the RS. This 132 document does not use the CoAP definition of "endpoint", which is "An 133 entity participating in the CoAP protocol". 135 Readers are expected to be familiar with the terms and concepts for 136 protection and processing of CoAP messages through OSCORE 137 [I-D.ietf-core-object-security] also in group communication scenarios 138 [I-D.ietf-core-oscore-groupcomm]. 140 This document refers also to the following terminology. 142 o Joining node: a network node intending to join an OSCORE group, 143 where communication is based on CoAP [RFC7390] and secured with 144 OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 146 o Join process: the process through which a joining node becomes a 147 member of an OSCORE group. The join process is enforced and 148 assisted by the Group Manager responsible for that group. 150 o Join resource: a resource hosted by the Group Manager, associated 151 to an OSCORE group under that Group Manager. A join resource is 152 identifiable with the Group Identifier (Gid) of the respective 153 group. A joining node accesses a join resource to start the join 154 process and become a member of that group. 156 o Join endpoint: an endpoint at the Group Manager associated to a 157 join resource. 159 2. Protocol Overview 161 Group communication for CoAP over IP multicast has been enabled in 162 [RFC7390] and can be secured with Object Security for Constrained 163 RESTful Environments (OSCORE) [I-D.ietf-core-object-security] as 164 described in [I-D.ietf-core-oscore-groupcomm]. A network node 165 explicitly joins an OSCORE group, by interacting with the responsible 166 Group Manager. Once registered in the group, the new node can 167 securely exchange messages with other group members. 169 This specification describes how a network node joins an OSCORE group 170 by using the ACE framework for authentication and authorization 171 [I-D.ietf-ace-oauth-authz]. With reference to the ACE framework and 172 the terminology defined in OAuth 2.0 [RFC6749]: 174 o The Group Manager acts as Resource Server (RS), and hosts one join 175 resource for each OSCORE group it manages. Each join resource is 176 exported by a distinct join endpoint. During the join process, 177 the Group Manager provides joining nodes with the parameters and 178 keying material for taking part to secure communications in the 179 group. 181 o The joining node acts as Client (C), and requests to join an 182 OSCORE group by accessing the related join endpoint at the Group 183 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 and hence the access to the related OSCORE groups. Multiple Group 188 Managers can be associated to the same AS. The AS is not 189 necessarily expected to release Access Tokens for any other 190 purpose than accessing join resources on registered Group 191 Managers. However, the AS may be configured also to release 192 Access Tokens for accessing resources at members of OSCORE groups. 194 All communications between the involved entities rely on the CoAP 195 protocol and must be secured. The joining node and the Group Manager 196 leverage protocol-specific profiles of ACE to achieve communication 197 security, proof-of-possession and server authentication. To this 198 end, the AS must signal the specific profile to use, consistently 199 with requirements and assumptions defined in the ACE framework 200 [I-D.ietf-ace-oauth-authz]. 202 Communications between the joining node and the AS (/token endpoint) 203 as well as between the Group Manager and the AS (/introspection 204 endpoint) can be secured by different means, for instance by means of 205 DTLS [RFC6347] or OSCORE [I-D.ietf-core-object-security]. Further 206 details on how the AS secures communications (with the joining node 207 and the Group Manager) depend on the specifically used profile of 208 ACE, and are out of the scope of this specification. 210 The following steps are performed for joining an OSCORE group. 211 Messages exchanged among the participants follow the formats defined 212 in [I-D.palombini-ace-key-groupcomm], and are further specified in 213 Section 3 and Section 4 of this document. The Group Manager acts as 214 the Key Distribution Center (KDC) referred in 215 [I-D.palombini-ace-key-groupcomm]. 217 1. The joining node requests an Access Token from the AS to access a 218 join resource on the Group Manager and hence the associated 219 OSCORE group (see Section 3). The response from the AS enables 220 the joining node to start a secure channel with the Group 221 Manager, if not already established. 223 2. The joining node transfers authentication and authorization 224 information to the Group Manager by posting the obtained Access 225 Token. Then, the joining node and the Group Manager have to 226 establish a secure channel in case one is not already set up (see 227 Section 4). That is, a joining node must establish a secure 228 communication channel with a Group Manager, before joining an 229 OSCORE group under that Group Manager for the first time. 231 3. The joining node starts the join process to become a member of 232 the OSCORE group, by accessing the related join resource hosted 233 by the Group Manager (see Section 4). 235 4. At the end of the join process, the joining node has received 236 from the Group Manager the parameters and keying material to 237 securely communicate in the OSCORE group. 239 3. Joining Node to Authorization Server 241 This section considers a joining node that intends to contact the 242 Group Manager for the first time. That is, the joining node has 243 never attempted before to join an OSCORE group under that Group 244 Manager. Also, the joining node and the Group Manager do not have a 245 secure communication channel established. 247 In case the specific AS associated to the Group Manager is unknown to 248 the joining node, the latter can rely on mechanisms like the 249 Unauthorized Resource Request message described in Section 2 of 250 [I-D.ietf-ace-dtls-authorize] to discover the correct AS in charge of 251 the Group Manager. As an alternative, the joining node may look up 252 in a Resource Directory service [I-D.ietf-core-resource-directory]. 254 3.1. Authorization Request 256 The joining node contacts the AS, in order to request an Access Token 257 for accessing the join resource hosted by the Group Manager and 258 associated to the OSCORE group. The Access Token request sent to the 259 /token endpoint follows the format of the Authorization Request 260 message defined in Section 3.1 of [I-D.palombini-ace-key-groupcomm]. 261 In particular: 263 o The "scope" parameter MUST be present and includes: 265 * in the first element, the Group Identifier (Gid) of the group 266 to join under the Group Manager. This identifier may not fully 267 coincide with the Gid currently associated to the respective 268 group, e.g. if it includes a dynamic component. 270 * in the second element, which MUST be present, the role(s) that 271 the joining node intends to have in the group it intends to 272 join. Roles and their combinations are defined in 273 [I-D.ietf-core-oscore-groupcomm], and indicated as 274 "multicaster", "listener" and "purelistener". Multiple roles 275 are specified in the form of a CBOR array. 277 o The "aud" parameter MUST be present and is set to the address of 278 the Group Manager. 280 o The "get_pub_keys" parameter is present only if the Group Manager 281 is configured to store the public keys of the group members and, 282 at the same time, the joining node wants to retrieve such public 283 keys during the joining process (see Section 5). In any other 284 case, this parameter MUST NOT be present. 286 3.2. Authorization Response 288 The AS is responsible for authorizing the joining node, accordingly 289 to group join policies enforced on behalf of the Group Manager. In 290 case of successful authorization, the AS releases an Access Token 291 bound to a proof-of-possession key associated to the joining node. 293 Then, the AS provides the joining node with the Access Token as part 294 of an Access Token response, which follows the format of the 295 Authorization Response message defined in Section 3.2 of 296 [I-D.palombini-ace-key-groupcomm]. 298 The "exp" parameter MUST be present, since defining the lifetime of 299 Access Tokens is out of the scope of this specification. 301 In case the value of "scope" specified in the Access Token differs 302 from the value originally included in the Access Token request, the 303 Access Token response MUST include the "scope" parameter, whose 304 second element MUST be present and includes the role(s) that the 305 joining node is actually authorized to take in the group, encoded as 306 specified in Section 3.1 of this document. 308 Also, the "profile" parameter indicates the specific profile of ACE 309 to use for securing communications between the joining node and the 310 Group Manager (see Section 5.6.4.4 of [I-D.ietf-ace-oauth-authz]). 312 In particular, if symmetric keys are used, the AS generates a proof- 313 of-possession key, binds it to the Access Token, and provides it to 314 the joining node in the "cnf" parameter of the Access Token response. 315 Instead, if asymmetric keys are used, the joining node provides its 316 own public key to the AS in the "cnf" parameter of the Access Token 317 request. Then, the AS uses it as proof-of-possession key bound to 318 the Access Token, and provides the joining node with the Group 319 Manager's public key in the "rs_cnf" parameter of the Access Token 320 response. 322 4. Joining Node to Group Manager 324 First, the joining node posts the Access Token to the /authz-info 325 endpoint at the Group Manager, in accordance with the Token post 326 defined in Section 3.3 of [I-D.palombini-ace-key-groupcomm]. Then, 327 the joining node establishes a secure channel with the Group Manager, 328 according to what specified in the Access Token response and to the 329 signalled profile of ACE. 331 4.1. Join Request 333 Once a secure communication channel with the Group Manager has been 334 established, the joining node requests to join the OSCORE group, by 335 accessing the related join resource at the Group Manager. 337 In particular, the joining node sends to the Group Manager a 338 confirmable CoAP request, using the method POST and targeting the 339 join endpoint associated to that group. This join request follows 340 the format of the Key Distribution Request message defined in 341 Section 4.1 of [I-D.palombini-ace-key-groupcomm]. In particular: 343 o The "get_pub_keys" parameter can be present only if included also 344 in the Authorization Request previously sent to the AS. In such a 345 case, its value is the same as in the Authorization Request. 346 Otherwise, this parameter MUST NOT be present. 348 o The "client_cred" parameter, if present, includes the public key 349 or certificate of the joining node. Specifically, it includes the 350 public key of the joining node if the Group Manager is configured 351 to store the public keys of the group members, or the certificate 352 of the joining node otherwise. This parameter MAY be omitted if: 353 i) public keys are used as proof-of-possession keys between the 354 joining node and the Group Manager; or ii) the joining node is 355 asking to access the group exclusively as pure listener; or iii) 356 the Group Manager already acquired this information during a 357 previous join process. In any other case, this parameter MUST be 358 present. 360 o The "pub_keys_repos" parameter MAY be present if the "client_cred" 361 parameter is both present and with value a certificate of the 362 joining node. If present, this parameter contains the list of 363 public key repositories storing the certificate of the joining 364 node. In any other case, this parameter MUST NOT be present. 366 4.2. Join Response 368 The Group Manager processes the request according to 369 [I-D.ietf-ace-oauth-authz]. If this yields to a positive outcome, 370 the Group Manager updates the group membership by registering the 371 joining node as a new member of the OSCORE group. 373 Then, the Group Manager replies to the joining node providing the 374 information necessary to participate in the group communication. 375 This join response follows the format of the Key Distribution success 376 Response message defined in Section 4.2 of 377 [I-D.palombini-ace-key-groupcomm]. In particular: 379 o The "key" parameter includes what the joining node needs in order 380 to set up the OSCORE Security Context as in Section 2 of 381 [I-D.ietf-core-oscore-groupcomm]. In particular: 383 * The "kty" parameter has value "Symmetric". 385 * The "k" parameter includes the OSCORE Master Secret. 387 * The "alg" parameter, if present, has as value the AEAD 388 algorithm used in the group. 390 * The "kid" parameter, if present, has as value the identifier of 391 the key in the parameter "k". 393 * The "base IV" parameter, if present, has as value the OSCORE 394 Common IV. 396 * The "clientID" parameter MUST be present and has as value the 397 OSCORE Endpoint ID assigned to the joining node by the Group 398 Manager. 400 * The "serverID" parameter MUST be present and has as value the 401 Group Identifier (Gid) currently associated to the group. 403 * The "kdf" parameter, if present, has as value the KDF algorithm 404 used in the group. 406 * The "slt" parameter, if present, has as value the OSCORE Master 407 Salt. 409 * The "cs_alg" parameter MUST be present and has as value the 410 countersignature algorithm used in the group. 412 o The "pub_keys" parameter is present only if the "get_pub_keys" 413 parameter was present in the join request. If present, this 414 parameter includes the public keys of the group members that are 415 relevant to the joining node. That is, it includes: i) the public 416 keys of the non-pure listeners currently in the group, in case the 417 joining node is configured (also) as multicaster; and ii) the 418 public keys of the multicasters currently in the group, in case 419 the joining node is configured (also) as listener or pure 420 listener. 422 o The "group_policies" parameter SHOULD be present and includes a 423 list of parameters indicating particular policies enforced in the 424 group. For instance, it can indicate the method to achieve 425 synchronization of sequence numbers among group members (see 426 Appendix E of [I-D.ietf-core-oscore-groupcomm]), as well as the 427 rekeying protocol used to renew the keying material in the group 428 (see Section 2.1 of [I-D.ietf-core-oscore-groupcomm]). 430 o The "mgt_key_material" parameter SHOULD be present and includes 431 the administrative keying material that the joining node requires 432 to participate in the rekeying process led by the Group Manager. 433 The exact content and format depend on the specific rekeying 434 protocol used in the group. 436 Finally, the joining node uses the information received in the join 437 response to set up the OSCORE Security Context, as described in 438 Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the 439 joining node can exchange group messages secured with OSCORE as 440 described in Section 4 of [I-D.ietf-core-oscore-groupcomm]. 442 5. Public Keys of Joining Nodes 444 Source authentication of OSCORE messages exchanged within the group 445 is ensured by means of digital counter signatures 446 [I-D.ietf-core-oscore-groupcomm]. Therefore, group members must be 447 able to retrieve each other's public key from a trusted key 448 repository, in order to verify the source authenticity of incoming 449 group messages. 451 Upon joining an OSCORE group, a joining node is expected to make its 452 own public key available to the other group members, either through 453 the Group Manager or through another trusted, publicly available, key 454 repository. However, this is not required for a node that joins a 455 group exclusively as pure listener. 457 As also discussed in Section 6 of [I-D.ietf-core-oscore-groupcomm], 458 it is recommended that the Group Manager is configured to store the 459 public keys of the group members and to provide them upon request. 460 If so, three cases can occur when a new node joins a group. 462 o The Group Manager already acquired the public key of the joining 463 node during a previous join process. In this case, the joining 464 node is not required to provide again its own public key to the 465 Group Manager. 467 o The joining node and the Group Manager use an asymmetric proof-of- 468 possession key to establish a secure communication channel. In 469 this case, the Group Manager stores the proof-of-possession key 470 conveyed in the Access Token as the public key of the joining 471 node. 473 o The joining node and the Group Manager use a symmetric proof-of- 474 possession key to establish a secure communication channel. In 475 this case, upon performing a join process with that Group Manager 476 for the first time, the joining node specifies its own public key 477 in the "client_cred" parameter of the join request targeting the 478 join endpoint (see Section 4.1). 480 Before sending the join response, the Group Manager should verify 481 that the joining node actually owns the associated private key, for 482 instance by performing a proof-of-possession challenge-response, 483 whose details are out of the scope of this specification. 485 Furthermore, as described in Section 4.1, the joining node may have 486 explicitly requested the Group Manager to retrieve the public keys of 487 the current group members, i.e. through the "get_pub_keys" parameter 488 in the join request. In this case, the Group Manager includes also 489 such public keys in the "pub_keys" parameter of the join response 490 (see Section 4.2). 492 On the other hand, in case the Group Manager is not configured to 493 store public keys of group members, the joining node provides the 494 Group Manager with its own certificate in the "client_cred" parameter 495 of the join request targeting the join endpoint (see Section 4.1). 496 Then, the Group Manager validates and handles the certificate, for 497 instance as described in Appendix D.2 of 498 [I-D.ietf-core-oscore-groupcomm]. 500 6. Security Considerations 502 The method described in this document leverages the following 503 management aspects related to OSCORE groups and discussed in the 504 sections of [I-D.ietf-core-oscore-groupcomm] referred below. 506 o Management of group keying material (Section 2.1). This includes 507 the need to revoke and renew the keying material currently used in 508 the OSCORE group, upon changes in the group membership. In 509 particular, renewing the keying material is required upon a new 510 node joining the group, in order to preserve backward security. 511 That is, the Group Manager should renew the keying material before 512 completing the join process and sending a join response. Such a 513 join response provides the joining node with updated the keying 514 material just established in the group. The Group Manager is 515 responsible to enforce rekeying policies and accordingly update 516 the keying material in the groups of its competence (Section 6). 518 o Synchronization of sequence numbers (Section 5). This concerns 519 how a listener node that has just joined an OSCORE group can 520 synchronize with the sequence number of multicasters in the same 521 group. 523 o Provisioning and retrieval of public keys (Appendix D.2). This 524 provides guidelines about how to ensure the availability of group 525 members' public keys, possibly relying on the Group Manager as 526 trusted key repository (Section 6). 528 Further security considerations are inherited from the ACE framework 529 for Authentication and Authorization [I-D.ietf-ace-oauth-authz], as 530 well as from the specific profile of ACE signalled by the AS, such as 531 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 533 7. IANA Considerations 535 This document has no actions for IANA. 537 8. Acknowledgments 539 The authors sincerely thank Santiago Aragon, Stefan Beck, Martin 540 Gunnarsson, Francesca Palombini, Jim Schaad, Ludwig Seitz and Goeran 541 Selander for their comments and feedback. 543 The work on this document has been partly supported by the EIT- 544 Digital High Impact Initiative ACTIVE. 546 9. References 548 9.1. Normative References 550 [I-D.ietf-ace-dtls-authorize] 551 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 552 L. Seitz, "Datagram Transport Layer Security (DTLS) 553 Profiles for Authentication and Authorization for 554 Constrained Environments (ACE)", draft-ietf-ace-dtls- 555 authorize-02 (work in progress), October 2017. 557 [I-D.ietf-ace-oauth-authz] 558 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 559 H. Tschofenig, "Authentication and Authorization for 560 Constrained Environments (ACE)", draft-ietf-ace-oauth- 561 authz-10 (work in progress), February 2018. 563 [I-D.ietf-ace-oscore-profile] 564 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE 565 profile of the Authentication and Authorization for 566 Constrained Environments Framework", draft-ietf-ace- 567 oscore-profile-00 (work in progress), December 2017. 569 [I-D.ietf-core-object-security] 570 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 571 "Object Security for Constrained RESTful Environments 572 (OSCORE)", draft-ietf-core-object-security-08 (work in 573 progress), January 2018. 575 [I-D.ietf-core-oscore-groupcomm] 576 Tiloca, M., Selander, G., Palombini, F., and J. Park, 577 "Secure group communication for CoAP", draft-ietf-core- 578 oscore-groupcomm-01 (work in progress), March 2018. 580 [I-D.palombini-ace-key-groupcomm] 581 Palombini, F. and M. Tiloca, "Key Provisioning for Group 582 Communication using ACE", draft-palombini-ace-key- 583 groupcomm-00 (work in progress), March 2018. 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, 587 DOI 10.17487/RFC2119, March 1997, 588 . 590 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 591 Application Protocol (CoAP)", RFC 7252, 592 DOI 10.17487/RFC7252, June 2014, 593 . 595 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 596 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 597 May 2017, . 599 9.2. Informative References 601 [I-D.ietf-ace-actors] 602 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 603 architecture for authorization in constrained 604 environments", draft-ietf-ace-actors-06 (work in 605 progress), November 2017. 607 [I-D.ietf-core-resource-directory] 608 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 609 Amsuess, "CoRE Resource Directory", draft-ietf-core- 610 resource-directory-12 (work in progress), October 2017. 612 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 613 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 614 January 2012, . 616 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 617 RFC 6749, DOI 10.17487/RFC6749, October 2012, 618 . 620 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 621 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 622 DOI 10.17487/RFC7231, June 2014, 623 . 625 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 626 the Constrained Application Protocol (CoAP)", RFC 7390, 627 DOI 10.17487/RFC7390, October 2014, 628 . 630 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 631 RFC 8152, DOI 10.17487/RFC8152, July 2017, 632 . 634 Authors' Addresses 636 Marco Tiloca 637 RISE SICS AB 638 Isafjordsgatan 22 639 Kista SE-164 29 Stockholm 640 Sweden 642 Email: marco.tiloca@ri.se 644 Jiye Park 645 Universitaet Duisburg-Essen 646 Schuetzenbahn 70 647 Essen 45127 648 Germany 650 Email: ji-ye.park@uni-due.de