idnits 2.17.1 draft-ietf-ace-dtls-authorize-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 06, 2018) is 2052 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 748 -- Looks like a reference, but probably isn't: '2' on line 751 -- Looks like a reference, but probably isn't: '3' on line 754 -- Looks like a reference, but probably isn't: '4' on line 757 -- Looks like a reference, but probably isn't: '5' on line 759 -- Looks like a reference, but probably isn't: '6' on line 762 -- Looks like a reference, but probably isn't: '7' on line 765 -- Looks like a reference, but probably isn't: '8' on line 768 -- Looks like a reference, but probably isn't: '9' on line 771 -- Looks like a reference, but probably isn't: '10' on line 774 -- Looks like a reference, but probably isn't: '11' on line 777 -- Looks like a reference, but probably isn't: '12' on line 780 -- Looks like a reference, but probably isn't: '13' on line 782 == Missing Reference: 'RFC-XXXX' is mentioned on line 652, but not defined == Unused Reference: 'RFC5746' is defined on line 681, but no explicit reference was found in the text == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-13 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Gerdes 3 Internet-Draft O. Bergmann 4 Intended status: Standards Track C. Bormann 5 Expires: March 10, 2019 Universitaet Bremen TZI 6 G. Selander 7 Ericsson 8 L. Seitz 9 RISE SICS 10 September 06, 2018 12 Datagram Transport Layer Security (DTLS) Profile for Authentication and 13 Authorization for Constrained Environments (ACE) 14 draft-ietf-ace-dtls-authorize-04 16 Abstract 18 This specification defines a profile for delegating client 19 authentication and authorization in a constrained environment by 20 establishing a Datagram Transport Layer Security (DTLS) channel 21 between resource-constrained nodes. The protocol relies on DTLS for 22 communication security between entities in a constrained network 23 using either raw public keys or pre-shared keys. A resource- 24 constrained node can use this protocol to delegate management of 25 authorization information to a trusted host with less severe 26 limitations regarding processing power and memory. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 10, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Resource Access . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Dynamic Update of Authorization Information . . . . . . . 7 67 2.3. Token Expiration . . . . . . . . . . . . . . . . . . . . 8 68 3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 9 69 4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 12 71 4.2. Updating Authorization Information . . . . . . . . . . . 13 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 8.2. Informative References . . . . . . . . . . . . . . . . . 16 78 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 This specification defines a profile of the ACE framework 84 [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource 85 server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The 86 client uses an access token, bound to a key (the proof-of-possession 87 key) to authorize its access to protected resources hosted by the 88 resource server. DTLS provides communication security, proof of 89 possession, and server authentication. Optionally the client and the 90 resource server may also use CoAP over DTLS to communicate with the 91 authorization server. This specification supports the DTLS handshake 92 with Raw Public Keys (RPK) [RFC7250] and the DTLS handshake with Pre- 93 Shared Keys (PSK) [RFC4279]. 95 The DTLS RPK handshake [RFC7250] requires client authentication to 96 provide proof-of-possession for the key tied to the access token. 97 Here the access token needs to be transferred to the resource server 98 before the handshake is initiated, as described in section 5.8.1 of 99 draft-ietf-ace-oauth-authz [1]. 101 The DTLS PSK handshake [RFC4279] provides the proof-of-possession for 102 the key tied to the access token. Furthermore the psk_identity 103 parameter in the DTLS PSK handshake is used to transfer the access 104 token from the client to the resource server. 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 Readers are expected to be familiar with the terms and concepts 115 described in [I-D.ietf-ace-oauth-authz]. 117 2. Protocol Overview 119 The CoAP-DTLS profile for ACE specifies the transfer of 120 authentication and, if necessary, authorization information between 121 the client C and the resource server RS during setup of a DTLS 122 session for CoAP messaging. It also specifies how a Client can use 123 CoAP over DTLS to retrieve an Access Token from the authorization 124 server AS for a protected resource hosted on the resource server RS. 126 This profile requires a Client (C) to retrieve an Access Token for 127 the resource(s) it wants to access on a Resource Server (RS) as 128 specified in [I-D.ietf-ace-oauth-authz]. Figure 1 shows the typical 129 message flow in this scenario (messages in square brackets are 130 optional): 132 C RS AS 133 | [-- Resource Request --->] | | 134 | | | 135 | [<----- AS Information --] | | 136 | | | 137 | --- Token Request ----------------------------> | 138 | | | 139 | <---------------------------- Access Token ----- | 140 | + RS Information | 142 Figure 1: Retrieving an Access Token 144 To determine the AS in charge of a resource hosted at the RS, the 145 client C MAY send an initial Unauthorized Resource Request message to 146 the RS. The RS then denies the request and sends the address of its 147 AS back to the client C as specified in section 5.1.2 of draft-ietf- 148 ace-oauth-authz [2]. 150 Once the client C knows the authorization server's address, it can 151 send an Access Token request to the token endpoint at the AS as 152 specified in [I-D.ietf-ace-oauth-authz]. As the Access Token request 153 as well as the response may contain confidential data, the 154 communication between the client and the authorization server MUST be 155 confidentiality-protected and ensure authenticity. How the mutual 156 authentication between the client and the authorization server is 157 achieved is out of scope for this document; the client may have been 158 configured with a public key of the authorization server and have 159 been registered at the AS via the OAuth client registration mechanism 160 as outlined in section 5.3 of draft-ietf-ace-oauth-authz [3]. 162 If C wants to use the CoAP RawPublicKey mode as described in 163 Section 9 of RFC 7252 [4] it MUST provide a key or key identifier 164 within a "cnf" object in the token request. If the authorization 165 server AS decides that the request is to be authorized it generates 166 an access token response for the client C containing a "profile" 167 parameter with the value "coap_dtls" to indicate that this profile 168 MUST be used for communication between the client C and the resource 169 server. 171 For RPK mode, the authorization server also adds a "rs_cnf" parameter 172 containing information about the public that is used by the resource 173 server (see Section 3). 175 For PSK mode, the authorization server adds a "cnf" parameter 176 containing information about the shared secret that C can use to 177 setup a DTLS session with the resource server (see Section 4). 179 The Access Token returned by the authorization server then can be 180 used by the client to establish a new DTLS session with the resource 181 server. When the client intends to use asymmetric cryptography in 182 the DTLS handshake with the resource server, the client MUST upload 183 the Access Token to the authz-info resource on the resource server 184 before starting the DTLS handshake, as described in section 5.8.1 of 185 draft-ietf-ace-oauth-authz [5]. If only symmetric cryptography is 186 used between the client and the resource server, the Access Token MAY 187 instead be transferred in the DTLS ClientKeyExchange message (see 188 Section 4.1). 190 Figure 2 depicts the common protocol flow for the DTLS profile after 191 the client C has retrieved the Access Token from the authorization 192 server AS. 194 C RS AS 195 | [--- Access Token ------>] | | 196 | | | 197 | <== DTLS channel setup ==> | | 198 | | | 199 | == Authorized Request ===> | | 200 | | | 201 | <=== Protected Resource == | | 203 Figure 2: Protocol overview 205 The following sections specify how CoAP is used to interchange 206 access-related data between the resource server and the authorization 207 server so that the authorization server can provide the client and 208 the resource server with sufficient information to establish a secure 209 channel, and convey authorization information specific for this 210 communication relationship to the resource server. 212 Depending on the desired CoAP security mode, the Client-to-AS 213 request, AS-to-Client response and DTLS session establishment carry 214 slightly different information. Section 3 addresses the use of raw 215 public keys while Section 4 defines how pre-shared keys are used in 216 this profile. 218 2.1. Resource Access 220 Once a DTLS channel has been established as described in Section 3 221 and Section 4, respectively, the client is authorized to access 222 resources covered by the Access Token it has uploaded to the authz- 223 info resource hosted by the resource server. 225 On the resource server side, successful establishment of the DTLS 226 channel binds the client to the access token, functioning as a proof- 227 of-possession associated key. Any request that the resource server 228 receives on this channel MUST be checked against these authorization 229 rules that are associated with the identity of the client. Incoming 230 CoAP requests that are not authorized with respect to any Access 231 Token that is associated with the client MUST be rejected by the 232 resource server with 4.01 response as described in Section 5.1.1 of 233 draft-ietf-ace-oauth-authz [6]. 235 Note: The identity of the client is determined by the authentication 236 process 237 during the DTLS handshake. In the asymmetric case, the public key 238 will define the client's identity, while in the PSK case, the 239 client's identity is defined by the shared secret generated by the 240 authorization server for this communication. 242 The resource server SHOULD treat an incoming CoAP request as 243 authorized if the following holds: 245 1. The message was received on a secure channel that has been 246 established using the procedure defined in this document. 248 2. The authorization information tied to the sending peer is valid. 250 3. The request is destined for the resource server. 252 4. The resource URI specified in the request is covered by the 253 authorization information. 255 5. The request method is an authorized action on the resource with 256 respect to the authorization information. 258 Incoming CoAP requests received on a secure DTLS channel MUST be 259 rejected according to [Section 5.1.1 of draft-ietf-ace-oauth- 260 authz](https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 261 13#section-5.1.1 263 1. with response code 4.03 (Forbidden) when the resource URI 264 specified in the request is not covered by the authorization 265 information, and 267 2. with response code 4.05 (Method Not Allowed) when the resource 268 URI specified in the request covered by the authorization 269 information but not the requested action. 271 The client cannot always know a priori if an Authorized Resource 272 Request will succeed. If the client repeatedly gets error responses 273 containing AS Information (cf. Section 5.1.1 of draft-ietf-ace- 274 oauth-authz [7] as response to its requests, it SHOULD request a new 275 Access Token from the authorization server in order to continue 276 communication with the resource server. 278 2.2. Dynamic Update of Authorization Information 280 The client can update the authorization information stored at the 281 resource server at any time without changing an established DTLS 282 session. To do so, the Client requests from the authorization server 283 a new Access Token for the intended action on the respective resource 284 and uploads this Access Token to the authz-info resource on the 285 resource server. 287 Figure 3 depicts the message flow where the client C requests a new 288 Access Token after a security association between the client and the 289 resource server RS has been established using this protocol. The 290 token request MUST specify the key identifier of the existing DTLS 291 channel between the client and the resource server in the "kid" 292 parameter of the Client-to-AS request. The authorization server MUST 293 verify that the specified "kid" denotes a valid verifier for a proof- 294 of-possession ticket that has previously been issued to the 295 requesting client. Otherwise, the Client-to-AS request MUST be 296 declined with a the error code "unsupported_pop_key" as defined in 297 Section 5.6.3 of draft-ietf-ace-oauth-authz [8]. 299 When the authorization server issues a new access token to update 300 existing authorization information it MUST include the specified 301 "kid" parameter in this access token. A resource server MUST 302 associate the updated authorization information with any existing 303 DTLS session that is identified by this key identifier. 305 Note: By associating the access tokens with the identifier of an 306 existing DTLS session, the authorization information can be 307 updated without changing the cryptographic keys for the DTLS 308 communication between the client and the resource server, i.e. an 309 existing session can be used with updated permissions. 311 C RS AS 312 | <===== DTLS channel =====> | | 313 | + Access Token | | 314 | | | 315 | --- Token Request ----------------------------> | 316 | | | 317 | <---------------------------- New Access Token - | 318 | + RS Information | 319 | | | 320 | --- Update /authz-info --> | | 321 | New Access Token | | 322 | | | 323 | == Authorized Request ===> | | 324 | | | 325 | <=== Protected Resource == | | 327 Figure 3: Overview of Dynamic Update Operation 329 2.3. Token Expiration 331 DTLS sessions that have been established in accordance with this 332 profile are always tied to a specific set of access tokens. As these 333 tokens may become invalid at any time (either because the token has 334 expired or the responsible authorization server has revoked the 335 token), the session may become useless at some point. A resource 336 server therefore may decide to terminate existing DTLS sessions after 337 the last valid access token for this session has been deleted. 339 As specified in section 5.8.3 of draft-ietf-ace-oauth-authz [9], the 340 resource server MUST notify the client with an error response with 341 code 4.01 (Unauthorized) for any long running request before 342 terminating the session. 344 The resource server MAY also keep the session alive for some time and 345 respond to incoming requests with a 4.01 (Unauthorized) error message 346 including AS Information to signal that the client needs to upload a 347 new access token before it can continue using this DTLS session. The 348 AS Information is created as specified in section 5.1.2 of draft- 349 ietf-ace-oauth-authz [10]. The resource server SHOULD add a "kid" 350 parameter to the AS Information denoting the identifier of the key 351 that it uses internally for this DTLS session. The client then 352 includes this "kid" parameter in a Client-to-AS request used to 353 retrieve a new access token to be used with this DTLS session. In 354 case the key identifier is already known by the client (e.g. because 355 it was included in the RS Information in an AS-to-Client response), 356 the "kid" parameter MAY be elided from the AS Information. 358 Table 1 updates Figure 2 in section 5.1.2 of draft-ietf-ace-oauth- 359 authz [11] with the new "kid" parameter in accordance with [RFC8152]. 361 +----------------+----------+-----------------+ 362 | Parameter name | CBOR Key | Major Type | 363 +----------------+----------+-----------------+ 364 | kid | 4 | 2 (byte string) | 365 +----------------+----------+-----------------+ 367 Table 1: Updated AS Information parameters 369 3. RawPublicKey Mode 371 To retrieve an access token for the resource that the client wants to 372 access, the client requests an Access Token from the authorization 373 server. The client MUST add a "cnf" object carrying either its raw 374 public key or a unique identifier for a public key that it has 375 previously made known to the authorization server. To prove that the 376 client is in possession of this key, it MUST use the same public key 377 as in certificate message that is used to establish the DTLS session 378 with the authorization server. 380 An example Access Token request from the client to the resource 381 server is depicted in Figure 4. 383 POST coaps://as.example.com/token 384 Content-Format: application/cbor 385 { 386 grant_type: client_credentials, 387 aud: "tempSensor4711", 388 cnf: { 389 COSE_Key: { 390 kty: EC2, 391 crv: P-256, 392 x: h'TODOX', 393 y: h'TODOY' 394 } 395 } 396 } 398 Figure 4: Access Token Request Example for RPK Mode 400 The example shows an Access Token request for the resource identified 401 by the audience string "tempSensor4711" on the authorization server 402 using a raw public key. 404 When the authorization server authorizes a request, it will return an 405 Access Token and a "cnf" object in the AS-to-Client response. Before 406 the client initiates the DTLS handshake with the resource server, it 407 MUST send a "POST" request containing the new Access Token to the 408 authz-info resource hosted by the resource server. If this operation 409 yields a positive response, the client SHOULD proceed to establish a 410 new DTLS channel with the resource server. To use raw public key 411 mode, the client MUST pass the same public key that was used for 412 constructing the Access Token with the SubjectPublicKeyInfo structure 413 in the DTLS handshake as specified in [RFC7250]. 415 An implementation that supports the RPK mode of this profile MUST at 416 least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 417 [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). 419 Note: According to [RFC7252], CoAP implementations MUST support the 420 ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] and the 421 NIST P-256 curve. As discussed in [RFC7748], new ECC curves have 422 been defined recently that are considered superior to the so- 423 called NIST curves. The curve that is mandatory to implement in 424 this specification is said to be efficient and less dangerous 425 regarding implementation errors than the secp256r1 curve mandated 426 in [RFC7252]. 428 The Access Token is constructed by the authorization server such that 429 the resource server can associate the Access Token with the Client's 430 public key. If CBOR web tokens [RFC8392] are used as recommended in 431 [I-D.ietf-ace-oauth-authz], the authorization server MUST include a 432 "COSE_Key" object in the "cnf" claim of the Access Token. This 433 "COSE_Key" object MAY contain a reference to a key for the client 434 that is already known by the resource server (e.g., from previous 435 communication). If the authorization server has no certain knowledge 436 that the Client's key is already known to the resource server, the 437 Client's public key MUST be included in the Access Token's "cnf" 438 parameter. 440 4. PreSharedKey Mode 442 To retrieve an access token for the resource that the client wants to 443 access, the client MAY include a "cnf" object carrying an identifier 444 for a symmetric key in its Access Token request to the authorization 445 server. This identifier can be used by the authorization server to 446 determine the shared secret to construct the proof-of-possession 447 token and therefore MUST specify a symmetric key that was previously 448 generated by the authorization server as a shared secret for the 449 communication between the client and the resource server. 451 Depending on the requested token type and algorithm in the Access 452 Token request, the authorization server adds RS Information to the 453 response that provides the client with sufficient information to 454 setup a DTLS channel with the resource server. For symmetric proof- 455 of-possession keys (c.f. [I-D.ietf-ace-oauth-authz]), the client 456 must ensure that the Access Token request is sent over a secure 457 channel that guarantees authentication, message integrity and 458 confidentiality. 460 When the authorization server authorizes the client it returns an AS- 461 to-Client response with the profile parameter set to "coap_dtls" and 462 a "cnf" parameter carrying a "COSE_Key" object that contains the 463 symmetric key to be used between the client and the resource server 464 as illustrated in Figure 5. 466 2.01 Created 467 Content-Format: application/cbor 468 Location-Path: /token/asdjbaskd 469 { 470 access_token: h'd08343a10... 471 (remainder of CWT omitted for brevity) 472 token_type: pop, 473 alg: HS256, 474 expires_in: 86400, 475 profile: coap_dtls, 476 cnf: { 477 COSE_Key: { 478 kty: symmetric, 479 k: h'73657373696f6e6b6579' 480 } 481 } 482 } 484 Figure 5: Example Access Token response 486 In this example, the authorization server returns a 2.01 response 487 containing a new Access Token. The information is transferred as a 488 CBOR data structure as specified in [I-D.ietf-ace-oauth-authz]. 490 A response that declines any operation on the requested resource is 491 constructed according to Section 5.2 of RFC 6749 [12], (cf. 492 Section 5.7.3 of [I-D.ietf-ace-oauth-authz]). 494 4.00 Bad Request 495 Content-Format: application/cbor 496 { 497 error: invalid_request 498 } 500 Figure 6: Example Access Token response with reject 502 4.1. DTLS Channel Setup Between C and RS 504 When a client receives an Access Token from an authorization server, 505 it checks if the payload contains an "access_token" parameter and a 506 "cnf" parameter. With this information the client can initiate 507 establishment of a new DTLS channel with a resource server. To use 508 DTLS with pre-shared keys, the client follows the PSK key exchange 509 algorithm specified in Section 2 of [RFC4279] using the key conveyed 510 in the "cnf" parameter of the AS response as PSK when constructing 511 the premaster secret. 513 In PreSharedKey mode, the knowledge of the shared secret by the 514 client and the resource server is used for mutual authentication 515 between both peers. Therefore, the resource server must be able to 516 determine the shared secret from the Access Token. Following the 517 general ACE authorization framework, the client can upload the Access 518 Token to the resource server's authz-info resource before starting 519 the DTLS handshake. Alternatively, the client MAY provide the most 520 recent Access Token in the "psk_identity" field of the 521 ClientKeyExchange message. To do so, the client MUST treat the 522 contents of the "access_token" field from the AS-to-Client response 523 as opaque data and not perform any re-coding. 525 Note: As stated in section 4.2 of [RFC7925], the PSK identity should 526 be treated as binary data in the Internet of Things space and not 527 assumed to have a human-readable form of any sort. 529 If a resource server receives a ClientKeyExchange message that 530 contains a "psk_identity" with a length greater zero, it uses the 531 contents as index for its key store (i.e., treat the contents as key 532 identifier). The resource server MUST check if it has one or more 533 Access Tokens that are associated with the specified key. If no 534 valid Access Token is available for this key, the DTLS session setup 535 is terminated with an "illegal_parameter" DTLS alert message. 537 If no key with a matching identifier is found the resource server the 538 resource server MAY process the decoded contents of the 539 "psk_identity" field as access token that is stored with the 540 authorization information endpoint before continuing the DTLS 541 handshake. If the decoded contents of the "psk_identity" do not 542 yield a valid access token for the requesting client, the DTLS 543 session setup is terminated with an "illegal_parameter" DTLS alert 544 message. 546 Note1: As a resource server cannot provide a client with a meaningful 547 PSK identity hint in 548 response to the client's ClientHello message, the resource server 549 SHOULD NOT send a ServerKeyExchange message. 551 Note2: According to [RFC7252], CoAP implementations MUST support the 552 ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is 553 therefore expected to offer at least this ciphersuite to the 554 resource server. 556 This specification assumes that the Access Token is a PoP token as 557 described in [I-D.ietf-ace-oauth-authz] unless specifically stated 558 otherwise. Therefore, the Access Token is bound to a symmetric PoP 559 key that is used as shared secret between the client and the resource 560 server. 562 While the client can retrieve the shared secret from the contents of 563 the "cnf" parameter in the AS-to-Client response, the resource server 564 uses the information contained in the "cnf" claim of the Access Token 565 to determine the actual secret when no explicit "kid" was provided in 566 the "psk_identity" field. Usually, this is done by including a 567 "COSE_Key" object carrying either a key that has been encrypted with 568 a shared secret between the authorization server and the resource 569 server, or a key identifier that can be used by the resource server 570 to lookup the shared secret. 572 Instead of the "COSE_Key" object, the authorization server MAY 573 include a "COSE_Encrypt" structure to enable the resource server to 574 calculate the shared key from the Access Token. The "COSE_Encrypt" 575 structure MUST use the _Direct Key with KDF_ method as described in 576 Section 12.1.2 of RFC 8152 [13]. The authorization server MUST 577 include a Context information structure carrying a PartyU "nonce" 578 parameter carrying the nonce that has been used by the authorization 579 server to construct the shared key. 581 This specification mandates that at least the key derivation 582 algorithm "HKDF SHA-256" as defined in [RFC8152] MUST be supported. 583 This key derivation function is the default when no "alg" field is 584 included in the "COSE_Encrypt" structure for the resource server. 586 4.2. Updating Authorization Information 588 Usually, the authorization information that the resource server keeps 589 for a client is updated by uploading a new Access Token as described 590 in Section 2.2. 592 The Client MAY also perform a new DTLS handshake according to 593 Section 4.1 that replaces the existing DTLS session. After 594 successful completion of the DTLS handshake the resource server 595 updates the existing authorization information for the client 596 according to the new Access Token. 598 5. Security Considerations 600 This document specifies a profile for the Authentication and 601 Authorization for Constrained Environments (ACE) framework 602 [I-D.ietf-ace-oauth-authz]. As it follows this framework's general 603 approach, the general security and privacy considerations from 604 section 6 and section 7 also apply to this profile. 606 Constrained devices that use DTLS [RFC6347] are inherently vulnerable 607 to Denial of Service (DoS) attacks as the handshake protocol requires 608 creation of internal state within the device. This is specifically 609 of concern where an adversary is able to intercept the initial cookie 610 exchange and interject forged messages with a valid cookie to 611 continue with the handshake. 613 [I-D.tiloca-tls-dos-handshake] specifies a TLS extension to prevent 614 this type of attack which is applicable especially for constrained 615 environments where the authorization server can act as trust anchor. 617 6. Privacy Considerations 619 An unprotected response to an unauthorized request may disclose 620 information about the resource server and/or its existing 621 relationship with the client. It is advisable to include as little 622 information as possible in an unencrypted response. When a DTLS 623 session between the client and the resource server already exists, 624 more detailed information may be included with an error response to 625 provide the client with sufficient information to react on that 626 particular error. 628 Note that some information might still leak after DTLS session is 629 established, due to observable message sizes, the source, and the 630 destination addresses. 632 7. IANA Considerations 634 The following registrations are done for the ACE OAuth Profile 635 Registry following the procedure specified in 636 [I-D.ietf-ace-oauth-authz]. 638 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 639 with the RFC number of this specification and delete this paragraph. 641 Profile name: coap_dtls 643 Profile Description: Profile for delegating client authentication and 644 authorization in a constrained environment by establishing a Datagram 645 Transport Layer Security (DTLS) channel between resource-constrained 646 nodes. 648 Profile ID: 1 650 Change Controller: IESG 652 Reference: [RFC-XXXX] 654 8. References 656 8.1. Normative References 658 [I-D.ietf-ace-oauth-authz] 659 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 660 H. Tschofenig, "Authentication and Authorization for 661 Constrained Environments (ACE) using the OAuth 2.0 662 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-13 663 (work in progress), July 2018. 665 [I-D.tiloca-tls-dos-handshake] 666 Tiloca, M., Seitz, L., Hoeve, M., and O. Bergmann, 667 "Extension for protecting (D)TLS handshakes against Denial 668 of Service", draft-tiloca-tls-dos-handshake-02 (work in 669 progress), March 2018. 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 677 Ciphersuites for Transport Layer Security (TLS)", 678 RFC 4279, DOI 10.17487/RFC4279, December 2005, 679 . 681 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 682 "Transport Layer Security (TLS) Renegotiation Indication 683 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 684 . 686 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 687 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 688 January 2012, . 690 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 691 Application Protocol (CoAP)", RFC 7252, 692 DOI 10.17487/RFC7252, June 2014, 693 . 695 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 696 Security (TLS) / Datagram Transport Layer Security (DTLS) 697 Profiles for the Internet of Things", RFC 7925, 698 DOI 10.17487/RFC7925, July 2016, 699 . 701 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 702 RFC 8152, DOI 10.17487/RFC8152, July 2017, 703 . 705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 707 May 2017, . 709 8.2. Informative References 711 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 712 Transport Layer Security (TLS)", RFC 6655, 713 DOI 10.17487/RFC6655, July 2012, 714 . 716 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 717 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 718 Transport Layer Security (TLS) and Datagram Transport 719 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 720 June 2014, . 722 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 723 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 724 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 725 . 727 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 728 for Security", RFC 7748, DOI 10.17487/RFC7748, January 729 2016, . 731 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 732 Signature Algorithm (EdDSA)", RFC 8032, 733 DOI 10.17487/RFC8032, January 2017, 734 . 736 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 737 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 738 May 2018, . 740 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 741 Curve Cryptography (ECC) Cipher Suites for Transport Layer 742 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 743 DOI 10.17487/RFC8422, August 2018, 744 . 746 8.3. URIs 748 [1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 749 13#section-5.8.1 751 [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 752 13#section-5.1.2 754 [3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 755 13#section-5.3 757 [4] https://tools.ietf.org/html/rfc7252#section-9 759 [5] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 760 13#section-5.8.1 762 [6] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 763 13#section-5.1.1 765 [7] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 766 13#section-5.1.1 768 [8] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 769 13#section-5.6.3 771 [9] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 772 13#section-5.8.3 774 [10] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 775 13#section-5.1.2 777 [11] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 778 13#section-5.1.2 780 [12] https://tools.ietf.org/html/rfc6749#section-5.2 782 [13] https://tools.ietf.org/html/rfc8152#section-12.1.2 784 Authors' Addresses 786 Stefanie Gerdes 787 Universitaet Bremen TZI 788 Postfach 330440 789 Bremen D-28359 790 Germany 792 Phone: +49-421-218-63906 793 Email: gerdes@tzi.org 795 Olaf Bergmann 796 Universitaet Bremen TZI 797 Postfach 330440 798 Bremen D-28359 799 Germany 801 Phone: +49-421-218-63904 802 Email: bergmann@tzi.org 804 Carsten Bormann 805 Universitaet Bremen TZI 806 Postfach 330440 807 Bremen D-28359 808 Germany 810 Phone: +49-421-218-63921 811 Email: cabo@tzi.org 813 Goeran Selander 814 Ericsson 815 Faroegatan 6 816 Kista 164 80 817 Sweden 819 Email: goran.selander@ericsson.com 821 Ludwig Seitz 822 RISE SICS 823 Scheelevaegen 17 824 Lund 223 70 825 Sweden 827 Email: ludwig.seitz@ri.se