idnits 2.17.1 draft-tiloca-ace-oscoap-joining-02.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 (October 29, 2017) is 2365 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-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-08 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-06 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-11 -- 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: 1 error (**), 0 flaws (~~), 6 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: May 2, 2018 Universitaet Duisburg-Essen 6 October 29, 2017 8 Joining of OSCORE multicast groups in ACE 9 draft-tiloca-ace-oscoap-joining-02 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 for 15 Constrained RESTful Environments (OSCORE). The proposed method 16 delegates the authentication and authorization of client nodes that 17 join an OSCORE multicast group through a Group Manager server. This 18 approach builds on the ACE framework for Authentication and 19 Authorization, and leverages protocol-specific profiles of ACE to 20 achieve communication security, proof-of-possession and server 21 authentication. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 2, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Joining Node to Authorization Server . . . . . . . . . . . . 6 61 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 7 62 5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 8 63 6. Updating Authorization Information . . . . . . . . . . . . . 9 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 10.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 Object Security for Constrained RESTful Environments (OSCORE) 75 [I-D.ietf-core-object-security] is a method for application layer 76 protection of CoAP messages, using the CBOR Object Signing and 77 Encryption (COSE) [RFC8152], and enabling end-to-end security of CoAP 78 payload and options. 80 OSCORE may also be used to protect group communication for CoAP over 81 IP multicast, as described in [I-D.tiloca-core-multicast-oscoap]. 82 This relies on a Group Manager entity, which is responsible for 83 managing a multicast group where members exchange CoAP messages 84 secured with OSCORE. In particular, the Group Manager coordinates 85 the join process of new group members and can be responsible for 86 multiple groups. 88 This document builds on the ACE framework for Authentication and 89 Authorization [I-D.ietf-ace-oauth-authz] and specifies how a client 90 joins an OSCORE multicast group through a resource server acting as 91 Group Manager. The client acting as joining node relies on an Access 92 Token, which is bound to a proof-of-possession key and authorizes the 93 access to a specific join resource at the Group Manager. 95 In order to achieve communication security, proof-of-possession and 96 server authentication, the client and the Group Manager leverage 97 protocol-specific profiles of ACE such as the CoAP-DTLS profile 98 [I-D.ietf-ace-dtls-authorize], the OSCORE profile 99 [I-D.seitz-ace-oscoap-profile], or the IPsec profile 100 [I-D.aragon-ace-ipsec-profile]. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119][RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 Readers are expected to be familiar with the terms and concepts 111 described in the ACE framework for authentication and authorization 112 [I-D.ietf-ace-oauth-authz]. Message exchanges are presented as 113 RESTful protocol interactions, for which HTTP [RFC7231] provides 114 useful terminology. 116 The terminology for entities in the considered architecture is 117 defined in OAuth 2.0 [RFC6749] and [I-D.ietf-ace-actors]. In 118 particular, this includes Client (C), Resource Server (RS), and 119 Authorization Server (AS). Terminology for constrained environments, 120 such as "constrained device" and "constrained-node network", is 121 defined in [RFC7228]. 123 Readers are expected to be familiar with the terms and concepts 124 related to the CoAP protocol described in [RFC7252][RFC7390]. Note 125 that the term "endpoint" is used here following its OAuth definition, 126 aimed at denoting resources such as /token and /introspect at the AS 127 and /authz-info at the RS. This document does not use the CoAP 128 definition of "endpoint", which is "An entity participating in the 129 CoAP protocol". 131 Readers are expected to be familiar with the terms and concepts 132 related to the DTLS protocol [RFC6347] and with the CoAP-DTLS profile 133 of ACE [I-D.ietf-ace-dtls-authorize]. 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 contexts 138 [I-D.tiloca-core-multicast-oscoap]; and with the OSCORE profile of 139 ACE [I-D.seitz-ace-oscoap-profile]. 141 Readers are expected to be familiar with the terms and concepts 142 related to the IPsec protocol suite [RFC4301]; and with the IPsec 143 profile of ACE [I-D.aragon-ace-ipsec-profile]. 145 This document refers also to the following terminology. 147 o Joining node: a network node intending to join an OSCORE multicast 148 group, where communication is based on CoAP [RFC7390] and secured 149 with OSCORE as described in [I-D.tiloca-core-multicast-oscoap]. 151 o Join process: the process through which a joining node becomes a 152 member of an OSCORE multicast group. The join process is enforced 153 and assisted by the Group Manager responsible for that group. 155 o Join resource: a resource hosted by the Group Manager, associated 156 to an OSCORE multicast group under that Group Manager. A joining 157 node accesses the join resource in order to start the join process 158 and become a member of that group. 160 o Join endpoint: an endpoint at the Group Manager associated to a 161 join resource. 163 2. Protocol Overview 165 Group communication for CoAP over IP multicast has been enabled in 166 [RFC7390] and can be secured with Object Security for Constrained 167 RESTful Environments (OSCORE) [I-D.ietf-core-object-security] as 168 described in [I-D.tiloca-core-multicast-oscoap]. A network node 169 explicitly joins an OSCORE multicast group, by interacting with the 170 responsible Group Manager. Once registered in the group, the new 171 node can securely exchange (multicast) messages with other group 172 members. 174 This specification describes how a network node joins an OSCORE 175 multicast group leveraging the ACE framework for authentication and 176 authorization [I-D.ietf-ace-oauth-authz]. With reference to the ACE 177 framework and the terminology defined in OAuth 2.0 [RFC6749]: 179 o The Group Manager acts as Resource Server (RS), and hosts one join 180 resource for each OSCORE multicast group it manages. Each join 181 resource is exported by a distinct join endpoint. 183 o The joining node acts as Client (C), and requests to join an 184 OSCORE multicast group by accessing the related join endpoint at 185 the Group Manager. 187 o The Authorization Server (AS) enables and enforces the authorized 188 access of joining nodes to join endpoints at the Group Manager. 189 Multiple Group Managers can be associated to the same AS. 191 If the joining node is authorized to join the multicast group, it 192 receives from the AS an Access Token bound with a proof-of-possession 193 key. After that, the joining node provides the Group Manager with 194 the Access Token. This step involves the opening of a secure 195 communication channel between the joining node and the Group Manager, 196 in case they have not already established one. 198 Finally, the joining node accesses the join endpoint at the Group 199 Manager, so starting the join process to become a member of the 200 OSCORE multicast group. A same Access Token can authorize the 201 joining node to access multiple groups under the same Group Manager. 202 In such a case, the joining node sequentially performs multiple join 203 processes with the Group Manager, separately for each multicast group 204 to join and by accessing the respective join endpoint. 206 The AS is not necessarily expected to release Access Tokens for any 207 other purpose than accessing join resources on registered Group 208 Managers. However, the AS may be configured also to release Access 209 Tokens for accessing resources at members of multicast groups. 211 The following steps are performed for joining an OSCORE multicast 212 group, by leveraging one of the available profiles of ACE, such as 213 the CoAP-DTLS profile [I-D.ietf-ace-dtls-authorize], the OSCORE 214 profile [I-D.seitz-ace-oscoap-profile], or the IPsec profile 215 [I-D.aragon-ace-ipsec-profile]. 217 1. The joining node retrieves an Access Token from the AS to access 218 a join resource on the Group Manager (see Section 3). The 219 response from the AS enables the joining node to start a secure 220 channel with the Group Manager, if not already established. The 221 joining node can also contact the AS for updating a previously 222 released Access Token, in order to access further groups under 223 the same Group Manager (see Section 6). 225 2. Authentication and authorization information is transferred 226 between the joining node and the Group Manager, which establish a 227 secure channel in case one is not already set up (see Section 4). 228 That is, a joining node MUST establish a secure communication 229 channel with a Group Manager, before joining an OSCORE multicast 230 group under that Group Manager for the first time. 232 3. The joining node starts the join process to become a member of 233 the OSCORE multicast group, by accessing the related join 234 resource hosted by the Group Manager (see Section 4). 236 All communications between the involved entities rely on the CoAP 237 protocol and MUST be secured. In particular, communications between 238 the joining node and the AS (/token endpoint) and between the Group 239 Manager and the AS (/introspection endpoint) can be secured by 240 different means, for instance by means of DTLS [RFC6347], OSCORE (see 241 Sections 3 and 4 of [I-D.seitz-ace-oscoap-profile]), or IPsec (see 242 Sections 3.2 and 3.4 of [I-D.aragon-ace-ipsec-profile]). 244 Further details on how the AS secures communications (with the 245 joining node and the Group Manager) depend on the specifically used 246 profile of ACE, and are out of the scope of this specification. 248 3. Joining Node to Authorization Server 250 This section considers a joining node that intends to contact the 251 Group Manager for the first time. That is, the joining node has 252 never attempted before to join an OSCORE multicast group under that 253 Group Manager. Also, the joining node and the Group Manager do not 254 have a secure communication channel established. 256 In case the specific AS associated to the Group Manager is unknown to 257 the joining node, the latter can rely on mechanisms like the 258 Unauthorized Resource Request message described in Section 2.1 of 259 [I-D.ietf-ace-dtls-authorize] to discover the correct AS in charge of 260 the Group Manager. As an alternative, the joining node may look up 261 in a Resource Directory service [I-D.ietf-core-resource-directory]. 263 The joining node contacts the AS, in order to request an Access Token 264 for accessing the join resource(s) hosted by the Group Manager. In 265 particular, the Access Token request sent to the /token endpoint 266 specifies the join endpoint(s) of interest at the Group Manager. 268 The AS is responsible for authorizing the joining node, accordingly 269 to group join policies enforced on behalf of the Group Manager. In 270 case of successful authorization, the AS releases an Access Token 271 bound to a proof-of-possession key associated to the joining node. 272 The same Access Token can authorize the joining node to access 273 multiple groups under the same Group Manager. 275 Then, the AS provides the joining node with the Access Token, 276 together with an Access Token response. In particular, the Access 277 Token response indicates how to secure communications with the Group 278 Manager, when accessing the join resource(s) for which the Access 279 Token is valid. Specifically, the Access Token response MUST specify 280 one of the following alternatives: 282 o CoAP over DTLS, i.e. coaps://, indicating to consider the CoAP- 283 DTLS profile of ACE, with asymmetric or symmetric proof-of- 284 possession key (see Section 3 and Section 4 of 285 [I-D.ietf-ace-dtls-authorize], respectively). 287 o OSCORE, indicating to consider the OSCORE profile of ACE with the 288 symmetric proof-of-possession key used directly as Master Secret 289 in OSCORE [I-D.ietf-core-object-security], as described in 290 Section 2 of [I-D.seitz-ace-oscoap-profile]. 292 o IPsec, indicating to consider the IPsec profile of ACE, with 293 symmetric or asymmetric proof-of-possession key (see Section 3.2.2 294 and Section 3.2.3 of [I-D.aragon-ace-ipsec-profile], 295 respectively). 297 Consistently with the profiles of ACE [I-D.ietf-ace-dtls-authorize][I 298 -D.seitz-ace-oscoap-profile][I-D.aragon-ace-ipsec-profile], a 299 symmetric proof-of-possession key is generated by the AS, which uses 300 it as proof-of-possession key bound to the Access Token, and provides 301 it to the joining node in the Access Token response. 303 Instead, consistently with the profiles of ACE 304 [I-D.ietf-ace-dtls-authorize][I-D.aragon-ace-ipsec-profile], in case 305 of asymmetric proof-of-possession key, the joining node provides its 306 own public key to the AS in the Access Token request. Then, the AS 307 uses it as proof-of-possession key bound to the Access Token, and 308 provides the joining node with the Group Manager's public key in the 309 Access Token response. 311 4. Joining Node to Group Manager 313 First, the joining node establishes a secure channel with the Group 314 Manager, according to what is specified in the Access Token response. 315 In particular: 317 o If the CoAP-DTLS profile of ACE is specified, the joining node 318 MUST upload the Access Token to the /authz-info resource, before 319 starting the DTLS handshake and establishing a DTLS channel with 320 the Group Manager. Then, the Group Manager processes the Access 321 Token according to [I-D.ietf-ace-oauth-authz]. If this yields to 322 a positive response, the joining node and the Group Manager 323 establish a DTLS session, as described in Section 3 and Section 4 324 of [I-D.ietf-ace-dtls-authorize], in case of either asymmetric or 325 symmetric proof-of-possession key, respectively. 327 o If the OSCORE profile of ACE is specified, the joining node and 328 the Group Manager establish an OSCORE Security Context, as 329 described in Section 2.2 of [I-D.seitz-ace-oscoap-profile]. The 330 Group Manager processes the Access Token as specified in 331 [I-D.ietf-ace-oauth-authz] and proceeds as defined in Section 2.2 332 of [I-D.seitz-ace-oscoap-profile]. 334 o If the IPsec profile of ACE is specified, the joining node MUST 335 upload the Access Token to the /authz-info resource, before 336 performing the key management protocol indicated by the AS (e.g. 338 IKEv2 [RFC7296]) to establish an IPsec Security Association pair 339 and an IPsec channel with the Group Manager. Then, the Group 340 Manager processes the Access Token according to 341 [I-D.ietf-ace-oauth-authz]. If this yields to a positive 342 response, the joining node and the Group Manager establish an 343 IPsec Security Association pair and an IPsec channel, as described 344 in Section 3.3.2 of [I-D.aragon-ace-ipsec-profile]. 346 Once a secure communication channel with the Group Manager has been 347 established, the joining node requests to join the OSCORE multicast 348 groups of interest, by accessing the related join resources at the 349 Group Manager. That is, the joining node performs multiple join 350 processes with the Group Manager, separately for each multicast group 351 to join and by accessing the respective join endpoint. 353 In particular, for each OSCORE multicast group to join, the joining 354 node sends to the Group Manager a confirmable CoAP request, using the 355 method POST and targeting the join endpoint associated to that group. 356 The request payload conveys the information specified in Appendix C.1 357 of [I-D.tiloca-core-multicast-oscoap], which includes the intended 358 role(s) of the joining node in the multicast group, i.e. multicaster 359 and/or (pure) listener. 361 The Group Manager processes the request according to 362 [I-D.ietf-ace-oauth-authz]. If this yields to a positive response, 363 the Group Manager updates the group membership by registering the 364 joining node as a new member of the group. Then, the Group Manager 365 replies to the joining node providing the information specified in 366 Appendix C.1 of [I-D.tiloca-core-multicast-oscoap], which includes 367 the OSCORE Security Common Context associated to the joined multicast 368 group. 370 From then on, the joining node is registered as a member of the 371 multicast group, and can exchange group messages secured with OSCORE 372 as described in Section 5 of [I-D.tiloca-core-multicast-oscoap]. 374 5. Public Keys of Joining Nodes 376 Source authentication of OSCORE messages exchanged within the 377 multicast group is ensured by means of digital counter signatures 378 [I-D.tiloca-core-multicast-oscoap]. Therefore, group members must be 379 able to retrieve each other's public key from a trusted key 380 repository, in order to verify the source authenticity of incoming 381 group messages. 383 Upon joining a multicast group, a joining node is expected to make 384 its own public key available to the other group members, either 385 through the Group Manager or through another trusted, publicly 386 available, key repository. However, this is not required for a node 387 that joins a group exclusively as pure listener. 389 As also discussed in Section 3 of [I-D.tiloca-core-multicast-oscoap], 390 it is recommended that the Group Manager is configured to store the 391 public keys of the group members and to provide them upon request. 392 If so, two cases can occur. 394 o The joining node and the Group Manager have used an asymmetric 395 proof-of-possession key to establish a secure communication 396 channel. In this case, the Group Manager stores the proof-of- 397 possession key conveyed in the Access Token as the public key of 398 the joining node. 400 o The joining node and the Group Manager have used a symmetric 401 proof-of-possession key to establish a secure communication 402 channel. In this case, upon performing a join process with that 403 Group Manager for the first time, the joining node includes its 404 own public key in the "Identity credentials" of the POST request 405 targeting the join endpoint (see Appendix C.1 of 406 [I-D.tiloca-core-multicast-oscoap]). Then, the Group Manager MUST 407 verify that the joining node actually owns the associated private 408 key, for instance by performing a proof-of-possession challenge- 409 response. 411 Then, if the joining node has explicitly requested it, the Group 412 Manager provides also the public keys of the current members in the 413 joined group, when replying to the joining node during the same join 414 process (see Appendix C.1 of [I-D.tiloca-core-multicast-oscoap]). 416 Instead, in case the Group Manager is not configured to store public 417 keys of group members, the joining node provides the Group Manager 418 with its own certificate and with the identifier of the Certification 419 Authority that issued that certificate (see Appendix C.2 of 420 [I-D.tiloca-core-multicast-oscoap]). 422 6. Updating Authorization Information 424 At any point in time, a node might want to join further OSCORE 425 multicast groups under the same Group Manager. In such a case, the 426 joining node requests from the AS an updated Access Token for 427 accessing the new OSCORE multicast groups of interest. 429 The joining node uploads the new Access Token to the /authz-info 430 resource at the Group Manager, using the already established secure 431 communication channel. After that, the joining node performs the 432 joining process described in Section 4, separately for each OSCORE 433 multicast group to join. 435 Since the joining node and the Group Manager already share a secure 436 communication channel, they are not required to establish a new one. 437 However, according to the specific profile of ACE in use, the joining 438 node and the Group Manager may leverage the new Access Token to 439 establish a new secure communication channel or update the currently 440 existing one. For instance, Section 4.2 of 441 [I-D.ietf-ace-dtls-authorize] describes how the new Access Token can 442 be used to renegotiate an existing DTLS session or to establish a new 443 one by performing a new DTLS handshake. 445 7. Security Considerations 447 The method described in this document leverages the following 448 management aspects related to OSCORE multicast groups and discussed 449 in the sections of [I-D.tiloca-core-multicast-oscoap] indicated 450 below. 452 o Management of group keying material (Section 3.1). This includes 453 the need to revoke and renew the keying material currently used in 454 the OSCORE multicast group, upon changes in the group membership. 455 In particular, renewing the keying material is required upon a new 456 node joining the multicast group, in order to preserve backward 457 security. The Group Manager is responsible to enforce rekeying 458 policies and accordingly update the keying material within the 459 multicast groups of its competence. 461 o Synchronization of sequence numbers (Section 6). This concerns 462 how a listener node that has just joined an OSCORE multicast group 463 can synchronize with the sequence number of multicasters in the 464 same group. 466 o Provisioning and retrieval of public keys (Appendix C.2). This 467 provides guidelines about how to ensure the availability of group 468 members' public keys, possibly relying on the Group Manager as 469 trusted key repository. 471 Further security considerations are inherited from the ACE framework 472 for Authentication and Authorization [I-D.ietf-ace-oauth-authz], as 473 well as from the profiles of ACE [I-D.ietf-ace-dtls-authorize][I-D.se 474 itz-ace-oscoap-profile][I-D.aragon-ace-ipsec-profile]. 476 8. IANA Considerations 478 This document has no actions for IANA. 480 9. Acknowledgments 482 The authors sincerely thank Santiago Aragon, Stefan Beck, Martin 483 Gunnarsson, Francesca Palombini, Jim Schaad, Ludwig Seitz and Goeran 484 Selander for their comments and feedback. 486 10. References 488 10.1. Normative References 490 [I-D.aragon-ace-ipsec-profile] 491 Aragon, S., Tiloca, M., and S. Raza, "IPsec profile of 492 ACE", draft-aragon-ace-ipsec-profile-01 (work in 493 progress), October 2017. 495 [I-D.ietf-ace-actors] 496 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 497 architecture for authorization in constrained 498 environments", draft-ietf-ace-actors-05 (work in 499 progress), March 2017. 501 [I-D.ietf-ace-dtls-authorize] 502 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 503 L. Seitz, "Datagram Transport Layer Security (DTLS) 504 Profile for Authentication and Authorization for 505 Constrained Environments (ACE)", draft-ietf-ace-dtls- 506 authorize-01 (work in progress), July 2017. 508 [I-D.ietf-ace-oauth-authz] 509 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 510 H. Tschofenig, "Authentication and Authorization for 511 Constrained Environments (ACE)", draft-ietf-ace-oauth- 512 authz-08 (work in progress), October 2017. 514 [I-D.ietf-core-object-security] 515 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 516 "Object Security for Constrained RESTful Environments 517 (OSCORE)", draft-ietf-core-object-security-06 (work in 518 progress), October 2017. 520 [I-D.seitz-ace-oscoap-profile] 521 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE 522 profile of the Authentication and Authorization for 523 Constrained Environments Framework", draft-seitz-ace- 524 oscoap-profile-06 (work in progress), October 2017. 526 [I-D.tiloca-core-multicast-oscoap] 527 Tiloca, M., Selander, G., Palombini, F., and J. Park, 528 "Secure group communication for CoAP", draft-tiloca-core- 529 multicast-oscoap-04 (work in progress), October 2017. 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, 533 DOI 10.17487/RFC2119, March 1997, . 536 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 537 Application Protocol (CoAP)", RFC 7252, 538 DOI 10.17487/RFC7252, June 2014, . 541 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 542 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 543 May 2017, . 545 10.2. Informative References 547 [I-D.ietf-core-resource-directory] 548 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 549 Amsuess, "CoRE Resource Directory", draft-ietf-core- 550 resource-directory-11 (work in progress), July 2017. 552 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 553 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 554 December 2005, . 556 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 557 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 558 January 2012, . 560 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 561 RFC 6749, DOI 10.17487/RFC6749, October 2012, 562 . 564 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 565 Constrained-Node Networks", RFC 7228, 566 DOI 10.17487/RFC7228, May 2014, . 569 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 570 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 571 DOI 10.17487/RFC7231, June 2014, . 574 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 575 Kivinen, "Internet Key Exchange Protocol Version 2 576 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 577 2014, . 579 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 580 the Constrained Application Protocol (CoAP)", RFC 7390, 581 DOI 10.17487/RFC7390, October 2014, . 584 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 585 RFC 8152, DOI 10.17487/RFC8152, July 2017, 586 . 588 Authors' Addresses 590 Marco Tiloca 591 RISE SICS AB 592 Isafjordsgatan 22 593 Kista SE-164 29 Stockholm 594 Sweden 596 Email: marco.tiloca@ri.se 598 Jiye Park 599 Universitaet Duisburg-Essen 600 Schuetzenbahn 70 601 Essen 45127 602 Germany 604 Email: ji-ye.park@uni-due.de