idnits 2.17.1 draft-palombini-ace-oscore-profile-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2020) is 1306 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 (-19) exists of draft-ietf-ace-oscore-profile-11 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 September 21, 2020 5 Expires: March 25, 2021 7 OSCORE Profile of ACE v2 8 draft-palombini-ace-oscore-profile-v2-00 10 Abstract 12 This document specifies a profile for the Authentication and 13 Authorization for Constrained Environments (ACE) framework. It 14 utilizes Object Security for Constrained RESTful Environments 15 (OSCORE) to provide communication security and proof-of-possession 16 for a key owned by the client and bound to an OAuth 2.0 access token. 17 Additionally, this profile provides OSCORE identifiers negotiation 18 between Client and Resource Server. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 25, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 5 59 3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 5 60 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 6 61 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 10 62 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 10 63 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 11 64 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 12 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 7.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 13 69 7.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 13 70 7.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 13 71 7.4. OSCORE Security Context Parameters Registry . . . . . . . 14 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 9.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 An OSCORE profile of ACE is defined in [I-D.ietf-ace-oscore-profile]. 81 That profiles describes how to set up OSCORE between nodes, while the 82 OSCORE Sender and Recipient Identifiers, i.e. the identifiers of the 83 OSCORE keying material, are assigned by the Authorization Server. 84 This has some limitations, especially if the OSCORE profile is used 85 in conjuction with other mechamisms that also derive identifiers, in 86 which case there needs to be a mechanism in place to avoid 87 collisions. 89 This document describes a new OSCORE profile that builds on 90 [I-D.ietf-ace-oscore-profile], and adds a mechanism for negotiating 91 identifiers between Client and Resource Server. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 Readers are expected to be familiar with the terms and concepts 102 described in [I-D.ietf-ace-oauth-authz] 103 [I-D.ietf-ace-oscore-profile], such as Authorization Server (AS) and 104 Resource Server (RS). 106 Readers are expected to be familiar with the terms and concepts 107 described in [RFC8613], especially on the use of Sender, Recipient 108 and Context Identifiers. 110 1.2. Background 112 TODO: introduce OSCORE Sender and Recipient Identifiers and how they 113 are used in OSCORE. 115 The OSCORE profile defined in [I-D.ietf-ace-oscore-profile] specifies 116 that the AS assigns and sends the OSCORE Sender and Recipient 117 Identifiers to both Client and RS, together with the rest of the 118 input material to derive the complete OSCORE Security Context. That 119 is done by including these identifiers in the Access Token and Access 120 Information response to the Client. The access token containing 121 these identifiers is also forwarded to the RS by the Client. 123 This works with a number of requirements: the OSCORE profile states 124 that if other authentication mechanisms are used to set up OSCORE 125 between the same client and RS, that do not rely on an AS assigning 126 identifiers, collisions may happen and need to be mitigated. Such 127 mitigation mechanisms also need to be used if a different AS (which 128 does not synchronize identifiers with the first AS) or authentication 129 protocol is used to set up OSCORE between the same RS and other 130 clients. A mitigation example would be to use distinct namespaces of 131 context identifiers for different authentication mechanisms or 132 authentication servers. Another solution would be to use longer 133 random identifiers. A third possible solution, acceptable if 134 collisions are not expected to be numerous, would be to rely on trial 135 and error of security contexts when receiving a message. 137 These solutions have the drawback of requiring either some sort of 138 agreement between different authentication mechanisms using disjoint 139 namespaces for the identifiers, and/or longer identifiers to be used, 140 which leads to larger message sizes, or additional processing on the 141 RS. 143 This document specifies an OSCORE profile that adds a mechanism to 144 assign identifiers on top of the current OSCORE profile, and that 145 allows to set up identifiers without collisions, even when other 146 authentication mechanisms or non-syncrhonized AS are used. What 147 specified in [I-D.ietf-ace-oscore-profile] applies to this profile as 148 well, with the modifications reported in the following sections. 149 Although defining a separate profile, the reader is advised that the 150 [I-D.ietf-ace-oscore-profile] needs to be read side by side with this 151 specification, to understand it. 153 2. Protocol Overview 155 This section defines the additions to Section 2 of 156 [I-D.ietf-ace-oscore-profile]. 158 Once the client has retrieved the access token, and generated the 159 nonce N1, the Client also generates a Recipient Identifier ID1 for 160 use with the keying material associated to the RS. The client posts 161 the token, N1 and its Recipient ID to the RS using the authz-info 162 endpoint and mechanisms specified in section 5.8 of 163 [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor. 165 If the access token is valid, the RS replies to this request with a 166 2.01 (Created) response with Content-Format = application/ace+cbor, 167 which contains a nonce N2 and a newly generated Recipient Identifier 168 ID2 for use with the keying material associated to the Client in a 169 CBOR map. Moreover, the server concatenates the input salt, N1, and 170 N2 to obtain the Master Salt of the OSCORE Security Context (see 171 section 3 of [RFC8613]). The RS then derives the complete Security 172 Context associated with the received token from the Master Salt, the 173 Recipient ID generated by the Client (set as its OSCORE Sender Id), 174 the Recipient ID generated by itself (set as its OSCORE Recipient 175 Id), plus the parameters received in the access token from the AS, 176 following section 3.2 of [RFC8613]. 178 In a similar way, after receiving the nonce N2, the client 179 concatenates the input salt, N1 and N2 to obtain the Master Salt of 180 the OSCORE Security Context. The client then derives the complete 181 Security Context from the Master Salt, the Recipient ID generated by 182 the RS (set as its OSCORE Sender Id), the Recipient ID generated by 183 itself (set as its OSCORE Recipient Id), plus the parameters received 184 from the AS. 186 After the whole message exchange has taken place, the client can 187 contact the AS to request an update of its access rights, sending a 188 similar request to the token endpoint that also includes an 189 identifier so that the AS can find the correct OSCORE security 190 material it has previously shared with the Client. This specific 191 identifier, encoded as a byte string, is set by the AS to be unique 192 in the sets of its OSCORE Security Contexts, and is not used as input 193 material to derive the full OSCORE Security Context. 195 C RS AS 196 | | | 197 | ----- POST /token ----------------------------> | 198 | | | 199 | <---------------------------- Access Token ----- | 200 | + Access Information | 201 | ---- POST /authz-info ---> | | 202 | (access_token, N1, Id1) | | 203 | | | 204 | <- 2.01 Created (N2, Id2)- | | 205 | | | 206 /Sec Context /Sec Context | 207 Derivation/ Derivation/ | 208 | | | 209 | ---- OSCORE Request -----> | | 210 | | | 211 | /proof-of-possession | 212 | Sec Context storage/ | 213 | | | 214 | <--- OSCORE Response ----- | | 215 | | | 216 /proof-of-possession | | 217 Sec Context storage/ | | 218 | | | 219 | ---- OSCORE Request -----> | | 220 | ... | | 222 Figure 1: OSCORE Profile v2 Overview 224 3. Client-AS Communication 226 The following subsections apply modifications to what specified in 227 Section 3 of [I-D.ietf-ace-oscore-profile]. 229 3.1. C-to-AS: POST to token endpoint 231 If the client wants to update its access rights without changing an 232 existing OSCORE Security Context, it MUST include in its POST request 233 to the token endpoint a req_cnf object. The req_cnf MUST include a 234 kid field carrying a CBOR byte string containing the 235 OSCORE_Input_Material Identifier (assigned as discussed in 236 Section 3.2). 238 An example of an update of access rights request, with payload in 239 CBOR diagnostic notation without the tag and value abbreviations is 240 reported in Figure 2. 242 Header: POST (Code=0.02) 243 Uri-Host: "as.example.com" 244 Uri-Path: "token" 245 Content-Format: "application/ace+cbor" 246 Payload: 247 { 248 "req_aud" : "tempSensor4711", 249 "scope" : "write", 250 "req_cnf" : { 251 "kid" : h'01' 252 } 254 Figure 2: Example C-to-AS POST /token request for updating rights to 255 an access token bound to a symmetric key. 257 3.2. AS-to-C: Access Token 259 The AS can signal that the use of OSCORE is REQUIRED for a specific 260 access token by including the "profile" parameter with the value 261 "coap_oscore_2" in the access token response. 263 The AS MUST send the following data: 265 o a master secret 267 o an identifier of the OSCORE_Input_Material 269 The AS MUST NOT include clientId or serverId, in the 270 OSCORE_Input_Material, neither in the 'cnf' nor in the claims sets 271 associated with the access token. 273 The identifier of the OSCORE_Input_Material MUST be communicated as 274 the 'id' field in the 'osc' field in the 'cnf' parameter of the 275 access token response (and therefore included in the claims 276 associated with the access token). 278 We don't assume in this document that a resource is associated to one 279 single AS, since the AS is not tasked with enforcing uniqueness of 280 identifiers for each client requesting a particular resource to a RS. 281 This profile can also be used together with other authentication 282 mechanisms such as EDHOC, see [I-D.ietf-lake-edhoc]. 284 Figure 3 shows an example of an AS response, with payload in CBOR 285 diagnostic notation without the tag and value abbreviations. The 286 access token has been truncated for readability. 288 Header: Created (Code=2.01) 289 Content-Type: "application/ace+cbor" 290 Payload: 291 { 292 "access_token" : h'8343a1010aa2044c53 ... 293 (remainder of access token (CWT) omitted for brevity)', 294 "profile" : "coap_oscore_2", 295 "expires_in" : "3600", 296 "cnf" : { 297 "osc" : { 298 "ms" : h'f9af838368e353e78888e1426bd94e6f', 299 "id" : h'01' 300 } 301 } 302 } 304 Figure 3: Example AS-to-C Access Token response with OSCORE profile 305 2. 307 Figure 4 shows an example CWT Claims Set, including the relevant 308 OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation 309 without tag and value abbreviations. 311 { 312 "aud" : "tempSensorInLivingRoom", 313 "iat" : "1360189224", 314 "exp" : "1360289224", 315 "scope" : "temperature_g firmware_p", 316 "cnf" : { 317 "osc" : { 318 "ms" : h'f9af838368e353e78888e1426bd94e6f', 319 "id" : h'01' 320 } 321 } 322 } 324 Figure 4: Example CWT Claims Set with OSCORE parameters. 326 The same CWT Claims Set as in Figure 4, using the value abbreviations 327 defined in [I-D.ietf-ace-oauth-authz] and [RFC8747] and encoded in 328 CBOR is shown in Figure 5. The bytes in hexadecimal are reported in 329 the first column, while their corresponding CBOR meaning is reported 330 after the '#' sign on the second column, for easiness of readability. 332 A5 # map(5) 333 63 # text(3) 334 617564 # "aud" 335 76 # text(22) 336 74656D7053656E736F72496E4C6976696E67526F6F6D 337 # "tempSensorInLivingRoom" 338 63 # text(3) 339 696174 # "iat" 340 6A # text(10) 341 31333630313839323234 # "1360189224" 342 63 # text(3) 343 657870 # "exp" 344 6A # text(10) 345 31333630323839323234 # "1360289224" 346 65 # text(5) 347 73636F7065 # "scope" 348 78 18 # text(24) 349 74656D70657261747572655F67206669726D776172655F70 350 # "temperature_g firmware_p" 351 63 # text(3) 352 636E66 # "cnf" 353 A1 # map(1) 354 63 # text(3) 355 6F7363 # "osc" 356 A2 # map(2) 357 62 # text(2) 358 6D73 # "ms" 359 50 # bytes(16) 360 F9AF838368E353E78888E1426BD94E6F 361 # "\xF9\xAF\x83\x83h\xE3S\xE7 362 \x88\x88\xE1Bk\xD9No" 363 62 # text(2) 364 6964 # "id" 365 41 # bytes(1) 366 01 # "\x01" 368 Figure 5: Example CWT Claims Set with OSCORE parameters, CBOR encoded 370 If the client has requested an update to its access rights using the 371 same OSCORE_Input_Material, which is valid and authorized, the AS 372 MUST omit the 'cnf' parameter in the response, and MUST carry the 373 OSCORE_Input_Material Identifier in the 'kid' field in the 'cnf' 374 parameter of the token. This identifier needs to be included in the 375 token in order for the RS to identify the correct OSCORE Input 376 Material. 378 Figure 6 shows an example of such an AS response, with payload in 379 CBOR diagnostic notation without the tag and value abbreviations. 380 The access token has been truncated for readability. 382 Header: Created (Code=2.01) 383 Content-Type: "application/ace+cbor" 384 Payload: 385 { 386 "access_token" : h'8343a1010aa2044c53 ... 387 (remainder of access token (CWT) omitted for brevity)', 388 "profile" : "coap_oscore_2", 389 "expires_in" : "3600" 390 } 392 Figure 6: Example AS-to-C Access Token response with OSCORE profile, 393 for update of access rights. 395 Figure 7 shows an example CWT Claims Set, containing the necessary 396 OSCORE parameters in the 'cnf' claim for update of access rights, in 397 CBOR diagnostic notation without tag and value abbreviations. 399 { 400 "aud" : "tempSensorInLivingRoom", 401 "iat" : "1360189224", 402 "exp" : "1360289224", 403 "scope" : "temperature_h", 404 "cnf" : { 405 "kid" : h'01' 406 } 407 } 409 Figure 7 411 3.2.1. OSCORE_Input_Material Object 413 The following parameter is added to the OSCORE_Input_Material object 414 defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. 416 +------------+-------+-------------+------------+--------------+ 417 | name | CBOR | CBOR type | registry | description | 418 | | label | | | | 419 +------------+-------+-------------+------------+--------------+ 420 | identifier | 8 | byte string | | OSCORE Input | 421 | | | | | Material | 422 | | | | | Identifier | 423 +------------+-------+-------------+------------+--------------+ 425 Figure 8: OSCORE_Input_Material Additional Parameters 427 id: This parameter identifies the OSCORE_Input_Material and is 428 encoded as a byte string. In JSON, the "id" value is a Base64 429 encoded byte string. In CBOR, the "id" type is byte string, and 430 has label 8. 432 4. Client-RS Communication 434 Additionally to what specified in Section 4 of 435 [I-D.ietf-ace-oscore-profile], the client also generates an 436 identifier id1, unique in the sets of its own Recipient Ids, and 437 posts it together with the token and nonce N1 to the RS. The RS also 438 generates an identifier id2, unique in the sets of its own Recipient 439 Ids, and uses it together with the rest of the input material to 440 derive a security context. Both the nonces and identifiers are 441 encoded as CBOR bstr if CBOR is used, and as Base64 string if JSON is 442 used. 444 4.1. C-to-RS: POST to authz-info endpoint 446 Additionally to what specified in Section 4.1 of 447 [I-D.ietf-ace-oscore-profile], the following applies. 449 The client generates its own Recipient Id for the OSCORE Security 450 Context that it is establishing with the RS. By generating its own 451 Recipient Id, the client makes sure that it does not collide with any 452 of its Recipient Identifiers. The client posts it to the RS together 453 with what is described in Section 4.1 of 454 [I-D.ietf-ace-oscore-profile]: the client includes the Recipient Id 455 in the POST to authz-info request, as an ace_client_recipientid 456 parameter, registered in Section 7.2 and Section 7.3. 458 When receiving the POST to authz-info request including the 459 ace_client_recipientid parameter, the RS MUST set its own Sender 460 Identifier to the value of the ace_client_recipientid. If the 461 ace_client_recipientid parameter is not included in the request, the 462 RS MUST stop processing the request and interrupt the Ace exchange, 463 and MAY reply with a 4.00 (Bad Request) error message. 465 If the access token received contains either the clientId or serverId 466 parameters, the server SHOULD stop processing the message, and MAY 467 reply with a 4.00 (Bad Request) error message. 469 Figure 9 shows an example of the request sent from the client to the 470 RS, with payload in CBOR diagnostic notation without the tag and 471 value abbreviations. The access token has been truncated for 472 readability. 474 Header: POST (Code=0.02) 475 Uri-Host: "rs.example.com" 476 Uri-Path: "authz-info" 477 Content-Format: "application/ace+cbor" 478 Payload: 479 { 480 "access_token": h'8343a1010aa2044c53 ... 481 (remainder of access token (CWT) omitted for brevity)', 482 "nonce1": h'018a278f7faab55a', 483 "ace_client_recipientid" : h'11' 484 } 486 Figure 9 488 4.1.1. The ace_client_recipientid Parameter 490 This parameter MUST be sent from the client to the RS, together with 491 the access token and the nonce, if the ace profile used is 492 coap_oscore_2. The parameter is encoded as a byte string for CBOR- 493 based interactions, and as a string (Base64 encoded binary) for JSON- 494 based interactions. This parameter is registered in Section 7.2 and 495 Section 7.3. 497 4.2. RS-to-C: 2.01 (Created) 499 Additionally to what specified in Section 4.2 of 500 [I-D.ietf-ace-oscore-profile], the following applies. 502 The RS generates its own Recipient Id for the OSCORE Security Context 503 that it is establishing with the client. By generating its own 504 Recipient Id, the RS makes sure that it does not collide with any of 505 its Recipient Identifiers. The RS MUST ensure that id2 is different 506 from the ace_client_recipientid. The RS sends it to the Client 507 together with what is described in Section 4.2 of 508 [I-D.ietf-ace-oscore-profile]: the RS includes the Recipient Id in 509 the 2.01 (Created) response, as a ace_server_recipientid parameter, 510 as registered in Section 7.2 and Section 7.3. 512 When receiving the response including the ace_server_recipientid 513 parameter, the Client MUST set its own Sender Identifier to the value 514 of the ace_server_recipientid and discard any ClientId present in the 515 access token. If the ace_server_recipientid parameter is not 516 included in the response, the client MUST stop processing the 517 response and interrupt the Ace exchange. 519 Figure 10 shows an example of the response sent from the RS to the 520 client, with payload in CBOR diagnostic notation without the tag and 521 value abbreviations. 523 Header: Created (Code=2.01) 524 Content-Format: "application/ace+cbor" 525 Payload: 526 { 527 "nonce2": h'25a8991cd700ac01', 528 "ace_server_recipientid" : h'22' 529 } 531 Figure 10 533 4.2.1. The ace_server_recipientid Parameter 535 This parameter MUST be sent from the RS to the client, together with 536 the access token and nonce, if the ace profile used is coap_oscore_2. 537 The parameter is encoded as a byte string for CBOR-based 538 interactions, and as a string (Base64 encoded binary) for JSON-based 539 interactions. This parameter is registered in Section Section 7.2 540 and Section 7.3. 542 4.3. OSCORE Setup 544 Differently than what defined in Section 4.3 of 545 [I-D.ietf-ace-oscore-profile], the client and RS do not set the 546 Sender ID and Recipient ID from the parameters received from the AS 547 in Section 3.2. 549 Instead, the client MUST set the Sender ID from the 550 ace_server_recipientid received in Section 4.2, and the Recipient ID 551 from its own generated ace_client_recipientid. Conversely, the 552 server MUST set the Sender ID from the ace_client_recipientid 553 received in Section 4.1, and the Recipient ID from its own generated 554 ace_server_recipientid. 556 5. Security Considerations 558 TODO 560 TBD: How do this profile and the v1 OSCORE profile work together? can 561 the AS send a v1 profile + token and the c and RS try to run a v2? 562 how does c react if it tries to run v2 and get reverted to v1? How 563 do the 2 profiles work together? 565 6. Privacy Considerations 567 TODO 569 7. IANA Considerations 571 This document has the following actions for IANA. 573 7.1. ACE Profile Registry 575 The following registration is done for the ACE Profile Registry 576 following the procedure specified in section 8.8 of 577 [I-D.ietf-ace-oauth-authz]: 579 o Name: coap_oscore_2 581 o Description: Profile for using OSCORE to secure communication 582 between constrained nodes using the Authentication and 583 Authorization for Constrained Environments framework. 585 o CBOR Value: TBD (value between 1 and 255) 587 o Reference: [[This specification]] 589 7.2. OAuth Parameters Registry 591 The following registrations are done for the OAuth ParametersRegistry 592 following the procedure specified in section 11.2 of [RFC6749]: 594 o Parameter name: ace_client_recipientid 595 o Parameter usage location: client request 596 o Change Controller: IESG 597 o Specification Document(s): [[This specification]] 599 o Parameter name: ace_server_recipientid 600 o Parameter usage location: token response 601 o Change Controller: IESG 602 o Specification Document(s): [[This specification]] 604 7.3. OAuth Parameters CBOR Mappings Registry 606 The following registrations are done for the OAuth Parameters CBOR 607 Mappings Registry following the procedure specified in section 8.9 of 608 [I-D.ietf-ace-oauth-authz]: 610 * Name: ace_client_recipientid 611 * CBOR Key: TBD (range -256 to 255) 612 * Value Type: byte string 613 * Reference: \[\[This specification\]\] 614 * Name: ace_server_recipientid 615 * CBOR Key: TBD (range -256 to 255) 616 * Value Type: byte string 617 * Reference: \[\[This specification\]\] 619 7.4. OSCORE Security Context Parameters Registry 621 The following registration is done for the ACE Profile Registry 622 following the procedure specified in section 9.4 of 623 [I-D.ietf-ace-oscore-profile]: 625 This registry will be populated by the values in Figure 8. The 626 specification column for all of these entries will be this document. 628 Acknowledgments 630 This document was started from comments and discussion with the 631 following individuals: John Mattsson, Jim Schaad, Goeran Selander. 633 9. References 635 9.1. Normative References 637 [I-D.ietf-ace-oauth-authz] 638 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 639 H. Tschofenig, "Authentication and Authorization for 640 Constrained Environments (ACE) using the OAuth 2.0 641 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 642 (work in progress), June 2020. 644 [I-D.ietf-ace-oscore-profile] 645 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 646 "OSCORE profile of the Authentication and Authorization 647 for Constrained Environments Framework", draft-ietf-ace- 648 oscore-profile-11 (work in progress), June 2020. 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, 652 DOI 10.17487/RFC2119, March 1997, 653 . 655 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 656 RFC 6749, DOI 10.17487/RFC6749, October 2012, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 664 "Object Security for Constrained RESTful Environments 665 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 666 . 668 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 669 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 670 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 671 2020, . 673 9.2. Informative References 675 [I-D.ietf-lake-edhoc] 676 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 677 Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- 678 edhoc-01 (work in progress), August 2020. 680 Author's Address 682 Francesca Palombini 683 Ericsson AB 684 Torshamnsgatan 23 685 Kista SE-16440 Stockholm 686 Sweden 688 Email: francesca.palombini@ericsson.com