idnits 2.17.1 draft-richardson-anima-masa-considerations-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '... RECOMMENDED....' RFC 2119 keyword, line 191: '...the manufacturer SHOULD plan for a sit...' RFC 2119 keyword, line 202: '...tting mechanisms SHOULD be employed. ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 November 2021) is 895 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: 'I-D.richardson-anima-registrar-considerations' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'I-D.moskowitz-ecdsa-pki' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'BedOfNails' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RambusCryptoManager' is defined on line 509, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-richardson-t2trg-idevid-considerations-05 ** Downref: Normative reference to an Informational draft: draft-richardson-t2trg-idevid-considerations (ref. 'I-D.richardson-t2trg-idevid-considerations') == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-14 == Outdated reference: A later version (-08) exists of draft-richardson-anima-registrar-considerations-04 ** Downref: Normative reference to an Informational draft: draft-moskowitz-ecdsa-pki (ref. 'I-D.moskowitz-ecdsa-pki') -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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 W. Pan 5 Expires: 17 May 2022 Huawei Technologies 6 13 November 2021 8 Operatonal Considerations for Voucher infrastructure for BRSKI MASA 9 draft-richardson-anima-masa-considerations-06 11 Abstract 13 This document describes a number of operational modes that a BRSKI 14 Manufacturer Authorized Signing Authority (MASA) 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 MASA is 18 deployed into. This document does not change any protocol 19 mechanisms. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 17 May 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Operational Considerations for Manufacturer Authorized Signing 56 Authority (MASA) . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Deflecting unwanted TLS traffic with Client 58 Certificates . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Web framework architecture . . . . . . . . . . . . . . . 4 60 2.3. Self-contained multi-product MASA, no PKI . . . . . . . . 5 61 2.4. Self-contained multi-product MASA, with one-level PKI . . 6 62 2.5. Self-contained per-product MASA . . . . . . . . . . . . . 7 63 2.6. Per-product MASA keys intertwined with IDevID PKI . . . . 7 64 2.7. Rotating MASA authorization keys . . . . . . . . . . . . 8 65 3. Operational Considerations for Constrained MASA . . . . . . . 9 66 4. Operational Considerations for creating Nonceless vouchers . 9 67 5. Business Continuity and Escow Considerations . . . . . . . . 9 68 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 11.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 [RFC8995] introduces a mechanism for new devices (called pledges) to 81 be onboarded into a network without intervention from an expert 82 operator. 84 This mechanism leverages the pre-existing relationship between a 85 device and the manufacturer that built the device. There are two 86 aspects to this relationship: the provision of an identity for the 87 device by the manufacturer (the IDevID), and a mechanism which 88 convinces the device to trust the new owner (the [RFC8366] voucher). 90 The manufacturer, or their designate, is involved in both aspects of 91 this process. This requires the manufacturer (or designate) to 92 maintain on online presence. 94 This document offers a number of operational considerations 95 recommendations for operating this online presence. 97 The first aspect is the device identity in the form of an 98 [ieee802-1AR] certificate that is installed at manufacturing time in 99 the device. Some of the background for the operational 100 considerations of building this public key infrastructure is 101 described in [I-D.richardson-t2trg-idevid-considerations]. 103 The second aspect is the use of the Manufacturer Authorized Signing 104 Authority (MASA), as described in [RFC8995] section 2.5.4. The 105 device needs to have the MASA anchor built in; the exact nature of 106 the anchor is open to a number of possibilities which are explained 107 in this document. This document primarily deals with a number of 108 options for architecting the security of the MASA relationship. 110 There are some additional considerations for a MASA that deals with 111 constrained vouchers as described in 112 [I-D.ietf-anima-constrained-voucher]. In particular in the COSE 113 signed version, there may be no PKI structure included in the voucher 114 mechanism, so cryptographic hygiene needs a different set of 115 tradeoffs. 117 2. Operational Considerations for Manufacturer Authorized Signing 118 Authority (MASA) 120 The manufacturer needs to make a Signing Authority available to new 121 owners so that they may obtain [RFC8366] format vouchers to prove 122 ownership. This section initially assumes that the manufacturer will 123 provide this Authority internally, but subsequent sections deal with 124 some adjustments when the authority is externally run. 126 The MASA is a public facing web system. It will be subject to 127 network load from legitimate users when a network is bootstrapped for 128 the first time. The legitimate load will be proportional to sales. 130 The MASA will also be subject to a malicious load. 132 2.1. Deflecting unwanted TLS traffic with Client Certificates 134 One way to deflect unwanted users from the application framework 135 backend is to require TLS Client Certificates for all connections. 136 As described in Section 5.5.4 of [RFC8995], the Registrar may be 137 authenticated with a TLS Client Certificate. 139 This offloads much of the defense to what is typically a hardware TLS 140 termination system. This can be effective even if the hardware is 141 unable to do the actual validation of the TLS Client Certificate, as 142 validation of the certificate occurs prior to any communication with 143 the application server. 145 This increases the effort requires for attackers, and if they repeat 146 the same certificate then it becomes easier to reject such attackers 147 if a list of invalid/unwanted clients is cached. 149 The use of a client certificate forces attackers to generate new key 150 pairs and certificates for each attack. 152 2.2. Web framework architecture 154 Web framework three-tier mechanisms are a very common architecture. 155 See [threetier] for an overview. There are Internet scale frameworks 156 exist for Ruby (RubyOnRails), Python (Django), Java (J2EE), GO, PHP 157 and others. The methods of deploying them and dealing with expected 158 scale are common in most enterprise IT departments. 160 Consideration should be made to deploying the presentation layer into 161 multiple data centers in order to provide resiliency against 162 distributed denial of service (DDoS) attacks that affect all tenants 163 of that data center. 165 Consideration should also be given to the use of a cloud front end to 166 mitigate attacks, however, such a system needs to be able to securely 167 transmit the TLS Client Certificates, if the MASA wants to identify 168 Registrars at the TLS connection time. 170 The middle (application) tier needs to be scalable, but it is 171 unlikely that it needs to scale very much on a per-minute or even 172 per-hour basis. It is probably easier and more reliable to have 173 application tiers do database operations across the Internet or via 174 VPN to a single location database cluster than it is to handle 175 asynchronous database operations resulting from geographically 176 dispersed multi-master database systems. 178 But, these are local design decisions which web deployment make on a 179 regular basis. The MASA functionality is not different than other 180 public facing systems. 182 The database tables that the MASA uses scale linearly with the number 183 of products sold, but as they are mostly read-only, they could be 184 easily replicated in a read-only manner from a sales database. 186 Direct integration with a sales system could be considered, but would 187 involve a more significant security impact analysis, so a process 188 where the sales data is extracted to a less sensitive system is 189 RECOMMENDED. 191 In any case, the manufacturer SHOULD plan for a situation where the 192 manufacturer is no longer able or interested in running the 193 Authority: this does not have to an unhappy situation! While the 194 case of the manufacturer going out of business is discussed in 195 Section 5, there are more happy events which should be prepared for. 196 For instance, if a manufacturer goes through a merge or acquisition 197 and it makes sense to consolidate the Signing Authority in another 198 part of the organization. 200 Business continuity plan should include backing up the voucher 201 signing keys. This may involve multiple Hardware Security Modules, 202 and secret splitting mechanisms SHOULD be employed. For large value 203 items, customers are going to need to review the plan as part of 204 their contingency audits. The document 205 [I-D.richardson-t2trg-idevid-considerations] can provide some common 206 basis for this kind of evaluation. 208 The trust anchors needs to validate [RFC8366] vouchers will typically 209 be part of the firmware loaded inot the devie firmware. 211 There are many models to manage these trust anchors, but in order 212 having only a single key, a PKI infrastructure is appropriate, but 213 not required. 215 On constrained devices without code space to parse and validate a 216 public key certificate chain require different considerations, a 217 single key may be necessary. This document does not (yet) provide 218 appropriate considerations for that case. 220 What follows are a number of ways to construct a resilient PKI to 221 sign vouchers. 223 2.3. Self-contained multi-product MASA, no PKI 225 The simplest situation is to create a self-signed End Entity 226 certificate. That is, a public/private key pair. The certificate/ 227 public key is embedded in the products to validate vouchers, and the 228 private part is kept online to sign vouchers. 230 This situation has very low security against theft of a key from the 231 MASA. Such a theft would result in recall of all products that have 232 not yet been onboarded. It is very simple to operate. 234 2.4. Self-contained multi-product MASA, with one-level PKI 236 A simple way is to create an new offline certification authority 237 (CA), have it periodically sign a new End-Entity (EE) identity's 238 certificate. This End-Entity identity has a private key kept online, 239 and it uses that to sign voucher requests. Note that the entity used 240 to sign [RFC8366] format vouchers does not need to be a certificate 241 authority. 243 If the public key of this offline CA is then built-in to the firmware 244 of the device, then the devices do not need any further anchors. 246 There is no requirement for this CA to be signed by any other 247 certification authority. That is, it may be a root CA. There is 248 also no prohibition against it. 250 If this offline CA signs any other certificates, then it is important 251 that the device know which End-Entity certificates may sign vouchers. 252 This is an authorization step, and it may be accomplished it a number 253 of ways: 255 1. the Distinguished Name (DN) of the appropriate End-Entity 256 certificate can be built-in to the firmware 258 2. a particular policy OID may be included in certificates intended 259 to sign vouchers 261 A voucher created for one product could be used to sign a voucher for 262 another product. This situation is also mitigated by never repeating 263 serialNumbers across product lines. 265 An End-Entity certificate used to sign the voucher is included in the 266 certificate set in the CMS structure that is used to sign the 267 voucher. The root CA's trust anchor should _also_ be included, even 268 though it is self-signed, as this permits auditing elements in a 269 Registrar to validate the End-Entity Certificate. 271 The inclusion of the full chain also supports a Trust-on-First-Use 272 (TOFU) workflow for the manager of the Registrar: they can see the 273 trust anchor chain and can compare a fingerprint displayed on their 274 screen with one that could be included in packaging or other sales 275 channel information. 277 When building the MASA public key into a device, only the public key 278 contents matter, not the structure of the self-signed certificate 279 itself. Using only the public key enables a MASA architecture to 280 evolve from a single self-contained system into a more complex 281 architecture later on. 283 2.5. Self-contained per-product MASA 285 A simple enhancement to the previous scenario is to have a unique 286 MASA offline key for each product line. This has a few advantages: 288 * if the private keys are kept separately (under different 289 encryption keys), then compromise of a single product lines MASA 290 does not compromise all products. 292 * if a product line is sold to another entity, or if it has to go 293 through an escrow process due to the product going out of 294 production, then the process affects only a single product line. 296 * it is safe to have serialNumber duplicated among different product 297 lines since a voucher for one product line would not validate on 298 another product line. 300 The disadvantage is that it requires a private key to be stored per 301 product line, and most large OEMs have many dozens of product lines. 302 If the keys are stored in a single Hardware Security Module (HSM), 303 with the access to it split across the same parties, then some of the 304 cryptographic advantages of different private keys will go away, as a 305 compromise of one key likely compromises them all. Given a HSM, the 306 most likely way a key is compromised is by an attacker getting 307 authorization on the HSM through theft or coercion. 309 The use of per-product MASA signing keys is encouraged. 311 2.6. Per-product MASA keys intertwined with IDevID PKI 313 The IDevID certificate chain (the intermediate CA and root CA that 314 signed the IDevID certificate) should be included in the device 315 firmware so that they can be communicated during the BRSKI-EST 316 exchange. 318 Since they are already present, could they be used as the MASA trust 319 anchor as well? 321 In order to do this there is an attack that needs to mitigated. 322 Since the root-CA that creates IDevIDs and the root-CA that creates 323 vouchers are the same, when validating a voucher, a pledge needs to 324 make sure that it is signed by a key authorized to sign vouchers. In 325 other scenarios any key signed by the voucher-signing-root-CA would 326 be valid, but in this scenario that would also include any IDevID, 327 such as would be installed in any other device. Without an 328 additional signal as to which keys can sign vouchers, and which keys 329 are just IDevID keys, then it would be possible to sign vouchers with 330 any IDevID private key, rather than just the designated voucher- 331 signing key. An attacker that could extract a private key from even 332 one instance of a product, could use that to sign vouchers, and 333 impersonate the MASA. 335 The challenge with combining it into the IDevID PKI is making sure 336 that only an authorized entity can sign the vouchers. The solution 337 is that it can not be the same intermediate CA that is used to sign 338 the IDevID, since that CA should have the authority to sign vouchers. 340 The PKI root CA therefore needs to sign an intermediate CA, or End- 341 Entity certificate with an extension OID that is specific for Voucher 342 Authorization. This is easy to do as policy OIDs can be created from 343 Private Enterprise Numbers. There is no need for standardization, as 344 the entity doing the signing is also creating the verification code. 345 If the entire PKI operation was outsource, then there would be a 346 benefit for standardization. 348 2.7. Rotating MASA authorization keys 350 As a variation of the scenario described in Section 2.5, there could 351 be multiple Signing Authority keys per product line. They could be 352 rotated though in some deterministic order. For instance, serial 353 numbers ending in 0 would have MASA key 0 embedded in them at 354 manufacturing time. The asset database would have to know which key 355 that corresponded to, and it would have to produce vouchers using 356 that key. 358 There are significant downsides to this mechanism: 360 * all of the MASA signing keys need to be online and available in 361 order to respond to any voucher request 363 * it is necessary to keep track of which device trust which key in 364 the asset database 366 There is no obvious advantage to doing this if all the MASA signing 367 private keys are kept in the same device, under control of the same 368 managers. But if the keys are spread out to multiple locations and 369 are under control of different people, then there may be some 370 advantage. A single MASA signing authority key compromise does not 371 cause a recall of all devices, but only the portion that had that key 372 embedded in it. 374 The relationship between signing key and device could be temporal: 375 all devices made on Tuesday could have the same key, there could be 376 hundreds of keys, each one used only for a few hundred devices. 377 There are many variations possible. 379 The major advantage comes with the COSE signed constrained-vouchers 380 described in [I-D.ietf-anima-constrained-voucher]. In this context, 381 where there isn't space in the voucher for a certificate chain, nor 382 is there code in the device to validate a certificate chain, a raw 383 public key can sign the voucher. The (public) key used to sign is 384 embedded directly in the firmware of each device without the benefit 385 of any public key infrastructure, which would allow indirection of 386 the key. 388 3. Operational Considerations for Constrained MASA 390 TBD 392 4. Operational Considerations for creating Nonceless vouchers 394 TBD 396 5. Business Continuity and Escow Considerations 398 A number of jurisdictions have legal requirements for businesses to 399 have contingency plans in order to continue operating after an 400 incident or disaster. Specifications include [iso22301_2019], but 401 the problem of continuity goes back over 40 years. 403 The [holman2012] document defined an eight tier process to understand 404 how data would be backed up. Tier 0 is "no off-site data", and would 405 be inappropriate for the MASA's signing key. The question as to how 406 much delay (downtime) is tolerable during a disaster for activating 407 new devices. The consideration should depend upon the type of the 408 device, and what kind of disasters are being planned for. Given 409 current technologies for replicating databases online, a tier-4 410 ("Point-in-time copies") or better solution may be quite economically 411 deployed. 413 A key aspect of the MASA is that it was designed as a component that 414 can be outsourced to a third party, and this third party can leverage 415 economies of scale to provide more resilient systems at much lower 416 costs. 418 The PKI components that are used to provision the IDevID 419 certificiates into new devices need to be operational only when the 420 factory that produces the devices is active. The business continuity 421 planning needs to include provision for backing up the private keys 422 used within the PKI. It may be enough to backup just the root CA 423 key: the rest of the levels of the PKI can be regenerated in another 424 location if necessary. 426 6. Privacy Considerations 428 YYY 430 7. Security Considerations 432 ZZZ 434 8. IANA Considerations 436 This document makes no IANA requests. 438 9. Acknowledgements 440 Hello. 442 10. Changelog 444 11. References 446 11.1. Normative References 448 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 449 "A Voucher Artifact for Bootstrapping Protocols", 450 RFC 8366, DOI 10.17487/RFC8366, May 2018, 451 . 453 [I-D.richardson-t2trg-idevid-considerations] 454 Richardson, M., "A Taxonomy of operational security 455 considerations for manufacturer installed keys and Trust 456 Anchors", Work in Progress, Internet-Draft, draft- 457 richardson-t2trg-idevid-considerations-05, 21 June 2021, 458 . 461 [I-D.ietf-anima-constrained-voucher] 462 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 463 Dijk, "Constrained Bootstrapping Remote Secure Key 464 Infrastructure (BRSKI)", Work in Progress, Internet-Draft, 465 draft-ietf-anima-constrained-voucher-14, 25 October 2021, 466 . 469 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 470 and K. Watsen, "Bootstrapping Remote Secure Key 471 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 472 May 2021, . 474 [I-D.richardson-anima-registrar-considerations] 475 Richardson, M. and J. Yang, "Operational Considerations 476 for BRSKI Registrar", Work in Progress, Internet-Draft, 477 draft-richardson-anima-registrar-considerations-04, 29 478 July 2020, . 481 [I-D.moskowitz-ecdsa-pki] 482 Moskowitz, R., Birkholz, H., Xia, L., and M. C. 483 Richardson, "Guide for building an ECC pki", Work in 484 Progress, Internet-Draft, draft-moskowitz-ecdsa-pki-10, 31 485 January 2021, . 488 [threetier] 489 Wikipedia, ., "Multitier architecture", December 2019, 490 . 492 [ieee802-1AR] 493 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 494 2009, . 497 11.2. Informative References 499 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 500 "Enrollment over Secure Transport", RFC 7030, 501 DOI 10.17487/RFC7030, October 2013, 502 . 504 [BedOfNails] 505 Wikipedia, "In-circuit test", 2019, 506 . 509 [RambusCryptoManager] 510 Qualcomm press release, "Qualcomm Licenses Rambus 511 CryptoManager Key and Feature Management Security 512 Solution", 2014, . 516 [kskceremony] 517 Verisign, "DNSSEC Practice Statement for the Root Zone ZSK 518 Operator", 2017, . 521 [rootkeyceremony] 522 Community, "Root Key Ceremony, Cryptography Wiki", April 523 2020, 524 . 526 [keyceremony2] 527 Digi-Sign, "SAS 70 Key Ceremony", April 2020, 528 . 531 [nistsp800-57] 532 NIST, "SP 800-57 Part 1 Rev. 4 Recommendation for Key 533 Management, Part 1: General", 1 January 2016, 534 . 537 [iso22301_2019] 538 ISO, "ISO 22301: Societal security — Business continuity 539 management systems — Requirements", 1 January 2019, 540 . 542 [holman2012] 543 Holman, E., "A Business Continuity Solution Selection 544 Methodology", 13 March 2012, 545 . 549 Authors' Addresses 551 Michael Richardson 552 Sandelman Software Works 554 Email: mcr+ietf@sandelman.ca 556 Wei Pan 557 Huawei Technologies 559 Email: william.panwei@huawei.com