idnits 2.17.1 draft-ietf-ace-dtls-authorize-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1865 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) == Missing Reference: 'RFC-XXXX' is mentioned on line 778, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-ace-cwt-proof-of-possession-06 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-22 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-04 ** 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 (==), 1 comment (--). 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: September 12, 2019 Universitaet Bremen TZI 6 G. Selander 7 Ericsson AB 8 L. Seitz 9 RISE SICS 10 March 11, 2019 12 Datagram Transport Layer Security (DTLS) Profile for Authentication and 13 Authorization for Constrained Environments (ACE) 14 draft-ietf-ace-dtls-authorize-07 16 Abstract 18 This specification defines a profile of the ACE framework that allows 19 constrained servers to delegate client authentication and 20 authorization. The protocol relies on DTLS for communication 21 security between entities in a constrained network using either raw 22 public keys or pre-shared keys. A resource-constrained server can 23 use this protocol to delegate management of authorization information 24 to a trusted host with less severe limitations regarding processing 25 power and memory. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Communication between C and AS . . . . . . . . . . . . . 5 66 3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6 67 3.2.1. DTLS Channel Setup Between C and RS . . . . . . . . . 7 68 3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 8 69 3.3.1. DTLS Channel Setup Between C and RS . . . . . . . . . 12 70 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 13 71 4. Dynamic Update of Authorization Information . . . . . . . . . 14 72 5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 16 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 78 9.2. Informative References . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 requires the client and server to prove that they 97 can use certain keying material. In the RPK mode, the client proves 98 with the DTLS handshake that it can use the RPK bound to the token 99 and the server shows that it can use a certain RPK. The access token 100 must be presented to the resource server. For the RPK mode, the 101 access token needs to be uploaded to the resource server before the 102 handshake is initiated, as described in Section 5.8.1 of the ACE 103 framework [I-D.ietf-ace-oauth-authz]. 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] and in 121 [I-D.ietf-ace-oauth-params]. 123 The authorization information (authz-info) resource refers to the 124 authorization information endpoint as specified in 125 [I-D.ietf-ace-oauth-authz]. 127 2. Protocol Overview 129 The CoAP-DTLS profile for ACE specifies the transfer of 130 authentication information and, if necessary, authorization 131 information between the client (C) and the resource server (RS) 132 during setup of a DTLS session for CoAP messaging. It also specifies 133 how C can use CoAP over DTLS to retrieve an access token from the 134 authorization server (AS) for a protected resource hosted on the 135 resource server. 137 This profile requires the client to retrieve an access token for 138 protected resource(s) it wants to access on RS as specified in 139 [I-D.ietf-ace-oauth-authz]. Figure 1 shows the typical message flow 140 in this scenario (messages in square brackets are optional): 142 C RS AS 143 | [---- Resource Request ------>]| | 144 | | | 145 | [<-AS Request Creation Hints-] | | 146 | | | 147 | ------- Token Request ----------------------------> | 148 | | | 149 | <---------------------------- Access Token --------- | 150 | + Access Information | 152 Figure 1: Retrieving an Access Token 154 To determine the AS in charge of a resource hosted at the RS, C MAY 155 send an initial Unauthorized Resource Request message to the RS. The 156 RS then denies the request and sends an AS Request Creation Hints 157 message containing the address of its AS back to the client as 158 specified in Section 5.1.2 of [I-D.ietf-ace-oauth-authz]. 160 Once the client knows the authorization server's address, it can send 161 an access token request to the token endpoint at the AS as specified 162 in [I-D.ietf-ace-oauth-authz]. As the access token request as well 163 as the response may contain confidential data, the communication 164 between the client and the authorization server MUST be 165 confidentiality-protected and ensure authenticity. C may have been 166 registered at the AS via the OAuth 2.0 client registration mechanism 167 as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. 169 The access token returned by the authorization server can then be 170 used by the client to establish a new DTLS session with the resource 171 server. When the client intends to use an asymmetric proof-of- 172 possession key in the DTLS handshake with the resource server, the 173 client MUST upload the access token to the authz-info resource, i.e. 174 the authz-info endpoint, on the resource server before starting the 175 DTLS handshake, as described in Section 5.8.1 of 176 [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric 177 proof-of-possession key in the DTLS handshake, the procedure as above 178 MAY be used, or alternatively, the access token MAY instead be 179 transferred in the DTLS ClientKeyExchange message (see 180 Section 3.3.1). 182 Figure 2 depicts the common protocol flow for the DTLS profile after 183 the client C has retrieved the access token from the authorization 184 server AS. 186 C RS AS 187 | [--- Access Token ------>] | | 188 | | | 189 | <== DTLS channel setup ==> | | 190 | | | 191 | == Authorized Request ===> | | 192 | | | 193 | <=== Protected Resource == | | 195 Figure 2: Protocol overview 197 3. Protocol Flow 199 The following sections specify how CoAP is used to interchange 200 access-related data between the resource server, the client and the 201 authorization server so that the authorization server can provide the 202 client and the resource server with sufficient information to 203 establish a secure channel, and convey authorization information 204 specific for this communication relationship to the resource server. 206 Section 3.1 describes how the communication between C and AS must be 207 secured. Depending on the used CoAP security mode (see also 208 Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client 209 response and DTLS session establishment carry slightly different 210 information. Section 3.2 addresses the use of raw public keys while 211 Section 3.3 defines how pre-shared keys are used in this profile. 213 3.1. Communication between C and AS 215 To retrieve an access token for the resource that the client wants to 216 access, the client requests an access token from the authorization 217 server. Before C can request the access token, C and AS MUST 218 establish a secure communication channel. C MUST securely have 219 obtained keying material to communicate with AS. Furthermore, C MUST 220 verify that AS is authorized to provide access tokens (including 221 authorization information) about RS to C. Also, AS MUST securely 222 have obtained keying material for C, and obtained authorization rules 223 approved by the resource owner (RO) concerning C and RS that relate 224 to this keying material. C and AS MUST use their respective keying 225 material for all exchanged messages. How the security association 226 between C and AS is bootstrapped is not part of this document. C and 227 AS MUST ensure the confidentiality, integrity and authenticity of all 228 exchanged messages. 230 If C is constrained, C and AS should use DTLS to communicate with 231 each other. But C and AS may also use other means to secure their 232 communication, e.g., TLS. The used security protocol MUST fulfill 233 the communication security requirements in Section 6.2 of 234 [I-D.ietf-ace-oauth-authz]. 236 3.2. RawPublicKey Mode 238 After C and AS mutually authenticated each other and validated each 239 other's authorization, C sends a token request to AS's token 240 endpoint. The client MUST add a "req_cnf" object carrying either its 241 raw public key or a unique identifier for a public key that it has 242 previously made known to the authorization server. To prove that the 243 client is in possession of this key, C MUST use the same keying 244 material that it uses to secure the communication with AS, e.g., the 245 DTLS session. 247 An example access token request from the client to the AS is depicted 248 in Figure 3. 250 POST coaps://as.example.com/token 251 Content-Format: application/ace+cbor 252 Payload: 253 { 254 "grant_type" : "client_credentials", 255 "req_aud" : "tempSensor4711", 256 "req_cnf" : { 257 "COSE_Key" : { 258 "kty" : "EC2", 259 "crv" : "P-256", 260 "x" : h'e866c35f4c3c81bb96a1...', 261 "y" : h'2e25556be097c8778a20...' 262 } 263 } 264 } 266 Figure 3: Access Token Request Example for RPK Mode 268 The example shows an access token request for the resource identified 269 by the string "tempSensor4711" on the authorization server using a 270 raw public key. 272 AS MUST check if the client that it communicates with is associated 273 with the RPK in the cnf object before issuing an access token to it. 274 If AS determines that the request is to be authorized according to 275 the respective authorization rules, it generates an access token 276 response for C. The access token MUST be bound to the RPK of the 277 client by means of the cnf claim. The response MAY contain a 278 "profile" parameter with the value "coap_dtls" to indicate that this 279 profile MUST be used for communication between the client C and the 280 resource server. The "profile" may be specified out-of-band, in 281 which case it does not have to be sent. The response also contains 282 an access token and an "rs_cnf" parameter containing information 283 about the public key that is used by the resource server. AS MUST 284 ascertain that the RPK specified in "rs_cnf" belongs to the resource 285 server that C wants to communicate with. AS MUST protect the 286 integrity of the token. If the access token contains confidential 287 data, AS MUST also protect the confidentiality of the access token. 289 C MUST ascertain that the access token response belongs to a certain 290 previously sent access token request, as the request may specify the 291 resource server with which C wants to communicate. 293 An example access token response from the AS to the client is 294 depicted in Figure 4. 296 2.01 Created 297 Content-Format: application/ace+cbor 298 Max-Age: 3600 299 Payload: 300 { 301 "access_token" : "b64'SlAV32hkKG ... 302 (remainder of CWT omitted for brevity; 303 CWT contains clients RPK in the "cnf" claim)', 304 "expires_in" : "3600", 305 "rs_cnf" : { 306 "COSE_Key" : { 307 "kty" : "EC2", 308 "crv" : "P-256", 309 "x" : h'd7cc072de2205bdc1537...', 310 "y" : h'f95e1d4b851a2cc80fff...' 311 } 312 } 313 } 315 Figure 4: Access Token Response Example for RPK Mode 317 3.2.1. DTLS Channel Setup Between C and RS 319 Before the client initiates the DTLS handshake with the resource 320 server, C MUST send a "POST" request containing the new access token 321 to the authz-info resource hosted by the resource server. After the 322 client 323 receives a confirmation that the RS has accepted the access token, it 324 SHOULD proceed to establish a new DTLS channel with the resource 325 server. To use the RawPublicKey mode, the client MUST specify the 326 public key that AS defined in the "cnf" field of the access token 327 response in the SubjectPublicKeyInfo structure in the DTLS handshake 328 as specified in [RFC7250]. 330 An implementation that supports the RPK mode of this profile MUST at 331 least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 332 [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). 334 Note: According to [RFC7252], CoAP implementations MUST support the 335 ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] and the 336 NIST P-256 curve. As discussed in [RFC7748], new ECC curves have 337 been defined recently that are considered superior to the so- 338 called NIST curves. The curve that is mandatory to implement in 339 this specification is said to be efficient and less dangerous 340 regarding implementation errors than the secp256r1 curve mandated 341 in [RFC7252]. 343 RS MUST check if the access token is still valid, if RS is the 344 intended destination, i.e., the audience, of the token, and if the 345 token was issued by an authorized AS. The access token is 346 constructed by the authorization server such that the resource server 347 can associate the access token with the Client's public key. The 348 "cnf" claim MUST contain either C's RPK or, if the key is already 349 known by the resource server (e.g., from previous communication), a 350 reference to this key. If the authorization server has no certain 351 knowledge that the Client's key is already known to the resource 352 server, the Client's public key MUST be included in the access 353 token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as 354 recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as 355 specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the 356 keying material in the handshake that AS specified in the rs_cnf 357 parameter in the access token. Thus, the handshake only finishes if 358 C and RS are able to use their respective keying material. 360 3.3. PreSharedKey Mode 362 To retrieve an access token for the resource that the client wants to 363 access, the client MAY include a "cnf" object carrying an identifier 364 for a symmetric key in its access token request to the authorization 365 server. This identifier can be used by the authorization server to 366 determine the shared secret to construct the proof-of-possession 367 token. AS MUST check if the identifier refers to a symmetric key 368 that was previously generated by AS as a shared secret for the 369 communication between this client and the resource server. 371 The authorization server MUST determine the authorization rules for 372 the C it communicates with as defined by RO and generate the access 373 token accordingly. If the authorization server authorizes the 374 client, it returns an AS-to-Client response. If the profile 375 parameter is present, it is set to "coap_dtls". AS MUST ascertain 376 that the access token is generated for the resource server that C 377 wants to communicate with. Also, AS MUST protect the integrity of 378 the access token. If the token contains confidential data such as 379 the symmetric key, the confidentiality of the token MUST also be 380 protected. Depending on the requested token type and algorithm in 381 the access token request, the authorization server adds access 382 Information to the response that provides the client with sufficient 383 information to setup a DTLS channel with the resource server. AS 384 adds a "cnf" parameter to the access information carrying a 385 "COSE_Key" object that informs the client about the symmetric key 386 that is to be used between C and the resource server. The access 387 token MUST be bound to the same symmetric key by means of the cnf 388 claim. 390 An example access token request for an access token with a symmetric 391 proof-of-possession key is illustrated in Figure 5. 393 POST coaps://as.example.com/token 394 Content-Format: application/ace+cbor 395 Payload: 396 { 397 "audience" : "smokeSensor1807", 398 } 400 Figure 5: Example Access Token Request, symmetric PoP-key 402 An example access token response is illustrated in Figure 6. In this 403 example, the authorization server returns a 2.01 response containing 404 a new access token and information for the client, including the 405 symmetric key in the cnf claim. The information is transferred as a 406 CBOR data structure as specified in [I-D.ietf-ace-oauth-authz]. 408 2.01 Created 409 Content-Format: application/ace+cbor 410 Max-Age: 86400 411 Payload: 412 { 413 "access_token" : h'd08343a10... 414 (remainder of CWT omitted for brevity) 415 "token_type" : "pop", 416 "expires_in" : 86400, 417 "profile" : "coap_dtls", 418 "cnf" : { 419 "COSE_Key" : { 420 "kty" : "symmetric", 421 "kid" : h'3d027833fc6267ce', 422 "k" : h'73657373696f6e6b6579' 423 } 424 } 425 } 427 Figure 6: Example Access Token Response, symmetric PoP-key 429 The access token also comprises a "cnf" claim. This claim usually 430 contains a "COSE_Key" object that carries either the symmetric key 431 itself or a key identifier that can be used by the resource server to 432 determine the secret key shared with the client. If the access token 433 carries a symmetric key, the access token MUST be encrypted using a 434 "COSE_Encrypt0" structure. The AS MUST use the keying material 435 shared with the RS to encrypt the token. 437 The "cnf" structure in the access token is provided in Figure 7. 439 "cnf" : { 440 "COSE_Key" : { 441 "kty" : "symmetric", 442 "kid" : h'eIiOFCa9lObw' 443 } 444 } 446 Figure 7: Access Token without Keying Material 448 A response that declines any operation on the requested resource is 449 constructed according to Section 5.2 of [RFC6749], (cf. 450 Section 5.6.3. of [I-D.ietf-ace-oauth-authz]). 452 4.00 Bad Request 453 Content-Format: application/ace+cbor 454 Payload: 455 { 456 "error" : "invalid_request" 457 } 459 Figure 8: Example Access Token Response With Reject 461 The method for how the resource server determines the symmetric key 462 from an access token containing only a key identifier is application 463 specific, the remainder of this section provides one example. 465 The AS and the resource server are assumed to share a key derivation 466 key used to derive the symmetric key shared with the client from the 467 key identifier in the access token. The key derivation key may be 468 derived 469 from some other secret key shared between the AS and the resource 470 server. This key needs to be securely stored and processed in the 471 same way as the key used to protect the communication between AS and 472 RS. 474 Knowledge of the symmetric key shared with the client must not reveal 475 any information about the key derivation key or other secret keys 476 shared between AS and resource server. 478 In order to generate a new symmetric key to be used by client and 479 resource server, the AS generates a key identifier and uses the key 480 derivation key shared with the resource server to derive the 481 symmetric key as specified below. Instead of providing the keying 482 material in the access token, the AS includes the key identifier in 483 the "kid" parameter, see Figure 7. This key identifier enables the 484 resource server to calculate the keying material for the 485 communication with the client from the access token using the key 486 derivation key and following Section 11 of [RFC8152] with parameters 487 as specified here. The KDF to be used needs to be defined by the 488 application, for example HKDF-SHA-256. The key identifier picked by 489 the AS needs to be unique for each access token where a unique 490 symmetric key is required. 492 The fields in the context information "COSE_KDF_Context" 493 (Section 11.2 of [RFC8152]) have the following values: 495 o AlgorithmID = "ACE-CoAP-DTLS-key-derivation" 497 o PartyUInfo = PartyVInfo = ( null, null, null ) 499 o keyDataLength needs to be defined by the application 500 o protected MUST be a zero length bstr 502 o other is a zero length bstr 504 o SuppPrivInfo is omitted 506 3.3.1. DTLS Channel Setup Between C and RS 508 When a client receives an access token response from an authorization 509 server, C MUST ascertain that the access token response belongs to a 510 certain previously sent access token request, as the request may 511 specify the resource server with which C wants to communicate. 513 C checks if the payload of the access token response contains an 514 "access_token" parameter and a "cnf" parameter. With this 515 information the client can initiate the establishment of a new DTLS 516 channel with a resource server. To use DTLS with pre-shared keys, 517 the client follows the PSK key exchange algorithm specified in 518 Section 2 of [RFC4279] using the key conveyed in the "cnf" parameter 519 of the AS response as PSK when constructing the premaster secret. 521 In PreSharedKey mode, the knowledge of the shared secret by the 522 client and the resource server is used for mutual authentication 523 between both peers. Therefore, the resource server must be able to 524 determine the shared secret from the access token. Following the 525 general ACE authorization framework, the client can upload the access 526 token to the resource server's authz-info resource before starting 527 the DTLS handshake. Alternatively, the client MAY provide the most 528 recent access token in the "psk_identity" field of the 529 ClientKeyExchange message. To do so, the client MUST treat the 530 contents of the "access_token" field from the AS-to-Client response 531 as opaque data and not perform any re-coding. 533 Note: As stated in Section 4.2 of [RFC7925], the PSK identity should 534 be treated as binary data in the Internet of Things space and not 535 assumed to have a human-readable form of any sort. 537 If a resource server receives a ClientKeyExchange message that 538 contains a "psk_identity" with a length greater zero, it uses the 539 contents as index for its key store (i.e., treat the contents as key 540 identifier). The resource server MUST check if it has one or more 541 access tokens that are associated with the specified key. 543 If no key with a matching identifier is found, the resource server 544 MAY process the contents of the "psk_identity" field as access token 545 that is stored with the authorization information endpoint, before 546 continuing the DTLS handshake. If the contents of the "psk_identity" 547 do not yield a valid access token for the requesting client, the DTLS 548 session setup is terminated with an "illegal_parameter" DTLS alert 549 message. 551 Note1: As a resource server cannot provide a client with a 552 meaningful PSK identity hint in response to the client's 553 ClientHello message, the resource server SHOULD NOT send a 554 ServerKeyExchange message. 556 Note2: According to [RFC7252], CoAP implementations MUST support the 557 ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is 558 therefore expected to offer at least this ciphersuite to the 559 resource server. 561 When RS receives an access token, RS MUST check if the access token 562 is still valid, if RS is the intended destination, i.e., the audience 563 of the token, and if the token was issued by an authorized AS. This 564 specification assumes that the access token is a PoP token as 565 described in [I-D.ietf-ace-oauth-authz] unless specifically stated 566 otherwise. Therefore, the access token is bound to a symmetric PoP 567 key that is used as shared secret between the client and the resource 568 server. 570 While the client can retrieve the shared secret from the contents of 571 the "cnf" parameter in the AS-to-Client response, the resource server 572 uses the information contained in the "cnf" claim of the access token 573 to determine the actual secret when no explicit "kid" was provided in 574 the "psk_identity" field. If key derivation is used, the RS uses the 575 "COSE_KDF_Context" information as described above. 577 3.4. Resource Access 579 Once a DTLS channel has been established as described in Section 3.2 580 and Section 3.3, respectively, the client is authorized to access 581 resources covered by the access token it has uploaded to the authz- 582 info resource hosted by the resource server. 584 With the successful establishment of the DTLS channel, C and RS have 585 proven that they can use their respective keying material. An access 586 token that is bound to the client's keying material is associated 587 with the channel. Any request that the resource server receives on 588 this channel MUST be checked against these authorization rules. RS 589 MUST check for every request if the access token is still valid. 590 Incoming CoAP requests that are not authorized with respect to any 591 access token that is associated with the client MUST be rejected by 592 the resource server with 4.01 response as described in Section 5.1.1 593 of [I-D.ietf-ace-oauth-authz]. 595 The resource server SHOULD treat an incoming CoAP request as 596 authorized if the following holds: 598 1. The message was received on a secure channel that has been 599 established using the procedure defined in this document. 601 2. The authorization information tied to the sending client is 602 valid. 604 3. The request is destined for the resource server. 606 4. The resource URI specified in the request is covered by the 607 authorization information. 609 5. The request method is an authorized action on the resource with 610 respect to the authorization information. 612 Incoming CoAP requests received on a secure DTLS channel that are not 613 thus authorized MUST be rejected according to Section 5.8.2 of 614 [I-D.ietf-ace-oauth-authz] 616 1. with response code 4.03 (Forbidden) when the resource URI 617 specified in the request is not covered by the authorization 618 information, and 620 2. with response code 4.05 (Method Not Allowed) when the resource 621 URI specified in the request covered by the authorization 622 information but not the requested action. 624 The client cannot always know a priori if an Authorized Resource 625 Request will succeed. It MUST check the validity of its keying 626 material before sending a request or processing a response. If the 627 client repeatedly gets error responses containing AS Creation Hints 628 (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its 629 requests, it SHOULD request a new access token from the authorization 630 server in order to continue communication with the resource server. 632 Unauthorized requests that have been received over a DTLS session 633 SHOULD be treated as non-fatal by the RS, i.e., the DTLS session 634 SHOULD be kept alive until the associated access token has expired. 636 4. Dynamic Update of Authorization Information 638 The client can update the authorization information stored at the 639 resource server at any time without changing an established DTLS 640 session. To do so, the Client requests a new access token from the 641 authorization server for the intended action on the respective 642 resource and uploads this access token to the authz-info resource on 643 the resource server. 645 Figure 9 depicts the message flow where the C requests a new access 646 token after a security association between the client and the 647 resource server has been established using this protocol. If the 648 client wants to update the authorization information, the token 649 request MUST specify the key identifier of the proof-of-possession 650 key used for the existing DTLS channel between the client and the 651 resource server in the "kid" parameter of the Client-to-AS request. 652 The authorization server MUST verify that the specified "kid" denotes 653 a valid verifier for a proof-of-possession token that has previously 654 been issued to the requesting client. Otherwise, the Client-to-AS 655 request MUST be declined with the error code "unsupported_pop_key" as 656 defined in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 658 When the authorization server issues a new access token to update 659 existing authorization information, it MUST include the specified 660 "kid" parameter in this access token. A resource server MUST replace 661 the authorization information of any existing DTLS session that is 662 identified by this key identifier with the updated authorization 663 information. 665 Note: By associating the access tokens with the identifier of an 666 existing DTLS session, the authorization information can be 667 updated without changing the cryptographic keys for the DTLS 668 communication between the client and the resource server, i.e. an 669 existing session can be used with updated permissions. 671 C RS AS 672 | <===== DTLS channel =====> | | 673 | + Access Token | | 674 | | | 675 | --- Token Request ----------------------------> | 676 | | | 677 | <---------------------------- New Access Token - | 678 | + Access Information | 679 | | | 680 | --- Update /authz-info --> | | 681 | New Access Token | | 682 | | | 683 | == Authorized Request ===> | | 684 | | | 685 | <=== Protected Resource == | | 687 Figure 9: Overview of Dynamic Update Operation 689 5. Token Expiration 691 DTLS sessions that have been established in accordance with this 692 profile are always tied to a specific access token. As this token 693 may become invalid at any time (e.g. because it has expired), the 694 session may become useless at some point. A resource server 695 therefore MUST terminate existing DTLS sessions after the access 696 token for this session has been deleted. 698 As specified in Section 5.8.3 of [I-D.ietf-ace-oauth-authz], the 699 resource server MUST notify the client with an error response with 700 code 4.01 (Unauthorized) for any long running request before 701 terminating the session. 703 6. Security Considerations 705 This document specifies a profile for the Authentication and 706 Authorization for Constrained Environments (ACE) framework 707 [I-D.ietf-ace-oauth-authz]. As it follows this framework's general 708 approach, the general security considerations from section 6 also 709 apply to this profile. 711 When using pre-shared keys provisioned by the AS, the security level 712 depends on the randomness of PSK, and the security of the TLS cipher 713 suite and key exchange algorithm. 715 Constrained devices that use DTLS [RFC6347] are inherently vulnerable 716 to Denial of Service (DoS) attacks as the handshake protocol requires 717 creation of internal state within the device. This is specifically 718 of concern where an adversary is able to intercept the initial cookie 719 exchange and interject forged messages with a valid cookie to 720 continue with the handshake. A similar issue exists with the 721 authorization information endpoint where the resource server needs to 722 keep valid access tokens until their expiry. Adversaries can fill up 723 the constrained resource server's internal storage for a very long 724 time with interjected or otherwise retrieved valid access tokens. 726 The use of multiple access tokens for a single client increases the 727 strain on the resource server as it must consider every access token 728 and calculate the actual permissions of the client. Also, tokens may 729 contradict each other which may lead the server to enforce wrong 730 permissions. If one of the access tokens expires earlier than 731 others, the resulting permissions may offer insufficient protection. 732 Developers SHOULD avoid using multiple access tokens for a client. 734 7. Privacy Considerations 736 This privacy considerations from section 7 of the 737 [I-D.ietf-ace-oauth-authz] apply also to this profile. 739 An unprotected response to an unauthorized request may disclose 740 information about the resource server and/or its existing 741 relationship with the client. It is advisable to include as little 742 information as possible in an unencrypted response. When a DTLS 743 session between the client and the resource server already exists, 744 more detailed information MAY be included with an error response to 745 provide the client with sufficient information to react on that 746 particular error. 748 Also, unprotected requests to the resource server may reveal 749 information about the client, e.g., which resources the client 750 attempts to request or the data that the client wants to provide to 751 the resource server. The client SHOULD NOT send confidential data in 752 an unprotected request. 754 Note that some information might still leak after DTLS session is 755 established, due to observable message sizes, the source, and the 756 destination addresses. 758 8. IANA Considerations 760 The following registrations are done for the ACE OAuth Profile 761 Registry following the procedure specified in 762 [I-D.ietf-ace-oauth-authz]. 764 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 765 with the RFC number of this specification and delete this paragraph. 767 Profile name: coap_dtls 769 Profile Description: Profile for delegating client authentication and 770 authorization in a constrained environment by establishing a Datagram 771 Transport Layer Security (DTLS) channel between resource-constrained 772 nodes. 774 Profile ID: 1 776 Change Controller: IESG 778 Reference: [RFC-XXXX] 780 9. References 782 9.1. Normative References 784 [I-D.ietf-ace-cwt-proof-of-possession] 785 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 786 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 787 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 788 possession-06 (work in progress), February 2019. 790 [I-D.ietf-ace-oauth-authz] 791 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 792 H. Tschofenig, "Authentication and Authorization for 793 Constrained Environments (ACE) using the OAuth 2.0 794 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 795 (work in progress), March 2019. 797 [I-D.ietf-ace-oauth-params] 798 Seitz, L., "Additional OAuth Parameters for Authorization 799 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 800 params-04 (work in progress), February 2019. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 808 Ciphersuites for Transport Layer Security (TLS)", 809 RFC 4279, DOI 10.17487/RFC4279, December 2005, 810 . 812 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 813 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 814 January 2012, . 816 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 817 RFC 6749, DOI 10.17487/RFC6749, October 2012, 818 . 820 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 821 Application Protocol (CoAP)", RFC 7252, 822 DOI 10.17487/RFC7252, June 2014, 823 . 825 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 826 Security (TLS) / Datagram Transport Layer Security (DTLS) 827 Profiles for the Internet of Things", RFC 7925, 828 DOI 10.17487/RFC7925, July 2016, 829 . 831 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 832 RFC 8152, DOI 10.17487/RFC8152, July 2017, 833 . 835 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 836 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 837 May 2017, . 839 9.2. Informative References 841 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 842 Transport Layer Security (TLS)", RFC 6655, 843 DOI 10.17487/RFC6655, July 2012, 844 . 846 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 847 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 848 Transport Layer Security (TLS) and Datagram Transport 849 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 850 June 2014, . 852 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 853 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 854 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 855 . 857 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 858 for Security", RFC 7748, DOI 10.17487/RFC7748, January 859 2016, . 861 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 862 Signature Algorithm (EdDSA)", RFC 8032, 863 DOI 10.17487/RFC8032, January 2017, 864 . 866 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 867 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 868 May 2018, . 870 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 871 Curve Cryptography (ECC) Cipher Suites for Transport Layer 872 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 873 DOI 10.17487/RFC8422, August 2018, 874 . 876 Authors' Addresses 878 Stefanie Gerdes 879 Universitaet Bremen TZI 880 Postfach 330440 881 Bremen D-28359 882 Germany 884 Phone: +49-421-218-63906 885 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 909 Ludwig Seitz 910 RISE SICS 911 Scheelevaegen 17 912 Lund 223 70 913 Sweden 915 Email: ludwig.seitz@ri.se