idnits 2.17.1 draft-ietf-ace-dtls-authorize-00.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 (June 08, 2017) is 2507 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 724 -- Looks like a reference, but probably isn't: '2' on line 727 -- Looks like a reference, but probably isn't: '3' on line 729 -- Looks like a reference, but probably isn't: '4' on line 732 -- Looks like a reference, but probably isn't: '5' on line 734 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-06 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-15) exists of draft-ietf-ace-cbor-web-token-05 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-03 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-10 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 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: December 10, 2017 Universitaet Bremen TZI 6 G. Selander 7 Ericsson 8 L. Seitz 9 RISE SICS 10 June 08, 2017 12 Datagram Transport Layer Security (DTLS) Profile for Authentication and 13 Authorization for Constrained Environments (ACE) 14 draft-ietf-ace-dtls-authorize-00 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. A 23 resource-constrained node can use this protocol to delegate 24 management of authorization information to a trusted host with less 25 severe limitations regarding processing 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 http://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 December 10, 2017. 44 Copyright Notice 46 Copyright (c) 2017 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 (http://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 2.1. Unauthorized Resource Request Message . . . . . . . . . . 5 65 2.2. AS Information . . . . . . . . . . . . . . . . . . . . . 6 66 2.3. Resource Access . . . . . . . . . . . . . . . . . . . . . 7 67 2.4. Dynamic Update of Authorization Information . . . . . . . 8 68 3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 9 69 4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 11 71 4.2. Updating Authorization Information . . . . . . . . . . . 13 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 5.1. Unprotected AS Information . . . . . . . . . . . . . . . 14 74 5.2. Use of Nonces for Replay Protection . . . . . . . . . . . 14 75 5.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 7.2. Informative References . . . . . . . . . . . . . . . . . 15 80 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 This specification defines a profile of the ACE framework 86 [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource 87 server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The 88 client uses an access token, bound to a key (the proof-of-possession 89 key) to authorize its access to the resource server. DTLS provides 90 communication security, proof of possession, and server 91 authentication. Optionally the client and the resource server may 92 also use CoAP over DTLS to communicate with the authorization server. 93 This specification supports the DTLS PSK handshake [RFC4279] and the 94 DTLS handshake with Raw Public Keys (RPK) [RFC7250]. 96 The DTLS PSK handshake [RFC4279] provides the proof-of-possession for 97 the key tied to the access token. Furthermore the psk_identity 98 parameter in the DTLS PSK handshake is used to transfer the access 99 token from the client to the resource server. 101 The DTLS RPK handshake [RFC7250] requires client authentication to 102 provide proof-of-possession for the key tied to the access token. 103 Here the access token needs to be transferred to the resource server 104 before the handshake is initiated, as described in section 8.1 of 105 draft-ietf-ace-oauth-authz. [1] 107 Note: While the scope of this draft is on client and resource server 109 communicating using CoAP over DTLS, it is expected that it applies 110 also to CoAP over TLS, possibly with minor modifications. 111 However, that is out of scope for this version of the draft. 113 1.1. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 Readers are expected to be familiar with the terms and concepts 120 described in [I-D.ietf-ace-oauth-authz]. 122 2. Protocol Overview 124 The CoAP-DTLS profile for ACE specifies the transfer of 125 authentication and, if necessary, authorization information between C 126 and RS during setup of a DTLS session for CoAP messaging. It also 127 specifies how a Client can use CoAP over DTLS to retrieve an Access 128 Token from AS for a protected resource hosted on RS. 130 This profile requires a Client (C) to retrieve an Access Token for 131 the resource(s) it wants to access on a Resource Server (RS) as 132 specified in [I-D.ietf-ace-oauth-authz]. Figure 1 shows the typical 133 message flow in this scenario (messages in square brackets are 134 optional): 136 C RS AS 137 | [-- Resource Request --->] | | 138 | | | 139 | [<----- AS Information --] | | 140 | | | 141 | --- Token Request ----------------------------> | 142 | | | 143 | <---------------------------- Access Token ----- | 144 | + RS Information | 146 Figure 1: Retrieving an Access Token 148 To determine the AS in charge of a resource hosted at the RS, C MAY 149 send an initial Unauthorized Resource Request message to RS. RS then 150 denies the request and sends the address of its AS back to C. 152 Instead of the initial Unauthorized Resource Request message, C MAY 153 look up the desired resource in a resource directory (cf. 154 [I-D.ietf-core-resource-directory]). 156 Once C knows AS's address, it can send an Access Token request to the 157 /token endpoint at the AS as specified in [I-D.ietf-ace-oauth-authz]. 158 If C wants to use the CoAP RawPublicKey mode as described in 159 Section 9 of RFC 7252 [2] it MUST provide a key or key identifier 160 within a "cnf" object in the token request. If AS decides that the 161 request is to be authorized it generates an access token response for 162 C containing a "profile" parameter with the value "coap_dtls" to 163 indicate that this profile MUST be used for communication between C 164 and RS. Is also adds a "cnf" parameter with additional data for the 165 establishment of a secure DTLS channel between C and RS. The 166 semantics of the 'cnf' parameter depend on the type of key used 167 between C and RS, see Section 3 and Section 4. 169 The Access Token returned by AS then can be used by C to establish a 170 new DTLS session with RS. When C intends to use asymmetric 171 cryptography in the DTLS handshake with RS, C MUST upload the Access 172 Token to the "/authz-info" resource on RS before starting the DTLS 173 handshake, as described in section 8.1 of draft-ietf-ace-oauth-authz 174 [3]. If only symmetric cryptography is used between C and RS, the 175 Access Token MAY instead be transferred in the DTLS ClientKeyExchange 176 message (see Section 4.1). 178 Figure 2 depicts the common protocol flow for the DTLS profile after 179 C has retrieved the Access Token from AS. 181 C RS AS 182 | [--- Access Token ------>] | | 183 | | | 184 | <== DTLS channel setup ==> | | 185 | | | 186 | == Authorized Request ===> | | 187 | | | 188 | <=== Protected Resource == | | 190 Figure 2: Protocol overview 192 The following sections specify how CoAP is used to interchange 193 access-related data between RS and AS so that AS can provide C and RS 194 with sufficient information to establish a secure channel, and convey 195 authorization information specific for this communication 196 relationship to RS. 198 Depending on the desired CoAP security mode, the Client-to-AS 199 request, AS-to-Client response and DTLS session establishment carry 200 slightly different information. Section 3 addresses the use of raw 201 public keys while Section 4 defines how pre-shared keys are used in 202 this profile. 204 2.1. Unauthorized Resource Request Message 206 The optional Unauthorized Resource Request message is a request for a 207 resource hosted by RS for which no proper authorization is granted. 208 RS MUST treat any CoAP request for a resource other than "/authz- 209 info" as Unauthorized Resource Request message when any of the 210 following holds: 212 o The request has been received on an unprotected channel. 214 o RS has no valid access token for the sender of the request 215 regarding the requested action on that resource. 217 o RS has a valid access token for the sender of the request, but 218 this does not allow the requested action on the requested 219 resource. 221 Note: These conditions ensure that RS can handle requests 222 autonomously once access was granted and a secure channel has been 223 established between C and RS. The resource "/authz-info" is publicly 224 accessible to be able to upload new access tokens to RS (cf. 225 [I-D.ietf-ace-oauth-authz]). 227 Unauthorized Resource Request messages MUST be denied with a client 228 error response. In this response, the Resource Server SHOULD provide 229 proper AS Information to enable the Client to request an access token 230 from RS's Authorization Server as described in Section 2.2. 232 The response code MUST be 4.01 (Unauthorized) in case the sender of 233 the Unauthorized Resource Request message is not authenticated, or if 234 RS has no valid access token for C. If RS has an access token for C 235 but not for the resource that C has requested, RS MUST reject the 236 request with a 4.03 (Forbidden). If RS has an access token for C but 237 it does not cover the action C requested on the resource, RS MUST 238 reject the request with a 4.05 (Method Not Allowed). 240 Note: The use of the response codes 4.03 and 4.05 is intended to 241 prevent infinite loops where a dumb Client optimistically tries to 242 access a requested resource with any access token received from 243 AS. As malicious clients could pretend to be C to determine C's 244 privileges, these detailed response codes must be used only when a 245 certain level of security is already available which can be 246 achieved only when the Client is authenticated. 248 2.2. AS Information 250 The AS Information is sent by RS as a response to an Unauthorized 251 Resource Request message (see Section 2.1) to point the sender of the 252 Unauthorized Resource Request message to RS's AS. The AS information 253 is a set of attributes containing an absolute URI (see Section 4.3 of 254 [RFC3986]) that specifies the AS in charge of RS. 256 TBD: We might not want to add more parameters in the AS information 257 because 258 this would not only reveal too much information about RS's 259 capabilities to unauthorized peers but also be of little value as 260 C cannot really trust that information anyway. 262 The message MAY also contain a nonce generated by RS to ensure 263 freshness in case that the RS and AS do not have synchronized clocks. 265 Figure 3 shows an example for an AS Information message payload using 266 CBOR [RFC7049] diagnostic notation. 268 4.01 Unauthorized 269 Content-Format: application/ace+cbor 270 {AS: "coaps://as.example.com/token", 271 nonce: h'e0a156bb3f'} 273 Figure 3: AS Information payload example 275 In this example, the attribute AS points the receiver of this message 276 to the URI "coaps://as.example.com/token" to request access 277 permissions. The originator of the AS Information payload (i.e., RS) 278 uses a local clock that is loosely synchronized with a time scale 279 common between RS and AS (e.g., wall clock time). Therefore, it has 280 included a parameter "nonce" for replay attack prevention (c.f. 281 Section 5.2). 283 Note: There is an ongoing discussion how freshness of access tokens 284 can be achieved in constrained environments. This specification 285 for now assumes that RS and AS do not have a common understanding 286 of time that allows RS to achieve its security objectives without 287 explicitly adding a nonce. 289 The examples in this document are written in CBOR diagnostic notation 290 to improve readability. Figure 4 illustrates the binary encoding of 291 the message payload shown in Figure 3. 293 a2 # map(2) 294 00 # unsigned(0) (=AS) 295 78 1c # text(28) 296 636f6170733a2f2f61732e657861 297 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 298 05 # unsigned(5) (=nonce) 299 45 # bytes(5) 300 e0a156bb3f 302 Figure 4: AS Information example encoded in CBOR 304 2.3. Resource Access 306 Once a DTLS channel has been established as described in Section 3 307 and Section 4, respectively, C is authorized to access resources 308 covered by the Access Token it has uploaded to the "/authz-info" 309 resource hosted by RS. 311 On the server side (i.e., RS), successful establishment of the DTLS 312 channel binds C to the access token, functioning as a proof-of- 313 possession associated key. Any request that RS receives on this 314 channel MUST be checked against these authorization rules that are 315 associated with the identity of C. Incoming CoAP requests that are 316 not authorized with respect to any Access Token that is associated 317 with C MUST be rejected by RS with 4.01 response as described in 318 Section 2.1. 320 Note: The identity of C is determined by the authentication process 321 during the DTLS handshake. In the asymmetric case, the public key 322 will define C's identity, while in the PSK case, C's identity is 323 defined by the session key generated by AS for this communication. 325 RS SHOULD treat an incoming CoAP request as authorized if the 326 following holds: 328 1. The message was received on a secure channel that has been 329 established using the procedure defined in this document. 331 2. The authorization information tied to the sending peer is valid. 333 3. The request is destined for RS. 335 4. The resource URI specified in the request is covered by the 336 authorization information. 338 5. The request method is an authorized action on the resource with 339 respect to the authorization information. 341 Incoming CoAP requests received on a secure DTLS channel MUST be 342 rejected 344 1. with response code 4.03 (Forbidden) when the resource URI 345 specified in the request is not covered by the authorization 346 information, and 348 2. with response code 4.05 (Method Not Allowed) when the resource 349 URI specified in the request covered by the authorization 350 information but not the requested action. 352 C cannot always know a priori if a Authorized Resource Request will 353 succeed. If C repeatedly gets AS Information messages (cf. 354 Section 2.2) as response to its requests, it SHOULD request a new 355 Access Token from AS in order to continue communication with RS. 357 2.4. Dynamic Update of Authorization Information 359 The Client can update the authorization information stored at RS at 360 any time. To do so, the Client requests from AS a new Access Token 361 for the intended action on the respective resource and uploads this 362 Access Token to the "/authz-info" resource on RS. 364 Figure 5 depicts the message flow where C requests a new Access Token 365 after a security association between C and RS has been established 366 using this protocol. 368 C RS AS 369 | <===== DTLS channel =====> | | 370 | + Access Token | | 371 | | | 372 | --- Token Request ----------------------------> | 373 | | | 374 | <---------------------------- New Access Token - | 375 | + RS Information | 376 | | | 377 | --- Update /authz-info --> | | 378 | New Access Token | | 379 | | | 380 | == Authorized Request ===> | | 381 | | | 382 | <=== Protected Resource == | | 384 Figure 5: Overview of Dynamic Update Operation 386 3. RawPublicKey Mode 388 To retrieve an access token for the resource that C wants to access, 389 C requests an Access Token from AS. C MUST add a "cnf" object 390 carrying either its raw public key or a unique identifier for a 391 public key that it has previously made known to AS. 393 An example Access Token request from C to RS is depicted in Figure 6. 395 POST coaps://as.example.com/token 396 Content-Format: application/cbor 397 { 398 grant_type: client_credentials, 399 aud: "tempSensor4711", 400 cnf: { 401 COSE_Key: { 402 kty: EC2, 403 crv: P-256, 404 x: h'TODOX', 405 y: h'TODOY' 406 } 407 } 408 } 410 Figure 6: Access Token Request Example for RPK Mode 412 The example shows an Access Token request for the resource identified 413 by the audience string "tempSensor4711" on the AS using a raw public 414 key. 416 When AS authorizes a request, it will return an Access Token and a 417 "cnf" object in the AS-to-Client response. Before C initiates the 418 DTLS handshake with RS, it MUST send a "POST" request containing the 419 new Access Token to the "/authz-info" resource hosted by RS. If this 420 operation yields a positive response, C SHOULD proceed to establish a 421 new DTLS channel with RS. To use raw public key mode, C MUST pass 422 the same public key that was used for constructing the Access Token 423 with the SubjectPublicKeyInfo structure in the DTLS handshake as 424 specified in [RFC7250]. 426 Note: According to [RFC7252], CoAP implementations MUST support the 427 ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] and the 428 NIST P-256 curve. C is therefore expected to offer at least this 429 ciphersuite to RS. 431 The Access Token is constructed by AS such that RS can associate the 432 Access Token with the Client's public key. If CBOR web tokens 433 [I-D.ietf-ace-cbor-web-token] are used as recommended in 434 [I-D.ietf-ace-oauth-authz], the AS MUST include a "COSE_Key" object 435 in the "cnf" claim of the Access Token. This "COSE_Key" object MAY 436 contain a reference to a key for C that is already known by RS (e.g., 437 from previous communication). If the AS has no certain knowledge 438 that the Client's key is already known to RS, the Client's public key 439 MUST be included in the Access Token's "cnf" parameter. 441 4. PreSharedKey Mode 443 To retrieve an access token for the resource that C wants to access, 444 C MAY include a "cnf" object carrying an identifier for a symmetric 445 key in its Access Token request to AS. This identifier can be used 446 by AS to determine the session key to construct the proof-of- 447 possession token and therefore MUST specify a symmetric key that was 448 previously generated by AS as a session key for the communication 449 between C and RS. 451 Depending on the requested token type and algorithm in the Access 452 Token request, AS adds RS Information to the response that provides C 453 with sufficient information to setup a DTLS channel with RS. For 454 symmetric proof-of-possession keys (c.f. 455 [I-D.ietf-ace-oauth-authz]), C must ensure that the Access Token 456 request is sent over a secure channel that guarantees authentication, 457 message integrity and confidentiality. This could be, e.g., a DTLS 458 channel (for "coaps") or an OSCOAP [I-D.ietf-core-object-security] 459 exchange (for "coap"). 461 When AS authorizes C it returns an AS-to-Client response with the 462 profile parameter set to "coap_dtls" and a "cnf" parameter carrying a 463 "COSE_Key" object that contains the symmetric session key to be used 464 between C and RS as illustrated in Figure 7. 466 2.01 Created 467 Content-Format: application/cbor 468 Location-Path: /token/asdjbaskd 469 Max-Age: 86400 470 { 471 access_token: b64'SlAV32hkKG ... 472 (remainder of CWT omitted for brevity; 473 token_type: pop, 474 alg: HS256, 475 expires_in: 86400, 476 profile: coap_dtls, 477 cnf: { 478 COSE_Key: { 479 kty: symmetric, 480 k: h'73657373696f6e6b6579' 481 } 482 } 483 } 485 Figure 7: Example Access Token response 487 In this example, AS returns a 2.01 response containing a new Access 488 Token. The information is transferred as a CBOR data structure as 489 specified in [I-D.ietf-ace-oauth-authz]. The Max-Age option tells 490 the receiving Client how long this token will be valid. 492 A response that declines any operation on the requested resource is 493 constructed according to Section 5.2 of RFC 6749 [4], (cf. 494 Section 5.5.3 of [I-D.ietf-ace-oauth-authz]). 496 4.00 Bad Request 497 Content-Format: application/cbor 498 { 499 error: invalid_request 500 } 502 Figure 8: Example Access Token response with reject 504 4.1. DTLS Channel Setup Between C and RS 506 When C receives an Access Token from AS, it checks if the payload 507 contains an "access_token" parameter and a "cnf" parameter. With 508 this information C can initiate establishment of a new DTLS channel 509 with RS. To use DTLS with pre-shared keys, C follows the PSK key 510 exchange algorithm specified in Section 2 of [RFC4279] using the key 511 conveyed in the "cnf" parameter of the AS response as PSK when 512 constructing the premaster secret. 514 In PreSharedKey mode, the knowledge of the session key by C and RS is 515 used for mutual authentication between both peers. Therefore, RS 516 must be able to determine the session key from the Access Token. 517 Following the general ACE authorization framework, C can upload the 518 Access Token to RS's "/authz-info" resource before starting the DTLS 519 handshake. Alternatively, C MAY provide the most recent 520 base64-encoded Access Token in the "psk_identity" field of the 521 ClientKeyExchange message. 523 If RS receives a ClientKeyExchange message that contains a 524 "psk_identity" with a length greater zero, it MUST base64-decode its 525 contents and check if the "psk_identity" field contains a key 526 identifier or Access Token according to the following CDDL 527 specification: 529 psk_identity = { 530 kid => bstr // access_token => bstr 531 } 533 The identifiers for the map keys "kid" and "access_token" are used 534 with the same meaning as in COSE [I-D.ietf-cose-msg] and the ACE 535 framework [I-D.ietf-ace-oauth-authz] respectively. The identifier 536 "kid" thus has the value 4 (see [I-D.ietf-cose-msg]), and the 537 identifier "access_token" has the value 19, respectively (see 538 [I-D.ietf-ace-oauth-authz]). 540 If the "psk_identity" field contains a key identifier, the receiver 541 MUST check if it has one or more Access Tokens that are associated 542 with the specified key. If no valid Access Token is available for 543 this key, the DTLS session setup is terminated with an 544 "illegal_parameter" DTLS alert message. 546 If instead the "psk_identity" field contains an Access Token, it must 547 processed in the same way as an Access Token that has been uploaded 548 to its "/authz-info" resource. In this case, RS continues processing 549 the ClientKeyExchange message if the contents of the "psk_identity" 550 contained a valid Access Token. Otherwise, the DTLS session setup is 551 terminated with an "illegal_parameter" DTLS alert message. 553 Note1: As RS cannot provide C with a meaningful PSK identity hint in 555 response to C's ClientHello message, RS SHOULD NOT send a 556 ServerKeyExchange message. 558 Note2: According to [RFC7252], CoAP implementations MUST support the 559 ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. C is therefore 560 expected to offer at least this ciphersuite to RS. 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 C and RS. 567 While C can retrieve the session key from the contents of the "cnf" 568 parameter in the AS-to-Client response, RS uses the information 569 contained in the "cnf" claim of the Access Token to determine the 570 actual session key when no explicit "kid" was provided in the 571 "psk_identity" field. Usually, this is done by including a 572 "COSE_Key" object carrying either a key that has been encrypted with 573 a shared secret between AS and RS, or a key identifier that can be 574 used by RS to lookup the session key. 576 Instead of the "COSE_Key" object, AS MAY include a "COSE_Encrypt" 577 structure to enable RS to calculate the session key from the Access 578 Token. The "COSE_Encrypt" structure MUST use the _Direct Key with 579 KDF_ method as described in Section 12.1.2 of draft-ietf-cose-msg 580 [5]. The AS MUST include a Context information structure carrying a 581 PartyU "nonce" parameter carrying the nonce that has been used by AS 582 to construct the session key. 584 This specification mandates that at least the key derivation 585 algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be 586 supported. This key derivation function is the default when no "alg" 587 field is included in the "COSE_Encrypt" structure for RS. 589 4.2. Updating Authorization Information 591 Usually, the authorization information that RS keeps for C is updated 592 by uploading a new Access Token as described in Section 2.4. 594 If the security association with RS still exists and RS has indicated 595 support for session renegotiation according to [RFC5746], the new 596 Access Token MAY be used to renegotiate the existing DTLS session. 597 In this case, the Access Token is used as "psk_identity" as defined 598 in Section 4.1. The Client MAY also perform a new DTLS handshake 599 according to Section 4.1 that replaces the existing DTLS session. 601 After successful completion of the DTLS handshake RS updates the 602 existing authorization information for C according to the new Access 603 Token. 605 5. Security Considerations 607 TODO 609 5.1. Unprotected AS Information 611 Initially, no secure channel exists to protect the communication 612 between C and RS. Thus, C cannot determine if the AS information 613 contained in an unprotected response from RS to an unauthorized 614 request (c.f. Section 2.2) is authentic. It is therefore advisable 615 to provide C with a (possibly hard-coded) list of trustworthy 616 authorization servers. AS information responses referring to a URI 617 not listed there would be ignored. 619 5.2. Use of Nonces for Replay Protection 621 RS may add a nonce to the AS Information message sent as a response 622 to an unauthorized request to ensure freshness of an Access Token 623 subsequently presented to RS. While a timestamp of some granularity 624 would be sufficient to protect against replay attacks, using 625 randomized nonce is preferred to prevent disclosure of information 626 about RS's internal clock characteristics. 628 5.3. Privacy 630 An unprotected response to an unauthorized request (c.f. 631 Section 2.2) may disclose information about RS and/or its existing 632 relationship with C. It is advisable to include as little 633 information as possible in an unencrypted response. When a DTLS 634 session between C and RS already exists, more detailed information 635 may be included with an error response to provide C with sufficient 636 information to react on that particular error. 638 6. IANA Considerations 640 This document has no actions for IANA. 642 7. References 644 7.1. Normative References 646 [I-D.ietf-ace-oauth-authz] 647 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 648 H. Tschofenig, "Authentication and Authorization for 649 Constrained Environments (ACE)", draft-ietf-ace-oauth- 650 authz-06 (work in progress), March 2017. 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 658 Resource Identifier (URI): Generic Syntax", STD 66, 659 RFC 3986, DOI 10.17487/RFC3986, January 2005, 660 . 662 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 663 Ciphersuites for Transport Layer Security (TLS)", 664 RFC 4279, DOI 10.17487/RFC4279, December 2005, 665 . 667 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 668 "Transport Layer Security (TLS) Renegotiation Indication 669 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 670 . 672 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 673 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 674 January 2012, . 676 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 677 Application Protocol (CoAP)", RFC 7252, 678 DOI 10.17487/RFC7252, June 2014, 679 . 681 7.2. Informative References 683 [I-D.ietf-ace-cbor-web-token] 684 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 685 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-05 686 (work in progress), June 2017. 688 [I-D.ietf-core-object-security] 689 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 690 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 691 object-security-03 (work in progress), May 2017. 693 [I-D.ietf-core-resource-directory] 694 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 695 Resource Directory", draft-ietf-core-resource-directory-10 696 (work in progress), March 2017. 698 [I-D.ietf-cose-msg] 699 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 700 draft-ietf-cose-msg-24 (work in progress), November 2016. 702 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 703 Transport Layer Security (TLS)", RFC 6655, 704 DOI 10.17487/RFC6655, July 2012, 705 . 707 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 708 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 709 October 2013, . 711 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 712 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 713 Transport Layer Security (TLS) and Datagram Transport 714 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 715 June 2014, . 717 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 718 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 719 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 720 . 722 7.3. URIs 724 [1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 725 03#section-8.1 727 [2] https://tools.ietf.org/html/rfc7252#section-9 729 [3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz- 730 03#section-8.1 732 [4] https://tools.ietf.org/html/rfc6749#section-5.2 734 [5] https://tools.ietf.org/html/draft-ietf-cose-msg-23#section-12.1.2 736 Authors' Addresses 738 Stefanie Gerdes 739 Universitaet Bremen TZI 740 Postfach 330440 741 Bremen D-28359 742 Germany 744 Phone: +49-421-218-63906 745 Email: gerdes@tzi.org 746 Olaf Bergmann 747 Universitaet Bremen TZI 748 Postfach 330440 749 Bremen D-28359 750 Germany 752 Phone: +49-421-218-63904 753 Email: bergmann@tzi.org 755 Carsten Bormann 756 Universitaet Bremen TZI 757 Postfach 330440 758 Bremen D-28359 759 Germany 761 Phone: +49-421-218-63921 762 Email: cabo@tzi.org 764 Goeran Selander 765 Ericsson 766 Faroegatan 6 767 Kista 164 80 768 Sweden 770 Email: goran.selander@ericsson.com 772 Ludwig Seitz 773 RISE SICS 774 Scheelevaegen 17 775 Lund 223 70 776 Sweden 778 Email: ludwig.seitz@ri.se