idnits 2.17.1 draft-selander-ace-coap-est-oscore-05.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 (May 05, 2021) is 1086 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) == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-06 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-40 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-18 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-08 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group G. Selander 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track S. Raza 5 Expires: November 6, 2021 RISE 6 M. Furuhed 7 Nexus 8 M. Vucinic 9 INRIA 10 T. Claeys 11 May 05, 2021 13 Protecting EST Payloads with OSCORE 14 draft-selander-ace-coap-est-oscore-05 16 Abstract 18 This document specifies public-key certificate enrollment procedures 19 protected with lightweight application-layer security protocols 20 suitable for Internet of Things (IoT) deployments. The protocols 21 leverage payload formats defined in Enrollment over Secure Transport 22 (EST) and existing IoT standards including the Constrained 23 Application Protocol (CoAP), Concise Binary Object Representation 24 (CBOR) and the CBOR Object Signing and Encryption (COSE) format. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 6, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Operational Differences with EST-coaps . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Authentication . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. EDHOC . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Certificate-based Authentication . . . . . . . . . . . . 6 66 3.3. Channel Binding . . . . . . . . . . . . . . . . . . . . . 6 67 3.4. Optimizations . . . . . . . . . . . . . . . . . . . . . . 6 68 3.5. RPK-based Trust Anchors . . . . . . . . . . . . . . . . . 7 69 4. Protocol Design and Layering . . . . . . . . . . . . . . . . 7 70 4.1. Discovery and URI . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Distribution of RPKs . . . . . . . . . . . . . . . . . . 8 72 4.3. Mandatory/optional EST Functions . . . . . . . . . . . . 8 73 4.4. Payload formats . . . . . . . . . . . . . . . . . . . . . 9 74 4.5. Message Bindings . . . . . . . . . . . . . . . . . . . . 10 75 4.6. CoAP response codes . . . . . . . . . . . . . . . . . . . 11 76 4.7. Message fragmentation . . . . . . . . . . . . . . . . . . 11 77 4.8. Delayed Responses . . . . . . . . . . . . . . . . . . . . 11 78 5. HTTP-CoAP Proxy . . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Other Authentication Methods . . . . . . . . . . . . 15 87 A.1. TTP Assisted Authentication . . . . . . . . . . . . . . . 16 88 A.2. PSK Based Authentication . . . . . . . . . . . . . . . . 17 89 Appendix B. CBOR Encoding of EST Payloads . . . . . . . . . . . 17 90 B.1. Distribution of CA Certificates (/crts) . . . . . . . . . 18 91 B.2. Enrollment/Re-enrollment of Clients (/sen, /sren) . . . . 18 92 B.2.1. CBOR Certificate Request Examples . . . . . . . . . . 19 93 B.2.2. ASN.1 Certificate Request Examples . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 One of the challenges with deploying a Public Key Infrastructure 99 (PKI) for the Internet of Things (IoT) is certificate enrollment, 100 because existing enrollment protocols are not optimized for 101 constrained environments [RFC7228]. 103 One optimization of certificate enrollment targeting IoT deployments 104 is specified in EST-coaps ([I-D.ietf-ace-coap-est]), which defines a 105 version of Enrollment over Secure Transport [RFC7030] for 106 transporting EST payloads over CoAP [RFC7252] and DTLS [RFC6347], 107 instead of secured HTTP. 109 This document describes a method for protecting EST payloads over 110 CoAP or HTTP with OSCORE [RFC8613]. OSCORE specifies an extension to 111 CoAP which protects the application layer message and can be applied 112 independently of how CoAP messages are transported. OSCORE can also 113 be applied to CoAP-mappable HTTP which enables end-to-end security 114 for mixed CoAP and HTTP transfer of application layer data. Hence 115 EST payloads can be protected end-to-end independent of underlying 116 transport and through proxies translating between between CoAP and 117 HTTP. 119 OSCORE is designed for constrained environments, building on IoT 120 standards such as CoAP, CBOR [RFC8949] and COSE [RFC8152], and has in 121 particular gained traction in settings where message sizes and the 122 number of exchanged messages needs to be kept at a minimum, such as 123 6TiSCH [I-D.ietf-6tisch-minimal-security], or for securing multicast 124 CoAP messages [I-D.ietf-core-oscore-groupcomm]. Where OSCORE is 125 implemented and used for communication security, the reuse of OSCORE 126 for other purposes, such as enrollment, reduces the code footprint. 128 In order to protect certificate enrollment with OSCORE, the necessary 129 keying material (notably, the OSCORE Master Secret, see [RFC8613]) 130 needs to be established between EST-oscore client and EST-oscore 131 server. For this purpose we assume the use of the lightweight 132 authenticated key exchange protocol EDHOC [I-D.ietf-lake-edhoc]. 133 Other methods for key establishment are described in Appendix A. 135 Other ways to optimize the performance of certificate enrollment and 136 certificate based authentication described in this draft include the 137 use of: 139 o Compact representations of X.509 certificates (see 140 [I-D.mattsson-cose-cbor-cert-compress]) 142 o Certificates by reference (see [I-D.ietf-cose-x509]) 143 o Compact representations of EST payloads (see Appendix B) 145 1.1. Operational Differences with EST-coaps 147 The protection of EST payloads defined in this document builds on 148 EST-coaps [I-D.ietf-ace-coap-est] but transport layer security is 149 replaced, or complemented, by protection of the transfer- and 150 application layer data (i.e., CoAP message fields and payload). This 151 specification deviates from EST-coaps in the following respects: 153 o The DTLS record layer is replaced, or complemented, with OSCORE. 155 o The DTLS handshake is replaced, or complemented, with the 156 lightweight authenticated key exchange protocol EDHOC 157 [I-D.ietf-lake-edhoc], and makes use of the following features: 159 * Authentication based on certificates is complemented with 160 authentication based on raw public keys. 162 * Authentication based on signature keys is complemented with 163 authentication based on static Diffie-Hellman keys, for 164 certificates/raw public keys. 166 * Authentication based on certificate by value is complemented 167 with authentication based on certificate/raw public keys by 168 reference. 170 o One new EST function, /rpks, is defined for installation of 171 compact explicit TAs in the EST client. 173 o The EST payloads protected by OSCORE can be proxied between 174 constrained networks supporting CoAP/CoAPs and non-constrained 175 networks supporting HTTP/HTTPs with a CoAP-HTTP proxy protection 176 without any security processing in the proxy (see Section 5). The 177 concept "Registrar" and its required trust relation with EST 178 server as described in Section 6 of [I-D.ietf-ace-coap-est] is 179 therefore redundant. 181 So, while the same authentication scheme (Diffie-Hellman key exchange 182 authenticated with transported certificates) and the same EST 183 payloads as EST-coaps also apply to EST-oscore, the latter specifies 184 other authentication schemes and a new matching EST function. The 185 reason for these deviations is that a significant overhead can be 186 removed in terms of message sizes and round trips by using a 187 different handshake, public key type or transported credential, and 188 those are independent of the actual enrollment procedure. 190 Appendix A discusses yet other authentication and secure 191 communication methods. 193 2. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. These 198 words may also appear in this document in lowercase, absent their 199 normative meanings. 201 This document uses terminology from [I-D.ietf-ace-coap-est] which in 202 turn is based on [RFC7030] and, in turn, on [RFC5272]. 204 The term "Trust Anchor" follows the terminology of [RFC6024]: "A 205 trust anchor represents an authoritative entity via a public key and 206 associated data. The public key is used to verify digital 207 signatures, and the associated data is used to constrain the types of 208 information for which the trust anchor is authoritative." One 209 example of specifying more compact alternatives to X.509 certificates 210 for exchanging trust anchor information is provided by the 211 TrustAnchorInfo structure of [RFC5914], the mandatory parts of which 212 essentially is the SubjectPublicKeyInfo structure [RFC5280], i.e., an 213 algorithm identifier followed by a public key. 215 3. Authentication 217 This specification replaces the DTLS handshake in EST-coaps with the 218 lightweight authenticated key exchange protocol EDHOC 219 [I-D.ietf-lake-edhoc]. During initial enrollment the EST-oscore 220 client and server run EDHOC [I-D.ietf-lake-edhoc] to authenticate and 221 establish the OSCORE security context with which the EST payloads are 222 protected. 224 EST-oscore clients and servers MUST perform mutual authentication. 225 The EST server and EST client are responsible for ensuring that an 226 acceptable cipher suite is negotiated. The client MUST authenticate 227 the server before accepting any server response. The server MUST 228 authenticate the client and provide relevant information to the CA 229 for decision about issuing a certificate. 231 3.1. EDHOC 233 EDHOC supports authentication with certificates/raw public keys 234 (referred to as "credentials"), and the credentials may either be 235 transported in the protocol, or referenced. This is determined by 236 the identifier of the credential of the endpoint, ID_CRED_x for x= 237 Initiator/Responder, which is transported in an EDHOC message. This 238 identifier may be the credential itself (in which case the credential 239 is transported), or a pointer such as a URI to the credential (e.g., 240 x5t, see [I-D.ietf-cose-x509]) or some other identifier which enables 241 the receiving endpoint to retrieve the credential. 243 3.2. Certificate-based Authentication 245 EST-oscore, like EST-coaps, supports certificate-based authentication 246 between EST client and server. In this case the client MUST be 247 configured with an Implicit or Explicit Trust Anchor (TA) [RFC7030] 248 database, enabling the client to authenticate the server. During the 249 initial enrollment the client SHOULD populate its Explicit TA 250 database and use it for subsequent authentications. 252 The EST client certificate SHOULD conform to [RFC7925]. The EST 253 client and/or EST server certificate MAY be a (natively signed) CBOR 254 certificate [I-D.mattsson-cose-cbor-cert-compress]. 256 3.3. Channel Binding 258 The [RFC5272] specification describes proof-of-possession as the 259 ability of a client to prove its possession of a private key which is 260 linked to a certified public key. In case of signature key, a proof- 261 of-possession is generated by the client when it signs the PKCS#10 262 Request during the enrollment phase. Connection-based proof-of- 263 possession is OPTIONAL for EST-oscore clients and servers. 265 When desired the client can use the EDHOC-Exporter API to extract 266 channel-binding information and provide a connection-based proof-of 267 possession. Channel-binding information is obtained as follows 269 edhoc-unique = EDHOC-Exporter("EDHOC Unique", length), 271 where length equals the desired length of the edhoc-unique byte 272 string. The client then adds the edhoc-unique byte string as a 273 challengePassword (see Section 5.4.1 of [RFC2985]) in the attributes 274 section of the PKCS#10 Request to prove to the server that the 275 authenticated EDHOC client is in possession of the private key 276 associated with the certification request, and signed the 277 certification request after the EDHOC session was established. 279 3.4. Optimizations 281 o The last message of the EDHOC protocol, message_3, MAY be combined 282 with an OSCORE request, enabling authenticated Diffie-Hellman key 283 exchange and a protected CoAP request/response (which may contain 284 an enrolment request and response) in two round trips 285 [I-D.palombini-core-oscore-edhoc]. 287 o The certificates MAY be compressed, e.g. using the CBOR encoding 288 defined in [I-D.mattsson-cose-cbor-cert-compress]. 290 o The certificate MAY be referenced instead of transported 291 [I-D.ietf-cose-x509]. The EST-oscore server MAY use information 292 in the credential identifier field of the EDHOC message 293 (ID_CRED_x) to access the EST-oscore client certificate, e.g., in 294 a directory or database provided by the issuer. In this case the 295 certificate may not need to be transported over a constrained link 296 between EST client and server. 298 o Conversely, the response to the PKCS#10 request MAY be a reference 299 to the enrolled certificate rather than the certificate itself. 300 The EST-oscore server MAY in the enrolment response to the EST- 301 oscore client include a pointer to a directory or database where 302 the certificate can be retrieved. 304 3.5. RPK-based Trust Anchors 306 A trust anchor is commonly a self-signed certificate of the CA public 307 key. In order to reduce transport overhead, the trust anchor could 308 be just the CA public key and associated data (see Section 2), e.g., 309 the SubjectPublicKeyInfo, or a public key certificate without the 310 signature. In either case they can be compactly encoded, e.g. using 311 CBOR encoding [I-D.mattsson-cose-cbor-cert-compress]. A client MAY 312 request an unsigned trust anchors using the /rpks function (see 313 Section 4.2). 315 Client authentication can be performed with long-lived RPKs installed 316 by the manufacturer. Re-enrollment requests can be authenticated 317 through a valid certificate issued previously by the EST-oscore 318 server or by using the key material available in the Implicit TA 319 database. 321 TODO: Sanity check this. Review the use of Implicit TA vs. Explicit 322 TA. 324 4. Protocol Design and Layering 326 EST-oscore uses CoAP [RFC7252] and Block-Wise [RFC7959] to transfer 327 EST messages in the same way as [I-D.ietf-ace-coap-est]. Instead of 328 DTLS record layer, OSCORE [RFC8613] is used to protect the EST 329 payloads. Figure 1 below shows the layered EST-oscore architecture. 331 +------------------------------------------------+ 332 | EST request/response messages | 333 +------------------------------------------------+ 334 | CoAP with OSCORE | HTTP with OSCORE | 335 +------------------------------------------------+ 336 | UDP | DTLS/UDP | TCP | TLS/TCP | 337 +------------------------------------------------+ 339 Figure 1: EST protected with OSCORE. 341 EST-oscore follows much of the EST-coaps and EST design. 343 4.1. Discovery and URI 345 The discovery of EST resources and the definition of the short EST- 346 coaps URI paths specified in Section 5.1 of [I-D.ietf-ace-coap-est], 347 as well as the new Resource Type defined in Section 9.1 of 348 [I-D.ietf-ace-coap-est] apply to EST-oscore. Support for OSCORE is 349 indicated by the "osc" attribute defined in Section 9 of [RFC8613], 350 for example: 352 REQ: GET /.well-known/core?rt=ace.est.sen 354 RES: 2.05 Content 355 ; rt="ace.est";osc 357 4.2. Distribution of RPKs 359 The EST client can request a copy of the current CA public keys. 361 TODO: Map relevant parts of section 4.1 of RFC 7030 and other EST 362 function related content from RFC7030 and EST-coaps. 364 RATIONALE: EST-coaps provides the /crts operation. A successful 365 request from the client to this resource will be answered with a bag 366 of certificates which is subsequently installed in the Explicit TA. 367 Motivated by the specification of more compact trust anchors (see 368 Section 2) we define here the new EST function /rpks which returns a 369 set of RPKs to be installed in the Explicit TA database. 371 4.3. Mandatory/optional EST Functions 373 The EST-oscore specification has the same set of required-to- 374 implement functions as EST-coaps. The content of Table 1 is adapted 375 from Section 5.2 in [I-D.ietf-ace-coap-est] and uses the updated URI 376 paths (see Section 4.1). 378 +---------------+---------------------------+ 379 | EST functions | EST-oscore implementation | 380 +---------------+---------------------------+ 381 | /crts | MUST | 382 | | | 383 | /sen | MUST | 384 | | | 385 | /sren | MUST | 386 | | | 387 | /skg | OPTIONAL | 388 | | | 389 | /skc | OPTIONAL | 390 | | | 391 | /att | OPTIONAL | 392 +---------------+---------------------------+ 394 Table 1: Mandatory and optional EST-oscore functions 396 TODO: Add /rpks OPTIONAL 398 4.4. Payload formats 400 Similar to EST-coaps, EST-oscore allows transport of the ASN.1 401 structure of a given Media-Type in binary format. In addition, EST- 402 oscore uses the same CoAP Content-Format Options to transport EST 403 requests and responses . Table 2 summarizes the information from 404 Section 5.3 in [I-D.ietf-ace-coap-est]. 406 +-------+---------------------------------------------------+-------+ 407 | URI | Content-Format | #IANA | 408 +-------+---------------------------------------------------+-------+ 409 | /crts | N/A | - | 410 | | (req) | | 411 | | | | 412 | | application/pkix-cert | 287 | 413 | | (res) | | 414 | | | | 415 | | application/pkcs-7-mime;smime-type=certs-only | 281 | 416 | | (res) | | 417 | | | | 418 | /sen | application/pkcs10 | 286 | 419 | | (req) | | 420 | | | | 421 | | application/pkix-cert | 287 | 422 | | (res) | | 423 | | | | 424 | | application/pkcs-7-mime;smime-type=certs-only | 281 | 425 | | (res) | | 426 | | | | 427 | /sren | application/pkcs10 | 286 | 428 | | (req) | | 429 | | | | 430 | | application/pkix-cert | 287 | 431 | | (res) | | 432 | | | | 433 | | application/pkcs-7-mime;smime-type=certs-only | 281 | 434 | | (res) | | 435 | | | | 436 | /skg | application/pkcs10 | 286 | 437 | | (req) | | 438 | | | | 439 | | application/multipart-core | 62 | 440 | | (res) | | 441 | | | | 442 | /skc | application/pkcs10 | 286 | 443 | | (req) | | 444 | | | | 445 | | application/multipart-core | 62 | 446 | | (res) | | 447 | | | | 448 | /att | N/A | - | 449 | | (req) | | 450 | | | | 451 | | application/csrattrs | 285 | 452 | | (res) | | 453 +-------+---------------------------------------------------+-------+ 455 Table 2: EST functions and there associated Media-Type and IANA 456 numbers 458 NOTE: CBOR is becoming a de facto encoding scheme in IoT settings. 459 There is already work in progress on CBOR encoding of X.509 460 certificates [I-D.mattsson-cose-cbor-cert-compress], and this can be 461 extended to other EST messages, see Appendix B. 463 4.5. Message Bindings 465 The EST-oscore message characteristics are identical to those 466 specified in Section 5.4 of [I-D.ietf-ace-coap-est]. It is 467 RECOMMENDED that 469 o The EST-oscore endpoints support delayed responses 471 o The endpoints supports the following CoAP options: OSCORE, Uri- 472 Host, Uri-Path, Uri-Port, Content-Format, Block1, Block2, and 473 Accept. 475 o The EST URLs based on https:// are translated to coap://, but with 476 mandatory use of the CoAP OSCORE option. 478 4.6. CoAP response codes 480 See Section 5.5 in [I-D.ietf-ace-coap-est]. 482 4.7. Message fragmentation 484 The EDHOC key exchange is optimized for message overhead, in 485 particular the use of static DH keys instead of signature keys for 486 authentication (e.g., method 3 of [I-D.ietf-lake-edhoc]). Together 487 with various measures listed in this document such as CBOR payloads 488 (Appendix B), CBOR certificates 489 [I-D.mattsson-cose-cbor-cert-compress], certificates by reference 490 (Section 3.4), and trust anchors without signature (Section 3.5), a 491 significant reduction of message sizes can be achieved. 493 Nevertheless, depending on application, the protocol messages may 494 become larger than available frame size resulting in fragmentation 495 and, in resource constrained networks such as IEEE 802.15.4 where 496 throughput is limited, fragment loss can trigger costly 497 retransmissions. 499 It is RECOMMENDED to prevent IP fragmentation, since it involves an 500 error-prone datagram reconstitution. To limit the size of the CoAP 501 payload, this specification mandates the implementation of CoAP 502 option Block1 and Block2 fragmentation mechanism [RFC7959] as 503 described in Section 5.6 of [I-D.ietf-ace-coap-est]. 505 4.8. Delayed Responses 507 See Section 5.7 in [I-D.ietf-ace-coap-est]. 509 5. HTTP-CoAP Proxy 511 As noted in Section 6 of [I-D.ietf-ace-coap-est], in real-world 512 deployments, the EST server will not always reside within the CoAP 513 boundary. The EST-server can exist outside the constrained network 514 in a non-constrained network that supports HTTP but not CoAP, thus 515 requiring an intermediary CoAP-to-HTTP proxy. 517 Since OSCORE is applicable to CoAP-mappable HTTP (see Section 11 of 518 [RFC8613]) the EST payloads can be protected end-to-end between EST 519 client and EST server independent of transport protocol or potential 520 transport layer security which may need to be terminated in the 521 proxy, see Figure 2. Therefore the concept "Registrar" and its 522 required trust relation with EST server as described in Section 6 of 523 [I-D.ietf-ace-coap-est] is redundant. 525 The mappings between CoAP and HTTP referred to in Section 9.1 of 526 [I-D.ietf-ace-coap-est] apply, and additional mappings resulting from 527 the use of OSCORE are specified in Section 11 of [RFC8613]. 529 OSCORE provides end-to-end security between EST Server and EST 530 Client. The use of TLS and DTLS is optional. 532 Constrained-Node Network 533 .---------. .----------------------------. 534 | CA | |.--------------------------.| 535 '---------' || || 536 | || || 537 .------. HTTP .-----------------. CoAP .-----------. || 538 | EST |<------->| CoAP-to-HTTP |<-------->| EST Client| || 539 |Server| (TLS) | Proxy | (DTLS) '-----------' || 540 '------' '-----------------' || 541 || || 542 <------------------------------------------------> || 543 OSCORE || || 544 |'--------------------------'| 545 '----------------------------' 547 Figure 2: CoAP-to-HTTP proxy at the CoAP boundary. 549 6. Security Considerations 551 TBD 553 7. Privacy Considerations 555 TBD 557 8. IANA Considerations 559 9. Acknowledgments 561 10. References 563 10.1. Normative References 565 [I-D.ietf-ace-coap-est] 566 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 567 Raza, "EST over secure CoAP (EST-coaps)", draft-ietf-ace- 568 coap-est-18 (work in progress), January 2020. 570 [I-D.ietf-lake-edhoc] 571 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 572 Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- 573 edhoc-06 (work in progress), April 2021. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, 577 DOI 10.17487/RFC2119, March 1997, 578 . 580 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 581 Application Protocol (CoAP)", RFC 7252, 582 DOI 10.17487/RFC7252, June 2014, 583 . 585 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 586 Security (TLS) / Datagram Transport Layer Security (DTLS) 587 Profiles for the Internet of Things", RFC 7925, 588 DOI 10.17487/RFC7925, July 2016, 589 . 591 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 592 the Constrained Application Protocol (CoAP)", RFC 7959, 593 DOI 10.17487/RFC7959, August 2016, 594 . 596 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 597 RFC 8152, DOI 10.17487/RFC8152, July 2017, 598 . 600 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 601 "Object Security for Constrained RESTful Environments 602 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 603 . 605 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 606 Representation (CBOR)", STD 94, RFC 8949, 607 DOI 10.17487/RFC8949, December 2020, 608 . 610 10.2. Informative References 612 [I-D.ietf-6tisch-minimal-security] 613 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 614 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 615 6tisch-minimal-security-15 (work in progress), December 616 2019. 618 [I-D.ietf-ace-oauth-authz] 619 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 620 H. Tschofenig, "Authentication and Authorization for 621 Constrained Environments (ACE) using the OAuth 2.0 622 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-40 623 (work in progress), April 2021. 625 [I-D.ietf-ace-oscore-profile] 626 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 627 "OSCORE Profile of the Authentication and Authorization 628 for Constrained Environments Framework", draft-ietf-ace- 629 oscore-profile-18 (work in progress), April 2021. 631 [I-D.ietf-core-oscore-groupcomm] 632 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 633 and J. Park, "Group OSCORE - Secure Group Communication 634 for CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 635 progress), February 2021. 637 [I-D.ietf-cose-x509] 638 Schaad, J., "CBOR Object Signing and Encryption (COSE): 639 Header parameters for carrying and referencing X.509 640 certificates", draft-ietf-cose-x509-08 (work in progress), 641 December 2020. 643 [I-D.mattsson-cose-cbor-cert-compress] 644 Raza, S., Hoeglund, J., Selander, G., Mattsson, J. P., and 645 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 646 Certificates)", draft-mattsson-cose-cbor-cert-compress-08 647 (work in progress), February 2021. 649 [I-D.palombini-core-oscore-edhoc] 650 Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., 651 and G. Selander, "Combining EDHOC and OSCORE", draft- 652 palombini-core-oscore-edhoc-02 (work in progress), 653 February 2021. 655 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 656 Classes and Attribute Types Version 2.0", RFC 2985, 657 DOI 10.17487/RFC2985, November 2000, 658 . 660 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 661 Request Syntax Specification Version 1.7", RFC 2986, 662 DOI 10.17487/RFC2986, November 2000, 663 . 665 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 666 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 667 . 669 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 670 Housley, R., and W. Polk, "Internet X.509 Public Key 671 Infrastructure Certificate and Certificate Revocation List 672 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 673 . 675 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 676 Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, 677 . 679 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 680 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 681 2010, . 683 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 684 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 685 January 2012, . 687 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 688 "Enrollment over Secure Transport", RFC 7030, 689 DOI 10.17487/RFC7030, October 2013, 690 . 692 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 693 Constrained-Node Networks", RFC 7228, 694 DOI 10.17487/RFC7228, May 2014, 695 . 697 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 698 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 699 May 2018, . 701 Appendix A. Other Authentication Methods 703 In order to protect certificate enrollment with OSCORE, the necessary 704 keying material (notably, the OSCORE Master Secret, see [RFC8613]) 705 needs to be established between EST-oscore client and EST-oscore 706 server. In this appendix we analyse alternatives to EDHOC, which was 707 assumed in the body of this specification. 709 A.1. TTP Assisted Authentication 711 Trusted third party (TTP) based provisioning, such as the OSCORE 712 profile of ACE [I-D.ietf-ace-oscore-profile] assumes existing 713 security associations between the client and the TTP, and between the 714 server and the TTP. This setup allows for reduced message overhead 715 and round trips compared to the full-fledged EDHOC key exchange. 716 Following the ACE terminology the TTP plays the role of the 717 Authorization Server (AS), the EST-oscore client corresponds to the 718 ACE client and the EST-oscore server is the ACE Resource Server (RS). 720 +------------+ +------------+ 721 | | | | 722 | | ---(A)- Token Request ------> | Trusted | 723 | | | Third | 724 | | <--(B)- Access Token ------- | Party (AS) | 725 | | | | 726 | | +------------+ 727 | EST-oscore | | ^ 728 | Client | (F) (E) 729 |(ACE Client)| V | 730 | | +------------+ 731 | | | | 732 | | -(C)- Token + EST Request --> | EST-oscore | 733 | | | server (RS)| 734 | | <--(D)--- EST response ------ | | 735 | | | | 736 +------------+ +------------+ 738 Figure 3: Accessing EST services using a TTP for authenticated key 739 establishment and authorization. 741 During initial enrollment the EST-oscore client uses its existing 742 security association with the TTP, which replaces the Implicit TA 743 database, to establish an authenticated secure channel. The 744 [I-D.ietf-ace-oscore-profile] ACE profile RECOMMENDS the use of 745 OSCORE between client and TTP (AS), but TLS or DTLS MAY be used 746 additionally or instead. The client requests an access token at the 747 TTP corresponding the EST service it wants to access. If the client 748 request was invalid, or not authorized according to the local EST 749 policy, the AS returns an error response as described in 750 Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. In its responses the 751 TTP (AS) SHOULD signal that the use of OSCORE is REQUIRED for a 752 specific access token as indicated in section 4.3 of 753 [I-D.ietf-ace-oscore-profile]. This means that the EST-oscore client 754 MUST use OSCORE towards all EST-oscore servers (RS) for which this 755 access token is valid, and follow Section 4.3 in 756 [I-D.ietf-ace-oscore-profile] to derive the security context to run 757 OSCORE. The ACE OSCORE profile RECOMMENDS the use of CBOR web token 758 (CWT) as specified in [RFC8392]. The TTP (AS) MUST also provision an 759 OSCORE security context to the EST-oscore client and EST-oscore 760 server (RS), which is then used to secure the subsequent messages 761 between the client and the server. The details on how to transfer 762 the OSCORE contexts are described in section 3.2 of 763 [I-D.ietf-ace-oscore-profile]. 765 Once the client has retrieved the access token it follows the steps 766 in [I-D.ietf-ace-oscore-profile] to install the OSCORE security 767 context and presents the token to the EST-oscore server. The EST- 768 oscore server installs the corresponding OSCORE context and can 769 either verify the validity of the token locally or request a token 770 introspection at the TTP. In either case EST policy decisions, e.g., 771 which client can request enrollment or reenrollment, can be 772 implemented at the TTP. Finally the EST-oscore client receives a 773 response from the EST-oscore server. 775 A.2. PSK Based Authentication 777 Another method to bootstrap EST services requires a pre-shared OSCORE 778 security context between the EST-oscore client and EST-oscore server. 779 Authentication using the Implicit TA is no longer required since the 780 shared security context authenticates both parties. The EST-oscore 781 client and EST-oscore server need access to the same OSCORE Master 782 Secret as well as the OSCORE identifiers (Sender ID and Recipient ID) 783 from which an OSCORE security context can be derived, see [RFC8613]. 784 Some optional parameters may be provisioned if different from the 785 default value: 787 o an ID context distinguishing between different OSCORE security 788 contexts to use, 790 o an AEAD algorithm, 792 o an HKDF algorithm, 794 o a master salt, and 796 o a replay window size. 798 Appendix B. CBOR Encoding of EST Payloads 800 Current EST based specifications transport messages using the ASN.1 801 data type declaration. It would be favorable to use a more compact 802 representation better suitable for constrained device 803 implementations. In this appendix we list CBOR encodings of requests 804 and responses of the mandatory EST functions (see Section 4.3). 806 B.1. Distribution of CA Certificates (/crts) 808 The EST client can request a copy of the current CA certificates. In 809 EST-coaps and EST-oscore this is done using a GET request to /crts 810 (with empty payload). The response contains a chain of certificates 811 used to establish an Explicit Trust Anchor database for subsequent 812 authentication of the EST server. 814 CBOR encoding of X.509 certificates is specified in 815 [I-D.mattsson-cose-cbor-cert-compress]. CBOR encoding of certificate 816 chains is specified below. This allows for certificates encoded 817 using the CBOR certificate format, or as binary X.509 data wrapped as 818 a CBOR byte string. 820 CDDL: 822 certificate chain = ( 823 + certificate : bstr 824 ) 825 certificate = x509_certificate / cbor_certificate 827 B.2. Enrollment/Re-enrollment of Clients (/sen, /sren) 829 Existing EST standards specify the enrollment request to be a PKCS#10 830 formated message [RFC2986]. The essential information fields for the 831 CA to verify are the following: 833 o Information about the subject, here condensed to the subject 834 common name, 836 o subject public key, and 838 o signature made by the subject private key. 840 CDDL: 842 certificate request = ( 843 subject_common_name : bstr, 844 public_key : bstr 845 signature : bstr, 846 ? ( signature_alg : int, public_key_info : int ) 847 ) 848 The response to the enrollment request is the subject certificate, 849 for which CBOR encoding is specified in 850 [I-D.mattsson-cose-cbor-cert-compress]. 852 The same message content in request and response applies to re- 853 enrollment. 855 TODO: PKCS#10 allows inclusion of attributes, which can be used to 856 specify extension requests, see Section 5.4.2 of [RFC2985]. CBOR 857 encoding of the challengePassword attribute needs to be defined (see 858 Section 3.3). What other attributes are relevant? 860 B.2.1. CBOR Certificate Request Examples 862 Here is an example of CBOR encoding of certificate request as defined 863 in the previous section. 865 114 bytes: 867 ( h'0123456789ABCDF0', 868 h'61eb80d2abf7d7e4139c86b87e42466f1b4220d3f7ff9d6a1ae298fb9adbb464', 869 h'30440220064348b9e52ee0da9f9884d8dd41248c49804ab923330e208a168172dca 870 e1 27a02206a06c05957f1db8c4e207437b9ab7739cb857aa6dd9486627b8961606a2 871 b68ae' ) 873 In the example above the signature is generated on an ASN.1 data 874 structure. To validate this, the receiver needs to reconstruct the 875 original data structure. Alternatively, in native mode, the 876 signature is generated on the profiled data structure, in which case 877 the overall overhead is further reduced. 879 B.2.2. ASN.1 Certificate Request Examples 881 A corresponding certificate request of the previous section using 882 ASN.1 is shown in Figure 4. 884 SEQUENCE { 885 SEQUENCE { 886 INTEGER 0 887 SEQUENCE { 888 SET { 889 SEQUENCE { 890 OBJECT IDENTIFIER commonName (2 5 4 3) 891 UTF8String '01-23-45-67-89-AB-CD-F0' 892 } 893 } 894 } 895 SEQUENCE { 896 SEQUENCE { 897 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 898 OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) 899 } 900 BIT STRING 901 (65 byte public key) 902 } 903 SEQUENCE { 904 OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 905 } 906 BIT STRING 907 (64 byte signature) 909 Figure 4: ASN.1 Structure. 911 In Base64, 375 bytes: 913 -----BEGIN CERTIFICATE REQUEST----- 914 MIHcMIGEAgEAMCIxIDAeBgNVBAMMFzAxLTIzLTQ1LTY3LTg5LUFCLUNELUYwMFkw 915 EwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYeuA0qv31+QTnIa4fkJGbxtCINP3/51q 916 GuKY+5rbtGSeZn3l8rVbU0jVEBWvKhAd98JeqgsuauGHRNWt2FqJ1aAAMAoGCCqG 917 SM49BAMCA0cAMEQCIAZDSLnlLuDan5iE2N1BJIxJgEq5IzMOIIoWgXLcrhJ6AiBq 918 BsBZV/HbjE4gdDe5q3c5y4V6pt2UhmJ7iWFgaitorg== 919 -----END CERTIFICATE REQUEST----- 921 In hex, 221 bytes: 923 3081dc30818402010030223120301e06035504030c1730312d32332d34352d36 924 372d38392d41422d43442d46303059301306072a8648ce3d020106082a8648ce 925 3d0301070342000461eb80d2abf7d7e4139c86b87e42466f1b4220d3f7ff9d6a 926 1ae298fb9adbb4649e667de5f2b55b5348d51015af2a101df7c25eaa0b2e6ae1 927 8744d5add85a89d5a000300a06082a8648ce3d04030203470030440220064348 928 b9e52ee0da9f9884d8dd41248c49804ab923330e208a168172dcae127a02206a 929 06c05957f1db8c4e207437b9ab7739cb857aa6dd9486627b8961606a2b68ae 931 Authors' Addresses 933 Goeran Selander 934 Ericsson AB 936 Email: goran.selander@ericsson.com 938 Shahid Raza 939 RISE 941 Email: shahid.raza@ri.se 943 Martin Furuhed 944 Nexus 946 Email: martin.furuhed@nexusgroup.com 948 Malisa Vucinic 949 INRIA 951 Email: malisa.vucinic@inria.fr 953 Timothy Claeys 955 Email: timothy.claeys@gmail.com