idnits 2.17.1 draft-richardson-anima-registrar-considerations-05.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 March 2022) is 782 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-acme-star' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'I-D.friel-acme-integrations' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 976, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-16 == Outdated reference: A later version (-18) exists of draft-hallambaker-mesh-udf-15 == Outdated reference: A later version (-17) exists of draft-ietf-acme-integrations-06 == Outdated reference: A later version (-08) exists of draft-ietf-anima-brski-cloud-03 == Outdated reference: A later version (-15) exists of draft-ietf-anima-constrained-join-proxy-06 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-04 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice W. Pan 5 Expires: 7 September 2022 Huawei Technologies 6 6 March 2022 8 Operational Considerations for BRSKI Registrar 9 draft-richardson-anima-registrar-considerations-05 11 Abstract 13 This document describes a number of operational modes that a BRSKI 14 Registration Authority (Registrar) may take on. 16 Each mode is defined, and then each mode is given a relevance within 17 an over applicability of what kind of organization the Registrar is 18 deployed into. This document does not change any protocol 19 mechanisms. 21 This document includes operational advice about avoiding unwanted 22 consequences. 24 About This Document 26 This note is to be removed before publishing as an RFC. 28 Status information for this document may be found at 29 https://datatracker.ietf.org/doc/draft-richardson-anima-registrar- 30 considerations/. 32 Discussion of this document takes place on the anima Working Group 33 mailing list (mailto:anima@ietf.org), which is archived at 34 https://mailarchive.ietf.org/arch/browse/anima/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/mcr/registrar-operational-considerations.git. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 7 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Reference Network and Diagrams . . . . . . . . . . . . . 4 75 1.2.1. Tier-1 Network . . . . . . . . . . . . . . . . . . . 4 76 1.2.2. Enterprise Network . . . . . . . . . . . . . . . . . 5 77 1.2.3. Home Network . . . . . . . . . . . . . . . . . . . . 6 78 1.3. Internal architectural view . . . . . . . . . . . . . . . 6 79 1.3.1. Pledge Interface (Southbound Interface) . . . . . . . 6 80 1.3.2. MASA client (Northbound Interface) . . . . . . . . . 7 81 1.3.3. Join Proxy (Southbound Interface) . . . . . . . . . . 8 82 1.3.4. EST and BRSKI GRASP announcements . . . . . . . . . . 8 83 1.3.5. Certification Authority . . . . . . . . . . . . . . . 9 84 1.3.6. Management Interface . . . . . . . . . . . . . . . . 9 85 2. Connecting the Autonomic Control Plane to the Network 86 Operations Center (NOC) . . . . . . . . . . . . . . . . . 9 87 3. Public Key Infrastructure Recommendations for the 88 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 10 89 3.1. PKI recommendations for Tier-1/ISP Networks . . . . . . . 10 90 3.2. Enterprise Network . . . . . . . . . . . . . . . . . . . 11 91 3.3. Home Network . . . . . . . . . . . . . . . . . . . . . . 12 92 4. Architecture Considerations for the Registrar . . . . . . . . 13 93 4.1. Completely Synchronous Registrar . . . . . . . . . . . . 14 94 4.2. Partially Synchronous Registrar . . . . . . . . . . . . . 14 95 4.3. Asynchronous Registrar . . . . . . . . . . . . . . . . . 15 96 5. Certificates needed for the Registrar . . . . . . . . . . . . 15 97 5.1. TLS Server Certificate for BRSKI-EST . . . . . . . . . . 15 98 5.2. TLS Client Certificate for BRSKI-MASA . . . . . . . . . . 16 99 5.2.1. Use of Publically Anchored TLS Client Certificate with 100 BRSKI-MASA connection . . . . . . . . . . . . . . . . 16 101 5.3. Certificate for signing of Voucher-Requests . . . . . . . 16 102 6. Autonomic Control Plane Addressing . . . . . . . . . . . . . 16 103 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 105 8.1. Denial of Service Attacks against the Registrar . . . . . 18 106 8.2. Loss of Keys/Corruption of Infrastructure . . . . . . . . 18 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 109 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 112 12.2. Informative References . . . . . . . . . . . . . . . . . 20 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 115 1. Introduction 117 [RFC8995] introduces a mechanism for new devices (called pledges) to 118 be onboarded into a network without intervention from an expert 119 operator. 121 A key aspect of this is that there has to be a thing for the pledge 122 to join! [RFC8995] refers to this thing as the "Domain", identified 123 technically by the "DomainID". The Registrar component embodies the 124 identity, membership and trust anchor of the domain. Membership in 125 the domain is proven by possession of a valid Local DeviceID, a form 126 of [ieee802-1AR] certificate. 128 The Registrar is the component that implements the domain, 129 authorizing new devices (pledges) to join. Proper and efficient 130 operation of the Registrar is key aspect for the Autonomic 131 mechanisms, and for enabling secure onboarding. 133 This document provides implementation, deployment and operational 134 guidance for the BRSKI Registrar. 136 There are however several classes of operator of a local domain: ISP 137 and large managed multi-side Enterprises are the primary target for 138 this document. Medium sized single site Enterprises and Industrial 139 Plant users are a secondary target for this document. Unmanaged 140 small enterprises and home users are addressed in a separate section 141 at the end as special case. 143 This document first introduces the different scales of deployment as 144 a reference for further discussion and contrasts, and then provides 145 analyses some consequences of architectural choices that may be 146 appropriate for different scales of deployments. 148 The document includes security best practices for the management of 149 the certificates and the certification authorities. 151 1.1. Terminology 153 Although this document is not an IETF Standards Track publication, it 154 adopts the conventions for normative language to provide clarity of 155 instructions to the implementer. The key words "MUST", "MUST NOT", 156 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 157 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in BCP 14 [RFC2119] 159 [RFC8174] when, and only when, they appear in all capitals, as shown 160 here. 162 1.2. Reference Network and Diagrams 164 In order to deal with the full complexity and generality of 165 operations, the reference network described herein is a bit more 166 complicated than many networks actually are. 168 XXX-some of these diagrams as more complex than the document 169 currently justifies. 171 1.2.1. Tier-1 Network 173 In this guide one target is a world-wide Tier-1 ISP. It has three 174 network operations centers (NOC), the two major ones in Frankfurt and 175 Denver, with an secondary center located in Perth, Australia. The 176 exact location of these NOCs is not important: the locations have 177 been chosen to have an hour overlap in their 8-6 daytime shift, 178 typical of world-wide operations. This overlap is also not 179 important, it just adds a degree of realism to this discussion. The 180 use of actual names makes subsequent discussion about failures 181 easier. 183 .---------. .------. 184 | Denver | | NYC | 185 .----|---------|---|router|-. .-----------. 186 / | NOC/JRC | '------' \ | Frankfurt | 187 ' '---------' '|-----------| 188 .---------. | NOC/JRC | 189 | SanJose | '-----------' 190 | router | . 191 '---------' / 192 | / 193 | / 194 .-----------. / 195 | Perth | .-------. / 196 |-----------| | Tokyo | / 197 | NOC/EST |--------------|router |-----' 198 | | '-------' 199 '-----------' 201 Figure 1: Reference Tier-1 ISP network 203 1.2.2. Enterprise Network 205 A second target is a medium Enterprise that has a single (probably 206 on-premise) data center. The Enterprise has Information Technology 207 (IT) operations that include the routers and systems supporting it's 208 office staff in it's buildings. It has Building Operations which 209 integrates the IoT devices found in the buildings that it owns, and 210 it has Operations Technology (OT) that manages the automated systems 211 in it's on-site manufacturing facilities. 213 .-------------. 214 | Data Center | 215 .----|-------------|------. 216 / | NOC/JRC | \ 217 / '-------------' \ 218 / \ 219 / \ 220 / \ 221 .--------------. .-------------. 222 | Office Staff | | building | 223 | routers | | automation | 224 | switches | | IoT | 225 | servers | | sensors | 226 '--------------' '-------------' 228 Figure 2: Reference Enterprise network 230 1.2.3. Home Network 232 A third target is a resident with a single CPE device. The home 233 owner has a few medium sized devices (a home NAS) as well as a few 234 IoT devices (light bulbs, clothes washing machine). 236 1.3. Internal architectural view 238 A Registrar will have four major interfaces, connected together by a 239 common database. 241 .------------. 242 | MASA | 243 | Interface | 244 | BRSKI-MASA | 245 '------------' 246 ^ 247 | 248 .------------. | .---------------. 249 | management | .----------. | certification | 250 | interface |<---| database |----->| authority | 251 '------------' '----------' '---------------' 252 | 253 | 254 v 255 .------------. .-----------. .------------. 256 | Join Proxy | | Pledge |--. | EST/BRSKI | 257 |------------| | Interface | | |------------| 258 | GRASP | | BRSKI-EST |e | | GRASP | 259 | (DULL) | '-----------'T | '------------' 260 '------------' '-----------' 262 Figure 3: Reference Internal Architecture for Registrar 264 1.3.1. Pledge Interface (Southbound Interface) 266 The pledge interface is the southbound interface. This interface 267 runs the BRSKI-EST protocol. This interface faces into the 268 operator's network, receiving requests from devices to join the 269 network. 271 For [RFC8995] use, the pledge interface is an HTTPS interface. Due 272 to the use of provinsional trust state in the BRSKI-EST interface the 273 pledge never verifies the contents of the TLS server certificate. As 274 a result, the registrar may run on arbitrary port numbers. The 275 voucher pins the associated certificate, so the Registrar does not 276 need to have any specific (subjectAltName) dnsName. 278 When a constrained onboarding mechanism is supported via 279 [I-D.ietf-anima-constrained-voucher], then CoAP is used. 281 [I-D.ietf-anima-constrained-join-proxy] describes a mechanism to 282 provide a stateless proxy of CoAPS connections, in which case DTLS 283 traffic will be proxied by the Join Proxy to the port that the 284 Registrar announces via GRASP within the ACP. In this case, then 285 there is DTLS layer below the CoAP layer. 287 [RFC9031] describes a proxy mechanism that can be used with 288 [I-D.selander-ace-ake-authz] to pass CoAP traffic. In this case, 289 depending upon the chosen AKE, the key agreement protocol would be 290 above CoAP. 292 [I-D.richardson-anima-state-for-joinrouter] offers some additional 293 mechanisms, one of which involves dynamically created IPIP tunnels. 294 If these mechanisms are in use, then the southbound interface would 295 need to support these options as well. 297 The Pledge Interface requires a TLS ServerCertificate, and 298 Section 5.1 discusses option for creating this certificate. 300 The Pledge Inteface does not require a public IP address, nor does it 301 have have to run on port 443. The address and port of the Pledge 302 interface to the Registrar is advertised by the Registrar using 303 GRASP, according to [RFC8995] section 4.1.1. The service may run on 304 any available port. The HTTPS, CoAP and CoAPS port numbers do not 305 need to be coordinated. 307 In an ACP application ([RFC8994]), the Pledge Interface SHOULD have 308 an IPv6 Unique Local Address (ULA) address from the prefix allocated 309 to the ACP. Section 2 provides some options for how the Pledge 310 Interface can be best connected to the ACP. 312 Outside of the ACP context, running the Pledge interface on an IP 313 address that has a FQDN that resolves to that IP address (if only 314 internally), and operating it on port 443 may have operational 315 advantages. The Registrar may have additional management functions, 316 it may also serve as an EST end point for certificate renewal, and 317 [I-D.ietf-anima-brski-cloud] proposes a mechanism to bootstrap 318 devices which are not connected by a convex ACP, or no ACP. The 319 Registrar may be accessible via multiple interfaces. 321 1.3.2. MASA client (Northbound Interface) 323 The MASA client interface connects outward to the Internet to speak 324 to the Manufacturer Authorized Signing Authority (MASA). This is a 325 TLS Client interface. 327 Use of a TLSClientCertificate is RECOMMENDED as this may be the best 328 way for a manufacturer to identify clients. Section 5.2 discusses 329 options for signing this certificate. 331 The MASA client interface is outgoing only and does not require any 332 special connectivity. It may be placed behind a typical enterprise 333 or residential NAT44 gateway. IPv6 connectivity is RECOMMENDED. It 334 does need access to DNS, and the DNS lookups SHOULD be validated with 335 DNSSEC. 337 The MASA client interface will need to validate the server 338 certificates of the MASA, and to do this it will need access to the 339 common public WebPKI ([WebPKI]) trust anchors to validate the MASA. 340 The MASA client MAY also require access to a database of pinned 341 certificates to validate specific manufacturers as called out for in 342 [RFC8995] section 2.8 and section 5.4. 344 1.3.3. Join Proxy (Southbound Interface) 346 In the ACP context, the Registrar is expected to have a Join Proxy 347 operating on the Southbound Interface in order to announce the 348 existence of the Registrar to the local network, for the benefit of 349 directly connected devices. This permits the systems on the LAN in 350 the NOC itself to autonomically join the domain. 352 The Join Proxy MAY announce the IP address (ULA) and port of the 353 actual Pledge Interface, rather than announcing a link-local address 354 and then performing a proxy operation. 356 1.3.4. EST and BRSKI GRASP announcements 358 As specified in [RFC8995] section 4.3, in an ACP context, the 359 Registrar MUST announce itself inside the ACP using GRASP. The 360 Registrar MUST incorporate enough of a GRASP daemon in order to 361 perform the M_FLOOD announcements. 363 As specified in [RFC8995] section 6.1.2, in an ACP context, if the 364 Registrar will also be providing for renewal of certificates using 365 EST, then it SHOULD announce itself inside the ACP using GRASP. See 366 [RFC8994] section 6.1.5.1 for details. Unless made impossible due to 367 loading concerns, it is RECOMMENDED that all Registrar instances 368 offer certificate renewal services in this fashion. 370 The use of [RFC8739] Short-Term Automatically-Renewed Certificates is 371 RECOMMENDED. This mandates that the EST server be highly available. 372 If STAR-style renewals are not used, then the Certification Authority 373 will need to make OCSP or CRL Distribution points available. 375 1.3.5. Certification Authority 377 If the Enterprise/ISP has an existing certification authority system 378 that it wishes to use, then an interface to it has to be enabled. 379 This may run protocols like EST, CMP or ACME. 381 Smaller Enterprises and Residential uses of BRSKI are encouraged to 382 use an internal (private) certification authority. See Section 3 for 383 a discussion of securing this CA. 385 1.3.6. Management Interface 387 The Registrar will require a management interface. As is the trend, 388 this will often be a web-based single page application using AJAX API 389 calls to perform communications. This interface SHOULD be made 390 available on the Southbound NOC interface only, and it MUST be on a 391 different IP address and port number then the BRSKI-EST interface. 392 It should be secured with HTTPS, and use of a public ([WebPKI]) 393 anchor is reasonable as it may be that the internal certification 394 authority may be unavailable or require maintenance. 396 An entirely separate process is justified with the only connection to 397 the other procesess being the database. (This does not mean it can 398 not share code modules) 400 2. Connecting the Autonomic Control Plane to the Network Operations 401 Center (NOC) 403 [RFC8994] section 8.1 describes a mechanism to connect non-ACP 404 capable systems to the ACP. The use of this mechanism is critical to 405 incremental deployment of ANIMA and BRSKI in operators. 407 The deployment of BRSKI capable equipment would ideally occur in an 408 outward wave, a concentric ring, from the NOC. 410 (EDNOTE: INSERT DIAGRAMS) 412 This would start by an upgrade of the router that connects the NOC to 413 the production network. This device needs to support the ACP connect 414 functionality. 416 It is possible, but beyond the scope of this document, to do initial 417 connectivity of the ACP and of multiple NOCs by manually configured 418 IPsec tunnels. This is likely an important step for incremental 419 initial deployment. 421 The Registrar described in the next section either needs to be 422 connected via one of the above mentioned tunnels, or it must be 423 located on a network with ACP Connect, or it must itself be part of 424 an automatically configured ACP. It is quite reasonable for the 425 Registrar to be part of a larger appliance that also includes an ACP 426 Connect functionality. 428 3. Public Key Infrastructure Recommendations for the Registrar 430 The Registrar requires access to, or must contain a Certification 431 Authority (CA). 433 This section deals with the situation where the CA is provided 434 internally. [I-D.ietf-acme-integrations] deals with the case where 435 the CA is provided by an external service, and the CA trust anchors 436 are public. These use ACME ([RFC8555]) is used as the interface. 437 That is out of scope for this document. 439 There are also a number of commercial offerings where a private CA is 440 operated by an external entity using a wide variety of protocols, 441 including proprietary ones. Those are also out of scope for this 442 document. 444 The requirements for the PKI depends upon what kind of network is 445 being managed. 447 3.1. PKI recommendations for Tier-1/ISP Networks 449 A three-tier PKI infrastructure is appropriate for an ISP. This 450 entails having a root CA created with the key kept offline, and a 451 number of intermediate CAs that have online keys that issue "day-to- 452 day" certificates. 454 Whether the root private key is secured by applying secret-splitting, 455 and then storing the results on multiple USBs key kept in multiple 456 safes, or via Hardware Security Module is a local decision informed 457 by best current practices. 459 The root CA is then used to sign a number of intermediate entities: 460 this will include an intermediate CA for the Registrar that is 461 deployed into each redundant NOC location. Multiple intermediate CAs 462 with a common root provides significantly more security and 463 operational flexibility than attempts to share a private key among 464 locations. 466 While the root CA should have a longevity of at least 5 years, after 467 which it can be re-signed rather than re-generated. (Resigning an 468 existing key might not require replacement of trust anchors on all 469 devices) 471 The intermediate CA keys need only have a 1-2 year duration, and 472 before the end of their lifetime, a new private key should be 473 generated and replace the old one. 475 Shorter periods are possible, but until there is more experience with 476 them, not recommended. The intermediate CA key should be regenerated 477 because the intermediate CA private key will need to be online, 478 available to the Registrar CA system. There are many more 479 opportunities for the key to leak, such as into backups. 481 The intermediate CA is then used to sign End-Entity certificates 482 which are returned as part of the BRSKI-EST mechanism. 484 The Registrar needs both of client and server certificates for it's 485 BRSKI-EST and BRSKI-MASA connections. It is recommended that an 486 additional intermediate CA can be created for manually issued 487 certificates such as these. This intermediate CA could be called the 488 NOC Infrastructure CA, and could be used to issue certificates for 489 all manner of infrastructure such as web-based monitoring tools. The 490 private root CA certificate should be installed into the browsers of 491 NOC personnel. 493 The document [I-D.moskowitz-ecdsa-pki] provides some practical 494 instructions on setting up this kind of system. This document 495 recommends the use of ECDSA keys for the root and intermediate CAs, 496 but there may be operational reasons why an RSA intermediate CA will 497 be required for some legacy equipment. 499 3.2. Enterprise Network 501 Enterprises that have multiple Network Operations Center should 502 consider the recommendations above for an ISP. 504 This section applies to Enterprises that have all NOC operations/ 505 personel into a single location, which is probably on-premise data 506 center. This is not a hard rule for scaling, but the intent is that 507 physical security for the ACP Connect network is rather easy, that 508 only a single legal jurisdiction will apply, and that it is possible 509 to get people together easily to do things like resign keys. 511 A three-tier PKI infrastructure is still recommended for the reason 512 that it provides operational continuity options not available with a 513 two-level system. The recommendation is to have a root CA mechanism 514 installed on a Virtual Machine which is not connected to a network. 515 The root CA private key is kept offline, secret split among a number 516 of USB keys, kept in the possession of key personnel. 518 The secret split should have at least five components, of which at 519 least three are required to reconstruct the key. See 520 [I-D.hallambaker-mesh-udf] section 4.5 for one such mechanism, there 521 are many others, and there are no interoperability requirements for 522 the secret split. 524 The essential point is that the Enterprise is able to recover the 525 root CA key even without some number of personnel and is able to 526 continue operating it's network. 528 As in the ISP case, the intermediate CA is then used to sign End- 529 Entity certificates which are returned as part of the BRSKI-EST 530 mechanism. One intermediate CA key suffices as there is only one NOC 531 location with a Registrar. Incidental certificates for internal 532 operations (such as internal web servers, email servers, etc.), and 533 for the BRSKI-EST server certificate can be done with this single 534 intermediate CA. 536 The BRSKI-MASA TLS Client Certificate key for an enterprise may not 537 be needed; it depends upon the policies of the manufacturers which 538 are involved. It may be simpler to use a certificate produced by a 539 public CA (such as LetsEncrypt), as this makes it easier for 540 manufacturers to validate the provided certificate. 542 The document [I-D.moskowitz-ecdsa-pki] provides some practical 543 instructions on setting up this kind of system. This document 544 recommends the use of ECDSA keys for the root and intermediate CAs. 545 In an Enterprise, there are likely many more legacy devices that 546 might need to become involved in the secure domain. It is 547 recommended that an RSA root and intermediate CA be more strongly 548 considered. 550 3.3. Home Network 552 Home networks and small offices that use residential class equipment 553 are the most challenging situation. The three-tier PKI architecture 554 is not justified because the ability to keep the root CA offline has 555 no operational value. 557 The home network registrar should be initialized with a single key 558 pair used as the certification authority. 560 Secret splitting is useful in order to save the generated key with a 561 few neighbours. It is recommended that the entire PKI system 562 database (including CA private key) be encrypted with a symmetric key 563 and the results made available regularly for download to a variety of 564 devices. The symmetric key is split among the neighbours. 566 The most difficult part of the Home Network PKI and Registrar is 567 where to locate it. Generally it should be located on a device that 568 is fully owned by the home user. This is sometimes the Home Router, 569 but in a lot of situations the Home Router is the ISP's CPE router. 570 If the home has a Network Attached Storage (NAS) system, then running 571 it there is probably better. 573 A compromise for CPE devices owned by the ISP that can run containers 574 is for the Registrar to be located on detachable storage that is 575 inserted into the CPE. The detachable storage is owned by the home 576 owner, and can be removed from the CPE device if it is replaced. 577 More experience will be necessary in order to determine if this is a 578 workable solution. 580 4. Architecture Considerations for the Registrar 582 There are a number of ways to scale the Registrar. Web framework 583 three-tier mechanisms are the most obvious. See [threetier] for an 584 overview. This architecture is very familiar and can work well for a 585 Registrar. There are a few small issues that need to be addressed 586 relating to the TLS connections. 588 The BRSKI-EST connection uses TLS Client Certificate information, so 589 it is necessary for the presentation tier to pass the entire 590 certificate through to the application layer. The presentation tier 591 MUST accept all Client Certificates, many of which might it might not 592 have anchors for. Many n-tier systems provide for non-standard ways 593 to transmit the client certificate from presentation layer to 594 application layer, but [I-D.bdc-something-something-certificate] also 595 intends to provide a standards track mechanism. 597 In addition, the Registrar Voucher-Request MUST be signed using the 598 same key pair that is used to terminate the TLS connection, so the 599 application layer will need access to the same keypair that the 600 presentation tier uses. This can be operationally challenging if the 601 presentation tier is provided by a hardware-based TLS load balancer. 603 For this reason, an alternate architecture where the front-end load 604 balancer provides TCP level load balancing, leaving the TLS 605 operations to software TLS implementations in the application layer 606 may be simpler to build. Given that the Registrar is an inward 607 facing system, and is not subject to the Internet-scale loads typical 608 of "Black Friday" web system, the same kind of extreme scaling is not 609 necessary. 611 The BRSKI-EST flow includes a back-end call to the BRSKI-MASA flow. 612 That is, during the BRSKI-EST /voucherrequest call, a voucher will 613 need to be fetched from the MASA using a BRSKI-MASA connection. 614 There are three ways to do this. 616 4.1. Completely Synchronous Registrar 618 In this simplest version the Registrar operates as a single thread, 619 processing the voucher-request from the Pledge, and then starting a 620 BRSKI-MASA client session, while the connection from the Pledge 621 waits. 623 This flow is very simple to implement, but requires an entire 624 processing thread to block while the BRSKI-MASA protocol executes. 625 The Pledge may timeout on this request, disconnect and retry. 626 Experience so far is that typical default timeouts work fine. 628 It is recommended that the voucher-request be recorded in a database, 629 and if a corresponding fresh voucher is also found in the database, 630 that it be returned rather than fetching a new voucher from the MASA. 631 This accomodates the situation where the Pledge did timeout, but the 632 BRSKI-MASA protocol did complete. This results in the Pledge 633 receiving the voucher upon retrying without having to go through the 634 process of getting a new voucher. This only works if the Pledge 635 retries with the same Nonce each time. 637 4.2. Partially Synchronous Registrar 639 A slightly more complicated version is for the Registrar to look in a 640 database for a matching voucher-request, and if none is found, to 641 return a 202 code upon the voucher-request, asking the Pledge to 642 retry. 644 In the meantime the BRSKI-MASA connection can be performed, and the 645 resulting voucher stored in a database. The connection can be done 646 in the same thread that just deferred the connection, or in another 647 thread kicked off for this purpose. 649 4.3. Asynchronous Registrar 651 In the completely asynchronous architecture, things work as with the 652 Partially Synchronous version. The voucher request is placed into a 653 database as before. 655 A completely separate system, probably with different network 656 connectivity, but connected to the same database, performs the BRSKI- 657 MASA processing, then fills the database with the answer. 659 This version may have a noticeably higher latency as it requires a 660 database operation and a database trigger to invoke the process. 661 This architecture has the advantage, however, that the internal 662 facing Registrar never connects to the Internet. Furthermore, the 663 number of internal facing Registrar instances can be tuned 664 independently from the number of outward facing clients. This may be 665 an advantage for networks that need to deal with a high number of 666 malicious or lost internal clients. 668 5. Certificates needed for the Registrar 670 In addition to hosting a PKI root, the Registrar needs several other 671 key pairs. They are: 673 5.1. TLS Server Certificate for BRSKI-EST 675 A certificate to be used to answer TLS connections from new devices 676 (pledges). This must be of a type that expected pledges can 677 understand. Returning an RSA key to a client that can validate only 678 ECDSA chains is a problem. The constrained IoT ecosystem prefers 679 ECDSA, and often does not have code that can verify RSA. Meanwhile, 680 older FIPS-140 validated libraries present in many router operating 681 systems support only RSA! 683 The recommendation is to use ECDSA keys, with a sensitiviity to when 684 a majority of systems might support EdDSA. There are well 685 established mechanisms in most TLS server libraries to permit 686 multiple certificates to be loaded and to return an appropriate key 687 based upon the client capabilities. This should be used. 689 The certificate used for the BRSKI-EST end point is not validated by 690 the BRSKI pledge using public trust anchors, but rather it is pinned 691 by the [RFC8366] voucher. As such it can come from the private CA, 692 as recommended above: either signed by a specific intermediate CA or 693 via a root CA as appropriate for the environment. 695 5.2. TLS Client Certificate for BRSKI-MASA 697 A certificate may optionally be used for authentication of the 698 Registrar to the MASA. It is recommended to always include one. 700 It can be the same certificate used by TLS Server Certificate above, 701 and this is most appropriate in small Registrars which are not 702 distributed, such as ones aimed as Residential/Home networks. 704 In larger, distributed Registrars, cryptographic hygiene dictates 705 that the private key not be distributed, so a unique certificate per 706 Registrar client is appropriate. They should all be signed by the 707 same intermediate CA, with the intermediate and root CA certificates 708 being supplied in the TLS connection. 710 5.2.1. Use of Publically Anchored TLS Client Certificate with BRSKI- 711 MASA connection 713 The use TLS Client Certificate which has a public anchor (such as 714 from LetsEncrypt) has an advantage that is makes it easier for the 715 MASA to reject malicious clients. 717 If the Registrar is not using a supply chain integration that 718 includes the MASA being aware of the cryptographic identity of the 719 Registrar, then the use of a publically anchored certificate is 720 RECOMMENDED. 722 5.3. Certificate for signing of Voucher-Requests 724 As part of the BRSKI voucher-request process the Pledge's Voucher- 725 Request is wrapped by the Registrar in another voucher-request and 726 signed. It is this certificate which pinned by MASA to validate the 727 connection. 729 The certificate used to sign the (parboiled) voucher-request MUST be 730 the same as the one that is used for the TLS Server Connection. This 731 implies that the signed voucher-request MUST be constructed on the 732 same machine that terminates the BRSKI-EST connection. 734 6. Autonomic Control Plane Addressing 736 In the Enterprise and ISP use cases, the creation of an [RFC8994] 737 Autonomic Control Plane is assumed. (The use of an ACP for the Home 738 Network of IoT devices is considered unnecessary due to HNCP) 739 In these context the certificates which are returned by the Registrar 740 MUST contain a unique IPv6 ULA address. [RFC8994] section 6.10 741 outlines several addressing schemes for the ULA addresses. The use 742 of the ACP Vlong Addressing Sub-Scheme (6.10.5) is recommended as it 743 provides the most flexibility for devices. 745 The use of this mode limits the number of nodes in the network to 746 between 32768 and 8 Million. 32K routers in an ISP network seems like 747 quite a lot already, but use of F=0 addresses provides for up to 8 748 Million devices, each with 256 management end points. 750 It should be noted that a mix of F=0 and F=1 addresses may be used, 751 but the BRSKI protocol does not directly provide a way to negotiated 752 this. This could be done as part of the Certificate Signing Request: 753 the device could decide which kind of address to ask for by changing 754 the address that it asks for, but this is non-standardized and may 755 not work. 757 A network manager that saw that a device was running out of F=0 758 space, that is if 256 addresses was not enough for a device, could 759 allocate an F=1 address in a management interface. At the next 760 certificate renewal (which could be forced by a management action), 761 then a new certificate would be issues with the larger address space. 763 256 addresses for a single device may seem like a lot, but it is 764 increasing the case that routers may have a large number of 765 virtualized functions within and each may reasonably need to be 766 separately connected to it's SDN controller. 768 7. Privacy Considerations 770 Section 10.2 of [RFC8995] details a number of things that are 771 revealed by the BRSKI-EST protocol. A multi-location Registrar with 772 different TLS Server Certificates will have a different privacy 773 profile than a Registrar that uses only a single certificate. 775 Section 10.3 of [RFC8995] details what is revealed by the BRSKI-MASA 776 protocol. The operational recommendations of this document do not 777 affect or mitigate things at all. 779 8. Security Considerations 781 Section 11 of [RFC8995] does not deal with any attacks against the 782 Registrar, as the Registrar is considered to be an internally facing 783 system. 785 In the context of the Autonomic Control Plane ([RFC8995] section 9, 786 and [RFC8994]) it is expected that the majority of equipment attached 787 to a network are connected by wired ethernet. The opportunity for a 788 massive attack against the Registrar is considered low in an ISP, or 789 multi-side Enterprise backbone network. 791 8.1. Denial of Service Attacks against the Registrar 793 However, there are some exposures which need to be taken into 794 account, particular in the Enterprise or Institutional Campus 795 network: typically these networks have large number of access ports, 796 one for each desktop system. Those systems can be infected with 797 Malware, or may be located in student computer labs physically 798 accessible with minimal authorization. While an attack on the 799 Registrar might be part of some kind of student protest, an attack by 800 malware seems more likely. 802 The different architectures proposed in Section 4 of this document 803 provides some recommendations on differing scales. The use of a 804 fully asynchronous design is recommended for Enterprise uses of BRSKI 805 where there may be a large number of IoT devices that are expected to 806 onboard. The ability to scale the BRSKI-EST Pledge Interface without 807 having the scale the rest of the system provides for resiliency of 808 the Registrary. 810 It bears repeating that the use of of a stateless technology in the 811 Join Proxy moves the load due to attacking systems from the Join 812 Proxy into the Registrar. This increases the network bandwidth 813 required from the Join Proxy to the Registrar with the benefit of 814 simplifying the Join Proxy. 816 This is an intentional design decision to centralize the impact into 817 the purpose built Registrar system(s). 819 8.2. Loss of Keys/Corruption of Infrastructure 821 In Home/Residential Network ("homenet") uses of [RFC8995] the biggest 822 risk is likely that of loss of the Registrar's key pairs. That is, 823 accidental loss of the private key is more likely than loss to a 824 malicious entity that steals them with intent to cause damage. 826 This can be due to failure to backup the database followed by a CPE 827 device failure, but the case where a CPE device is simply thrown away 828 to be replaced by an uninformed technician or household member is 829 probably the most likely situation. 831 This situation results in loss of control for all devices in the 832 home, and much frustration from the home owner who has to go through 833 an onboarding process for all the devices. The use of a standardized 834 onboarding protocol significantly mitigates the hassle; the current 835 "state of the art" proccess involves a series of appliance-specific 836 smartphone applications, which may or not not actually work on more 837 recent devices. 839 This is why the focus on saving of the database along with a secret 840 splitting process to secure it. At present there is no cross-vendor 841 format for this database, so the saved data is only useable with a 842 Registrar from the same vendor. So this protects against device 843 failure, where it is replaced by an identical device or an upward 844 compatible device from the same manufacturer, but not against changes 845 of vendor. 847 9. IANA Considerations 849 This document makes no IANA allocations. 851 10. Acknowledgements 853 Your name here. 855 11. Changelog 857 12. References 859 12.1. Normative References 861 [I-D.ietf-acme-star] 862 Sheffer, Y., Lopez, D., Dios, O. G. D., Perales, A. A. P., 863 and T. Fossati, "Support for Short-Term, Automatically 864 Renewed (STAR) Certificates in the Automated Certificate 865 Management Environment (ACME)", Work in Progress, 866 Internet-Draft, draft-ietf-acme-star-11, 24 October 2019, 867 . 870 [I-D.ietf-anima-constrained-voucher] 871 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 872 Dijk, "Constrained Bootstrapping Remote Secure Key 873 Infrastructure (BRSKI)", Work in Progress, Internet-Draft, 874 draft-ietf-anima-constrained-voucher-16, 14 February 2022, 875 . 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, 880 DOI 10.17487/RFC2119, March 1997, 881 . 883 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 884 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 885 May 2017, . 887 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 888 "A Voucher Artifact for Bootstrapping Protocols", 889 RFC 8366, DOI 10.17487/RFC8366, May 2018, 890 . 892 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 893 Autonomic Control Plane (ACP)", RFC 8994, 894 DOI 10.17487/RFC8994, May 2021, 895 . 897 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 898 and K. Watsen, "Bootstrapping Remote Secure Key 899 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 900 May 2021, . 902 12.2. Informative References 904 [I-D.bdc-something-something-certificate] 905 Campbell, B., "Client-Cert HTTP Header: Conveying Client 906 Certificate Information from TLS Terminating Reverse 907 Proxies to Origin Server Applications", Work in Progress, 908 Internet-Draft, draft-bdc-something-something-certificate- 909 05, 23 March 2021, . 912 [I-D.friel-acme-integrations] 913 Friel, O., Barnes, R., and R. Shekh-Yusef, "ACME 914 Integrations", Work in Progress, Internet-Draft, draft- 915 friel-acme-integrations-02, 24 October 2019, 916 . 919 [I-D.hallambaker-mesh-udf] 920 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 921 Data Fingerprint.", Work in Progress, Internet-Draft, 922 draft-hallambaker-mesh-udf-15, 25 October 2021, 923 . 926 [I-D.ietf-acme-integrations] 927 Friel, O., Barnes, R., Shekh-Yusef, R., and M. Richardson, 928 "ACME Integrations", Work in Progress, Internet-Draft, 929 draft-ietf-acme-integrations-06, 17 December 2021, 930 . 933 [I-D.ietf-anima-brski-cloud] 934 Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI 935 Cloud Registrar", Work in Progress, Internet-Draft, draft- 936 ietf-anima-brski-cloud-03, 6 March 2022, 937 . 940 [I-D.ietf-anima-constrained-join-proxy] 941 Richardson, M., Stok, P. V. D., and P. Kampanakis, 942 "Constrained Join Proxy for Bootstrapping Protocols", Work 943 in Progress, Internet-Draft, draft-ietf-anima-constrained- 944 join-proxy-06, 3 December 2021, 945 . 948 [I-D.moskowitz-ecdsa-pki] 949 Moskowitz, R., Birkholz, H., Xia, L., and M. C. 950 Richardson, "Guide for building an ECC pki", Work in 951 Progress, Internet-Draft, draft-moskowitz-ecdsa-pki-10, 31 952 January 2021, . 955 [I-D.richardson-anima-state-for-joinrouter] 956 Richardson, M. C., "Considerations for stateful vs 957 stateless join router in ANIMA bootstrap", Work in 958 Progress, Internet-Draft, draft-richardson-anima-state- 959 for-joinrouter-03, 22 September 2020, 960 . 963 [I-D.selander-ace-ake-authz] 964 Selander, G., Mattsson, J. P., Vučinić, M., Richardson, 965 M., and A. Schellenbaum, "Lightweight Authorization for 966 Authenticated Key Exchange.", Work in Progress, Internet- 967 Draft, draft-selander-ace-ake-authz-04, 22 October 2021, 968 . 971 [ieee802-1AR] 972 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 973 2009, . 976 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 977 "Enrollment over Secure Transport", RFC 7030, 978 DOI 10.17487/RFC7030, October 2013, 979 . 981 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 982 Kasten, "Automatic Certificate Management Environment 983 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 984 . 986 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 987 Perales, A., and T. Fossati, "Support for Short-Term, 988 Automatically Renewed (STAR) Certificates in the Automated 989 Certificate Management Environment (ACME)", RFC 8739, 990 DOI 10.17487/RFC8739, March 2020, 991 . 993 [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. 994 Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", 995 RFC 9031, DOI 10.17487/RFC9031, May 2021, 996 . 998 [threetier] 999 Wikipedia, "Multitier architecture", December 2019, 1000 . 1002 [WebPKI] CA/Browser Forum, ., "CA/Browser Forum Baseline 1003 Requirements for the Issuance and Management of Publicly- 1004 Trusted Certificates, v.1.2.2", October 2014, 1005 . 1007 Authors' Addresses 1009 Michael Richardson 1010 Sandelman Software Works 1011 Email: mcr+ietf@sandelman.ca 1013 Wei Pan 1014 Huawei Technologies 1015 Email: william.panwei@huawei.com