idnits 2.17.1 draft-selander-ace-coap-est-oscore-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2020) is 1508 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) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-09 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-06 == Outdated reference: A later version (-04) exists of draft-raza-ace-cbor-certificates-03 == Outdated reference: A later version (-01) exists of draft-selander-lake-edhoc-00 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 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: September 10, 2020 RISE 6 M. Furuhed 7 Nexus 8 M. Vucinic 9 T. Claeys 10 INRIA 11 March 09, 2020 13 Protecting EST Payloads with OSCORE 14 draft-selander-ace-coap-est-oscore-03 16 Abstract 18 This document specifies public-key certificate enrollment procedures 19 protected with application-layer security protocols suitable for 20 Internet of Things (IoT) deployments. The protocols leverage payload 21 formats defined in Enrollment over Secure Transport (EST) and 22 existing IoT standards including the Constrained Application Protocol 23 (CoAP), Concise Binary Object Representation (CBOR) and the CBOR 24 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 September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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. EST-coaps operational differences . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. OSCORE and Authenticated Key Establishment . . . . . . . . . 4 64 3.1. EDHOC . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Protocol Design and Layering . . . . . . . . . . . . . . . . 6 66 4.1. Discovery and URI . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Mandatory/optional EST Functions . . . . . . . . . . . . 6 68 4.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 8 70 4.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 9 71 4.6. Message fragmentation . . . . . . . . . . . . . . . . . . 9 72 4.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 9 73 5. HTTP-CoAP registrar . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Appendix A. Other Authentication Methods . . . . . . . . . . . . 13 82 A.1. TTP Assisted Authentication . . . . . . . . . . . . . . . 13 83 A.2. PSK Based Authentication . . . . . . . . . . . . . . . . 14 84 A.3. EDHOC with alternative authentication methods . . . . . . 15 85 Appendix B. CBOR Encoding of EST Payloads . . . . . . . . . . . 15 86 B.1. Distribution of CA Certificates (/crts) . . . . . . . . . 15 87 B.2. Enrollment/Re-enrollment of Clients (/sen, /sren) . . . . 16 88 B.2.1. CBOR Certificate Request Examples . . . . . . . . . . 16 89 B.2.2. ASN.1 Certificate Request Examples . . . . . . . . . 17 90 Appendix C. Other Explicit TA Material . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 One of the challenges with deploying a Public Key Infrastructure 96 (PKI) for the Internet of Things (IoT) is certificate enrollment, 97 because existing enrollment protocols are not optimized for 98 constrained environments [RFC7228]. 100 One optimization of certificate enrollment targeting IoT deployments 101 is specified in EST-coaps ([I-D.ietf-ace-coap-est]), which defines a 102 version of Enrollment over Secure Transport [RFC7030] for 103 transporting EST payloads over CoAP [RFC7252] and DTLS [RFC6347], 104 instead of secured HTTP. 106 This document describes a method for protecting EST payloads over 107 CoAP or HTTP with OSCORE [RFC8613]. OSCORE specifies an extension to 108 CoAP which protects the application layer message and can be applied 109 independently of how CoAP messages are transported. OSCORE can also 110 be applied to CoAP-mappable HTTP which enables end-to-end security 111 for mixed CoAP and HTTP transfer of application layer data. Hence 112 EST payloads can be protected end-to-end independent of underlying 113 transport and through proxies translating between between CoAP and 114 HTTP. 116 OSCORE is designed for constrained environments, building on IoT 117 standards such as CoAP, CBOR [RFC7049] and COSE [RFC8152], and has in 118 particular gained traction in settings where message sizes and the 119 number of exchanged messages needs to be kept at a minimum, see e.g. 120 [I-D.ietf-6tisch-minimal-security], or for securing multicast CoAP 121 messages [I-D.ietf-core-oscore-groupcomm]. Where OSCORE is 122 implemented and used for communication security, the reuse of OSCORE 123 for other purposes, such as enrollment, reduces the implementation 124 footprint. 126 Another way to optimize the performance of certificate enrollment and 127 certificate based authentication is the use of more compact 128 representations of EST payloads (see Appendix B) and of X.509 129 certificates (see [I-D.raza-ace-cbor-certificates]. 131 1.1. EST-coaps operational differences 133 This specification builds on EST-coaps [I-D.ietf-ace-coap-est] but 134 transport layer security provided by DTLS is replaced, or 135 complemented, by protection of the application layer data. This 136 specification deviates from EST-coaps in the following respects: 138 o The DTLS record layer is replaced, or complemented, with OSCORE. 140 o The DTLS handshake is replaced, or complemented, with the EDHOC 141 key exchange protocol [I-D.selander-lake-edhoc] completing the 142 analogy with EST-coaps. EDHOC can also leverage its support for 143 static Diffie-Hellman keys. The latter enables that certificates 144 containing static DH public keys can be used for authentication of 145 a Diffie-Hellman key exchange. 147 * The use of a Diffie-Hellman key exchange authenticated with 148 certificates adds significant overhead in terms of message size 149 and round trips which is not necessary for the enrollment 150 procedure. The main reason for specifying this is to align 151 with EST-coaps, and reuse a security protocol rather than 152 defining a special security protocol for enrollment. 153 Appendix A discusses alternative authentication and secure 154 communication methods. 156 o The EST payloads protected by OSCORE can be proxied between 157 constrained networks supporting CoAP/CoAPs and non-constrained 158 networks supporting HTTP/HTTPs with a CoAP-HTTP proxy protection 159 without any security processing in the proxy. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. These 166 words may also appear in this document in lowercase, absent their 167 normative meanings. 169 This document uses terminology from [I-D.ietf-ace-coap-est] which in 170 turn is based on [RFC7030] and, in turn, on [RFC5272]. 172 3. OSCORE and Authenticated Key Establishment 174 EST-oscore clients and servers MUST perform mutual authentication 175 before EST-oscore functions and services can be accessed. Prior to 176 the initial enrollment the client MUST be configured with an Implicit 177 Trust Anchor (TA) [RFC7030] database, enabling the client to 178 authenticate the server. During the initial enrollment the client 179 SHOULD populate its Explicit TA database and use it for subsequent 180 authentications. 182 The EST-coaps specification [I-D.ietf-ace-coap-est] only supports 183 certificate-based authentication during the DTLS handshake between 184 the EST-coaps server and the client. This specification replaces the 185 DTLS handshake with the certificate-based EDHOC key exchange protocol 186 and provides additional authenticated methods in the Appendix A 187 The [RFC5272] specification describes proof-of-identity as the 188 ability of an endpoint, i.e., client, to prove its possession of a 189 private key which is linked to a certified public key. Additionally, 190 [RFC5272] details how to use channel-binding information (extracted 191 from the underlying TLS layer) to link the proof-of-identity to a 192 proof-of-possession. A proof-of-possession is generated by the 193 client when it signs the PKCS#10 Request during the enrollment phase. 194 Connection-based proof-of-possession is OPTIONAL for EST-oscore 195 clients and servers. In case of certificate-based EDHOC key 196 establishment, a set of actions are required which are further 197 described below. 199 3.1. EDHOC 201 The EST-oscore client and server use the EDHOC key establishment 202 protocol to populate the OSCORE security context. The endpoints MUST 203 use public key certificates to perform mutual authentication. During 204 the initial enrollment the Implicit TA database MUST contain 205 certificates capable of authenticating the EST-oscore server. When 206 the EST-oscore client issues a request to the /crts endpoint of the 207 EST server, it SHALL return a bag of certificates to be installed in 208 the Explicit TA database. 210 The cryptographic material used for EST-oscore client authentication 211 can either be 213 o previously issued certificates (e.g., an existing certificate 214 issued by the EST server); this could be a common case for simple 215 re-enrollment of clients. 217 o previously installed certificates (e.g., installed by the 218 manufacturer). Manufacturer installed certificates are expected 219 to have a very long life, as long as the device, but under some 220 conditions could expire. In that case, the server MAY 221 authenticate a client certificate against its trust store although 222 the certificate is expired (Section 6). 224 When desired the client can use the EDHOC-Exporter API to extract 225 channel-binding information and provide a connection-based proof-of 226 possession. Channel-binding information is obtained as follows 228 edhoc-unique = EDHOC-Exporter("EDHOC Unique", length), 230 where length equals the desired length of the edhoc-unique byte 231 string. The client then adds the edhoc-unique byte string as a 232 ChallengePassword in the attributes section of the PKCS#10 Request to 233 prove that the client is indeed in control of the private key at the 234 time of the EDHOC key exchange. 236 4. Protocol Design and Layering 238 EST-oscore uses CoAP [RFC7252] and Block-Wise [RFC7959] to transfer 239 EST messages in the same way as [I-D.ietf-ace-coap-est]. Figure 1 240 below shows the layered EST-oscore architecture. 242 +------------------------------------------------+ 243 | EST request/response messages | 244 +------------------------------------------------+ 245 | CoAP with OSCORE | HTTP with OSCORE | 246 +------------------------------------------------+ 247 | UDP | DTLS/UDP | TCP | TLS/TCP | 248 +------------------------------------------------+ 250 Figure 1: EST protected with OSCORE. 252 EST-oscore follows closely the EST-coaps and EST design. 254 4.1. Discovery and URI 256 The discovery of EST resources and the definition of the short EST- 257 coaps URI paths specified in Section 5.1 of [I-D.ietf-ace-coap-est], 258 as well as the new Resource Type defined in Section 9.1 of 259 [I-D.ietf-ace-coap-est] apply to EST-oscore. Support for OSCORE is 260 indicated by the "osc" attribute defined in Section 9 of [RFC8613], 261 for example: 263 REQ: GET /.well-known/core?rt=ace.est.sen 265 RES: 2.05 Content 266 ; rt="ace.est";osc 268 4.2. Mandatory/optional EST Functions 270 The EST-oscore specification has the same set of required-to- 271 implement functions as EST-coaps. The content of Table 1 is adapted 272 from Section 5.2 in [I-D.ietf-ace-coap-est] and uses the updated URI 273 paths (see Section 4.1). 275 +---------------+---------------------------+ 276 | EST functions | EST-oscore implementation | 277 +---------------+---------------------------+ 278 | /crts | MUST | 279 | | | 280 | /sen | MUST | 281 | | | 282 | /sren | MUST | 283 | | | 284 | /skg | OPTIONAL | 285 | | | 286 | /skc | OPTIONAL | 287 | | | 288 | /att | OPTIONAL | 289 +---------------+---------------------------+ 291 Table 1: Mandatory and optional EST-oscore functions 293 4.3. Payload formats 295 Similar to EST-coaps, EST-oscore allows transport of the ASN.1 296 structure of a given Media-Type in binary format. In addition, EST- 297 oscore uses the same CoAP Content-Format Options to transport EST 298 requests and responses . Table 2 summarizes the information from 299 Section 5.3 in [I-D.ietf-ace-coap-est]. 301 +-------+---------------------------------------------------+-------+ 302 | URI | Content-Format | #IANA | 303 +-------+---------------------------------------------------+-------+ 304 | /crts | N/A | - | 305 | | (req) | | 306 | | | | 307 | | application/pkix-cert | 287 | 308 | | (res) | | 309 | | | | 310 | | application/pkcs-7-mime;smime-type=certs-only | 281 | 311 | | (res) | | 312 | | | | 313 | /sen | application/pkcs10 | 286 | 314 | | (req) | | 315 | | | | 316 | | application/pkix-cert | 287 | 317 | | (res) | | 318 | | | | 319 | | application/pkcs-7-mime;smime-type=certs-only | 281 | 320 | | (res) | | 321 | | | | 322 | /sren | application/pkcs10 | 286 | 323 | | (req) | | 324 | | | | 325 | | application/pkix-cert | 287 | 326 | | (res) | | 327 | | | | 328 | | application/pkcs-7-mime;smime-type=certs-only | 281 | 329 | | (res) | | 330 | | | | 331 | /skg | application/pkcs10 | 286 | 332 | | (req) | | 333 | | | | 334 | | application/multipart-core | 62 | 335 | | (res) | | 336 | | | | 337 | /skc | application/pkcs10 | 286 | 338 | | (req) | | 339 | | | | 340 | | application/multipart-core | 62 | 341 | | (res) | | 342 | | | | 343 | /att | N/A | - | 344 | | (req) | | 345 | | | | 346 | | application/csrattrs | 285 | 347 | | (res) | | 348 +-------+---------------------------------------------------+-------+ 350 Table 2: EST functions and there associated Media-Type and IANA 351 numbers 353 NOTE: CBOR is becoming a de facto encoding scheme in IoT settings. 354 There is already work in progress on CBOR encoding of X.509 355 certificates [I-D.raza-ace-cbor-certificates], and this can be 356 extended to other EST messages, see Appendix B. 358 4.4. Message Bindings 360 The EST-oscore message characteristics are identical to those 361 specified in Section 5.4 of [I-D.ietf-ace-coap-est]. It is 362 RECOMMENDED that 364 o The EST-oscore endpoints support delayed responses 366 o The endpoints supports the following CoAP options: OSCORE, Uri- 367 Host, Uri-Path, Uri-Port, Content-Format, Block1, Block2, and 368 Accept. 370 o The EST URLs based on https:// are translated to coap://, but with 371 mandatory use of the CoAP OSCORE option. 373 4.5. CoAP response codes 375 See Section 5.5 in [I-D.ietf-ace-coap-est]. 377 4.6. Message fragmentation 379 The EDHOC key exchange with asymmetric keys and certificates for 380 authentication can result in large messages. It is RECOMMENDED to 381 prevent IP fragmentation, since it involves an error-prone datagram 382 reconstitution. In addition, this specification targets resource 383 constrained networks such as IEEE 802.15.4 where throughput is 384 limited and fragment loss can trigger costly retransmissions. Even 385 though ECC-based certificates are an improvement over the RSA or DSA 386 counterparts, they can still amount to roughly a 1000 bytes per 387 certificate depending on the used algorithms, curves, OIDs, Subject 388 Alternative Names (SAN) and cert fields. Additionally, in response 389 to a client request to /crts an EST-oscore server might answer with 390 multiple certificates. This is another motivation for the need for 391 more compact EST payloads, see Appendix B. This specification 392 further employs the CoAP Block1 and Block2 fragmentation mechanisms 393 as described in Section 5.6 of [I-D.ietf-ace-coap-est] to limit the 394 size of the CoAP payload. 396 4.7. Delayed Responses 398 See Section 5.7 in [I-D.ietf-ace-coap-est]. 400 5. HTTP-CoAP registrar 402 As is noted in Section 6 of [I-D.ietf-ace-coap-est], in real-world 403 deployments, the EST server will not always reside within the CoAP 404 boundary. The EST-server can exist outside the constrained network 405 in a non-constrained network that does not support CoAP but HTTP, 406 thus requiring an intermediary CoAP-to-HTTP proxy. 408 Since OSCORE is applicable to CoAP-mappable HTTP the EST payloads can 409 be protected end-to-end between EST client and EST server independent 410 of transport protocol or potential transport layer security which may 411 need to be terminated in the proxy, see Figure 2. When using the 412 EDHOC key exchange protocol to establish a shared OSCORE security 413 context, PKCS#10 request MAY be bound to the OSCORE security context 414 using the procedure described in Section 3.1. The mappings between 415 CoAP and HTTP referred to in Section 6 of [I-D.ietf-ace-coap-est] 416 apply and the additional mappings resulting from the use of OSCORE 417 are specified in Section 11 of [RFC8613]. 419 OSCORE provides end-to-end security between EST Server and EST 420 Client. The use of TLS and DTLS is optional. 422 Constrained-Node Network 423 .---------. .----------------------------. 424 | CA | |.--------------------------.| 425 '---------' || || 426 | || || 427 .------. HTTP .-----------------. CoAP .-----------. || 428 | EST |<------->| CoAP-to-HTTP |<-------->| EST Client| || 429 |Server| (TLS) | Proxy | (DTLS) '-----------' || 430 '------' '-----------------' || 431 || || 432 <------------------------------------------------> || 433 OSCORE || || 434 |'--------------------------'| 435 '----------------------------' 437 Figure 2: CoAP-to-HTTP proxy at the CoAP boundary. 439 6. Security Considerations 441 TBD 443 7. Privacy Considerations 445 TBD 447 8. IANA Considerations 449 9. Acknowledgments 451 10. References 453 10.1. Normative References 455 [I-D.ietf-ace-coap-est] 456 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 457 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 458 est-18 (work in progress), January 2020. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 466 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 467 October 2013, . 469 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 470 Application Protocol (CoAP)", RFC 7252, 471 DOI 10.17487/RFC7252, June 2014, 472 . 474 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 475 the Constrained Application Protocol (CoAP)", RFC 7959, 476 DOI 10.17487/RFC7959, August 2016, 477 . 479 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 480 RFC 8152, DOI 10.17487/RFC8152, July 2017, 481 . 483 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 484 "Object Security for Constrained RESTful Environments 485 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 486 . 488 10.2. Informative References 490 [I-D.ietf-6tisch-minimal-security] 491 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 492 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 493 6tisch-minimal-security-15 (work in progress), December 494 2019. 496 [I-D.ietf-ace-oauth-authz] 497 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 498 H. Tschofenig, "Authentication and Authorization for 499 Constrained Environments (ACE) using the OAuth 2.0 500 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 501 (work in progress), February 2020. 503 [I-D.ietf-ace-oscore-profile] 504 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 505 "OSCORE profile of the Authentication and Authorization 506 for Constrained Environments Framework", draft-ietf-ace- 507 oscore-profile-09 (work in progress), March 2020. 509 [I-D.ietf-core-oscore-groupcomm] 510 Tiloca, M., Selander, G., Palombini, F., and J. Park, 511 "Group OSCORE - Secure Group Communication for CoAP", 512 draft-ietf-core-oscore-groupcomm-06 (work in progress), 513 November 2019. 515 [I-D.raza-ace-cbor-certificates] 516 Raza, S., Hoglund, J., Selander, G., Mattsson, J., and M. 517 Furuhed, "CBOR Profile of X.509 Certificates", draft-raza- 518 ace-cbor-certificates-03 (work in progress), December 519 2019. 521 [I-D.selander-lake-edhoc] 522 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 523 Diffie-Hellman Over COSE (EDHOC)", draft-selander-lake- 524 edhoc-00 (work in progress), November 2019. 526 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 527 Classes and Attribute Types Version 2.0", RFC 2985, 528 DOI 10.17487/RFC2985, November 2000, 529 . 531 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 532 Request Syntax Specification Version 1.7", RFC 2986, 533 DOI 10.17487/RFC2986, November 2000, 534 . 536 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 537 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 538 . 540 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 541 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 542 January 2012, . 544 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 545 "Enrollment over Secure Transport", RFC 7030, 546 DOI 10.17487/RFC7030, October 2013, 547 . 549 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 550 Constrained-Node Networks", RFC 7228, 551 DOI 10.17487/RFC7228, May 2014, 552 . 554 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 555 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 556 May 2018, . 558 Appendix A. Other Authentication Methods 560 In order to protect certificate enrollment with OSCORE, the necessary 561 keying material (notably, the OSCORE Master Secret, see [RFC8613]) 562 needs to be established between EST-oscore client and EST-oscore 563 server. In this appendix we analyse alternatives to EDHOC 564 authenticated with certificates, which was assumed in the body of 565 this specification. 567 A.1. TTP Assisted Authentication 569 Trusted third party (TTP) based provisioning, such as the OSCORE 570 profile of ACE [I-D.ietf-ace-oscore-profile] assumes existing 571 security associations between the client and the TTP, and between the 572 server and the TTP. This setup allows for reduced message overhead 573 and round trips compared to the full-fledged EDHOC key exchange. 574 Following the ACE terminology the TTP plays the role of the 575 Authorization Server (AS), the EST-oscore client corresponds to the 576 ACE client and the EST-oscore server is the ACE Resource Server (RS). 578 +------------+ +------------+ 579 | | | | 580 | | ---(A)- Token Request ------> | Trusted | 581 | | | Third | 582 | | <--(B)- Access Token ------- | Party (AS) | 583 | | | | 584 | | +------------+ 585 | EST-oscore | | ^ 586 | Client | (F) (E) 587 |(ACE Client)| V | 588 | | +------------+ 589 | | | | 590 | | -(C)- Token + EST Request --> | EST-oscore | 591 | | | server (RS)| 592 | | <--(D)--- EST response ------ | | 593 | | | | 594 +------------+ +------------+ 596 Figure 3: Accessing EST services using a TTP for authenticated key 597 establishment and authorization. 599 During initial enrollment the EST-oscore client uses its existing 600 security association with the TTP, which replaces the Implicit TA 601 database, to establish an authenticated secure channel. The 602 [I-D.ietf-ace-oscore-profile] ACE profile RECOMMENDS the use of 603 OSCORE between client and TTP (AS), but TLS or DTLS MAY be used 604 additionally or instead. The client requests an access token at the 605 TTP corresponding the EST service it wants to access. If the client 606 request was invalid, or not authorized according to the local EST 607 policy, the AS returns an error response as described in 608 Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. In its responses the 609 TTP (AS) SHOULD signal that the use of OSCORE is REQUIRED for a 610 specific access token as indicated in section 4.3 of 611 [I-D.ietf-ace-oscore-profile]. This means that the EST-oscore client 612 MUST use OSCORE towards all EST-oscore servers (RS) for which this 613 access token is valid, and follow Section 4.3 in 614 [I-D.ietf-ace-oscore-profile] to derive the security context to run 615 OSCORE. The ACE OSCORE profile RECOMMENDS the use of CBOR web token 616 (CWT) as specified in [RFC8392]. The TTP (AS) MUST also provision an 617 OSCORE security context to the EST-oscore client and EST-oscore 618 server (RS), which is then used to secure the subsequent messages 619 between the client and the server. The details on how to transfer 620 the OSCORE contexts are described in section 3.2 of 621 [I-D.ietf-ace-oscore-profile]. 623 Once the client has retrieved the access token it follows the steps 624 in [I-D.ietf-ace-oscore-profile] to install the OSCORE security 625 context and presents the token to the EST-oscore server. The EST- 626 oscore server installs the corresponding OSCORE context and can 627 either verify the validity of the token locally or request a token 628 introspection at the TTP. In either case EST policy decisions, e.g., 629 which client can request enrollment or reenrollment, can be 630 implemented at the TTP. Finally the EST-oscore client receives a 631 response from the EST-oscore server. 633 A.2. PSK Based Authentication 635 Another method to bootstrap EST services requires a pre-shared OSCORE 636 security context between the EST-oscore client and EST-oscore server. 637 Authentication using the Implicit TA is no longer required since the 638 shared security context authenticates both parties. The EST-oscore 639 client and EST-oscore server need access to the same OSCORE Master 640 Secret as well as the OSCORE identifiers (Sender ID and Recipient ID) 641 from which an OSCORE security context can be derived, see [RFC8613]. 642 Some optional parameters may be provisioned if different from the 643 default value: 645 o an ID context distinguishing between different OSCORE security 646 contexts to use, 648 o an AEAD algorithm, 650 o an HKDF algorithm, 651 o a master salt, and 653 o a replay window size. 655 A.3. EDHOC with alternative authentication methods 657 Section 3.1 describes the use of EDHOC in combination with 658 certificates during the initial bootstrap phase. The latter requires 659 that the Implicit TA is equipped with certificates capable of 660 authenticating the EST-oscore server. Since EDHOC also supports 661 authentication with RPKs and PSKs, the Implicit TA can be populated 662 alternatively with RPKs and PSKs. Similarly to Section 3.1, client 663 authentication can be performed with long-lived RPKs or long-lived 664 PSKs, installed by the manufacturer. Re-enrollment requests can be 665 authenticated through a valid certificate issued previously by the 666 EST-oscore server or by using the key material available in the 667 Implicit TA. 669 Appendix B. CBOR Encoding of EST Payloads 671 Current EST based specifications transport messages using the ASN.1 672 data type declaration. It would be favorable to use a more compact 673 representation better suitable for constrained device 674 implementations. In this appendix we list CBOR encodings of requests 675 and responses of the mandatory EST functions (see Section 4.2). 677 B.1. Distribution of CA Certificates (/crts) 679 The EST client can request a copy of the current CA certificates. In 680 EST-coaps and EST-oscore this is done using a GET request to /crts 681 (with empty payload). The response contains a chain of certificates 682 used to establish an Explicit Trust Anchor database for subsequent 683 authentication of the EST server. 685 CBOR encoding of X.509 certificates is specified in 686 [I-D.raza-ace-cbor-certificates]. CBOR encoding of certificate 687 chains is specified below. This allows for certificates encoded 688 using the CBOR certificate format, or as binary X.509 data wrapped as 689 a CBOR byte string. 691 CDDL: 693 certificate chain = ( 694 + certificate : bstr 695 ) 696 certificate = x509_certificate / cbor_certificate 698 B.2. Enrollment/Re-enrollment of Clients (/sen, /sren) 700 Existing EST standards specify the enrollment request to be a PKCS#10 701 formated message [RFC2986]. The essential information fields for the 702 CA to verify are the following: 704 o Information about the subject, here condensed to the subject 705 common name, 707 o subject public key, and 709 o signature made by the subject private key. 711 CDDL: 713 certificate request = ( 714 subject_common_name : bstr, 715 public_key : bstr 716 signature : bstr, 717 ? ( signature_alg : int, public_key_info : int ) 718 ) 720 The response to the enrollment request is the subject certificate, 721 for which CBOR encoding is specified in 722 [I-D.raza-ace-cbor-certificates]. 724 The same message content in request and response applies to re- 725 enrollment. 727 TBD PKCS#10 allows inclusion of attributes, which can be used to 728 specify extension requests, see Section 5.4.2 in [RFC2985]. Are 729 these attributes important for the scenarios we care about, or can we 730 allow the CA to decide this? 732 B.2.1. CBOR Certificate Request Examples 734 Here is an example of CBOR encoding of certificate request as defined 735 in the previous section. 737 114 bytes: 739 ( h'0123456789ABCDF0', 740 h'61eb80d2abf7d7e4139c86b87e42466f1b4220d3f7ff9d6a1ae298fb9adbb464', 741 h'30440220064348b9e52ee0da9f9884d8dd41248c49804ab923330e208a168172dca 742 e1 27a02206a06c05957f1db8c4e207437b9ab7739cb857aa6dd9486627b8961606a2 743 b68ae' ) 744 In the example above the signature is generated on an ASN.1 data 745 structure. To validate this, the receiver needs to reconstruct the 746 original data structure. Alternatively, in native mode, the 747 signature is generated on the profiled data structure, in which case 748 the overall overhead is further reduced. 750 B.2.2. ASN.1 Certificate Request Examples 752 A corresponding certificate request of the previous section using 753 ASN.1 is shown in Figure 4. 755 SEQUENCE { 756 SEQUENCE { 757 INTEGER 0 758 SEQUENCE { 759 SET { 760 SEQUENCE { 761 OBJECT IDENTIFIER commonName (2 5 4 3) 762 UTF8String '01-23-45-67-89-AB-CD-F0' 763 } 764 } 765 } 766 SEQUENCE { 767 SEQUENCE { 768 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 769 OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) 770 } 771 BIT STRING 772 (65 byte public key) 773 } 774 SEQUENCE { 775 OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 776 } 777 BIT STRING 778 (64 byte signature) 780 Figure 4: ASN.1 Structure. 782 In Base64, 375 bytes: 784 -----BEGIN CERTIFICATE REQUEST----- 785 MIHcMIGEAgEAMCIxIDAeBgNVBAMMFzAxLTIzLTQ1LTY3LTg5LUFCLUNELUYwMFkw 786 EwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEYeuA0qv31+QTnIa4fkJGbxtCINP3/51q 787 GuKY+5rbtGSeZn3l8rVbU0jVEBWvKhAd98JeqgsuauGHRNWt2FqJ1aAAMAoGCCqG 788 SM49BAMCA0cAMEQCIAZDSLnlLuDan5iE2N1BJIxJgEq5IzMOIIoWgXLcrhJ6AiBq 789 BsBZV/HbjE4gdDe5q3c5y4V6pt2UhmJ7iWFgaitorg== 790 -----END CERTIFICATE REQUEST----- 791 In hex, 221 bytes: 793 3081dc30818402010030223120301e06035504030c1730312d32332d34352d36 794 372d38392d41422d43442d46303059301306072a8648ce3d020106082a8648ce 795 3d0301070342000461eb80d2abf7d7e4139c86b87e42466f1b4220d3f7ff9d6a 796 1ae298fb9adbb4649e667de5f2b55b5348d51015af2a101df7c25eaa0b2e6ae1 797 8744d5add85a89d5a000300a06082a8648ce3d04030203470030440220064348 798 b9e52ee0da9f9884d8dd41248c49804ab923330e208a168172dcae127a02206a 799 06c05957f1db8c4e207437b9ab7739cb857aa6dd9486627b8961606a2b68ae 801 Appendix C. Other Explicit TA Material 803 TBD Currently all EST specifications provide the /crts (or /cacerts) 804 endpoint. A successful request from the client to this endpoint will 805 be answered with a bag of certificates which is subsequently 806 installed in the Explicit TA. Should we optionally support new 807 endpoints, e.g., /rpks and/or /psks, which would return a set or RPKs 808 and PSKs to be installed in the Explicit TA? Support for this type 809 of key material in the Explicit TA result in smaller messages sizes. 811 Authors' Addresses 813 Goeran Selander 814 Ericsson AB 816 Email: goran.selander@ericsson.com 818 Shahid Raza 819 RISE 821 Email: shahid.raza@ri.se 823 Martin Furuhed 824 Nexus 826 Email: martin.furuhed@nexusgroup.com 828 Malisa Vucinic 829 INRIA 831 Email: malisa.vucinic@inria.fr 832 Timothy Claeys 833 INRIA 835 Email: timothy.claeys@inria.fr