idnits 2.17.1 draft-selander-ace-coap-est-oscore-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 05, 2018) is 2053 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-05 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-14 ** 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-06 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-02 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-09 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 7 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: March 9, 2019 RISE SICS 6 M. Furuhed 7 Nexus 8 M. Vucinic 9 University of Montenegro 10 September 05, 2018 12 Protecting EST payloads with OSCORE 13 draft-selander-ace-coap-est-oscore-01 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 March 9, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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. 121 1.1. EST-CoAPs operational differences 123 This specification builds on EST-CoAPs [I-D.ietf-ace-coap-est] but 124 transport layer security provided by DTLS is replaced, or 125 complemented, by protection of the application layer data. This 126 specification deviates from EST-CoAPs in the following respects: 128 o The DTLS record layer is replaced, or complemented, with OSCORE. 130 o The DTLS handshake is replaced, or complemented, with an 131 alternative key establishment, for example: 133 * A key exchange protocol, such as EDHOC 134 [I-D.selander-ace-cose-ecdhe]. The use of a key exchange 135 protocol completes the analogy with EST-CoAPs, and provides 136 perfect forward secrecy (PFS) of the keys used to protect the 137 EST messages. However, PFS is not necessary for the enrolment 138 procedure and adds significant overhead in terms of message 139 size and round trips. 141 * Trusted third party (TTP) based provisioning, such as the 142 OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. This 143 assumes existing security associations between the client and 144 the TTP, and between the server and the TTP, and reduces the 145 message size and round trips compared to a key exchange 146 protocol. 148 * Pre-shared keys (PSK). Although one reason for using a PKI is 149 to avoid managing PSK, applying OSCORE directly with PSK 150 specifically during deployment gives a one round-trip enrolment 151 protocol with low message overhead, thereby further reducing 152 the network load and time for commissioning. 154 o EST payloads protected by OSCORE can be proxied between 155 constrained networks supporting CoAP/CoAPs and non-constrained 156 networks supporting HTTP/HTTPs with a CoAP-HTTP proxy protection 157 without any security processing in the proxy. 159 1.2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 This document uses terminology from [I-D.ietf-ace-coap-est] which in 168 turn is based on [RFC7030] and, in turn, on [RFC5272]. 170 2. Protocol Design and Layering 172 EST-oscore uses CoAP [RFC7252] and Block-Wise [RFC7959] to transfer 173 EST messages in the same way as [I-D.ietf-ace-coap-est]. Figure 1 174 below shows the layered EST-oscore architecture. 176 +------------------------------------------------+ 177 | EST request/response messages | 178 +------------------------------------------------+ 179 | CoAP with OSCORE | HTTP with OSCORE | 180 +------------------------------------------------+ 181 | UDP | DTLS/UDP | TLS/TCP | 182 +------------------------------------------------+ 184 Figure 1: EST protected with OSCORE. 186 EST-oscore follows closely the EST-coaps and EST design. The message 187 types for simple enroll, reenroll, CA certificate retrieval, CSR 188 Attributes request messages and server-side key generation messages 189 apply. Section references in this paragraph refer to EST-coaps 190 ([I-D.ietf-ace-coap-est]): The payload format, content format, 191 message bindings and CoAP response codes specified in Section 4.1 - 192 4.3 apply. The procedure for handling delayed responses described in 193 section 4.4 may also be used with OSCORE. For server-side key 194 generation, the procedure described in Section 4.5 may be used with 195 DecryptKeyIdentifier established out of band or derived from the 196 OSCORE Master Secret. Message fragmentation based on CoAP Block 197 options specified in Section 4.6 is also applicable with OSCORE. 199 3. Discovery and URI 201 The discovery of EST resources defined in Section 5 of 202 [I-D.ietf-ace-coap-est], as well as the new Resource Type defined in 203 Section 9.1 of [I-D.ietf-ace-coap-est] apply to EST-oscore. Support 204 for OSCORE is indicated by the "osc" attribute defined in Section 9 205 of [I-D.ietf-core-object-security], for example: 207 REQ: GET /.well-known/core?rt=ace.est 209 RES: 2.05 Content 210 ; rt="ace.est";osc 212 The abbreviated EST-coaps URI paths defined in Section 5 of 213 [I-D.ietf-ace-coap-est] also apply. 215 4. OSCORE-Based Security 217 EST-oscore depends on the application layer security provided by 218 OSCORE for protecting CoAP and CoAP-mappable HTTP independent of 219 transport. The establishment of keys for OSCORE defines many of the 220 properties of the protocol. 222 If a key exchange protocols is used, fragmentation of the protocol 223 messages needs to be handled. EDHOC [I-D.selander-ace-cose-ecdhe] 224 may be carried in CoAP in which case Block fragmentation can be used. 226 (Editor's note: Compare and complete with the analogous Section 6 in 227 EST-coaps) 229 5. Proxying 231 As is noted Section 7 of [I-D.ietf-ace-coap-est], in real-world 232 deployments, the EST server will not always reside within the CoAP 233 boundary. The EST-server can exist outside the constrained network 234 in a non-constrained network that does not support CoAP but HTTP, 235 thus requiring an intermediary CoAP-to-HTTP proxy. 237 Since OSCORE is applicable to CoAP-mappable HTTP the EST payloads can 238 be protected end-to-end between EST client and EST server independent 239 of transport protocol or potential transport layer security which may 240 need to be terminated in the proxy, see Figure Figure 2. The signed 241 certification request SHOULD be bound to the OSCORE security context 242 using a derived secret analogously to the use of tls-unique as 243 described in Section 3.5 of [RFC7030]. The mappings between CoAP and 244 HTTP referred to in Section 6 of [I-D.ietf-ace-coap-est] applies and 245 the additional mappings resulting from the use of OSCORE are 246 specified in Section 11 of [I-D.ietf-core-object-security]. 248 Constrained-Node Network 249 .---------. .----------------------------. 250 | CA | |.--------------------------.| 251 '---------' || || 252 | || || 253 .------. HTTP .-----------------. CoAP .-----------. || 254 | EST |<------->| CoAP-to-HTTP |<-------->| EST Client| || 255 |Server| (TLS) | Proxy | (DTLS) '-----------' || 256 '------' '-----------------' || 257 || || 258 <------------------------------------------------> || 259 OSCORE || || 260 |'--------------------------'| 261 '----------------------------' 263 Figure 2: CoAP-to-HTTP proxy at the CoAP boundary. 265 6. Security Considerations 267 TBD 269 7. Privacy Considerations 271 TBD 273 8. IANA Considerations 275 9. Acknowledgments 277 10. References 279 10.1. Normative References 281 [I-D.ietf-ace-coap-est] 282 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 283 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 284 coaps)", draft-ietf-ace-coap-est-05 (work in progress), 285 July 2018. 287 [I-D.ietf-core-object-security] 288 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 289 "Object Security for Constrained RESTful Environments 290 (OSCORE)", draft-ietf-core-object-security-14 (work in 291 progress), July 2018. 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 299 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 300 October 2013, . 302 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 303 Application Protocol (CoAP)", RFC 7252, 304 DOI 10.17487/RFC7252, June 2014, 305 . 307 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 308 the Constrained Application Protocol (CoAP)", RFC 7959, 309 DOI 10.17487/RFC7959, August 2016, 310 . 312 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 313 RFC 8152, DOI 10.17487/RFC8152, July 2017, 314 . 316 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 317 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 318 May 2017, . 320 10.2. Informative References 322 [I-D.ietf-6tisch-minimal-security] 323 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 324 "Minimal Security Framework for 6TiSCH", draft-ietf- 325 6tisch-minimal-security-06 (work in progress), May 2018. 327 [I-D.ietf-ace-oscore-profile] 328 Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander, 329 "OSCORE profile of the Authentication and Authorization 330 for Constrained Environments Framework", draft-ietf-ace- 331 oscore-profile-02 (work in progress), June 2018. 333 [I-D.ietf-core-oscore-groupcomm] 334 Tiloca, M., Selander, G., Palombini, F., and J. Park, 335 "Secure group communication for CoAP", draft-ietf-core- 336 oscore-groupcomm-02 (work in progress), June 2018. 338 [I-D.selander-ace-cose-ecdhe] 339 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 340 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 341 cose-ecdhe-09 (work in progress), July 2018. 343 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 344 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 345 . 347 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 348 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 349 January 2012, . 351 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 352 "Enrollment over Secure Transport", RFC 7030, 353 DOI 10.17487/RFC7030, October 2013, 354 . 356 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 357 Constrained-Node Networks", RFC 7228, 358 DOI 10.17487/RFC7228, May 2014, 359 . 361 Appendix A. Examples 363 TBD 365 Authors' Addresses 367 Goeran Selander 368 Ericsson AB 370 Email: goran.selander@ericsson.com 371 Shahid Raza 372 RISE SICS 374 Email: shahid.raza@ri.se 376 Martin Furuhed 377 Nexus 379 Email: martin.furuhed@nexusgroup.com 381 Malisa Vucinic 382 University of Montenegro 384 Email: malisav@ac.me