idnits 2.17.1 draft-richardson-anima-masa-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 492, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 512, but no explicit reference was found in the text == 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 (-10) exists of draft-moskowitz-ecdsa-pki-07 ** Downref: Normative reference to an Informational draft: draft-moskowitz-ecdsa-pki (ref. 'I-D.moskowitz-ecdsa-pki') == Outdated reference: A later version (-08) exists of draft-richardson-anima-registrar-considerations-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' Summary: 1 error (**), 0 flaws (~~), 8 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 5 December 2019 5 Expires: 7 June 2020 7 Operational Considerations for Manufacturer Authorized Signing Authority 8 draft-richardson-anima-masa-considerations-02 10 Abstract 12 This document describes a number of operational modes that a BRSKI 13 Manufacturer Authorized Signing Authority (MASA) 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 MASA is 17 deployed into. This document does not change any protocol 18 mechanisms. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 7 June 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Operational Considerations for Manufacturer IDevID Public Key 55 Infrastructure . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. On-device private key generation . . . . . . . . . . . . 4 57 2.2. Off-device private key generation . . . . . . . . . . . . 4 58 2.3. Public Key infrastructure for IDevID . . . . . . . . . . 5 59 3. Operational Considerations for Manufacturer Authorized Signing 60 Authority (MASA) . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Self-contained multi-product MASA . . . . . . . . . . . . 7 62 3.2. Self-contained per-product MASA . . . . . . . . . . . . . 7 63 3.3. Per-product MASA keys intertwined with IDevID PKI . . . . 8 64 3.4. Rotating MASA authorization keys . . . . . . . . . . . . 9 65 4. Operational Considerations for Constrained MASA . . . . . . . 9 66 5. Operational Considerations for creating Nonceless vouchers . 10 67 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 11.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 [I-D.ietf-anima-bootstrapping-keyinfra] introduces a mechanism for 80 new devices (called pledges) to be onboarded into a network without 81 intervention from an expert operator. 83 This mechanism leverages the pre-existing relationship between a 84 device and the manufacturer that built the device. There are two 85 aspects to this relationship: the provision of an identity for the 86 device by the manufacturer (the IDevID), and a mechanism which 87 convinces the device to trust the new owner (the [RFC8366] voucher). 89 The manufacturer, or their designate, is involved in both aspects of 90 this process. This requires the manufacturer to operate a 91 significant process for each aspect. 93 This document offers a number of operational considerations for each 94 aspect. 96 The first aspect is the device identity in the form of an 97 [ieee802-1AR] certificate that is installed at manufacturing time in 98 the device. The first section of this document deals with 99 operational considerations of building this public key 100 infrastructure. 102 The second aspect is the use of the Manufacturer Authorized Signing 103 Authority (MASA), as described in 104 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.5.4. The device 105 needs to have the MASA anchor built in; the exact nature of the 106 anchor is subject to a many possibilities. The second section of 107 this document deals with a number of options for architecting the 108 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 are 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 IDevID Public Key 118 Infrastructure 120 The manufacturer has the responsability to provision a keypair into 121 each device as part of the manufacturing process. There are a 122 variety of mechanisms to accomplish this, which this document will 123 overview. 125 There are two fundamental ways to generate IDevID certificates for 126 devices: 128 1) generating a private key on the device, creating a Certificate 129 Signing Request (or equivalent), and then returning a certificate to 130 the device. 132 2) generating a private key outside the device, signing the 133 certificate, and the installing both into the device. 135 There is a third situation where the IDevID is provided as part of a 136 Trusted Platform Module (TPM), in which case the TPM vendor may be 137 making the same tradeoffs. Or the mechanisms to install the 138 certificate into the TPM will use TPM APIs. 140 The document [I-D.moskowitz-ecdsa-pki] provides some practical 141 instructions on setting up a reference implementation for ECDSA keys 142 using a three-tier mechanism. This document recommends the use of 143 ECDSA keys for the root and intermediate CAs, but there may be 144 operational reasons why an RSA intermediate CA will be required for 145 some legacy TPM equipment. 147 2.1. On-device private key generation 149 Generating the key on-device has the advantage that the private key 150 never leaves the device. The disadvantage is that the device may not 151 have a verified random number generator. 153 There are a number of options of how to get the public key securely 154 from the device to the certification authority. This transmission 155 must be done in an integral manner, and must be securely associated 156 with the assigned serial number. The serial number goes into the 157 certificate, and the resulting certificate needs to be loaded into 158 the manufacturer's asset database. This asset database needs to be 159 shared with the MASA. 161 One way to do the transmission is during a manufacturing during a Bed 162 of Nails (see [BedOfNails]) or Boundary Scan. There are other ways 163 that could be used where a certificate signing request is sent over a 164 special network channel after the system has been started the first 165 time. There are risks with these methods, as an attacker with 166 physical access may be able to put device back into this mode 167 afterwards. 169 2.2. Off-device private key generation 171 Generating the key off-device has the advantage that the randomness 172 of the private key can be better analyzed. As the private key is 173 available to the manufacturing infrastructure, the authenticity of 174 the public key is well known ahead of time. A serial number for the 175 device can be assigned and placed into a certificate. The private 176 key and certificate could be programmed into the device along with 177 the initial bootloader firmware in a single step. 179 The major downside to generating the private key off-device is that 180 it could be seen by the manufacturing infrastructure. This makes the 181 manufacturing infrastructure a high-value attack target, so 182 mechanisms that keep the private key secure within the manufacturing 183 process, yet allow the device to get access to the private key would 184 be adventageous. 186 Per-device keys would be ideal, but that would require that an 187 individual per-device key be provisioned in seperately. An alternate 188 mechanism would be that a constant decryption key is kept in the 189 firmware, but this provides little protection against an attack on 190 the manufacturing infrastructure unless the firmware is loaded in a 191 completely different place than the keypair. 193 2.3. Public Key infrastructure for IDevID 195 A three-tier PKI infrastructure is appropriate. This entails having 196 a root CA created with the key kept offline, and a number of 197 intermediate CAs that have online keys that issue "day-to-day" 198 certificates. 200 The root private key should be kept offline, quite probably in a 201 Hardware Security Module if financially feasible. If not, then it 202 should be secret-split across seven to nine people, with a threshold 203 of four to five people. The split secrets should be kept in 204 geographically diverse places if the manufacturer has operations in 205 multiple places. 207 Ongoing access to the root-CA is important, but not as critical as 208 access to the MASA key. 210 The root CA is then used to sign a number of intermediate entities. 211 If manufacturing occurs in multiple factories, then an intermediate 212 CA for each factory is appropriate. It is also reasonable to use 213 different intermediate CAs for different product lines. It may also 214 be valuable to split IDevID certificates across intermediate CAs in a 215 round-robin fashion for products with high volumes. 217 Cycling the intermediate CAs after a period of a few months or so is 218 a quite reasonable strategy. The intermediate CAs private key may be 219 destroyed after it signed some number of IDevIDs, and a new key 220 generated. The IDevID certificates have very long (ideally infinite) 221 validity lifetimes for reasons that [ieee802-1AR] explains, but once 222 the certificates have been created the intermediate CA has no further 223 obligations as neither CRLs nor OCSP are appropriate. 225 In all cases the serialNumber embedded in the certificate must be 226 unique across all products produced by the manufacturer. This 227 suggests some amount of structure to the serialNumber, such that 228 different intermediate CAs do not need to coordinate when issuing 229 certificates. 231 3. Operational Considerations for Manufacturer Authorized Signing 232 Authority (MASA) 234 The manufacturer needs to make a Signing Authority available to new 235 owners so that they may obtain [RFC8366] format vouchers to prove 236 ownership. This section initially assumes that the manufacturer will 237 provide this Authority internally, but subsequent sections deal with 238 some adjustments when the authority is externally run. 240 The MASA is a public facing web system. It will be subject to loads 241 from legitimate users when a network is bootstrapped for the first 242 time. The legitimate load will be proportional to sales. 244 The MASA will be subject to a malicious load: the best way to deflect 245 unwanted users is to require TLS Client Certificates for all 246 connections, even if the TLS Certificate is not validated. This 247 increases the effort requires for attackers, and if they repeat the 248 same certificate then it becomes easier to reject such attackers 249 earlier. The use of this certificate forces attackers to generate 250 new key pairs and certificates each time. The accompanying document 251 [I-D.richardson-anima-registrar-considerations] recommends in section 252 5.2.1 recommends the use of a public anchor, or an anchor that is 253 known to the MASA. 255 Web framework three-tier mechanisms are the most obvious. See 256 [threetier] for an overview. Consideration should be made to 257 deploying the presentation layer into multiple data centers in order 258 to provide resiliency against distributed denial of service (DDoS) 259 attacks that affect all tenants of that data center. Consideration 260 should be given to the use of a cloud front end to mitigate attacks, 261 however, such a system needs to be able to securely transmit the TLS 262 Client Certificates, it the MASA wants to do supply chain 263 integration. 265 The middle (application) tier needs to be scalable, but it is 266 unlikely that it needs to scale very much on a per-minute or even 267 per-hour basis. It is probably easier and more reliable to have 268 application tiers do database operations across the Internet or via 269 VPN to a single location database cluster than it is to handle 270 asynchronous database operations resulting from geographically 271 dispersed multi-master database systems. The assets tables that the 272 MASA needs scale linearly with the number of products sold. Many 273 columns could be replicated in a read-only manner from a sales 274 database. Direct integration with a sales system could be 275 considered, but would involve a more significant security impact 276 analysis. 278 In any case, the manufacturer SHOULD plan for a situation where the 279 manufacturer is no longer able or interested in running the 280 Authority: this does not have to an unhappy situation of the 281 manufacturer going out of business. It could be a happy event where 282 the manufacturer goes through a merge or acquisition and it makes 283 sense to consolidate the Signing Authority in another part of the 284 organziation. 286 A plan to escrow the signing keys SHOULD be detailed, and it is 287 likely that customers will want to review it for high-value products. 289 The anchors for the MASA need to be "baked-in" to the device firmware 290 so that they are always available to validate vouchers. In order to 291 avoid locking down a single validation key, a PKI infrastructure is 292 appropriate. Note that constrained devices without code space to 293 parse and validate a public key certificate chain require different 294 considerations, and this document does not (yet) provide that 295 consideration. 297 There are many ways to construct a resilient PKI to sign vouchers. 299 3.1. Self-contained multi-product MASA 301 The most obvious is to just create a new offline CA, have it 302 periodically sign a new End-Entity (EE) Certificate with an online 303 private key, and use that to sign voucher requests. The entity used 304 to sign [RFC8366] format vouchers does not need to be a certificate 305 authority. 307 The public key of the offline CA is then built-in to the firmware of 308 the device, providing a trust anchor with with to validate vouchers. 309 In addition, the DN of the appropriate End-Entity certificate needs 310 to built-in to the device, otherwise a voucher created for one 311 product could be used to sign a voucher for another product. This 312 situation is also mitigated by never repeating serialNumbers across 313 product lines. 315 An End-Entity certificate used to sign the voucher is included in the 316 certificate set in the CMS structure that is used to sign the 317 voucher. The root CA's trust anchor should _also_ be included, even 318 though it is self-signed, as this permits auditing elements in a 319 Registrar to validate the End-Entity Certificate. 321 The inclusion of the full chain also supports a Trust-on-First-Use 322 (TOFU) workflow for the manager of the Registrar: they can see the 323 trust anchor chain and can compare a fingerprint displayed on their 324 screen with one that could be included in packaging or other sales 325 channel information. 327 When building the MASA public key into a device, only the public key 328 contents matter, not the structure of the self-signed certificate 329 itself. Using only the public key enables a MASA architecture to 330 evolve from a single self-contained system into a more complex 331 architecture later on. 333 3.2. Self-contained per-product MASA 335 A simple enhancement to the previous scenario is to have a unique 336 MASA offline key for each product line. This has a few advantages: 338 * if the private keys are kept separately (under different 339 encryption keys), then compromise of a single product lines MASA 340 does not compromise all products. 342 * if a product line is sold to another entity, or if it has to go 343 through an escrow process due to the product going out of 344 production, then the process affects only a single product line. 346 * it is safe to have serialNumber duplicated among different product 347 lines since a voucher for one product line would not validate on 348 another product line. 350 The disadvantage is that it requires a private key to be stored per 351 product line, and most large OEMs have many dozens of product lines. 352 If the keys are stored in a single Hardware Security Module (HSM), 353 with the access to it split across the same parties, then some of the 354 cryptographic advantages of different private keys goes away, as a 355 compromise of one key likely compromises them all. Given a HSM, the 356 most likely way a key is compromised is by an attacker getting 357 authorization on the HSM through theft or coercion. 359 The use of per-product MASA signing keys is encouraged. 361 3.3. Per-product MASA keys intertwined with IDevID PKI 363 The IDevID certificate chain (the intermediate CA and root CA that 364 signed the IDevID certificate) should be included in the device 365 firmware so that they can be communicated during the BRSKI-EST 366 exchange. 368 Since they are already present, why not use of them as the MASA trust 369 anchor? 371 A voucher needs to be signed by recognized End-Entity, which has been 372 authorized to be a voucher signer. The challenge with combining it 373 into the IDevID PKI is making sure that only an authorized entity can 374 sign the vouchers. This suggests that it can not be the same 375 intermediate CA that is used to sign the IDevID, since that CA should 376 have the authority to sign vouchers. If it did, then the End- 377 Entities that it created, the IDevID for devices, would then be able 378 to sign vouchers, which would not be an appropriate authorization. 380 The PKI root CA therefore needs to sign an intermediate CA, or End- 381 Entity certificate with an extension OID that is specific for Voucher 382 Authorization. This is easy to do as policy OIDs can be created from 383 Private Enterprise Numbers. There is no need for standardization, as 384 the entity doing the signing is also creating the verification code. 386 If the entire PKI operation was outsource, then there would be a 387 benefit for standardization. 389 3.4. Rotating MASA authorization keys 391 As a variation of the scenario described in Section 3.2, there could 392 be multiple Signing Authority keys per product line. They could be 393 rotated though in some deterministic order. For instance, serial 394 numbers ending in 0 would have MASA key 0 embedded in them at 395 manufacturing time. The asset database would have to know which key 396 that corresponded to, and it would have to produce vouchers using 397 that key. 399 There are significant downsides to this mechanism: 401 * all of the MASA signing keys need to be online and available in 402 order to respond to any voucher request 404 * it is necessary to keep track of which device trust which key in 405 the asset database 407 There is no obvious advantage to doing this if all the MASA signing 408 private keys are kept in the same device, under control of the same 409 managers. But if the keys are spread out to multiple locations and 410 are under control of different people, then there may be some 411 advantage. A single MASA signing authority key compromise does not 412 cause a recall of all devices, but only the portion that had that key 413 embedded in it. 415 The relationship between signing key and device could be temporal: 416 all devices made on Tuesday could have the same key, there could be 417 hundreds of keys, each one used only for a few hundred devices. 418 There are many variations possible. 420 The major advantage comes with the COSE signed constrained-vouchers 421 described in [I-D.ietf-anima-constrained-voucher]. In this context 422 there isn't space in the voucher for a certificate chain, nor is 423 there code space in the device to validate a certificate chain. The 424 (public) key used to sign is embedded directly in the firmware of 425 each device without the benefit of any public key infrastructure to 426 allow indirection of the key. 428 4. Operational Considerations for Constrained MASA 430 TBD 432 5. Operational Considerations for creating Nonceless vouchers 434 TBD 436 6. Privacy Considerations 438 YYY 440 7. Security Considerations 442 ZZZ 444 8. IANA Considerations 446 This document makes no IANA requests. 448 9. Acknowledgements 450 Hello. 452 10. Changelog 454 11. References 456 11.1. Normative References 458 [I-D.ietf-anima-bootstrapping-keyinfra] 459 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 460 and K. Watsen, "Bootstrapping Remote Secure Key 461 Infrastructures (BRSKI)", Work in Progress, Internet- 462 Draft, draft-ietf-anima-bootstrapping-keyinfra-30, 17 463 November 2019, . 466 [I-D.ietf-anima-constrained-voucher] 467 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 468 Voucher Artifacts for Bootstrapping Protocols", Work in 469 Progress, Internet-Draft, draft-ietf-anima-constrained- 470 voucher-05, 8 July 2019, . 473 [I-D.moskowitz-ecdsa-pki] 474 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 475 "Guide for building an ECC pki", Work in Progress, 476 Internet-Draft, draft-moskowitz-ecdsa-pki-07, 13 August 477 2019, . 480 [I-D.richardson-anima-registrar-considerations] 481 Richardson, M., "Operational Considerations for BRSKI 482 Registrar", Work in Progress, Internet-Draft, draft- 483 richardson-anima-registrar-considerations-00, 2 December 484 2019, . 487 [ieee802-1AR] 488 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 489 2009, . 492 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 493 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 494 May 2017, . 496 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 497 "A Voucher Artifact for Bootstrapping Protocols", 498 RFC 8366, DOI 10.17487/RFC8366, May 2018, 499 . 501 [threetier] 502 Wikipedia, ., "Multitier architecture", December 2019, 503 . 505 11.2. Informative References 507 [BedOfNails] 508 Wikipedia, "In-circuit test", 2019, 509 . 512 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 513 "Enrollment over Secure Transport", RFC 7030, 514 DOI 10.17487/RFC7030, October 2013, 515 . 517 Author's Address 519 Michael Richardson 520 Sandelman Software Works 522 Email: mcr+ietf@sandelman.ca