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