idnits 2.17.1 draft-selander-ace-ake-authz-01.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 (9 March 2020) is 1502 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-04) exists of draft-ietf-lake-reqs-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-04) exists of draft-raza-ace-cbor-certificates-03 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-02 == Outdated reference: A later version (-01) exists of draft-selander-lake-edhoc-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Selander 3 Internet-Draft J. Mattsson 4 Intended status: Informational Ericsson AB 5 Expires: 10 September 2020 M. Vucinic 6 INRIA 7 M. Richardson 8 Sandelman Software Works 9 A. Schellenbaum 10 Institute of Embedded Systems, ZHAW 11 9 March 2020 13 Lightweight Authorization for Authenticated Key Exchange. 14 draft-selander-ace-ake-authz-01 16 Abstract 18 This document describes a procedure for augmenting an authenticated 19 Diffie-Hellman key exchange with third party assisted authorization 20 targeting constrained IoT deployments (RFC 7228). 22 Note to Readers 24 Source for this draft and an issue tracker can be found at 25 https://github.com/EricssonResearch/ace-ake-authz 26 (https://github.com/EricssonResearch/ace-ake-authz). 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 10 September 2020. 45 Copyright Notice 47 Copyright (c) 2020 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 4 64 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Device . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Domain Authenticator . . . . . . . . . . . . . . . . . . 5 67 3.3. Authorization Server . . . . . . . . . . . . . . . . . . 5 68 3.4. Lightweight AKE . . . . . . . . . . . . . . . . . . . . . 6 69 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Device <-> Authorization Server . . . . . . . . . . . . . 7 71 4.1.1. Voucher . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. Device <-> Authenticator . . . . . . . . . . . . . . . . 10 73 4.2.1. Message 1 . . . . . . . . . . . . . . . . . . . . . . 10 74 4.2.2. Message 2 . . . . . . . . . . . . . . . . . . . . . . 10 75 4.2.3. Message 3 . . . . . . . . . . . . . . . . . . . . . . 11 76 4.3. Authenticator <-> Authorization Server . . . . . . . . . 11 77 4.3.1. Voucher Request . . . . . . . . . . . . . . . . . . . 11 78 4.3.2. Voucher Response . . . . . . . . . . . . . . . . . . 12 79 5. ACE Profile . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 12 81 5.2. AS Request Creation Hints . . . . . . . . . . . . . . . . 13 82 5.3. Client-to-AS Request . . . . . . . . . . . . . . . . . . 14 83 5.4. AS-to-Client Response . . . . . . . . . . . . . . . . . . 14 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 8. Informative References . . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 For constrained IoT deployments [RFC7228] the overhead contributed by 92 security protocols may be significant which motivates the 93 specification of lightweight protocols that are optimizing, in 94 particular, message overhead (see [I-D.ietf-lake-reqs]). This 95 document describes a lightweight procedure for augmenting an 96 authenticated Diffie-Hellman key exchange with third party assisted 97 authorization. 99 The procedure involves a device, a domain authenticator and an 100 authorization server. The device and authenticator perform mutual 101 authentication and authorization, assisted by the authorization 102 server which provides relevant authorization information to the 103 device (a "voucher") and the authenticator. 105 The protocol specified in this document optimizes the message count 106 by performing authorization and enrollment in parallel with 107 authentication, instead of in sequence which is common for network 108 access. It further reuses protocol elements from the authentication 109 protocol leading to reduced message sizes on constrained links. 111 The specification assumes a lightweight AKE protocol 112 [I-D.ietf-lake-reqs] between device and authenticator, and defines 113 the integration of a lightweight authorization procedure. This 114 enables a secure target interaction in few message exchanges. In 115 this document we consider the target interaction to be "enrollment", 116 for example certificate enrollment (such as [I-D.ietf-ace-coap-est]) 117 or joining a network for the first time (e.g. 118 [I-D.ietf-6tisch-minimal-security]), but it can be applied to 119 authorize other target interactions. 121 This protocol is applicable to a wide variety of settings, and can be 122 mapped to different authorization architectures. This document 123 specifies a profile of the ACE framework [I-D.ietf-ace-oauth-authz]. 124 Other settings such as EAP [RFC3748] are out of scope for this 125 specification. 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. Problem Description 137 The (potentially constrained) device wants to enroll into a domain 138 over a constrained link. The device authenticates and enforces 139 authorization of the (non-constrained) domain authenticator with the 140 help of a voucher, and makes the enrollment request. The domain 141 authenticator authenticates the device and authorizes its enrollment. 142 Authentication between device and domain authenticator is made with a 143 lightweight authenticated Diffie-Hellman key exchange protocol (LAKE, 144 [I-D.ietf-lake-reqs]). The procedure is assisted by a (non- 145 constrained) authorization server located in a non-constrained 146 network behind the domain authenticator providing information to the 147 device and to the domain authenticator. 149 The objective of this document is to specify such a protocol which is 150 lightweight over the constrained link and reuses elements of the 151 LAKE. See illustration in Figure 1. 153 Voucher 154 LAKE Info 155 +----------+ | | +---------------+ Voucher +---------------+ 156 | | | | | | Request | | 157 | Device |--|----o-->| Domain |---------->| Authorization | 158 | |<-|---o----| Authenticator |<----------| Server | 159 | (U) |--|---|--->| (V) | Voucher | (W) | 160 | | | | | Response | | 161 +----------+ | +---------------+ +---------------+ 162 Voucher 164 Figure 1: Overview and example of message content. Voucher Info 165 and Voucher are sent together with LAKE messages. 167 3. Assumptions 169 3.1. Device 171 The device is pre-provisioned with an identity ID and asymmetric key 172 credentials: a private key, a public key (PK_U), and optionally a 173 public key certificate Cert(PK_U), issued by a trusted third party 174 such as e.g. the device manufacturer, used to authenticate to the 175 domain authenticator. The ID may be a reference or pointer to the 176 certificate. 178 The device is also provisioned with information about its 179 authorization server: 181 * At least one static public DH key of the authorization server 182 (G_W) used to ensure secure communication with the device (see 183 Section 4.1). 185 * Location information about the authorization server (LOC_W), e.g. 186 its domain name. This information may be available in the device 187 certificate Cert(PK_U). 189 3.2. Domain Authenticator 191 The domain authenticator has a private key and a corresponding public 192 key PK_V used to authenticate to the device. 194 The domain authenticator needs to be able to locate the authorization 195 server of the device for which the LOC_W is expected to be 196 sufficient. The communication between domain authenticator and 197 authorization server is mutually authenticated and protected. 198 Authentication credentials and communication security used with the 199 domain authenticator is out of scope, except for as specified below 200 in this section. 202 The domain authenticator may in principle use differents credentials 203 for authenticating to the authorization server and to the device, for 204 which PK_V is used. However, the domain authenticator MUST prove 205 possession of private key of PK_V to the authorization server since 206 the authorization server is asserting (by means of the voucher to the 207 device) that this credential belongs to the domain authenticator. 209 In this version of the draft it is assumed that the domain 210 authenticator authenticates to the authorization server with PK_V 211 using some authentication protocol providing proof of possession of 212 the private key, for example TLS 1.3 [RFC8446]. A future version of 213 this draft may specify explicit proof of possession of the private 214 key of PK_V in the voucher request, e.g., by including a signature of 215 the voucher request with the private key of PK_V. 217 3.3. Authorization Server 219 The authorization server has a private DH key corresponding to G_W, 220 which is used to secure the communication with the device (see 221 Section 4.1). 223 Authentication credentials and communication security used with the 224 domain authenticator is out of scope, except for the need to verify 225 the possession of the private key of PK_V as specified in 226 Section 3.2. 228 The authorization server provides to the device the authorization 229 decision for enrollment with the domain authenticator in the form of 230 a voucher. The authorization server provides information to the 231 domain authenticator about the device, such as the the device's 232 certificate Cert(PK_U). 234 The authorization server needs to be available during the execution 235 of the protocol. 237 3.4. Lightweight AKE 239 We assume a Diffie-Hellman key exchange protocol complying with the 240 LAKE requirements [I-D.ietf-lake-reqs]. Specifically we assume for 241 the LAKE: 243 * Three messages 245 * CBOR encoding 247 * The ephemeral public Diffie-Hellman key of the device, G_X, is 248 sent in message 1. G_X is also used as ephemeral key and nonce in 249 an ECIES scheme between device and authorization server. 251 * The public authentication key of the domain authenticator, PK_V, 252 is sent in message 2. 254 * Support for Auxilliary Data AD1-3 in messages 1-3 as specified in 255 section 2.5 of [I-D.ietf-lake-reqs]. 257 * Cipher suite negotiation where the device can propose ECDH curves 258 restricted by its available public keys of the authorization 259 server. 261 4. The Protocol 263 Three security sessions are going on in parallel (see Figure 2): 265 * Between device (U) and (domain) authenticator (V), 267 * between authenticator and authorization server (W), and 269 * between device and authorization server mediated by the 270 authenticator. 272 The content of the LAKE messages (see Section 3.4) is highlighted 273 with brackets in the figure below (Figure 2) using the notation of 274 EDHOC [I-D.selander-lake-edhoc]. The content includes: 276 * G_X: the x-coordinate of the ephemeral public Diffie-Hellman key 277 of party U 279 * ID_CRED_V: data enabling the party U to obtain the credentials 280 containing the public authentication key of V 282 * Sig(V;): a signature made with the private authentication key of V 284 * Sig(U;): a signature made with the private authentication key of U 286 We study each security session in turn, starting with the last. 288 U V W 289 | (G_X) | | 290 | AD1=(LOC_W, CC, AEAD(K_1; ID_U)) | | 291 +----------------------------------->| | 292 | LAKE message 1 |G_X, PK_V, CC, AEAD(K_1; ID_U)| 293 | +----------------------------->| 294 | | Voucher Request (VREQ) | 295 | | | 296 | | CERT_PK_U, Voucher | 297 | |<-----------------------------+ 298 | (ID_CRED_V, Sig(V;)) | Voucher Response (VRES) | 299 | AD2=Voucher | | 300 |<-----------------------------------+ | 301 | LAKE message 2 | | 302 | | | 303 | (Sig(U;)) | | 304 +----------------------------------->| | 305 | LAKE message 3 | | 307 where Voucher = AEAD(K_2; V_TYPE, PK_V, G_X, ID_U) 309 Figure 2: W-assisted authorization of AKE between U and V. 310 Relevant content from the LAKE protocol between U and V with 311 auxiliary data AD1 and AD2. The Voucher Request/Response 312 Protocol between V and W. 314 4.1. Device <-> Authorization Server 316 The communication between device and authorization server is carried 317 out via the authenticator protected between the endpoints (protocol 318 between U and W in Figure 2) using an ECIES hybrid encryption scheme 319 (see [I-D.irtf-cfrg-hpke]): The device uses the private key 320 corresponding to its ephemeral DH key G_X generated for LAKE message 321 1 (see Section 4.2) together with the static public DH key of the 322 authorization server G_W to generate a shared secret G_XW. The 323 shared secret is used to derive AEAD encryption keys to protect data 324 between device and authorization server. The data is carried in AD1 325 and AD2 (between device and authenticator) and in Voucher Request/ 326 Response (between authenticator and authorization server). 328 TODO: Reference relevant ECIES scheme in [I-D.irtf-cfrg-hpke]. 330 TODO: Define derivation of encryption keys (K_1, K_2) and nonces 331 (N_1, N_2) for the both directions 333 AD1 SHALL be the following CBOR sequence containing voucher 334 information: 336 AD1 = ( 337 LOC_W: tstr, 338 CC: bstr, 339 CIPHERTEXT_RQ: bstr 340 ) 342 where 344 * LOC_W is location information about the authorization server 346 * CC is a crypto context identifier for the security context between 347 the device and the authorization server 349 * 'CIPHERTEXT_RQ' is the authenticated encrypted identity of the 350 device with CC as Additional Data, more specifically: 352 'CIPHERTEXT_RQ' is 'ciphertext' of COSE_Encrypt0 (Section 5.2-5.3 of 353 [RFC8152]) computed from the following: 355 * the secret key K_1 357 * the nonce N_1 359 * 'protected' is a byte string of size 0 361 * 'plaintext and 'external_aad' as below: 363 plaintext = ( 364 ID: bstr 365 ) 367 external_aad = ( 368 CC: bstr 369 ) 371 where 373 * ID is the identity of the device, for example a reference or 374 pointer to the device certificate 376 * CC is defined above. 378 AD2 SHALL be the Voucher, defined in the next section. 380 AD2 = ( 381 Voucher: bstr 382 ) 384 4.1.1. Voucher 386 The Voucher is essentially a Message Authentication Code binding the 387 identity of the authenticator to the first message sent from the 388 device in the LAKE protocol. 390 More specifically 'Voucher' is the 'ciphertext' of COSE_Encrypt0 391 (Section 5.2 of [RFC8152]) computed from the following: 393 * the secret key K_2 395 * the nonce N_2 397 * 'protected' is a byte string of size 0 399 * 'plaintext' is empty (plaintext = nil) 401 * 'external_aad' as below: 403 external_aad = bstr .cbor external_aad_array 405 external_aad_array = [ 406 voucher_type: int, 407 PK_V: bstr, 408 G_X: bstr, 409 CC: bstr, 410 ID: bstr 411 ] 413 where 415 * 'voucher-type' indicates the kind of voucher used 417 * PK_V is a COSE_Key containing the public authentication key of the 418 authenticator. The public key must be an Elliptic Curve Diffie- 419 Hellman key, COSE key type 'kty' = 'EC2' or 'OKP'. 421 - COSE_Keys of type OKP SHALL only include the parameters 1 422 (kty), -1 (crv), and -2 (x-coordinate). COSE_Keys of type EC2 423 SHALL only include the parameters 1 (kty), -1 (crv), -2 424 (x-coordinate), and -3 (y-coordinate). The parameters SHALL be 425 encoded in decreasing order. 427 * G_X is the ephemeral key of the device sent in the first LAKE 428 message 430 * CC and ID are defined in Section 4.1 432 All parameters, except 'voucher-type', are as received in the voucher 433 request (see Section 4.3). 435 TODO: Consider making the voucher a CBOR Map to indicate type of 436 voucher, to indicate the feature (cf. Section 4.3) 438 4.2. Device <-> Authenticator 440 The device and authenticator run the LAKE protocol authenticated with 441 public keys (PK_U and PK_V) of the device and the authenticator, see 442 protocol between U and V in Figure 2. The normal processing of the 443 LAKE is omitted here. 445 4.2.1. Message 1 447 4.2.1.1. Device processing 449 The device selects a cipher suite with an ECDH curve satisfying the 450 static public DH key G_W of the authorization server. As part of the 451 normal LAKE processing, the device generates the ephemeral public key 452 G_X to be sent in LAKE message 1. A new G_X MUST be generated for 453 each execution of the protocol. The ephemeral key G_X is reused in 454 the ECIES scheme, see Section 4.1. 456 The device sends LAKE message 1 with AD1 as specified in Section 4.1. 458 4.2.1.2. Authenticator processing 460 The authenticator receives LAKE message 1 from the device, which 461 triggers the exchange of voucher related data with the authorization 462 server as described in Section 4.3. 464 4.2.2. Message 2 466 4.2.2.1. Authenticator processing 468 The authenticator sends LAKE message 2 to the device with the voucher 469 (see Section 4.1) in AD2. The public key PK_V is encoded in the way 470 public keys are encoded in the LAKE protocol. 472 4.2.2.2. Device processing 474 The device MUST verify the Voucher using its ephemeral key G_X sent 475 in message 1 and PK_V received in message 2. If the Voucher does not 476 verify, the device MUST discontinue the protocol. 478 4.2.3. Message 3 480 4.2.3.1. Device processing 482 The device sends message 3. AD3 depends on the kind of enrollment 483 the device is requesting. It may e.g. be a CBOR encoded Certificate 484 Signing Request, see [I-D.raza-ace-cbor-certificates]. 486 4.2.3.2. Authenticator processing 488 The authenticator MUST NOT verify the signature Sig(U;) (see 489 Figure 2) in LAKE message 3 with the PK_U included in message 3. 490 Instead, the signature MUST be verified with the public key included 491 in Cert(PK_U) (see Section 4.3.2) received from the authorization 492 server. This way, the authenticator can make sure that message 3 is 493 signed by the right entity trusted by the authorization server. 495 4.3. Authenticator <-> Authorization Server 497 The authenticator and authorization server are assumed to have secure 498 communication, for example TLS 1.3 authenticated with certificates, 499 protecting the Voucher Request/Response Protocol (see protocol 500 between V and W in Figure 2). 502 4.3.1. Voucher Request 504 The authenticator sends the voucher request to the authorization 505 server. The Voucher_Request SHALL be a CBOR array as defined below: 507 Voucher_Request = [ 508 PK_V: bstr, 509 G_X: bstr, 510 CC: bstr, 511 CIPHERTEXT_RQ: bstr 512 ] 514 where the parameters are defined in Section 4.1. 516 4.3.2. Voucher Response 518 The authorization server decrypts the identity of the device and 519 looks up its certificate, Cert(PK_U). The authorization server sends 520 the voucher response to the authenticator. The Voucher_Response 521 SHALL be a CBOR array as defined below: 523 Voucher_Response = [ 524 CERT_PK_U: bstr, 525 Voucher: bstr 526 ] 528 where 530 * CERT_PK_U is the device certificate of the public key PK_U, 531 Cert(PK_U), issued by a trusted third party, intended to be 532 verified by the authenticator. The format of this certificate is 533 out of scope. 535 * The voucher is defined in Section 4.1 537 TODO: The voucher response may contain a "Voucher-info" field as an 538 alternative to make the Voucher a CBOR Map (see Section 4.1) 540 5. ACE Profile 542 This section defines the profile of the ACE framework (see Appendix C 543 of [I-D.ietf-ace-oauth-authz]). 545 U plays the role of the ACE Resource Server (RS). V plays the role 546 of the ACE Client (C). W plays the role of the ACE Authorization 547 Server (AS). 549 C and RS use the Auxiliary Data in the LAKE protocol to communicate. 550 C and RS use the LAKE protocol to protect their communication. LAKE 551 also provides mutual authentication of C and RS, assisted by the AS. 553 5.1. Protocol Overview 554 RS C AS 555 | LAKE Message 1 | | 556 | AD1=AS Request Creation Hints | | 557 |-------------------------------->| POST /token | 558 | |-------------------->| 559 | | | 560 | | Access Token + | 561 | LAKE Message 2 | Access Information | 562 | AD2=Access Token |<--------------------| 563 |<--------------------------------| | 564 | LAKE Message 3 | | 565 |-------------------------------->| | 567 Figure 3: Overview of the protocol mapping to ACE 569 RS proactively sends the AS Request Creation Hints message to C to 570 signal the information on where C can reach the AS. RS piggybacks 571 the AS Request Creation Hints message using Auxiliary Data of the 572 LAKE message 1. Before continuing the LAKE handshake, based on the 573 AS Request Creation Hints information, C sends a POST request to the 574 token endpoint at the AS requesting the access token. The AS issues 575 an assertion to C that is cryptographically protected based on the 576 secret shared between the AS and RS. In this profile, the assertion 577 is encoded as a Bearer Token. C presents this token to RS in the 578 Auxiliary Data of the LAKE message 2. RS verifies the token based on 579 the possession of the shared secret with the AS and authenticates C. 581 5.2. AS Request Creation Hints 583 Parameters that can appear in the AS Request Creation Hints message 584 are specified in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. RS 585 MUST use the "AS" parameter to transport LOC_W, i.e. an absolute URI 586 where C can reach the AS. RS MUST use the "audience" parameter to 587 transport the CBOR sequence consisting of two elements: CC, the 588 crypto context; CIPHERTEXT_RQ, the authenticated encrypted identity 589 of the RS. The "cnonce" parameter MUST be implied to G^X, i.e. the 590 ephemeral public key of the RS in the underlying LAKE exchange. The 591 "cnonce" parameter is not carried in the AS Request Creation Hints 592 message for byte saving reasons. AS Request Creation Hints MUST be 593 carried within Auxiliary Data of the LAKE message 1 (AD1). 595 An example AD1 value in CBOR diagnostic notation is shown below: 597 AD1: 598 { 599 "AS" : "coaps://as.example.com/token", 600 "audience": << h'73',h'737570657273...' >> 601 } 603 5.3. Client-to-AS Request 605 The protocol that provides the secure channel between C and the AS is 606 out-of-scope. This can, for example, be TLS or DTLS. What is 607 important is that the two peers are mutually authenticated, and that 608 the secure channel provides message integrity, confidentiality and 609 freshness. It is also necessary for the AS to be able to extract the 610 public key of C used in the underlying security handshake. 612 C sends the POST request to the token endpoint at the AS following 613 Section 5.6.1. of [I-D.ietf-ace-oauth-authz]. C MUST set the 614 "audience" parameter to the value received in AS Request Creation 615 Hints. C MUST set the "cnonce" parameter to G^X, the ephemeral 616 public key of RS in the LAKE handshake. 618 An example exchange using CoAP and CBOR diagnostic notation is shown 619 below: 621 Header: POST (Code=0.02) 622 Uri-Host: "as.example.com" 623 Uri-Path: "token" 624 Content-Format: "application/ace+cbor" 625 Payload: 626 { 627 "audience" : << h'73',h'737570657273...' >> 628 "cnonce" : h'756E73686172...' 629 } 631 5.4. AS-to-Client Response 633 Given successful authorization of C at the AS, the AS responds by 634 issuing a Bearer token and retrieves the certificate of RS on behalf 635 of C. The access token and the certificate are passed back to C, who 636 uses it to complete the LAKE handshake. This document extends the 637 ACE framework by registering a new Access Information parameter: 639 rsp_ad: OPTIONAL. Carries additional information from the AS to C 640 associated with the access token. 642 When responding to C, the AS MUST set the "ace_profile" parameter to 643 "lake". The AS MUST set the "token_type" parameter to "Bearer". The 644 access token MUST be formatted as specified in Section 4.1.1. The AS 645 MUST set the "rsp_ad" parameter to the certificate of RS. To be able 646 to do so, AS first needs to decrypt the audience value, and based on 647 it retrieve the corresponding RS certificate. 649 An example AS response to C is shown below: 651 2.01 Created 652 Content-Format: application/ace+cbor 653 Max-Age: 3600 654 Payload: 655 { 656 "ace_profile" : "lake", 657 "token_type" : "Bearer", 658 "access_token" : h'666F726571756172746572...', 659 "rsp_ad" : h'61726973746F64656D6F637261746963616C...' 660 } 662 6. Security Considerations 664 TODO: Identity protection of device 666 TODO: Use of G_X as ephemeral key between device and authenticator, 667 and between device and authorization server 669 TODO: Remote attestation 671 7. IANA Considerations 673 TODO: CC registry 675 TODO: Voucher type registry 677 TODO: register rsp_ad ACE parameter 679 8. Informative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 687 Levkowetz, Ed., "Extensible Authentication Protocol 688 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 689 . 691 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 692 Constrained-Node Networks", RFC 7228, 693 DOI 10.17487/RFC7228, May 2014, 694 . 696 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 697 RFC 8152, DOI 10.17487/RFC8152, July 2017, 698 . 700 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 701 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 702 May 2017, . 704 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 705 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 706 . 708 [I-D.ietf-lake-reqs] 709 Vucinic, M., Selander, G., Mattsson, J., and D. Garcia- 710 Carillo, "Requirements for a Lightweight AKE for OSCORE", 711 Work in Progress, Internet-Draft, draft-ietf-lake-reqs-01, 712 19 February 2020, . 715 [I-D.ietf-ace-oauth-authz] 716 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 717 H. Tschofenig, "Authentication and Authorization for 718 Constrained Environments (ACE) using the OAuth 2.0 719 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 720 draft-ietf-ace-oauth-authz-33, 6 February 2020, 721 . 724 [I-D.raza-ace-cbor-certificates] 725 Raza, S., Hoglund, J., Selander, G., Mattsson, J., and M. 726 Furuhed, "CBOR Profile of X.509 Certificates", Work in 727 Progress, Internet-Draft, draft-raza-ace-cbor- 728 certificates-03, 20 December 2019, . 731 [I-D.irtf-cfrg-hpke] 732 Barnes, R. and K. Bhargavan, "Hybrid Public Key 733 Encryption", Work in Progress, Internet-Draft, draft-irtf- 734 cfrg-hpke-02, 4 November 2019, . 737 [I-D.ietf-ace-coap-est] 738 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 739 "EST over secure CoAP (EST-coaps)", Work in Progress, 740 Internet-Draft, draft-ietf-ace-coap-est-18, 6 January 741 2020, . 744 [I-D.ietf-6tisch-minimal-security] 745 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 746 "Constrained Join Protocol (CoJP) for 6TiSCH", Work in 747 Progress, Internet-Draft, draft-ietf-6tisch-minimal- 748 security-15, 10 December 2019, . 752 [I-D.selander-lake-edhoc] 753 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 754 Diffie-Hellman Over COSE (EDHOC)", Work in Progress, 755 Internet-Draft, draft-selander-lake-edhoc-00, 4 November 756 2019, . 759 Authors' Addresses 761 Goeran Selander 762 Ericsson AB 764 Email: goran.selander@ericsson.com 766 John Preuss Mattsson 767 Ericsson AB 769 Email: john.mattsson@ericsson.com 771 Malisa Vucinic 772 INRIA 774 Email: malisa.vucinic@inria.fr 776 Michael Richardson 777 Sandelman Software Works 779 Email: mcr+ietf@sandelman.ca 781 Aurelio Schellenbaum 782 Institute of Embedded Systems, ZHAW 784 Email: aureliorubendario.schellenbaum@zhaw.ch