idnits 2.17.1 draft-ietf-anima-voucher-05.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2017) is 2411 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) ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-15 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track M. Richardson 5 Expires: February 22, 2018 Sandelman Software 6 M. Pritikin 7 Cisco Systems 8 T. Eckert 9 Huawei 10 August 21, 2017 12 Voucher Profile for Bootstrapping Protocols 13 draft-ietf-anima-voucher-05 15 Abstract 17 This document defines a strategy to securely assign a pledge to an 18 owner, using an artifact signed, directly or indirectly, by the 19 pledge's manufacturer. This artifact is known as a "voucher". 21 The voucher artifact is a YANG-defined JSON document that has (by 22 default) been signed using a PKCS#7 structure. The voucher artifact 23 is normally generated by the pledge's manufacturer or delegate (i.e. 24 the Manufacturer Authorized Signing Authority). 26 This document only defines the voucher artifact, leaving it to other 27 documents to describe specialized protocols for accessing it. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 22, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 4. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 4 67 5. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5 68 6. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8 70 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 73 7.1. Renewals instead of Revocations . . . . . . . . . . . . . 14 74 7.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 15 77 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 78 8.3. Test Domain Certificate Validity when Signing . . . . . . 16 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 81 9.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 10.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 This document defines a strategy to securely assign a candidate 91 device (pledge) to an owner, using an artifact signed, directly or 92 indirectly, by the pledge's manufacturer or delegate, i.e. the 93 Manufacturer Authorized Signing Authority (MASA). This artifact is 94 known as the voucher. 96 The voucher artifact is a JSON [RFC7159] document, conforming to a 97 data model described by YANG [RFC7950], encoded using the rules 98 defined in [RFC7159], and signed using (by default) a PKCS#7 99 structure [RFC2315]. 101 A voucher may be useful in several contexts, but the driving 102 motivation herein is to support secure bootstrapping mechanisms. 103 Assigning ownership is important to bootstrapping mechanisms so that 104 the pledge can authenticate the network that's trying to take control 105 of it. 107 The lifetimes of vouchers may vary. In some bootstrapping protocols 108 the vouchers may be ephemeral, whereas in others the vouchers may be 109 potentially long-lived. In order to support the second category of 110 vouchers, this document recommends using short-life vouchers with 111 programatic renewal, enabling the MASA to communicate the ongoing 112 validity of vouchers. 114 This document only defines the voucher artifact, leaving it to other 115 documents to describe specialized protocols for accessing it. Some 116 bootstrapping protocols using the voucher artifact defined in this 117 draft include: [I-D.ietf-netconf-zerotouch], 118 [I-D.ietf-6tisch-dtsecurity-secure-join], and 119 [I-D.ietf-anima-bootstrapping-keyinfra]). 121 2. Terminology 123 This document uses the following terms (sorted by name): 125 Artifact: The term "artifact" is used throughout to represent the 126 voucher as instantiated in the form of a signed structure. 128 Imprint: The process where a device obtains the cryptographic key 129 material to identify and trust future interactions with a network. 130 This term is taken from Konrad Lorenz's work in biology with new 131 ducklings: "during a critical period, the duckling would assume 132 that anything that looks like a mother duck is in fact their 133 mother." An equivalent for a device is to obtain the fingerprint 134 of the network's root certification authority certificate. A 135 device that imprints on an attacker suffers a similar fate to a 136 duckling that imprints on a hungry wolf. Securely imprinting is a 137 primary focus of this document [imprinting]. The analogy to 138 Lorenz's work was first noted in [Stajano99theresurrecting]. 140 Domain: The set of entities or infrastructure under common 141 administrative control. The goal of the bootstrapping protocol is 142 to enable a Pledge to discover and join a Domain. 144 Join Registrar (and Coordinator): A representative of the domain 145 that is configured, perhaps autonomically, to decide whether a new 146 device is allowed to join the domain. The administrator of the 147 domain interfaces with a Join Registrar (and Coordinator) to 148 control this process. Typically a Join Registrar is "inside" its 149 domain. For simplicity this document often refers to this as just 150 "Registrar". 152 MASA: The Manufacturer Authorized Signing Authority (MASA) service 153 that signs vouchers. In some bootstrapping protocols, the MASA 154 may have Internet presence and be integral to the bootstrapping 155 process, whereas in other protocols the MASA may be an offline 156 service that has no active role in the bootstrapping process. 158 Pledge: The prospective device attempting to find and securely join 159 a domain. When shipped it only trusts authorized representatives 160 of the manufacturer. 162 Registrar See Join Registrar 164 TOFU: Trust on First Use. This is where a Pledge device makes no 165 security decisions but rather simply trusts the first Domain 166 entity it is contacted by. Used similarly to [RFC7435]. This is 167 also known as the "resurrecting duckling" model. 169 Voucher: A signed statement from the MASA service that indicates to 170 a Pledge the cryptographic identity of the Domain it should trust. 172 3. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 4. Tree Diagram Notation 182 A simplified graphical representation of the data models is used in 183 this document. The meaning of the symbols in these diagrams is as 184 follows: 186 o Brackets "[" and "]" enclose list keys. 188 o Braces "{" and "}" enclose feature names, and indicate that the 189 named feature must be present for the subtree to be present. 191 o Abbreviations before data node names: "rw" (read-write) represents 192 configuration data and "ro" (read-only) represents state data. 194 o Symbols after data node names: "?" means an optional node, "!" 195 means a presence container, and "*" denotes a list and leaf-list. 197 o Parentheses enclose choice and case nodes, and case nodes are also 198 marked with a colon (":"). 200 o Ellipsis ("...") stands for contents of subtrees that are not 201 shown. 203 5. Survey of Voucher Types 205 A voucher is a cryptographically protected statement to the Pledge 206 device authorizing a zero-touch "imprint" on the Join Registrar of 207 the domain. The specific information a voucher provides is 208 influenced by the bootstrapping use case. 210 The voucher can impart the following information to the Join 211 Registrar and Pledge: 213 Assertion Basis: Indicates the method that protects the imprint 214 (this is distinct from the voucher signature that protects the 215 voucher itself). This might include manufacturer asserted 216 ownership verification, assured logging operations or reliance on 217 Pledge endpoint behavior such as secure root of trust of 218 measurement. The Join Registrar might use this information. Only 219 some methods are normatively defined in this document. Other 220 methods are left for future work. 222 Authentication of Join Registrar: Indicates how the Pledge can 223 authenticate the Join Registrar. This might include an indication 224 of the private PKIX (Public Key Infrastructure using X.509) trust 225 anchor used by the Registrar, or an indication of a public PKIX 226 trust anchor and additional CN-ID or DNS-ID information to 227 complete authentication. Symmetric key or other methods are left 228 for future work. 230 Anti-Replay Protections: Time or nonce based information to 231 constrain the voucher to time periods or bootstrap attempts. 233 A number of bootstrapping scenarios can be met using differing 234 combinations of this information. All scenarios address the primary 235 threat of a Man-in-The-Middle (MiTM) Registrar gaining control over 236 the Pledge device. The following combinations are "types" of 237 vouchers: 239 |Assertion |Registrar ID | Validity | 240 Voucher |Log-|Veri- |Trust |CN-ID or| RTC | Nonce | 241 Type | ged| fied |Anchor |DNS-ID | | | 242 ---------------------------------------------------------| 243 Audit | X | | X | | | X | 244 -------------|----|-------|-------|--------|-----|-------| 245 Nonceless | X | | X | | X | | 246 Audit | | | | | | | 247 -------------|----|-------|-------|--------|-----|-------| 248 Owner Audit | X | X | X | | X | X | 249 -------------|----|-------|-------|--------|-----|-------| 250 Owner ID | | X | X | X | X | | 251 -------------|----|-------|----------------|-----|-------| 252 Bearer | X | | wildcard | optional | 253 out-of-scope | | | | | 254 -------------|----|-------|----------------|-------------| 256 NOTE: All voucher types include a 'Pledge ID serial number' 257 (Not shown for space reasons) 259 Audit Voucher: An Audit Voucher is named after the logging assertion 260 mechanisms that the Registrar then "audits" to enforce local 261 policy. The Registrar mitigates a MiTM Registrar by auditing that 262 an unknown MiTM registrar does not appear in the log entries. 263 This does not direct prevent the MiTM but provides a response 264 mechanism that ensures the MiTM is unsuccessful. This advantage 265 is that actual ownership knowledge is not required on the MASA 266 service. 268 Nonceless Audit Voucher: An Audit Voucher without a validity period 269 statement. Fundamentally the same as an Audit Voucher except that 270 it can be issued in advance to support network partitions or to 271 provide a permanent voucher for remote deployments. 273 Ownership Audit Voucher: An Audit Voucher where the MASA service has 274 verified the Registrar as the authorized owner. The MASA service 275 mitigates a MiTM Registrar by refusing to generate Audit Vouchers 276 for unauthorized Registrars. The Registrar uses audit techniques 277 to supplement the MASA. This provides a ideal sharing of policy 278 decisions and enforcement between the vendor and the owner. 280 Ownership ID Voucher: An Ownership ID Voucher is named after 281 inclusion of the Pledge's CN-ID or DNS-ID within the voucher. The 282 MASA service mitigates a MiTM Registrar by identifying the 283 specific Registrar (via WebPKI) authorized to own the Pledge. 285 Bearer Voucher: A Bearer Voucher is named after the inclusion of a 286 Registrar ID wildcard. Because the Registrar identity is not 287 indicated this voucher type must be treated as a secret and 288 protected from exposure as any 'bearer' of the voucher can claim 289 the Pledge device. Publishing a nonceless bearer voucher 290 effectively turns the specified Pledge into a "TOFU" device with 291 minimal mitigation against MiTM Registrars. Bearer vouchers are 292 out-of-scope. 294 6. Voucher artifact 296 The voucher's primary purpose is to securely assign a pledge to an 297 owner. The voucher informs the pledge which entity it should 298 consider to be its owner. 300 The voucher signing structure that MUST contain JSON-encoded content 301 conforming to the voucher-artifact YANG data schema of the YANG 302 module specified in Section 6.3. 304 Unless otherwise signaled (outside of the voucher artifact), the 305 signing structure is by default a PKCS#7 SignedData structure, as 306 specified by Section 9.1 of [RFC2315], encoded using ASN.1 307 distinguished encoding rules (DER), as specified in ITU-T X.690. 309 The PKCS#7 structure MUST also contain a 'signerInfo' structure, as 310 described in Section 9.1 of [RFC2315], containing the signature 311 generated over the content using a private key trusted by the 312 recipient. Normally the recipient is the pledge and the signer is 313 the MASA. A possible other use use could be as a "signed voucher 314 request" format originating from pledge or registrar toward the MASA. 315 Within this document the signer is assumed to be the MASA. 317 The PKCS#7 structure SHOULD also contain all the certificates leading 318 up to and including the signer's trust anchor certificate known to 319 the recipient. 321 The PKCS#7 structure MAY also contain revocation objects for any 322 intermediate certificate authorities (CAs) between the voucher-issuer 323 and the trust anchor known to the recipient. 325 Methods of signaling alternative signature methods are out-of-scope 326 of this document, but documents that leverage vouchers can provide 327 this signaling. For example they might instruct that JSON Web 328 Signature (JWS) signing is the signature method in their work. 329 Documents describing the use of alternative signature methods for 330 voucher artifacts need to encode the same information as described 331 above for PKCS#7 or else describe why the encoded information may 332 differ. 334 6.1. Tree Diagram 336 The following tree diagram illustrates a high-level view of a voucher 337 document. The notation used in this diagram is described in 338 Section 4). Each node in the diagram is fully described by the YANG 339 module in Section 6.3. Please review the YANG module for a detailed 340 description of the voucher format. 342 module: ietf-voucher 343 yang-data: 344 voucher-artifact 345 +---- voucher 346 +---- created-on yang:date-and-time 347 +---- expires-on? yang:date-and-time 348 +---- assertion enumeration 349 +---- serial-number string 350 +---- idevid-issuer? binary 351 +---- pinned-domain-cert binary 352 +---- domain-cert-revocation-checks? boolean 353 +---- nonce? binary 354 +---- last-renewal-date? yang:date-and-time 356 6.2. Examples 358 This section provides voucher examples for illustration purposes. 359 That these examples conform to the encoding rules defined in 360 [RFC7159]. 362 The following example illustrates an ephemeral voucher (uses a 363 nonce). The MASA generated this voucher using the 'logged' assertion 364 type, knowing that it would be suitable for the pledge making the 365 request. 367 { 368 "ietf-voucher:voucher": { 369 "created-on": "2016-10-07T19:31:42Z", 370 "assertion": "logged", 371 "serial-number": "JADA123456789", 372 "idevid-issuer": "base64encodedvalue==", 373 "pinned-domain-cert": "base64encodedvalue==", 374 "nonce": "base64encodedvalue==" 375 } 376 } 378 The following example illustrates a non-ephemeral voucher (no nonce). 379 While the voucher itself expires after two weeks, it presumably can 380 be renewed for up to a year later. The MASA generated this voucher 381 using the 'verified' assertion type, which should satisfy all 382 pledges. 384 { 385 "ietf-voucher:voucher": { 386 "created-on": "2016-10-07T19:31:42Z", 387 "expires-on": "2016-10-21T19:31:42Z", 388 "assertion": "verified", 389 "serial-number": "JADA123456789", 390 "idevid-issuer": "base64encodedvalue==", 391 "pinned-domain-cert": "base64encodedvalue==", 392 "domain-cert-revocation-checks": "true", 393 "last-renewal-date": "2017-10-07T19:31:42Z" 394 } 395 } 397 6.3. YANG Module 399 Following is a YANG [RFC7950] module formally describing the 400 voucher's JSON document structure. 402 file "ietf-voucher@2017-08-21.yang" 403 module ietf-voucher { 404 yang-version 1.1; 406 namespace 407 "urn:ietf:params:xml:ns:yang:ietf-voucher"; 408 prefix "vch"; 410 import ietf-yang-types { 411 prefix yang; 412 reference "RFC 6991: Common YANG Data Types"; 413 } 415 import ietf-restconf { 416 prefix rc; 417 description 418 "This import statement is only present to access 419 the yang-data extension defined in RFC 8040."; 420 reference "RFC 8040: RESTCONF Protocol"; 421 } 423 organization 424 "IETF ANIMA Working Group"; 426 contact 427 "WG Web: 428 WG List: 429 Author: Kent Watsen 430 431 Author: Max Pritikin 432 433 Author: Michael Richardson 434 435 Author: Toerless Eckert 436 "; 438 description 439 "This module defines the format for a voucher, which is produced by 440 a pledge's manufacturer or delegate (MASA) to securely assign a 441 pledge to an 'owner', so that the pledge may establish a secure 442 connection to the owner's network infrastructure. 444 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 445 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 446 the module text are to be interpreted as described in RFC 2119. 448 Copyright (c) 2017 IETF Trust and the persons identified as 449 authors of the code. All rights reserved. 451 Redistribution and use in source and binary forms, with or without 452 modification, is permitted pursuant to, and subject to the license 453 terms contained in, the Simplified BSD License set forth in Section 454 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 455 (http://trustee.ietf.org/license-info). 457 This version of this YANG module is part of RFC XXXX; see the RFC 458 itself for full legal notices."; 460 revision "2017-08-21" { 461 description 462 "Initial version"; 463 reference 464 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 465 } 467 // Top-level statement 468 rc:yang-data voucher-artifact { 469 uses voucher-artifact-grouping; 470 } 472 // Grouping defined for future augmentations 473 grouping voucher-artifact-grouping { 474 description 475 "Grouping to allow reuse/extensions in future work."; 477 container voucher { 478 description 479 "A voucher assigns a pledge to an owner (pinned-domain-cert)."; 481 leaf created-on { 482 type yang:date-and-time; 483 mandatory true; 484 description 485 "A value indicating the date this voucher was created. This 486 node is optional because its primary purpose is for human 487 consumption. However, when present, pledges that have 488 reliable clocks SHOULD ensure that this created-on value 489 is not greater than the current time."; 490 } 492 leaf expires-on { 493 type yang:date-and-time; 494 must "not(../nonce)"; 495 description 496 "A value indicating when this voucher expires. The node is 497 optional as not all pledges support expirations, such as 498 pledges lacking a reliable clock. 500 If this field exists, then the the pledges MUST ensure that 501 the expires-on time has not yet passed. A pledge without 502 an accurate clock cannot meet this requirement. 504 The expires-on value MUST NOT exceed the expiration date 505 of any of the listed 'pinned-domain-cert' certificates."; 507 } 509 leaf assertion { 510 type enumeration { 511 enum verified { 512 description 513 "Indicates that the ownership has been positively 514 verified by the MASA (e.g., through sales channel 515 integration)."; 516 } 517 enum logged { 518 description 519 "Indicates that this ownership assignment has been 520 logged into a database maintained by the MASA, after 521 first verifying that there has not been a previous 522 claim in the database for the same pledge (voucher 523 transparency)."; 524 } 525 enum proximity { 526 description 527 "Indicates that this assertion is made based on 528 the proximity of the signer as determined by 529 local network information. This is useful for 530 a pledge device to indicate it 'sees' a specific 531 registrar on a TLS connection, or for a registrar 532 to indicate it 'sees' a pledge."; 533 } 534 } 535 mandatory true; 536 description 537 "The assertion is a statement from the MASA regarding how 538 the owner was verified. This statement enables pledges 539 to support more detailed policy checks. Pledges MUST 540 ensure that the assertion provided is acceptable before 541 processing the voucher."; 542 } 544 leaf serial-number { 545 type string; 546 mandatory true; 547 description 548 "The serial number of the hardware. When processing a 549 voucher, a pledge MUST ensure that its serial number 550 matches this value. If no match occurs, then the 551 pledge MUST NOT process this voucher."; 552 } 554 leaf idevid-issuer { 555 type binary; 556 description 557 "The RFC5280 4.2.1.1 Authority Key Identifier OCTET STRING 558 from the pledge's IDevID certificate. Optional since some 559 serial-numbers are already unique within the scope of a 560 MASA. Inclusion of the statistically unique key identifier 561 ensures statistically unique identification of the hardware. 562 When processing a voucher, a pledge MUST ensure that its 563 IDevID Authority Key Identifier matches this value. If no 564 match occurs, then the pledge MUST NOT process this voucher. 566 When issuing a voucher, the MASA MUST ensure that this field 567 is populated for serial numbers that are not otherwise unique 568 within the scope of the MASA."; 569 } 571 leaf pinned-domain-cert { 572 type binary; 573 mandatory true; 574 description 575 "An X.509 v3 certificate structure as specified by RFC 5280, 576 Section 4 encoded using the ASN.1 distinguished encoding 577 rules (DER), as specified in ITU-T X.690. 579 This certificate is used by a pledge to trust a public key 580 infrastructure, in order to verify a domain certificate 581 supplied to the pledge separately by the bootstrapping 582 protocol. The domain certificate MUST have this certificate 583 somewhere in its chain of certificates. This certificate 584 MAY be an end-entity certificate, including a self-signed 585 entity."; 586 reference 587 "RFC 5280: 588 Internet X.509 Public Key Infrastructure Certificate 589 and Certificate Revocation List (CRL) Profile. 590 ITU-T X.690: 591 Information technology - ASN.1 encoding rules: 592 Specification of Basic Encoding Rules (BER), 593 Canonical Encoding Rules (CER) and Distinguished 594 Encoding Rules (DER)."; 595 } 597 leaf domain-cert-revocation-checks { 598 type boolean; 599 must "../expires-on"; 600 description 601 "A processing instruction to the pledge that it MUST verify 602 the revocation status for the domain certificate. This 603 instruction is only available for vouchers that expire. If 604 this field is not set, then normal PKIX behaviour applies 605 to validation of the domain certificate."; 606 } 608 leaf nonce { 609 type binary { 610 length "8..32"; 611 } 612 must "not(../expires-on)"; 613 description 614 "A value that can be used by a pledge in some bootstrapping 615 protocols to enable anti-replay protection. This node is 616 optional because it is not used by all bootstrapping 617 protocols. 619 When present, the pledge MUST compare the provided nonce 620 value with another value that the pledge randomly generated 621 and sent to a bootstrap server in an earlier bootstrapping 622 message. If the values do not match, then the pledge MUST 623 NOT process this voucher."; 624 } 626 leaf last-renewal-date { 627 type yang:date-and-time; 628 must "../expires-on"; 629 description 630 "The date that the MASA projects to be the last date it 631 will renew a voucher on. This field is merely informative, it 632 is not processed by pledges. 634 Circumstances may occur after a voucher is generated that 635 may alter a voucher's validity period. For instance, a 636 vendor may associate validity periods with support contracts, 637 which may be terminated or extended over time."; 638 } 640 } // end voucher 641 } // end voucher-grouping 642 } 644 646 7. Design Considerations 648 7.1. Renewals instead of Revocations 650 The lifetimes of vouchers may vary. In some bootstrapping protocols, 651 the vouchers may be created and consumed immediately whereas, in 652 other bootstrapping solutions, there may be a significant time delay 653 between when a voucher is created and when it is consumed. In cases 654 when there is a time delay, there is a need for the pledge to ensure 655 that the assertions made when the voucher was created are still 656 valid. 658 A revocation artifact is generally used to verify the continued 659 validity of an assertion such as a PKIX certificate, web token, or a 660 "voucher". With this approach, a potentially long-lived assertion is 661 paired with a reasonably fresh revocation status check to ensure that 662 the assertion is still valid. However, this approach increases 663 solution complexity, as it introduces the need for additional 664 protocols and code paths to distribute and process the revocations. 666 Addressing the short-comings of revocations, this document recommends 667 instead the use of lightweight renewals of short-lived non-revocable 668 vouchers. That is, rather than issue a long-lived voucher, where the 669 'expires-on' leaf is set to some distant date, the expectation is for 670 the MASA to instead issue a short-lived voucher, where the 'expires- 671 on' leaf is set to a relatively near date, along with a promise 672 (reflected in the 'last-renewal-date' field) to re-issue the voucher 673 again when needed. Importantly, while issuing the initial voucher 674 may incur heavyweight verification checks (are you who you say you 675 are? does the pledge actually belong to you?), re-issuing the 676 voucher should be a lightweight process, as it ostensibly only 677 updates the voucher's validity period. With this approach, there is 678 only the one artifact, and only one code path is needed to process 679 it, without any possibility for a pledge to choose to skip the 680 revocation status check because, for instance, the OCSP Responder is 681 not reachable. 683 While this document recommends issuing short-lived vouchers, the 684 voucher artifact does not restrict the ability to create a long-lived 685 vouchers, if required, however no revocation method is described. 687 Note that a voucher may be signed by a chain of intermediate CAs 688 leading up to the trust anchor certificate known by the pledge. Even 689 though the voucher itself is not revocable, it may still be revoked, 690 per se, if one of the intermediate CA certificates is revoked. 692 7.2. Voucher Per Pledge 694 The solution described herein originally enabled a single voucher to 695 apply to many pledges, using lists of regular expressions to 696 represent ranges of serial numbers. However, it was determined that 697 blocking the renewal of a voucher that applied to many devices would 698 be excessive when only the ownership for a single pledge needed to be 699 blocked. Thus, the voucher format now only supports a single serial- 700 number to be listed. 702 8. Security Considerations 704 8.1. Clock Sensitivity 706 An attacker could use an expired voucher to gain control over a 707 device that has no understand of time. 709 To defend against this there are three things: devices are required 710 to verify that the expires-on field has not yet passed. Devices 711 without access to time can use nonces to get ephemeral vouchers. 712 Thirdly, vouchers without expiration times may be used, which will 713 appear in the audit log, informing the security decision. 715 This document defines a voucher format that contains time values for 716 expirations, which require an accurate clock in order to be processed 717 correctly. Vendors planning on issuing vouchers with expiration 718 values must ensure devices have an accurate clock when shipped from 719 manufacturing facilities, and take steps to prevent clock tampering. 720 If it is not possible to ensure clock accuracy then vouchers with 721 expirations should not be issued. 723 8.2. Protect Voucher PKI in HSM 725 A voucher is signed by a CA, that may itself be signed by a chain of 726 CAs leading to a trust anchor known to a pledge. Revocation checking 727 of the intermediate certificates may be difficult in some scenarios. 728 The voucher format supports the existing PKIX revocation information 729 distribution within the limits of the current PKI technology (a PKCS7 730 structure can contain revocation objects as well), but pledges MAY 731 accept vouchers without checking X.509 certificate revocation (when 732 'domain-cert-revocation-checks' is false). Without revocation 733 checking, a compromised MASA keychain could be used to issue vouchers 734 ad infinitum without recourse. For this reason, MASA implementations 735 wanting to support such deployments SHOULD ensure that all the CA 736 private keys used for signing the vouchers are protected by hardware 737 security modules (HSMs). 739 8.3. Test Domain Certificate Validity when Signing 741 If a domain certificate is compromised, then any outstanding vouchers 742 for that domain could be used by the attacker. The domain 743 administrator is clearly expected to initiate revocation of any 744 domain identity certificates (as is normal in PKI solutions). 746 Similarly they are expected to contact the MASA to indicate that an 747 outstanding (presumably short lifetime) voucher should be blocked 748 from automated renewal. Protocols for voucher distribution are 749 RECOMMENDED to check for revocation of any domain identity 750 certificates before automated renewal of vouchers. 752 9. IANA Considerations 754 9.1. The IETF XML Registry 756 This document registers a URIs in the IETF XML registry [RFC3688]. 757 Following the format in [RFC3688], the following registration is 758 requested: 760 URI: urn:ietf:params:xml:ns:yang:ietf-voucher 761 Registrant Contact: The ANIMA WG of the IETF. 762 XML: N/A, the requested URI is an XML namespace. 764 9.2. The YANG Module Names Registry 766 This document registers a YANG module in the YANG Module Names 767 registry [RFC6020]. Following the format defined in [RFC6020], the 768 the following registration is requested: 770 name: ietf-voucher 771 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher 772 prefix: vch 773 reference: RFC XXXX 775 10. References 777 10.1. Normative References 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, 781 DOI 10.17487/RFC2119, March 1997, 782 . 784 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 785 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 786 . 788 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 789 the Network Configuration Protocol (NETCONF)", RFC 6020, 790 DOI 10.17487/RFC6020, October 2010, 791 . 793 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 794 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 795 2014, . 797 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 798 RFC 7950, DOI 10.17487/RFC7950, August 2016, 799 . 801 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 802 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 803 May 2017, . 805 10.2. Informative References 807 [I-D.ietf-6tisch-dtsecurity-secure-join] 808 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 809 6tisch-dtsecurity-secure-join-01 (work in progress), 810 February 2017. 812 [I-D.ietf-anima-bootstrapping-keyinfra] 813 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 814 S., and K. Watsen, "Bootstrapping Remote Secure Key 815 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 816 keyinfra-07 (work in progress), July 2017. 818 [I-D.ietf-netconf-zerotouch] 819 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 820 Provisioning for NETCONF or RESTCONF based Management", 821 draft-ietf-netconf-zerotouch-15 (work in progress), August 822 2017. 824 [imprinting] 825 Wikipedia, "Wikipedia article: Imprinting", July 2015, 826 . 828 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 829 DOI 10.17487/RFC3688, January 2004, . 832 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 833 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 834 December 2014, . 836 [Stajano99theresurrecting] 837 Stajano, F. and R. Anderson, "The resurrecting duckling: 838 security issues for ad-hoc wireless networks", 1999, 839 . 842 Appendix A. Acknowledgements 844 The authors would like to thank for following for lively discussions 845 on list and in the halls (ordered by last name): William Atwood, 846 Toerless Eckert, Sheng Jiang. 848 Authors' Addresses 850 Kent Watsen 851 Juniper Networks 853 EMail: kwatsen@juniper.net 855 Michael C. Richardson 856 Sandelman Software 858 EMail: mcr+ietf@sandelman.ca 859 URI: http://www.sandelman.ca/ 861 Max Pritikin 862 Cisco Systems 864 EMail: pritikin@cisco.com 866 Toerless Eckert 867 Futurewei Technologies Inc. 868 2330 Central Expy 869 Santa Clara 95050 870 USA 872 EMail: tte+ietf@cs.fau.de