idnits 2.17.1 draft-richardson-enrollment-roadmap-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 == Line 161 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 (October 07, 2020) is 1296 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.selander-ace-cose-ecdhe' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'ieee802-1AR' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC7049' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 591, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-44 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-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 (-04) exists of draft-friel-anima-brski-cloud-03 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-29 == Outdated reference: A later version (-05) exists of draft-ietf-anima-brski-async-enroll-00 == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-14 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-01 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-01 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational October 07, 2020 5 Expires: April 10, 2021 7 Device Enrollment in IETF protocols -- A Roadmap 8 draft-richardson-enrollment-roadmap-03 10 Abstract 12 This document provides an overview of enrollment or imprinting 13 mechanisms in current IETF protocols. 15 This document is being worked on in the ANIMA-WG, and on github at: 16 https://github.com/anima-wg/enrollment-roadmap 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 10, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Components of enrollment solutions . . . . . . . . . . . . . 3 54 3. Map of Enrollment solution . . . . . . . . . . . . . . . . . 4 55 4. Components . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. generic voucher semantics . . . . . . . . . . . . . . . . 6 57 4.2. constrained voucher . . . . . . . . . . . . . . . . . . . 6 58 4.3. JSON format voucher . . . . . . . . . . . . . . . . . . . 6 59 4.4. COSE-8152 . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.5. standard signature (CMS) . . . . . . . . . . . . . . . . 6 61 4.6. EDHOC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.7. EST-COAPS 2/DTLS sec(urity) . . . . . . . . . . . . . . . 6 63 4.8. EST-HTTPS TLS sec(urity) . . . . . . . . . . . . . . . . 7 64 4.9. constrained object security (OSCORE) . . . . . . . . . . 7 65 4.10. ultra-constrained enrollment . . . . . . . . . . . . . . 7 66 4.11. Pledge traffic proxy mechanisms . . . . . . . . . . . . . 7 67 4.11.1. COAP proxy,stateless . . . . . . . . . . . . . . . . 7 68 4.12. DTLS proxy . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.13. IPIP proxy,stateless . . . . . . . . . . . . . . . . . . 8 70 4.14. circuit proxy stateful . . . . . . . . . . . . . . . . . 8 71 5. call-home ssh/tls/usbkey . . . . . . . . . . . . . . . . . . 8 72 6. manufacturer authorized signing authority (MASA) . . . . . . 8 73 7. Enrollment Mechanisms . . . . . . . . . . . . . . . . . . . . 8 74 7.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.2. BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.3. Transition to Constrained Bootstrap . . . . . . . . . . . 10 77 7.4. Cloud-based Registrars . . . . . . . . . . . . . . . . . 10 78 7.5. BRSKY Asynchronous Enrollment . . . . . . . . . . . . . . 10 79 7.6. 6tisch Zero Touch . . . . . . . . . . . . . . . . . . . . 11 80 7.7. 6tisch minimal security . . . . . . . . . . . . . . . . . 11 81 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9. OPEN ISSUE . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 13.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 There are numerous mechanisms being proposed to solve the problem of 94 securely introducing a new devices into an existing managed network. 96 This document provides an overview of the different mechanisms 97 showing what technologies are common. 99 The document starts with a diagram showing the various components and 100 how they go together to form five enrollment scenarios. 102 2. Components of enrollment solutions 104 This diagram is taken from [I-D.ietf-anima-bootstrapping-keyinfra], 105 which is where this work started. 107 +------------------------+ 108 +--------------Drop Ship--------------->| Vendor Service | 109 | +------------------------+ 110 | | M anufacturer| | 111 | | A uthorized |Ownership| 112 | | S igning |Tracker | 113 | | A uthority | | 114 | +--------------+---------+ 115 | ^ 116 | | BRSKI- 117 V | MASA 118 +-------+ ............................................|... 119 | | . | . 120 | | . +------------+ +-----------+ | . 121 | | . | | | | | . 122 |Pledge | . | Circuit | | Domain <-------+ . 123 | | . | Proxy | | Registrar | . 124 | <-------->............<-------> (PKI RA) | . 125 | | | BRSKI-EST | | . 126 | | . | | +-----+-----+ . 127 |IDevID | . +------------+ | EST RFC7030 . 128 | | . +-----------------+----------+ . 129 | | . | Key Infrastructure | . 130 | | . | (e.g. PKI Certificate | . 131 +-------+ . | Authority) | . 132 . +----------------------------+ . 133 . . 134 ................................................ 135 "Domain" components 137 Five major components are described: 139 1. pledge: The node that is attempting to enroll. 141 2. proxy: A node that is within one layer-2 hop of the pledge that 142 is helping. 144 3. domain registrar: the Join Registrar/Coordinator (JRC) that will 145 determine eligibility of the pledge. 147 4. MASA: the representative of the manufacturer that has a pre- 148 established trust relationship with the pledge. 150 5. the domain PKI (if any) 152 3. Map of Enrollment solution 153 .-------------------. 154 . generic (YANG) . 155 .----------------. voucher semantics . 156 | '-------------------' 157 | .--- 158 | | 159 6tisch 6tisch Tran|ition to | 160 minimal zero Con|trained | 161 security touch Bo|tstrap BRSKI | Netconf 162 .----------..-----------..---|-------..------------. |-------------. 163 | || || v || | v | 164 | ||..................................................... | 165 | ||. constrained voucher . JSON format voucher . | 166 | ||. (anima) . (RFC8366) . | 167 | ||..................................................... | 168 | || || || | | | 169 | |.............| ...................................... | 170 | |. COSE .| . standard signature (CMS - RFC5652) . | 171 | |. rfc8152 .| ...................................... | 172 | |.............| || | | | 173 | || ............................| | | 174 | |......... . EST-COAPS .. EST-HTTPS .| | | 175 | |. EDHOC . . w/DTLS sec. .. TLS sec. .| | | 176 |..................................................| | | 177 |. constrained object . || || | | | 178 |. security (OSCORE) . || || | |.............| 179 |...................... || ||............| |. call-home .| 180 | || ||......... ||. circuit .| |. ssh/tls .| 181 |........................|. DTLS . ||. proxy .| |. .usbkey .| 182 |. CoAP proxy,stateless .|. proxy . ||. stateful .| |.............| 183 |..................................................| | | 184 | ||. IPIP proxy,stateless .| | | 185 | ||......................................| | | 186 '----------''-----------''-----------''------------' '-------------' 187 ^ ^ ^ ^ 188 | \ | | 189 | '. .--------------' 190 | | | 191 | | | 192 | | .--------------. 193 | | . manufacturer . 194 | | . authorized . 195 '---------------|--. signing . 196 . authority . 197 . (MASA) . 198 '--------------' 200 4. Components 202 4.1. generic voucher semantics 204 The abstract semantics of the voucher, described in YANG, are in 205 [RFC8366]. 207 4.2. constrained voucher 209 The semantics of the constrained voucher, represented in CBOR, are 210 described in [I-D.ietf-anima-constrained-voucher]. 212 4.3. JSON format voucher 214 The semantics of the basic voucher, represented in JSON, are 215 described in [RFC8366]. 217 4.4. COSE-8152 219 In constrained systems the voucher is signed using the COSE mechanism 220 described in [RFC8152]. This is to be replaced with 221 [I-D.ietf-cose-rfc8152bis-algs] (now in RFC-EDITOR Q) and 222 [I-D.ietf-cose-rfc8152bis-struct] (in WGLC, being revised to remove 223 countersignatures). 225 4.5. standard signature (CMS) 227 In un-constrained systems the voucher is signed using the 228 Cryptographic Message Syntax (CMS) described in [RFC5652]. 230 4.6. EDHOC 232 On constrained and challenged networks, the session key management 233 can be formed by [I-D.ietf-lake-edhoc]. 235 This document has a WG called LAKE. 237 The CoAP-EST layer on top is described by [I-D.ietf-ace-coap-est] 239 4.7. EST-COAPS 2/DTLS sec(urity) 241 On unconstrained networks, the session key management is provided by 242 [RFC6347]. The CoAP-EST layer on top is described by 243 [I-D.ietf-ace-coap-est], which is in the RFC-EDITOR Q, waiting for 244 DTLS 1.3. 246 The ACE WG adopted this document, and published it. 248 4.8. EST-HTTPS TLS sec(urity) 250 On unconstrained networks with unconstrained nodes, the EST layer and 251 session key management is described by [RFC7030] as modified by 252 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI). 254 BRSKI is in the RFC-EDITOR Q, waiting for 255 [I-D.ietf-anima-autonomic-control-plane], which is awaiting IESG go- 256 ahead. 258 4.9. constrained object security (OSCORE) 260 On constained networks with constrained nodes, the CoAP transactions 261 are secured by [I-D.ietf-core-object-security] using symmetric keys. 262 The symmetric key may be pre-shared (for 6tisch minimal security), or 263 MAY be derived using EDHOC. 265 4.10. ultra-constrained enrollment 267 The document [I-D.selander-ace-ake-authz]. Version -01 expired in 268 September 2020, but is expected to be reposted for discussion in the 269 ACE WG. 271 4.11. Pledge traffic proxy mechanisms 273 Traffic between the Pledge and the JRC does not flow directly as the 274 pledge does not typically have a globally reachable address, nor does 275 it have any network access keys (whether WEP, WPA, 802.1x, or 276 802.15.4 keys). 278 Communication between the pledge and JRC is mediated by a proxy. 279 This is primarily to protect the network against attacks. The proxy 280 mechanism is provided by as many nodes as can afford to as a benefit 281 to the network, and therefore MUST be as light weight as possible. 283 There are therefore stateless mechanisms and stateful mechanisms. 284 The costs of the various methods is analysized in 285 [I-D.richardson-anima-state-for-joinrouter]. 287 4.11.1. COAP proxy,stateless 289 The CoAP proxy mechanism uses the OSCORE Context Hint to statelessly 290 store the address of the proxy within the CoAP structure. It is 291 described in [I-D.ietf-6tisch-minimal-security]. 293 4.12. DTLS proxy 295 A DTLS specific mechanism for COAPS, is described in 296 [I-D.vanderstok-anima-constrained-join-proxy]. 298 4.13. IPIP proxy,stateless 300 An IPIP proxy mechanism uses a layer of IP-in-IP header (protocol 98) 301 to encapsulate the traffic between Join Proxy and JRC. It has some 302 complexities to implement on typical POSIX platforms. 304 At one point, it was described in 305 [I-D.ietf-6tisch-dtsecurity-zerotouch-join], in an Appendix. Another 306 home for the text is desired. 308 4.14. circuit proxy stateful 310 The circuit proxy method utilitizes either an application layer 311 gateway (which in canonical 1990-era implementation requires a 312 process per connection), or the use of NAT66. It maintains some 313 state for each connection whether TCP or UDP. 315 It is this most expensive and most easily abused, but also the most 316 widely available, code-wise. 318 5. call-home ssh/tls/usbkey 320 The NETCONF call-home mechanism assumes that the device can get basic 321 connectivity, enough for an out "outgoing" TCP connection to the 322 manufacturer. 324 6. manufacturer authorized signing authority (MASA) 326 The MASA is the manufacturers anchor of the manufacturer/pledge trust 327 relationship that is established at the factory where the pledge is 328 built. 330 7. Enrollment Mechanisms 332 7.1. NETCONF 334 The NETCONF WG is describing this in [I-D.ietf-netconf-zerotouch] 335 document. 337 The NETCONF Zerotouch mechanism provides configuration and ownership 338 information by having the pledge "call home" to a location determined 339 by a mix of local hints (DHCPv4, DHCPv6, and mDNS), as well as built- 340 in anchors. Additionally, ownership vouchers can be alternatively 341 distributed by portable storage such as USB key. 343 Upon reaching a validated call-home server, Zerotouch typically 344 "reverses" the connection providing either an SSH or TLS connection 345 _to_ the pledge device such that it can be configured automatically. 347 Zerotouch relies upon either open or very easy access to network 348 connectivity, along with the ability to make an outgoing TCP 349 connection to the Internet, or to the provided local configuration 350 agent. 352 Zerotouch is seen as an updated version of TR-69 by some, appropriate 353 for configuration of residential appliances which are drop-shiped by 354 ISPs or other service providers to homes. That is not the only 355 targetted use. 357 7.2. BRSKI 359 The ANIMA WG is describing BRSKI in 360 [I-D.ietf-anima-bootstrapping-keyinfra] document. 362 The ANIMA WG does enrollment with the aim of creating a secure 363 channel with a public-key infrastructure (PKI) Registrar. The 364 secured channel is used to perform Enrollment over Secure Transport 365 (EST, RFC7030). The real goal is the enrollment a new device which 366 was probably been drop-shipped into ANIMA's Autonomic Control Plane. 368 That is, after the pledge has been assigned a certificate within the 369 (autonomic) domain, the device (no longer a pledge) will then form 370 secure channels (typically using IKEv2 to key an IPsec channel). On 371 top of that channel a routing protocol (RPL) is run to form the 372 Autonomic Control Plane (ACP). The ACP is then used as a management 373 network with which to configure the new device. 375 BRSKI is therefore step one of a number of steps, the ultimate goal 376 of which is to bring the pledge into the ACP as a new device. 378 BRSKI itself does not provide for any direct keying of the network 379 (802.11 WEP/WPA, or 802.15.4 security). The provision of a domain 380 certificate at each node can, however, be used to do that kind of 381 keying: for instance 802.15.9 provides for use of HIP and IKEv2 to 382 key 802.15.4 networks. 384 7.3. Transition to Constrained Bootstrap 386 It is distinguished from BRSKI in that it uses DTLS (rather than TLS) 387 and constrained (CBOR) vouchers. It is distinguished from 6tisch 388 Zero Touch in that uses CMS to sign rather than COSE. 390 The ACE WG has adopted [I-D.ietf-ace-coap-est], but this is not a 391 sufficient. 393 The constrained version of BRSKI is current described as part of 394 [I-D.ietf-anima-constrained-voucher]. 396 The use of this technology slice is attractive to IoT deployments 397 where the devices are not battery powered (lighting for instance, AMI 398 for electric meters). In such situations, the processors in each 399 device have significantly more resources, and in particular far more 400 code space available. The use of DTLS to secure application traffic 401 (as described in the ACE documents) is already common, and so reuse 402 of DTLS is desireable from a code point of view. 404 However, the network capacity is still limited so TCP and CBOR are 405 still important. The network may also contain extremely constrained 406 devices (kinetically powered light switches for n instance). 408 7.4. Cloud-based Registrars 410 BRSKI depends upon a local join proxy to direct the pledge device to 411 the location of the Registrar. Not only does this require that a 412 join proxy be widely available, but it also assumes that the owner is 413 able to operate a Registrar. 415 [I-D.friel-anima-brski-cloud] deals with two use cases: 417 1. where there is a Registrar, but no join proxy. A redirection 418 through a manufacturer or VAR operated register points the device 419 to a Registrar located on the Internet. 421 2. where there is no Registrar (yet), but the network operator does 422 have an RFC7030 EST server. The cloud registrar provides a 423 voucher connecting the pledge to the appropriate EST server. 425 7.5. BRSKY Asynchronous Enrollment 427 BRSKI depends the join proxy being available in the location where 428 the devices are installed, and for that proxy to also be able to 429 communicate to the Registrar (possibly over the Internet). 431 In a number of environments, such as new construction, a number of 432 devices need to go through an onboarding process, but there is no 433 connectivity available. (Possibly not even LTE/3G due to metal 434 walls, lack of towers, etc.). 436 The [I-D.ietf-anima-brski-async-enroll] proposes two amendments to 437 BRSKI: 439 1. the use of CMP rather than EST for enrollment, which eliminates 440 the need to keep a live TLS connection between pledge and 441 Registrar. 443 2. a discovery, store-and-forward mechanism for moving voucher 444 requests and vouchers between the Registrar and Pledge, including 445 a batch mechanism that aims to reduce the amount of walking that 446 an installer might have to do. 448 7.6. 6tisch Zero Touch 450 The 6tisch WG is describing this in 451 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] document. 453 The 6tisch use case consists of very constrained devices with very 454 constrained networks. Code space in the devices is larger than 455 typical class 2, but the devices are typically battery powered and 456 wish to sleep significantly. 458 The use of CBOR for vouchers, COSE to sign the vouchers saves 459 significant network bandwidth and code space. Both CBOR, COSE and 460 OSCORE are typically already in use for the application support. The 461 addition of EDHOC to provide asymmetric bootstrap of OSCORE completes 462 the suite of constrained security protocols. 464 7.7. 6tisch minimal security 466 The 6tisch WG is describing this in 467 [I-D.ietf-6tisch-minimal-security] document. This mechanism does 468 enrollment in a single request/response message, but requires at 469 least one "touch" to pre-share symmetric keys. 471 The 6tisch WG felt that the number of round trips required to do 472 EDHOC, and the size of the vouchers required an even simpler 473 protocol. As existing 6tisch-type technology is typically deployed 474 with network keys built-in at manufacturer time (no "drop-ship"), the 475 switch from a static network key to a PSK for authenticaiton is 476 considered an incremental improvement. 478 All other methods are considered zero "touch". 480 [I-D.ietf-6tisch-minimal-security] is in the RFC-EDITOR Q, waiting 481 for core-stateless on which is depends to leave the WG. 483 8. Discussion 485 A goal of this document is to provide some guidance in selecting 486 which enrollment profile to use for a given scenario. This section 487 tries to provide some constrasting comments between the various 488 mechanisms. 490 (BUT, it does not yet do that..) 492 9. OPEN ISSUE 494 1. insufficient guidance if there is no internet connection. 496 2. classes of devices where the manufacturer will never have an HSM/ 497 PKI. so, it will only be a self-signed key. 499 3. how does a supply-chain manage BRSKI? 501 10. Security Considerations 503 This document includes a tradeoff of the security attributes of the 504 different protocols, and so the entire document contains security 505 advice. 507 11. IANA Considerations 509 This document does not define any new protocols, and therefore does 510 not have any IANA Considerations. 512 12. Acknowledgements 514 TBD 516 13. References 518 13.1. Normative References 520 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 521 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 522 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 523 progress), July 2019. 525 [I-D.ietf-6tisch-minimal-security] 526 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 527 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 528 6tisch-minimal-security-15 (work in progress), December 529 2019. 531 [I-D.ietf-ace-coap-est] 532 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 533 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 534 est-18 (work in progress), January 2020. 536 [I-D.ietf-anima-bootstrapping-keyinfra] 537 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 538 and K. Watsen, "Bootstrapping Remote Secure Key 539 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 540 keyinfra-44 (work in progress), September 2020. 542 [I-D.ietf-anima-constrained-voucher] 543 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 544 Voucher Artifacts for Bootstrapping Protocols", draft- 545 ietf-anima-constrained-voucher-08 (work in progress), July 546 2020. 548 [I-D.ietf-core-object-security] 549 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 550 "Object Security for Constrained RESTful Environments 551 (OSCORE)", draft-ietf-core-object-security-16 (work in 552 progress), March 2019. 554 [I-D.ietf-netconf-zerotouch] 555 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 556 Touch Provisioning (SZTP)", draft-ietf-netconf- 557 zerotouch-29 (work in progress), January 2019. 559 [I-D.selander-ace-cose-ecdhe] 560 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 561 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 562 cose-ecdhe-14 (work in progress), September 2019. 564 [ieee802-1AR] 565 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 566 2009, . 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 575 RFC 5652, DOI 10.17487/RFC5652, September 2009, 576 . 578 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 579 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 580 January 2012, . 582 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 583 "Enrollment over Secure Transport", RFC 7030, 584 DOI 10.17487/RFC7030, October 2013, 585 . 587 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 588 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 589 October 2013, . 591 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 592 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 593 Transport Layer Security (TLS) and Datagram Transport 594 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 595 June 2014, . 597 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 598 RFC 8152, DOI 10.17487/RFC8152, July 2017, 599 . 601 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 602 "A Voucher Artifact for Bootstrapping Protocols", 603 RFC 8366, DOI 10.17487/RFC8366, May 2018, 604 . 606 13.2. Informative References 608 [I-D.friel-anima-brski-cloud] 609 Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI 610 Cloud Registrar", draft-friel-anima-brski-cloud-03 (work 611 in progress), September 2020. 613 [I-D.ietf-anima-autonomic-control-plane] 614 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 615 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 616 plane-29 (work in progress), September 2020. 618 [I-D.ietf-anima-brski-async-enroll] 619 Fries, S., Brockhaus, H., and E. Lear, "Support of 620 asynchronous Enrollment in BRSKI (BRSKI-AE)", draft-ietf- 621 anima-brski-async-enroll-00 (work in progress), July 2020. 623 [I-D.ietf-cose-rfc8152bis-algs] 624 Schaad, J., "CBOR Object Signing and Encryption (COSE): 625 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 626 (work in progress), September 2020. 628 [I-D.ietf-cose-rfc8152bis-struct] 629 Schaad, J., "CBOR Object Signing and Encryption (COSE): 630 Structures and Process", draft-ietf-cose-rfc8152bis- 631 struct-14 (work in progress), September 2020. 633 [I-D.ietf-lake-edhoc] 634 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 635 Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- 636 edhoc-01 (work in progress), August 2020. 638 [I-D.richardson-anima-state-for-joinrouter] 639 Richardson, M., "Considerations for stateful vs stateless 640 join router in ANIMA bootstrap", draft-richardson-anima- 641 state-for-joinrouter-03 (work in progress), September 642 2020. 644 [I-D.selander-ace-ake-authz] 645 Selander, G., Mattsson, J., Vucinic, M., Richardson, M., 646 and A. Schellenbaum, "Lightweight Authorization for 647 Authenticated Key Exchange.", draft-selander-ace-ake- 648 authz-01 (work in progress), March 2020. 650 [I-D.vanderstok-anima-constrained-join-proxy] 651 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 652 Join Proxy for Bootstrapping Protocols", draft-vanderstok- 653 anima-constrained-join-proxy-04 (work in progress), 654 September 2020. 656 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 657 . 659 Author's Address 661 Michael Richardson 662 Sandelman Software Works 664 Email: mcr+ietf@sandelman.ca