idnits 2.17.1 draft-ietf-ace-dtls-authorize-09.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 (December 18, 2019) is 1588 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 789, but not defined == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-29 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-07 ** 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 (==), 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: June 20, 2020 Universitaet Bremen TZI 6 G. Selander 7 Ericsson AB 8 L. Seitz 9 Combitech 10 December 18, 2019 12 Datagram Transport Layer Security (DTLS) Profile for Authentication and 13 Authorization for Constrained Environments (ACE) 14 draft-ietf-ace-dtls-authorize-09 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 June 20, 2020. 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. Secure Communication with AS . . . . . . . . . . . . . . . . 16 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 79 10.2. Informative References . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 This specification defines a profile of the ACE framework 85 [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource 86 server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The 87 client obtains an access token, bound to a key (the proof-of- 88 possession key), from an authorization server to prove its 89 authorization to access protected resources hosted by the resource 90 server. Also, the client and the resource server are provided by the 91 authorization server with the necessary keying material to establish 92 a DTLS session. The communication between client and authorization 93 server may also be secured with DTLS. This specification supports 94 DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys 95 (PSK) [RFC4279]. 97 The DTLS handshake requires the client and server to prove that they 98 can use certain keying material. In the RPK mode, the client proves 99 with the DTLS handshake that it can use the RPK bound to the token 100 and the server shows that it can use a certain RPK. The access token 101 must be presented to the resource server. For the RPK mode, the 102 access token needs to be uploaded to the resource server before the 103 handshake is initiated, as described in Section 5.8.1 of the ACE 104 framework [I-D.ietf-ace-oauth-authz]. 106 In the PSK mode, client and server show with the DTLS handshake that 107 they can use the keying material that is bound to the access token. 108 To transfer the access token from the client to the resource server, 109 the "psk_identity" parameter in the DTLS PSK handshake may be used 110 instead of uploading the token prior to the handshake. 112 1.1. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 Readers are expected to be familiar with the terms and concepts 121 described in [I-D.ietf-ace-oauth-authz] and in 122 [I-D.ietf-ace-oauth-params]. 124 The authorization information (authz-info) resource refers to the 125 authorization information endpoint as specified in 126 [I-D.ietf-ace-oauth-authz]. 128 2. Protocol Overview 130 The CoAP-DTLS profile for ACE specifies the transfer of 131 authentication information and, if necessary, authorization 132 information between the client (C) and the resource server (RS) 133 during setup of a DTLS session for CoAP messaging. It also specifies 134 how C can use CoAP over DTLS to retrieve an access token from the 135 authorization server (AS) for a protected resource hosted on the 136 resource server. 138 This profile requires the client to retrieve an access token for 139 protected resource(s) it wants to access on RS as specified in 140 [I-D.ietf-ace-oauth-authz]. Figure 1 shows the typical message flow 141 in this scenario (messages in square brackets are optional): 143 C RS AS 144 | [---- Resource Request ------>]| | 145 | | | 146 | [<-AS Request Creation Hints-] | | 147 | | | 148 | ------- Token Request ----------------------------> | 149 | | | 150 | <---------------------------- Access Token --------- | 151 | + Access Information | 153 Figure 1: Retrieving an Access Token 155 To determine the AS in charge of a resource hosted at the RS, C MAY 156 send an initial Unauthorized Resource Request message to the RS. The 157 RS then denies the request and sends an AS Request Creation Hints 158 message containing the address of its AS back to the client as 159 specified in Section 5.1.2 of [I-D.ietf-ace-oauth-authz]. 161 Once the client knows the authorization server's address, it can send 162 an access token request to the token endpoint at the AS as specified 163 in [I-D.ietf-ace-oauth-authz]. As the access token request as well 164 as the response may contain confidential data, the communication 165 between the client and the authorization server MUST be 166 confidentiality-protected and ensure authenticity. C may have been 167 registered at the AS via the OAuth 2.0 client registration mechanism 168 as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. 170 The access token returned by the authorization server can then be 171 used by the client to establish a new DTLS session with the resource 172 server. When the client intends to use an asymmetric proof-of- 173 possession key in the DTLS handshake with the resource server, the 174 client MUST upload the access token to the authz-info resource, i.e. 175 the authz-info endpoint, on the resource server before starting the 176 DTLS handshake, as described in Section 5.8.1 of 177 [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric 178 proof-of-possession key in the DTLS handshake, the procedure as above 179 MAY be used, or alternatively, the access token MAY instead be 180 transferred in the DTLS ClientKeyExchange message (see 181 Section 3.3.1). 183 Figure 2 depicts the common protocol flow for the DTLS profile after 184 the client C has retrieved the access token from the authorization 185 server AS. 187 C RS AS 188 | [--- Access Token ------>] | | 189 | | | 190 | <== DTLS channel setup ==> | | 191 | | | 192 | == Authorized Request ===> | | 193 | | | 194 | <=== Protected Resource == | | 196 Figure 2: Protocol overview 198 3. Protocol Flow 200 The following sections specify how CoAP is used to interchange 201 access-related data between the resource server, the client and the 202 authorization server so that the authorization server can provide the 203 client and the resource server with sufficient information to 204 establish a secure channel, and convey authorization information 205 specific for this communication relationship to the resource server. 207 Section 3.1 describes how the communication between C and AS must be 208 secured. Depending on the used CoAP security mode (see also 209 Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client 210 response and DTLS session establishment carry slightly different 211 information. Section 3.2 addresses the use of raw public keys while 212 Section 3.3 defines how pre-shared keys are used in this profile. 214 3.1. Communication between C and AS 216 To retrieve an access token for the resource that the client wants to 217 access, the client requests an access token from the authorization 218 server. Before C can request the access token, C and AS MUST 219 establish a secure communication channel. C MUST securely have 220 obtained keying material to communicate with AS. Furthermore, C MUST 221 verify that AS is authorized to provide access tokens (including 222 authorization information) about RS to C. Also, AS MUST securely 223 have obtained keying material for C, and obtained authorization rules 224 approved by the resource owner (RO) concerning C and RS that relate 225 to this keying material. C and AS MUST use their respective keying 226 material for all exchanged messages. How the security association 227 between C and AS is bootstrapped is not part of this document. C and 228 AS MUST ensure the confidentiality, integrity and authenticity of all 229 exchanged messages. 231 Section Section 6 specifies how communication with the AS is secured. 233 3.2. RawPublicKey Mode 235 After C and AS mutually authenticated each other and validated each 236 other's authorization, C sends a token request to AS's token 237 endpoint. The client MUST add a "req_cnf" object carrying either its 238 raw public key or a unique identifier for a public key that it has 239 previously made known to the authorization server. To prove that the 240 client is in possession of this key, C MUST use the same keying 241 material that it uses to secure the communication with AS, e.g., the 242 DTLS session. 244 An example access token request from the client to the AS is depicted 245 in Figure 3. 247 POST coaps://as.example.com/token 248 Content-Format: application/ace+cbor 249 Payload: 250 { 251 grant_type : client_credentials, 252 req_aud : "tempSensor4711", 253 req_cnf : { 254 COSE_Key : { 255 kty : EC2, 256 crv : P-256, 257 x : h'e866c35f4c3c81bb96a1...', 258 y : h'2e25556be097c8778a20...' 259 } 260 } 261 } 263 Figure 3: Access Token Request Example for RPK Mode 265 The example shows an access token request for the resource identified 266 by the string "tempSensor4711" on the authorization server using a 267 raw public key. 269 AS MUST check if the client that it communicates with is associated 270 with the RPK in the cnf object before issuing an access token to it. 271 If AS determines that the request is to be authorized according to 272 the respective authorization rules, it generates an access token 273 response for C. The access token MUST be bound to the RPK of the 274 client by means of the cnf claim. The response MAY contain a 275 "profile" parameter with the value "coap_dtls" to indicate that this 276 profile MUST be used for communication between the client C and the 277 resource server. The "profile" may be specified out-of-band, in 278 which case it does not have to be sent. The response also contains 279 an access token and an "rs_cnf" parameter containing information 280 about the public key that is used by the resource server. AS MUST 281 ascertain that the RPK specified in "rs_cnf" belongs to the resource 282 server that C wants to communicate with. AS MUST protect the 283 integrity of the token. If the access token contains confidential 284 data, AS MUST also protect the confidentiality of the access token. 286 C MUST ascertain that the access token response belongs to a certain 287 previously sent access token request, as the request may specify the 288 resource server with which C wants to communicate. 290 An example access token response from the AS to the client is 291 depicted in Figure 4. 293 2.01 Created 294 Content-Format: application/ace+cbor 295 Max-Age: 3600 296 Payload: 297 { 298 access_token : b64'SlAV32hkKG... 299 (remainder of CWT omitted for brevity; 300 CWT contains clients RPK in the cnf claim)', 301 expires_in : 3600, 302 rs_cnf : { 303 COSE_Key : { 304 kty : EC2, 305 crv : P-256, 306 x : h'd7cc072de2205bdc1537...', 307 y : h'f95e1d4b851a2cc80fff...' 308 } 309 } 310 } 312 Figure 4: Access Token Response Example for RPK Mode 314 3.2.1. DTLS Channel Setup Between C and RS 316 Before the client initiates the DTLS handshake with the resource 317 server, C MUST send a "POST" request containing the new access token 318 to the authz-info resource hosted by the resource server. After the 319 client 320 receives a confirmation that the RS has accepted the access token, it 321 SHOULD proceed to establish a new DTLS channel with the resource 322 server. To use the RawPublicKey mode, the client MUST specify the 323 public key that AS defined in the "cnf" field of the access token 324 response in the SubjectPublicKeyInfo structure in the DTLS handshake 325 as specified in [RFC7250]. 327 An implementation that supports the RPK mode of this profile MUST at 328 least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 329 [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). 331 Note: According to [RFC7252], CoAP implementations MUST support the 332 ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] and the 333 NIST P-256 curve. As discussed in [RFC7748], new ECC curves have 334 been defined recently that are considered superior to the so- 335 called NIST curves. The curve that is mandatory to implement in 336 this specification is said to be efficient and less dangerous 337 regarding implementation errors than the secp256r1 curve mandated 338 in [RFC7252]. 340 RS MUST check if the access token is still valid, if RS is the 341 intended destination, i.e., the audience, of the token, and if the 342 token was issued by an authorized AS. The access token is 343 constructed by the authorization server such that the resource server 344 can associate the access token with the Client's public key. The 345 "cnf" claim MUST contain either C's RPK or, if the key is already 346 known by the resource server (e.g., from previous communication), a 347 reference to this key. If the authorization server has no certain 348 knowledge that the Client's key is already known to the resource 349 server, the Client's public key MUST be included in the access 350 token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as 351 recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as 352 specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the 353 keying material in the handshake that AS specified in the rs_cnf 354 parameter in the access token. Thus, the handshake only finishes if 355 C and RS are able to use their respective keying material. 357 3.3. PreSharedKey Mode 359 To retrieve an access token for the resource that the client wants to 360 access, the client MAY include a "cnf" object carrying an identifier 361 for a symmetric key in its access token request to the authorization 362 server. This identifier can be used by the authorization server to 363 determine the shared secret to construct the proof-of-possession 364 token. AS MUST check if the identifier refers to a symmetric key 365 that was previously generated by AS as a shared secret for the 366 communication between this client and the resource server. 368 The authorization server MUST determine the authorization rules for 369 the C it communicates with as defined by RO and generate the access 370 token accordingly. If the authorization server authorizes the 371 client, it returns an AS-to-Client response. If the profile 372 parameter is present, it is set to "coap_dtls". AS MUST ascertain 373 that the access token is generated for the resource server that C 374 wants to communicate with. Also, AS MUST protect the integrity of 375 the access token. If the token contains confidential data such as 376 the symmetric key, the confidentiality of the token MUST also be 377 protected. Depending on the requested token type and algorithm in 378 the access token request, the authorization server adds access 379 Information to the response that provides the client with sufficient 380 information to setup a DTLS channel with the resource server. AS 381 adds a "cnf" parameter to the access information carrying a 382 "COSE_Key" object that informs the client about the symmetric key 383 that is to be used between C and the resource server. The access 384 token MUST be bound to the same symmetric key by means of the cnf 385 claim. 387 An example access token request for an access token with a symmetric 388 proof-of-possession key is illustrated in Figure 5. 390 POST coaps://as.example.com/token 391 Content-Format: application/ace+cbor 392 Payload: 393 { 394 audience : "smokeSensor1807", 395 } 397 Figure 5: Example Access Token Request, symmetric PoP-key 399 An example access token response is illustrated in Figure 6. In this 400 example, the authorization server returns a 2.01 response containing 401 a new access token and information for the client, including the 402 symmetric key in the cnf claim. The information is transferred as a 403 CBOR data structure as specified in [I-D.ietf-ace-oauth-authz]. 405 2.01 Created 406 Content-Format: application/ace+cbor 407 Max-Age: 86400 408 Payload: 409 { 410 access_token : h'd08343a10... 411 (remainder of CWT omitted for brevity) 412 token_type : pop, 413 expires_in : 86400, 414 profile : coap_dtls, 415 cnf : { 416 COSE_Key : { 417 kty : symmetric, 418 kid : h'3d027833fc6267ce', 419 k : h'73657373696f6e6b6579' 420 } 421 } 422 } 424 Figure 6: Example Access Token Response, symmetric PoP-key 426 The access token also comprises a "cnf" claim. This claim usually 427 contains a "COSE_Key" object that carries either the symmetric key 428 itself or a key identifier that can be used by the resource server to 429 determine the secret key shared with the client. If the access token 430 carries a symmetric key, the access token MUST be encrypted using a 431 "COSE_Encrypt0" structure. The AS MUST use the keying material 432 shared with the RS to encrypt the token. 434 The "cnf" structure in the access token is provided in Figure 7. 436 cnf : { 437 COSE_Key : { 438 kty : symmetric, 439 kid : h'6549694f464361396c4f6277' 440 } 441 } 443 Figure 7: Access Token without Keying Material 445 A response that declines any operation on the requested resource is 446 constructed according to Section 5.2 of [RFC6749], (cf. 447 Section 5.6.3. of [I-D.ietf-ace-oauth-authz]). 449 4.00 Bad Request 450 Content-Format: application/ace+cbor 451 Payload: 452 { 453 error : invalid_request 454 } 456 Figure 8: Example Access Token Response With Reject 458 The method for how the resource server determines the symmetric key 459 from an access token containing only a key identifier is application 460 specific, the remainder of this section provides one example. 462 The AS and the resource server are assumed to share a key derivation 463 key used to derive the symmetric key shared with the client from the 464 key identifier in the access token. The key derivation key may be 465 derived from some other secret key shared between the AS and the 466 resource server. This key needs to be securely stored and processed 467 in the same way as the key used to protect the communication between 468 AS and RS. 470 Knowledge of the symmetric key shared with the client must not reveal 471 any information about the key derivation key or other secret keys 472 shared between AS and resource server. 474 In order to generate a new symmetric key to be used by client and 475 resource server, the AS generates a key identifier and uses the key 476 derivation key shared with the resource server to derive the 477 symmetric key as specified below. Instead of providing the keying 478 material in the access token, the AS includes the key identifier in 479 the "kid" parameter, see Figure 7. This key identifier enables the 480 resource server to calculate the keying material for the 481 communication with the client from the access token using the key 482 derivation key and following Section 11 of [RFC8152] with parameters 483 as specified here. The KDF to be used needs to be defined by the 484 application, for example HKDF-SHA-256. The key identifier picked by 485 the AS needs to be unique for each access token where a unique 486 symmetric key is required. 488 The fields in the context information "COSE_KDF_Context" 489 (Section 11.2 of [RFC8152]) have the following values: 491 o AlgorithmID = "ACE-CoAP-DTLS-key-derivation" 493 o PartyUInfo = PartyVInfo = ( null, null, null ) 495 o keyDataLength needs to be defined by the application 496 o protected MUST be a zero length bstr 498 o other is a zero length bstr 500 o SuppPrivInfo is omitted 502 3.3.1. DTLS Channel Setup Between C and RS 504 When a client receives an access token response from an authorization 505 server, C MUST ascertain that the access token response belongs to a 506 certain previously sent access token request, as the request may 507 specify the resource server with which C wants to communicate. 509 C checks if the payload of the access token response contains an 510 "access_token" parameter and a "cnf" parameter. With this 511 information the client can initiate the establishment of a new DTLS 512 channel with a resource server. To use DTLS with pre-shared keys, 513 the client follows the PSK key exchange algorithm specified in 514 Section 2 of [RFC4279] using the key conveyed in the "cnf" parameter 515 of the AS response as PSK when constructing the premaster secret. 517 In PreSharedKey mode, the knowledge of the shared secret by the 518 client and the resource server is used for mutual authentication 519 between both peers. Therefore, the resource server must be able to 520 determine the shared secret from the access token. Following the 521 general ACE authorization framework, the client can upload the access 522 token to the resource server's authz-info resource before starting 523 the DTLS handshake. Alternatively, the client MAY provide the most 524 recent access token in the "psk_identity" field of the 525 ClientKeyExchange message. To do so, the client MUST treat the 526 contents of the "access_token" field from the AS-to-Client response 527 as opaque data and not perform any re-coding. 529 Note: As stated in Section 4.2 of [RFC7925], the PSK identity should 530 be treated as binary data in the Internet of Things space and not 531 assumed to have a human-readable form of any sort. 533 If a resource server receives a ClientKeyExchange message that 534 contains a "psk_identity" with a length greater zero, it uses the 535 contents as index for its key store (i.e., treat the contents as key 536 identifier). The resource server MUST check if it has one or more 537 access tokens that are associated with the specified key. 539 If no key with a matching identifier is found, the resource server 540 MAY process the contents of the "psk_identity" field as access token 541 that is stored with the authorization information endpoint, before 542 continuing the DTLS handshake. If the contents of the "psk_identity" 543 do not yield a valid access token for the requesting client, the DTLS 544 session setup is terminated with an "illegal_parameter" DTLS alert 545 message. 547 Note1: As a resource server cannot provide a client with a 548 meaningful PSK identity hint in response to the client's 549 ClientHello message, the resource server SHOULD NOT send a 550 ServerKeyExchange message. 552 Note2: According to [RFC7252], CoAP implementations MUST support the 553 ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is 554 therefore expected to offer at least this ciphersuite to the 555 resource server. 557 When RS receives an access token, RS MUST check if the access token 558 is still valid, if RS is the intended destination, i.e., the audience 559 of the token, and if the token was issued by an authorized AS. This 560 specification assumes that the access token is a PoP token as 561 described in [I-D.ietf-ace-oauth-authz] unless specifically stated 562 otherwise. Therefore, the access token is bound to a symmetric PoP 563 key that is used as shared secret between the client and the resource 564 server. 566 While the client can retrieve the shared secret from the contents of 567 the "cnf" parameter in the AS-to-Client response, the resource server 568 uses the information contained in the "cnf" claim of the access token 569 to determine the actual secret when no explicit "kid" was provided in 570 the "psk_identity" field. If key derivation is used, the RS uses the 571 "COSE_KDF_Context" information as described above. 573 3.4. Resource Access 575 Once a DTLS channel has been established as described in Section 3.2 576 and Section 3.3, respectively, the client is authorized to access 577 resources covered by the access token it has uploaded to the authz- 578 info resource hosted by the resource server. 580 With the successful establishment of the DTLS channel, C and RS have 581 proven that they can use their respective keying material. An access 582 token that is bound to the client's keying material is associated 583 with the channel. Any request that the resource server receives on 584 this channel MUST be checked against these authorization rules. RS 585 MUST check for every request if the access token is still valid. 586 Incoming CoAP requests that are not authorized with respect to any 587 access token that is associated with the client MUST be rejected by 588 the resource server with 4.01 response as described in Section 5.1.1 589 of [I-D.ietf-ace-oauth-authz]. 591 The resource server SHOULD treat an incoming CoAP request as 592 authorized if the following holds: 594 1. The message was received on a secure channel that has been 595 established using the procedure defined in this document. 597 2. The authorization information tied to the sending client is 598 valid. 600 3. The request is destined for the resource server. 602 4. The resource URI specified in the request is covered by the 603 authorization information. 605 5. The request method is an authorized action on the resource with 606 respect to the authorization information. 608 Incoming CoAP requests received on a secure DTLS channel that are not 609 thus authorized MUST be rejected according to Section 5.8.2 of 610 [I-D.ietf-ace-oauth-authz] 612 1. with response code 4.03 (Forbidden) when the resource URI 613 specified in the request is not covered by the authorization 614 information, and 616 2. with response code 4.05 (Method Not Allowed) when the resource 617 URI specified in the request covered by the authorization 618 information but not the requested action. 620 The client cannot always know a priori if an Authorized Resource 621 Request will succeed. It MUST check the validity of its keying 622 material before sending a request or processing a response. If the 623 client repeatedly gets error responses containing AS Creation Hints 624 (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its 625 requests, it SHOULD request a new access token from the authorization 626 server in order to continue communication with the resource server. 628 Unauthorized requests that have been received over a DTLS session 629 SHOULD be treated as non-fatal by the RS, i.e., the DTLS session 630 SHOULD be kept alive until the associated access token has expired. 632 4. Dynamic Update of Authorization Information 634 The client can update the authorization information stored at the 635 resource server at any time without changing an established DTLS 636 session. To do so, the Client requests a new access token from the 637 authorization server for the intended action on the respective 638 resource and uploads this access token to the authz-info resource on 639 the resource server. 641 Figure 9 depicts the message flow where the C requests a new access 642 token after a security association between the client and the 643 resource server has been established using this protocol. If the 644 client wants to update the authorization information, the token 645 request MUST specify the key identifier of the proof-of-possession 646 key used for the existing DTLS channel between the client and the 647 resource server in the "kid" parameter of the Client-to-AS request. 648 The authorization server MUST verify that the specified "kid" denotes 649 a valid verifier for a proof-of-possession token that has previously 650 been issued to the requesting client. Otherwise, the Client-to-AS 651 request MUST be declined with the error code "unsupported_pop_key" as 652 defined in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 654 When the authorization server issues a new access token to update 655 existing authorization information, it MUST include the specified 656 "kid" parameter in this access token. A resource server MUST replace 657 the authorization information of any existing DTLS session that is 658 identified by this key identifier with the updated authorization 659 information. 661 Note: By associating the access tokens with the identifier of an 662 existing DTLS session, the authorization information can be 663 updated without changing the cryptographic keys for the DTLS 664 communication between the client and the resource server, i.e. an 665 existing session can be used with updated permissions. 667 C RS AS 668 | <===== DTLS channel =====> | | 669 | + Access Token | | 670 | | | 671 | --- Token Request ----------------------------> | 672 | | | 673 | <---------------------------- New Access Token - | 674 | + Access Information | 675 | | | 676 | --- Update /authz-info --> | | 677 | New Access Token | | 678 | | | 679 | == Authorized Request ===> | | 680 | | | 681 | <=== Protected Resource == | | 683 Figure 9: Overview of Dynamic Update Operation 685 5. Token Expiration 687 DTLS sessions that have been established in accordance with this 688 profile are always tied to a specific access token. As this token 689 may become invalid at any time (e.g. because it has expired), the 690 session may become useless at some point. A resource server 691 therefore MUST terminate existing DTLS sessions after the access 692 token for this session has been deleted. 694 As specified in Section 5.8.3 of [I-D.ietf-ace-oauth-authz], the 695 resource server MUST notify the client with an error response with 696 code 4.01 (Unauthorized) for any long running request before 697 terminating the session. 699 6. Secure Communication with AS 701 As specified in the ACE framework (sections 5.6 and 5.7 of 702 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) 703 and the AS communicate via the token endpoint or introspection 704 endpoint. The use of CoAP and DTLS for this communication is 705 RECOMMENDED in this profile, other protocols (such as HTTP and TLS or 706 CoAP and OSCORE) MAY be used instead. 708 How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the 709 AS are established is out of scope for this profile. 711 If other means of securing the communication with the AS are used, 712 the security protocol MUST fulfill the communication security 713 requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. 715 7. Security Considerations 717 This document specifies a profile for the Authentication and 718 Authorization for Constrained Environments (ACE) framework 719 [I-D.ietf-ace-oauth-authz]. As it follows this framework's general 720 approach, the general security considerations from section 6 also 721 apply to this profile. 723 When using pre-shared keys provisioned by the AS, the security level 724 depends on the randomness of PSK, and the security of the TLS cipher 725 suite and key exchange algorithm. 727 Constrained devices that use DTLS [RFC6347] are inherently vulnerable 728 to Denial of Service (DoS) attacks as the handshake protocol requires 729 creation of internal state within the device. This is specifically 730 of concern where an adversary is able to intercept the initial cookie 731 exchange and interject forged messages with a valid cookie to 732 continue with the handshake. A similar issue exists with the 733 authorization information endpoint where the resource server needs to 734 keep valid access tokens until their expiry. Adversaries can fill up 735 the constrained resource server's internal storage for a very long 736 time with interjected or otherwise retrieved valid access tokens. 738 The use of multiple access tokens for a single client increases the 739 strain on the resource server as it must consider every access token 740 and calculate the actual permissions of the client. Also, tokens may 741 contradict each other which may lead the server to enforce wrong 742 permissions. If one of the access tokens expires earlier than 743 others, the resulting permissions may offer insufficient protection. 744 Developers SHOULD avoid using multiple access tokens for a client. 746 8. Privacy Considerations 748 This privacy considerations from section 7 of the 749 [I-D.ietf-ace-oauth-authz] apply also to this profile. 751 An unprotected response to an unauthorized request may disclose 752 information about the resource server and/or its existing 753 relationship with the client. It is advisable to include as little 754 information as possible in an unencrypted response. When a DTLS 755 session between the client and the resource server already exists, 756 more detailed information MAY be included with an error response to 757 provide the client with sufficient information to react on that 758 particular error. 760 Also, unprotected requests to the resource server may reveal 761 information about the client, e.g., which resources the client 762 attempts to request or the data that the client wants to provide to 763 the resource server. The client SHOULD NOT send confidential data in 764 an unprotected request. 766 Note that some information might still leak after DTLS session is 767 established, due to observable message sizes, the source, and the 768 destination addresses. 770 9. IANA Considerations 772 The following registrations are done for the ACE OAuth Profile 773 Registry following the procedure specified in 774 [I-D.ietf-ace-oauth-authz]. 776 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 777 with the RFC number of this specification and delete this paragraph. 779 Profile name: coap_dtls 780 Profile Description: Profile for delegating client authentication and 781 authorization in a constrained environment by establishing a Datagram 782 Transport Layer Security (DTLS) channel between resource-constrained 783 nodes. 785 Profile ID: 1 787 Change Controller: IESG 789 Reference: [RFC-XXXX] 791 10. References 793 10.1. Normative References 795 [I-D.ietf-ace-cwt-proof-of-possession] 796 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 797 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 798 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 799 possession-11 (work in progress), October 2019. 801 [I-D.ietf-ace-oauth-authz] 802 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 803 H. Tschofenig, "Authentication and Authorization for 804 Constrained Environments (ACE) using the OAuth 2.0 805 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-29 806 (work in progress), December 2019. 808 [I-D.ietf-ace-oauth-params] 809 Seitz, L., "Additional OAuth Parameters for Authorization 810 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 811 params-07 (work in progress), December 2019. 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, 815 DOI 10.17487/RFC2119, March 1997, 816 . 818 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 819 Ciphersuites for Transport Layer Security (TLS)", 820 RFC 4279, DOI 10.17487/RFC4279, December 2005, 821 . 823 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 824 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 825 January 2012, . 827 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 828 RFC 6749, DOI 10.17487/RFC6749, October 2012, 829 . 831 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 832 Application Protocol (CoAP)", RFC 7252, 833 DOI 10.17487/RFC7252, June 2014, 834 . 836 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 837 Security (TLS) / Datagram Transport Layer Security (DTLS) 838 Profiles for the Internet of Things", RFC 7925, 839 DOI 10.17487/RFC7925, July 2016, 840 . 842 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 843 RFC 8152, DOI 10.17487/RFC8152, July 2017, 844 . 846 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 847 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 848 May 2017, . 850 10.2. Informative References 852 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 853 Transport Layer Security (TLS)", RFC 6655, 854 DOI 10.17487/RFC6655, July 2012, 855 . 857 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 858 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 859 Transport Layer Security (TLS) and Datagram Transport 860 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 861 June 2014, . 863 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 864 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 865 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 866 . 868 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 869 for Security", RFC 7748, DOI 10.17487/RFC7748, January 870 2016, . 872 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 873 Signature Algorithm (EdDSA)", RFC 8032, 874 DOI 10.17487/RFC8032, January 2017, 875 . 877 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 878 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 879 May 2018, . 881 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 882 Curve Cryptography (ECC) Cipher Suites for Transport Layer 883 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 884 DOI 10.17487/RFC8422, August 2018, 885 . 887 Authors' Addresses 889 Stefanie Gerdes 890 Universitaet Bremen TZI 891 Postfach 330440 892 Bremen D-28359 893 Germany 895 Phone: +49-421-218-63906 896 Email: gerdes@tzi.org 898 Olaf Bergmann 899 Universitaet Bremen TZI 900 Postfach 330440 901 Bremen D-28359 902 Germany 904 Phone: +49-421-218-63904 905 Email: bergmann@tzi.org 907 Carsten Bormann 908 Universitaet Bremen TZI 909 Postfach 330440 910 Bremen D-28359 911 Germany 913 Phone: +49-421-218-63921 914 Email: cabo@tzi.org 915 Goeran Selander 916 Ericsson AB 918 Email: goran.selander@ericsson.com 920 Ludwig Seitz 921 Combitech 922 Djaeknegatan 31 923 Malmoe 211 35 924 Sweden 926 Email: ludwig.seitz@combitech.se