idnits 2.17.1 draft-ietf-ace-oscore-profile-07.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 (February 19, 2019) is 1891 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-21 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-04 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-11) exists of draft-ietf-ace-cwt-proof-of-possession-05 -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 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: August 23, 2019 RISE SICS AB 6 G. Selander 7 Ericsson AB 8 M. Gunnarsson 9 RISE SICS AB 10 February 19, 2019 12 OSCORE profile of the Authentication and Authorization for Constrained 13 Environments Framework 14 draft-ietf-ace-oscore-profile-07 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, server authentication, 22 and proof-of-possession for a key owned by the client and bound to an 23 OAuth 2.0 access token. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 23, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 5 63 3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 6 64 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 7 65 3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 11 66 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 14 67 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 15 68 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 16 69 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 17 70 4.4. Access rights verification . . . . . . . . . . . . . . . 18 71 5. Secure Communication with AS . . . . . . . . . . . . . . . . 19 72 6. Discarding the Security Context . . . . . . . . . . . . . . . 19 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 74 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 21 77 9.2. OSCORE Security Context Parameters Registry . . . . . . . 22 78 9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 22 79 9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 23 80 9.5. Expert Review Instructions . . . . . . . . . . . . . . . 23 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 83 10.2. Informative References . . . . . . . . . . . . . . . . . 25 84 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 25 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 88 1. Introduction 90 This memo specifies a profile of the ACE framework 91 [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource 92 server use CoAP [RFC7252] to communicate. The client uses an access 93 token, bound to a key (the proof-of-possession key) to authorize its 94 access to the resource server. In order to provide communication 95 security, proof of possession, and server authentication they use 96 Object Security for Constrained RESTful Environments (OSCORE) 97 [I-D.ietf-core-object-security]. 99 OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) 100 [RFC8152] to secure CoAP messages. Note that OSCORE can be used to 101 secure CoAP messages, as well as HTTP and combinations of HTTP and 102 CoAP; a profile of ACE similar to the one described in this document, 103 with the difference of using HTTP instead of CoAP as communication 104 protocol, could be specified analogously to this one. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 Certain security-related terms such as "authentication", 115 "authorization", "confidentiality", "(data) integrity", "message 116 authentication code", and "verify" are taken from [RFC4949]. 118 RESTful terminology follows HTTP [RFC7231]. 120 Terminology for entities in the architecture is defined in OAuth 2.0 121 [RFC6749], such as client (C), resource server (RS), and 122 authorization server (AS). It is assumed in this document that a 123 given resource on a specific RS is associated to a unique AS. 125 Note that the term "endpoint" is used here, as in 126 [I-D.ietf-ace-oauth-authz], following its OAuth definition, which is 127 to denote resources such as token and introspect at the AS and authz- 128 info at the RS. The CoAP [RFC7252] definition, which is "An entity 129 participating in the CoAP protocol" is not used in this memo. 131 2. Protocol Overview 133 This section gives an overview on how to use the ACE Framework 134 [I-D.ietf-ace-oauth-authz] to secure the communication between a 135 client and a resource server using OSCORE 136 [I-D.ietf-core-object-security]. The parameters needed by the client 137 to negotiate the use of this profile with the authorization server, 138 as well as OSCORE setup process, are described in detail in the 139 following sections. 141 This profile requires a client to retrieve an access token from the 142 AS for the resource it wants to access on a RS, using the token 143 endpoint, as specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. 145 To determine the AS in charge of a resource hosted at the RS, the 146 client C MAY send an initial Unauthorized Resource Request message to 147 the RS. The RS then denies the request and sends the address of its 148 AS back to the client C as specified in section 5.1 of 149 [I-D.ietf-ace-oauth-authz]. The access token request and response 150 MUST be confidentiality-protected and ensure authenticity. This 151 profile RECOMMENDS the use of OSCORE between client and AS, but TLS 152 or DTLS MAY be used additionally or instead. 154 Once the client has retrieved the access token, it generates a nonce 155 N1 and posts both the token and N1 to the RS using the authz-info 156 endpoint and mechanisms specified in section 5.8 of 157 [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor. 159 If the access token is valid, the RS replies to this request with a 160 2.01 (Created) response with Content-Format = application/ace+cbor, 161 which contains a nonce N2 in a CBOR map. Moreover, the server 162 concatenates N1 with N2 and sets the ID Context in the Security 163 Context (see section 3 of [I-D.ietf-core-object-security]) to N1 164 concatenated with N2. The RS then derives the complete Security 165 Context associated with the received token from it plus the 166 parameters received in the AS, following section 3.2 of 167 [I-D.ietf-core-object-security]. 169 After receiving the nonce N2, the client concatenates it with N1 and 170 sets the ID Context in its Security Context (see section 3 of 171 [I-D.ietf-core-object-security]) to N1 concatenated with N2. The 172 client then derives the complete Security Context from the ID Context 173 plus the parameters received from the AS. 175 Finally, the client sends a request protected with OSCORE to the RS. 176 This message may contain the ID Context value. If the request 177 verifies, then this Security Context is stored in the server, and 178 used in the response, and in further communications with the client, 179 until token expiration. This Security Context is discarded if the 180 same token is re-used to successfully derive a new Security Context. 181 Once the client receives a valid response, it does not continue to 182 include the ID Context value in further requests. 184 The use of random nonces during the exchange prevents the reuse of 185 AEAD nonces and keys with different messages, in case of re- 186 derivation of the Security Context both for Clients and Resource 187 Servers from an old non-expired access token, e.g. in case of re-boot 188 of either the client or RS. In fact, by using random nonces as ID 189 Context, the request to the authz-info endpoint posting the same 190 token results in a different Security Context, since Master Secret, 191 Sender ID and Recipient ID are the same but ID Context is different. 192 Therefore, the main requirement for the nonces is that they have a 193 good amount of randomness. If random nonces were not used, a node 194 re-using a non-expired old token would be susceptible to on-path 195 attackers provoking the creation of OSCORE messages using old AEAD 196 keys and nonces. 198 An overview of the profile flow for the OSCORE profile is given in 199 Figure 1. 201 C RS AS 202 | [-- Resource Request --->] | | 203 | | | 204 | [<----- AS Information --] | | 205 | | | 206 | ----- POST /token ----------------------------> | 207 | | | 208 | <---------------------------- Access Token ----- | 209 | + RS Information | 210 | ---- POST /authz-info ---> | | 211 | (access_token, N1) | | 212 | | | 213 | <--- 2.01 Created (N2) --- | | 214 | | | 215 /Sec Context /Sec Context | 216 Derivation/ Derivation/ | 217 | | | 218 | ---- OSCORE Request -----> | | 219 | ?(N1, N2) | | 220 | | | 221 | <--- OSCORE Response ----- | | 222 | | | 223 | ---- OSCORE Request -----> | | 224 | | | 225 | <--- OSCORE Response ----- | | 226 | ... | | 228 Figure 1: Protocol Overview 230 3. Client-AS Communication 232 The following subsections describe the details of the POST request 233 and response to the token endpoint between client and AS. 234 Section 3.2 of [I-D.ietf-core-object-security] defines how to derive 235 a Security Context based on a shared master secret and a set of other 236 parameters, established between client and server, which the client 237 receives from the AS in this exchange. The proof-of-possession key 238 (pop-key) provisioned from the AS MUST be used as master secret in 239 OSCORE. 241 3.1. C-to-AS: POST to token endpoint 243 The client-to-AS request is specified in Section 5.6.1 of 244 [I-D.ietf-ace-oauth-authz]. 246 The client MUST send this POST request to the token endpoint over a 247 secure channel that guarantees authentication, message integrity and 248 confidentiality (see Section 5). 250 An example of such a request, in CBOR diagnostic notation without the 251 tag and value abbreviations is reported in Figure 2 253 Header: POST (Code=0.02) 254 Uri-Host: "as.example.com" 255 Uri-Path: "token" 256 Content-Format: "application/ace+cbor" 257 Payload: 258 { 259 "req_aud" : "tempSensor4711", 260 "scope" : "read" 261 } 263 Figure 2: Example C-to-AS POST /token request for an access token 264 bound to a symmetric key. 266 If the client wants to update its access rights without changing an 267 existing OSCORE Security Context, it MUST include in its POST request 268 to the token endpoint a req_cnf object carrying the client's 269 identifier (that was assigned in section Section 3.2) in the kid 270 field. This identifier can be used by the AS to determine the shared 271 secret to construct the proof-of-possession token and therefore MUST 272 identify a symmetric key that was previously generated by the AS as a 273 shared secret for the communication between the client and the RS. 274 The AS MUST verify that the received value identifies a proof-of- 275 possession key and token that have previously been issued to the 276 requesting client. If that is not the case, the Client-to-AS request 277 MUST be declined with the error code 'invalid_request' as defined in 278 Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 280 An example of such a request, in CBOR diagnostic notation without the 281 tag and value abbreviations is reported in Figure 3 282 Header: POST (Code=0.02) 283 Uri-Host: "as.example.com" 284 Uri-Path: "token" 285 Content-Format: "application/ace+cbor" 286 Payload: 287 { 288 "req_aud" : "tempSensor4711", 289 "scope" : "write", 290 "req_cnf" : { 291 "kid" : "myclient" 292 } 294 Figure 3: Example C-to-AS POST /token request for updating rights to 295 an access token bound to a symmetric key. 297 3.2. AS-to-C: Access Token 299 After verifying the POST request to the token endpoint and that the 300 client is authorized to obtain an access token corresponding to its 301 access token request, the AS responds as defined in section 5.6.2 of 302 [I-D.ietf-ace-oauth-authz]. If the client request was invalid, or 303 not authorized, the AS returns an error response as described in 304 section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 306 The AS can signal that the use of OSCORE is REQUIRED for a specific 307 access token by including the "profile" parameter with the value 308 "coap_oscore" in the access token response. This means that the 309 client MUST use OSCORE towards all resource servers for which this 310 access token is valid, and follow Section 4.3 to derive the security 311 context to run OSCORE. Usually it is assumed that constrained 312 devices will be pre-configured with the necessary profile, so that 313 this kind of profile negotiation can be omitted. 315 Moreover, the AS MUST provision the following data: 317 o a master secret 319 o a server identifier 321 Additionally, the AS MAY provision the following data, in the same 322 response. 324 o a client identifier 326 o an AEAD algorithm 328 o an HKDF algorithm 329 o a salt 331 o a replay window type and size 333 The master secret MUST be communicated as the 'ms' field in the 334 OSCORE_Security_Context in the 'cnf' parameter of the access token 335 response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params]. 336 The OSCORE_Security_Context is a CBOR map object, defined in 337 Section 3.2.1. The AEAD algorithm MAY be included as the 'alg' 338 parameter in the OSCORE_Security_Context; the HKDF algorithm MAY be 339 included as the 'hkdf' parameter of the OSCORE_Security_Context, the 340 salt MAY be included as the 'salt' parameter of the 341 COSCORE_Security_Context, and the replay window type and size MAY be 342 included as the 'rpl' of the OSCORE_Security_Context, as defined in 343 Section 3.2.1. 345 The same parameters MUST be included as metadata of the access token. 346 This profile RECOMMENDS the use of CBOR web token (CWT) as specified 347 in [RFC8392]. If the token is a CWT, the same 348 OSCORE_Security_Context structure defined above MUST be placed in the 349 'cnf' claim of this token. 351 The AS MUST also assign an identifier to the RS, and MAY assign an 352 identifier to the client. These identifiers are then used as Sender 353 ID and Recipient ID in the OSCORE context as described in section 3.1 354 of [I-D.ietf-core-object-security]. The client identifiers MUST be 355 unique in the set of all clients on a single RS, and RS identifiers 356 MUST be unique in the set of all RS for any given client. Moreover, 357 when assigned, these MUST be included in the OSCORE_Security_Context, 358 as defined in Section 3.2.1. 360 We assume in this document that a resource is associated to one 361 single AS, which makes it possible to assume unique identifiers for 362 each client requesting a particular resource to a RS. If this is not 363 the case, collisions of identifiers may appear in the RS, in which 364 case the RS needs to have a mechanism in place to disambiguate 365 identifiers or mitigate their effect. 367 Note that in Section 4.3 C sets the Sender ID of its Security Context 368 to the clientId value received and the Recipient ID to the serverId 369 value, and RS does the opposite. 371 Figure 4 shows an example of such an AS response, in CBOR diagnostic 372 notation without the tag and value abbreviations. 374 Header: Created (Code=2.01) 375 Content-Type: "application/ace+cbor" 376 Payload: 377 { 378 "access_token" : h'a5037674656d7053656e73 ...' 379 (remainder of access token omitted for brevity)', 380 "profile" : "coap_oscore", 381 "expires_in" : "3600", 382 "cnf" : { 383 "OSCORE_Security_Context" : { 384 "alg" : "AES-CCM-16-64-128", 385 "clientId" : b64'qA', 386 "serverId" : b64'Qg', 387 "ms" : h'f9af838368e353e78888e1426bd94e6f' 388 } 389 } 390 } 392 Figure 4: Example AS-to-C Access Token response with OSCORE profile. 394 Figure 5 shows an example CWT, containing the necessary OSCORE 395 parameters in the 'cnf' claim, in CBOR diagnostic notation without 396 tag and value abbreviations. 398 { 399 "aud" : "tempSensorInLivingRoom", 400 "iat" : "1360189224", 401 "exp" : "1360289224", 402 "scope" : "temperature_g firmware_p", 403 "cnf" : { 404 "OSCORE_Security_Context" : { 405 "alg" : "AES-CCM-16-64-128", 406 "clientId" : "client", 407 "serverId" : "server", 408 "ms" : h'f9af838368e353e78888e1426bd94e6f' 409 } 410 } 412 Figure 5: Example CWT with OSCORE parameters. 414 The same CWT token as in Figure 5, using the value abbreviations 415 defined in [I-D.ietf-ace-oauth-authz] and 416 [I-D.ietf-ace-cwt-proof-of-possession] and encoded in CBOR is shown 417 in Figure 6. 419 NOTE TO THE RFC EDITOR: before publishing, it should be checked (and 420 in case fixed) that the values used below (which are not yet 421 registered) are the final values registered in IANA. 423 A5 # map(5) 424 03 # unsigned(3) 425 76 # text(22) 426 74656D7053656E736F72496E4C6976696E67526F6F6D 427 # "tempSensorInLivingRoom" 428 06 # unsigned(6) 429 1A 5112D728 # unsigned(1360189224) 430 04 # unsigned(4) 431 1A 51145DC8 # unsigned(1360289224) 432 09 # unsigned(9) 433 78 18 # text(24) 434 74656D70657261747572655F67206669726D776172655F70 435 # "temperature_g firmware_p" 436 08 # unsigned(8) 437 A1 # map(1) 438 04 # unsigned(4) 439 A4 # map(4) 440 05 # unsigned(5) 441 0A # unsigned(10) 442 02 # unsigned(2) 443 66 # text(6) 444 636C69656E74 # "client" 445 03 # unsigned(3) 446 66 # text(6) 447 736572766572 # "server" 448 01 # unsigned(1) 449 50 # bytes(16) 450 F9AF838368E353E78888E1426BD94E6F 452 Figure 6: Example CWT with OSCORE parameters. 454 If the client has requested an update to its access rights using the 455 same OSCORE Security Context, which is valid and authorized, the AS 456 MUST omit the 'cnf' parameter in the response, and MUST carry the 457 client identifier in the 'kid' field in the 'cnf' parameter of the 458 token. The client identifier needs to be provisioned, in order for 459 the RS to identify the previously generated Security Context. 461 Figure 7 shows an example of such an AS response, in CBOR diagnostic 462 notation without the tag and value abbreviations. 464 Header: Created (Code=2.01) 465 Content-Type: "application/ace+cbor" 466 Payload: 467 { 468 "access_token" : h'a5037674656d7053656e73 ...' 469 (remainder of access token omitted for brevity)', 470 "profile" : "coap_oscore", 471 "expires_in" : "3600" 472 } 474 Figure 7: Example AS-to-C Access Token response with OSCORE profile, 475 for update of access rights. 477 Figure 8 shows an example CWT, containing the necessary OSCORE 478 parameters in the 'cnf' claim for update of access rights, in CBOR 479 diagnostic notation without tag and value abbreviations. 481 { 482 "aud" : "tempSensorInLivingRoom", 483 "iat" : "1360189224", 484 "exp" : "1360289224", 485 "scope" : "temperature_h", 486 "cnf" : { 487 "kid" : b64'qA' 488 } 489 } 491 Figure 8: Example CWT with OSCORE parameters for update of access 492 rights. 494 3.2.1. OSCORE_Security_Context Object 496 An OSCORE_Security_Context is an object that represents part or all 497 of an OSCORE Security Context (Section 3.1 of 498 [I-D.ietf-core-object-security]). The OSCORE_Security_Context object 499 can either be encoded as JSON or as CBOR. In both cases, the set of 500 common parameters that can appear in an OSCORE_Security_Context 501 object can be found in the IANA "OSCORE Security Context Parameters" 502 registry (Section Section 9.2) and is defined below. All parameters 503 are optional. Table 1 provides a summary of the 504 OSCORE_Security_Context parameters defined in this section. 506 +-----------+-------+----------------+--------------+---------------+ 507 | name | CBOR | CBOR type | registry | description | 508 | | label | | | | 509 +-----------+-------+----------------+--------------+---------------+ 510 | ms | 1 | bstr | | OSCORE Master | 511 | | | | | Secret value | 512 | | | | | | 513 | clientId | 2 | bstr | | OSCORE Sender | 514 | | | | | ID value of | 515 | | | | | the client, | 516 | | | | | OSCORE | 517 | | | | | Recipient ID | 518 | | | | | value of the | 519 | | | | | server | 520 | | | | | | 521 | serverId | 3 | bstr | | OSCORE Sender | 522 | | | | | ID value of | 523 | | | | | the server, | 524 | | | | | OSCORE | 525 | | | | | Recipient ID | 526 | | | | | value of the | 527 | | | | | client | 528 | | | | | | 529 | hkdf | 4 | bstr / int | COSE | OSCORE HKDF | 530 | | | | Algorithm | value | 531 | | | | Values | | 532 | | | | (HMAC-based) | | 533 | | | | | | 534 | alg | 5 | tstr / int | COSE | OSCORE AEAD | 535 | | | | Algorithm | Algorithm | 536 | | | | Values | value | 537 | | | | (AEAD) | | 538 | | | | | | 539 | salt | 6 | bstr | | OSCORE Master | 540 | | | | | Salt value | 541 | | | | | | 542 | contextId | 7 | bstr | | OSCORE ID | 543 | | | | | Context value | 544 | | | | | | 545 | rpl | 8 | bstr / int | | OSCORE Replay | 546 | | | | | Window Type | 547 | | | | | and Size | 548 +-----------+-------+----------------+--------------+---------------+ 550 Table 1: OSCORE_Security_Context Parameters 552 ms: This parameter identifies the OSCORE Master Secret value, which 553 is a byte string. For more information about this field, see 554 section 3.1 of [I-D.ietf-core-object-security]. In JSON, the "ms" 555 value is a Base64 encoded byte string. In CBOR, the "ms" type is 556 bstr, and has label 1. 558 clientId: This parameter identifies a client identifier as a byte 559 string. This identifier is used as OSCORE Sender ID in the client 560 and OSCORE Recipient ID in the server. For more information about 561 this field, see section 3.1 of [I-D.ietf-core-object-security]. 562 In JSON, the "clientId" value is a Base64 encoded byte string. In 563 CBOR, the "clientId" type is bstr, and has label 2. 565 serverId: This parameter identifies a server identifier as a byte 566 string. This identifier is used as OSCORE Sender ID in the server 567 and OSCORE Recipient ID in the client. For more information about 568 this field, see section 3.1 of [I-D.ietf-core-object-security]. 569 In JSON, the "serverId" value is a Base64 encoded byte string. In 570 CBOR, the "serverId" type is bstr, and has label 3. 572 hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more 573 information about this field, see section 3.1 of 574 [I-D.ietf-core-object-security]. The values used MUST be 575 registered in the IANA "COSE Algorithms" registry and MUST be 576 HMAC-based HKDF algorithms. The value can either be the integer 577 or the text string value of the HMAC-based HKDF algorithm in the 578 "COSE Algorithms" registry. In JSON, the "hkdf" value is a case- 579 sensitive ASCII string or an integer. In CBOR, the "hkdf" type is 580 tstr or int, and has label 4. 582 alg: This parameter identifies the OSCORE AEAD Algorithm. For more 583 information about this field, see section 3.1 of 584 [I-D.ietf-core-object-security] The values used MUST be registered 585 in the IANA "COSE Algorithms" registry and MUST be AEAD 586 algorithms. The value can either be the integer or the text 587 string value of the HMAC-based HKDF algorithm in the "COSE 588 Algorithms" registry. In JSON, the "alg" value is a case- 589 sensitive ASCII string or an integer. In CBOR, the "alg" type is 590 tstr or int, and has label 5. 592 salt: This parameter identifies the OSCORE Master Salt value, which 593 is a byte string. For more information about this field, see 594 section 3.1 of [I-D.ietf-core-object-security]. In JSON, the 595 "salt" value is a Base64 encoded byte string. In CBOR, the "salt" 596 type is bstr, and has label 6. 598 contextId: This parameter identifies the security context as a byte 599 string. This identifier is used as OSCORE ID Context. For more 600 information about this field, see section 3.1 of 601 [I-D.ietf-core-object-security]. In JSON, the "contextID" value 602 is a Base64 encoded byte string. In CBOR, the "contextID" type is 603 bstr, and has label 7. 605 rpl: This parameter is used to carry the OSCORE value, encoded as a 606 bstr. This parameter identifies the OSCORE Replay Window Size and 607 Type value, which is a byte string. For more information about 608 this field, see section 3.1 of [I-D.ietf-core-object-security]. 609 In JSON, the "rpl" value is a Base64 encoded byte string. In 610 CBOR, the "rpl" type is bstr, and has label 8. 612 An example of JSON OSCORE_Security_Context is given in Figure 9. 614 "OSCORE_Security_Context" : { 615 "alg" : "AES-CCM-16-64-128", 616 "clientId" : b64'qA', 617 "serverId" : b64'Qg', 618 "ms" : b64'+a+Dg2jjU+eIiOFCa9lObw' 619 } 621 Figure 9: Example JSON OSCORE_Security_Context object 623 The CDDL grammar describing the CBOR OSCORE_Security_Context object 624 is: 626 OSCORE_Security_Context = { 627 ? 1 => bstr, ; ms 628 ? 2 => bstr, ; clientId 629 ? 3 => bstr, ; serverId 630 ? 4 => tstr / int, ; hkdf 631 ? 5 => tstr / int, ; alg 632 ? 6 => bstr, ; salt 633 ? 7 => bstr, ; contextId 634 ? 8 => bstr / tstr, ; rpl 635 * int / tstr => any 636 } 638 4. Client-RS Communication 640 The following subsections describe the details of the POST request 641 and response to the authz-info endpoint between client and RS. The 642 client generates a nonce N1 and posts it together with the token that 643 includes the materials provisioned by the AS to the RS. The RS then 644 derives a nonce N2 and use Section 3.2 of 645 [I-D.ietf-core-object-security] to derive a security context based on 646 a shared master secret and the two nonces, established between client 647 and server. 649 Note that the proof-of-possession required to bind the access token 650 to the client is implicitly performed by generating the shared OSCORE 651 Security Context using the pop-key as master secret, for both client 652 and RS. An attacker using a stolen token will not be able to 653 generate a valid OSCORE context and thus not be able to prove 654 possession of the pop-key. 656 4.1. C-to-RS: POST to authz-info endpoint 658 The client MUST generate a nonce N1 very unlikely to have been 659 previously used with the same input keying material. This profile 660 RECOMMENDS to use a 64-bit long random number as nonce. The client 661 MUST store this nonce as long as the response from the RS is not 662 received and the access token related to it is still valid. The 663 client MUST use CoAP and the Authorization Information resource as 664 described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to transport 665 the token and N1 to the RS. The client MUST use the Content-Format 666 "application/ace+cbor" defined in section 8.14 of 667 [I-D.ietf-ace-oauth-authz]. The client MUST include the access token 668 using the correct CBOR label (e.g., "cwt" for CWT, "jwt" for JWT) and 669 N1 using the 'nonce' parameter defined in section 5.1.2 of 670 [I-D.ietf-ace-oauth-authz]. 672 The authz-info endpoint is not protected, nor are the responses from 673 this resource. 675 The access token MUST be encrypted, since it is transferred from the 676 client to the RS over an unprotected channel. 678 Note that a client may be required to re-POST the access token, since 679 an RS may delete a stored access token, due to lack of memory. 681 Figure 10 shows an example of the request sent from the client to the 682 RS, in CBOR diagnostic notation without the tag and value 683 abbreviations. 685 Header: POST (Code=0.02) 686 Uri-Host: "rs.example.com" 687 Uri-Path: "authz-info" 688 Content-Format: "application/ace+cbor" 689 Payload: 690 { 691 "access_token": h'a5037674656d7053656e73 ...' 692 (remainder of access token omitted for brevity)', 693 "nonce": h'018a278f7faab55a' 694 } 696 Figure 10: Example C-to-RS POST /authz-info request using CWT 698 4.2. RS-to-C: 2.01 (Created) 700 The RS MUST follow the procedures defined in section 5.8.1 of 701 [I-D.ietf-ace-oauth-authz]: the RS MUST verify the validity of the 702 token. If the token is valid, the RS MUST respond to the POST 703 request with 2.01 (Created). If the token is valid but is associated 704 to claims that the RS cannot process (e.g., an unknown scope), or if 705 any of the expected parameters in the OSCORE_Security_Context is 706 missing (e.g. any of the mandatory parameters from the AS), or if any 707 parameters received in the OSCORE_Security_Context is unrecognized, 708 the RS MUST respond with an error response code equivalent to the 709 CoAP code 4.00 (Bad Request). In the latter two cases, the RS MAY 710 provide additional information in the error response, in order to 711 clarify what went wrong. The RS MAY make an introspection request to 712 validate the token before responding to the POST request to the 713 authz-info endpoint. 715 Additionally, the RS MUST generate a nonce N2 very unlikely to have 716 been previously used with the same input keying material, and send it 717 within the 2.01 (Created) response. The payload of the 2.01 718 (Created) response MUST be a CBOR map containing the 'nonce' 719 parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set 720 to N2. This profile RECOMMENDS to use a 64-bit long random number as 721 nonce. Moreover, if the OSCORE_Security_Context in the token did not 722 contain a 'clientId' parameter, the RS MUST generate an identifier, 723 unique in the set of all its existing client identifiers, and send it 724 in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS MAY 725 generate and send a 'ClientId' identifier even though the 726 OSCORE_Security_Context contained such a parameter, in order to 727 guarantee the uniqueness of the client identifier. The RS MUST use 728 the Content-Format "application/ace+cbor" defined in section 8.14 of 729 [I-D.ietf-ace-oauth-authz]. 731 Figure 11 shows an example of the response sent from the RS to the 732 client, in CBOR diagnostic notation without the tag and value 733 abbreviations. 735 Header: Created (Code=2.01) 736 Content-Format: "application/ace+cbor" 737 Payload: 738 { 739 "nonce": h'25a8991cd700ac01' 740 } 742 Figure 11: Example RS-to-C 2.01 (Created) response 744 When receiving an updated access token with updated authorization 745 information from the client (see section Section 3.1), it is 746 RECOMMENDED that the RS overwrites the previous token, that is only 747 the latest authorization information in the token received by the RS 748 is valid. This simplifies for the RS to keep track of authorization 749 information for a given client. 751 As specified in section 5.8.3 of [I-D.ietf-ace-oauth-authz], the RS 752 MUST notify the client with an error response with code 4.01 753 (Unauthorized) for any long running request before terminating the 754 session, when the access token expires. 756 4.3. OSCORE Setup 758 Once receiving the 2.01 (Created) response from the RS, following the 759 POST request to authz-info endpoint, the client MUST extract the 760 nonce N2 from the 'nonce' parameter and the client identifier from 761 the 'clientId' in the CBOR map in the payload of the response. Then, 762 the client MUST set the ID Context of the Security Context created to 763 communicate with the RS to the concatenation of N1 and N2, in this 764 order: ID Context = N1 | N2, where | denotes byte string 765 concatenation. The client MUST set the Master Secret and Recipient 766 ID from the parameters received from the AS in Section 3.2. The 767 client MUST set the AEAD Algorithm, Master Salt, HKDF, and Replay 768 Window from the parameters received from the AS in Section 3.2, if 769 present. In case these parameters are omitted, the default values 770 are used as described in section 3.2 of 771 [I-D.ietf-core-object-security]. The client MUST set the Sender ID 772 from the 'clientId in the 2.01 (Created) response, if present; 773 otherwise, the client MUST set the Sender ID from the parameters 774 received from the AS in Section 3.2. After that, the client MUST 775 derive the complete Security Context following section 3.2.1 of 776 [I-D.ietf-core-object-security]. From this point on, the client MUST 777 use this Security Context to communicate with the RS when accessing 778 the resources as specified by the authorization information. 780 If any of the expected parameters is missing (e.g. any of the 781 mandatory parameters from the AS, or the 'clientId', either received 782 from the AS or in the 2.01 (Created) response from the RS), the 783 client MUST stop the exchange, and MUST NOT derive the Security 784 Context. The client MAY restart the exchange, to get the correct 785 security material. 787 The client then uses this Security Context to send requests to RS 788 using OSCORE. In the first request sent to the RS, the client MAY 789 include the kid context if the application needs to, with value ID 790 Context, i.e. N1 concatenated with N2. 792 After sending the 2.01 (Created) response, the RS MUST set the ID 793 Context of the Security Context created to communicate with the 794 client to the concatenation of N1 and N2, in this order: ID Context = 795 N1 | N2, where | denotes byte string concatenation. The RS MUST set 796 the Master Secret, Sender ID and Recipient ID from the parameters, 797 received from the client in the access token in Section 4.1 after 798 validation of the token as specified in Section 4.2. The RS MUST set 799 the AEAD Algorithm, Master Salt, HKDF, and Replay Window from the 800 parameters received from the client in the access token in 801 Section 4.1 after validation of the token as specified in 802 Section 4.2, if present. In case these parameters are omitted, the 803 default values are used as described in section 3.2 of 804 [I-D.ietf-core-object-security]. After that, the RS MUST derive the 805 complete Security Context following section 3.2.1 of 806 [I-D.ietf-core-object-security], and MUST associate this Security 807 Context with the authorization information from the access token. 809 The RS then uses this Security Context to verify the request and send 810 responses to C using OSCORE. If OSCORE verification fails, error 811 responses are used, as specified in section 8 of 812 [I-D.ietf-core-object-security]. Additionally, if OSCORE 813 verification succeeds, the verification of access rights is performed 814 as described in section Section 4.4. The RS MUST NOT use the 815 Security Context after the related token has expired, and MUST 816 respond with a unprotected 4.01 (Unauthorized) error message. 818 4.4. Access rights verification 820 The RS MUST follow the procedures defined in section 5.8.2 of 821 [I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected 822 request from a client, then the RS processes it according to 823 [I-D.ietf-core-object-security]. If OSCORE verification succeeds, 824 and the target resource requires authorization, the RS retrieves the 825 authorization information from the access token associated to the 826 Security Context. The RS then MUST verify that the authorization 827 information covers the resource and the action requested. 829 The response code MUST be 4.01 (Unauthorized) in case the client has 830 not used the Security Context associated with the access token, or if 831 RS has no valid access token for the client. If RS has an access 832 token for the client but not for the resource that was requested, RS 833 MUST reject the request with a 4.03 (Forbidden). If RS has an access 834 token for the client but it does not cover the action that was 835 requested on the resource, RS MUST reject the request with a 4.05 836 (Method Not Allowed). 838 5. Secure Communication with AS 840 As specified in the ACE framework (section 5.7 of 841 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) 842 and the AS communicates via the introspection or token endpoint. The 843 use of CoAP and OSCORE for this communication is RECOMMENDED in this 844 profile, other protocols (such as HTTP and DTLS or TLS) MAY be used 845 instead. 847 If OSCORE is used, the requesting entity and the AS are expected to 848 have pre-established security contexts in place. How these security 849 contexts are established is out of scope for this profile. 850 Furthermore the requesting entity and the AS communicate using OSCORE 851 ([I-D.ietf-core-object-security]) through the introspection endpoint 852 as specified in section 5.7 of [I-D.ietf-ace-oauth-authz] and through 853 the token endpoint as specified in section 5.6 of 854 [I-D.ietf-ace-oauth-authz]. 856 6. Discarding the Security Context 858 There are a number of scenarios where a client or RS needs to discard 859 the OSCORE security context, and acquire a new one. 861 The client MUST discard the current security context associated with 862 an RS when: 864 o the Sequence Number space ends. 866 o the access token associated with the context expires. 868 o the client receives a number of 4.01 Unauthorized responses to 869 OSCORE requests using the same security context. The exact number 870 needs to be specified by the application. 872 o the client receives a new nonce in the 2.01 (Created) response 873 (see Section 4.2) to a POST request to the authz-info endpoint, 874 when re-posting a non-expired token associated to the existing 875 context. 877 The RS MUST discard the current security context associated with a 878 client when: 880 o Sequence Number space ends. 882 o Access token associated with the context expires. 884 7. Security Considerations 886 This document specifies a profile for the Authentication and 887 Authorization for Constrained Environments (ACE) framework 888 [I-D.ietf-ace-oauth-authz]. Thus the general security considerations 889 from the framework also apply to this profile. 891 Furthermore the general security considerations of OSCORE 892 [I-D.ietf-core-object-security] also apply to this specific use of 893 the OSCORE protocol. 895 OSCORE is designed to secure point-to-point communication, providing 896 a secure binding between the request and the response(s). Thus the 897 basic OSCORE protocol is not intended for use in point-to-multipoint 898 communication (e.g. multicast, publish-subscribe). Implementers of 899 this profile should make sure that their usecase corresponds to the 900 expected use of OSCORE, to prevent weakening the security assurances 901 provided by OSCORE. 903 Since the use of nonces in the exchange guarantees uniqueness of AEAD 904 keys and nonces, it is REQUIRED that nonces are not reused with the 905 same input keying material even in case of re-boots. This document 906 RECOMMENDS the use of 64 bit random nonces to guarantee non-reuse; if 907 applications use something else, such as a counter, they need to 908 guarantee that reboot and lost of state on either node does not 909 provoke re-use. If that is not guaranteed, nodes are still 910 susceptible to re-using AEAD nonces and keys, in case the Security 911 Context is lost, and on-path attacker replay messages. 913 This profiles recommends that the RS maintains a single access token 914 for a client. The use of multiple access tokens for a single client 915 increases the strain on the resource server as it must consider every 916 access token and calculate the actual permissions of the client. 917 Also, tokens may contradict each other which may lead the server to 918 enforce wrong permissions. If one of the access tokens expires 919 earlier than others, the resulting permissions may offer insufficient 920 protection. Developers should avoid using multiple access tokens for 921 a client. 923 8. Privacy Considerations 925 This document specifies a profile for the Authentication and 926 Authorization for Constrained Environments (ACE) framework 927 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 928 from the framework also apply to this profile. 930 As this document uses OSCORE, thus the privacy considerations from 931 [I-D.ietf-core-object-security] apply here as well. 933 An unprotected response to an unauthorized request may disclose 934 information about the resource server and/or its existing 935 relationship with the client. It is advisable to include as little 936 information as possible in an unencrypted response. When an OSCORE 937 Security Context already exists between the client and the resource 938 server, more detailed information may be included. 940 Note that some information might still leak after OSCORE is 941 established, due to observable message sizes, the source, and the 942 destination addresses. 944 9. IANA Considerations 946 Note to RFC Editor: Please replace all occurrences of "[[this 947 specification]]" with the RFC number of this specification and delete 948 this paragraph. 950 9.1. ACE OAuth Profile Registry 952 The following registration is done for the ACE OAuth Profile Registry 953 following the procedure specified in section 8.7 of 954 [I-D.ietf-ace-oauth-authz]: 956 o Profile name: coap_oscore 957 o Profile Description: Profile for using OSCORE to secure 958 communication between constrained nodes using the Authentication 959 and Authorization for Constrained Environments framework. 960 o Profile ID: TBD (value between 1 and 255) 961 o Change Controller: IESG 962 o Specification Document(s): [[this specification]] 964 9.2. OSCORE Security Context Parameters Registry 966 It is requested that IANA create a new registry entitled "OSCORE 967 Security Context Parameters" registry. The registry is to be created 968 as Expert Review Required. Guidelines for the experts is provided 969 Section 9.5. It should be noted that in addition to the expert 970 review, some portions of the registry require a specification, 971 potentially on standards track, be supplied as well. 973 The columns of the registry are: 975 name The JSON name requested (e.g., "ms"). Because a core goal of 976 this specification is for the resulting representations to be 977 compact, it is RECOMMENDED that the name be short. This name is 978 case sensitive. Names may not match other registered names in a 979 case-insensitive manner unless the Designated Experts state that 980 there is a compelling reason to allow an exception. The name is 981 not used in the CBOR encoding. 982 CBOR label The value to be used to identify this algorithm. Key map 983 labels MUST be unique. The label can be a positive integer, a 984 negative integer or a string. Integer values between 0 and 255 985 and strings of length 1 are designated as Standards Track Document 986 required. Integer values from 256 to 65535 and strings of length 987 2 are designated as Specification Required. Integer values of 988 greater than 65535 and strings of length greater than 2 are 989 designated as expert review. Integer values less than -65536 are 990 marked as private use. 991 CBOR Type This field contains the CBOR type for the field. 992 registry This field denotes the registry that values may come from, 993 if one exists. 994 description This field contains a brief description for the field. 995 specification This contains a pointer to the public specification 996 for the field if one exists 998 This registry will be initially populated by the values in Table 1. 999 The specification column for all of these entries will be this 1000 document. 1002 9.3. CWT Confirmation Methods Registry 1004 The following registration is done for the CWT Confirmation Methods 1005 Registry following the procedure specified in section 7.2.1 of 1006 [I-D.ietf-ace-cwt-proof-of-possession]: 1008 o Confirmation Method Name: "OSCORE_Security_Context" 1009 o Confirmation Method Description: OSCORE_Security_Context carrying 1010 the OSCORE Security Context parameters 1011 o Confirmation Key: TBD (value between 4 and 255) 1012 o Confirmation Value Type(s): map 1013 o Change Controller: IESG 1014 o Specification Document(s): Section 3.2.1 of [[this specification]] 1016 9.4. JWT Confirmation Methods Registry 1018 The following registration is done for the JWT Confirmation Methods 1019 Registry following the procedure specified in section 6.2.1 of 1020 [RFC7800]: 1022 o Confirmation Method Value: "osc" 1023 o Confirmation Method Description: OSCORE_Security_Context carrying 1024 the OSCORE Security Context parameters 1025 o Change Controller: IESG 1026 o Specification Document(s): Section 3.2.1 of [[this specification]] 1028 9.5. Expert Review Instructions 1030 The IANA registry established in this document is defined as expert 1031 review. This section gives some general guidelines for what the 1032 experts should be looking for, but they are being designated as 1033 experts for a reason so they should be given substantial latitude. 1035 Expert reviewers should take into consideration the following points: 1037 o Point squatting should be discouraged. Reviewers are encouraged 1038 to get sufficient information for registration requests to ensure 1039 that the usage is not going to duplicate one that is already 1040 registered and that the point is likely to be used in deployments. 1041 The zones tagged as private use are intended for testing purposes 1042 and closed environments, code points in other ranges should not be 1043 assigned for testing. 1044 o Specifications are required for the standards track range of point 1045 assignment. Specifications should exist for specification 1046 required ranges, but early assignment before a specification is 1047 available is considered to be permissible. Specifications are 1048 needed for the first-come, first-serve range if they are expected 1049 to be used outside of closed environments in an interoperable way. 1050 When specifications are not provided, the description provided 1051 needs to have sufficient information to identify what the point is 1052 being used for. 1053 o Experts should take into account the expected usage of fields when 1054 approving point assignment. The fact that there is a range for 1055 standards track documents does not mean that a standards track 1056 document cannot have points assigned outside of that range. The 1057 length of the encoded value should be weighed against how many 1058 code points of that length are left, the size of device it will be 1059 used on, and the number of code points left that encode to that 1060 size. 1062 10. References 1064 10.1. Normative References 1066 [I-D.ietf-ace-oauth-authz] 1067 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1068 H. Tschofenig, "Authentication and Authorization for 1069 Constrained Environments (ACE) using the OAuth 2.0 1070 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-21 1071 (work in progress), February 2019. 1073 [I-D.ietf-ace-oauth-params] 1074 Seitz, L., "Additional OAuth Parameters for Authorization 1075 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1076 params-04 (work in progress), February 2019. 1078 [I-D.ietf-core-object-security] 1079 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1080 "Object Security for Constrained RESTful Environments 1081 (OSCORE)", draft-ietf-core-object-security-15 (work in 1082 progress), August 2018. 1084 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1085 Requirement Levels", BCP 14, RFC 2119, 1086 DOI 10.17487/RFC2119, March 1997, 1087 . 1089 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1090 Application Protocol (CoAP)", RFC 7252, 1091 DOI 10.17487/RFC7252, June 2014, 1092 . 1094 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1095 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1096 . 1098 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1099 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1100 May 2017, . 1102 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1103 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1104 May 2018, . 1106 10.2. Informative References 1108 [I-D.ietf-ace-cwt-proof-of-possession] 1109 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1110 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1111 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1112 possession-05 (work in progress), November 2018. 1114 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1115 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1116 . 1118 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1119 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1120 . 1122 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1123 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1124 DOI 10.17487/RFC7231, June 2014, 1125 . 1127 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1128 Possession Key Semantics for JSON Web Tokens (JWTs)", 1129 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1130 . 1132 Appendix A. Profile Requirements 1134 This section lists the specifications on this profile based on the 1135 requirements on the framework, as requested in Appendix C of 1136 [I-D.ietf-ace-oauth-authz]. 1138 o (Optional) discovery process of how the client finds the right AS 1139 for an RS it wants to send a request to: Not specified 1140 o communication protocol the client and the RS must use: CoAP 1141 o security protocol the client and RS must use: OSCORE 1142 o how the client and the RS mutually authenticate: Implicitly by 1143 possession of a common OSCORE security context 1144 o Content-format of the protocol messages: "application/ace+cbor" 1145 o proof-of-possession protocol(s) and how to select one; which key 1146 types (e.g. symmetric/asymmetric) supported: OSCORE algorithms; 1147 pre-established symmetric keys 1148 o profile identifier: coap_oscore 1149 o (Optional) how the RS talks to the AS for introspection: HTTP/CoAP 1150 (+ TLS/DTLS/OSCORE) 1151 o how the client talks to the AS for requesting a token: HTTP/CoAP 1152 (+ TLS/DTLS/OSCORE) 1154 o how/if the authz-info endpoint is protected: Security protocol 1155 above 1156 o (Optional)other methods of token transport than the authz-info 1157 endpoint: no 1159 Acknowledgments 1161 The authors wish to thank Jim Schaad and Marco Tiloca for the input 1162 on this memo. 1164 Authors' Addresses 1166 Francesca Palombini 1167 Ericsson AB 1169 Email: francesca.palombini@ericsson.com 1171 Ludwig Seitz 1172 RISE SICS AB 1173 Scheelevagen 17 1174 Lund 22370 1175 Sweden 1177 Email: ludwig.seitz@ri.se 1179 Goeran Selander 1180 Ericsson AB 1182 Email: goran.selander@ericsson.com 1184 Martin Gunnarsson 1185 RISE SICS AB 1186 Scheelevagen 17 1187 Lund 22370 1188 Sweden 1190 Email: martin.gunnarsson@ri.se