idnits 2.17.1 draft-ietf-ace-oscore-profile-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 31 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2020) is 1274 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-13 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track L. Seitz 5 Expires: April 30, 2021 Combitech 6 G. Selander 7 Ericsson AB 8 M. Gunnarsson 9 RISE 10 October 27, 2020 12 OSCORE Profile of the Authentication and Authorization for Constrained 13 Environments Framework 14 draft-ietf-ace-oscore-profile-13 16 Abstract 18 This memo specifies a profile for the Authentication and 19 Authorization for Constrained Environments (ACE) framework. It 20 utilizes Object Security for Constrained RESTful Environments 21 (OSCORE) to provide communication security and proof-of-possession 22 for a key owned by the client and bound to an OAuth 2.0 access token. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 30, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 6 62 3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 6 63 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 8 64 3.2.1. The OSCORE_Input_Material . . . . . . . . . . . . . . 12 65 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 15 66 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 16 67 4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 17 68 4.1.2. The ace_client_recipientid Parameter . . . . . . . . 17 69 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 17 70 4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 19 71 4.2.2. The ace_server_recipientid Parameter . . . . . . . . 19 72 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 19 73 4.4. Access rights verification . . . . . . . . . . . . . . . 22 74 5. Secure Communication with AS . . . . . . . . . . . . . . . . 22 75 6. Discarding the Security Context . . . . . . . . . . . . . . . 22 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 77 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 79 9.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 25 80 9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 26 81 9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 26 82 9.4. OSCORE Security Context Parameters Registry . . . . . . . 27 83 9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 28 84 9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 28 85 9.7. Expert Review Instructions . . . . . . . . . . . . . . . 28 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 88 10.2. Informative References . . . . . . . . . . . . . . . . . 30 89 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 31 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 93 1. Introduction 95 This memo specifies a profile of the ACE framework 96 [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource 97 server use the Constrained Application Protocol (CoAP) [RFC7252] to 98 communicate. The client uses an access token, bound to a symmetric 99 key (the proof-of-possession key) to authorize its access to the 100 resource server. Note that this profile uses a symmetric-crypto- 101 based scheme, where the symmetric secret is used as input material 102 for keying material derivation. In order to provide communication 103 security and proof of possession, the client and resource server use 104 Object Security for Constrained RESTful Environments (OSCORE) 105 [RFC8613]. Note that the proof of possession is not done by a 106 dedicated protocol element, but rather occurs after the first OSCORE 107 exchange. 109 OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) 110 [RFC8152] to secure CoAP messages. Note that OSCORE can be used to 111 secure CoAP messages, as well as HTTP and combinations of HTTP and 112 CoAP; a profile of ACE similar to the one described in this document, 113 with the difference of using HTTP instead of CoAP as communication 114 protocol, could be specified analogously to this one. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 Certain security-related terms such as "authentication", 125 "authorization", "confidentiality", "(data) integrity", "message 126 authentication code", and "verify" are taken from [RFC4949]. 128 RESTful terminology follows HTTP [RFC7231]. 130 Terminology for entities in the architecture is defined in OAuth 2.0 131 [RFC6749], such as client (C), resource server (RS), and 132 authorization server (AS). It is assumed in this document that a 133 given resource on a specific RS is associated to a unique AS. 135 Concise Binary Object Representation (CBOR) [I-D.ietf-cbor-7049bis] 136 and Concise Data Definition Language (CDDL) [RFC8610] are used in 137 this specification. CDDL predefined type names, especially bstr for 138 CBOR byte strings and tstr for CBOR text strings, are used 139 extensively in the document. 141 Note that the term "endpoint" is used here, as in 142 [I-D.ietf-ace-oauth-authz], following its OAuth definition, which is 143 to denote resources such as token and introspect at the AS and authz- 144 info at the RS. The CoAP [RFC7252] definition, which is "An entity 145 participating in the CoAP protocol" is not used in this memo. 147 2. Protocol Overview 149 This section gives an overview of how to use the ACE Framework 150 [I-D.ietf-ace-oauth-authz] to secure the communication between a 151 client and a resource server using OSCORE [RFC8613]. The parameters 152 needed by the client to negotiate the use of this profile with the 153 authorization server, as well as the OSCORE setup process, are 154 described in detail in the following sections. 156 The RS maintains a collection of OSCORE Security Contexts with 157 associated authorization information for all the clients that it is 158 communicating with. The authorization information is maintained as 159 policy that is used as input to processing requests from those 160 clients. 162 This profile requires a client to retrieve an access token from the 163 AS for the resource it wants to access on an RS, by sending an access 164 token request to the token endpoint, as specified in section 5.6 of 165 [I-D.ietf-ace-oauth-authz]. The access token request and response 166 MUST be confidentiality-protected and ensure authenticity. This 167 profile RECOMMENDS the use of OSCORE between client and AS, but other 168 protocols (such as TLS or DTLS) can be used as well. 170 Once the client has retrieved the access token, it generates a nonce 171 N1. The client also generates its OSCORE Recipient ID (see 172 Section 3.1 of [RFC8613]), ID1, for use with the keying material 173 associated to the RS. The client posts the token, N1 and its 174 Recipient ID to the RS using the authz-info endpoint and mechanisms 175 specified in section 5.8 of [I-D.ietf-ace-oauth-authz] and Content- 176 Format = application/ace+cbor. When using this profile, the 177 communication with the authz-info endpoint is not protected, except 178 for update of access rights. 180 If the access token is valid, the RS replies to this request with a 181 2.01 (Created) response with Content-Format = application/ace+cbor, 182 which contains a nonce N2 and its newly generated OSCORE Recipient 183 ID, ID2, for use with the keying material associated to the client. 184 Moreover, the server concatenates the input salt received in the 185 token, N1, and N2 to obtain the Master Salt of the OSCORE Security 186 Context (see section 3 of [RFC8613]). The RS then derives the 187 complete Security Context associated with the received token from the 188 Master Salt, the OSCORE Recipient ID generated by the client (set as 189 its OSCORE Sender ID), its own OSCORE Recipient ID, plus the 190 parameters received in the access token from the AS, following 191 section 3.2 of [RFC8613]. 193 In a similar way, after receiving the nonce N2, the client 194 concatenates the input salt, N1 and N2 to obtain the Master Salt of 195 the OSCORE Security Context. The client then derives the complete 196 Security Context from the Master Salt, the OSCORE Recipient ID 197 generated by the RS (set as its OSCORE Sender ID), its own OSCORE 198 Recipient ID, plus the parameters received from the AS. 200 Finally, the client sends a request protected with OSCORE to the RS. 201 If the request verifies, the server stores the complete Security 202 Context state that is ready for use in protecting messages, and uses 203 it in the response, and in further communications with the client, 204 until token expiration. This Security Context is discarded when a 205 token (whether the same or different) is used to successfully derive 206 a new Security Context for that client. 208 The use of random nonces during the exchange prevents the reuse of an 209 Authenticated Encryption with Associated Data (AEAD) nonces/key pair 210 for two different messages. Two-time pad might otherwise occur when 211 client and RS derive a new Security Context from an existing (non- 212 expired) access token, as might occur when either party has just 213 rebooted. Instead, by using random nonces as part of the Master 214 Salt, the request to the authz-info endpoint posting the same token 215 results in a different Security Context, by OSCORE construction, 216 since even though the Master Secret, Sender ID and Recipient ID are 217 the same, the Master Salt is different (see Section 3.2.1 of 218 [RFC8613]). Therefore, the main requirement for the nonces is that 219 they have a good amount of randomness. If random nonces were not 220 used, a node re-using a non-expired old token would be susceptible to 221 on-path attackers provoking the creation of OSCORE messages using old 222 AEAD keys and nonces. 224 After the whole message exchange has taken place, the client can 225 contact the AS to request an update of its access rights, sending a 226 similar request to the token endpoint that also includes an 227 identifier so that the AS can find the correct OSCORE security 228 material it has previously shared with the client. This specific 229 identifier, encoded as a byte string, is assigned by the AS to be 230 unique in the sets of its OSCORE Security Contexts, and is not used 231 as input material to derive the full OSCORE Security Context. 233 An overview of the profile flow for the OSCORE profile is given in 234 Figure 1. The names of messages coincide with those of 235 [I-D.ietf-ace-oauth-authz] when applicable. 237 C RS AS 238 | | | 239 | ----- POST /token ----------------------------> | 240 | | | 241 | <---------------------------- Access Token ----- | 242 | + Access Information | 243 | ---- POST /authz-info ---> | | 244 | (access_token, N1, ID1) | | 245 | | | 246 | <- 2.01 Created (N2, ID2)- | | 247 | | | 248 /Sec Context /Sec Context | 249 derivation/ derivation/ | 250 | | | 251 | ---- OSCORE Request -----> | | 252 | | | 253 | /proof-of-possession | 254 | Sec Context storage/ | 255 | | | 256 | <--- OSCORE Response ----- | | 257 | | | 258 /proof-of-possession | | 259 Sec Context storage/ | | 260 | | | 261 | ---- OSCORE Request -----> | | 262 | | | 263 | <--- OSCORE Response ----- | | 264 | ... | | 266 Figure 1: Protocol Overview 268 3. Client-AS Communication 270 The following subsections describe the details of the POST request 271 and response to the token endpoint between client and AS. 272 Section 3.2 of [RFC8613] defines how to derive a Security Context 273 based on a shared master secret and a set of other parameters, 274 established between client and server, which the client receives from 275 the AS in this exchange. The proof-of-possession key (pop-key) 276 included in the response from the AS MUST be used as master secret in 277 OSCORE. 279 3.1. C-to-AS: POST to token endpoint 281 The client-to-AS request is specified in Section 5.6.1 of 282 [I-D.ietf-ace-oauth-authz]. 284 The client must send this POST request to the token endpoint over a 285 secure channel that guarantees authentication, message integrity and 286 confidentiality (see Section 5). 288 An example of such a request, with payload in CBOR diagnostic 289 notation without the tag and value abbreviations is reported in 290 Figure 2 292 Header: POST (Code=0.02) 293 Uri-Host: "as.example.com" 294 Uri-Path: "token" 295 Content-Format: "application/ace+cbor" 296 Payload: 297 { 298 "req_aud" : "tempSensor4711", 299 "scope" : "read" 300 } 302 Figure 2: Example C-to-AS POST /token request for an access token 303 bound to a symmetric key. 305 If the client wants to update its access rights without changing an 306 existing OSCORE Security Context, it MUST include in its POST request 307 to the token endpoint a req_cnf object. kid field carrying a CBOR 308 byte string containing the OSCORE_Input_Material Identifier (assigned 309 as discussed in Section 3.2). This identifier, together with other 310 information such as audience (see Section 5.6.1 of 311 [I-D.ietf-ace-oauth-authz]), can be used by the AS to determine the 312 shared secret bound to the proof-of-possession token and therefore 313 MUST identify a symmetric key that was previously generated by the AS 314 as a shared secret for the communication between the client and the 315 RS. The AS MUST verify that the received value identifies a proof- 316 of-possession key that has previously been issued to the requesting 317 client. If that is not the case, the Client-to-AS request MUST be 318 declined with the error code 'invalid_request' as defined in 319 Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 321 An example of such a request, with payload in CBOR diagnostic 322 notation without the tag and value abbreviations is reported in 323 Figure 3 324 Header: POST (Code=0.02) 325 Uri-Host: "as.example.com" 326 Uri-Path: "token" 327 Content-Format: "application/ace+cbor" 328 Payload: 329 { 330 "req_aud" : "tempSensor4711", 331 "scope" : "write", 332 "req_cnf" : { 333 "kid" : h'01' 334 } 336 Figure 3: Example C-to-AS POST /token request for updating rights to 337 an access token bound to a symmetric key. 339 3.2. AS-to-C: Access Token 341 After verifying the POST request to the token endpoint and that the 342 client is authorized to obtain an access token corresponding to its 343 access token request, the AS responds as defined in section 5.6.2 of 344 [I-D.ietf-ace-oauth-authz]. If the client request was invalid, or 345 not authorized, the AS returns an error response as described in 346 section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 348 The AS can signal that the use of OSCORE is REQUIRED for a specific 349 access token by including the "profile" parameter with the value 350 "coap_oscore" in the access token response. This means that the 351 client MUST use OSCORE towards all resource servers for which this 352 access token is valid, and follow Section 4.3 to derive the security 353 context to run OSCORE. Usually it is assumed that constrained 354 devices will be pre-configured with the necessary profile, so that 355 this kind of profile negotiation can be omitted. 357 Moreover, the AS MUST send the following data: 359 o a master secret 361 o an identifier of the OSCORE Input Material 363 Additionally, the AS MAY send the following data, in the same 364 response. 366 o a context identifier 368 o an AEAD algorithm 370 o an HMAC-based key derivation function (HKDF) algorithm 371 o a salt 373 o the OSCORE version number 375 This data is transported in the the OSCORE_Input_Material. The 376 OSCORE_Input_Material is a CBOR map object, defined in Section 3.2.1. 377 This object is transported in the 'cnf' parameter of the access token 378 response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params], as 379 the value of a field named 'osc', registered in Section 9.5 and 380 Section 9.6. 382 The AS MAY assign an identifier to the context (context identifier). 383 This identifier is used as ID Context in the OSCORE context as 384 described in section 3.1 of [RFC8613]. If assigned, this parameters 385 MUST be communicated as the 'contextId' field in the 386 OSCORE_Input_Material. The applications needs to consider that this 387 identifier is sent in the clear and may reveal information about the 388 endpoints, as mentioned in section 12.8 of [RFC8613]. 390 The master secret and the identifier of the OSCORE_Input_Material 391 MUST be communicated as the 'ms' and 'id' field in the 'osc' field in 392 the 'cnf' parameter of the access token response. If included, the 393 AEAD algorithm is sent in the 'alg' parameter in the 394 OSCORE_Input_Material; the HKDF algorithm in the 'hkdf' parameter of 395 the OSCORE_Input_Material; a salt in the 'salt' parameter of the 396 OSCORE_Input_Material; and the OSCORE version in the 'version' 397 parameter of the OSCORE_Input_Material. 399 The same parameters MUST be included in the claims associated with 400 the access token. This profile RECOMMENDS the use of CBOR web token 401 (CWT) as specified in [RFC8392]. If the token is a CWT, the same 402 OSCORE_Input_Material structure defined above MUST be placed in the 403 'osc' field of the 'cnf' claim of this token. 405 The AS MUST send different OSCORE_Input_Material (and therefore 406 different access tokens) to different authorized clients, in order 407 for the RS to differentiate between clients. 409 Figure 4 shows an example of an AS response, with payload in CBOR 410 diagnostic notation without the tag and value abbreviations. The 411 access token has been truncated for readability. 413 Header: Created (Code=2.01) 414 Content-Type: "application/ace+cbor" 415 Payload: 416 { 417 "access_token" : h'8343a1010aa2044c53 ... 418 (remainder of access token (CWT) omitted for brevity)', 419 "profile" : "coap_oscore", 420 "expires_in" : "3600", 421 "cnf" : { 422 "osc" : { 423 "id" : h'01', 424 "ms" : h'f9af838368e353e78888e1426bd94e6f' 425 } 426 } 427 } 429 Figure 4: Example AS-to-C Access Token response with OSCORE profile. 431 Figure 5 shows an example CWT Claims Set, including the relevant 432 OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation 433 without tag and value abbreviations. 435 { 436 "aud" : "tempSensorInLivingRoom", 437 "iat" : "1360189224", 438 "exp" : "1360289224", 439 "scope" : "temperature_g firmware_p", 440 "cnf" : { 441 "osc" : { 442 "ms" : h'f9af838368e353e78888e1426bd94e6f', 443 "id" : h'01' 444 } 445 } 446 } 448 Figure 5: Example CWT Claims Set with OSCORE parameters. 450 The same CWT Claims Set as in Figure 5, using the value abbreviations 451 defined in [I-D.ietf-ace-oauth-authz] and [RFC8747] and encoded in 452 CBOR is shown in Figure 6. The bytes in hexadecimal are reported in 453 the first column, while their corresponding CBOR meaning is reported 454 after the '#' sign on the second column, for easiness of readability. 456 NOTE TO THE RFC EDITOR: before publishing, it should be checked (and 457 in case fixed) that the values used below (which are not yet 458 registered) are the final values registered in IANA. 460 A5 # map(5) 461 63 # text(3) 462 617564 # "aud" 463 76 # text(22) 464 74656D7053656E736F72496E4C6976696E67526F6F6D 465 # "tempSensorInLivingRoom" 466 63 # text(3) 467 696174 # "iat" 468 6A # text(10) 469 31333630313839323234 # "1360189224" 470 63 # text(3) 471 657870 # "exp" 472 6A # text(10) 473 31333630323839323234 # "1360289224" 474 65 # text(5) 475 73636F7065 # "scope" 476 78 18 # text(24) 477 74656D70657261747572655F67206669726D776172655F70 478 # "temperature_g firmware_p" 479 63 # text(3) 480 636E66 # "cnf" 481 A1 # map(1) 482 63 # text(3) 483 6F7363 # "osc" 484 A2 # map(2) 485 62 # text(2) 486 6D73 # "ms" 487 50 # bytes(16) 488 F9AF838368E353E78888E1426BD94E6F 489 # "\xF9\xAF\x83\x83h\xE3S\xE7 490 \x88\x88\xE1Bk\xD9No" 491 62 # text(2) 492 6964 # "id" 493 41 # bytes(1) 494 01 # "\x01" 496 Figure 6: Example CWT Claims Set with OSCORE parameters, CBOR 497 encoded. 499 If the client has requested an update to its access rights using the 500 same OSCORE Security Context, which is valid and authorized, the AS 501 MUST omit the 'cnf' parameter in the response, and MUST carry the 502 OSCORE Input Material identifier in the 'kid' field in the 'cnf' 503 parameter of the token. This identifier needs to be included in the 504 token in order for the RS to identify the correct OSCORE Input 505 Material. 507 Figure 7 shows an example of such an AS response, with payload in 508 CBOR diagnostic notation without the tag and value abbreviations. 509 The access token has been truncated for readability. 511 Header: Created (Code=2.01) 512 Content-Type: "application/ace+cbor" 513 Payload: 514 { 515 "access_token" : h'8343a1010aa2044c53 ... 516 (remainder of access token (CWT) omitted for brevity)', 517 "profile" : "coap_oscore", 518 "expires_in" : "3600" 519 } 521 Figure 7: Example AS-to-C Access Token response with OSCORE profile, 522 for update of access rights. 524 Figure 8 shows an example CWT Claims Set, containing the necessary 525 OSCORE parameters in the 'cnf' claim for update of access rights, in 526 CBOR diagnostic notation without tag and value abbreviations. 528 { 529 "aud" : "tempSensorInLivingRoom", 530 "iat" : "1360189224", 531 "exp" : "1360289224", 532 "scope" : "temperature_h", 533 "cnf" : { 534 "kid" : h'01' 535 } 536 } 538 Figure 8: Example CWT Claims Set with OSCORE parameters for update of 539 access rights. 541 3.2.1. The OSCORE_Input_Material 543 An OSCORE_Input_Material is an object that represents the input 544 material to derive an OSCORE Security Context, i.e., the local set of 545 information elements necessary to carry out the cryptographic 546 operations in OSCORE (Section 3.1 of [RFC8613]). In particular, the 547 OSCORE_Input_Material is defined to be serialized and transported 548 between nodes, as specified by this document, but can also be used by 549 other specifications if needed. The OSCORE_Input_Material can either 550 be encoded as a JSON object or as a CBOR map. The set of common 551 parameters that can appear in an OSCORE_Input_Material can be found 552 in the IANA "OSCORE Security Context Parameters" registry 553 (Section 9.4), defined for extensibility, and is specified below. 554 All parameters are optional. Table 1 provides a summary of the 555 OSCORE_Input_Material parameters defined in this section. 557 +-----------+-------+-------------+-------------------+-------------+ 558 | name | CBOR | CBOR type | registry | description | 559 | | label | | | | 560 +-----------+-------+-------------+-------------------+-------------+ 561 | version | 0 | unsigned | | OSCORE | 562 | | | integer | | Version | 563 | | | | | | 564 | ms | 1 | byte string | | OSCORE | 565 | | | | | Master | 566 | | | | | Secret | 567 | | | | | value | 568 | | | | | | 569 | id | 2 | byte string | | OSCORE | 570 | | | | | Input | 571 | | | | | Material | 572 | | | | | Identifier | 573 | | | | | | 574 | hkdf | 3 | text string | [COSE.Algorithms] | OSCORE HKDF | 575 | | | / integer | Values (HMAC- | value | 576 | | | | based) | | 577 | | | | | | 578 | alg | 4 | text string | [COSE.Algorithms] | OSCORE AEAD | 579 | | | / integer | Values (AEAD) | Algorithm | 580 | | | | | value | 581 | | | | | | 582 | salt | 5 | byte string | | an input to | 583 | | | | | OSCORE | 584 | | | | | Master Salt | 585 | | | | | value | 586 | | | | | | 587 | contextId | 6 | byte string | | OSCORE ID | 588 | | | | | Context | 589 | | | | | value | 590 +-----------+-------+-------------+-------------------+-------------+ 592 Table 1: OSCORE_Input_Material Parameters 594 version: This parameter identifies the OSCORE Version number, which 595 is an unsigned integer. For more information about this field, 596 see section 5.4 of [RFC8613]. In JSON, the "version" value is an 597 integer. In CBOR, the "version" type is int, and has label 0. 599 ms: This parameter identifies the OSCORE Master Secret value, which 600 is a byte string. For more information about this field, see 601 section 3.1 of [RFC8613]. In JSON, the "ms" value is a Base64 602 encoded byte string. In CBOR, the "ms" type is bstr, and has 603 label 1. 605 id: This parameter identifies the OSCORE_Input_Material and is 606 encoded as a byte string. In JSON, the "id" value is a Base64 607 encoded byte string. In CBOR, the "id" type is byte string, and 608 has label 8. 610 hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more 611 information about this field, see section 3.1 of [RFC8613]. The 612 values used MUST be registered in the IANA "COSE Algorithms" 613 registry (see [COSE.Algorithms]) and MUST be HMAC-based HKDF 614 algorithms. The value can either be the integer or the text 615 string value of the HMAC-based HKDF algorithm in the "COSE 616 Algorithms" registry. In JSON, the "hkdf" value is a case- 617 sensitive ASCII string or an integer. In CBOR, the "hkdf" type is 618 tstr or int, and has label 4. 620 alg: This parameter identifies the OSCORE AEAD Algorithm. For more 621 information about this field, see section 3.1 of [RFC8613] The 622 values used MUST be registered in the IANA "COSE Algorithms" 623 registry (see [COSE.Algorithms]) and MUST be AEAD algorithms. The 624 value can either be the integer or the text string value of the 625 HMAC-based HKDF algorithm in the "COSE Algorithms" registry. In 626 JSON, the "alg" value is a case-sensitive ASCII string or an 627 integer. In CBOR, the "alg" type is tstr or int, and has label 5. 629 salt: This parameter identifies an input to the OSCORE Master Salt 630 value, which is a byte string. For more information about this 631 field, see section 3.1 of [RFC8613]. In JSON, the "salt" value is 632 a Base64 encoded byte string. In CBOR, the "salt" type is bstr, 633 and has label 6. 635 contextId: This parameter identifies the security context as a byte 636 string. This identifier is used as OSCORE ID Context. For more 637 information about this field, see section 3.1 of [RFC8613]. In 638 JSON, the "contextID" value is a Base64 encoded byte string. In 639 CBOR, the "contextID" type is bstr, and has label 7. 641 An example of JSON OSCORE_Input_Material is given in Figure 9. 643 "osc" : { 644 "alg" : "AES-CCM-16-64-128", 645 "id" : b64'AQ==' 646 "ms" : b64'+a+Dg2jjU+eIiOFCa9lObw' 647 } 649 Figure 9: Example JSON OSCORE_Input_Material 651 The CDDL grammar describing the CBOR OSCORE_Input_Material is: 653 OSCORE_Input_Material = { 654 ? 0 => int, ; version 655 ? 1 => bstr, ; ms 656 ? 2 => bstr, ; id 657 ? 3 => tstr / int, ; hkdf 658 ? 4 => tstr / int, ; alg 659 ? 5 => bstr, ; salt 660 ? 6 => bstr, ; contextId 661 * int / tstr => any 662 } 664 4. Client-RS Communication 666 The following subsections describe the details of the POST request 667 and response to the authz-info endpoint between client and RS. The 668 client generates a nonce N1 and an identifier ID1 unique in the sets 669 of its own Recipient IDs, and posts them together with the token that 670 includes the materials (e.g., OSCORE parameters) received from the AS 671 to the RS. The RS then generates a nonce N2 and an identifier ID2 672 unique in the sets of its own Recipient IDs, and uses Section 3.2 of 673 [RFC8613] to derive a security context based on a shared master 674 secret, the two nonces and the two identifiers, established between 675 client and server. The nonces and identifiers are encoded as CBOR 676 byte string if CBOR is used, and as Base64 string if JSON is used. 677 This security context is used to protect all future communication 678 between client and RS using OSCORE, as long as the access token is 679 valid. 681 Note that the RS and client authenticates themselves by generating 682 the shared OSCORE Security Context using the pop-key as master 683 secret. An attacker posting a valid token to the RS will not be able 684 to generate a valid OSCORE context and thus not be able to prove 685 possession of the pop-key. Additionally, the mutual authentication 686 is only achieved after the client has successfully verified the 687 response from the RS. 689 4.1. C-to-RS: POST to authz-info endpoint 691 The client MUST generate a nonce value very unlikely to have been 692 previously used with the same input keying material. This profile 693 RECOMMENDS to use a 64-bit long random number as nonce's value. The 694 client MUST store the nonce N1 as long as the response from the RS is 695 not received and the access token related to it is still valid. 697 The client generates its own Recipient ID, ID1, for the OSCORE 698 Security Context that it is establishing with the RS. By generating 699 its own Recipient ID, the client makes sure that it does not collide 700 with any of its Recipient IDs. 702 The client MUST use CoAP and the Authorization Information resource 703 as described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to 704 transport the token, N1 and ID1 to the RS. 706 Note that the use of the payload and the Content-Format is different 707 from what is described in section 5.8.1 of 708 [I-D.ietf-ace-oauth-authz], which only transports the token without 709 any CBOR wrapping. In this profile, the client MUST wrap the token 710 and N1 in a CBOR map. The client MUST use the Content-Format 711 "application/ace+cbor" defined in section 8.14 of 712 [I-D.ietf-ace-oauth-authz]. The client MUST include the access token 713 using the "access_token" parameter, N1 using the 'nonce1' parameter 714 defined in Section 4.1.1, and ID1 using the 'ace_client_recipientid' 715 parameter defined in Section 4.1.2. 717 The communication with the authz-info endpoint does not have to be 718 protected, except for the update of access rights case described 719 below. 721 Note that a client may be required to re-POST the access token in 722 order to complete a request, since an RS may delete a stored access 723 token (and associated Security Context) at any time, for example due 724 to all storage space being consumed. This situation is detected by 725 the client when it receives an AS Request Creation Hints response. 726 Reposting the same access token will result in deriving a new OSCORE 727 Security Context to be used with the RS, as different nonces will be 728 used. 730 Figure 10 shows an example of the request sent from the client to the 731 RS, with payload in CBOR diagnostic notation without the tag and 732 value abbreviations. The access token has been truncated for 733 readability. 735 Header: POST (Code=0.02) 736 Uri-Host: "rs.example.com" 737 Uri-Path: "authz-info" 738 Content-Format: "application/ace+cbor" 739 Payload: 740 { 741 "access_token": h'8343a1010aa2044c53 ... 742 (remainder of access token (CWT) omitted for brevity)', 743 "nonce1": h'018a278f7faab55a', 744 "ace_client_recipientid" : h'1645' 745 } 747 Figure 10: Example C-to-RS POST /authz-info request using CWT 749 If the client has already posted a valid token, has already 750 established a security association with the RS, and wants to update 751 its access rights, the client can do so by posting the new token 752 (retrieved from the AS and containing the update of access rights) to 753 the /authz-info endpoint. The client MUST protect the request using 754 the OSCORE Security Context established during the first token 755 exchange. The client MUST only send the access token in the payload, 756 no nonce or identifier are sent. After proper verification (see 757 Section 4.2), the RS will replace the old token with the new one, 758 maintaining the same Security Context. 760 4.1.1. The Nonce 1 Parameter 762 This parameter MUST be sent from the client to the RS, together with 763 the access token, if the ace profile used is coap_oscore. The 764 parameter is encoded as a byte string for CBOR-based interactions, 765 and as a string (Base64 encoded binary) for JSON-based interactions. 766 This parameter is registered in Section 9.2. 768 4.1.2. The ace_client_recipientid Parameter 770 This parameter MUST be sent from the client to the RS, together with 771 the access token, if the ace profile used is coap_oscore. The 772 parameter is encoded as a byte string for CBOR-based interactions, 773 and as a string (Base64 encoded binary) for JSON-based interactions. 774 This parameter is registered in Section 9.2. 776 4.2. RS-to-C: 2.01 (Created) 778 The RS MUST follow the procedures defined in section 5.8.1 of 779 [I-D.ietf-ace-oauth-authz]: the RS must verify the validity of the 780 token. If the token is valid, the RS must respond to the POST 781 request with 2.01 (Created). If the token is valid but is associated 782 to claims that the RS cannot process (e.g., an unknown scope), or if 783 any of the expected parameters is missing (e.g., any of the mandatory 784 parameters from the AS or the identifier), or if any parameters 785 received in the 'osc' is unrecognized, the RS must respond with an 786 error response code equivalent to the CoAP code 4.00 (Bad Request). 787 In the latter two cases, the RS may provide additional information in 788 the error response, in order to clarify what went wrong. The RS may 789 make an introspection request (see Section 5.7.1 of 790 [I-D.ietf-ace-oauth-authz]) to validate the token before responding 791 to the POST request to the authz-info endpoint. 793 Additionally, the RS MUST generate a nonce N2 very unlikely to have 794 been previously used with the same input keying material, and its own 795 Recipient ID, ID2. The RS makes sure that ID2 does not collide with 796 any of its Recipient IDs. The RS MUST ensure that ID2 is different 797 from the ace_client_recipientid. The RS sends N2 and ID2 within the 798 2.01 (Created) response. The payload of the 2.01 (Created) response 799 MUST be a CBOR map containing the 'nonce2' parameter defined in 800 Section 4.2.1, set to N2, and the 'ace_server_recipientid' parameter 801 defined in Section 4.2.2, set to ID2. This profile RECOMMENDS to use 802 a 64-bit long random number as nonce's value. The RS MUST use the 803 Content-Format "application/ace+cbor" defined in section 8.14 of 804 [I-D.ietf-ace-oauth-authz]. 806 Figure 11 shows an example of the response sent from the RS to the 807 client, with payload in CBOR diagnostic notation without the tag and 808 value abbreviations. 810 Header: Created (Code=2.01) 811 Content-Format: "application/ace+cbor" 812 Payload: 813 { 814 "nonce2": h'25a8991cd700ac01', 815 "ace_server_recipientid" : h'0000' 816 } 818 Figure 11: Example RS-to-C 2.01 (Created) response 820 As specified in section 5.8.3 of [I-D.ietf-ace-oauth-authz], the RS 821 must notify the client with an error response with code 4.01 822 (Unauthorized) for any long running request before terminating the 823 session, when the access token expires. 825 If the RS receives the token in a OSCORE protected message, it means 826 that the client is requesting an update of access rights. The RS 827 MUST discard any nonce and identifiers in the request, if any was 828 sent. The RS MUST check that the "kid" of the "cnf" parameter of the 829 new access token matches the OSCORE Input Material of the context 830 used to protect the message. If that is the case, the RS MUST 831 discard the old token and associate the new token to the Security 832 Context identified by the "kid" value in the "cnf" parameter. The RS 833 MUST respond with a 2.01 (Created) response protected with the same 834 Security Context, with no payload. If any verification fails, the RS 835 MUST respond with a 4.01 (Unauthorized) error response. 837 As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when 838 receiving an updated access token with updated authorization 839 information from the client (see Section 3.1), it is recommended that 840 the RS overwrites the previous token, that is only the latest 841 authorization information in the token received by the RS is valid. 842 This simplifies the process needed by the RS to keep track of 843 authorization information for a given client. 845 4.2.1. The Nonce 2 Parameter 847 This parameter MUST be sent from the RS to the client if the ace 848 profile used is coap_oscore. The parameter is encoded as a byte 849 string for CBOR-based interactions, and as a string (Base64 encoded 850 binary) for JSON-based interactions. This parameter is registered in 851 Section 9.2 853 4.2.2. The ace_server_recipientid Parameter 855 This parameter MUST be sent from the RS to the client if the ace 856 profile used is coap_oscore. The parameter is encoded as a byte 857 string for CBOR-based interactions, and as a string (Base64 encoded 858 binary) for JSON-based interactions. This parameter is registered in 859 Section 9.2 861 4.3. OSCORE Setup 863 Once receiving the 2.01 (Created) response from the RS, following the 864 POST request to authz-info endpoint, the client MUST extract the bstr 865 nonce N2 from the 'nonce2' parameter in the CBOR map in the payload 866 of the response. Then, the client MUST set the Master Salt of the 867 Security Context created to communicate with the RS to the 868 concatenation of salt, N1, and N2, in this order: Master Salt = 869 salt | N1 | N2, where | denotes byte string concatenation, where salt 870 is the CBOR byte string received from the AS in Section 3.2, and 871 where N1 and N2 are the two nonces encoded as CBOR byte strings. An 872 example of Master Salt construction using CBOR encoding is given in 873 Figure 12. 875 N1, N2 and input salt expressed in CBOR diagnostic notation: 876 nonce1 = h'018a278f7faab55a' 877 nonce2 = h'25a8991cd700ac01' 878 input salt = h'f9af838368e353e78888e1426bd94e6f' 880 N1, N2 and input salt as CBOR encoded byte strings: 881 nonce1 = 0x48018a278f7faab55a 882 nonce2 = 0x4825a8991cd700ac01 883 input salt = 0x50f9af838368e353e78888e1426bd94e6f 885 Master Salt = 0x50 f9af838368e353e78888e1426bd94e6f 48 018a278f7faab55a 48 25a8991cd700ac01 887 Figure 12: Example of Master Salt construction using CBOR encoding 889 If JSON is used instead of CBOR, the Master Salt of the Security 890 Context is the Base64 encoding of the concatenation of the same 891 parameters, each of them prefixed by their size, encoded in 1 byte. 892 When using JSON, the nonces and input salt have a maximum size of 255 893 bytes. An example of Master Salt construction using Base64 encoding 894 is given in Figure 13. 896 N1, N2 and input salt values: 897 nonce1 = 0x018a278f7faab55a (8 bytes) 898 nonce2 = 0x25a8991cd700ac01 (8 bytes) 899 input salt = 0xf9af838368e353e78888e1426bd94e6f (16 bytes) 901 Input to Base64 encoding: 0x10 f9af838368e353e78888e1426bd94e6f 08 018a278f7faab55a 08 25a8991cd700ac01 903 Master Salt = b64'EPmvg4No41PniIjhQmvZTm8IAYonj3+qtVoIJaiZHNcArAE=' 905 Figure 13: Example of Master Salt construction using Base64 encoding 907 The client MUST set the Sender ID to the ace_server_recipientid 908 received in Section 4.2, and the Recipient ID to the 909 ace_client_recipientid sent in Section 4.1. The client MUST set the 910 Master Secret from the parameter received from the AS in Section 3.2. 911 The client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE 912 Version from the parameters received from the AS in Section 3.2, if 913 present. In case an optional parameter is omitted, the default value 914 SHALL be used as described in sections 3.2 and 5.4 of [RFC8613]. 915 After that, the client MUST derive the complete Security Context 916 following section 3.2.1 of [RFC8613]. From this point on, the client 917 MUST use this Security Context to communicate with the RS when 918 accessing the resources as specified by the authorization 919 information. 921 If any of the expected parameters is missing (e.g., any of the 922 mandatory parameters from the AS or the RS), or if 923 ace_client_recipientid equals ace_server_recipientid, then the client 924 MUST stop the exchange, and MUST NOT derive the Security Context. 925 The client MAY restart the exchange, to get the correct security 926 material. 928 The client then uses this Security Context to send requests to RS 929 using OSCORE. 931 After sending the 2.01 (Created) response, the RS MUST set the Master 932 Salt of the Security Context created to communicate with the client 933 to the concatenation of salt, N1, and N2, in the same way described 934 above. An example of Master Salt construction using CBOR encoding is 935 given in Figure 12 and using Base64 encoding is given in Figure 13. 936 The RS MUST set the Sender ID from the ace_client_recipientid 937 received in Section 4.1, and the Recipient ID from the 938 ace_server_recipientid sent in Section 4.2. The RS MUST set the 939 Master Secret from the parameter, received from the AS and forwarded 940 by the client in the access token in Section 4.1 after validation of 941 the token as specified in Section 4.2. The RS MUST set the AEAD 942 Algorithm, ID Context, HKDF, and OSCORE Version from the parameters 943 received from the AS and forwarded by the client in the access token 944 in Section 4.1 after validation of the token as specified in 945 Section 4.2, if present. In case an optional parameter is omitted, 946 the default value SHALL be used as described in sections 3.2 and 5.4 947 of [RFC8613]. After that, the RS MUST derive the complete Security 948 Context following section 3.2.1 of [RFC8613], and MUST associate this 949 Security Context with the authorization information from the access 950 token. 952 The RS then uses this Security Context to verify requests and send 953 responses to C using OSCORE. If OSCORE verification fails, error 954 responses are used, as specified in section 8 of [RFC8613]. 955 Additionally, if OSCORE verification succeeds, the verification of 956 access rights is performed as described in section Section 4.4. The 957 RS MUST NOT use the Security Context after the related token has 958 expired, and MUST respond with a unprotected 4.01 (Unauthorized) 959 error message to requests received that correspond to a Security 960 Context with an expired token. 962 Note that the ID Context can be assigned by the AS, communicated and 963 set in both the RS and client after the exchange specified in this 964 profile is executed. Subsequently, client and RS can update their ID 965 Context by running a mechanism such as the one defined in 966 Appendix B.2 of [RFC8613] if they both support it and are configured 967 to do so. In that case, the ID Context in the OSCORE Security 968 Context will not match the "contextId" parameter of the corresponding 969 OSCORE_Input_Material. Running Appendix B.2 results in the keying 970 material in the Security Contexts of client and RS being updated; 971 this same result can also be achieved by the client reposting the 972 access token as described in Section 4.1, but without updating the ID 973 Context. 975 4.4. Access rights verification 977 The RS MUST follow the procedures defined in section 5.8.2 of 978 [I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected 979 request from a client, then the RS processes it according to 980 [RFC8613]. If OSCORE verification succeeds, and the target resource 981 requires authorization, the RS retrieves the authorization 982 information using the access token associated to the Security 983 Context. The RS then must verify that the authorization information 984 covers the resource and the action requested. 986 5. Secure Communication with AS 988 As specified in the ACE framework (section 5.7 of 989 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) 990 and the AS communicates via the introspection or token endpoint. The 991 use of CoAP and OSCORE ([RFC8613]) for this communication is 992 RECOMMENDED in this profile, other protocols (such as HTTP and DTLS 993 or TLS) MAY be used instead. 995 If OSCORE is used, the requesting entity and the AS are expected to 996 have pre-established security contexts in place. How these security 997 contexts are established is out of scope for this profile. 998 Furthermore the requesting entity and the AS communicate through the 999 introspection endpoint as specified in section 5.7 of 1000 [I-D.ietf-ace-oauth-authz] and through the token endpoint as 1001 specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. 1003 6. Discarding the Security Context 1005 There are a number of scenarios where a client or RS needs to discard 1006 the OSCORE security context, and acquire a new one. 1008 The client MUST discard the current Security Context associated with 1009 an RS when: 1011 o the Sequence Number space ends. 1013 o the access token associated with the context expires. 1015 o the client receives a number of 4.01 Unauthorized responses to 1016 OSCORE requests using the same Security Context. The exact number 1017 needs to be specified by the application. 1019 o the client receives a new nonce in the 2.01 (Created) response 1020 (see Section 4.2) to a POST request to the authz-info endpoint, 1021 when re-posting a (non-expired) token associated to the existing 1022 context. 1024 The RS MUST discard the current Security Context associated with a 1025 client when: 1027 o the Sequence Number space ends. 1029 o the access token associated with the context expires. 1031 o the client has successfully replaced the current security context 1032 with a newer one by posting an access token to the unprotected 1033 /authz-info endpoint at the RS, e.g., by re-posting the same 1034 token, as specified in Section 4.1. 1036 Whenever one more access token is successfully posted to the RS, and 1037 a new Security Context is derived between the client and RS, messages 1038 in transit that were protected with the previous Security Context 1039 might not pass verification, as the old context is discarded. That 1040 means that messages sent shortly before the client posts one more 1041 access token to the RS might not successfully reach the destination. 1042 Analogously, implementations may want to cancel CoAP observations at 1043 the RS registered before the Security Context is replaced, or 1044 conversely they will need to implement a mechanism to ensure that 1045 those observation are to be protected with the newly derived Security 1046 Context. 1048 7. Security Considerations 1050 This document specifies a profile for the Authentication and 1051 Authorization for Constrained Environments (ACE) framework 1052 [I-D.ietf-ace-oauth-authz]. Thus the general security considerations 1053 from the framework also apply to this profile. 1055 Furthermore the general security considerations of OSCORE [RFC8613] 1056 also apply to this specific use of the OSCORE protocol. 1058 As previously stated, the proof-of-possession in this profile is 1059 performed by both parties verifying that they have established the 1060 same Security Context, as specified in Section 4.3, which means that 1061 both the OSCORE request and OSCORE response pass verification. RS 1062 authentication requires both that the client trusts the AS and that 1063 the OSCORE response from the RS pass verification. 1065 OSCORE is designed to secure point-to-point communication, providing 1066 a secure binding between the request and the response(s). Thus the 1067 basic OSCORE protocol is not intended for use in point-to-multipoint 1068 communication (e.g., multicast, publish-subscribe). Implementers of 1069 this profile should make sure that their usecase corresponds to the 1070 expected use of OSCORE, to prevent weakening the security assurances 1071 provided by OSCORE. 1073 Since the use of nonces in the exchange guarantees uniqueness of AEAD 1074 keys and nonces, it is REQUIRED that nonces are not reused with the 1075 same input keying material even in case of re-boots. This document 1076 RECOMMENDS the use of 64 bit random nonces. Considering the birthday 1077 paradox, the average collision for each nonce will happen after 2^32 1078 messages, which is considerably more token provisionings than 1079 expected for intended applications. If applications use something 1080 else, such as a counter, they need to guarantee that reboot and loss 1081 of state on either node does not provoke re-use. If that is not 1082 guaranteed, nodes are susceptible to re-use of AEAD (nonces, keys) 1083 pairs, especially since an on-path attacker can cause the client to 1084 use an arbitrary nonce for Security Context establishment by 1085 replaying client-to-server messages. 1087 This profile recommends that the RS maintains a single access token 1088 for a client. The use of multiple access tokens for a single client 1089 increases the strain on the resource server as it must consider every 1090 access token and calculate the actual permissions of the client. 1091 Also, tokens indicating different or disjoint permissions from each 1092 other may lead the server to enforce wrong permissions. If one of 1093 the access tokens expires earlier than others, the resulting 1094 permissions may offer insufficient protection. Developers should 1095 avoid using multiple access tokens for a client. 1097 If a single OSCORE_Input_Material is used with multiple RSs, the RSs 1098 can impersonate C to one of the other RS, and impersonate another RS 1099 to the client. If a master secret is used with several clients, the 1100 Cs can impersonate RS to one of the other C. Similarly if symmetric 1101 keys are used to integrity protect the token between AS and RS and 1102 the token can be used with multiple RSs, the RSs can impersonate AS 1103 to one of the other RS. If the token key is used for any other 1104 communication between the RSs and AS, the RSs can impersonate each 1105 other to the AS. 1107 8. Privacy Considerations 1109 This document specifies a profile for the Authentication and 1110 Authorization for Constrained Environments (ACE) framework 1111 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 1112 from the framework also apply to this profile. 1114 As this document uses OSCORE, thus the privacy considerations from 1115 [RFC8613] apply here as well. 1117 An unprotected response to an unauthorized request may disclose 1118 information about the resource server and/or its existing 1119 relationship with the client. It is advisable to include as little 1120 information as possible in an unencrypted response. When an OSCORE 1121 Security Context already exists between the client and the resource 1122 server, more detailed information may be included. 1124 The token is sent in the clear to the authz-info endpoint, so if a 1125 client uses the same single token from multiple locations with 1126 multiple Resource Servers, it can risk being tracked by the token's 1127 value even when the access token is encrypted. 1129 The nonces exchanged in the request and response to the authz-info 1130 endpoint are also sent in the clear, so using random nonces is best 1131 for privacy (as opposed to, e.g., a counter, that might leak some 1132 information about the client). 1134 The identifiers used in OSCORE, negotiated between client and RS are 1135 privacy sensitive (see Section 12.8 of [RFC8613]), and could reveal 1136 information about the client, or may be used for correlating requests 1137 from one client. 1139 Note that some information might still leak after OSCORE is 1140 established, due to observable message sizes, the source, and the 1141 destination addresses. 1143 9. IANA Considerations 1145 Note to RFC Editor: Please replace all occurrences of "[[this 1146 specification]]" with the RFC number of this specification and delete 1147 this paragraph. 1149 9.1. ACE Profile Registry 1151 The following registration is done for the ACE Profile Registry 1152 following the procedure specified in section 8.8 of 1153 [I-D.ietf-ace-oauth-authz]: 1155 o Name: coap_oscore 1156 o Description: Profile for using OSCORE to secure communication 1157 between constrained nodes using the Authentication and 1158 Authorization for Constrained Environments framework. 1159 o CBOR Value: TBD (value between 1 and 255) 1160 o Reference: [[this specification]] 1162 9.2. OAuth Parameters Registry 1164 The following registrations are done for the OAuth Parameters 1165 Registry following the procedure specified in section 11.2 of 1166 [RFC6749]: 1168 o Parameter name: nonce1 1169 o Parameter usage location: client-rs request 1170 o Change Controller: IESG 1171 o Specification Document(s): [[this specification]] 1173 o Parameter name: nonce2 1174 o Parameter usage location: rs-client response 1175 o Change Controller: IESG 1176 o Specification Document(s): [[this specification]] 1178 o Parameter name: ace_client_recipientid 1179 o Parameter usage location: client-rs request 1180 o Change Controller: IESG 1181 o Specification Document(s): [[this specification]] 1183 o Parameter name: ace_server_recipientid 1184 o Parameter usage location: rs-client response 1185 o Change Controller: IESG 1186 o Specification Document(s): [[this specification]] 1188 9.3. OAuth Parameters CBOR Mappings Registry 1190 The following registrations are done for the OAuth Parameters CBOR 1191 Mappings Registry following the procedure specified in section 8.10 1192 of [I-D.ietf-ace-oauth-authz]: 1194 o Name: nonce1 1195 o CBOR Key: TBD1 1196 o Value Type: bstr 1197 o Reference: [[this specification]] 1199 o Name: nonce2 1200 o CBOR Key: TBD2 1201 o Value Type: bstr 1202 o Reference: [[this specification]] 1203 o Name: ace_client_recipientid 1204 o CBOR Key: TBD3 1205 o Value Type: bstr 1206 o Reference: [[this specification]] 1208 o Name: ace_server_recipientid 1209 o CBOR Key: TBD4 1210 o Value Type: bstr 1211 o Reference: [[this specification]] 1213 9.4. OSCORE Security Context Parameters Registry 1215 It is requested that IANA create a new registry entitled "OSCORE 1216 Security Context Parameters" registry. The registry is to be created 1217 as Expert Review Required. Guidelines for the experts is provided 1218 Section 9.7. It should be noted that in addition to the expert 1219 review, some portions of the registry require a specification, 1220 potentially on standards track, be supplied as well. 1222 The columns of the registry are: 1224 name The JSON name requested (e.g., "ms"). Because a core goal of 1225 this specification is for the resulting representations to be 1226 compact, it is RECOMMENDED that the name be short. This name is 1227 case sensitive. Names may not match other registered names in a 1228 case-insensitive manner unless the Designated Experts determine 1229 that there is a compelling reason to allow an exception. The name 1230 is not used in the CBOR encoding. 1231 CBOR label The value to be used to identify this algorithm. Map key 1232 labels MUST be unique. The label can be a positive integer, a 1233 negative integer or a string. Integer values between -256 and 255 1234 and strings of length 1 are designated as Standards Track Document 1235 required. Integer values from -65536 to -257 and from 256 to 1236 65535 and strings of length 2 are designated as Specification 1237 Required. Integer values greater than 65535 and strings of length 1238 greater than 2 are designated as expert review. Integer values 1239 less than -65536 are marked as private use. 1240 CBOR Type This field contains the CBOR type for the field. 1241 registry This field denotes the registry that values may come from, 1242 if one exists. 1243 description This field contains a brief description for the field. 1244 specification This contains a pointer to the public specification 1245 for the field if one exists 1247 This registry will be initially populated by the values in Table 1. 1248 The specification column for all of these entries will be this 1249 document and [RFC8613]. 1251 9.5. CWT Confirmation Methods Registry 1253 The following registration is done for the CWT Confirmation Methods 1254 Registry following the procedure specified in section 7.2.1 of 1255 [RFC8747]: 1257 o Confirmation Method Name: "osc" 1258 o Confirmation Method Description: OSCORE_Input_Material carrying 1259 the parameters for using OSCORE per-message security with implicit 1260 key confirmation 1261 o Confirmation Key: TBD (value between 4 and 255) 1262 o Confirmation Value Type(s): map 1263 o Change Controller: IESG 1264 o Specification Document(s): Section 3.2.1 of [[this specification]] 1266 9.6. JWT Confirmation Methods Registry 1268 The following registration is done for the JWT Confirmation Methods 1269 Registry following the procedure specified in section 6.2.1 of 1270 [RFC7800]: 1272 o Confirmation Method Value: "osc" 1273 o Confirmation Method Description: OSCORE_Input_Material carrying 1274 the parameters for using OSCORE per-message security with implicit 1275 key confirmation 1276 o Change Controller: IESG 1277 o Specification Document(s): Section 3.2.1 of [[this specification]] 1279 9.7. Expert Review Instructions 1281 The IANA registry established in this document is defined to use the 1282 Expert Review registration policy. This section gives some general 1283 guidelines for what the experts should be looking for, but they are 1284 being designated as experts for a reason so they should be given 1285 substantial latitude. 1287 Expert reviewers should take into consideration the following points: 1289 o Point squatting should be discouraged. Reviewers are encouraged 1290 to get sufficient information for registration requests to ensure 1291 that the usage is not going to duplicate one that is already 1292 registered and that the point is likely to be used in deployments. 1293 The zones tagged as private use are intended for testing purposes 1294 and closed environments. Code points in other ranges should not 1295 be assigned for testing. 1296 o Specifications are required for the standards track range of point 1297 assignment. Specifications should exist for specification 1298 required ranges, but early assignment before a specification is 1299 available is considered to be permissible. Specifications are 1300 needed for the first-come, first-serve range if they are expected 1301 to be used outside of closed environments in an interoperable way. 1302 When specifications are not provided, the description provided 1303 needs to have sufficient information to identify what the point is 1304 being used for. 1305 o Experts should take into account the expected usage of fields when 1306 approving point assignment. The fact that there is a range for 1307 standards track documents does not mean that a standards track 1308 document cannot have points assigned outside of that range. The 1309 length of the encoded value should be weighed against how many 1310 code points of that length are left, the size of device it will be 1311 used on, and the number of code points left that encode to that 1312 size. 1314 10. References 1316 10.1. Normative References 1318 [COSE.Algorithms] 1319 IANA, "COSE Algorithms", 1320 . 1323 [I-D.ietf-ace-oauth-authz] 1324 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1325 H. Tschofenig, "Authentication and Authorization for 1326 Constrained Environments (ACE) using the OAuth 2.0 1327 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1328 (work in progress), June 2020. 1330 [I-D.ietf-ace-oauth-params] 1331 Seitz, L., "Additional OAuth Parameters for Authorization 1332 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1333 params-13 (work in progress), April 2020. 1335 [I-D.ietf-cbor-7049bis] 1336 Bormann, C. and P. Hoffman, "Concise Binary Object 1337 Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work 1338 in progress), September 2020. 1340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1341 Requirement Levels", BCP 14, RFC 2119, 1342 DOI 10.17487/RFC2119, March 1997, 1343 . 1345 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1346 Application Protocol (CoAP)", RFC 7252, 1347 DOI 10.17487/RFC7252, June 2014, 1348 . 1350 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1351 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1352 . 1354 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1355 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1356 May 2017, . 1358 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1359 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1360 May 2018, . 1362 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1363 Definition Language (CDDL): A Notational Convention to 1364 Express Concise Binary Object Representation (CBOR) and 1365 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1366 June 2019, . 1368 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1369 "Object Security for Constrained RESTful Environments 1370 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1371 . 1373 10.2. Informative References 1375 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1376 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1377 . 1379 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1380 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1381 . 1383 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1384 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1385 DOI 10.17487/RFC7231, June 2014, 1386 . 1388 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1389 Possession Key Semantics for JSON Web Tokens (JWTs)", 1390 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1391 . 1393 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1394 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1395 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1396 2020, . 1398 Appendix A. Profile Requirements 1400 This section lists the specifications on this profile based on the 1401 requirements on the framework, as requested in Appendix C of 1402 [I-D.ietf-ace-oauth-authz]. 1404 o Optionally define new methods for the client to discover the 1405 necessary permissions and AS for accessing a resource, different 1406 from the one proposed in: Not specified 1407 o Optionally specify new grant types: Not specified 1408 o Optionally define the use of client certificates as client 1409 credential type: Not specified 1410 o Specify the communication protocol the client and RS the must use: 1411 CoAP 1412 o Specify the security protocol the client and RS must use to 1413 protect their communication: OSCORE 1414 o Specify how the client and the RS mutually authenticate: 1415 Implicitly by possession of a common OSCORE security context. 1416 Note that the mutual authentication is not completed before the 1417 client has verified an OSCORE response using this security 1418 context. 1419 o Specify the proof-of-possession protocol(s) and how to select one, 1420 if several are available. Also specify which key types (e.g., 1421 symmetric/asymmetric) are supported by a specific proof-of- 1422 possession protocol: OSCORE algorithms; pre-established symmetric 1423 keys 1424 o Specify a unique ace_profile identifier: coap_oscore 1425 o If introspection is supported: Specify the communication and 1426 security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE) 1427 o Specify the communication and security protocol for interactions 1428 between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE) 1429 o Specify how/if the authz-info endpoint is protected, including how 1430 error responses are protected: Not protected. 1431 o Optionally define other methods of token transport than the authz- 1432 info endpoint: Not defined 1434 Acknowledgments 1436 The authors wish to thank Jim Schaad and Marco Tiloca for the input 1437 on this memo. Special thanks to the responsible area director 1438 Benjamin Kaduk for his extensive review and contributed text. Ludwig 1439 Seitz worked on this document as part of the CelticNext projects 1440 CyberWI, and CRITISEC with funding from Vinnova. 1442 Authors' Addresses 1444 Francesca Palombini 1445 Ericsson AB 1447 Email: francesca.palombini@ericsson.com 1449 Ludwig Seitz 1450 Combitech 1451 Djaeknegatan 31 1452 Malmoe 211 35 1453 Sweden 1455 Email: ludwig.seitz@combitech.se 1457 Goeran Selander 1458 Ericsson AB 1460 Email: goran.selander@ericsson.com 1462 Martin Gunnarsson 1463 RISE 1464 Scheelevagen 17 1465 Lund 22370 1466 Sweden 1468 Email: martin.gunnarsson@ri.se