idnits 2.17.1 draft-selander-ace-coap-est-oscore-02.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 08, 2019) is 1848 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 (-18) exists of draft-ietf-ace-coap-est-09 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 ** 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 (-15) exists of draft-ietf-6tisch-minimal-security-09 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-07 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-03 == Outdated reference: A later version (-04) exists of draft-raza-ace-cbor-certificates-00 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-12 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 8 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 9, 2019 RISE SICS 6 M. Furuhed 7 Nexus 8 M. Vucinic 9 University of Montenegro 10 March 08, 2019 12 Protecting EST payloads with OSCORE 13 draft-selander-ace-coap-est-oscore-02 15 Abstract 17 This document specifies public key certificate enrollment procedures 18 protected with application-layer security protocols suitable for 19 Internet of Things (IoT) deployments. The protocols leverage payload 20 formats defined in Enrolment over Secure Transport (EST) and existing 21 IoT standards including the Constrained Application Protocol (CoAP), 22 Concise Binary Object Representation (CBOR) and the CBOR Object 23 Signing and Encryption (COSE) format. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 9, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. EST-CoAPs operational differences . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Protocol Design and Layering . . . . . . . . . . . . . . . . 4 63 3. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5 64 4. OSCORE-Based Security . . . . . . . . . . . . . . . . . . . . 5 65 5. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 One of the challenges with deploying a Public Key Infrastructure 79 (PKI) for the Internet of Things (IoT) is certificate enrolment, 80 because existing enrolment protocols are not optimized for 81 constrained environments [RFC7228]. 83 One optimization of certificate enrollment targeting IoT deployments 84 is specified in EST-CoAPs ([I-D.ietf-ace-coap-est]), which defines a 85 version of Enrolment over Secure Transport [RFC7030] for transporting 86 EST payloads over CoAP [RFC7252] and DTLS [RFC6347], instead of 87 secured HTTP. 89 This document describes a method for protecting EST payloads over 90 CoAP or HTTP with OSCORE [I-D.ietf-core-object-security]. OSCORE 91 specifies an extension to CoAP which protects the application layer 92 message and can be applied independently of how CoAP messages are 93 transported. OSCORE can also be applied to CoAP-mappable HTTP which 94 enables end-to-end security for mixed CoAP and HTTP transfer of 95 application layer data. Hence EST payloads can be protected end-to- 96 end independent of underlying transport and through proxies 97 translating between between CoAP and HTTP. 99 OSCORE is designed for constrained environments, building on IoT 100 standards such as CoAP, CBOR [RFC7049] and COSE [RFC8152], and has in 101 particular gained traction in settings where message sizes and the 102 number of exchanged messages needs to be kept at a minimum, see e.g. 103 [I-D.ietf-6tisch-minimal-security], or for securing multicast CoAP 104 messages [I-D.ietf-core-oscore-groupcomm]. Where OSCORE is 105 implemented and used for communication security, the reuse of OSCORE 106 for other purposes, such as enrolment, reduces the implementation 107 footprint. 109 In order to protect certificate enrolment with OSCORE, the necessary 110 keying material (notably, the OSCORE Master Secret, see 111 [I-D.ietf-core-object-security]) needs to be established between CoAP 112 client and server, e.g. using a key exchange protocol; a trusted 113 third party; or pre-established keys. Different options are allowed 114 and with different properties as is indicated in the next section. 116 Yet other optimizations to certificate based enrolment are possible 117 further improve the performance of certificate enrolment and 118 certificate based authentication, in particular the use of more 119 compact representations of X.509 certificates such as 120 [I-D.raza-ace-cbor-certificates]. 122 1.1. EST-CoAPs operational differences 124 This specification builds on EST-CoAPs [I-D.ietf-ace-coap-est] but 125 transport layer security provided by DTLS is replaced, or 126 complemented, by protection of the application layer data. This 127 specification deviates from EST-CoAPs in the following respects: 129 o The DTLS record layer is replaced, or complemented, with OSCORE. 131 o The DTLS handshake is replaced, or complemented, with an 132 alternative key establishment, for example: 134 * A key exchange protocol, such as EDHOC 135 [I-D.selander-ace-cose-ecdhe]. The use of a key exchange 136 protocol completes the analogy with EST-CoAPs, and provides 137 perfect forward secrecy (PFS) of the keys used to protect the 138 EST messages. However, PFS is not necessary for the enrolment 139 procedure and adds significant overhead in terms of message 140 size and round trips. 142 * Trusted third party (TTP) based provisioning, such as the 143 OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. This 144 assumes existing security associations between the client and 145 the TTP, and between the server and the TTP, and reduces the 146 message size and round trips compared to a key exchange 147 protocol. 149 * Pre-shared keys (PSK). Although one reason for using a PKI is 150 to avoid managing PSK, applying OSCORE directly with PSK 151 specifically during deployment gives a one round-trip enrolment 152 protocol with low message overhead, thereby further reducing 153 the network load and time for commissioning. 155 o EST payloads protected by OSCORE can be proxied between 156 constrained networks supporting CoAP/CoAPs and non-constrained 157 networks supporting HTTP/HTTPs with a CoAP-HTTP proxy protection 158 without any security processing in the proxy. 160 1.2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. These 165 words may also appear in this document in lowercase, absent their 166 normative meanings. 168 This document uses terminology from [I-D.ietf-ace-coap-est] which in 169 turn is based on [RFC7030] and, in turn, on [RFC5272]. 171 2. Protocol Design and Layering 173 EST-oscore uses CoAP [RFC7252] and Block-Wise [RFC7959] to transfer 174 EST messages in the same way as [I-D.ietf-ace-coap-est]. Figure 1 175 below shows the layered EST-oscore architecture. 177 +------------------------------------------------+ 178 | EST request/response messages | 179 +------------------------------------------------+ 180 | CoAP with OSCORE | HTTP with OSCORE | 181 +------------------------------------------------+ 182 | UDP | DTLS/UDP | TLS/TCP | 183 +------------------------------------------------+ 185 Figure 1: EST protected with OSCORE. 187 EST-oscore follows closely the EST-coaps and EST design. The message 188 types for simple enroll, reenroll, CA certificate retrieval, CSR 189 Attributes request messages and server-side key generation messages 190 apply. Section references in this paragraph refer to EST-coaps 191 ([I-D.ietf-ace-coap-est]): The payload format, message bindings, CoAP 192 response codes, message fragmentation based on Blockwise, and the 193 delayed responses specified in Section 5 apply. 195 3. Discovery and URI 197 The discovery of EST resources defined in Section 5.1 of 198 [I-D.ietf-ace-coap-est], as well as the new Resource Type defined in 199 Section 9.1 of [I-D.ietf-ace-coap-est] apply to EST-oscore. Support 200 for OSCORE is indicated by the "osc" attribute defined in Section 9 201 of [I-D.ietf-core-object-security], for example: 203 REQ: GET /.well-known/core?rt=ace.est.sen 205 RES: 2.05 Content 206 ; rt="ace.est";osc 208 The short EST-coaps URI paths defined in Section 5.1 of 209 [I-D.ietf-ace-coap-est] also apply. 211 4. OSCORE-Based Security 213 EST-oscore depends on the application layer security provided by 214 OSCORE for protecting CoAP and CoAP-mappable HTTP independent of 215 transport. The establishment of keys for OSCORE defines many of the 216 properties of the protocol. 218 If a key exchange protocols is used, fragmentation of the protocol 219 messages needs to be handled. EDHOC [I-D.selander-ace-cose-ecdhe] 220 may be carried in CoAP in which case Block fragmentation can be used. 222 5. Proxying 224 As is noted Section 6 of [I-D.ietf-ace-coap-est], in real-world 225 deployments, the EST server will not always reside within the CoAP 226 boundary. The EST-server can exist outside the constrained network 227 in a non-constrained network that does not support CoAP but HTTP, 228 thus requiring an intermediary CoAP-to-HTTP proxy. 230 Since OSCORE is applicable to CoAP-mappable HTTP the EST payloads can 231 be protected end-to-end between EST client and EST server independent 232 of transport protocol or potential transport layer security which may 233 need to be terminated in the proxy, see Figure Figure 2. The signed 234 certification request SHOULD be bound to the OSCORE security context 235 using a derived secret analogously to the use of tls-unique as 236 described in Section 3.5 of [RFC7030]. The mappings between CoAP and 237 HTTP referred to in Section 6 of [I-D.ietf-ace-coap-est] applies and 238 the additional mappings resulting from the use of OSCORE are 239 specified in Section 11 of [I-D.ietf-core-object-security]. 241 OSCORE provides security end-to-end between EST Server and EST 242 Client. The use of TLS and DTLS is optional. 244 Constrained-Node Network 245 .---------. .----------------------------. 246 | CA | |.--------------------------.| 247 '---------' || || 248 | || || 249 .------. HTTP .-----------------. CoAP .-----------. || 250 | EST |<------->| CoAP-to-HTTP |<-------->| EST Client| || 251 |Server| (TLS) | Proxy | (DTLS) '-----------' || 252 '------' '-----------------' || 253 || || 254 <------------------------------------------------> || 255 OSCORE || || 256 |'--------------------------'| 257 '----------------------------' 259 Figure 2: CoAP-to-HTTP proxy at the CoAP boundary. 261 6. Security Considerations 263 TBD 265 7. Privacy Considerations 267 TBD 269 8. IANA Considerations 271 9. Acknowledgments 273 10. References 275 10.1. Normative References 277 [I-D.ietf-ace-coap-est] 278 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 279 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 280 est-09 (work in progress), February 2019. 282 [I-D.ietf-core-object-security] 283 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 284 "Object Security for Constrained RESTful Environments 285 (OSCORE)", draft-ietf-core-object-security-15 (work in 286 progress), August 2018. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 294 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 295 October 2013, . 297 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 298 Application Protocol (CoAP)", RFC 7252, 299 DOI 10.17487/RFC7252, June 2014, 300 . 302 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 303 the Constrained Application Protocol (CoAP)", RFC 7959, 304 DOI 10.17487/RFC7959, August 2016, 305 . 307 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 308 RFC 8152, DOI 10.17487/RFC8152, July 2017, 309 . 311 10.2. Informative References 313 [I-D.ietf-6tisch-minimal-security] 314 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 315 "Minimal Security Framework for 6TiSCH", draft-ietf- 316 6tisch-minimal-security-09 (work in progress), November 317 2018. 319 [I-D.ietf-ace-oscore-profile] 320 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 321 "OSCORE profile of the Authentication and Authorization 322 for Constrained Environments Framework", draft-ietf-ace- 323 oscore-profile-07 (work in progress), February 2019. 325 [I-D.ietf-core-oscore-groupcomm] 326 Tiloca, M., Selander, G., Palombini, F., and J. Park, 327 "Group OSCORE - Secure Group Communication for CoAP", 328 draft-ietf-core-oscore-groupcomm-03 (work in progress), 329 October 2018. 331 [I-D.raza-ace-cbor-certificates] 332 Raza, S., Hoglund, J., Selander, G., and J. Mattsson, 333 "CBOR Profile of X.509 Certificates", draft-raza-ace-cbor- 334 certificates-00 (work in progress), October 2018. 336 [I-D.selander-ace-cose-ecdhe] 337 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 338 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 339 cose-ecdhe-12 (work in progress), February 2019. 341 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 342 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 343 . 345 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 346 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 347 January 2012, . 349 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 350 "Enrollment over Secure Transport", RFC 7030, 351 DOI 10.17487/RFC7030, October 2013, 352 . 354 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 355 Constrained-Node Networks", RFC 7228, 356 DOI 10.17487/RFC7228, May 2014, 357 . 359 Appendix A. Examples 361 TBD 363 Authors' Addresses 365 Goeran Selander 366 Ericsson AB 368 Email: goran.selander@ericsson.com 370 Shahid Raza 371 RISE SICS 373 Email: shahid.raza@ri.se 374 Martin Furuhed 375 Nexus 377 Email: martin.furuhed@nexusgroup.com 379 Malisa Vucinic 380 University of Montenegro 382 Email: malisav@ac.me