idnits 2.17.1 draft-ietf-6tisch-dtsecurity-zerotouch-join-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-anima-constrained-voucher], [I-D.ietf-6tisch-minimal-security]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 247 has weird spacing: '... pledge the p...' == Line 251 has weird spacing: '...ed Node the p...' == 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 (July 08, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ieee802154' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'ieee802159' is defined on line 1156, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-11 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-12 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-22 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-04 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-13 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-19 Summary: 1 error (**), 0 flaws (~~), 12 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 July 08, 2019 5 Expires: January 9, 2020 7 6tisch Zero-Touch Secure Join protocol 8 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 10 Abstract 12 This document describes a Zero-touch Secure Join (ZSJ) mechanism to 13 enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network 14 using the 6tisch signaling mechanisms. The resulting device will 15 obtain a domain specific credential that can be used with either 16 802.15.9 per-host pair keying protocols, or to obtain the network- 17 wide key from a coordinator. The mechanism describe here is an 18 augmentation to the one-touch mechanism described in 19 [I-D.ietf-6tisch-minimal-security], and is a profile of the 20 constrained voucher mechanism [I-D.ietf-anima-constrained-voucher]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 9, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 5 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 6 60 1.4. Leveraging the new key infrastructure / next steps . . . 7 61 1.4.1. Key Distribution Process . . . . . . . . . . . . . . 7 62 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 7 63 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 7 64 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 9 65 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 9 66 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 10 67 2.5. Architectural Components . . . . . . . . . . . . . . . . 12 68 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 12 69 2.5.2. Stateless IPIP Join Proxy . . . . . . . . . . . . . . 12 70 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 12 71 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 12 72 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 12 73 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 13 74 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 13 75 2.8. Determining the MASA to contact . . . . . . . . . . . . . 13 76 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 13 77 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 13 78 5. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 14 80 5.2. HTTPS proxy connection to Registrar . . . . . . . . . . . 14 81 5.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 14 82 6. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 15 83 6.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 15 84 6.1.1. BRSKI-EST CoAP estasblishment details . . . . . . . . 15 85 6.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 15 86 6.2. Pledge Requests Voucher from the Registrar . . . . . . . 17 87 6.3. Registrar Requests Voucher from MASA . . . . . . . . . . 17 88 6.3.1. MASA renewal of expired vouchers . . . . . . . . . . 18 89 6.3.2. MASA verification of voucher-request signature 90 consistency . . . . . . . . . . . . . . . . . . . . . 18 91 6.3.3. MASA authentication of registrar (certificate) . . . 18 92 6.3.4. MASA revocation checking of registrar (certificate) . 18 93 6.3.5. MASA verification of pledge prior-signed-voucher- 94 request . . . . . . . . . . . . . . . . . . . . . . . 18 95 6.3.6. MASA pinning of registrar . . . . . . . . . . . . . . 19 96 6.3.7. MASA nonce handling . . . . . . . . . . . . . . . . . 19 98 6.4. MASA Voucher Response . . . . . . . . . . . . . . . . . . 19 99 6.4.1. Pledge voucher verification . . . . . . . . . . . . . 19 100 6.4.2. Pledge authentication of provisional TLS connection . 20 101 6.5. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 20 102 6.6. Registrar audit log request . . . . . . . . . . . . . . . 20 103 6.6.1. MASA audit log response . . . . . . . . . . . . . . . 20 104 6.6.2. Registrar audit log verification . . . . . . . . . . 20 105 6.6.3. EST CSR Attributes . . . . . . . . . . . . . . . . . 20 106 6.6.4. EST Client Certificate Request . . . . . . . . . . . 20 107 6.6.5. Enrollment Status Telemetry . . . . . . . . . . . . . 21 108 6.6.6. Multiple certificates . . . . . . . . . . . . . . . . 21 109 6.6.7. EST over CoAP . . . . . . . . . . . . . . . . . . . . 21 110 6.7. Use of Secure Transport for Minimal Join . . . . . . . . 21 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 112 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 113 8.1. Privacy Considerations for Production network . . . . . . 22 114 8.2. Privacy Considerations for New Pledges . . . . . . . . . 22 115 8.2.1. EUI-64 derived address for join time IID . . . . . . 23 116 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 117 9.1. Security of MASA voucher signing key(s) . . . . . . . . . 23 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 120 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 121 11.2. Informative References . . . . . . . . . . . . . . . . . 26 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 124 1. Introduction 126 Enrollment of new nodes into LLNs present unique challenges. The 127 constrained nodes has no user interfaces, and even if they did, 128 configuring thousands of such nodes manually is undesireable from a 129 human resources issue, as well as the difficulty in getting 130 consistent results. 132 This document is about a standard way to introduce new nodes into a 133 6tisch network that does not involve any direct manipulation of the 134 nodes themselves. This act has been called "zero-touch" 135 provisioning, and it does not occur by chance, but requires 136 coordination between the manufacturer of the node, the service 137 operator running the LLN, and the installers actually taking the 138 devices out of the shipping boxes. 140 The mechanism described in [I-D.ietf-anima-bootstrapping-keyinfra] 141 has been adapted in [I-D.ietf-anima-constrained-voucher] to produce a 142 protocol that is suited for constrained devices and constrained 143 networks such as 6tisch. The above document/protocol is referred by 144 by it's acronym: BRSKI and constrained-BRSKI. The pronounciation of 145 which is "brew-ski", a common north american slang for beer with a 146 pseudo-polish ending. This constrained protocol is called Zero-touch 147 Secure Join. 149 This document is a profile of [I-D.ietf-anima-constrained-voucher]. 150 It uses COSE signatures of CBOR voucher [RFC8366] artifacts, and it 151 uses [I-D.selander-ace-cose-ecdhe] as a Lightweight authenticated key 152 exchange protocol. 154 [I-D.ietf-anima-constrained-voucher] has options for CMS signatures 155 of CBOR vouchers, and for using DTLS. The protocol described in this 156 document does not make use those options. 158 Like [I-D.ietf-anima-bootstrapping-keyinfra], the networks which are 159 in scope for this protocol are deployed by a professional operator. 160 The deterministic mechanisms which have been designed into 6tisch 161 have been created to satisfy the operational needs of industrial 162 settings where such an operator exists. 164 This document builds upon the "one-touch" provisioning described in 165 [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request 166 mechanism when appropriate, but preceeding it with the EDHOC key 167 agreement protocol. 169 As a second option, a certificate may be deployed using the 170 constrained version of [RFC7030] EST described in 171 [I-D.ietf-ace-coap-est]. 173 Otherwise, this document follows BRSKI with the following high-level 174 changes: 176 o HTTP is replaced with CoAP. 178 o TLS (HTTPS) is replaced with EDHOC/OSCOAP+CoAP 180 o the domain-registrar anchor certificate is replaced with a Raw 181 Public Key (RPK) using [RFC7250]. 183 o the PKCS7 signed JSON voucher format is replaced with COSE 184 signature 186 o the GRASP discovery mechanism for the Proxy is replaced with an 187 announcement in the Enhanced Beacon 188 [I-D.richardson-6tisch-join-enhanced-beacon] 190 o the TCP circuit proxy mechanism is not used. The CoAP based 191 stateless proxy mechanism described in 192 [I-D.ietf-6tisch-minimal-security] section 7.1 is used. 194 o real time clocks are assumed to be unavailable, so expiry dates in 195 ownership vouchers are never used 197 o nonce-full vouchers are encouraged, but off-line nonce-less 198 operation is also supported, however, the resulting vouchers would 199 have infinite life. 201 802.1AR Client certificates are retained, but optionally are 202 specified by reference rather than value (Work in Progress). 204 It is expected that the back-end network operator infrastructure 205 would be able to bootstrap ANIMA BRSKI-type devices over ethernet, 206 while also being able bootstrap 6tisch devices over 802.15.4 with few 207 changes. 209 1.1. Prior Bootstrapping Approaches 211 Constrained devices as used in industrial control systems are usually 212 installed (or replaced) by technicians with expertise in the 213 equipment being serviced, not in secure enrollment of devices. 215 Devices therefore are typically pre-configured in advance, marked for 216 a particular factory, assembly line, or even down to the specific 217 machine. It is not uncommon for manufacturers to have a unique 218 product (stock keeping unit -SKU) for each customer as the part will 219 be loaded with customer specifc security configuration. The 220 resulting customer-specific parts are hard to inventory and very 221 expensive to provide spares for. Should a part be delivered to the 222 wrong customer, determining the reason for inability to configure is 223 difficult and time consuming. 225 End-user actions to configure the part at the time of installation, 226 aside from being error prone, also suffer from requiring a part that 227 has a user interface. 229 1.2. Terminology 231 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 232 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 233 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 234 [RFC2119] and indicate requirement levels for compliant STuPiD 235 implementations. 237 The reader is expected to be familiar with the terms and concepts 238 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 239 [I-D.ietf-core-object-security], 240 [I-D.ietf-anima-bootstrapping-keyinfra] and 241 [I-D.ietf-anima-constrained-voucher]. The following terms are 242 imported: drop ship, imprint, enrollment, pledge, join proxy, 243 ownership voucher, and join registrar/coordinator (JRC). The 244 following terms are repeated here for readability, but this document 245 is not authoritative for their definition: 247 pledge the prospective device, which has the identity provided to at 248 the factory. Neither the device nor the network knows if the 249 device yet knows if this device belongs with this network. 251 Joined Node the prospective device, after having completing the join 252 process, often just called a Node. 254 Join Proxy (JP): a stateless relay that provides connectivity 255 between the pledge and the join registrar/coordinator. 257 Join Registrar/Coordinator (JRC): central entity responsible for 258 authentication and authorization of joining nodes. 260 Audit Token A signed token from the manufacturer authorized signing 261 authority indicating that the bootstrapping event has been 262 successfully logged. This has been referred to as an 263 "authorization token" indicating that it authorizes bootstrapping 264 to proceed. 266 Ownership Voucher A signed voucher from the vendor vouching that a 267 specific domain "owns" the new entity as defined in 268 [I-D.ietf-anima-voucher]. 270 MIC manufacturer installed certificate. An [ieee802-1AR] identity. 271 Not to be confused with a (cryptographic) "Message Integrity 272 Check" 274 1.3. Scope of solution 276 The solution described in this document is appropriate to enrolling 277 between hundreds to hundreds of thousands of diverse devices into a 278 network without any prior contact with the devices. The devices 279 could be shipped by the manufacturer directly to the customer site 280 without ever being seen by the operator of the network. As described 281 in BRSKI, in the audit-mode of operation the device will be claimed 282 by the first network that sees it. In the tracked owner mode of 283 operation, sales channel integration provides a strong connection 284 that the operator of the network is the legitimate owner of the 285 device. 287 BRSKI describes a more general, more flexible approach for 288 bootstrapping devices into an ISP or Enterprise network. 290 [I-D.ietf-6tisch-minimal-security] provides an extremely streamlined 291 approach to enrolling from hundreds to thousands of devices into a 292 network, provided that a unique secret key can be installed in each 293 device. 295 1.4. Leveraging the new key infrastructure / next steps 297 In constrained networks, it is unlikely that an ACP be formed. This 298 document does not preclude such a thing, but it is not mandated. 300 The resulting secure channel SHOULD be used just to distribute 301 network-wide keys using a protocol such as 302 [I-D.ietf-6tisch-minimal-security]. 304 As a more complex, but but more secure alternative the resulting 305 secure channel MAY be instead used to do an enrollment of an LDevID 306 as in BRSKI. The resulting certificate is used to do per-pair keying 307 such as described by {{ieee802159}. 309 XXX - this document does not yet provide a way to signal which mode 310 the pledge should do. 312 1.4.1. Key Distribution Process 314 In addition to being used for the initial enrollment process, the 315 secure channel SHOULD be kept open to use for network rekeying. The 316 CoJP protocol described in [I-D.ietf-6tisch-minimal-security] 317 includes a mechanism for rekeys in section 8.4.3.1. 319 2. Architectural Overview 321 Section 2 of BRSKI has a diagram with all of the components shown 322 together. There are no significant changes to the diagram. 324 The use of a circuit proxy is not desireable. The CoAP based 325 stateless proxy mechanism described in 326 [I-D.ietf-6tisch-minimal-security] section 7.1 MUST be used. 328 2.1. Behavior of a Pledge 330 The pledge goes through a series of steps which are outlined here at 331 a high level. 333 +--------------+ 334 | Factory | 335 | default | 336 +------+-------+ 337 | 338 +------v-------+ 339 | (1) Discover | 340 +------------> | 341 | +------+-------+ 342 | | 343 | +------v-------+ 344 | | (2) Identity | 345 ^------------+ | 346 | rejected +------+-------+ 347 | | 348 | +------v-------+ 349 | | (3) Request | 350 | | Join | 351 | +------+-------+ 352 | | 353 | +------v-------+ 354 | | (4) Imprint | 355 ^------------+ | 356 | Bad MASA +------+-------+ 357 | response | send Voucher Status Telemetry 358 | +------v-------+ 359 | | (5) Enroll | 360 ^------------+ | 361 | Enroll +------+-------+ 362 | Failure | 363 | +------v-------+ 364 | | (6) Enrolled | 365 ^------------+ | 366 Factory +--------------+ 367 reset 369 State descriptions for the pledge are as follows: 371 1. Discover a communication channel to a Registrar. This is done by 372 listening for beacons as described by 373 [I-D.richardson-anima-6join-discovery] 375 2. Identify itself. This is done by presenting an X.509 IDevID 376 credential to the discovered Registrar (via the Proxy) in the 377 EDHOC handshake. The certificate MAY be presented by reference. 378 (The Registrar credentials are only provisionally accepted at 379 this time). 381 The registrar identifies itself using a raw public key, while the 382 the pledge identifies itself to the registrar using an IDevID 383 credential. 385 3. Requests to Join the discovered Registrar. A unique nonce SHOULD 386 be included ensuring that any responses can be associated with 387 this particular bootstrapping attempt. 389 4. Imprint on the Registrar. This requires verification of the 390 vendor service (MASA) provided voucher. A voucher contains 391 sufficient information for the Pledge to complete authentication 392 of a Registrar. The voucher is signed by the vendor (MASA) using 393 a raw public key, previously installed into the pledge at 394 manufacturing time. 396 5. Optionally Enroll. By accepting the domain specific information 397 from a Registrar, and by obtaining a domain certificate from a 398 Registrar using a standard enrollment protocol, e.g. Enrollment 399 over Secure Transport (EST) [RFC7030]. 401 6. The Pledge is now a member of, and can be managed by, the domain 402 and will only repeat the discovery aspects of bootstrapping if it 403 is returned to factory default settings. 405 2.2. Secure Imprinting using Vouchers 407 As in BRSKI, there is a voucher mechanism based upon [RFC8366]. The 408 format and cryptographic mechansim of the constrained vouchers is 409 described in detail in [I-D.ietf-anima-constrained-voucher]. 411 COSE signed vouchers and voucher-requests are MANDATORY. 413 2.3. Initial Device Identifier 415 The essential component of the zero-touch operation is that the 416 pledge is provisioned with an 802.1AR (PKIX) certificate installed 417 during the manufacturing process. 419 It is expected that constrained devices will use a signature 420 algorithm corresponding to the hardware acceleration that they have, 421 if they have any. The anticipated initial algorithms are the ECDSA 422 P-256 (secp256v1). Newer devices SHOULD begin to appear using EdDSA 423 curves using the 25519 curves. 425 The manufacturer will always know what algorithms are available in 426 the Pledge, and will use an appropriate one. The other components 427 that need to evaluate the IDevID (the Registrar and MASA) are 428 expected to support all common algorithms. 430 The JRC is expected to be an easily updated appliance that can learn 431 about new algorithms with a regular maintenance cycle. 433 There are a number of simplications detailed later on in this 434 document designed to eliminate the need for an ASN.1 parser in the 435 pledge. 437 The pledge should consider it's 802.1AR certificate to be an opaque 438 blob of bytes, to be inserted into protocols at appropriate places. 439 The pledge SHOULD have access to the underlying public and private 440 keys in the most useable native format for computation. 442 The pledge MUST have the public key of the MASA built in a 443 manufacturer time. This protocol optimizes for network bandwidth, 444 and does not transfer the public key or certificate chain used to 445 validate the voucher in-band. 447 This is a seemingly identical requirement as for BRSKI, but rather 448 than being an abstract trust anchor that can be augmented with a 449 certificate chain, the pledge MUST be provided with the Raw Public 450 Key that the MASA will use to sign vouchers for that pledge. 452 This use of a direct key has drawbacks, section Section 9.1 addresses 453 some of them with some operational suggestions. 455 BRSKI places some clear requirements upon the contents of the IDevID, 456 but leaves the exact origin of the voucher serial-number open. This 457 document restricts the process to being the hwSerialNum OCTET STRING. 458 As CWT can handle binary formats, no base64 encoding is necessary. 460 The MASA-URL extension MANDATORY. The inclusion of a MUD URL 461 [RFC8520] is strongly recommended. 463 EDNOTE: here belongs text about sending only a reference to the 464 IDevID rather than the entire certificate 466 2.4. Protocol Flow 468 This diagram from BRSKI is reproduced with some edits: 470 +--------+ +---------+ +------------+ +------------+ 471 | Pledge | | IPIP | | Domain | | Vendor | 472 | | | Proxy | | Registrar | | Service | 473 | | | | | (JRC) | | (MASA) | 474 +--------+ +---------+ +------------+ +------------+ 475 | | | | 476 |<-RFC4862 IPv6 adr | | | 477 | | | | 478 |<--------------------| | | 479 | Enhanced Beacon | | | 480 | periodic broadcast| | | 481 | | | | 482 |<------------------->C<----------------->| | 483 |<--Registrar EDHOC server authentication-| | 484 [PROVISIONAL accept of server RPK ] | | 485 P-------- client authentication---------->| | 486 P | | | 487 P---Voucher Request (include nonce)------>| | 488 P | | | 489 P | | | 490 P | [accept device?] | 491 P | [contact Vendor] | 492 P | |--Pledge ID-------->| 493 P | |--Domain ID-------->| 494 P | |--nonce------------>| 495 P | | [extract DomainID] 496 P | | | 497 P | | [update audit log] 498 P | | | 499 P | | | 500 P | | | 501 P | | | 502 P | | | 503 P | |<-device audit log--| 504 P | |<- voucher ---------| 505 P | | | 506 P | | | 507 P | [verify audit log and voucher] | 508 P | | | 509 P<------voucher---------------------------| | 510 [verify voucher ] | | | 511 [verify provisional cert| | | 512 | | | | 513 |<--------------------------------------->| | 514 | Continue with EST-COAPS enrollment | | 515 | using now bidirectionally authenticated | | 516 | | | | 517 |<--------------------------------------->| | 518 | Use 6tisch-minimal-security join request | 520 Noteable changes are: 522 1. no IPv4 support/options. 524 2. no mDNS steps, 6tisch only uses Enhanced Beacon 525 3. nonce-full option is always mandatory 527 2.5. Architectural Components 529 The bootstrap process includes the following architectural 530 components: 532 2.5.1. Pledge 534 The Pledge is the device which is attempting to join. Until the 535 pledge completes the enrollment process, it has network connectivity 536 only to the Proxy. 538 2.5.2. Stateless IPIP Join Proxy 540 The stateless CoAP provides CoAP connectivity between the pledge and 541 the registrar. The stateless CoAP proxy mechanism is described in 542 [I-D.ietf-6tisch-minimal-security]. 544 2.5.3. Domain Registrar 546 The Domain Registrar (having the formal name Join Registrar/ 547 Coordinator (JRC)), operates as a CMC Registrar, terminating the 548 CoAP-EST and BRSKI connections. The Registrar is manually configured 549 or distributed with a list of trust anchors necessary to authenticate 550 any Pledge device expected on the network. The Registrar 551 communicates with the Vendor supplied MASA to establish ownership. 553 The JRC is typically located on the 6LBR/DODAG root, but it may be 554 located elsewhere, provided IP level connectivity can be established. 555 The 6LBR may also provide a proxy or relay function to connect to the 556 actual registrar in addition to the IPIP proxy described above. The 557 existence of such an additional proxy is a private matter, and this 558 documents assumes without loss of generality that the registrar is 559 co-located with the 6LBR. 561 2.5.4. Manufacturer Service 563 The Manufacturer Service provides two logically seperate functions: 564 the Manufacturer Authorized Signing Authority (MASA), and an 565 ownership tracking/auditing function. This function is identical to 566 that used by BRSKI, except that a different format voucher is used. 568 2.6. Certificate Time Validation 569 2.6.1. Lack of realtime clock 571 For the constrained situation it is assumed that devices have no real 572 time clock. These nodes do have access to a monotonically increasing 573 clock that will not go backwards in the form of the Absolute Sequence 574 Number. Synchronization to the ASN is required in order to transmit/ 575 receive data and most nodes will maintain it in hardware. 577 The heuristic described in BRSKI under this section SHOULD be applied 578 if there are dates in the COSE format voucher. 580 Voucher requests SHOULD include a nonce. For devices intended for 581 off-line deployment, the vouchers will have been generated in advance 582 and no nonce-ful operation will not be possible. 584 2.7. Cloud Registrar 586 In 6tisch, the pledge never has network connectivity until it is 587 enrolled, so no alternate registrar is ever possible. 589 2.8. Determining the MASA to contact 591 There are no changes from BRSKI: the IDevID provided by the pledge 592 will contain a MASA URL extension. 594 3. Voucher-Request artifact 596 The voucher-request artifact is defined in 597 [I-D.ietf-anima-constrained-voucher] section 6.1. 599 For the 6tisch ZSJ protocol defined in this document, only COSE 600 signed vouchers as described in [I-D.ietf-anima-constrained-voucher] 601 section 6.3.2 are supported. 603 4. Proxying details (Pledge - Proxy - Registrar) 605 The voucher-request artifact is defined in 606 [I-D.ietf-anima-constrained-voucher]. 608 The 6tisch use of the constrained version differs from the non- 609 constrained version in two ways: 611 1. it does not include the proximity-registrar-cert, but rather uses 612 the proximity-registrar-subjet-public-key-info entry. This 613 accomodates the use of a raw public key to identify the 614 registrar. 616 2. the pledge uses the proximity-registrar-subject-public-key-info 617 to verify the raw public key for the JRC. 619 An appendix of [I-D.ietf-anima-constrained-voucher] shows example 620 requests and responses. 622 5. Proxy details 624 The role of the Proxy is to facilitate communication. In the 625 constrained situation the proxy needs to be stateless as there is 626 very little ram in constrained nodes, and none can be allocated to 627 keep state for an unlimited number of potential pledges. 629 5.1. Pledge discovery of Proxy 631 In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD 632 messages sent by the proxy. In 6tisch ZSJ, the existence of the 633 proxy is announced by the Enhanced Beacon message described in 634 [I-D.richardson-6tisch-enrollment-enhanced-beacon]. The proxy as 635 described by [I-D.ietf-6tisch-minimal-security] section 10 is to be 636 used in an identical fashion when EDHOC and OSCOAP are used. 638 5.2. HTTPS proxy connection to Registrar 640 HTTPS connections are not used between the Pledge, Proxy and 641 Registrar. The Proxy relays CoAP packets and does not interpret or 642 terminate CoAP connections. 644 HTTPS is still used between the Registrar and MASA! 646 5.3. Proxy discovery of Registrar 648 In BRSKI, the proxy autonomically discovers the Registrar by 649 listening for GRASP messages. 651 In the constrained network, the proxies are optionally configured 652 with the address of the JRC by the Join Response in in 653 [I-D.ietf-6tisch-minimal-security] section 9.3.2. (As described in 654 that section, the address of the registrar otherwise defaults to be 655 that of the DODAG root) 657 Whether or not a 6LR will announce itself as a possible Join Proxy is 658 outside the scope of this document. 660 6. Protocol Details (Pledge - Registrar - MASA) 662 BRSKI is specified to run over HTTPS. This document respecifies it 663 to run over CoAP with either DTLS or EDHOC-provided OSCOAP security. 665 BRSKI introduces the concept of a provisional state for EST. 667 [I-D.ietf-ace-coap-est] specifies that CoAP specifies the use of CoAP 668 Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at 669 the application layer. 671 As in [I-D.ietf-ace-coap-est], support for Observe CoAP options 672 [RFC7641] with BRSKI is not supported in the current BRSKI/EST 673 message flows. 675 Observe options could be used by the server to notify clients about a 676 change in the cacerts or csr attributes (resources) and might be an 677 area of future work. 679 Redirection as described in [RFC7030] section 3.2.1 is NOT supported. 681 6.1. BRSKI-EST (D)TLS establishment details 683 6tisch ZSJ does not use TLS. The connection is CoAP with EDHOC 684 security. 686 6.1.1. BRSKI-EST CoAP estasblishment details 688 The details in the BRSKI document apply directly to use of DTLS. 690 The registrar SHOULD authenticate itself with a raw public key. A 691 256 bit ECDSA raw public key is RECOMMENDED. Pledges SHOULD support 692 EDDSA keys if they contain hardware that supports doing so 693 efficiently. 695 TBD: the Pledge needs to signal what kind of Raw Public Key it 696 supports before the Registrar sends its ServerCertificate. Can SNI 697 be used to do this? 699 The pledge SHOULD authenticate itself with the built-in IDevID 700 certificate as a ClientCertificate. 702 6.1.2. BRSKI-EST CoAP/EDHOC estasblishment details 704 [I-D.selander-ace-cose-ecdhe] details how to use EDHOC. The EDHOC 705 description identifiers a party U (the initiator), and a party V. 706 The Pledge is the party U, and the JRC is the party V. 708 The communication from the Pledge is via CoAP via the Join Proxy. 709 The Join proxy relays traffic to the JRC, and using the mechanism 710 described in [I-D.ietf-6tisch-minimal-security] section 5.1. This is 711 designed so that the Join Proxy does not need to know if it is 712 performing the one-touch enrollment described in 713 [I-D.ietf-6tisch-minimal-security] or the zero-touch enrollment 714 protocol described in this document. A network could consist of a 715 mix of nodes of each type. 717 As generating ephemeral keys is expensive for a low-resource Pledge, 718 the use of a common E_U by the Pledge for multiple enrollment 719 attempts (should the first turn out to be the wrong network) is 720 encouraged. 722 The first communication detailed in [I-D.ietf-ace-coap-est] is to 723 query the "/.well-known/core" resource to request the Link for EST. 724 This is where the initial CoAP request is to sent. 726 The JRC MAY replace it's E_V ephermal key on a periodic basis, or 727 even for every communication session. 729 The Pledge's ID_U is the Pledge's IDevID. It is transmitted in an 730 x5bag [I-D.schaad-cose-x509]. An x5u (URL) MAY be used. An x5t 731 (hash) MAY also be used and would be the smallest, but the Registrar 732 may not know where to find the Pledge's IDevID unless the JRC has 733 been preloaded will all the IDevIDs via out-of-band mechanism. It is 734 impossible for the Pledge to know if the JRC has been loaded in such 735 a way so x5t is discouraged for general use. 737 The JRC's ID_V is the JRC's Raw Public Key. It is transmitted as a 738 key in COSE's YYY parameter. 740 The initial Mandatory to Implement (MTI) of an HKDF of SHA2-256, an 741 AEAD based upon AES-CCM-16-64-128, a signature verification of 742 TBD:BBBB, and signature generation of TBD:BBBB. The Pledge proposes 743 a set of algorithms that it supports, and Pledge need not support 744 more than one combination. 746 JRCs are expected to run on non-constrained servers, and are expected 747 to support the above initial as MTI, and any subsequent ones that 748 become common. 750 A JRC SHOULD support all available algorithms for a significant 751 amount of time. 753 Even when algorithms become weak or suspect, it is likely that it 754 will still have to perform secure join for older devices. A JRC that 755 responds to such an older device might not in the end accept the 756 device into the network, but it is important that it be able to audit 757 the event and communicate the event to an operator. 759 While EDHOC supports sending additional data in the message_3, in the 760 constrained network situation, it is anticipated that the size of the 761 this message will already be large, and no additional data is to be 762 sent. 764 A COAP confirmable message SHOULD be used. 766 [I-D.ietf-6tisch-minimal-security] section 6 details how to setup 767 OSCORE context given a shared key derived by EDHOC. 769 The registrar SHOULD authenticate itself with a raw public key. 771 The pledge SHOULD authenticate itself with the built-in IDevID 772 certificate. 774 6.2. Pledge Requests Voucher from the Registrar 776 The voucher request and response as defined by BRSKI is modified 777 slightly. 779 In order to simplify the pledge, the use of a certificate (and chain) 780 for the Registrar is not supported. Instead the newly defined 781 proximity-registrar-subject-public-key-info must contain the (raw) 782 public key info for the Registrar. It MUST be byte for byte 783 identical to that which is transmitted by the Registrar during the 784 TLS ServerCertificate handshake. 786 BRSKI mandates that all voucher requests be signed. 788 6.3. Registrar Requests Voucher from MASA 790 There are no change from BRSKI, as this step is between two non- 791 constrained devices. 793 The format of the voucher-request and voucher response is COSE, which 794 implies changes to both the Registrar and the MASA, but semantically 795 the content is the same. 797 The manufacturer will know what algorithms are supported by the 798 pledge, and will issue a 406 (Conflict) error to the Registrar if the 799 Registar's public key format is not supported by the pledge. It is 800 however, too late for the Registar to use a different key, but at 801 least it can log a reason for a failure. 803 It is likely that the ZSJ-BRSKI-EST connection has already failed, 804 and this step is never reached. 806 6.3.1. MASA renewal of expired vouchers 808 There are assumed to be no useful real-time clocks on constrained 809 devices, so all vouchers are in effect infinite duration. Pledges 810 will use nonces for freshness, and a request for a new voucher with a 811 new voucher for the same Registrar is not unusual. 813 A token-bucket system SHOULD be used such that no more than 24 814 vouchers are issued per-day, but more than one voucher can be issued 815 in a one hour period. Tokens should not accumulate for more than one 816 day. 818 6.3.2. MASA verification of voucher-request signature consistency 820 The voucher-request is signed by the Registrar using it's Raw Public 821 Key. There is no additional certificate authority to sign this key. 822 The MASA MAY have this key via sales-channel integration, but in most 823 cases it will be seeing the key for the first time. 825 XXX-should the TLS connection from Registrar to MASA have a 826 ClientCertificate? If so, then should it use the same Public Key? 827 Or a different one? 829 6.3.3. MASA authentication of registrar (certificate) 831 IDEA: The MASA SHOULD pin the Raw Public Key (RPK) to the IP address 832 that was first used to make a request with it. Should the RPK <-> IP 833 address relationship be 1:1, 1:N, N:1? Should we take IP address to 834 mean, "IP subnet", essentially the IPv4/24, and IPv6/64? The value 835 of doing is about DDoS mitigation? 837 Should above mapping be on a per-Pledge basis? 839 6.3.4. MASA revocation checking of registrar (certificate) 841 As the Registrar has a Raw Public Key as an identity, there is no 842 meaningful standard revocation checking that can be done. The MASA 843 SHOULD have a blacklist table, and a way to add entries, but this 844 process is out of scope. 846 6.3.5. MASA verification of pledge prior-signed-voucher-request 848 The Registrar will put the signed pledge voucher-request into it's 849 voucher-request as 'prior-signed-voucher-request'. The MASA can 850 verify the signature from the Pledge using the MASA's copy of the 851 Pledge's IDevID public key. 853 6.3.6. MASA pinning of registrar 855 When the MASA creates a voucher, it puts the Registrar's Raw Public 856 Key into the 'pinned-domain-subject-public-key-info' leaf of the 857 voucher. 859 The MASA does not include the 'pinned-domain-cert' field in such 860 vouchers. 862 6.3.7. MASA nonce handling 864 Use of nonces is highly RECOMMENDED, but there are situations where 865 not all components are connected at the same time in which the nonce 866 will not be present. 868 There are no significant changes from BRSKI. 870 6.4. MASA Voucher Response 872 As exaplained in [I-D.ietf-anima-constrained-voucher] section 6.3.2, 873 when a voucher is returned by the MASA to the JRC, a public key or 874 certificate container that will verify the voucher SHOULD also be 875 returned. 877 In order to do this, the MASA MAY return a multipart/related return, 878 within that body, two items SHOULD be returned: 880 1. An application/voucher-cose+cbor body. 882 2. An application/TBD:SOMETHING containing a Raw Public Key. 884 A MASA is not obligated to return the public key, and MAY return only 885 the application/voucher-cose+cbor object. In that case, the JRC will 886 be unable to validate it, and will have to just audit the contents. 888 6.4.1. Pledge voucher verification 890 The Pledge receives the voucher from the Registrar over it's CoAP 891 connection. It verifies the signature using the MASA anchor built 892 in, as in the BRSKI case. 894 6.4.2. Pledge authentication of provisional TLS connection 896 The BRSKI process uses the pinned-domain-cert field of the voucher to 897 validate the registrar's ServerCertificate. In the ZeroTouch case, 898 the voucher will contain a pinned-domain-subject-public-key-info 899 field containing the raw public key of the certificate. It should 900 match, byte-to-byte with the raw public key ServerCertificate. 902 6.5. Pledge Voucher Status Telemetry 904 The voucher status telemetry report is communicated from the pledge 905 to the registrar over CoAP channel. The shortened URL is as 906 described in table QQQ. 908 6.6. Registrar audit log request 910 There are no changes to the Registrar audit log request. 912 6.6.1. MASA audit log response 914 There are no changes to the MASA audit log response. 916 6.6.2. Registrar audit log verification 918 There are no changes to how the Registrar verifies the audit log. 920 6.6.3. EST CSR Attributes 922 In 6tisch, no Autonomic Control Plane will be created, so none of the 923 criteria for SubjectAltname found in 924 [I-D.ietf-anima-autonomic-control-plane] apply. 926 The CSR Attributes request SHOULD NOT be performed. 928 6.6.4. EST Client Certificate Request 930 6tisch will use a certificate to: 932 1. to authenticate an 802.15.9 key agreement protocol. 934 2. to terminate an incoming DTLS or EDHOC key agreement as part of 935 application data protection. 937 It is recommended that the requested subjectAltName contain only the 938 [RFC4514] hwSerialNum. 940 6.6.5. Enrollment Status Telemetry 942 There are no changes to the status telemetry between Registrar and 943 MASA. 945 6.6.6. Multiple certificates 947 Multiple certificates are not supported. 949 6.6.7. EST over CoAP 951 This document and [I-D.ietf-ace-coap-est] detail how to run EST over 952 CoAP. 954 6.7. Use of Secure Transport for Minimal Join 956 Rather than bootstrap to a public key infrastructure, the secure 957 channel MAY instead be for the minimal security join process 958 described in [I-D.ietf-6tisch-minimal-security]. 960 The desire to do a minimal-security join process is signaled by the 961 Registrar in it's voucher-request by including a 'join-process' value 962 of 'minimal'. The MASA copies this value into the voucher that is 963 creates, and also logs this to the audit log. 965 When the secure channel was created with EDHOC, then the keys setup 966 by EDHOC are simply used by OSCORE exactly as if they had been Pre- 967 Shared. The keys derived by EDHOC SHOULD be stored by both Registrar 968 and Pledge as their long term key should the join process need to be 969 repeated. 971 7. IANA Considerations 973 No specific requests are made 975 8. Privacy Considerations 977 [I-D.ietf-6lo-privacy-considerations] details a number of privacy 978 considerations important in Resource Constrained nodes. There are 979 two networks and three sets of constrained nodes to consider. They 980 are: 1. the production nodes on the production network. 2. the new 981 pledges, which have yet to enroll, and which are on a join network. 982 3. the production nodes which are also acting as proxy nodes. 984 8.1. Privacy Considerations for Production network 986 The details of this are out of scope for this document. 988 8.2. Privacy Considerations for New Pledges 990 New Pledges do not yet receive Router Advertisements with PIO 991 options, and so configure link-local addresses only based upon 992 layer-2 addresses using the normal SLAAC mechanisms described in 993 [RFC4191]. 995 These link-local addresses are visible to any on-link eavesdropper 996 (who is synchronized to the same Join Assistant), so regardless of 997 what is chosen they can be seen. This link-layer traffic is 998 encapsulated by the Join Proxy into IPIP packets and carried to the 999 JRC. The traffic SHOULD never leave the operator's network, will be 1000 kept confidential by the layer-2 keys inside the LLN. As no outside 1001 traffic can enter the join network, to do any ICMP scanning as 1002 described in [I-D.ietf-6lo-privacy-considerations]. 1004 The join process described herein requires that some identifier 1005 meaningful to the network operator be communicated to the JRC. The 1006 join request with this object occurs within a secured CoAP channel, 1007 although the link-local address configured by the pledge will be 1008 visible in either the CoAP stateless proxy option (section 5.1 of 1009 [I-D.ietf-6tisch-minimal-security]), or in the equivalent DTLS 1010 stateless proxy option (reference TBD). 1012 This need not be a manufacturer created EUI-64 as assigned by IEEE; 1013 it could be another value with higher entropy and less interesting 1014 vendor/device information. Regardless of what is chosen, it can be 1015 used to track where the device attaches. 1017 For most constrained device, network attachment occurs very 1018 infrequently, often only once in their lifetime, so tracking 1019 opportunities may be rare. Once connected, the long 8-byte EUI64 1020 layer-2 address is usually replaced with a short JRC assigned 2-byte 1021 address. 1023 Additionally, during the enrollment process, a DTLS connection or 1024 EDHOC connection will be created. TLS1.3 will keep contents of the 1025 certificates transmitted private while TLS 1.2 will not. If the 1026 client certificate can be observed, then the device identity will be 1027 visible to passive observers in the 802.11AR IDevID certificate that 1028 is sent. 1030 Even when TLS 1.3 is used, an active attacker could collect the 1031 information by creating a rogue proxy. 1033 The use of a manufacturer assigned EUI64 (whether derived from IEEE 1034 assignment or created through another process during manufacturing 1035 time) is encouraged. 1037 8.2.1. EUI-64 derived address for join time IID 1039 The IID used in the link-local address used during the join process 1040 be a vendor assigned EUI-64. After the join process has concluded, 1041 the device SHOULD be assigned a unique randomly generated long 1042 address, and a unique short address (not based upon the vendor EUI- 1043 64) for use at link-layer address. At that point, all layer-3 1044 content is encrypted by the layer-2 key. 1046 9. Security Considerations 1048 TBD 1050 9.1. Security of MASA voucher signing key(s) 1052 TBD 1054 10. Acknowledgements 1056 Kristofer Pister helped with many non-IETF references. 1058 11. References 1060 11.1. Normative References 1062 [cullenCiscoPhoneDeploy] 1063 Jennings, C., "Transitive Trust Enrollment for Constrained 1064 Devices", 2012, . 1067 [I-D.ietf-6lo-privacy-considerations] 1068 Thaler, D., "Privacy Considerations for IPv6 Adaptation 1069 Layer Mechanisms", draft-ietf-6lo-privacy- 1070 considerations-04 (work in progress), October 2016. 1072 [I-D.ietf-6tisch-minimal-security] 1073 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 1074 "Minimal Security Framework for 6TiSCH", draft-ietf- 1075 6tisch-minimal-security-11 (work in progress), June 2019. 1077 [I-D.ietf-6tisch-terminology] 1078 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1079 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 1080 draft-ietf-6tisch-terminology-10 (work in progress), March 1081 2018. 1083 [I-D.ietf-ace-coap-est] 1084 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 1085 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 1086 est-12 (work in progress), June 2019. 1088 [I-D.ietf-anima-bootstrapping-keyinfra] 1089 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1090 S., and K. Watsen, "Bootstrapping Remote Secure Key 1091 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1092 keyinfra-22 (work in progress), June 2019. 1094 [I-D.ietf-anima-constrained-voucher] 1095 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 1096 Voucher Artifacts for Bootstrapping Protocols", draft- 1097 ietf-anima-constrained-voucher-04 (work in progress), July 1098 2019. 1100 [I-D.ietf-anima-voucher] 1101 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1102 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 1103 anima-voucher-07 (work in progress), January 2018. 1105 [I-D.ietf-core-object-security] 1106 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1107 "Object Security for Constrained RESTful Environments 1108 (OSCORE)", draft-ietf-core-object-security-16 (work in 1109 progress), March 2019. 1111 [I-D.richardson-6tisch-enrollment-enhanced-beacon] 1112 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 1113 Element encapsulation of 6tisch Join and Enrollment 1114 Information", draft-richardson-6tisch-enrollment-enhanced- 1115 beacon-01 (work in progress), April 2018. 1117 [I-D.richardson-6tisch-join-enhanced-beacon] 1118 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 1119 Element encapsulation of 6tisch Join Information", draft- 1120 richardson-6tisch-join-enhanced-beacon-03 (work in 1121 progress), January 2018. 1123 [I-D.richardson-anima-6join-discovery] 1124 Richardson, M., "GRASP discovery of Registrar by Join 1125 Assistant", draft-richardson-anima-6join-discovery-00 1126 (work in progress), October 2016. 1128 [I-D.schaad-cose-x509] 1129 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1130 Headers for carrying and referencing X.509 certificates", 1131 draft-schaad-cose-x509-03 (work in progress), December 1132 2018. 1134 [I-D.selander-ace-cose-ecdhe] 1135 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1136 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1137 cose-ecdhe-13 (work in progress), March 2019. 1139 [iec62591] 1140 IEC, ., "62591:2016 Industrial networks - Wireless 1141 communication network and communication profiles - 1142 WirelessHART", 2016, 1143 . 1145 [ieee802-1AR] 1146 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 1147 2009, . 1150 [ieee802154] 1151 IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- 1152 Rate Wireless Personal Area Networks (WPANs)", 2015, 1153 . 1156 [ieee802159] 1157 IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft 1158 Recommended Practice for Transport of Key Management 1159 Protocol (KMP) Datagrams", 2016, 1160 . 1163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1164 Requirement Levels", BCP 14, RFC 2119, 1165 DOI 10.17487/RFC2119, March 1997, 1166 . 1168 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 1169 (LDAP): String Representation of Distinguished Names", 1170 RFC 4514, DOI 10.17487/RFC4514, June 2006, 1171 . 1173 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1174 "Enrollment over Secure Transport", RFC 7030, 1175 DOI 10.17487/RFC7030, October 2013, 1176 . 1178 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1179 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1180 Transport Layer Security (TLS) and Datagram Transport 1181 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1182 June 2014, . 1184 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1185 Application Protocol (CoAP)", RFC 7252, 1186 DOI 10.17487/RFC7252, June 2014, 1187 . 1189 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1190 the Constrained Application Protocol (CoAP)", RFC 7959, 1191 DOI 10.17487/RFC7959, August 2016, 1192 . 1194 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1195 "A Voucher Artifact for Bootstrapping Protocols", 1196 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1197 . 1199 11.2. Informative References 1201 [I-D.ietf-anima-autonomic-control-plane] 1202 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1203 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1204 plane-19 (work in progress), March 2019. 1206 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1207 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1208 November 2005, . 1210 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1211 Application Protocol (CoAP)", RFC 7641, 1212 DOI 10.17487/RFC7641, September 2015, 1213 . 1215 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1216 Description Specification", RFC 8520, 1217 DOI 10.17487/RFC8520, March 2019, 1218 . 1220 Author's Address 1222 Michael Richardson 1223 Sandelman Software Works 1225 Email: mcr+ietf@sandelman.ca