idnits 2.17.1 draft-ietf-ace-oscore-profile-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1502 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-33 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-12 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 3 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: September 10, 2020 Combitech 6 G. Selander 7 Ericsson AB 8 M. Gunnarsson 9 RISE 10 March 9, 2020 12 OSCORE profile of the Authentication and Authorization for Constrained 13 Environments Framework 14 draft-ietf-ace-oscore-profile-10 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 September 10, 2020. 42 Copyright Notice 44 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 6 63 3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 6 64 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 8 65 3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 13 66 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 16 67 4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 17 68 4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 18 69 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18 70 4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 19 71 4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 19 72 4.4. Access rights verification . . . . . . . . . . . . . . . 21 73 5. Secure Communication with AS . . . . . . . . . . . . . . . . 21 74 6. Discarding the Security Context . . . . . . . . . . . . . . . 21 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 76 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 24 79 9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 24 80 9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 24 81 9.4. OSCORE Security Context Parameters Registry . . . . . . . 25 82 9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 25 83 9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 26 84 9.7. Expert Review Instructions . . . . . . . . . . . . . . . 26 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 87 10.2. Informative References . . . . . . . . . . . . . . . . . 28 88 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 28 89 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 92 1. Introduction 94 This memo specifies a profile of the ACE framework 95 [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource 96 server use CoAP [RFC7252] to communicate. The client uses an access 97 token, bound to a key (the proof-of-possession key) to authorize its 98 access to the resource server. Note that this profile uses a 99 symmetric-crypto-based scheme, where the symmetric secret is used as 100 input material for keying material derivation. In order to provide 101 communication security, proof of possession, and server 102 authentication the client and resource server use Object Security for 103 Constrained RESTful Environments (OSCORE) [RFC8613]. Note that the 104 proof of possession is not done by a dedicated protocol element, but 105 rather occurs implicitly, based on knowledge of the security keying 106 material. 108 OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) 109 [RFC8152] to secure CoAP messages. Note that OSCORE can be used to 110 secure CoAP messages, as well as HTTP and combinations of HTTP and 111 CoAP; a profile of ACE similar to the one described in this document, 112 with the difference of using HTTP instead of CoAP as communication 113 protocol, could be specified analogously to this one. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 Certain security-related terms such as "authentication", 124 "authorization", "confidentiality", "(data) integrity", "message 125 authentication code", and "verify" are taken from [RFC4949]. 127 RESTful terminology follows HTTP [RFC7231]. 129 Terminology for entities in the architecture is defined in OAuth 2.0 130 [RFC6749], such as client (C), resource server (RS), and 131 authorization server (AS). It is assumed in this document that a 132 given resource on a specific RS is associated to a unique AS. 134 Concise Data Definition Language (CDDL) [RFC8610] is used in this 135 specification. 137 Note that the term "endpoint" is used here, as in 138 [I-D.ietf-ace-oauth-authz], following its OAuth definition, which is 139 to denote resources such as token and introspect at the AS and authz- 140 info at the RS. The CoAP [RFC7252] definition, which is "An entity 141 participating in the CoAP protocol" is not used in this memo. 143 2. Protocol Overview 145 This section gives an overview on how to use the ACE Framework 146 [I-D.ietf-ace-oauth-authz] to secure the communication between a 147 client and a resource server using OSCORE [RFC8613]. The parameters 148 needed by the client to negotiate the use of this profile with the 149 authorization server, as well as OSCORE setup process, are described 150 in detail in the following sections. 152 The RS maintains a collection of OSCORE Security Contexts with 153 associated authorization information for all the clients that it is 154 communicating with. The authorization information is maintained as 155 policy that's used as input to processing requests from those 156 clients. 158 This profile requires a client to retrieve an access token from the 159 AS for the resource it wants to access on a RS, using the token 160 endpoint, as specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. 161 To determine the AS in charge of a resource hosted at the RS, the 162 client C MAY send an initial Unauthorized Resource Request message to 163 the RS. The RS then denies the request and sends the address of its 164 AS back to the client C as specified in section 5.1 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 and posts both the token and N1 to the RS using the authz-info 172 endpoint and mechanisms specified in section 5.8 of 173 [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor. 174 Note that, as specified in the ACE framework, the authz-info endpoint 175 is not a protected resource, so there is no cryptographic protection 176 to this request. 178 If the access token is valid, the RS replies to this request with a 179 2.01 (Created) response with Content-Format = application/ace+cbor, 180 which contains a nonce N2 in a CBOR map. Moreover, the server 181 concatenates the input salt, N1, and N2 to obtain the Master Salt of 182 the OSCORE Security Context (see section 3 of [RFC8613]). The RS 183 then derives the complete Security Context associated with the 184 received token from it plus the parameters received in the access 185 token from the AS, following section 3.2 of [RFC8613]. 187 After receiving the nonce N2, the client concatenates the input salt, 188 N1 and N2 to obtain the Master Salt of the OSCORE Security Context 189 (see section 3 of [RFC8613]). The client then derives the complete 190 Security Context from the nonces plus the parameters received from 191 the AS. 193 Finally, the client sends a request protected with OSCORE to the RS. 194 If the request verifies, the server stores the complete Security 195 Context state that is ready for use in protecting messages, and uses 196 it in the response, and in further communications with the client, 197 until token expiration. This Security Context is discarded when a 198 token (whether the same or different) is used to successfully derive 199 a new Security Context for that client. 201 The use of random nonces during the exchange prevents the reuse of an 202 AEAD nonces/key pair for two different messages. This situation 203 might occur when client and RS derive a new Security Context from an 204 existing (non-expired) access token, as might occur when either party 205 has just rebooted. Instead, by using random nonces as part of the 206 Master Salt, the request to the authz-info endpoint posting the same 207 token results in a different Security Context, by OSCORE 208 construction, since even though the Master Secret, Sender ID and 209 Recipient ID are the same, the Master Salt is different (see 210 Section 3.2.1 of [RFC8613]). Therefore, the main requirement for the 211 nonces is that they have a good amount of randomness. If random 212 nonces were not used, a node re-using a non-expired old token would 213 be susceptible to on-path attackers provoking the creation of OSCORE 214 messages using old AEAD keys and nonces. 216 After the whole message exchange has taken place, the client can 217 contact the AS to request an update of its access rights, sending a 218 similar request to the token endpoint that also includes an 219 identifier so that the AS can find the correct OSCORE security 220 material it has previously shared with the Client. This specific 221 identifier, which [I-D.ietf-ace-oauth-authz] encodes as a bstr, is 222 formatted to include two OSCORE identifiers, namely ID context and 223 client ID, that are necessary to determine the correct OSCORE 224 Security Context. 226 An overview of the profile flow for the OSCORE profile is given in 227 Figure 1. 229 C RS AS 230 | [-- Resource Request --->] | | 231 | | | 232 | [<---- AS Request ------] | | 233 | Creation Hints | | 234 | | | 235 | ----- POST /token ----------------------------> | 236 | | | 237 | <---------------------------- Access Token ----- | 238 | + Access Information | 239 | ---- POST /authz-info ---> | | 240 | (access_token, N1) | | 241 | | | 242 | <--- 2.01 Created (N2) --- | | 243 | | | 244 /Sec Context /Sec Context | 245 Derivation/ Derivation/ | 246 | | | 247 | ---- OSCORE Request -----> | | 248 | | | 249 | <--- OSCORE Response ----- | | 250 | | | 251 | ---- OSCORE Request -----> | | 252 | | | 253 | <--- OSCORE Response ----- | | 254 | ... | | 256 Figure 1: Protocol Overview 258 3. Client-AS Communication 260 The following subsections describe the details of the POST request 261 and response to the token endpoint between client and AS. 262 Section 3.2 of [RFC8613] defines how to derive a Security Context 263 based on a shared master secret and a set of other parameters, 264 established between client and server, which the client receives from 265 the AS in this exchange. The proof-of-possession key (pop-key) 266 included in the response from the AS MUST be used as master secret in 267 OSCORE. 269 3.1. C-to-AS: POST to token endpoint 271 The client-to-AS request is specified in Section 5.6.1 of 272 [I-D.ietf-ace-oauth-authz]. 274 The client must send this POST request to the token endpoint over a 275 secure channel that guarantees authentication, message integrity and 276 confidentiality (see Section 5). 278 An example of such a request, with payload in CBOR diagnostic 279 notation without the tag and value abbreviations is reported in 280 Figure 2 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" : "read" 290 } 292 Figure 2: Example C-to-AS POST /token request for an access token 293 bound to a symmetric key. 295 If the client wants to update its access rights without changing an 296 existing OSCORE Security Context, it MUST include in its POST request 297 to the token endpoint a req_cnf object. The req_cnf MUST include a 298 kid field carrying a bstr-wrapped CBOR array object containing the 299 client's identifier (assigned as discussed in Section 3.2) and 300 optionally the context identifier (if assigned as discussed in 301 Section 3.2). The CBOR array is defined in Figure 3, and follows the 302 notation of [RFC8610]. These identifiers, together with other 303 information such as audience, can be used by the AS to determine the 304 shared secret bound to the proof-of-possession token and therefore 305 MUST identify a symmetric key that was previously generated by the AS 306 as a shared secret for the communication between the client and the 307 RS. The AS MUST verify that the received value identifies a proof- 308 of-possession key that has previously been issued to the requesting 309 client. If that is not the case, the Client-to-AS request MUST be 310 declined with the error code 'invalid_request' as defined in 311 Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 313 kid_arr = [ 314 clientId, 315 ?IdContext 316 ] 318 kid = bstr .cbor kid_arr 320 Figure 3: CDDL Notation of kid for Update of Access Rights 322 An example of such a request, with payload in CBOR diagnostic 323 notation without the tag and value abbreviations is reported in 324 Figure 4 326 Header: POST (Code=0.02) 327 Uri-Host: "as.example.com" 328 Uri-Path: "token" 329 Content-Format: "application/ace+cbor" 330 Payload: 331 { 332 "req_aud" : "tempSensor4711", 333 "scope" : "write", 334 "req_cnf" : { 335 "kid" : << ["myclient","contextid1"] >> 336 } 338 Figure 4: Example C-to-AS POST /token request for updating rights to 339 an access token bound to a symmetric key. 341 3.2. AS-to-C: Access Token 343 After verifying the POST request to the token endpoint and that the 344 client is authorized to obtain an access token corresponding to its 345 access token request, the AS responds as defined in section 5.6.2 of 346 [I-D.ietf-ace-oauth-authz]. If the client request was invalid, or 347 not authorized, the AS returns an error response as described in 348 section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 350 The AS can signal that the use of OSCORE is REQUIRED for a specific 351 access token by including the "profile" parameter with the value 352 "coap_oscore" in the access token response. This means that the 353 client MUST use OSCORE towards all resource servers for which this 354 access token is valid, and follow Section 4.3 to derive the security 355 context to run OSCORE. Usually it is assumed that constrained 356 devices will be pre-configured with the necessary profile, so that 357 this kind of profile negotiation can be omitted. 359 Moreover, the AS MUST send the following data: 361 o a master secret 363 o a server identifier 365 o a client identifier 367 Additionally, the AS MAY send the following data, in the same 368 response. 370 o a context identifier 372 o an AEAD algorithm 374 o an HKDF algorithm 376 o a salt 378 o the OSCORE version number 380 The OSCORE_Security_Context is a CBOR map object, defined in 381 Section 3.2.1. This object is transported in the 'cnf' parameter of 382 the access token response as defined in Section 3.2 of 383 [I-D.ietf-ace-oauth-params], as value of a field named 'osc' 384 registered in Section 9.5 and Section 9.6. The master secret MUST be 385 communicated as the 'ms' field in the 'osc' field in the 'cnf' 386 parameter of the access token response as defined in Section 3.2 of 387 [I-D.ietf-ace-oauth-params]. The AEAD algorithm may be included as 388 the 'alg' parameter in the OSCORE_Security_Context; the HKDF 389 algorithm may be included as the 'hkdf' parameter of the 390 OSCORE_Security_Context, a salt may be included as the 'salt' 391 parameter of the OSCORE_Security_Context, and the OSCORE version 392 number may be included as the 'version' parameter of the 393 OSCORE_Security_Context. 395 The same parameters MUST be included as part of the access token. 396 This profile RECOMMENDS the use of CBOR web token (CWT) as specified 397 in [RFC8392]. If the token is a CWT, the same 398 OSCORE_Security_Context structure defined above MUST be placed in the 399 'osc' field of the 'cnf' claim of this token. The access token MUST 400 be encrypted, since it will be transferred from the client to the RS 401 over an unprotected channel. 403 The AS MUST also assign an identifier to the RS (serverId), and to 404 the client (clientId), and MAY assign an identifier to the context 405 (contextId). These identifiers are then used as Sender ID, Recipient 406 ID and ID Context in the OSCORE context as described in section 3.1 407 of [RFC8613]. Applications need to consider that these identifiers 408 are sent in the clear and may reveal information about the endpoints, 409 as mentioned in section 12.8 of [RFC8613]. The pair (client 410 identifier, context identifier) MUST be unique in the set of all 411 clients for a single RS. Moreover, clientId, serverId and (when 412 assigned) contextId MUST be included in the OSCORE_Security_Context, 413 as defined in Section 3.2.1. 415 We assume in this document that a resource is associated to one 416 single AS, which makes it possible for the AS to enforce uniqueness 417 of identifiers for each client requesting a particular resource to a 418 RS. If this is not the case, collisions of identifiers may occur at 419 the RS, in which case the RS needs to have a mechanism in place to 420 disambiguate identifiers or mitigate the effect of the collisions. 422 Moreover, implementers of this specification need to be aware that if 423 other authentication mechanisms are used to set up OSCORE between the 424 same client and RS, that do not rely on AS assigning identifiers, 425 collisions may happen and need to be mitigated. 427 Note that in Section 4.3 C sets the Sender ID of its Security Context 428 to the clientId value received and the Recipient ID to the serverId 429 value, and RS does the opposite. 431 Figure 5 shows an example of an AS response, with payload in CBOR 432 diagnostic notation without the tag and value abbreviations. The 433 access token has been truncated for readability. 435 Header: Created (Code=2.01) 436 Content-Type: "application/ace+cbor" 437 Payload: 438 { 439 "access_token" : h'a5037674656d7053656e73 ... 440 (remainder of access token (CWT) omitted for brevity)', 441 "profile" : "coap_oscore", 442 "expires_in" : "3600", 443 "cnf" : { 444 "osc" : { 445 "alg" : "AES-CCM-16-64-128", 446 "clientId" : h'00', 447 "serverId" : h'01', 448 "ms" : h'f9af838368e353e78888e1426bd94e6f' 449 } 450 } 451 } 453 Figure 5: Example AS-to-C Access Token response with OSCORE profile. 455 Figure 6 shows an example CWT, containing the necessary OSCORE 456 parameters in the 'cnf' claim, in CBOR diagnostic notation without 457 tag and value abbreviations. 459 { 460 "aud" : "tempSensorInLivingRoom", 461 "iat" : "1360189224", 462 "exp" : "1360289224", 463 "scope" : "temperature_g firmware_p", 464 "cnf" : { 465 "osc" : { 466 "alg" : "AES-CCM-16-64-128", 467 "clientId" : h'00', 468 "serverId" : h'01', 469 "ms" : h'f9af838368e353e78888e1426bd94e6f' 470 } 471 } 473 Figure 6: Example CWT with OSCORE parameters. 475 The same CWT token as in Figure 6, using the value abbreviations 476 defined in [I-D.ietf-ace-oauth-authz] and 477 [I-D.ietf-ace-cwt-proof-of-possession] and encoded in CBOR is shown 478 in Figure 7. 480 NOTE TO THE RFC EDITOR: before publishing, it should be checked (and 481 in case fixed) that the values used below (which are not yet 482 registered) are the final values registered in IANA. 484 A5 # map(5) 485 03 # unsigned(3) 486 76 # text(22) 487 74656D7053656E736F72496E4C6976696E67526F6F6D 488 # "tempSensorInLivingRoom" 489 06 # unsigned(6) 490 1A 5112D728 # unsigned(1360189224) 491 04 # unsigned(4) 492 1A 51145DC8 # unsigned(1360289224) 493 09 # unsigned(9) 494 78 18 # text(24) 495 74656D70657261747572655F67206669726D776172655F70 496 # "temperature_g firmware_p" 497 08 # unsigned(8) 498 A1 # map(1) 499 04 # unsigned(4) 500 A4 # map(4) 501 05 # unsigned(5) 502 0A # unsigned(10) 503 02 # unsigned(2) 504 46 # bytes(6) 505 636C69656E74 # "client" 506 03 # unsigned(3) 507 46 # bytes(6) 508 736572766572 # "server" 509 01 # unsigned(1) 510 50 # bytes(16) 511 F9AF838368E353E78888E1426BD94E6F 512 # "\xF9\xAF\x83\x83h\xE3S\xE7 513 \x88\x88\xE1Bk\xD9No" 515 Figure 7: Example CWT with OSCORE parameters. 517 If the client has requested an update to its access rights using the 518 same OSCORE Security Context, which is valid and authorized, the AS 519 MUST omit the 'cnf' parameter in the response, and MUST carry the 520 client identifier and the context identifier (if it was set and 521 included in the initial access token response by the AS) in the 'kid' 522 field in the 'cnf' parameter of the token, with the same structure 523 defined in Figure 3. These identifiers need to be included in the 524 response, in order for the RS to identify the previously generated 525 Security Context. 527 Figure 8 shows an example of such an AS response, with payload in 528 CBOR diagnostic notation without the tag and value abbreviations. 529 The access token has been truncated for readability. 531 Header: Created (Code=2.01) 532 Content-Type: "application/ace+cbor" 533 Payload: 534 { 535 "access_token" : h'a5037674656d7053656e73 ... 536 (remainder of access token (CWT) omitted for brevity)', 537 "profile" : "coap_oscore", 538 "expires_in" : "3600" 539 } 541 Figure 8: Example AS-to-C Access Token response with OSCORE profile, 542 for update of access rights. 544 Figure 9 shows an example CWT, containing the necessary OSCORE 545 parameters in the 'cnf' claim for update of access rights, in CBOR 546 diagnostic notation without tag and value abbreviations. 548 { 549 "aud" : "tempSensorInLivingRoom", 550 "iat" : "1360189224", 551 "exp" : "1360289224", 552 "scope" : "temperature_h", 553 "cnf" : { 554 "kid" : h'43814100' 555 } 556 } 558 Figure 9: Example CWT with OSCORE parameters for update of access 559 rights. 561 3.2.1. OSCORE_Security_Context Object 563 An OSCORE_Security_Context is an object that represents part or all 564 of an OSCORE Security Context, i.e., the local set of information 565 elements necessary to carry out the cryptographic operations in 566 OSCORE (Section 3.1 of [RFC8613]). In particular, the 567 OSCORE_Security_Context object is defined to be serialized and 568 transported between nodes, as specified by this document, but can 569 also be used in this way by other specifications if needed. The 570 OSCORE_Security_Context object can either be encoded as a JSON object 571 or as a CBOR map. The set of common parameters that can appear in an 572 OSCORE_Security_Context object can be found in the IANA "OSCORE 573 Security Context Parameters" registry (Section 9.4), defined for 574 extensibility, and is specified below. All parameters are optional. 575 Table 1 provides a summary of the OSCORE_Security_Context parameters 576 defined in this section. 578 +-----------+-------+----------------+--------------+---------------+ 579 | name | CBOR | CBOR type | registry | description | 580 | | label | | | | 581 +-----------+-------+----------------+--------------+---------------+ 582 | version | 0 | int | | OSCORE | 583 | | | | | Version | 584 | | | | | | 585 | ms | 1 | bstr | | OSCORE Master | 586 | | | | | Secret value | 587 | | | | | | 588 | clientId | 2 | bstr | | OSCORE Sender | 589 | | | | | ID value of | 590 | | | | | the client, | 591 | | | | | OSCORE | 592 | | | | | Recipient ID | 593 | | | | | value of the | 594 | | | | | server | 595 | | | | | | 596 | serverId | 3 | bstr | | OSCORE Sender | 597 | | | | | ID value of | 598 | | | | | the server, | 599 | | | | | OSCORE | 600 | | | | | Recipient ID | 601 | | | | | value of the | 602 | | | | | client | 603 | | | | | | 604 | hkdf | 4 | tstr / int | COSE | OSCORE HKDF | 605 | | | | Algorithm | value | 606 | | | | Values | | 607 | | | | (HMAC-based) | | 608 | | | | | | 609 | alg | 5 | tstr / int | COSE | OSCORE AEAD | 610 | | | | Algorithm | Algorithm | 611 | | | | Values | value | 612 | | | | (AEAD) | | 613 | | | | | | 614 | salt | 6 | bstr | | OSCORE Master | 615 | | | | | Salt value | 616 | | | | | | 617 | contextId | 7 | bstr | | OSCORE ID | 618 | | | | | Context value | 619 +-----------+-------+----------------+--------------+---------------+ 621 Table 1: OSCORE_Security_Context Parameters 623 version: This parameter identifies the OSCORE Version number, which 624 is an int. For more information about this field, see section 5.4 625 of [RFC8613]. In JSON, the "version" value is an integer. In 626 CBOR, the "version" type is int, and has label 0. 628 ms: This parameter identifies the OSCORE Master Secret value, which 629 is a byte string. For more information about this field, see 630 section 3.1 of [RFC8613]. In JSON, the "ms" value is a Base64 631 encoded byte string. In CBOR, the "ms" type is bstr, and has 632 label 1. 634 clientId: This parameter identifies a client identifier as a byte 635 string. This identifier is used as OSCORE Sender ID in the client 636 and OSCORE Recipient ID in the server. For more information about 637 this field, see section 3.1 of [RFC8613]. In JSON, the "clientId" 638 value is a Base64 encoded byte string. In CBOR, the "clientId" 639 type is bstr, and has label 2. 641 serverId: This parameter identifies a server identifier as a byte 642 string. This identifier is used as OSCORE Sender ID in the server 643 and OSCORE Recipient ID in the client. For more information about 644 this field, see section 3.1 of [RFC8613]. In JSON, the "serverId" 645 value is a Base64 encoded byte string. In CBOR, the "serverId" 646 type is bstr, and has label 3. 648 hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more 649 information about this field, see section 3.1 of [RFC8613]. The 650 values used MUST be registered in the IANA "COSE Algorithms" 651 registry and MUST be HMAC-based HKDF algorithms. The value can 652 either be the integer or the text string value of the HMAC-based 653 HKDF algorithm in the "COSE Algorithms" registry. In JSON, the 654 "hkdf" value is a case-sensitive ASCII string or an integer. In 655 CBOR, the "hkdf" type is tstr or int, and has label 4. 657 alg: This parameter identifies the OSCORE AEAD Algorithm. For more 658 information about this field, see section 3.1 of [RFC8613] The 659 values used MUST be registered in the IANA "COSE Algorithms" 660 registry and MUST be AEAD algorithms. The value can either be the 661 integer or the text string value of the HMAC-based HKDF algorithm 662 in the "COSE Algorithms" registry. In JSON, the "alg" value is a 663 case-sensitive ASCII string or an integer. In CBOR, the "alg" 664 type is tstr or int, and has label 5. 666 salt: This parameter identifies the OSCORE Master Salt value, which 667 is a byte string. For more information about this field, see 668 section 3.1 of [RFC8613]. In JSON, the "salt" value is a Base64 669 encoded byte string. In CBOR, the "salt" type is bstr, and has 670 label 6. 672 contextId: This parameter identifies the security context as a byte 673 string. This identifier is used as OSCORE ID Context. For more 674 information about this field, see section 3.1 of [RFC8613]. In 675 JSON, the "contextID" value is a Base64 encoded byte string. In 676 CBOR, the "contextID" type is bstr, and has label 7. 678 An example of JSON OSCORE_Security_Context is given in Figure 10. 680 "osc" : { 681 "alg" : "AES-CCM-16-64-128", 682 "clientId" : b64'AA', 683 "serverId" : b64'AQ', 684 "ms" : b64'+a+Dg2jjU+eIiOFCa9lObw' 685 } 687 Figure 10: Example JSON OSCORE_Security_Context object 689 The CDDL grammar describing the CBOR OSCORE_Security_Context object 690 is: 692 OSCORE_Security_Context = { 693 ? 0 => int, ; version 694 ? 1 => bstr, ; ms 695 ? 2 => bstr, ; clientId 696 ? 3 => bstr, ; serverId 697 ? 4 => tstr / int, ; hkdf 698 ? 5 => tstr / int, ; alg 699 ? 6 => bstr, ; salt 700 ? 7 => bstr, ; contextId 701 * int / tstr => any 702 } 704 4. Client-RS Communication 706 The following subsections describe the details of the POST request 707 and response to the authz-info endpoint between client and RS. The 708 client generates a nonce N1, and posts it together with the token 709 that includes the materials (e.g., OSCORE parameters) received from 710 the AS to the RS. The RS then generates a nonce N2, and use 711 Section 3.2 of [RFC8613] to derive a security context based on a 712 shared master secret and the two nonces, established between client 713 and server. The nonces are encoded as CBOR bstr if CBOR is used, and 714 as Base64 string if JSON is used. This security context is used to 715 protect all future communication between client and RS using OSCORE, 716 as long as the access token is valid. 718 Note that the RS and client authenticates themselves by generating 719 the shared OSCORE Security Context using the pop-key as master 720 secret. An attacker posting a valid token to the RS will not be able 721 to generate a valid OSCORE context and thus not be able to prove 722 possession of the pop-key. 724 4.1. C-to-RS: POST to authz-info endpoint 726 The client MUST generate a nonce value very unlikely to have been 727 previously used with the same input keying material. This profile 728 RECOMMENDS to use a 64-bit long random number as nonce's value. The 729 client MUST store the nonce N1 as long as the response from the RS is 730 not received and the access token related to it is still valid. The 731 client MUST use CoAP and the Authorization Information resource as 732 described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to transport 733 the token and N1 to the RS. 735 Note that the use of the payload and the Content-Format is different 736 from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz], 737 which only transports the token without any CBOR wrapping. In this 738 profile, the client MUST wrap the token and N1 in a CBOR map. The 739 client MUST use the Content-Format "application/ace+cbor" defined in 740 section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include 741 the access token using the correct CBOR label (e.g., "cwt" for CWT, 742 "jwt" for JWT) and N1 using the 'nonce1' parameter defined in 743 Section 4.1.1. 745 The authz-info endpoint is not protected, nor are the responses from 746 this resource. 748 The access token MUST be encrypted, since it is transferred from the 749 client to the RS over an unprotected channel. 751 Note that a client may be required to re-POST the access token in 752 order to complete a request, since an RS may delete a stored access 753 token at any time, for example due to all storage space being 754 consumed. This situation is detected by the client when it receives 755 an AS Request Creation Hints response. 757 Figure 11 shows an example of the request sent from the client to the 758 RS, with payload in CBOR diagnostic notation without the tag and 759 value abbreviations. The access token has been truncated for 760 readability. 762 Header: POST (Code=0.02) 763 Uri-Host: "rs.example.com" 764 Uri-Path: "authz-info" 765 Content-Format: "application/ace+cbor" 766 Payload: 767 { 768 "access_token": h'a5037674656d7053656e73 ... 769 (remainder of access token (CWT) omitted for brevity)', 770 "nonce1": h'018a278f7faab55a' 771 } 773 Figure 11: Example C-to-RS POST /authz-info request using CWT 775 4.1.1. The Nonce 1 Parameter 777 This parameter MUST be sent from the client to the RS, together with 778 the access token, if the ace profile used is coap_oscore. The 779 parameter is encoded as a byte string for CBOR-based interactions, 780 and as a string (Base64 encoded binary) for JSON-based interactions. 781 This parameter is registered in Section 9.2. 783 4.2. RS-to-C: 2.01 (Created) 785 The RS MUST follow the procedures defined in section 5.8.1 of 786 [I-D.ietf-ace-oauth-authz]: the RS must verify the validity of the 787 token. If the token is valid, the RS must respond to the POST 788 request with 2.01 (Created). If the token is valid but is associated 789 to claims that the RS cannot process (e.g., an unknown scope), or if 790 any of the expected parameters in the 'osc' is missing (e.g., any of 791 the mandatory parameters from the AS), or if any parameters received 792 in the 'osc' is unrecognized, the RS must respond with an error 793 response code equivalent to the CoAP code 4.00 (Bad Request). In the 794 latter two cases, the RS may provide additional information in the 795 error response, in order to clarify what went wrong. The RS may make 796 an introspection request to validate the token before responding to 797 the POST request to the authz-info endpoint. 799 Additionally, the RS MUST generate a nonce N2 very unlikely to have 800 been previously used with the same input keying material, and send it 801 within the 2.01 (Created) response. The payload of the 2.01 802 (Created) response MUST be a CBOR map containing the 'nonce2' 803 parameter defined in Section 4.2.1, set to N2. This profile 804 RECOMMENDS to use a 64-bit long random number as nonce's value. The 805 RS MUST use the Content-Format "application/ace+cbor" defined in 806 section 8.14 of [I-D.ietf-ace-oauth-authz]. 808 Figure 12 shows an example of the response sent from the RS to the 809 client, with payload in CBOR diagnostic notation without the tag and 810 value abbreviations. 812 Header: Created (Code=2.01) 813 Content-Format: "application/ace+cbor" 814 Payload: 815 { 816 "nonce2": h'25a8991cd700ac01' 817 } 819 Figure 12: Example RS-to-C 2.01 (Created) response 821 As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when 822 receiving an updated access token with updated authorization 823 information from the client (see Section 3.1), it is recommended that 824 the RS overwrites the previous token, that is only the latest 825 authorization information in the token received by the RS is valid. 826 This simplifies for the RS to keep track of authorization information 827 for a given client. 829 As specified in section 5.8.3 of [I-D.ietf-ace-oauth-authz], the RS 830 must notify the client with an error response with code 4.01 831 (Unauthorized) for any long running request before terminating the 832 session, when the access token expires. 834 4.2.1. The Nonce 2 Parameter 836 This parameter MUST be sent from the RS to the Client if the ace 837 profile used is coap_oscore. The parameter is encoded as a byte 838 string for CBOR-based interactions, and as a string (Base64 encoded 839 binary) for JSON-based interactions. This parameter is registered in 840 Section 9.2 842 4.3. OSCORE Setup 844 Once receiving the 2.01 (Created) response from the RS, following the 845 POST request to authz-info endpoint, the client MUST extract the CBOR 846 bstr nonce N2 from the 'nonce2' parameter in the CBOR map in the 847 payload of the response. Then, the client MUST set the Master Salt 848 of the Security Context created to communicate with the RS to the 849 concatenation of salt, N1, and N2, in this order: Master Salt = 850 salt | N1 | N2, where | denotes byte string concatenation, where salt 851 was received from the AS in Section 3.2, and where N1 and N2 are the 852 two nonces encoded as CBOR bstr. The client MUST set the Master 853 Secret, Sender ID and Recipient ID from the parameters received from 854 the AS in Section 3.2. The client MUST set the AEAD Algorithm, ID 855 Context, HKDF, and OSCORE Version from the parameters received from 856 the AS in Section 3.2, if present. In case these parameters are 857 omitted, the default values are used as described in sections 3.2 and 858 5.4 of [RFC8613]. After that, the client MUST derive the complete 859 Security Context following section 3.2.1 of [RFC8613]. From this 860 point on, the client MUST use this Security Context to communicate 861 with the RS when accessing the resources as specified by the 862 authorization information. 864 If any of the expected parameters is missing (e.g., any of the 865 mandatory parameters from the AS, the client MUST stop the exchange, 866 and MUST NOT derive the Security Context. The client MAY restart the 867 exchange, to get the correct security material. 869 The client then uses this Security Context to send requests to RS 870 using OSCORE. 872 After sending the 2.01 (Created) response, the RS MUST set the Master 873 Salt of the Security Context created to communicate with the client 874 to the concatenation of salt, N1, and N2, in this order: Master Salt 875 = salt | N1 | N2, where | denotes byte string concatenation, where 876 salt was received from the AS in Section 4.2, and where N1 and N2 are 877 the two nonces encoded as CBOR bstr. The RS MUST set the Master 878 Secret, Sender ID and Recipient ID from the parameters, received from 879 the AS and forwarded by the client in the access token in Section 4.1 880 after validation of the token as specified in Section 4.2. The RS 881 MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE Version 882 from the parameters received from the AS and forwarded by the client 883 in the access token in Section 4.1 after validation of the token as 884 specified in Section 4.2, if present. In case these parameters are 885 omitted, the default values are used as described in sections 3.2 and 886 5.4 of [RFC8613]. After that, the RS MUST derive the complete 887 Security Context following section 3.2.1 of [RFC8613], and MUST 888 associate this Security Context with the authorization information 889 from the access token. 891 The RS then uses this Security Context to verify requests and send 892 responses to C using OSCORE. If OSCORE verification fails, error 893 responses are used, as specified in section 8 of [RFC8613]. 894 Additionally, if OSCORE verification succeeds, the verification of 895 access rights is performed as described in section Section 4.4. The 896 RS MUST NOT use the Security Context after the related token has 897 expired, and MUST respond with a unprotected 4.01 (Unauthorized) 898 error message to requests received that correspond to a Security 899 Context with an expired token. 901 If the exchange was an update of access rights, i.e., a new Security 902 Context was derived from a client that already had a Security Context 903 in place, the RS is RECOMMENDED to delete the old Security Context 904 after OSCORE verification and verification of access rights succeed. 905 The RS MUST delete the Security Context if it deletes the access 906 token associated to it. 908 4.4. Access rights verification 910 The RS MUST follow the procedures defined in section 5.8.2 of 911 [I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected 912 request from a client, then the RS processes it according to 913 [RFC8613]. If OSCORE verification succeeds, and the target resource 914 requires authorization, the RS retrieves the authorization 915 information using the access token associated to the Security 916 Context. The RS then must verify that the authorization information 917 covers the resource and the action requested. 919 The response code must be 4.01 (Unauthorized) in case the client has 920 a valid token associated with that Security Context, but the Security 921 Context has not been used before, as the proof-of-possession in this 922 profile is performed by both parties verifying that they have 923 established the same Security Context. 925 5. Secure Communication with AS 927 As specified in the ACE framework (section 5.7 of 928 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) 929 and the AS communicates via the introspection or token endpoint. The 930 use of CoAP and OSCORE ([RFC8613]) for this communication is 931 RECOMMENDED in this profile, other protocols (such as HTTP and DTLS 932 or TLS) MAY be used instead. 934 If OSCORE is used, the requesting entity and the AS are expected to 935 have pre-established security contexts in place. How these security 936 contexts are established is out of scope for this profile. 937 Furthermore the requesting entity and the AS communicate through the 938 introspection endpoint as specified in section 5.7 of 939 [I-D.ietf-ace-oauth-authz] and through the token endpoint as 940 specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. 942 6. Discarding the Security Context 944 There are a number of scenarios where a client or RS needs to discard 945 the OSCORE security context, and acquire a new one. 947 The client MUST discard the current security context associated with 948 an RS when: 950 o the Sequence Number space ends. 952 o the access token associated with the context expires. 954 o the client receives a number of 4.01 Unauthorized responses to 955 OSCORE requests using the same security context. The exact number 956 needs to be specified by the application. 958 o the client receives a new nonce in the 2.01 (Created) response 959 (see Section 4.2) to a POST request to the authz-info endpoint, 960 when re-posting a (non-expired) token associated to the existing 961 context. 963 The RS MUST discard the current security context associated with a 964 client when: 966 o the Sequence Number space ends. 968 o the access token associated with the context expires. 970 7. Security Considerations 972 This document specifies a profile for the Authentication and 973 Authorization for Constrained Environments (ACE) framework 974 [I-D.ietf-ace-oauth-authz]. Thus the general security considerations 975 from the framework also apply to this profile. 977 Furthermore the general security considerations of OSCORE [RFC8613] 978 also apply to this specific use of the OSCORE protocol. 980 OSCORE is designed to secure point-to-point communication, providing 981 a secure binding between the request and the response(s). Thus the 982 basic OSCORE protocol is not intended for use in point-to-multipoint 983 communication (e.g., multicast, publish-subscribe). Implementers of 984 this profile should make sure that their usecase corresponds to the 985 expected use of OSCORE, to prevent weakening the security assurances 986 provided by OSCORE. 988 Since the use of nonces in the exchange guarantees uniqueness of AEAD 989 keys and nonces, it is REQUIRED that nonces are not reused with the 990 same input keying material even in case of re-boots. This document 991 RECOMMENDS the use of 64 bit random nonces. Considering the birthday 992 paradox, the average collision for each nonce will happen after 2^32 993 messages, which is considerably more token provisionings than 994 expected for intended applications. If applications use something 995 else, such as a counter, they need to guarantee that reboot and loss 996 of state on either node does not provoke re-use. If that is not 997 guaranteed, nodes are susceptible to re-use of AEAD (nonces, keys) 998 pairs, especially since an on-path attacker can cause the client to 999 use an arbitrary nonce for Security Context establishment by 1000 replaying client-to-server messages. 1002 This profile recommends that the RS maintains a single access token 1003 for a client. The use of multiple access tokens for a single client 1004 increases the strain on the resource server as it must consider every 1005 access token and calculate the actual permissions of the client. 1006 Also, tokens indicating different or disjoint permissions from each 1007 other may lead the server to enforce wrong permissions. If one of 1008 the access tokens expires earlier than others, the resulting 1009 permissions may offer insufficient protection. Developers should 1010 avoid using multiple access tokens for a client. 1012 8. Privacy Considerations 1014 This document specifies a profile for the Authentication and 1015 Authorization for Constrained Environments (ACE) framework 1016 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 1017 from the framework also apply to this profile. 1019 As this document uses OSCORE, thus the privacy considerations from 1020 [RFC8613] apply here as well. 1022 An unprotected response to an unauthorized request may disclose 1023 information about the resource server and/or its existing 1024 relationship with the client. It is advisable to include as little 1025 information as possible in an unencrypted response. When an OSCORE 1026 Security Context already exists between the client and the resource 1027 server, more detailed information may be included. 1029 Although encrypted, the token is sent in the clear to the authz-info 1030 endpoint, so if a client uses the same single token from multiple 1031 locations with multiple Resource Servers, it can risk being tracked 1032 by the token's value. 1034 The nonces exchanged in the request and response to the authz-info 1035 endpoint are also sent in the clear, so using random nonces is best 1036 for privacy (as opposed to, e.g., a counter, that might leak some 1037 information about the client). 1039 The AS is the party tasked of assigning the identifiers used in 1040 OSCORE, which are privacy sensitive (see Section 12.8 of [RFC8613]), 1041 and which could reveal information about the client, or may be used 1042 for correlating requests from one client. 1044 Note that some information might still leak after OSCORE is 1045 established, due to observable message sizes, the source, and the 1046 destination addresses. 1048 9. IANA Considerations 1050 Note to RFC Editor: Please replace all occurrences of "[[this 1051 specification]]" with the RFC number of this specification and delete 1052 this paragraph. 1054 9.1. ACE OAuth Profile Registry 1056 The following registration is done for the ACE OAuth Profile Registry 1057 following the procedure specified in section 8.7 of 1058 [I-D.ietf-ace-oauth-authz]: 1060 o Profile name: coap_oscore 1061 o Profile Description: Profile for using OSCORE to secure 1062 communication between constrained nodes using the Authentication 1063 and Authorization for Constrained Environments framework. 1064 o Profile ID: TBD (value between 1 and 255) 1065 o Change Controller: IESG 1066 o Specification Document(s): [[this specification]] 1068 9.2. OAuth Parameters Registry 1070 The following registrations are done for the OAuth Parameters 1071 Registry following the procedure specified in section 11.2 of 1072 [RFC6749]: 1074 o Parameter name: nonce1 1075 o Parameter usage location: token request 1076 o Change Controller: IESG 1077 o Specification Document(s): [[this specification]] 1079 o Parameter name: nonce2 1080 o Parameter usage location: token response 1081 o Change Controller: IESG 1082 o Specification Document(s): [[this specification]] 1084 9.3. OAuth Parameters CBOR Mappings Registry 1086 The following registrations are done for the OAuth Parameters CBOR 1087 Mappings Registry following the procedure specified in section 8.9 of 1088 [I-D.ietf-ace-oauth-authz]: 1090 o Name: nonce1 1091 o CBOR Key: TBD1 1092 o Value Type: bstr 1093 o Reference: [[this specification]] 1095 o Name: nonce2 1096 o CBOR Key: TBD2 1097 o Value Type: IESG 1098 o Reference: [[this specification]] 1100 9.4. OSCORE Security Context Parameters Registry 1102 It is requested that IANA create a new registry entitled "OSCORE 1103 Security Context Parameters" registry. The registry is to be created 1104 as Expert Review Required. Guidelines for the experts is provided 1105 Section 9.7. It should be noted that in addition to the expert 1106 review, some portions of the registry require a specification, 1107 potentially on standards track, be supplied as well. 1109 The columns of the registry are: 1111 name The JSON name requested (e.g., "ms"). Because a core goal of 1112 this specification is for the resulting representations to be 1113 compact, it is RECOMMENDED that the name be short. This name is 1114 case sensitive. Names may not match other registered names in a 1115 case-insensitive manner unless the Designated Experts determine 1116 that there is a compelling reason to allow an exception. The name 1117 is not used in the CBOR encoding. 1118 CBOR label The value to be used to identify this algorithm. Map key 1119 labels MUST be unique. The label can be a positive integer, a 1120 negative integer or a string. Integer values between -256 and 255 1121 and strings of length 1 are designated as Standards Track Document 1122 required. Integer values from -65536 to -257 and from 256 to 1123 65535 and strings of length 2 are designated as Specification 1124 Required. Integer values greater than 65535 and strings of length 1125 greater than 2 are designated as expert review. Integer values 1126 less than -65536 are marked as private use. 1127 CBOR Type This field contains the CBOR type for the field. 1128 registry This field denotes the registry that values may come from, 1129 if one exists. 1130 description This field contains a brief description for the field. 1131 specification This contains a pointer to the public specification 1132 for the field if one exists 1134 This registry will be initially populated by the values in Table 1. 1135 The specification column for all of these entries will be this 1136 document and [RFC8613]. 1138 9.5. CWT Confirmation Methods Registry 1140 The following registration is done for the CWT Confirmation Methods 1141 Registry following the procedure specified in section 7.2.1 of 1142 [I-D.ietf-ace-cwt-proof-of-possession]: 1144 o Confirmation Method Name: "osc" 1145 o Confirmation Method Description: OSCORE_Security_Context carrying 1146 the parameters for using OSCORE per-message security with implicit 1147 key confirmation 1148 o Confirmation Key: TBD (value between 4 and 255) 1149 o Confirmation Value Type(s): map 1150 o Change Controller: IESG 1151 o Specification Document(s): Section 3.2.1 of [[this specification]] 1153 9.6. JWT Confirmation Methods Registry 1155 The following registration is done for the JWT Confirmation Methods 1156 Registry following the procedure specified in section 6.2.1 of 1157 [RFC7800]: 1159 o Confirmation Method Value: "osc" 1160 o Confirmation Method Description: OSCORE_Security_Context carrying 1161 the parameters for using OSCORE per-message security with implicit 1162 key confirmation 1163 o Change Controller: IESG 1164 o Specification Document(s): Section 3.2.1 of [[this specification]] 1166 9.7. Expert Review Instructions 1168 The IANA registry established in this document is defined to use the 1169 Expert Review registration policy. This section gives some general 1170 guidelines for what the experts should be looking for, but they are 1171 being designated as experts for a reason so they should be given 1172 substantial latitude. 1174 Expert reviewers should take into consideration the following points: 1176 o Point squatting should be discouraged. Reviewers are encouraged 1177 to get sufficient information for registration requests to ensure 1178 that the usage is not going to duplicate one that is already 1179 registered and that the point is likely to be used in deployments. 1180 The zones tagged as private use are intended for testing purposes 1181 and closed environments. Code points in other ranges should not 1182 be assigned for testing. 1183 o Specifications are required for the standards track range of point 1184 assignment. Specifications should exist for specification 1185 required ranges, but early assignment before a specification is 1186 available is considered to be permissible. Specifications are 1187 needed for the first-come, first-serve range if they are expected 1188 to be used outside of closed environments in an interoperable way. 1189 When specifications are not provided, the description provided 1190 needs to have sufficient information to identify what the point is 1191 being used for. 1193 o Experts should take into account the expected usage of fields when 1194 approving point assignment. The fact that there is a range for 1195 standards track documents does not mean that a standards track 1196 document cannot have points assigned outside of that range. The 1197 length of the encoded value should be weighed against how many 1198 code points of that length are left, the size of device it will be 1199 used on, and the number of code points left that encode to that 1200 size. 1202 10. References 1204 10.1. Normative References 1206 [I-D.ietf-ace-oauth-authz] 1207 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1208 H. Tschofenig, "Authentication and Authorization for 1209 Constrained Environments (ACE) using the OAuth 2.0 1210 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 1211 (work in progress), February 2020. 1213 [I-D.ietf-ace-oauth-params] 1214 Seitz, L., "Additional OAuth Parameters for Authorization 1215 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1216 params-12 (work in progress), February 2020. 1218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1219 Requirement Levels", BCP 14, RFC 2119, 1220 DOI 10.17487/RFC2119, March 1997, 1221 . 1223 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1224 Application Protocol (CoAP)", RFC 7252, 1225 DOI 10.17487/RFC7252, June 2014, 1226 . 1228 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1229 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1230 . 1232 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1233 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1234 May 2017, . 1236 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1237 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1238 May 2018, . 1240 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1241 Definition Language (CDDL): A Notational Convention to 1242 Express Concise Binary Object Representation (CBOR) and 1243 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1244 June 2019, . 1246 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1247 "Object Security for Constrained RESTful Environments 1248 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1249 . 1251 10.2. Informative References 1253 [I-D.ietf-ace-cwt-proof-of-possession] 1254 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1255 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1256 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1257 possession-11 (work in progress), October 2019. 1259 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1260 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1261 . 1263 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1264 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1265 . 1267 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1268 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1269 DOI 10.17487/RFC7231, June 2014, 1270 . 1272 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1273 Possession Key Semantics for JSON Web Tokens (JWTs)", 1274 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1275 . 1277 Appendix A. Profile Requirements 1279 This section lists the specifications on this profile based on the 1280 requirements on the framework, as requested in Appendix C of 1281 [I-D.ietf-ace-oauth-authz]. 1283 o Optionally define new methods for the client to discover the 1284 necessary permissions and AS for accessing a resource, different 1285 from the one proposed in: Not specified 1286 o Optionally specify new grant types: Not specified 1287 o Optionally define the use of client certificates as client 1288 credential type: Not specified 1289 o Specify the communication protocol the client and RS the must use: 1290 CoAP 1291 o Specify the security protocol the client and RS must use to 1292 protect their communication: OSCORE 1293 o Specify how the client and the RS mutually authenticate: 1294 Implicitly by possession of a common OSCORE security context 1295 o Specify the proof-of-possession protocol(s) and how to select one, 1296 if several are available. Also specify which key types (e.g., 1297 symmetric/asymmetric) are supported by a specific proof-of- 1298 possession protocol: OSCORE algorithms; pre-established symmetric 1299 keys 1300 o Specify a unique ace_profile identifier: coap_oscore 1301 o If introspection is supported: Specify the communication and 1302 security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE) 1303 o Specify the communication and security protocol for interactions 1304 between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE) 1305 o Specify how/if the authz-info endpoint is protected, including how 1306 error responses are protected: Not protected. 1307 o Optionally define other methods of token transport than the authz- 1308 info endpoint: Not defined 1310 Acknowledgments 1312 The authors wish to thank Jim Schaad and Marco Tiloca for the input 1313 on this memo. Special thanks to the responsible area director Ben 1314 Kaduk for his extensive review and contributed text. 1316 Authors' Addresses 1318 Francesca Palombini 1319 Ericsson AB 1321 Email: francesca.palombini@ericsson.com 1323 Ludwig Seitz 1324 Combitech 1325 Djaeknegatan 31 1326 Malmoe 211 35 1327 Sweden 1329 Email: ludwig.seitz@combitech.se 1330 Goeran Selander 1331 Ericsson AB 1333 Email: goran.selander@ericsson.com 1335 Martin Gunnarsson 1336 RISE 1337 Scheelevagen 17 1338 Lund 22370 1339 Sweden 1341 Email: martin.gunnarsson@ri.se