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