idnits 2.17.1 draft-richardson-enrollment-roadmap-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 == Line 153 has weird spacing: '...ecurity tou...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 23, 2018) is 2158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ieee802-1AR' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC7049' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 516, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-dtsecurity-zerotouch-join-02 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-05 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-00 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-15 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-12 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-21 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-08 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** 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 (-03) exists of draft-richardson-anima-state-for-joinrouter-02 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational May 23, 2018 5 Expires: November 24, 2018 7 Device Enrollment in IETF protocols -- A Roadmap 8 draft-richardson-enrollment-roadmap-02 10 Abstract 12 This document provides an overview of enrollment or imprinting 13 mechanisms in current IETF protocols. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 24, 2018. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Components of enrollment solutions . . . . . . . . . . . . . 3 51 3. Map of Enrollment solution . . . . . . . . . . . . . . . . . 4 52 4. Components . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. generic voucher semantics . . . . . . . . . . . . . . . . 6 54 4.2. constrained voucher . . . . . . . . . . . . . . . . . . . 6 55 4.3. JSON format voucher . . . . . . . . . . . . . . . . . . . 6 56 4.4. COSE-8152 . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.5. standard signature (CMS) . . . . . . . . . . . . . . . . 6 58 4.6. EDHOC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.7. EST-COAPS 2/DTLS sec(urity) . . . . . . . . . . . . . . . 6 60 4.8. EST-HTTPS TLS sec(urity) . . . . . . . . . . . . . . . . 7 61 4.9. constrained object security (OSCORE) . . . . . . . . . . 7 62 4.10. Pledge traffic proxy mechanisms . . . . . . . . . . . . . 7 63 4.10.1. COAP proxy,stateless . . . . . . . . . . . . . . . . 7 64 4.11. DTLS proxy . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.12. IPIP proxy,stateless . . . . . . . . . . . . . . . . . . 7 66 4.13. circuit proxy stateful . . . . . . . . . . . . . . . . . 8 67 5. call-home ssh/tls/usbkey . . . . . . . . . . . . . . . . . . 8 68 6. manufacturer authorized signing authority (MASA) . . . . . . 8 69 7. Enrollment Mechanisms . . . . . . . . . . . . . . . . . . . . 8 70 7.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.2. BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.3. Transition to Constrained Bootstrap . . . . . . . . . . . 9 73 7.4. 6tisch Zero Touch . . . . . . . . . . . . . . . . . . . . 10 74 7.5. 6tisch minimal security . . . . . . . . . . . . . . . . . 10 75 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 12.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 There are numerous mechanisms being proposed to solve the problem of 87 securely introducing a new devices into an existing managed network. 89 This document provides an overview of the different mechanisms 90 showing what technologies are common. The document starts with a 91 diagram showing the various components and how they go together to 92 form five enrollment scenarios. 94 2. Components of enrollment solutions 96 This diagram is taken from [I-D.ietf-anima-bootstrapping-keyinfra], 97 which is where this work started. 99 +------------------------+ 100 +--------------Drop Ship--------------->| Vendor Service | 101 | +------------------------+ 102 | | M anufacturer| | 103 | | A uthorized |Ownership| 104 | | S igning |Tracker | 105 | | A uthority | | 106 | +--------------+---------+ 107 | ^ 108 | | BRSKI- 109 V | MASA 110 +-------+ ............................................|... 111 | | . | . 112 | | . +------------+ +-----------+ | . 113 | | . | | | | | . 114 |Pledge | . | Circuit | | Domain <-------+ . 115 | | . | Proxy | | Registrar | . 116 | <-------->............<-------> (PKI RA) | . 117 | | | BRSKI-EST | | . 118 | | . | | +-----+-----+ . 119 |IDevID | . +------------+ | EST RFC7030 . 120 | | . +-----------------+----------+ . 121 | | . | Key Infrastructure | . 122 | | . | (e.g. PKI Certificate | . 123 +-------+ . | Authority) | . 124 . +----------------------------+ . 125 . . 126 ................................................ 127 "Domain" components 129 Five major components are described: 131 1. pledge: The node that is attempting to enroll. 133 2. proxy: A node that is within one layer-2 hop of the pledge that 134 is helping. 136 3. domain registrar: the Join Registrar/Coordinator (JRC) that will 137 determine eligibility of the pledge. 139 4. MASA: the representative of the manufacturer that has a pre- 140 established trust relationship with the pledge. 142 5. the domain PKI (if any) 144 3. Map of Enrollment solution 145 .-------------------. 146 . generic (YANG) . 147 .----------------. voucher semantics . 148 | '-------------------' 149 | .--- 150 | | 151 6tisch 6tisch Tran|ition to | 152 minimal zero Con|trained | 153 security touch Bo|tstrap BRSKI | Netconf 154 .----------..-----------..---|-------..------------. |-------------. 155 | || || v || | v | 156 | ||..................................................... | 157 | ||. constrained voucher . JSON format voucher . | 158 | ||. (anima) . (RFC8366) . | 159 | ||..................................................... | 160 | || || || | | | 161 | |.............| ...................................... | 162 | |. COSE .| . standard signature (CMS - RFC5652) . | 163 | |. rfc8152 .| ...................................... | 164 | |.............| || | | | 165 | || ............................| | | 166 | |......... . EST-COAPS .. EST-HTTPS .| | | 167 | |. EDHOC . . w/DTLS sec. .. TLS sec. .| | | 168 |..................................................| | | 169 |. constrained object . || || | | | 170 |. security (OSCORE) . || || | |.............| 171 |...................... || ||............| |. call-home .| 172 | || ||......... ||. circuit .| |. ssh/tls .| 173 |........................|. DTLS . ||. proxy .| |. .usbkey .| 174 |. CoAP proxy,stateless .|. proxy . ||. stateful .| |.............| 175 |..................................................| | | 176 | ||. IPIP proxy,stateless .| | | 177 | ||......................................| | | 178 '----------''-----------''-----------''------------' '-------------' 179 ^ ^ ^ ^ 180 | \ | | 181 | '. .--------------' 182 | | | 183 | | | 184 | | .--------------. 185 | | . manufacturer . 186 | | . authorized . 187 '---------------|--. signing . 188 . authority . 189 . (MASA) . 190 '--------------' 192 4. Components 194 4.1. generic voucher semantics 196 The abstract semantics of the voucher, described in YANG, are in 197 [RFC8366]. 199 4.2. constrained voucher 201 The semantics of the constrained voucher, represented in CBOR, are 202 described in [I-D.ietf-anima-constrained-voucher]. 204 4.3. JSON format voucher 206 The semantics of the basic voucher, represented in JSON, are 207 described in [RFC8366]. 209 4.4. COSE-8152 211 In constrained systems the voucher is signed using the COSE mechanism 212 described in [RFC8152]. 214 4.5. standard signature (CMS) 216 In un-constrained systems the voucher is signed using the 217 Cryptographic Message Syntax (CMS) described in [RFC5652]. 219 4.6. EDHOC 221 On constrained and challenged networks, the session key management 222 can be formed by [I-D.selander-ace-cose-ecdhe]. 224 This document does NOT have a home. 226 The CoAP-EST layer on top is described by [I-D.ietf-ace-coap-est] 228 4.7. EST-COAPS 2/DTLS sec(urity) 230 On unconstrained networks, the session key management is provided by 231 [RFC6347]. The CoAP-EST layer on top is described by 232 [I-D.ietf-ace-coap-est]. 234 The ACE WG has adopted this document. 236 4.8. EST-HTTPS TLS sec(urity) 238 On unconstrained networks with unconstrained nodes, the EST layer and 239 session key management is described by [RFC7030] as modified by 240 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI). 242 4.9. constrained object security (OSCORE) 244 On constained networks with constrained nodes, the CoAP transactions 245 are secured by [I-D.ietf-core-object-security] using symmetric keys. 246 The symmetric key may be pre-shared (for 6tisch minimal security), or 247 MAY be derived using EDHOC. 249 4.10. Pledge traffic proxy mechanisms 251 Traffic between the Pledge and the JRC does not flow directly as the 252 pledge does not typically have a globally reachable address, nor does 253 it have any network access keys (whether WEP, WPA, 802.1x, or 254 802.15.4 keys). 256 Communication between the pledge and JRC is mediated by a proxy. 257 This is primarily to protect the network against attacks. The proxy 258 mechanism is provided by as many nodes as can afford to as a benefit 259 to the network, and therefore MUST be as light weight as possible. 260 There are therefore stateless mechanisms and stateful mechanisms. 261 The costs of the various methods is analysized in 262 [I-D.richardson-anima-state-for-joinrouter]. 264 4.10.1. COAP proxy,stateless 266 The CoAP proxy mechanism uses the OSCORE Context Hint to statelessly 267 store the address of the proxy within the CoAP structure. It is 268 described in [I-D.ietf-6tisch-minimal-security]. 270 4.11. DTLS proxy 272 There has been no specific DTLS specific stateless proxy described, 273 although the mechanism described by the Thread Group is being 274 considered, if it can be referenced easily. 276 4.12. IPIP proxy,stateless 278 An IPIP proxy mechanism uses a layer of IP-in-IP header (protocol 98) 279 to encapsulate the traffic between Join Proxy and JRC. It has some 280 complexities to implement on typical POSIX platforms. It is intended 281 to be described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join], in an 282 Appendix. Another home for the text is also desired. 284 4.13. circuit proxy stateful 286 The circuit proxy method utilitizes either an application layer 287 gateway (which in canonical 1990-era implementation requires a 288 process per connection), or the use of NAT66. It maintains some 289 state for each connection whether TCP or UDP. 291 It is this most expensive and most easily abused, but also the most 292 widely available, code-wise. 294 5. call-home ssh/tls/usbkey 296 The NETCONF call-home mechanism assumes that the device can get basic 297 connectivity, enough for an out "outgoing" TCP connection to the 298 manufacturer. 300 6. manufacturer authorized signing authority (MASA) 302 The MASA is the manufacturers anchor of the manufacturer/pledge trust 303 relationship that is established at the factory where the pledge is 304 built. 306 7. Enrollment Mechanisms 308 7.1. NETCONF 310 The NETCONF WG is describing this in [I-D.ietf-netconf-zerotouch] 311 document. 313 The NETCONF Zerotouch mechanism provides configuration and ownership 314 information by having the pledge "call home" to a location determined 315 by a mix of local hints (DHCPv4, DHCPv6, and mDNS), as well as built- 316 in anchors. Additionally, ownership vouchers can be alternatively 317 distributed by portable storage such as USB key. 319 Upon reaching a validated call-home server, Zerotouch typically 320 "reverses" the connection providing either an SSH or TLS connection 321 _to_ the pledge device such that it can be configured automatically. 323 Zerotouch relies upon either open or very easy access to network 324 connectivity, along with the ability to make an outgoing TCP 325 connection to the Internet, or to the provided local configuration 326 agent. 328 Zerotouch is seen as an updated version of TR-69 by some, appropriate 329 for configuration of residential appliances which are drop-shiped by 330 ISPs or other service providers to homes. That is not the only 331 targetted use. 333 7.2. BRSKI 335 The ANIMA WG is describing BRSKI in 336 [I-D.ietf-anima-bootstrapping-keyinfra] document. 338 The ANIMA WG does enrollment with the aim of creating a secure 339 channel with a public-key infrastructure (PKI) Registrar. The 340 secured channel is used to perform Enrollment over Secure Transport 341 (EST, RFC7030). The real goal is the enrollment a new device which 342 was probably been drop-shipped into ANIMA's Autonomic Control Plane. 344 That is, after the pledge has been assigned a certificate within the 345 (autonomic) domain, the device (no longer a pledge) will then form 346 secure channels (typically using IKEv2 to key an IPsec channel). On 347 top of that channel a routing protocol (RPL) is run to form the 348 Autonomic Control Plane (ACP). The ACP is then used as a management 349 network with which to configure the new device. 351 BRSKI is therefore step one of a number of steps, the ultimate goal 352 of which is to bring the pledge into the ACP as a new device. 354 BRSKI itself does not provide for any direct keying of the network 355 (802.11 WEP/WPA, or 802.15.4 security). The provision of a domain 356 certificate at each node can, however, be used to do that kind of 357 keying: for instance 802.15.9 provides for use of HIP and IKEv2 to 358 key 802.15.4 networks. 360 7.3. Transition to Constrained Bootstrap 362 This category of usage could use a better name. 364 The bulk of this work has no home as yet. It is distinguished from 365 BRSKI in that it uses DTLS (rather than TLS) and constrained (CBOR) 366 vouchers. It is distinguished from 6tisch Zero Touch in that uses 367 CMS to sign rather than COSE. 369 The ACE WG has adopted [I-D.ietf-ace-coap-est], but this is not a 370 sufficient. This work depends depends upon 371 [I-D.ietf-anima-constrained-voucher]. 373 The use of this technology slice is attractive to IoT deployments 374 where the devices are not battery powered (lighting for instance, AMI 375 for electric meters). In such situations, the processors in each 376 device have significantly more resources, and in particular far more 377 code space available. The use of DTLS to secure application traffic 378 (as described in the ACE documents) is already common, and so reuse 379 of DTLS is desireable from a code point of view. 381 However, the network capacity is still limited so TCP and CBOR are 382 still important. The network may also contain extremely constrained 383 devices (kinetically powered light switches for instance). 385 7.4. 6tisch Zero Touch 387 The 6tisch WG is describing this in 388 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] document. 390 The 6tisch use case consists of very constrained devices with very 391 constrained networks. Code space in the devices is larger than 392 typical class 2, but the devices are typically battery powered and 393 wish to sleep significantly. 395 The use of CBOR for vouchers, COSE to sign the vouchers saves 396 significant network bandwidth and code space. Both CBOR, COSE and 397 OSCORE are typically already in use for the application support. The 398 addition of EDHOC to provide asymmetric bootstrap of OSCORE completes 399 the suite of constrained security protocols. 401 7.5. 6tisch minimal security 403 The 6tisch WG is describing this in 404 [I-D.ietf-6tisch-minimal-security] document. This mechanism does 405 enrollment in a single request/response message, but requires at 406 least one "touch" to pre-share symmetric keys. 408 The 6tisch WG felt that the number of round trips required to do 409 EDHOC, and the size of the vouchers required an even simpler 410 protocol. As existing 6tisch-type technology is typically deployed 411 with network keys built-in at manufacturer time (no "drop-ship"), the 412 switch from a static network key to a PSK for authenticaiton is 413 considered an incremental improvement. 415 All other methods are considered zero "touch". 417 8. Discussion 419 A goal of this document is to provide some guidance in selecting 420 which enrollment profile to use for a given scenario. This section 421 tries to provide some constrasting comments between the various 422 mechanisms. 424 (BUT, it does not yet do that..) 426 9. Security Considerations 428 This document includes a tradeoff of the security attributes of the 429 different protocols, and so the entire document contains security 430 advice. 432 10. IANA Considerations 434 This document does not define any new protocols, and therefore does 435 not have any IANA Considerations. 437 11. Acknowledgements 439 TBD 441 12. References 443 12.1. Normative References 445 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 446 Richardson, M. and B. Damm, "6tisch Zero-Touch Secure Join 447 protocol", draft-ietf-6tisch-dtsecurity-zerotouch-join-02 448 (work in progress), April 2018. 450 [I-D.ietf-6tisch-minimal-security] 451 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 452 "Minimal Security Framework for 6TiSCH", draft-ietf- 453 6tisch-minimal-security-05 (work in progress), March 2018. 455 [I-D.ietf-ace-coap-est] 456 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 457 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 458 coaps)", draft-ietf-ace-coap-est-00 (work in progress), 459 February 2018. 461 [I-D.ietf-anima-bootstrapping-keyinfra] 462 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 463 S., and K. Watsen, "Bootstrapping Remote Secure Key 464 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 465 keyinfra-15 (work in progress), April 2018. 467 [I-D.ietf-anima-constrained-voucher] 468 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 469 Voucher Artifacts for Bootstrapping Protocols", draft- 470 ietf-anima-constrained-voucher-00 (work in progress), May 471 2018. 473 [I-D.ietf-core-object-security] 474 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 475 "Object Security for Constrained RESTful Environments 476 (OSCORE)", draft-ietf-core-object-security-12 (work in 477 progress), March 2018. 479 [I-D.ietf-netconf-zerotouch] 480 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 481 Provisioning for Networking Devices", draft-ietf-netconf- 482 zerotouch-21 (work in progress), March 2018. 484 [I-D.selander-ace-cose-ecdhe] 485 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 486 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 487 cose-ecdhe-08 (work in progress), March 2018. 489 [ieee802-1AR] 490 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 491 2009, . 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, 496 DOI 10.17487/RFC2119, March 1997, 497 . 499 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 500 RFC 5652, DOI 10.17487/RFC5652, September 2009, 501 . 503 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 504 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 505 January 2012, . 507 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 508 "Enrollment over Secure Transport", RFC 7030, 509 DOI 10.17487/RFC7030, October 2013, 510 . 512 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 513 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 514 October 2013, . 516 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 517 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 518 Transport Layer Security (TLS) and Datagram Transport 519 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 520 June 2014, . 522 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 523 RFC 8152, DOI 10.17487/RFC8152, July 2017, 524 . 526 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 527 "A Voucher Artifact for Bootstrapping Protocols", 528 RFC 8366, DOI 10.17487/RFC8366, May 2018, 529 . 531 12.2. Informative References 533 [I-D.richardson-anima-state-for-joinrouter] 534 Richardson, M., "Considerations for stateful vs stateless 535 join router in ANIMA bootstrap", draft-richardson-anima- 536 state-for-joinrouter-02 (work in progress), January 2018. 538 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 539 . 541 Author's Address 543 Michael Richardson 544 Sandelman Software Works 546 Email: mcr+ietf@sandelman.ca