idnits 2.17.1 draft-selander-ace-ake-authz-04.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. 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 (22 October 2021) is 909 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-45 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-12 == Outdated reference: A later version (-06) exists of draft-selander-ace-coap-est-oscore-05 -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 5 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. Preuß Mattsson 4 Intended status: Informational Ericsson AB 5 Expires: 25 April 2022 M. Vučinić 6 INRIA 7 M. Richardson 8 Sandelman Software Works 9 A. Schellenbaum 10 ZHAW 11 22 October 2021 13 Lightweight Authorization for Authenticated Key Exchange. 14 draft-selander-ace-ake-authz-04 16 Abstract 18 This document describes a procedure for augmenting the lightweight 19 authenticated Diffie-Hellman key exchange protocol EDHOC with third 20 party assisted authorization, targeting constrained IoT deployments 21 (RFC 7228). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 25 April 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 59 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Device . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Domain Authenticator . . . . . . . . . . . . . . . . . . 4 62 3.3. Authorization Server . . . . . . . . . . . . . . . . . . 5 63 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Reuse of EDHOC . . . . . . . . . . . . . . . . . . . . . 6 66 4.3. Device <-> Authorization Server . . . . . . . . . . . . . 8 67 4.4. Device <-> Authenticator . . . . . . . . . . . . . . . . 11 68 4.5. Authenticator <-> Authorization Server . . . . . . . . . 13 69 5. ACE Profile . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 5.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 16 71 5.2. AS Request Creation Hints . . . . . . . . . . . . . . . . 17 72 5.3. Client-to-AS Request . . . . . . . . . . . . . . . . . . 17 73 5.4. AS-to-Client Response . . . . . . . . . . . . . . . . . . 18 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 8. Informative References . . . . . . . . . . . . . . . . . . . 20 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 79 1. Introduction 81 For constrained IoT deployments [RFC7228] the overhead and processing 82 contributed by security protocols may be significant which motivates 83 the specification of lightweight protocols that are optimizing, in 84 particular, message overhead (see [I-D.ietf-lake-reqs]). This 85 document describes a procedure for augmenting the lightweight 86 authenticated Diffie-Hellman key exchange EDHOC [I-D.ietf-lake-edhoc] 87 with third party-assisted authorization. 89 The procedure involves a device, a domain authenticator and an 90 authorization server. The device and authenticator perform mutual 91 authentication and authorization, assisted by the authorization 92 server which provides relevant authorization information to the 93 device (a "voucher") and to the authenticator. 95 The protocol assumes that authentication between device and 96 authenticator is performed with EDHOC, and defines the integration of 97 a lightweight authorization procedure using the External 98 Authorization Data (EAD) field defined in EDHOC. 100 In this document we consider the target interaction for which 101 authorization is needed to be "enrollment", for example joining a 102 network for the first time (e.g. [RFC9031]), or certificate 103 enrollment (such as [I-D.selander-ace-coap-est-oscore]), but it can 104 be applied to authorize other target interactions. 106 The protocol enables a low message count by performing authorization 107 and enrollment in parallel with authentication, instead of in 108 sequence which is common for network access. It further reuses 109 protocol elements from EDHOC leading to reduced message sizes on 110 constrained links. 112 This protocol is applicable to a wide variety of settings, and can be 113 mapped to different authorization architectures. This document 114 specifies a profile of the ACE framework [I-D.ietf-ace-oauth-authz]. 115 Other settings such as EAP [RFC3748] are out of scope for this 116 specification. 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 Readers are expected to have some understanding of CBOR [RFC8949] and 127 EDHOC [I-D.ietf-lake-edhoc]. Appendix C.1 of [I-D.ietf-lake-edhoc] 128 contains some basic info about CBOR. 130 2. Problem Description 132 The (potentially constrained) device wants to enroll into a domain 133 over a constrained link. The device authenticates and enforces 134 authorization of the (non-constrained) domain authenticator with the 135 help of a voucher, and makes the enrollment request. The domain 136 authenticator authenticates the device and authorizes its enrollment. 137 Authentication between device and domain authenticator is made with 138 the lightweight authenticated Diffie-Hellman key exchange protocol 139 EDHOC [I-D.ietf-lake-edhoc]. The procedure is assisted by a (non- 140 constrained) authorization server located in a non-constrained 141 network behind the domain authenticator providing information to the 142 device and to the domain authenticator as part of the protocol. 144 The objective of this document is to specify such a protocol which is 145 lightweight over the constrained link and reuses elements of EDHOC. 146 See illustration in Figure 1. 148 Voucher 149 EDHOC Info 150 +----------+ | | +---------------+ Voucher +---------------+ 151 | | | | | | Request | | 152 | Device |--|----o-->| Domain |---------->| Authorization | 153 | |<-|---o----| Authenticator |<----------| Server | 154 | (U) |--|---|--->| (V) | Voucher | (W) | 155 | | | | | Response | | 156 +----------+ | +---------------+ +---------------+ 157 Voucher 159 Figure 1: Overview of message flow. Link between U anv V is 160 constrained but link between V and W is not. Voucher Info and 161 Voucher are sent in EDHOC External Authorization Data. 163 3. Assumptions 165 3.1. Device 167 The device is pre-provisioned with an identity ID_U and asymmetric 168 key credentials: a private key, a public key (PK_U), and optionally a 169 public key certificate (Cert_PK_U), issued by a trusted third party 170 such as e.g. the device manufacturer, used to authenticate to the 171 domain authenticator. ID_U may be a reference or pointer to the 172 certificate. 174 The device is also provisioned with information about its 175 authorization server: 177 * At least one static public DH key of the authorization server 178 (G_W) used to ensure secure communication with the device (see 179 Section 4.3). 181 * Location information about the authorization server (LOC_W), e.g. 182 its domain name. This information may be available in the device 183 certificate Cert_PK_U. 185 3.2. Domain Authenticator 187 The domain authenticator has a private key and a corresponding public 188 key PK_V used to authenticate to the device. 190 The domain authenticator needs to be able to locate the authorization 191 server of the device for which LOC_W is expected to be sufficient. 192 The communication between domain authenticator and authorization 193 server is assumed to be mutually authenticated and protected; 194 authentication credentials and communication security is out of 195 scope, except for as specified below in this section. 197 The domain authenticator may in principle use differents credentials 198 for authenticating to the authorization server and to the device, for 199 which PK_V is used. However, the domain authenticator MUST prove 200 possession of private key of PK_V to the authorization server since 201 the authorization server is asserting (by means of the voucher to the 202 device) that this credential belongs to the domain authenticator. 204 In this version of the draft it is assumed that the domain 205 authenticator authenticates to the authorization server with PK_V 206 using some authentication protocol providing proof of possession of 207 the private key, for example TLS 1.3 [RFC8446]. A future version of 208 this draft may specify explicit proof of possession of the private 209 key of PK_V in the voucher request, e.g., by including a signature of 210 the voucher request with the private key corresponding to PK_V. 212 3.3. Authorization Server 214 The authorization server has the private DH key corresponding to G_W, 215 which is used to secure the communication with the device (see 216 Section 4.3). 218 Authentication credentials and communication security used with the 219 domain authenticator is out of scope, except for the need to verify 220 the possession of the private key of PK_V as specified in 221 Section 3.2. 223 The authorization server provides to the device the authorization 224 decision for enrollment with the domain authenticator in the form of 225 a voucher. The authorization server provides information to the 226 domain authenticator about the device, such as the device's 227 certificate Cert_PK_U. 229 The authorization server needs to be available during the execution 230 of the protocol. 232 4. The Protocol 234 4.1. Overview 236 Three security sessions are going on in parallel: 238 1. EDHOC [I-D.ietf-lake-edhoc] between device (U) and (domain) 239 authenticator (V) 241 2. Voucher Request/Response between authenticator (V) and 242 authorization server (W) 244 3. An exchange of voucher-related information, including the voucher 245 itself, between device (U) and authorization server (W), mediated 246 by the authenticator. 248 Figure 2 provides an overview of the message flow detailed in this 249 section. Only selected message fields of EDHOC are shown, for more 250 details see Section 3.1 of [I-D.ietf-lake-edhoc]. 252 U V W 253 | | | 254 | SUITES_I, G_X, EAD_1 | | 255 +----------------------------------->| | 256 | EDHOC message_1 | SS, G_X, ENC_ID, ?PoP_V | 257 | +----------------------------->| 258 | | Voucher Request (VREQ) | 259 | | | 260 | | G_X, CERT_PK_U, Voucher | 261 | |<-----------------------------+ 262 | | Voucher Response (VRES) | 263 | ID_CRED_R, Sig_or_MAC_2, EAD_2 | | 264 |<-----------------------------------+ | 265 | EDHOC message_2 | | 266 | | | 267 | ID_CRED_I, Sig_or_MAC_3 | | 268 +----------------------------------->| | 269 | EDHOC message_3 | | 271 where 272 EAD_1 = (L, Voucher_Info) 273 Voucher_Info = [LOC_W, ENC_ID] 274 EAD_2 = (L, Voucher) 275 Voucher = MAC(V_TYPE, SS, G_X, ID_U, PK_V) 277 Figure 2: W-assisted authorization of AKE between U and V: EDHOC 278 between U and V (only selected message fields shown), and Voucher 279 Request/Response between V and W. 281 4.2. Reuse of EDHOC 283 The protocol illustrated in Figure 2 reuses several components of 284 EDHOC: 286 * G_X, the 'x' parameter of the ephemeral public Diffie-Hellman key 287 of party U, is also used in the protocol between U and W, as 288 ephemeral key and nonce. 290 * SUITES_I, the cipher suites relevant to U, which includes the 291 selected cipher suite - here denoted SS, also defines the 292 algorithms used between U and W. In particular SS contains 293 information about (see Section 3.6 of [I-D.ietf-lake-edhoc]): 295 - EDHOC AEAD algorithm: used to encrypt the identity of U 297 - EDHOC hash algorithm: used for key derivation and to calculate 298 the voucher 300 - EDHOC MAC length in bytes: length of the voucher 302 - EDHOC key exchange algorithm: used to calculate the shared 303 secret between U and W 305 * EAD_1, EAD_2 are the External Authorization Data of message_1 and 306 message_2, respectively, for which dedicated content is defined in 307 this document. 309 * ID_CRED_I and ID_CRED_R are used to identify the public 310 authentication keys of U and V. In this protocol ID_CRED_I can be 311 empty since V obtains the certificate of U from W, whereas 312 ID_CRED_R contains the public authentication key of V. 314 * Signature_or_MAC_2 and Signature_or_MAC_3 (abbreviated in 315 Figure 2), containing data generated using the private key of V 316 and U, respectively, are shown here just to be able to reason 317 about the use of credentials. 319 The protocol also reuses the Extract and Expand key derivation from 320 EDHOC (Section 4 of [I-D.ietf-lake-edhoc]). 322 * The intermediate pseudo-random key PRK is derived using Extract(): 324 - PRK = Extract(salt, IKM) 326 o where salt = 0x (the zero-length byte string) 328 o IKM is the ECDH shared secret G_XW (calculated from G_X and 329 W or G_W and X) as defined in Section 6.3.1 of [I-D.ietf- 330 cose-rfc8152bis-algs]. 332 The shared secret is derived using Expand() which is defined in terms 333 of the EDHOC hash algorithm of the selected cipher suite, see 334 Section 4.2. of [I-D.ietf-lake-edhoc]: 336 * shared secret = Expand(PRK, info, length) 338 where 340 info = ( 341 transcript_hash : bstr, 342 label : tstr, 343 context : bstr, 344 length : uint, 345 ) 347 4.3. Device <-> Authorization Server 349 The protocol between device and authorization server (U and W in 350 Figure 2) is carried out via the authenticator (V) with certain data 351 protected between the endpoints using the equivalent of a hybrid 352 encryption scheme (see, e.g., [I-D.irtf-cfrg-hpke]). The device uses 353 the public DH key of the authorization server G_W together with the 354 private DH key corresponding to ephemeral key G_X in EDHOC message_1, 355 and vice versa for the authorization server. The endpoints calculate 356 a shared secret G_XW (see Section 4.2), which is used to derive 357 secret keys to protect data between U and W, as detailed in this 358 section. 360 The data exchanged betweeen U and W is carried between U and V in 361 EAD_1 and EAD_2 (Section 4.4), and between V and W in Voucher 362 Request/Response (Section 4.5). 364 4.3.1. Voucher Info 366 The external authorization data EAD_1 of EDHOC message_1 includes 367 Voucher Info, which is the following CBOR sequence: 369 Voucher_Info = ( 370 LOC_W: tstr, 371 ENC_ID: bstr 372 ) 374 where 376 * LOC_W is location information about the authorization server, used 377 by the authenticator 379 * ENC_ID is the encrypted blob carrying the identity of the device 380 and an optional identity of the authenticator, passed on from the 381 authenticator to the authorization server, calculated as follows: 383 ENC_ID is 'ciphertext' of COSE_Encrypt0 (Section 5.2-5.3 of 384 [RFC8152]) computed from the following: 386 * The encryption key K_1 and nonce IV_1 are derived as specified 387 below. 389 * 'protected' is a byte string of size 0 391 * 'plaintext and 'external_aad' as below: 393 plaintext = ( 394 ID_U: bstr, 395 ? ID_V: bstr, 396 ) 398 external_aad = ( 399 SS: int, 400 ) 402 where 404 * ID_U is the identity of the device, for example a reference or 405 pointer to the device certificate 407 * ID_V is the identity of the authenticator as presented to the 408 authorization server. This may be a name in a name space agreed 409 out-of-band and managed by a party trusted by the authorization 410 server, for example a common name of an X.509 certificate signed 411 by a CA trusted by the authorization server. The value may be 412 obtained by the device through out-of-band means, possibly through 413 secure network discovery. 415 * SS is the selected cipher suite in SUITES_I. 417 The derivation of K_1 = Expand(PRK, info, length) uses the following 418 input to the info struct (Section 4.2): 420 * transcript_hash = h'' 422 * label is "EDHOC_ACE_AKE_AUTHZ_K_1" 424 * context = h'' 426 * length is length of key of the EDHOC AEAD algorithm 427 The derivation of IV_1 = Expand(PRK, info, length) uses the following 428 input to the info struct (Section 4.2): 430 * transcript_hash = h'' 432 * label is "EDHOC_ACE_AKE_AUTHZ_IV_1" 434 * context = h'' 436 * length is length of nonce of the EDHOC AEAD algorithm 438 4.3.2. Voucher 440 The voucher is an assertion by the authorization server to the device 441 that the authorization server has performed the relevant 442 verifications and that the device is authorized to continue the 443 protocol with the authenticator. The Voucher is essentially a 444 message authentication code which binds the identity of the 445 authenticator to message_1 of EDHOC, integrity protected with the 446 shared secret context between U and W. 448 The calculation of Voucher = Expand(PRK, info, length) uses the 449 following input to the info struct (Section 4.2): 451 * transcript_hash = h'' 453 * label is "EDHOC_ACE_AKE_AUTHZ_MAC" 455 * context = bstr .cbor voucher_input 457 * length is EDHOC MAC length in bytes 459 where context is a CBOR bstr wrapping of voucher_input: 461 voucher_input = ( 462 V_TYPE: int, 463 SS: int, 464 G_X: bstr, 465 ID_U: bstr, 466 PK_V: bstr, 467 ) 469 where 471 * V_TYPE indicates the type of voucher used (TBD) 473 * SS is the selected cipher suite of the EDHOC protocol, see 474 Section 4.2 476 * PK_V is a CWT Claims Set (CCS, [RFC8392]) containing the public 477 authentication key of the authenticator encoded as a COSE_Key in 478 the 'cnf' claim, see Section 3.5.3 of [I-D.ietf-lake-edhoc]. 480 * G_X is encoded as in EDHOC message_1, see Section 3.7 of 481 [I-D.ietf-lake-edhoc] 483 * ID_U is defined in Section 4.3 485 Editor's note: With the current definition of EAD as (ead_label, 486 ead_value), do we need to redefine the voucher to be a CBOR map? Do 487 we even need the V_TYPE? 489 4.4. Device <-> Authenticator 491 The device and authenticator run the EDHOC protocol authenticated 492 with their public keys (PK_U and PK_V), see Figure 2. Normal EDHOC 493 processing is omitted here. 495 4.4.1. Message 1 497 4.4.1.1. Device processing 499 The device composes EDHOC message_1 using authentication method, 500 identifiers, etc. according to the applicability statement, see 501 Section 3.9 of [I-D.ietf-lake-edhoc]. The selected cipher suite SS 502 applies also to the interaction with the authorization server as 503 detailed in Section 4.2, in particular, the key agreement algorithm 504 which is used with the static public DH key G_W of the authorization 505 server. As part of the normal EDHOC processing, the device generates 506 the ephemeral public key G_X which is reused in the interaction with 507 the authorization server, see Section 4.3. 509 The device sends EDHOC message_1 with EAD_1 = (L, Voucher_Info) where 510 L is the External Auxiliary Data Label for this protocol (IANA 511 registry created in Section 9.5 of [I-D.ietf-lake-edhoc]), and 512 Voucher_Info is specified in Section 4.3. 514 4.4.1.2. Authenticator processing 516 The authenticator receives EDHOC message_1 from the device and 517 processes as specified in Section 5.2.3 of [I-D.ietf-lake-edhoc], 518 with the additional step that the presence of EAD with label L 519 triggers the voucher request to the authorization server as described 520 in Section 4.5. The exchange with V needs to be completed 521 successfully for the EDHOC exchange to be continued. 523 4.4.2. Message 2 525 4.4.2.1. Authenticator processing 527 The authenticator receives the voucher response from the 528 authorization server as described in Section 4.5. 530 The authenticator sends EDHOC message_2 to the device with EAD_2 = 531 (L, Voucher) where L is the External Auxiliary Data Label for this 532 protocol (IANA registry created in Section 9.5 of 533 [I-D.ietf-lake-edhoc]) and the Voucher is specified in Section 4.3. 535 CRED_R is a CWT Claims Set (CCS, [RFC8392]) containing the public 536 authentication key of the authenticator PK_V encoded as a COSE_Key in 537 the 'cnf' claim, see Section 3.5.3 of [I-D.ietf-lake-edhoc]. 539 ID_CRED_R contains the CCS with 'kccs' as COSE header_map, see 540 Section 9.6 of [I-D.ietf-lake-edhoc]. The Sig_or_MAC_2 field 541 calculated using the private key corresponding to PK_V is either 542 signature or MAC depending on EDHOC method. 544 4.4.2.2. Device processing 546 In addition to normal EDHOC verifications, the device MUST verify the 547 Voucher by performing the same calculation as in Section 4.3.2 using 548 the SS, G_X and ID_U carried in message_1 and PK_V received in 549 message_2. If the voucher calculated in this way is not identical to 550 what was received in message_2, then the device MUST discontinue the 551 protocol. 553 Editor's note: Consider replace SS, G_X, ID_U in Voucher with 554 H(message_1), since that is already required by EDHOC to be cached by 555 the initiator. H(message_1) needs to be added to VREQ message in 556 that case. 558 4.4.3. Message 3 560 4.4.3.1. Device processing 562 If all verifications are passed, then the device sends EDHOC 563 message_3. 565 The message field ID_CRED_I contains data enabling the authenticator 566 to retrieve the public key of the device, PK_U. Since the 567 authenticator before sending message_2 received a certificate of PK_U 568 from the authorization server (see Section 4.5), ID_CRED_I SHALL be a 569 COSE header_map of type 'kid' with the empty byte string as value: 571 ID_CRED_I = 572 { 573 4 : h'' 574 } 576 The Sig_or_MAC_3 field calculated using the private key corresponding 577 to PK_U is either signature or MAC depending on EDHOC method. 579 EAD_3 MAY contain an enrolment request, see e.g. CSR specified in 580 [I-D.mattsson-cose-cbor-cert-compress], or other request which the 581 device is now authorized to make. 583 EDHOC message_3 may be combined with an OSCORE request, see 584 [I-D.palombini-core-oscore-edhoc]. 586 4.4.3.2. Authenticator processing 588 The authenticator performs the normal EDHOC verifications of 589 message_3, with the exception that the Sig_or_MAC_3 field MUST be 590 verified using the public key included in Cert_PK_U (see 591 Section 4.5.2) received from the authorization server. The 592 authenticator MUST ignore any key related information obtained in 593 ID_CRED_I. 595 This enables the authenticator to verify that message_3 was generated 596 by the device authorized by the authorization server as part of the 597 associated Voucher Request/Response procedure (see Section 4.5). 599 4.5. Authenticator <-> Authorization Server 601 The authenticator and authorization server are assumed to have, or to 602 be able to, set up a secure connection, for example TLS 1.3 603 authenticated with certificates. The authenticator is assumed to 604 authenticate with the public key PK_V, see Section 3.2. 606 This secure connection protects the Voucher Request/Response Protocol 607 (see protocol between V and W in Figure 2). 609 The ephemeral public key G_X sent in EDHOC message_1 from device to 610 authenticator serves as challenge/response nonce for the Voucher 611 Request/Response Protocol, and binds together instances of the two 612 protocols. 614 4.5.1. Voucher Request 615 4.5.1.1. Authenticator processing 617 Unless already in place, the authenticator and the authorization 618 server establish a secure connection. The autenticator uses G_X 619 received from the device as a nonce associated to this connection 620 with the authorization server. If the same value of the nonce G_X is 621 already used for a connection with this or other authorization 622 server, the protocol SHALL be discontinued. 624 The authenticator sends the voucher request to the authorization 625 server. The Voucher Request SHALL be a CBOR array as defined below: 627 Voucher_Request = [ 628 SS: int, 629 G_X: bstr, 630 ENC_ID: bstr, 631 ? PoP_V: bstr, 632 ] 634 where all parameters are defined in Section 4.3, except 636 * PoP_V is a proof-of-possession of public key PK_V using the 637 corresponding private key 639 Editor's note: Define PoP_V (include G_X, ENC_ID in the calculation 640 for binding to this EDHOC session). One case to study is when V 641 authenticates to U with static DH and to W with signature. 643 4.5.1.2. Authorization Server processing 645 The authorization server receives the voucher request, verifies and 646 decrypts the identity ID_U of the device, and associates the nonce 647 G_X to ID_U. If G_X is not unique among nonces associated to this 648 identity, the protocol SHALL be discontinued. If ENC_ID also 649 included the identity of V, ID_V, then the authorization server 650 performs an additional check to verify that the identity of the 651 authenticator who sent the voucher request over a secure session 652 between V-W matches the identity of the authenticator as observed by 653 U. If the identities of V as observed by U, and as observed by W, do 654 not match, the protocol SHALL be discontinued. 656 4.5.2. Voucher Response 658 4.5.2.1. Authorization Server processing 660 The authorization server uses the identity of the device, ID_U, to 661 look up the device certificate, Cert_PK_U. 663 The authorization server retrieves the public key of V used to 664 authenticate the secure connection with the authenticator, and 665 constructs the CWT Claims Set and the Voucher as defined in 666 Section 4.3.2. 668 The authorization server generates the voucher response and sends it 669 to the authenticator over the secure connection. The 670 Voucher_Response SHALL be a CBOR array as defined below: 672 Voucher_Response = [ 673 G_X: bstr, 674 CERT_PK_U: bstr, 675 Voucher: bstr 676 ] 678 where 680 * G_X is copied from the associated voucher request. 682 * CERT_PK_U is the device certificate of the public key PK_U, issued 683 by a trusted third party. The format of this certificate is out 684 of scope. 686 * The Voucher is defined in Section 4.3.2. 688 4.5.2.2. Authenticator processing 690 The authenticator receives the voucher response from the 691 authorization server over the secure connection. If the received G_X 692 does not match the value of the nonce associated to the secure 693 connection, the protocol SHALL be discontinued. 695 The authenticator verifies the certificate CERT_PK_U and that U is an 696 admissible device, or else discontinues the protocol. 698 5. ACE Profile 700 The messages specified in this document may be carried between the 701 endpoints in various protocols. This section defines an embedding as 702 a profile of the ACE framework (see Appendix C of 703 [I-D.ietf-ace-oauth-authz]). 705 * U plays the role of the ACE Resource Server (RS). 707 * V plays the role of the ACE Client (C). 709 * W plays the role of the ACE Authorization Server (AS). 711 Many readers who are used to the diagram having the Client on the 712 left may be surprised at the cast of characters. The "resource" 713 which C (V) is trying to access is the "ownership" of U. The AS (W) 714 is the manufacturer (or previous owner) of RS (U), and is therefore 715 in a position to grant C (V) ownership of RS (U). 717 C and RS use EDHOC's EAD to communicate. C and RS use the EDHOC 718 protocol to protect their communication. EDHOC also provides mutual 719 authentication of C and RS, assisted by the AS. 721 5.1. Protocol Overview 723 RS (U) C (V) AS (W) 724 | EDHOC message_1 | | 725 | AD1=AS Request Creation Hints | | 726 |-------------------------------->| POST /token | 727 | |-------------------->| 728 | | | 729 | | Access Token + | 730 | EDHOC message_2 | Access Information | 731 | AD2=Access Token |<--------------------| 732 |<--------------------------------| | 733 | EDHOC message_3 | | 734 |-------------------------------->| | 736 Figure 3: Overview of the protocol mapping to ACE 738 1. RS proactively sends the AS Request Creation Hints message to C 739 to signal the information on where C can reach the AS. 741 2. RS piggybacks the AS Request Creation Hints message using 742 Auxiliary Data of EDHOC message_1. 744 3. Before continuing the EDHOC exchange, based on the AS Request 745 Creation Hints information, C sends a POST request to the token 746 endpoint at the AS requesting the access token. 748 4. The AS issues an assertion to C that is cryptographically 749 protected based on the secret shared between the AS and RS. In 750 this profile, the assertion is encoded as a Bearer Token. 752 5. C presents this token to RS in EAD_2. 754 6. RS verifies the token based on the possession of the shared 755 secret with the AS and authenticates C. 757 5.2. AS Request Creation Hints 759 Parameters that can appear in the AS Request Creation Hints message 760 are specified in Section 5.3 of [I-D.ietf-ace-oauth-authz]. RS MUST 761 use the "AS" parameter to transport LOC_W, i.e. an absolute URI where 762 C can reach the AS. RS MUST use the "audience" parameter to 763 transport the CBOR sequence consisting of two elements: SS, the 764 selected cipher suite; ENC_ID, the AEAD encrypted blob containing 765 identities. The "cnonce" parameter MUST be implied to G_X, i.e. the 766 ephemeral public key of the RS in the underlying EDHOC exchange. The 767 "cnonce" parameter is not carried in the AS Request Creation Hints 768 message for byte saving reasons. AS Request Creation Hints MUST be 769 carried within EAD_1. 771 An example EAD_1 value in CBOR diagnostic notation is shown below: 773 EAD_1: 774 { 775 "AS" : "coaps://as.example.com/token", 776 "audience": << h'73',h'737570657273...' >> 777 } 779 5.3. Client-to-AS Request 781 The protocol that provides the secure connection between C and the AS 782 is out-of-scope. This can, for example, be TLS 1.3. What is 783 important is that the two peers are mutually authenticated, and that 784 the secure connection provides message integrity, confidentiality and 785 freshness. It is also necessary for the AS to be able to extract the 786 public key of C used in the underlying security handshake. 788 C sends the POST request to the token endpoint at the AS following 789 Section 5.8.1. of [I-D.ietf-ace-oauth-authz]. C MUST set the 790 "audience" parameter to the value received in AS Request Creation 791 Hints. C MUST set the "cnonce" parameter to G_X, the ephemeral 792 public key of RS in the EDHOC exchange. 794 An example exchange using CoAP and CBOR diagnostic notation is shown 795 below: 797 Header: POST (Code=0.02) 798 Uri-Host: "as.example.com" 799 Uri-Path: "token" 800 Content-Format: "application/ace+cbor" 801 Payload: 802 { 803 "audience" : << h'73',h'737570657273...' >> 804 "cnonce" : h'756E73686172...' 805 } 807 5.4. AS-to-Client Response 809 Given successful authorization of C at the AS, the AS responds by 810 issuing a Bearer token and retrieves the certificate of RS on behalf 811 of C. The access token and the certificate are passed back to C, who 812 uses it to complete the EDHOC exchange. This document extends the 813 ACE framework by registering a new Access Information parameter: 815 rsp_ad: OPTIONAL. Carries additional information from the AS to C 816 associated with the access token. 818 The AS-to-Client responsE MUST contain: 820 * ace_profileparameter set to "edhoc-authz" 822 * token_type parameter set to "Bearer" 824 * access_token as specified in Section 4.3.2 826 * rsp_ad = bstr .cbor cert_gx 828 cert_gx = ( 829 CERT_PK_U: bstr, 830 G_X: bstr 831 ) 833 where: 835 * CERT_PK_U is the RS's certificate, as discussed in Section 4.5.2. 836 To be able to retrieve this certificate, the AS first needs to 837 decrypt the audience value and obtain the RS's identity. 839 * G_X is the ephemeral key generated by RS in EDHOC message_1. 841 An example AS response to C is shown below: 843 2.01 Created 844 Content-Format: application/ace+cbor 845 Max-Age: 3600 846 Payload: 847 { 848 "ace_profile" : "edhoc-authz", 849 "token_type" : "Bearer", 850 "access_token" : h'666F726571756172746572...', 851 "rsp_ad" : h'61726973746F64656D6F637261746963616C...' 852 } 854 6. Security Considerations 856 This specification builds on and reuses many of the security 857 constructions of EDHOC, e.g. shared secret calculation and key 858 derivation. The security considerations of EDHOC 859 [I-D.ietf-lake-edhoc] apply with modifications discussed here. 861 EDHOC provides identity protection of the Initiator, disclosed to the 862 Responder in message_3. The sending of the certificate of U in the 863 Voucher Response provides information about the identity of the 864 device already before message_2, which changes the identity 865 protection properties and thus needs to be validated against a given 866 use case. The authorization server authenticates the authenticator, 867 receives the Voucher Request, and can perform potential other 868 verifications before sending the Voucher Response. This allows the 869 authorization server to restrict information about the identity of 870 the device to parties which are authorized to have that. However, if 871 there are multiple authorized authenticators, the authorization 872 server may not be able to distinguish between authenticator V which 873 the device is connecting to and a misbehaving but authorized 874 authenticator V' constructing a Voucher Request built from an 875 eavesdropped message_1. A mitigation for this kind of misbehaving 876 authenticator is that the device discovers the identity of the 877 authenticator through out-of-bands means before attempting to enroll, 878 and include the optional ID_V in the ENC_ID encrypted blob. For 879 example, the network's discovery mechanism can carry asserted 880 information on the associated identity of the authenticator. The use 881 of ID_V also changes the identity protection assumptions since it 882 requires U to know the identity of V before the protocol starts. The 883 identity of V is still protected against passive adversaries, unless 884 disclosed by the out-of-band mechanism by which U acquires 885 information about the identity of V. The privacy considerations 886 whether the identity of the device or of the authenticator is more 887 sensitive need to be studied depending on a specific use case. 889 For use cases where neither the early disclosure of the device nor of 890 the authenticator identities are deemed acceptable, the device 891 certificate must not be sent in the Voucher Response, and the 892 identity of V must be omitted. Instead, the device certificate could 893 be retrieved from the authorization server or other certificate 894 repository after message_3 is received by the authenticator, using 895 the device identifier provided in ID_CRED_I as lookup. This would 896 require the device identity to be transported in both message_1 (in 897 EAD_1) and message_3 but would make the protocol comply with the 898 default identity protection provided by EDHOC. 900 The encryption of the device identity in the first message should 901 consider potential information leaking from the length of the 902 identifier ID_U, either by making all identifiers having the same 903 length or the use of a padding scheme. 905 As noted Section 8.2 of [I-D.ietf-lake-edhoc] an ephemeral key may be 906 used to calculate several ECDH shared secrets. In this specification 907 the ephemeral key G_X is also used to calculate G_XW, the shared 908 secret with the authorization server. 910 The private ephemeral key is thus used in the device for calculations 911 of key material relating to both the authenticator and the 912 authorization server. There are different options for where to 913 implement these calculations, one option is as an addition to EDHOC, 914 i.e., to extend the EDHOC API in the device with input of public key 915 of W (G_W) and identifier of U (ID_U), and produce the encryption of 916 ID_U which is included in the external authorization data EAD_1. 918 7. IANA Considerations 920 TODO: register rsp_ad ACE parameter 922 8. Informative References 924 [I-D.ietf-ace-oauth-authz] 925 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 926 H. Tschofenig, "Authentication and Authorization for 927 Constrained Environments (ACE) using the OAuth 2.0 928 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 929 draft-ietf-ace-oauth-authz-45, 29 August 2021, 930 . 933 [I-D.ietf-lake-edhoc] 934 Selander, G., Mattsson, J. P., and F. Palombini, 935 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 936 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 937 October 2021, . 940 [I-D.ietf-lake-reqs] 941 Vucinic, M., Selander, G., Mattsson, J. P., and D. Garcia- 942 Carrillo, "Requirements for a Lightweight AKE for OSCORE", 943 Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04, 944 8 June 2020, . 947 [I-D.irtf-cfrg-hpke] 948 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 949 "Hybrid Public Key Encryption", Work in Progress, 950 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 951 . 954 [I-D.mattsson-cose-cbor-cert-compress] 955 Raza, S., Höglund, J., Selander, G., Mattsson, J. P., and 956 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 957 Certificates)", Work in Progress, Internet-Draft, draft- 958 mattsson-cose-cbor-cert-compress-08, 22 February 2021, 959 . 962 [I-D.palombini-core-oscore-edhoc] 963 Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., 964 and G. Selander, "Combining EDHOC and OSCORE", Work in 965 Progress, Internet-Draft, draft-palombini-core-oscore- 966 edhoc-02, 19 February 2021, 967 . 970 [I-D.selander-ace-coap-est-oscore] 971 Selander, G., Raza, S., Furuhed, M., Vucinic, M., and T. 972 Claeys, "Protecting EST Payloads with OSCORE", Work in 973 Progress, Internet-Draft, draft-selander-ace-coap-est- 974 oscore-05, 5 May 2021, . 977 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 978 Requirement Levels", BCP 14, RFC 2119, 979 DOI 10.17487/RFC2119, March 1997, 980 . 982 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 983 Levkowetz, Ed., "Extensible Authentication Protocol 984 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 985 . 987 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 988 Constrained-Node Networks", RFC 7228, 989 DOI 10.17487/RFC7228, May 2014, 990 . 992 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 993 RFC 8152, DOI 10.17487/RFC8152, July 2017, 994 . 996 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 997 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 998 May 2017, . 1000 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1001 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1002 May 2018, . 1004 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1005 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1006 . 1008 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1009 Representation (CBOR)", STD 94, RFC 8949, 1010 DOI 10.17487/RFC8949, December 2020, 1011 . 1013 [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. 1014 Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", 1015 RFC 9031, DOI 10.17487/RFC9031, May 2021, 1016 . 1018 Authors' Addresses 1020 Göran Selander 1021 Ericsson AB 1022 Sweden 1024 Email: goran.selander@ericsson.com 1025 John Preuß Mattsson 1026 Ericsson AB 1027 Sweden 1029 Email: john.mattsson@ericsson.com 1031 Mališa Vučinić 1032 INRIA 1033 France 1035 Email: malisa.vucinic@inria.fr 1037 Michael Richardson 1038 Sandelman Software Works 1039 Canada 1041 Email: mcr+ietf@sandelman.ca 1043 Aurelio Schellenbaum 1044 Institute of Embedded Systems, ZHAW 1045 Switzerland 1047 Email: aureliorubendario.schellenbaum@zhaw.ch