idnits 2.17.1 draft-richardson-anima-registrar-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (5 December 2019) is 1597 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8174' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 880, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-21 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-30 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-05 == Outdated reference: A later version (-18) exists of draft-hallambaker-mesh-udf-07 == Outdated reference: A later version (-10) exists of draft-moskowitz-ecdsa-pki-07 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track 5 December 2019 5 Expires: 7 June 2020 7 Operational Considerations for BRSKI Registrar 8 draft-richardson-anima-registrar-considerations-02 10 Abstract 12 This document describes a number of operational modes that a BRSKI 13 Registration Authority (Registrar) may take on. 15 Each mode is defined, and then each mode is given a relevance within 16 an over applicability of what kind of organization the Registrar is 17 deployed into. This document does not change any protocol 18 mechanisms. 20 This document includes operational advice about avoiding unwanted 21 consequences. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 7 June 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Reference Network and Diagrams . . . . . . . . . . . . . 4 59 1.2.1. Tier-1 Network . . . . . . . . . . . . . . . . . . . 4 60 1.2.2. Enterprise Network . . . . . . . . . . . . . . . . . 4 61 1.2.3. Home Network . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Internal architectural view . . . . . . . . . . . . . . . 5 63 1.3.1. Pledge Interface (Southbound Interface) . . . . . . . 5 64 1.3.2. MASA client (Northbound Interface) . . . . . . . . . 6 65 1.3.3. Join Proxy (Southbound Interface) . . . . . . . . . . 7 66 1.3.4. EST and BRSKI GRASP announcements . . . . . . . . . . 7 67 1.3.5. Certificate Authority . . . . . . . . . . . . . . . . 7 68 1.3.6. Management Interface . . . . . . . . . . . . . . . . 8 69 2. Connecting the Autonomic Control Plane to the Network 70 Operations Center (NOC) . . . . . . . . . . . . . . . . . 8 71 3. Public Key Infrastructure Recommendations for the 72 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. PKI recommendations for Tier-1/ISP Networks . . . . . . . 9 74 3.2. Enterprise Network . . . . . . . . . . . . . . . . . . . 10 75 3.3. Home Network . . . . . . . . . . . . . . . . . . . . . . 11 76 4. Architecture Considerations for the Registrar . . . . . . . . 12 77 4.1. Completely Synchronous Registrar . . . . . . . . . . . . 12 78 4.2. Partially Synchronous Registrar . . . . . . . . . . . . . 13 79 4.3. Asynchronous Registrar . . . . . . . . . . . . . . . . . 13 80 5. Certificates needed for the Registrar . . . . . . . . . . . . 13 81 5.1. TLS Server Certificate for BRSKI-EST . . . . . . . . . . 14 82 5.2. TLS Client Certificate for BRSKI-MASA . . . . . . . . . . 14 83 5.2.1. Use of Publically Anchored TLS Client Certificate with 84 BRSKI-MASA connection . . . . . . . . . . . . . . . . 14 85 5.3. Certificate for signing of Voucher-Requests . . . . . . . 15 86 6. Autonomic Control Plane Addressing . . . . . . . . . . . . . 15 87 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 8.1. Denial of Service Attacks against the Registrar . . . . . 16 90 8.2. Loss of Keys/Corruption of Infrastructure . . . . . . . . 17 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 93 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 96 12.2. Informative References . . . . . . . . . . . . . . . . . 18 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 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 domain is embodied by the Registrar component. Membership in the 110 domain is proven by possession of a valid Local DeviceID, a form of 111 [ieee802-1AR] certificate. 113 The Registrar is the component that implements the domain, 114 authorizing new devices (pledges) to join. Proper and efficient 115 operation of the Registrar is key aspect for the Autonomic 116 mechanisms, and for enabling secure onboarding. 118 This document provides implementation, deployment and operational 119 guidance for the BRSKI Registrar. 121 There are however several classes of operator of a local domain: ISP 122 and large managed multi-side Enterprises are the primary target for 123 this document. Medium sized single site Enterprises and Industrial 124 Plant users are a secondary target for this document. Unmanaged 125 small enterprises and home users are addressed in a separate section 126 at the end as special case. 128 This document first introduces the different scales of deployment as 129 a reference for further discussion and contrasts, and then provides 130 analyses some consequences of architectural choices that may be 131 appropriate for different scales of deployments. 133 The document includes security best practices for the management of 134 the certificates and the certificate authorities. 136 1.1. Terminology 138 ::boilerplate bcp14 140 This document, while a Best Current Practices, makes use of BCP14 141 language to indicate which practices are mandatory, and which ones 142 are just recommendations. 144 1.2. Reference Network and Diagrams 146 In order to deal with the full complexity and generality of 147 operations, the reference network described herein is a bit more 148 complicated than many networks actually are. 150 1.2.1. Tier-1 Network 152 In this guide one target is a world-wide Tier-1 ISP. It has three 153 network operations centers (NOC), the two major ones in Frankfurt and 154 Denver, with an secondary center located in Perth, Australia. The 155 exact location of these NOCs is not important: the locations have 156 been chosen to have an hour overlap in their 8-6 daytime shift, 157 typical of world-wide operations. This overlap is also not 158 important, it just adds a degree of realism to this discussion. The 159 use of actual names makes subsequent discussion about failures 160 easier. 162 .---------. .-----. 163 | Denver | | NYC | 164 .----|---------|----| rtr |--. .-----------. 165 / | NOC/JRC | '-----' \ | Frankfurt | 166 ' '---------' '|-----------| 167 .---------. | NOC/JRC | 168 | SanJose | '-----------' 169 | rtr | . 170 '---------' / 171 .- / 172 ' / 173 .-----------. / 174 | Perth | .-------. / 175 |-----------| | Tokyo | / 176 | NOC/EST |--------------| rtr |-----' 177 | | '-------' 178 '-----------' ' 180 Figure 1: Reference Tier-1 ISP network 182 1.2.2. Enterprise Network 184 A second target is a medium Enterprise that has a single (probably 185 on-premise) data center. The Enterprise has Information Technology 186 (IT) operations that include the routers and systems supporting it's 187 office staff in it's buildings. It has Building Operations which 188 integrates the IoT devices found in the buildings that it owns, and 189 it has Operations Technology (OT) that manages the automated systems 190 in it's on-site manufacturing facilities. 192 INSERT DIAGRAM 194 1.2.3. Home Network 196 A third target is a resident with a single CPE device. The home 197 owner has a few medium sized devices (a home NAS) as well as a few 198 IoT devices (light bulbs, clothes washing machine). 200 1.3. Internal architectural view 202 A Registrar will have four major interfaces, connected together by a 203 common database. 205 .------------. 206 | MASA | 207 | client | 208 | BRSKI-MASA | 209 '------------' 210 ^ 211 | 212 .------------. | .-------------. 213 | management | .----------. | certificate | 214 | interface |<---| database |----->| authority | 215 '------------' '----------' '-------------' 216 | 217 | 218 v 219 .------------. .-----------. .------------. 220 | Join Proxy | | Pledge |--. | EST/BRSKI | 221 |------------| | Interface | | |------------| 222 | GRASP | | BRSKI-EST |e | | full-GRASP | 223 | (DULL) | '-----------'T | '------------' 224 '------------' '-----------' 226 Figure 2: Reference Internal Architecture for Registrar 228 1.3.1. Pledge Interface (Southbound Interface) 230 The pledge interface is the southbound interface. This interface 231 runs the BRSKI-EST protocol. This interface faces into the 232 operator's network, receiving requests from devices to join the 233 network. 235 For [I-D.ietf-anima-bootstrapping-keyinfra] use, the pledge interface 236 is an HTTPS interface. It may run on arbitrary port numbers and due 237 to the way that the voucher interface pins the associated certificate 238 it does not need to have a specific DNS name, as it will not be 239 verified by the pledge. 241 For [I-D.ietf-anima-constrained-voucher] use, the pledge interface is 242 a CoAP or CoAPS interface over UDP. For use with CoAP/EDHOC, then a 243 plain CoAP interface is used, and the security (EDHOC and OSCORE) 244 lives above CoAP. For CoAP/DTLS (CoAPS) then there is DTLS layer 245 below the CoAP layer. 247 [I-D.richardson-anima-state-for-joinrouter] offers some additional 248 mechanisms, one of which involves dynamically created IPIP tunnels. 249 If these mechanisms are in use, then the southbound interface would 250 need to support these options as well. 252 The Pledge Interface requires a TLS ServerCertificate, and 253 Section 5.1 discusses option for creating this certificate. 255 The Pledge Inteface does not require a public IP address, nor does it 256 have have to run on port 443. 258 In an ACP application ([I-D.ietf-anima-autonomic-control-plane]), the 259 Pledge Interface SHOULD have an IPv6 ULA address from the prefix 260 allocated to the ACP. Section 2 provides some options for how the 261 Pledge Interface can be best connected to the ACP. 263 Outside of the ACP context, running the Pledge interface on an IP 264 address that has a FQDN that resolves to that IP address (if only 265 internally), and operating it on port 443 may have operational 266 advantages. 268 1.3.2. MASA client (Northbound Interface) 270 The MASA client interface connects outward to the Internet to speak 271 to the Manufacturer Authorized Signing Authority (MASA). This is a 272 TLS Client interface. 274 Use of a TLSClientCertificate is RECOMMENDED as this may be the best 275 way for a manufacturer to identify clients. Section 5.2 discusses 276 options for signing this certificate. 278 The MASA client interface is outgoing only and does not require any 279 special connectivity. It may be placed behind a typical enterprise 280 or residential NAT44 gateway. IPv6 connectivity is RECOMMENDED. It 281 does need access to DNS, and the DNS lookups SHOULD be validated with 282 DNSSEC. 284 The MASA client interface will need to validate the server 285 certificates of the MASA, and to do this it will need access to the 286 common public WebPKI ([WebPKI]) trust anchors to validate the MASA. 287 The MASA client MAY also require access to a database of pinned 288 certificates to validate specific manufacturers as called out for in 289 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.8 and section 5.4. 291 1.3.3. Join Proxy (Southbound Interface) 293 In the ACP context, the Registrar is expected to have a Join Proxy 294 operating on the Southbound Interface in order to announce the 295 existence of the Registrar to the local network, for the benefit of 296 directly connected devices. This permits the machines in the NOC 297 itself to autonomically join the domain. 299 The Join Proxy MAY announce the IP address (ULA) and port of the 300 actual Pledge Interface, rather than announcing a link-local address 301 and then performing a proxy operation. 303 1.3.4. EST and BRSKI GRASP announcements 305 As specified in [I-D.ietf-anima-bootstrapping-keyinfra] section 4.3, 306 in an ACP context, the Registrar MUST announce itself inside the ACP 307 using GRASP. The Registrar MUST incorporate enough of a GRASP daemon 308 in order to perform the M_FLOOD announcements. 310 As specified in [I-D.ietf-anima-autonomic-control-plane] section 311 6.1.2, in an ACP context, if the Registrar will also be providing for 312 renewal of certificates using EST, then it SHOULD announce itself 313 inside the ACP using GRASP. Unless made impossible due to loading 314 concerns, it is RECOMMENDED that all Registrar instances offer 315 certificate renewal services in this fashion. 317 The use of [I-D.ietf-acme-star] Short-Term Automatically-Renewed 318 Certificates is RECOMMENDED. This mandates that the EST server be 319 highly available. If STAR-style renewals are not used, then the 320 Certificate Authority will need to make OCSP or CRL Distribution 321 points available. 323 1.3.5. Certificate Authority 325 If the Enterprise/ISP has an existing certificate authority system 326 that it wishes to use, then an interface to it has to be enabled. 327 This may run protocols like EST, CMP or ACME. 329 Smaller Enterprises and Residential uses of BRSKI are encouraged to 330 use an internal (private) certificate authority. See Section 3 for a 331 discussion of securing this CA. 333 1.3.6. Management Interface 335 The Registrar will require a management interface. As is the trend, 336 this will often be a web-based single page application using AJAX API 337 calls to perform communications. This interface SHOULD be made 338 available on the Southbound NOC interface only, and it MUST be on a 339 different IP address and port number then the BRSKI-EST interface. 340 It should be secured with HTTPS, and use of a public ([WebPKI]) 341 anchor is reasonable as it may be that the internal certificate 342 authority may be unavailable or require maintenance. 344 An entirely separate process is justified with the only connection to 345 the other procesess being the database. (This does not mean it can 346 not share code modules) 348 2. Connecting the Autonomic Control Plane to the Network Operations 349 Center (NOC) 351 [I-D.ietf-anima-autonomic-control-plane] section 8.1 describes a 352 mechanism to connect non-ACP capable systems to the ACP. The use of 353 this mechanism is critical to incremental deployment of ANIMA and 354 BRSKI in operators. 356 The deployment of BRSKI capable equipment would ideally occur in a 357 concentric ring outward from the NOC. This would start by an upgrade 358 of the router that connects the NOC to the production network. This 359 device needs to support the ACP connect functionality. 361 It is possible, but beyond the scope of this document, to do initial 362 connectivity of the ACP and of multiple NOCs by manually configured 363 IPsec tunnels. This is likely an important step for incremental 364 initial deployment. 366 The Registrar described in the next section either needs to be 367 connected via one of the above mentioned tunnels, or it must be 368 located on a network with ACP Connect, or it must itself be part of 369 an automatically configured ACP. It is quite reasonable for the 370 Registrar to be part of a larger appliance that also includes an ACP 371 Connect functionality. 373 3. Public Key Infrastructure Recommendations for the Registrar 375 The Registrar requires access to, or must contain a Certificate 376 Authority (CA). 378 This section deals with the situation where the CA is provided 379 internally. [I-D.friel-acme-integrations] deals with the case where 380 the CA is provided by an external service, and the CA trust anchors 381 are public. These use ACME ([RFC8555]) is used as the interface. 382 That is out of scope for this document. 384 There are also a number of commercial offerings where a private CA is 385 operated by an external entity using a wide variety of protocols, 386 including proprietary ones. Those are also out of scope for this 387 document. 389 The requirements for the PKI depends upon what kind of network is 390 being managed. 392 3.1. PKI recommendations for Tier-1/ISP Networks 394 A three-tier PKI infrastructure is appropriate for an ISP. This 395 entails having a root CA created with the key kept offline, and a 396 number of intermediate CAs that have online keys that issue "day-to- 397 day" certificates. 399 Whether the root private key is secured by applying secret-splitting, 400 and then storing the results on multiple USBs key kept in multiple 401 safes, or via Hardware Security Module is a local decision informed 402 by best current practices. 404 The root CA is then used to sign a number of intermediate entities: 405 this will include an intermediate CA for the Registrar that is 406 deployed into each redundant NOC location. Multiple intermediate CAs 407 with a common root provides significantly more security and 408 operational flexibility than attempts to share a private key among 409 locations. 411 While the root CA should have a longevity of at least 5 years, after 412 which it can be resigned rather than re-generated, the intermediate 413 CA keys need only have a 1-2 year duration, and at the end of their 414 lifetime, a new private key should be generated. Shorter periods are 415 possible, but until there is more experience with them, not 416 recommended. The intermediate CA key should be regenerated because 417 the intermediate CA private key will need to be online, available to 418 the Registrar CA system. There are many more opportunities for the 419 key to leak, such as into backups. 421 The intermediate CA is then used to sign End-Entity certificates 422 which are returned as part of the BRSKI-EST mechanism. 424 The Registrar needs client and server certificates for it's BRSKI-EST 425 and BRSKI-MASA connections. It is recommended that an additional 426 intermediate CA be created for manually issued certificates such as 427 these. This intermediate CA could be called the NOC Infrastructure 428 CA, and could be used to issue certificates for all manner of 429 infrastructure such as web-based monitoring tools. The private root 430 CA certificate should be installed into the browsers of NOC 431 personnel. 433 The document [I-D.moskowitz-ecdsa-pki] provides some practical 434 instructions on setting up this kind of system. This document 435 recommends the use of ECDSA keys for the root and intermediate CAs, 436 but there may be operational reasons why an RSA intermediate CA will 437 be required for some legacy equipment. 439 3.2. Enterprise Network 441 Enterprises that have multiple Network Operations Center should 442 consider the recommendations above for an ISP. 444 This section applies to Enterprises that have all NOC operations/ 445 personel into a single location. This is not a hard rule for 446 scaling, but the intent is that physical security for the ACP Connect 447 network is rather easy, that only a single legal jurisdiction will 448 apply, and that it is possible to get people together easily to do 449 things like resign keys. 451 A three-tier PKI infrastructure is still recommended for the reason 452 that it provides operational continuity options not available with a 453 two-level system. The recommendation is to have a root CA mechanism 454 installed on a Virtual Machine which is not connected to a network. 455 The root CA private key is kept offline, secret split among a number 456 of USB keys, kept in the possession of key personnel. 458 The secret split should have at least five components, of which at 459 least three are required to reconstruct the key. See 460 [I-D.hallambaker-mesh-udf] section 4.5 for one such mechanism, there 461 are many others, and there are no interoperability requirements for 462 the secret split. 464 The essential point is that the Enterprise is able to recover the 465 root CA key even without some number of personnel and is able to 466 continue operating it's network. 468 As in the ISP case, the intermediate CA is then used to sign End- 469 Entity certificates which are returned as part of the BRSKI-EST 470 mechanism. One intermediate CA key suffices as there is only one NOC 471 location with a Registrar. Incidental keys for internal operations, 472 and for the BRSKI-EST server certificate can be done with this single 473 intermediate CA. 475 The BRSKI-MASA TLS Client Certificate key for an enterprise may not 476 be needed; it depends upon the policies of the manufacturers which 477 are involved. It may be simpler to use a certificate produced by a 478 public CA (such as LetsEncrypt), as this makes it easier for 479 manufacturers to validate the provided certificate. 481 The document [I-D.moskowitz-ecdsa-pki] provides some practical 482 instructions on setting up this kind of system. This document 483 recommends the use of ECDSA keys for the root and intermediate CAs. 484 In an Enterprise, there are likely many more legacy devices that 485 might need to become involved in the secure domain. It is 486 recommended that an RSA root and intermediate CA be more strongly 487 considered. 489 3.3. Home Network 491 Home networks and small offices that use residential class equipment 492 are the most challenging situation. The three-tier PKI architecture 493 is not justified because the ability to keep the root CA offline has 494 no operational value. 496 The home network registrar should be initialized with a single key 497 pair used as the certificate authority. 499 Secret splitting is useful in order to save the generated key with a 500 few neighbours. It is recommended that the entire PKI system 501 database (including CA private key) be encrypted with a symmetric key 502 and the results made available regularly for download to a variety of 503 devices. The symmetric key is split among the neighbours. 505 The most difficult part of the Home Network PKI and Registrar is 506 where to locate it. Generally it should be located on a device that 507 is fully owned by the home user. This is sometimes the Home Router, 508 but in a lot of situations the Home Router is the ISP's CPE router. 509 If the home has a Network Attached Storage (NAS) system, then running 510 it there is probably better. 512 A compromise for CPE devices owned by the ISP that can run containers 513 is for the Registrar to be located on detachable storage that is 514 inserted into the CPE. The detachable storage is owned by the home 515 owner, and can be removed from the CPE device if it is replaced. 516 More experience will be necessary in order to determine if this is a 517 workable solution. 519 4. Architecture Considerations for the Registrar 521 There are a number of ways to scale the Registrar. Web framework 522 three-tier mechanisms are the most obvious. See [threetier] for an 523 overview. This architecture is very familiar and can work well for a 524 Registrar. There are a few small issues that need to be addressed 525 relating to the TLS connections. 527 The BRSKI-EST connection uses TLS Client Certificate information, so 528 it is necessary for the presentation tier to pass the entire 529 certificate through to the application layer. The presentation tier 530 MUST accept all Client Certificates, many of which might it might not 531 have anchors for. 533 In addition, the Registrar Voucher-Request MUST be signed using the 534 same key pair that is used to terminate the TLS connection, so the 535 application layer will need access to the same keypair that the 536 presentation tier uses. This can be operationally challenging if the 537 presentation tier is provided by a hardware-based TLS load balancer. 539 For this reason, an alternate architecture where the front-end load 540 balancer provides TCP level load balancing, leaving the TLS 541 operations to software TLS implementations in the application layer 542 may be simpler to build. Given that the Registrar is an inward 543 facing system, and is not subject to the Internet-scale loads typical 544 of "Black Friday" web system, the same kind of extreme scaling is not 545 necessary. 547 The BRSKI-EST flow includes a back-end call to the BRSKI-MASA flow. 548 That is, during the BRSKI-EST /voucherrequest call, a voucher will 549 need to be fetched from the MASA using a BRSKI-MASA connection. 550 There are three ways to do this. 552 4.1. Completely Synchronous Registrar 554 In this simplest version the Registrar operates as a single thread, 555 processing the voucher-request from the Pledge, and then starting a 556 BRSKI-MASA client session, while the connection from the Pledge 557 waits. 559 This flow is very simple to implement, but requires an entire 560 processing thread to block while the BRSKI-MASA protocol executes. 561 The Pledge may timeout on this request, disconnect and retry. 562 Experience so far is that typical default timeouts work fine. 564 It is recommended that the voucher-request be recorded in a database, 565 and if a corresponding fresh voucher is also found in the database, 566 that it be returned rather than fetching a new voucher from the MASA. 568 This accomodates the situation where the Pledge did timeout, but the 569 BRSKI-MASA protocol did complete. This results in the Pledge 570 receiving the voucher upon retrying without having to go through the 571 process of getting a new voucher. This only works if the Pledge 572 retries with the same Nonce each time. 574 4.2. Partially Synchronous Registrar 576 A slightly more complicated version is for the Registrar to look in a 577 database for a matching voucher-request, and if none is found, to 578 return a 202 code upon the voucher-request, asking the Pledge to 579 retry. 581 In the meantime the BRSKI-MASA connection can be performed, and the 582 resulting voucher stored in a database. The connection can be done 583 in the same thread that just deferred the connection, or in another 584 thread kicked off for this purpose. 586 4.3. Asynchronous Registrar 588 In the completely asynchronous architecture, things work as with the 589 Partially Synchronous version. The voucher request is placed into a 590 database as before. 592 A completely separate system, probably with different network 593 connectivity, but connected to the same database, performs the BRSKI- 594 MASA processing, then fills the database with the answer. 596 This version may have a noticeably higher latency as it requires a 597 database operation and a database trigger to invoke the process. 598 This architecture has the advantage that the internal facing 599 Registrar never connects to the Internet. Furthermore, the number of 600 internal facing Registrar instances can be tuned independently from 601 the number of outward facing clients. This may be an advantage for 602 networks that need to deal with a high number of malicious or lost 603 internal clients. 605 5. Certificates needed for the Registrar 607 In addition to hosting a PKI root, the Registrar needs several other 608 key pairs. They are: 610 5.1. TLS Server Certificate for BRSKI-EST 612 A certificate to be used to answer TLS connections from new devices 613 (pledges). This must be of a type that expected pledges can 614 understand. Returning an RSA key to a client that can validate only 615 ECDSA chains is a problem. The constrained IoT ecosystem prefers 616 ECDSA, and often does not have code that can verify RSA. Meanwhile, 617 older FIPS-140 validated libraries present in many router operating 618 systems support only RSA! 620 The recommendation is to use ECDSA keys, with a sensitiviity to when 621 a majority of systems might support EdDSA. There are well 622 established mechanisms in most TLS server libraries to permit 623 multiple certificates to be loaded and to return an appropriate key 624 based upon the client capabilities. This should be used. 626 The certificate used for the BRSKI-EST end point is not validated by 627 the BRSKI pledge using public trust anchors, but rather it is pinned 628 by the [RFC8366] voucher. As such it can come from the private CA, 629 as recommended above: either signed by a specific intermediate CA or 630 via a root CA as appropriate for the environment. 632 5.2. TLS Client Certificate for BRSKI-MASA 634 A certificate may optionally be used for authentication of the 635 Registrar to the MASA. It is recommended to always include one. 637 It can be the same certificate used by TLS Server Certificate above, 638 and this is most appropriate in small Registrars which are not 639 distributed, such as ones aimed as Residential/Home networks. 641 In larger, distributed Registrars, cryptographic hygiene dictates 642 that the private key not be distributed, so a unique certificate per 643 Registrar client is appropriate. They should all be signed by the 644 same intermediate CA, with the intermediate and root CA certificates 645 being supplied in the TLS connection. 647 5.2.1. Use of Publically Anchored TLS Client Certificate with BRSKI- 648 MASA connection 650 The use TLS Client Certificate which has a public anchor (such as 651 from LetsEncrypt) has an advantage that is makes it easier for the 652 MASA to reject malicious clients. 654 If the Registrar is not using a supply chain integration that 655 includes the MASA being aware of the cryptographic identity of the 656 Registrar, then the use of a publically anchored certificate is 657 RECOMMENDED. 659 5.3. Certificate for signing of Voucher-Requests 661 As part of the BRSKI voucher-request process the Pledge's Voucher- 662 Request is wrapped by the Registrar in another voucher-request and 663 signed. It is this certificate which which pinned by MASA to 664 validate the connection. 666 The certificate used to sign the voucher-request MUST be the same as 667 the one that is used for the TLS Server Connection. This implies 668 that the signed voucher-request MUST be constructed on the same 669 machine that terminates the BRSKI-EST MASA connection. 671 6. Autonomic Control Plane Addressing 673 In the Enterprise and ISP use cases, the creation of an 674 [I-D.ietf-anima-autonomic-control-plane] Autonomic Control Plane is 675 assumed. (The use of an ACP for the Home Network of IoT devices is 676 considered unnecessary due to HNCP) 678 In these context the certificates which are returned by the Registrar 679 MUST contain a unique IPv6 ULA address. {{-ACP} section 6.10 outlines 680 several addressing schemes for the ULA addresses. The use of the ACP 681 Vlong Addressing Sub-Scheme (6.10.5) is recommended as it provides 682 the most flexibility for devices. 684 The use of this mode limits the number of nodes in the network to 685 between 32768 and 8 Million. 32K routers in an ISP network seems like 686 quite a lot already, but use of F=0 addresses provides for up to 8 687 Million devices, each with 256 management end points. 689 It should be noted that a mix of F=0 and F=1 addresses may be used, 690 but the BRSKI protocol does not directly provide a way to negotiated 691 this. This could be done as part of the Certificate Signing Request: 692 the device could decide which kind of address to ask for by changing 693 the address that it asks for, but this is non-standardized and may 694 not work. 696 A network manager that saw that a device was running out of F=0 697 space, that is if 256 addresses was not enough for a device, could 698 allocate an F=1 address in a management interface. At the next 699 certificate renewal (which could be forced by a management action), 700 then a new certificate would be issues with the larger address space. 702 256 addresses for a single device may seem like a lot, but it is 703 increasing the case that routers may have a large number of 704 virtualized functions within and each may reasonably need to be 705 separately connected to it's SDN controller. 707 7. Privacy Considerations 709 Section 10.2 of [I-D.ietf-anima-bootstrapping-keyinfra] details a 710 number of things that are revealed by the BRSKI-EST protocol. A 711 multi-location Registrar with different TLS Server Certificates will 712 have a different privacy profile than a Registrar that uses only a 713 single certificate. 715 Section 10.3 of [I-D.ietf-anima-bootstrapping-keyinfra] details what 716 is revealed by the BRSKI-MASA protocol. The operational 717 recommendations of this document do not affect or mitigate things at 718 all. 720 8. Security Considerations 722 Section 11 of [I-D.ietf-anima-bootstrapping-keyinfra] does not deal 723 with any attacks against the Registrar, as the Registrar is 724 considered to be an internally facing system. 726 In the context of the Autonomic Control Plane 727 ([I-D.ietf-anima-bootstrapping-keyinfra] section 9, and 728 [I-D.ietf-anima-autonomic-control-plane]) it is expected that the 729 majority of equipment attached to a network are connected by wired 730 ethernet. The opportunity for a massive attack against the Registrar 731 is considered low in an ISP, or multi-side Enterprise backbone 732 network. 734 8.1. Denial of Service Attacks against the Registrar 736 However, there are some exposures which need to be taken into 737 account, particular in the Enterprise or Institutional Campus 738 network: typically these networks have large number of access ports, 739 one for each desktop system. Those systems can be infected with 740 Malware, or may be located in student computer labs physically 741 accessible with minimal authorization. While an attack on the 742 Registrar might be part of some kind of student protest, an attack by 743 malware seems more likely. 745 The different architectures proposed in Section 4 of this document 746 provides some recommendations on differing scales. The use of a 747 fully asynchronous design is recommended for Enterprise uses of BRSKI 748 where there may be a large number of IoT devices that are expected to 749 onboard. The ability to scale the BRSKI-EST Pledge Interface without 750 having the scale the rest of the system provides for resiliency of 751 the Registrary. 753 It bears repeating that the use of of a stateless technology in the 754 Join Proxy moves the load due to attacking systems from the Join 755 Proxy into the Registrar. This increases the network bandwidth 756 required from the Join Proxy to the Registrar with the benefit of 757 simplifying the Join Proxy. 759 This is an intentional design decision to centralize the impact into 760 the purpose built Registrar system(s). 762 8.2. Loss of Keys/Corruption of Infrastructure 764 In Home/Residential Network ("homenet") uses of 765 [I-D.ietf-anima-bootstrapping-keyinfra] the biggest risk is likely 766 that of loss of the Registrar's key pairs. Not to a malicious entity 767 that steals them with intent to cause damage, but from outright loss. 769 This can be due to failure to backup the database followed by a CPE 770 device failure, but the case where a CPE device is simply thrown away 771 to be replaced by an uninformed technician is probably the most 772 likely situation. 774 This situation results in loss of control for all devices in the 775 home, and much frustration from the home owner who has to go through 776 an onboarding process for all the devices. The use of a standardized 777 onboarding protocol significantly mitigates the hassle; the current 778 "state of the art" proccess involves a series of appliance-specific 779 smartphone applications, which may or not not actually work on more 780 recent devices. 782 This is why the focus on saving of the database along with a secret 783 splitting process to secure it. At present there is no cross-vendor 784 format for this database, so the saved data is only useable with a 785 Registrar from the same vendor. So this protects against device 786 failure, where it is replaced by an identical device or an upward 787 compatible device from the same manufacturer, but not against changes 788 of vendor. 790 9. IANA Considerations 792 This document makes no IANA allocations. 794 10. Acknowledgements 796 Your name here. 798 11. Changelog 800 12. References 802 12.1. Normative References 804 [I-D.ietf-acme-star] 805 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 806 Fossati, "Support for Short-Term, Automatically-Renewed 807 (STAR) Certificates in Automated Certificate Management 808 Environment (ACME)", Work in Progress, Internet-Draft, 809 draft-ietf-acme-star-11, 24 October 2019, 810 . 813 [I-D.ietf-anima-autonomic-control-plane] 814 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 815 Control Plane (ACP)", Work in Progress, Internet-Draft, 816 draft-ietf-anima-autonomic-control-plane-21, 3 November 817 2019, . 820 [I-D.ietf-anima-bootstrapping-keyinfra] 821 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 822 and K. Watsen, "Bootstrapping Remote Secure Key 823 Infrastructures (BRSKI)", Work in Progress, Internet- 824 Draft, draft-ietf-anima-bootstrapping-keyinfra-30, 17 825 November 2019, . 828 [I-D.ietf-anima-constrained-voucher] 829 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 830 Voucher Artifacts for Bootstrapping Protocols", Work in 831 Progress, Internet-Draft, draft-ietf-anima-constrained- 832 voucher-05, 8 July 2019, . 835 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 836 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 837 May 2017, . 839 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 840 "A Voucher Artifact for Bootstrapping Protocols", 841 RFC 8366, DOI 10.17487/RFC8366, May 2018, 842 . 844 12.2. Informative References 846 [I-D.friel-acme-integrations] 847 Friel, O., Barnes, R., and R. Shekh-Yusef, "ACME 848 Integrations", Work in Progress, Internet-Draft, draft- 849 friel-acme-integrations-02, 24 October 2019, 850 . 853 [I-D.hallambaker-mesh-udf] 854 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 855 Data Fingerprint.", Work in Progress, Internet-Draft, 856 draft-hallambaker-mesh-udf-07, 18 October 2019, 857 . 860 [I-D.moskowitz-ecdsa-pki] 861 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 862 "Guide for building an ECC pki", Work in Progress, 863 Internet-Draft, draft-moskowitz-ecdsa-pki-07, 13 August 864 2019, . 867 [I-D.richardson-anima-state-for-joinrouter] 868 Richardson, M., "Considerations for stateful vs stateless 869 join router in ANIMA bootstrap", Work in Progress, 870 Internet-Draft, draft-richardson-anima-state-for- 871 joinrouter-02, 25 January 2018, . 875 [ieee802-1AR] 876 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 877 2009, . 880 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 881 "Enrollment over Secure Transport", RFC 7030, 882 DOI 10.17487/RFC7030, October 2013, 883 . 885 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 886 Kasten, "Automatic Certificate Management Environment 887 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 888 . 890 [threetier] 891 Wikipedia, ., "Multitier architecture", December 2019, 892 . 894 [WebPKI] CA/Browser Forum, ., "CA/Browser Forum Baseline 895 Requirements for the Issuance and Management of Publicly- 896 Trusted Certificates, v.1.2.2", October 2014, 897 . 899 Author's Address 900 Michael Richardson 901 Sandelman Software Works 903 Email: mcr+ietf@sandelman.ca