idnits 2.17.1 draft-richardson-anima-voucher-delegation-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-anima-bootstrapping-keyinfra]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 293 has weird spacing: '...ndatory false...' -- The document date (January 06, 2020) is 1564 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) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-34 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-05 Summary: 1 error (**), 0 flaws (~~), 4 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 January 06, 2020 5 Expires: July 9, 2020 7 Delegated Authority for Bootstrap Voucher Artifacts 8 draft-richardson-anima-voucher-delegation-00 10 Abstract 12 This document describes an extension of the RFC8366 Voucher Artifact 13 in order to support delegation of signing authority. The initial 14 voucher pins a public identity, and that public indentity can then 15 issue additional vouchers. This chain of authorization can support 16 permission-less resale of devices, as well as guarding against 17 business failure of the BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] 18 Manufacturer Authorized Signing Authority (MASA). 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 July 9, 2020. 37 Copyright Notice 39 Copyright (c) 2020 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements for the delegation . . . . . . . . . . . . . 3 56 1.1.1. Disconnected or Offline MASA . . . . . . . . . . . . 3 57 1.1.2. Resale of devices . . . . . . . . . . . . . . . . . . 3 58 1.1.3. Crypto-agility for Registrar . . . . . . . . . . . . 3 59 1.1.4. Transparent Assemblers/Value-Added-Resellers . . . . 4 60 1.2. Overview of proposed solution . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Delegated Voucher artifact . . . . . . . . . . . . . . . . . 5 63 3.1. YANG module . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Bundling of the vouchers . . . . . . . . . . . . . . . . 8 65 3.3. Delegation of multiple devices . . . . . . . . . . . . . 8 66 4. Enhanced Pledge behaviour . . . . . . . . . . . . . . . . . . 8 67 5. Changes to Registrar behaviour . . . . . . . . . . . . . . . 9 68 5.1. Discoverying the most recent Delegated Authority to use . 9 69 6. Applying the delegated voucher to requirements . . . . . . . 10 70 6.1. applicability one . . . . . . . . . . . . . . . . . . . . 10 71 6.2. applicability two . . . . . . . . . . . . . . . . . . . . 10 72 7. Constraints on pinning the Delegated Authority . . . . . . . 10 73 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 9.1. YANG Module Security Considerations . . . . . . . . . . . 11 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 11 78 10.2. YANG Module Names Registry . . . . . . . . . . . . . . . 11 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 13.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Appendix A. Extra references . . . . . . . . . . . . . . . . . . 13 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 The [RFC8366] voucher artifact provides a proof from a manufacturer's 90 authorizing signing authority (MASA) of the intended owner of a 91 device. This is used by an onboarding Pledge device in BRSKI 92 ([I-D.ietf-anima-bootstrapping-keyinfra], 93 [I-D.ietf-anima-constrained-voucher]), and SZTP ([RFC8572]). 95 There are a number of criticisms of the MASA concept. They include: 97 o the MASA must be reachable to the Registar during the onboarding 98 process. 100 o while the use of a nonceless voucher (see {{RFC8366} section 4) 101 can permit the MASA to be offline, it still requires the public 102 key/certificate of the Registrar to be known at issuing time 104 o the MASA must also approve all transfers of ownership, impacting 105 the rights of the initial seller to transfer ownership as they see 106 fit. 108 o if the Registrar has any nonceless vouchers, then it can not 109 change it's public key, nor can it change which certification 110 authority it uses 112 o it is not possible for a MASA to pin ownership to a Registrar by 113 Certification Authority plus DN 115 o the creator of an assembly of parts/components can speak for the 116 entire assembly of parts in a transparent way 118 1.1. Requirements for the delegation 120 This voucher artifact satisfies the following requirements: 122 1.1.1. Disconnected or Offline MASA 124 A Registrar wishes to onboard devices while not being connected to 125 the Internet. 127 1.1.2. Resale of devices 129 An owner of a device wishes to resale devices which have previously 130 been onboarded to a third party without specific authorization from 131 the manufacturer. 133 1.1.3. Crypto-agility for Registrar 135 The owner/manager of a registrar wishes to be able to replace its 136 domain registration key. Replacing the registration key would 137 invalidate any previously acquired (nonceless) vouchers. Any devices 138 which have not been onboarded, or which need to be factory reset, 139 would not trust a replacement key. 141 1.1.4. Transparent Assemblers/Value-Added-Resellers 143 An assembly may consist of a number of parts which are onboarded to a 144 local controller during the manufacturing process. Subsequent to 145 this, the entire assembly will be shipped to a customer who wishes to 146 onboard all the components. The sub-components of the assembly needs 147 to communicate with other sub-components, and so all the parts need 148 to transparently onboarded. (This is contrasted with an assembly 149 where the controller acts as a security gateway. Such a gateway 150 might be a single point of failure) 152 Assemblies may nest quite deeply. 154 1.2. Overview of proposed solution 156 The MASA will issue a voucher that delegates it's signing authority 157 for one or more devices to a specific Registrar. This is called a 158 "delegation voucher". 160 This Registrar can then operate as an authorized signing authority 161 for the manufacturer, and can subsequently issue additional vouchers 162 binding the pledge to new Registrars. 164 This delegation can potentially be repeated multiple times to enable 165 second, third, or n-th level of resale. 167 The delegation voucher may be stored by the pledge for storage, to be 168 included by the pledge in subsequent bootstrap operations. The 169 inclusion of the delegation permits next Registrars with heuristics 170 that permit it to find the delegated authorized signing service 171 (DASA). 173 The delegation voucher pins the identity of the delegated authority 174 using a variety of different mechanisms which are covered in 175 Section 7. 177 2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in 182 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 Delegated Authorized Signing Authority : the Delegated Authorized 186 Signing Authority (DASA) is a service that can generate vouchers 187 for one or more pledges to provide bootstrap authority separate 188 from the manufacturer. 190 Delegation Voucher: a Delegation Voucher is an [RFC8366] format 191 voucher that has additional fields to provide detailed the entity 192 to which authority has been delegated. 194 Intermediate Voucher: a voucher that is not the final voucher 195 linking a pledge to its owner. 197 End Voucher: a voucher that is the final voucher linking a pledge to 198 its owner. 200 3. Delegated Voucher artifact 202 The following tree diagram shows the extensions to the [RFC8366] 203 voucher. 205 There are a few new fields: pinned-delegation-certificate-authority, 206 pinned-delegation-name, delegation-count. In addition, the serial- 207 number field is no longer a plain leaf, but can also be an array. 209 module: ietf-delegated-voucher 211 grouping voucher-delegated-grouping 212 +-- voucher 213 +-- created-on yang:date-and-time 214 +-- expires-on? yang:date-and-time 215 +-- assertion enumeration 216 +-- serial-number string 217 +-- idevid-issuer? binary 218 +-- pinned-domain-cert? binary 219 +-- domain-cert-revocation-checks? boolean 220 +-- nonce? binary 221 +-- last-renewal-date? yang:date-and-time 222 +-- pinned-certificate-authority? binary 223 +-- pinned-certificate-name? binary 224 +-- delegation-voucher? binary 225 +-- intermediate-identities? binary 226 +-- delegation-countdown? int16 228 3.1. YANG module 230 This module uses the grouping that was created in [RFC8366] to extend 231 the definition. 233 file "ietf-delegated-voucher@2020-01-06.yang" 234 module ietf-delegated-voucher { 235 yang-version 1.1; 237 namespace 238 "urn:ietf:params:xml:ns:yang:ietf-delegated-voucher"; 239 prefix "delegated"; 241 import ietf-restconf { 242 prefix rc; 243 description 244 "This import statement is only present to access 245 the yang-data extension defined in RFC 8040."; 246 reference "RFC 8040: RESTCONF Protocol"; 247 } 249 // maybe should import from constrained-voucher instead! 250 import ietf-voucher { 251 prefix "v"; 252 } 254 organization 255 "IETF ANIMA Working Group"; 257 contact 258 "WG Web: 259 WG List: 260 Author: Michael Richardson 261 "; 263 description 264 "This module extends the RFC8366 voucher format to provide 265 a mechanism by which the authority to issue additional vouchers 266 may be delegated to another entity 268 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 269 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 270 and 'OPTIONAL' in the module text are to be interpreted as 271 described in BCP 14 RFC 2119, and RFC8174."; 273 revision "2020-01-06" { 274 description 275 "Initial version"; 276 reference 277 "RFC XXXX: Voucher Profile for Delegation Vouchers"; 278 } 280 rc:yang-data voucher-delegated-artifact { 281 // YANG data template for a voucher. 282 uses voucher-delegated-grouping; 283 } 285 // Grouping defined for future usage 286 grouping voucher-delegated-grouping { 287 description 288 "Grouping to allow reuse/extensions in future work."; 290 uses v:voucher-artifact-grouping { 292 refine voucher/pinned-domain-cert { 293 mandatory false; 294 } 296 augment "voucher" { 297 description "Base the delegated voucher 298 upon the regular one"; 300 leaf pinned-certificate-authority { 301 type binary; 302 description 303 "An subject-public-key-info for a public key of the 304 certificate authority that is to be trusted to issue 305 a voucher to the Registrar. 306 This is not used by end-vouchers."; 307 } 309 leaf pinned-certificate-name { 310 type binary; 311 description 312 "A string for the rfc822Name SubjectAltName contents 313 which will be trusted to issue vouchers. 314 This is not used by end-vouchers."; 315 } 317 leaf delegation-voucher { 318 type binary; 319 description 320 "The intermediate voucher that delegates 321 authority to the entity that signs this voucher 322 is to be included here."; 323 } 325 leaf intermediate-identities { 326 type binary; 327 description 328 "A set of identities that will be needed to 329 validate the chain of vouchers. MAY BE REDUNDANT"; 330 } 332 leaf delegation-countdown { 333 type int16; 334 description 335 "Number of delegations still available. If zero 336 or omitted, then this is a terminal voucher and 337 may not be further delegated"; 338 } 339 } 340 } 341 } 342 } 343 345 3.2. Bundling of the vouchers 347 The [I-D.ietf-anima-bootstrapping-keyinfra] defines a mechanism to 348 return a single voucher to the pledge. 350 This protocol requires a number of additional items to be returned to 351 the pledge for evaluation: the series of Intermediate Vouchers that 352 leads to the DASA, and the public keys (often as certificates) of the 353 Registrars on the Delegation Path that leads to each Authority. 355 3.3. Delegation of multiple devices 357 A MASA MAY delegate multiple devices to the same Registrar by putting 358 an array of items in the "serial-number" attributes. (XXX-how to 359 describe this in the YANG) 361 4. Enhanced Pledge behaviour 363 The use of a delegated voucher requires changes to how the pledge 364 evaluates the voucher that is returned to by the Registrar. 366 There are no significant changes to the voucher-request that is made. 367 The pledge continues to pin the identity of the Registrar to which it 368 is connected, providing a nonce to establish freshness. 370 A pledge which has previously stored a delegation voucher and 371 delegated authority, SHOULD include it in its voucher request. This 372 will be in the form of a certificate provided by the "previous" 373 owner. This allows the Registrar to discover the previous authority 374 for the pledge. As the pledge has no idea if it connecting to an 375 entity that it previously has connected to, it needs to include this 376 certificate anyway. 378 The pledge receives a voucher from the Registrar. This voucher is 379 called the zero voucher. It will observe that the voucher is not 380 signed with its built-in manufacturer trust anchor and it can not 381 verify it. 383 The pledge will examine the voucher to look for the "delegation- 384 voucher" and the intermediate-identities attributes within the 385 voucher. A certificate from the set of intermediate-identities is 386 expected to validate the signature on this zeroth end-entity voucher. 387 (XXX- This attribute can be replaced by the CMS certificate chain) 389 The contained delegation-voucher object is to be interpreted as an 390 (intermediate) voucher. This first voucher is called the first 391 voucher, or "voucher[1]". Generically, for voucher[i], the voucher 392 found in the delegation-voucher is called voucher[i+1]. 394 If voucher[i] can be validated by a built-in trust anchor, then the 395 process is done. If not, then voucher[i] is examined in a recursive 396 process until no there are no further embedded vouchers. The last 397 voucher[n] is expected to be validated by a built-in manufacturer 398 trust anchor. 400 Once the top (n-th) voucher is found, then the pinned-certificate- 401 authority is added to the working set of trust anchors. The pinned- 402 certificate-name attribute is used along with the trust anchor to 403 validate the certificate chain provided with the n-1th voucher. This 404 is repeated (unwinding the recursive processing) until the zeroth 405 voucher has been validated. 407 5. Changes to Registrar behaviour 409 TBD 411 5.1. Discoverying the most recent Delegated Authority to use 413 The pledge continues to use its manufacturer issued IDevID when 414 performing BRSKI-style onboarding. The IDevID contains an extension, 415 the MASA URL (see [I-D.ietf-anima-bootstrapping-keyinfra] section 416 2.3.2). The IDevID certificate is not expected to be updated when 417 the device is resold, nor may it be practical for an intermediate 418 owner to be able to replace the IDevID with their own. (Some devices 419 may support having an intermediate owner replace the IDevID, in which 420 case this section does not apply) 422 The Registrar needs to be informed that it should not contact a MASA 423 using the URL in the IDevID, but rather to contact the previous 424 owner's DASA. 426 This can be accomplished by local override, as described in 427 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4: 429 Registrars MAY include a mechanism to override 430 the MASA URL on a manufacturer-by-manufacturer basis, and within that 431 override it is appropriate to provide alternate anchors. This will 432 typically used by some vendors to establish explicit (or private) 433 trust anchors for validating their MASA that is part of a sales 434 channel integration. 436 The above override needs to be established on a per-device basis. It 437 requires per-device configuration which is very much non-autonomic. 439 There are two other alternatives: 441 1. The Manufacturer could be aware of any delegation-vouchers that 442 it has issued for a particular device, and when contacted by the 443 Registrar, it could redirect the Registrar to the DASA. 445 2. The Pledge could provide a signed statement from the manufacturer 446 providing the Registrar with a pointer to the DASA. 448 Option 1 requires that the Registrar still contact the MASA, 449 violating most of the goals from Section 1.1. 451 Option 2 requires a signed artifact, and conveniently, the delegation 452 voucher is exactly the document needed. The most difficult problem 453 is that the Pledge needs to (a) store one or more delegation vouchers 454 in a non-volatile storage that survives factory reset operations, (b) 455 attach these documents to the pledge's voucher-request. 457 The extension to the [I-D.ietf-anima-bootstrapping-keyinfra] voucher- 458 request described below provides for a contained for these delegation 459 vouchers. 461 6. Applying the delegated voucher to requirements 463 6.1. applicability one 465 TBD 467 6.2. applicability two 469 TBD 471 7. Constraints on pinning the Delegated Authority 473 TBD 475 8. Privacy Considerations 477 YYY 479 9. Security Considerations 481 9.1. YANG Module Security Considerations 483 As described in the Security Considerations section of [RFC8366] 484 (section 7.4), the YANG module specified in this document defines the 485 schema for data that is subsequently encapsulated by a CMS signed- 486 data content type, as described in Section 5 of [RFC5652]. As such, 487 all of the YANG modeled data is protected from modification. 489 The use of YANG to define data structures, via the 'yang-data' 490 statement, is relatively new and distinct from the traditional use of 491 YANG to define an API accessed by network management protocols such 492 as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these 493 guidelines do not follow template described by Section 3.7 of 494 [RFC8407]. 496 10. IANA Considerations 498 This document requires the following IANA actions: 500 10.1. The IETF XML Registry 502 This document registers a URI in the "IETF XML Registry" [RFC3688]. 503 IANA is asked to register the following: 505 URI: urn:ietf:params:xml:ns:yang:ietf-delegated-voucher 506 Registrant Contact: The ANIMA WG of the IETF. 507 XML: N/A, the requested URI is an XML namespace. 509 10.2. YANG Module Names Registry 511 This document registers a YANG module in the "YANG Module Names" 512 registry [RFC6020]. IANA is asked to register the following: 514 name: ietf-delegated-voucher 515 namespace: urn:ietf:params:xml:ns:yang:ietf-delegated-voucher 516 prefix: NONE 517 reference: THIS DOCUMENT 519 11. Acknowledgements 521 Hello. 523 12. Changelog 525 13. References 527 13.1. Normative References 529 [I-D.ietf-anima-bootstrapping-keyinfra] 530 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 531 and K. Watsen, "Bootstrapping Remote Secure Key 532 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 533 keyinfra-34 (work in progress), January 2020. 535 [I-D.ietf-anima-constrained-voucher] 536 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 537 Voucher Artifacts for Bootstrapping Protocols", draft- 538 ietf-anima-constrained-voucher-05 (work in progress), July 539 2019. 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, 543 DOI 10.17487/RFC2119, March 1997, 544 . 546 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 547 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 548 May 2017, . 550 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 551 "A Voucher Artifact for Bootstrapping Protocols", 552 RFC 8366, DOI 10.17487/RFC8366, May 2018, 553 . 555 13.2. Informative References 557 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 558 DOI 10.17487/RFC3688, January 2004, 559 . 561 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 562 RFC 5652, DOI 10.17487/RFC5652, September 2009, 563 . 565 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 566 the Network Configuration Protocol (NETCONF)", RFC 6020, 567 DOI 10.17487/RFC6020, October 2010, 568 . 570 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 571 and A. Bierman, Ed., "Network Configuration Protocol 572 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 573 . 575 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 576 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 577 . 579 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 580 Documents Containing YANG Data Models", BCP 216, RFC 8407, 581 DOI 10.17487/RFC8407, October 2018, 582 . 584 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 585 Touch Provisioning (SZTP)", RFC 8572, 586 DOI 10.17487/RFC8572, April 2019, 587 . 589 Appendix A. Extra references 591 RFC Editor, please remove this section. This section lists 592 references in the YANG. [RFC8174], [RFC8040]. 594 Author's Address 596 Michael Richardson 597 Sandelman Software Works 599 Email: mcr+ietf@sandelman.ca