idnits 2.17.1 draft-ietf-ace-dtls-authorize-05.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 (October 08, 2018) is 1998 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 808 -- Looks like a reference, but probably isn't: '2' on line 811 -- Looks like a reference, but probably isn't: '3' on line 813 -- Looks like a reference, but probably isn't: '4' on line 815 -- Looks like a reference, but probably isn't: '5' on line 817 -- Looks like a reference, but probably isn't: '6' on line 820 -- Looks like a reference, but probably isn't: '7' on line 822 -- Looks like a reference, but probably isn't: '8' on line 825 -- Looks like a reference, but probably isn't: '9' on line 828 -- Looks like a reference, but probably isn't: '10' on line 830 -- Looks like a reference, but probably isn't: '11' on line 832 -- Looks like a reference, but probably isn't: '12' on line 834 -- Looks like a reference, but probably isn't: '13' on line 836 -- Looks like a reference, but probably isn't: '14' on line 838 -- Looks like a reference, but probably isn't: '15' on line 840 -- Looks like a reference, but probably isn't: '16' on line 842 -- Looks like a reference, but probably isn't: '17' on line 844 -- Looks like a reference, but probably isn't: '18' on line 846 -- Looks like a reference, but probably isn't: '19' on line 848 -- Looks like a reference, but probably isn't: '20' on line 851 -- Looks like a reference, but probably isn't: '21' on line 853 -- Looks like a reference, but probably isn't: '22' on line 855 -- Looks like a reference, but probably isn't: '23' on line 857 -- Looks like a reference, but probably isn't: '24' on line 859 -- Looks like a reference, but probably isn't: '25' on line 862 -- Looks like a reference, but probably isn't: '26' on line 865 -- Looks like a reference, but probably isn't: '27' on line 868 -- Looks like a reference, but probably isn't: '28' on line 871 -- Looks like a reference, but probably isn't: '29' on line 874 == Missing Reference: 'RFC-XXXX' is mentioned on line 717, but not defined == Unused Reference: 'RFC7925' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'RFC7748' is defined on line 787, but no explicit reference was found in the text == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-16 ** 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 (~~), 5 warnings (==), 30 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: April 11, 2019 Universitaet Bremen TZI 6 G. Selander 7 Ericsson AB 8 L. Seitz 9 RISE SICS 10 October 08, 2018 12 Datagram Transport Layer Security (DTLS) Profile for Authentication and 13 Authorization for Constrained Environments (ACE) 14 draft-ietf-ace-dtls-authorize-05 16 Abstract 18 This specification defines a profile that allows constrained servers 19 to delegate client authentication and authorization. The protocol 20 relies on DTLS for communication security between entities in a 21 constrained network using either raw public keys or pre-shared keys. 22 A resource-constrained server can use this protocol to delegate 23 management of authorization information to a trusted host with less 24 severe limitations regarding processing power and memory. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 11, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Communication between C and AS . . . . . . . . . . . . . 5 65 3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6 66 3.2.1. DTLS Channel Setup Between C and RS . . . . . . . . . 7 67 3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 8 68 3.3.1. DTLS Channel Setup Between C and RS . . . . . . . . . 10 69 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 12 70 4. Dynamic Update of Authorization Information . . . . . . . . . 13 71 5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 77 9.2. Informative References . . . . . . . . . . . . . . . . . 17 78 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 obtains an access token, bound to a key (the proof-of- 87 possession key), from an authorization server to prove its 88 authorization to access protected resources hosted by the resource 89 server. Also, the client and the resource server are provided by the 90 authorization server with the necessary keying material to establish 91 a DTLS session. The communication between client and authorization 92 server may also be secured with DTLS. This specification supports 93 DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys 94 (PSK) [RFC4279]. 96 The DTLS handshake [RFC7250] requires the client and server to prove 97 that they can use certain keying material. In the RPK mode, the 98 client proves with the DTLS handshake that it can use the RPK bound 99 to the token and the server shows that it can use a certain RPK. The 100 access token must be presented to the resource server. For the RPK 101 mode, the access token needs to be uploaded to the resource server 102 before the handshake is initiated, as described in Section 5.8.1 of 103 draft-ietf-ace-oauth-authz [1]. 105 In the PSK mode, client and server show with the DTLS handshake that 106 they can use the keying material that is bound to the access token. 107 To transfer the access token from the client to the resource server, 108 the "psk_identity" parameter in the DTLS PSK handshake may be used 109 instead of uploading the token prior to the handshake. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 Readers are expected to be familiar with the terms and concepts 120 described in I-D.ietf-ace-oauth-authz [2]. 122 The authz-info resource refers to the authz-info endpoint as 123 specified in I-D.ietf-ace-oauth-authz [3]. 125 2. Protocol Overview 127 The CoAP-DTLS profile for ACE specifies the transfer of 128 authentication information and, if necessary, authorization 129 information between the client (C) and the resource server (RS) 130 during setup of a DTLS session for CoAP messaging. It also specifies 131 how C can use CoAP over DTLS to retrieve an access token from the 132 authorization server (AS) for a protected resource hosted on the 133 resource server. 135 This profile requires the client to retrieve an access token for 136 protected resource(s) it wants to access on RS as specified in I- 137 D.ietf-ace-oauth-authz [4]. Figure 1 shows the typical message flow 138 in this scenario (messages in square brackets are optional): 140 C RS AS 141 | [-- Resource Request --->] | | 142 | | | 143 | [<----- AS Information --] | | 144 | | | 145 | --- Token Request ----------------------------> | 146 | | | 147 | <---------------------------- Access Token ----- | 148 | + Access Information | 150 Figure 1: Retrieving an Access Token 152 To determine the AS in charge of a resource hosted at the RS, C MAY 153 send an initial Unauthorized Resource Request message to the RS. The 154 RS then denies the request and sends an AS information message 155 containing the address of its AS back to the client as specified in 156 Section 5.1.2 of draft-ietf-ace-oauth-authz [5]. 158 Once the client knows the authorization server's address, it can send 159 an access token request to the token endpoint at the AS as specified 160 in I-D.ietf-ace-oauth-authz [6]. As the access token request as well 161 as the response may contain confidential data, the communication 162 between the client and the authorization server MUST be 163 confidentiality-protected and ensure authenticity. C may have been 164 registered at the AS via the OAuth 2.0 client registration mechanism 165 as outlined in Section 5.3 of draft-ietf-ace-oauth-authz [7]. 167 The access token returned by the authorization server can then be 168 used by the client to establish a new DTLS session with the resource 169 server. When the client intends to use asymmetric cryptography in 170 the DTLS handshake with the resource server, the client MUST upload 171 the access token to the authz-info resource, i.e. the authz-info 172 endpoint, on the resource server before starting the DTLS handshake, 173 as described in Section 5.8.1 of draft-ietf-ace-oauth-authz [8]. If 174 only symmetric cryptography is used between the client and the 175 resource server, the access token MAY instead be transferred in the 176 DTLS ClientKeyExchange message (see Section 3.3.1). 178 Figure 2 depicts the common protocol flow for the DTLS profile after 179 the client C has retrieved the access token from the authorization 180 server AS. 182 C RS AS 183 | [--- Access Token ------>] | | 184 | | | 185 | <== DTLS channel setup ==> | | 186 | | | 187 | == Authorized Request ===> | | 188 | | | 189 | <=== Protected Resource == | | 191 Figure 2: Protocol overview 193 3. Protocol Flow 195 The following sections specify how CoAP is used to interchange 196 access-related data between the resource server, the client and the 197 authorization server so that the authorization server can provide the 198 client and the resource server with sufficient information to 199 establish a secure channel, and convey authorization information 200 specific for this communication relationship to the resource server. 202 Section 3.1 describes how the communication between C and AS must be 203 secured. Depending on the used CoAP security mode (see also 204 Section 9 of RFC 7252 [9]), the Client-to-AS request, AS-to-Client 205 response and DTLS session establishment carry slightly different 206 information. Section 3.2 addresses the use of raw public keys while 207 Section 3.3 defines how pre-shared keys are used in this profile. 209 3.1. Communication between C and AS 211 To retrieve an access token for the resource that the client wants to 212 access, the client requests an access token from the authorization 213 server. Before C can request the access token, C and AS must 214 establish a secure communication channel. C must securely have 215 obtained keying material to communicate with AS, and C must securely 216 have received authorization information intended for C that states 217 that AS is authorized to provide keying material concerning RS to C. 218 Also, AS must securely have obtained keying material for C, and 219 obtained authorization rules approved by the resource owner (RO) 220 concerning C and RS that relate to this keying material. C and AS 221 must use their respective keying material for all exchanged messages. 222 How the security association between C and AS is established is not 223 part of this document. C and AS MUST ensure the confidentiality, 224 integrity and authenticity of all exchanged messages. 226 If C is constrained, C and AS should use DTLS to communicate with 227 each other. But C and AS may also use other means to secure their 228 communication, e.g., TLS. The used security protocol must provide 229 confidentiality, integrity and authenticity, and enable the client to 230 determine if it is the intended recipient of a message, e.g., by 231 using an AEAD mechanism. C must also be able to determine if a 232 response from AS belongs to a certain request. Additionally, the 233 protocol must offer replay protection. 235 3.2. RawPublicKey Mode 237 After C and AS mutually authenticated each other and validated each 238 other's authorization, C sends a token request to AS's token 239 endpoint. The client MUST add a "cnf" object carrying either its raw 240 public key or a unique identifier for a public key that it has 241 previously made known to the authorization server. To prove that the 242 client is in possession of this key, C MUST use the same keying 243 material that it uses to secure the communication with AS, e.g., the 244 DTLS session. 246 An example access token request from the client to the AS is depicted 247 in Figure 3. 249 POST coaps://as.example.com/token 250 Content-Format: application/ace+cbor 251 { 252 grant_type: client_credentials, 253 req_aud: "tempSensor4711", 254 req_cnf: { 255 COSE_Key: { 256 kty: EC2, 257 crv: P-256, 258 x: h'e866c35f4c3c81bb96a1...', 259 y: h'2e25556be097c8778a20...' 260 } 261 } 262 } 264 Figure 3: Access Token Request Example for RPK Mode 266 The example shows an access token request for the resource identified 267 by the string "tempSensor4711" on the authorization server using a 268 raw public key. 270 AS MUST check if the client that it communicates with is associated 271 with the RPK in the cnf object before issuing an access token to it. 272 If AS determines that the request is to be authorized according to 273 the respective authorization rules, it generates an access token 274 response for C. The response SHOULD contain a "profile" parameter 275 with the value "coap_dtls" to indicate that this profile must be used 276 for communication between the client C and the resource server. The 277 response also contains an access token and an "rs_cnf" parameter 278 containing information about the public key that is used by the 279 resource server. AS MUST ascertain that the RPK specified in 280 "rs_cnf" belongs to the resource server that C wants to communicate 281 with. AS MUST protect the integrity of the token. If the access 282 token contains confidential data, AS MUST also protect the 283 confidentiality of the access token. 285 C MUST ascertain that the access token response belongs to a certain 286 previously sent access token request, as the request may specify the 287 resource server with which C wants to communicate. 289 3.2.1. DTLS Channel Setup Between C and RS 291 Before the client initiates the DTLS handshake with the resource 292 server, C MUST send a "POST" request containing the new access token 293 to the authz-info resource hosted by the resource server. If this 294 operation yields a positive response, the client SHOULD proceed to 295 establish a new DTLS channel with the resource server. To use the 296 RawPublicKey mode, the client MUST specify the public key that AS 297 defined in the "cnf" field of the access token response in the 298 SubjectPublicKeyInfo structure in the DTLS handshake as specified in 299 RFC 7250 [10]. 301 An implementation that supports the RPK mode of this profile MUST at 302 least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 303 [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). 305 Note: According to RFC 7252 [11], CoAP implementations MUST support 306 the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] and 307 the NIST P-256 curve. As discussed in RFC 7748 [12], new ECC 308 curves have been defined recently that are considered superior to 309 the so-called NIST curves. The curve that is mandatory to 310 implement in this specification is said to be efficient and less 311 dangerous regarding implementation errors than the secp256r1 curve 312 mandated in RFC 7252 [13]. 314 RS MUST check if the access token is still valid, if RS is the 315 intended destination, i.e., the audience, of the token, and if the 316 token was issued by an authorized AS. The access token is 317 constructed by the authorization server such that the resource server 318 can associate the access token with the Client's public key. The 319 "cnf" claim MUST contain either C's RPK or, if the key is already 320 known by the resource server (e.g., from previous communication), a 321 reference to this key. If the authorization server has no certain 322 knowledge that the Client's key is already known to the resource 323 server, the Client's public key MUST be included in the access 324 token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as 325 recommended in I-D.ietf-ace-oauth-authz [14], unencrypted keys MUST 326 be specified using a "COSE_Key" object, encrypted keys with a 327 "COSE_Encrypt0" structure and references to the key as "key_id" 328 parameters in a CBOR map. RS MUST use the keying material in the 329 handshake that AS specified in the rs_cnf parameter in the access 330 token. Thus, the handshake only finishes if C and RS are able to use 331 their respective keying material. 333 3.3. PreSharedKey Mode 335 To retrieve an access token for the resource that the client wants to 336 access, the client MAY include a "cnf" object carrying an identifier 337 for a symmetric key in its access token request to the authorization 338 server. This identifier can be used by the authorization server to 339 determine the shared secret to construct the proof-of-possession 340 token. AS MUST check if the identifier refers to a symmetric key 341 that was previously generated by AS as a shared secret for the 342 communication between this client and the resource server. 344 The authorization server MUST determine the authorization rules for 345 the C it communicates with as defined by RO and generate the access 346 token accordingly. If the authorization server authorizes the 347 client, it returns an AS-to-Client response. If the profile 348 parameter is present, it is set to "coap_dtls". AS MUST ascertain 349 that the access token is generated for the resource server that C 350 wants to communicate with. Also, AS MUST protect the integrity of 351 the access token. If the token contains confidential data such as 352 the symmetric key, the confidentiality of the token MUST also be 353 protected. Depending on the requested token type and algorithm in 354 the access token request, the authorization server adds access 355 Information to the response that provides the client with sufficient 356 information to setup a DTLS channel with the resource server. AS 357 adds a "cnf" parameter to the access information carrying a 358 "COSE_Key" object that informs the client about the symmetric key 359 that is to be used between C and the resource server. 361 An example access token response is illustrated in Figure 4. In this 362 example, the authorization server returns a 2.01 response containing 363 a new access token and information for the client, including the 364 symmetric key in the cnf claim. The information is transferred as a 365 CBOR data structure as specified in I-D.ietf-ace-oauth-authz [15]. 367 2.01 Created 368 Content-Format: application/ace+cbor 369 Max-Age: 86400 370 { 371 access_token: h'd08343a10... 372 (remainder of CWT omitted for brevity) 373 token_type: pop, 374 alg: HS256, 375 expires_in: 86400, 376 profile: coap_dtls, 377 cnf: { 378 COSE_Key: { 379 kty: symmetric, 380 k: h'73657373696f6e6b6579' 381 } 382 } 383 } 385 Figure 4: Example Access Token Response 387 The access token also comprises a "cnf" claim. This claim usually 388 contains a "COSE_Key" object that carries either the symmetric key 389 itself or or a key identifier that can be used by the resource server 390 to determine the shared secret. If the access token carries a 391 symmetric key, the access token MUST be encrypted using a 392 "COSE_Encrypt0" structure. The AS MUST use the keying material 393 shared with the RS to encrypt the token. 395 Instead of providing the keying material, the AS MAY include a key 396 derivation function and a salt in the access token that enables the 397 resource server to calculate the keying material for the 398 communication with C from the access token. In this case, the token 399 contains a "cnf" structure that specifies the key derivation 400 algorithm and the salt that the AS has used to construct the shared 401 key. AS and RS MUST use their shared keying material for the key 402 derivation, and the key derivation MUST follow Section 11 of RFC 8152 403 [16] with parameters as specified here. The KDF specified in the 404 "alg" parameter SHOULD be HKDF-SHA-256. The salt picked by the AS 405 must be uniformly random and is carried in the "salt" parameter. 407 The fields in the context information "COSE_KDF_Context" 408 (Section 11.2 of RFC 8152 [17]) MUST have the following values: 410 o AlgorithmID = "ACE-CoAP-DTLS-salt" 412 o PartyUInfo = PartyVInfo = ( null, null, null ) 413 o keyDataLength is a uint equal the length of the key shared between 414 AS and RS in bits 416 o protected MUST be a zero length bstr 418 o other is a zero length bstr 420 o SuppPrivInfo is omitted 422 An example "cnf" structure specifying HMAC-based key derivation of a 423 symmetric key with SHA-256 as pseudo-random function and a random 424 salt value is provided in Figure 5. 426 cnf : { 427 kty : symmetric, 428 alg : HKDF-SHA-256, 429 salt : h'eIiOFCa9lObw' 430 } 432 Figure 5: Key Derivation Specification in an Access Token 434 A response that declines any operation on the requested resource is 435 constructed according to Section 5.2 of RFC 6749 [18], (cf. 436 Section 5.7.3. of draft-ietf-ace-oauth-authz [19]). 438 4.00 Bad Request 439 Content-Format: application/ace+cbor 440 { 441 error: invalid_request 442 } 444 Figure 6: Example Access Token Response With Reject 446 3.3.1. DTLS Channel Setup Between C and RS 448 When a client receives an access token response from an authorization 449 server, C MUST ascertain that the access token response belongs to a 450 certain previously sent access token request, as the request may 451 specify the resource server with which C wants to communicate. 453 C checks if the payload of the access token response contains an 454 "access_token" parameter and a "cnf" parameter. With this 455 information the client can initiate the establishment of a new DTLS 456 channel with a resource server. To use DTLS with pre-shared keys, 457 the client follows the PSK key exchange algorithm specified in 458 Section 2 of RFC 4279 [20] using the key conveyed in the "cnf" 459 parameter of the AS response as PSK when constructing the premaster 460 secret. 462 In PreSharedKey mode, the knowledge of the shared secret by the 463 client and the resource server is used for mutual authentication 464 between both peers. Therefore, the resource server must be able to 465 determine the shared secret from the access token. Following the 466 general ACE authorization framework, the client can upload the access 467 token to the resource server's authz-info resource before starting 468 the DTLS handshake. Alternatively, the client MAY provide the most 469 recent access token in the "psk_identity" field of the 470 ClientKeyExchange message. To do so, the client MUST treat the 471 contents of the "access_token" field from the AS-to-Client response 472 as opaque data and not perform any re-coding. 474 Note: As stated in Section 4.2 of RFC 7925 [21], the PSK identity 475 should be treated as binary data in the Internet of Things space 476 and not assumed to have a human-readable form of any sort. 478 If a resource server receives a ClientKeyExchange message that 479 contains a "psk_identity" with a length greater zero, it uses the 480 contents as index for its key store (i.e., treat the contents as key 481 identifier). The resource server MUST check if it has one or more 482 access tokens that are associated with the specified key. 484 If no key with a matching identifier is found, the resource server 485 MAY process the contents of the "psk_identity" field as access token 486 that is stored with the authorization information endpoint, before 487 continuing the DTLS handshake. If the contents of the "psk_identity" 488 do not yield a valid access token for the requesting client, the DTLS 489 session setup is terminated with an "illegal_parameter" DTLS alert 490 message. 492 Note1: As a resource server cannot provide a client with a 493 meaningful PSK identity hint in response to the client's 494 ClientHello message, the resource server SHOULD NOT send a 495 ServerKeyExchange message. 497 Note2: According to RFC 7252 [22], CoAP implementations MUST support 498 the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is 499 therefore expected to offer at least this ciphersuite to the 500 resource server. 502 When RS receives an access token, RS MUST check if the access token 503 is still valid, if RS is the intended destination, i.e., the audience 504 of the token, and if the token was issued by an authorized AS. This 505 specification assumes that the access token is a PoP token as 506 described in I-D.ietf-ace-oauth-authz [23] unless specifically stated 507 otherwise. Therefore, the access token is bound to a symmetric PoP 508 key that is used as shared secret between the client and the resource 509 server. 511 While the client can retrieve the shared secret from the contents of 512 the "cnf" parameter in the AS-to-Client response, the resource server 513 uses the information contained in the "cnf" claim of the access token 514 to determine the actual secret when no explicit "kid" was provided in 515 the "psk_identity" field. If key derivation is used, the RS uses the 516 "COSE_KDF_Context" information as described above. 518 3.4. Resource Access 520 Once a DTLS channel has been established as described in Section 3.2 521 and Section 3.3, respectively, the client is authorized to access 522 resources covered by the access token it has uploaded to the authz- 523 info resource hosted by the resource server. 525 With the successful establishment of the DTLS channel, C and RS have 526 proven that they can use their respective keying material. An access 527 token that is bound to the client's keying material is associated 528 with the channel. Any request that the resource server receives on 529 this channel MUST be checked against these authorization rules. RS 530 MUST check for every request if the access token is still valid. 531 Incoming CoAP requests that are not authorized with respect to any 532 access token that is associated with the client MUST be rejected by 533 the resource server with 4.01 response as described in Section 5.1.1 534 of draft-ietf-ace-oauth-authz [24]. 536 The resource server SHOULD treat an incoming CoAP request as 537 authorized if the following holds: 539 1. The message was received on a secure channel that has been 540 established using the procedure defined in this document. 542 2. The authorization information tied to the sending client is 543 valid. 545 3. The request is destined for the resource server. 547 4. The resource URI specified in the request is covered by the 548 authorization information. 550 5. The request method is an authorized action on the resource with 551 respect to the authorization information. 553 Incoming CoAP requests received on a secure DTLS channel that are not 554 thus authorized MUST be rejected according to Section 5.8.2 of draft- 555 ietf-ace-oauth-authz [25] 556 1. with response code 4.03 (Forbidden) when the resource URI 557 specified in the request is not covered by the authorization 558 information, and 560 2. with response code 4.05 (Method Not Allowed) when the resource 561 URI specified in the request covered by the authorization 562 information but not the requested action. 564 The client cannot always know a priori if an Authorized Resource 565 Request will succeed. If the client repeatedly gets error responses 566 containing AS Information (cf. Section 5.1.2 of draft-ietf-ace- 567 oauth-authz [26]) as response to its requests, it SHOULD request a 568 new access token from the authorization server in order to continue 569 communication with the resource server. 571 4. Dynamic Update of Authorization Information 573 The client can update the authorization information stored at the 574 resource server at any time without changing an established DTLS 575 session. To do so, the Client requests a new access token from the 576 authorization server for the intended action on the respective 577 resource and uploads this access token to the authz-info resource on 578 the resource server. 580 Figure 7 depicts the message flow where the C requests a new access 581 token after a security association between the client and the 582 resource server has been established using this protocol. If the 583 client wants to update the authorization information, the token 584 request MUST specify the key identifier of the existing DTLS channel 585 between the client and the resource server in the "kid" parameter of 586 the Client-to-AS request. The authorization server MUST verify that 587 the specified "kid" denotes a valid verifier for a proof-of- 588 possession token that has previously been issued to the requesting 589 client. Otherwise, the Client-to-AS request MUST be declined with 590 the error code "unsupported_pop_key" as defined in Section 5.6.3 of 591 draft-ietf-ace-oauth-authz [27]. 593 When the authorization server issues a new access token to update 594 existing authorization information, it MUST include the specified 595 "kid" parameter in this access token. A resource server MUST 596 associate the updated authorization information with any existing 597 DTLS session that is identified by this key identifier. 599 Note: By associating the access tokens with the identifier of an 600 existing DTLS session, the authorization information can be 601 updated without changing the cryptographic keys for the DTLS 602 communication between the client and the resource server, i.e. an 603 existing session can be used with updated permissions. 605 C RS AS 606 | <===== DTLS channel =====> | | 607 | + Access Token | | 608 | | | 609 | --- Token Request ----------------------------> | 610 | | | 611 | <---------------------------- New Access Token - | 612 | + Access Information | 613 | | | 614 | --- Update /authz-info --> | | 615 | New Access Token | | 616 | | | 617 | == Authorized Request ===> | | 618 | | | 619 | <=== Protected Resource == | | 621 Figure 7: Overview of Dynamic Update Operation 623 5. Token Expiration 625 DTLS sessions that have been established in accordance with this 626 profile are always tied to a specific set of access tokens. As these 627 tokens may become invalid at any time (either because the token has 628 expired or the responsible authorization server has revoked the 629 token), the session may become useless at some point. A resource 630 server therefore MUST terminate existing DTLS sessions after the last 631 valid access token for this session has been deleted. 633 As specified in Section 5.8.3 of draft-ietf-ace-oauth-authz [28], the 634 resource server MUST notify the client with an error response with 635 code 4.01 (Unauthorized) for any long running request before 636 terminating the session. 638 Table 1 updates Figure 2 in Section 5.1.2 of draft-ietf-ace-oauth- 639 authz [29] with the new "kid" parameter in accordance with [RFC8152]. 641 +----------------+----------+-----------------+ 642 | Parameter name | CBOR Key | Major Type | 643 +----------------+----------+-----------------+ 644 | kid | 4 | 2 (byte string) | 645 +----------------+----------+-----------------+ 647 Table 1: Updated AS Information parameters 649 6. Security Considerations 651 This document specifies a profile for the Authentication and 652 Authorization for Constrained Environments (ACE) framework 653 [I-D.ietf-ace-oauth-authz]. As it follows this framework's general 654 approach, the general security and privacy considerations from 655 section 6 and section 7 also apply to this profile. 657 Constrained devices that use DTLS [RFC6347] are inherently vulnerable 658 to Denial of Service (DoS) attacks as the handshake protocol requires 659 creation of internal state within the device. This is specifically 660 of concern where an adversary is able to intercept the initial cookie 661 exchange and interject forged messages with a valid cookie to 662 continue with the handshake. 664 [I-D.tiloca-tls-dos-handshake] specifies a TLS extension to prevent 665 this type of attack which is applicable especially for constrained 666 environments where the authorization server can act as trust anchor. 668 The use of multiple access tokens for a single client increases the 669 strain on the resource server as it must consider every access token 670 and calculate the actual permissions of the client. Also, tokens may 671 contradict each other which may lead the server to enforce wrong 672 permissions. If one of the access tokens expires earlier than 673 others, the resulting permissions may offer insufficient protection. 674 Developers should avoid using multiple access tokens for a client. 676 7. Privacy Considerations 678 An unprotected response to an unauthorized request may disclose 679 information about the resource server and/or its existing 680 relationship with the client. It is advisable to include as little 681 information as possible in an unencrypted response. When a DTLS 682 session between the client and the resource server already exists, 683 more detailed information may be included with an error response to 684 provide the client with sufficient information to react on that 685 particular error. 687 Also, unprotected requests to the resource server may reveal 688 information about the client, e.g., which resources the client 689 attempts to request or the data that the client wants to provide to 690 the resource server. The client should not send confidential data in 691 an unprotected request. 693 Note that some information might still leak after DTLS session is 694 established, due to observable message sizes, the source, and the 695 destination addresses. 697 8. IANA Considerations 699 The following registrations are done for the ACE OAuth Profile 700 Registry following the procedure specified in 701 [I-D.ietf-ace-oauth-authz]. 703 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 704 with the RFC number of this specification and delete this paragraph. 706 Profile name: coap_dtls 708 Profile Description: Profile for delegating client authentication and 709 authorization in a constrained environment by establishing a Datagram 710 Transport Layer Security (DTLS) channel between resource-constrained 711 nodes. 713 Profile ID: 1 715 Change Controller: IESG 717 Reference: [RFC-XXXX] 719 9. References 721 9.1. Normative References 723 [I-D.ietf-ace-oauth-authz] 724 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 725 H. Tschofenig, "Authentication and Authorization for 726 Constrained Environments (ACE) using the OAuth 2.0 727 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 728 (work in progress), October 2018. 730 [I-D.tiloca-tls-dos-handshake] 731 Tiloca, M., Seitz, L., Hoeve, M., and O. Bergmann, 732 "Extension for protecting (D)TLS handshakes against Denial 733 of Service", draft-tiloca-tls-dos-handshake-02 (work in 734 progress), March 2018. 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 742 Ciphersuites for Transport Layer Security (TLS)", 743 RFC 4279, DOI 10.17487/RFC4279, December 2005, 744 . 746 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 747 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 748 January 2012, . 750 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 751 Application Protocol (CoAP)", RFC 7252, 752 DOI 10.17487/RFC7252, June 2014, 753 . 755 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 756 Security (TLS) / Datagram Transport Layer Security (DTLS) 757 Profiles for the Internet of Things", RFC 7925, 758 DOI 10.17487/RFC7925, July 2016, 759 . 761 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 762 RFC 8152, DOI 10.17487/RFC8152, July 2017, 763 . 765 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 766 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 767 May 2017, . 769 9.2. Informative References 771 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 772 Transport Layer Security (TLS)", RFC 6655, 773 DOI 10.17487/RFC6655, July 2012, 774 . 776 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 777 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 778 Transport Layer Security (TLS) and Datagram Transport 779 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 780 June 2014, . 782 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 783 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 784 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 785 . 787 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 788 for Security", RFC 7748, DOI 10.17487/RFC7748, January 789 2016, . 791 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 792 Signature Algorithm (EdDSA)", RFC 8032, 793 DOI 10.17487/RFC8032, January 2017, 794 . 796 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 797 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 798 May 2018, . 800 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 801 Curve Cryptography (ECC) Cipher Suites for Transport Layer 802 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 803 DOI 10.17487/RFC8422, August 2018, 804 . 806 9.3. URIs 808 [1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 809 16#section-5.8.1 811 [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 813 [3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 815 [4] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 817 [5] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 818 16#section-5.1.2 820 [6] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 822 [7] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 823 16#section-5.3 825 [8] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 826 16#section-5.8.1 828 [9] https://tools.ietf.org/html/rfc7252#section-9 830 [10] https://tools.ietf.org/html/rfc7250 832 [11] https://tools.ietf.org/html/rfc7252 834 [12] https://tools.ietf.org/html/rfc7748 836 [13] https://tools.ietf.org/html/rfc7252 838 [14] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 840 [15] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 842 [16] https://tools.ietf.org/html/rfc8152#section-11 844 [17] https://tools.ietf.org/html/rfc8152#section-11.2 846 [18] https://tools.ietf.org/html/rfc6749#section-5.2 848 [19] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz#section- 849 5.7.3 851 [20] https://tools.ietf.org/html/rfc4279#section-2 853 [21] https://tools.ietf.org/html/rfc7925#section-4.2 855 [22] https://tools.ietf.org/html/rfc7252 857 [23] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 859 [24] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 860 16#section-5.1.1 862 [25] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 863 16#section-5.8.2 865 [26] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 866 16#section-5.1.2 868 [27] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 869 16#section-5.6.3 871 [28] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 872 16#section-5.8.3 874 [29] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 875 16#section-5.1.2 877 Authors' Addresses 879 Stefanie Gerdes 880 Universitaet Bremen TZI 881 Postfach 330440 882 Bremen D-28359 883 Germany 885 Phone: +49-421-218-63906 886 Email: gerdes@tzi.org 887 Olaf Bergmann 888 Universitaet Bremen TZI 889 Postfach 330440 890 Bremen D-28359 891 Germany 893 Phone: +49-421-218-63904 894 Email: bergmann@tzi.org 896 Carsten Bormann 897 Universitaet Bremen TZI 898 Postfach 330440 899 Bremen D-28359 900 Germany 902 Phone: +49-421-218-63921 903 Email: cabo@tzi.org 905 Goeran Selander 906 Ericsson AB 908 Email: goran.selander@ericsson.com 910 Ludwig Seitz 911 RISE SICS 912 Scheelevaegen 17 913 Lund 223 70 914 Sweden 916 Email: ludwig.seitz@ri.se