idnits 2.17.1 draft-ietf-anima-voucher-01.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the pledge supports expirations and the expires-on value is less then the current time, then the pledge MUST not process this voucher."; } -- The document date (March 13, 2017) is 2599 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) == Missing Reference: 'RFC6066' is mentioned on line 662, but not defined == Missing Reference: 'RFC5652' is mentioned on line 665, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2315 -- No information found for draft-bjorklund-netmod-yang-tree-diagrams - is the name correct? == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-12 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: September 14, 2017 Sandelman Software 6 M. Pritikin 7 Cisco Systems 8 T. Eckert 9 March 13, 2017 11 Voucher Profile for Bootstrapping Protocols 12 draft-ietf-anima-voucher-01 14 Abstract 16 This document defines a strategy to securely assign a pledge to an 17 owner, using an artifact signed, directly or indirectly, by the 18 pledge's manufacturer. This artifact is known as a "voucher". 20 The voucher artifact is a YANG-defined JSON document that has been 21 signed using a PKCS#7 structure. The voucher artifact is generated 22 by the pledge's manufacture or delegate (i.e. the MASA). 24 This document only defines the voucher artifact, leaving it to other 25 documents to describe specialized protocols for accessing it. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 64 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 65 5. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 70 6.1. Renewals instead of Revocations . . . . . . . . . . . . . 14 71 6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16 74 7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 75 7.3. Test Domain Certificate Validity when Signing . . . . . . 16 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 78 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 9.2. Informative References . . . . . . . . . . . . . . . . . 18 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 This document defines a strategy to securely assign a pledge to an 88 owner, using an artifact signed, directly or indirectly, by the 89 pledge's manufacturer or delegate (i.e. the MASA). This artifact is 90 known as the voucher. 92 The voucher artifact is a JSON document, conforming to a data model 93 described by YANG [RFC7950], that has been signed using a PKCS#7 94 structure. 96 A voucher may be useful in several contexts, but the driving 97 motivation herein is to support secure bootstrapping mechanisms. 98 Assigning ownership is important to bootstrapping mechanisms so that 99 the pledge can authenticate the network that's trying to take control 100 of it. 102 The lifetimes of vouchers may vary. In some bootstrapping protocols 103 the vouchers may be ephemeral, whereas in others the vouchers may be 104 potentially long-lived. In order to support the second category of 105 vouchers, this document recommends using short-life vouchers with 106 programatic renewal, enabling the MASA to communicate the ongoing 107 validity of vouchers. 109 This document only defines the voucher artifact, leaving it to other 110 documents to describe specialized protocols for accessing it. Some 111 bootstrapping protocols using the voucher artifact defined in this 112 draft include: [I-D.ietf-netconf-zerotouch], 113 [I-D.ietf-6tisch-dtsecurity-secure-join], and 114 [I-D.ietf-anima-bootstrapping-keyinfra]). 116 2. Terminology 118 The following terms are defined for clarity: 120 Imprint: The process where a device obtains the cryptographic key 121 material to identify and trust future interactions with a network. 122 This term is taken from Konrad Lorenz's work in biology with new 123 ducklings: during a critical period, the duckling would assume 124 that anything that looks like a mother duck is in fact their 125 mother. An equivalent for a device is to obtain the fingerprint 126 of the network's root certification authority certificate. A 127 device that imprints on an attacker suffers a similar fate to a 128 duckling that imprints on a hungry wolf. Securely imprinting is a 129 primary focus of this document.[imprinting]. The analogy to 130 Lorenz's work was first noted in [Stajano99theresurrecting]. 132 Pledge: The prospective device attempting to find and join a secure 133 remote key infrastructure. When shipped it only trusts authorized 134 representatives of the manufacturer. 136 Voucher: A signed statement from the MASA service that indicates to 137 a Pledge the cryptographic identity of the Registrar it should 138 trust. There are different types of vouchers depending on how 139 that trust asserted. This document describes vouchers in detail. 141 Domain: The set of entities that trust a common key infrastructure 142 trust anchor. This includes the Proxy, Registrar, Domain 143 Certificate Authority, Management components and any existing 144 entity that is already a member of the domain. 146 Domain CA: The domain Certification Authority (CA) provides 147 certification functionalities to the domain. At a minimum it 148 provides certification functionalities to a Registrar and stores 149 the trust anchor that defines the domain. Optionally, it 150 certifies all elements. 152 Join Registrar (and Coordinator): A representative of the domain 153 that is configured, perhaps autonomically, to decide whether a new 154 device is allowed to join the domain. The administrator of the 155 domain interfaces with a Join Registrar (and Coordinator) to 156 control this process. Typically a Join Registrar is "inside" its 157 domain. For simplicity this document often refers to this as just 158 "Registrar". The term JRC is used in common with other bootstrap 159 mechanisms. 161 MASA Service: A third-party Manufacturer Authorized Signing 162 Authority (MASA) service on the global Internet. The MASA signs 163 vouchers. It also provides a repository for audit log information 164 of privacy protected bootstrapping events. It does not track 165 ownership. It is trusted by the Pledge. 167 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 168 where a Pledge device makes no security decisions but rather 169 simply trusts the first Registrar it is contacted by. This is 170 also known as the "resurrecting duckling" model. 172 3. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 176 sections below are to be interpreted as described in RFC 2119 177 [RFC2119]. 179 4. Survey of Voucher Types 181 A voucher is a cryptographically protected statement to the Pledge 182 device authorizing a zero-touch "imprint" on the Join Registrar of 183 the domain. The specific information a voucher provides is 184 influenced by the bootstrapping use case. 186 The voucher can impart the following information to the Join 187 Registrar and Pledge: 189 Assertion Basis: Indicates the method that protects the imprint 190 (this is distinct from the voucher signature that protects the 191 voucher itself). This might include manufacturer asserted 192 ownership verification, assured logging operations or reliance on 193 Pledge endpoint behavior such as secure root of trust of 194 measurement. The Join Registrar might use this information. Only 195 some methods are normatively defined in this document. Other 196 methods are left for future work. 198 Authentication of Join Registrar: Indicates how the Pledge can 199 authenticate the Join Registrar. This might include an indication 200 of the private PKIX trust anchor used by the Registrar, or an 201 indication of a public PKIX trust anchor and additional CN-ID or 202 DNS-ID information to complete authentication. Symmetric key or 203 other methods are left for future work. 205 Anti-Replay Protections: Time or nonce based information to 206 constrain the voucher to time periods or bootstrap attempts. 208 A number of bootstrapping scenarios can be met using differing 209 combinations of this information. All scenarios address the primary 210 threat of a Man-in-The-Middle Registrar gaining control over the 211 Pledge device. The following combinations are "types" of vouchers: 213 |Assertion |Registrar ID | Validity | 214 Voucher |Log-|Veri- |Trust |CN-ID or| RTC | Nonce | 215 Name | ged| fied |Anchor |DNS-ID | | | 216 ---------------------------------------------------------| 217 Audit | X | | X | | | X | 218 -------------|----|-------|-------|--------|-----|-------| 219 Nonceless | X | | X | | X | | 220 Audit | | | | | | | 221 -------------|----|-------|-------|--------|-----|-------| 222 Owner Audit | X | X | X | | X | X | 223 -------------|----|-------|-------|--------|-----|-------| 224 Owner ID | | X | X | X | X | | 225 -------------|----|-------|----------------|-----|-------| 226 Bearer | X | | wildcard | optional | 227 out-of-scope | | | | | 228 -------------|----|-------|----------------|-------------| 230 NOTE: All voucher types include a 'Pledge ID serial number' 231 (Not shown for space reasons) 233 Audit Voucher: An Audit Voucher is named after the logging assertion 234 mechanisms that the Registrar then "audits" to enforce local 235 policy. The Registrar mitigates a MiTM Registrar by auditing that 236 an unknown MiTM registrar does not appear in the log entries. 237 This does not direct prevent the MiTM but provides a response 238 mechanism that ensures the MiTM is unsuccessful. This advantage 239 is that actual ownership knowledge is not required on the MASA 240 service. 242 Nonceless Audit Voucher: An Audit Voucher without a validity period 243 statement. Fundamentally the same as an Audit Voucher except that 244 it can be issued in advance to support network partitions or to 245 provide a permanent voucher for remote deployments. 247 Ownership Audit Voucher: An Audit Voucher where the MASA service has 248 verified the Registrar as the authorized owner. The MASA service 249 mitigates a MiTM Registrar by refusing to generate Audit Voucher's 250 for unauthorized Registrars. The Registrar uses audit techniques 251 to supplement the MASA. This provides an ideal sharing of policy 252 decisions and enforcement between the vendor and the owner. 254 Ownership ID Voucher: An Ownership ID Voucher is named after 255 inclusion of the Pledge's CN-ID or DNS-ID within the voucher. An 256 example Ownership Voucher is defined in 257 [I-D.ietf-netconf-zerotouch]. The MASA service mitigates a MiTM 258 Registrar by identifying the specific Registrar authorized to own 259 the Pledge. [DISCUSS: still needed?] 261 Bearer Voucher: A Bearer Voucher is named after the inclusion of a 262 Registrar ID wildcard. Because the Registrar identity is not 263 indicated this voucher type must be treated as a secret and 264 protected from exposure as any 'bearer' of the voucher can claim 265 the Pledge device. Publishing a nonceless bearer voucher 266 effectively turns the specified Pledge into a "TOFU" device with 267 minimal mitigation against MiTM Registrars. Bearer vouchers are 268 out-of-scope. 270 5. Voucher 272 The voucher's purpose is to securely assign a pledge to an owner. 273 The voucher informs the pledge which entity it should consider to be 274 its owner. 276 The voucher is signed a PKCS#7 SignedData structure, as specified by 277 Section 9.1 of [RFC2315], encoded using ASN.1 distinguished encoding 278 rules (DER), as specified in ITU-T X.690. 280 The PKCS#7 structure MUST contain JSON-encoded content conforming to 281 the YANG module specified in Section 5.3. 283 The PKCS#7 structure MUST also contain a 'signerInfo' structure, as 284 described in Section 9.1 of [RFC2315], containing the signature 285 generated over the content using the MASA's private key. 287 The PKCS#7 structure SHOULD also contain all of the certificates 288 leading up to and including the MASA's trust anchor certificate known 289 to the pledges. 291 5.1. Tree Diagram 293 The following tree diagram [I-D.bjorklund-netmod-yang-tree-diagrams] 294 illustrates a high-level view of a voucher document. Each field in 295 the voucher is fully described by the YANG module provided in 296 Section 5.3. Please review this YANG module for a detailed 297 description of the voucher format. 299 module: ietf-voucher 300 +--ro voucher 301 +--ro authority-key-identifier? binary 302 +--ro created-on yang:date-and-time 303 +--ro expires-on? yang:date-and-time 304 +--ro assertion enumeration 305 +--ro device-identifier string 306 +--ro trusted-ca-certificate binary 307 +--ro domain-certificate-identifier 308 | +--ro subject? binary 309 | +--ro cn-id? string 310 | +--ro dns-id? string 311 +--ro assert-certificate-revocations? boolean 312 +--ro nonce? binary 313 +--ro last-renewal-date? yang:date-and-time 315 5.2. Examples 317 This section provides a couple Voucher examples for illustration 318 purposes. 320 The following example illustrates an ephemeral voucher (uses a nonce) 321 encoded in JSON. As is expected with a dynamically-generated 322 voucher, only a single pledge (device-identifier) is specified. The 323 MASA generated this voucher using the 'logged' assertion type, 324 knowing that it would be suitable for the pledge making the request. 326 { 327 "ietf-voucher:voucher": { 328 "assertion": "logged", 329 "trusted-ca-certificate": "base64-encoded X.509 DER", 330 "device-identifier": "JADA123456789", 331 "created-on": "2016-10-07T19:31:42Z", 332 "nonce": "base64-encoded octet string" 333 } 334 } 336 The following illustrates a long-lived voucher (no nonce), encoded in 337 XML. This particular voucher applies to more than one pledge 338 (unique-id), which might relate to, for instance, they were all 339 issued as part of the same purchase order. This voucher includes 340 both a trust anchor certificate (trusted-ca-certificate) as well as 341 some additional information (cn-id and dns-id) that can be used to 342 identify a specific domain certificate issued, perhaps indirectly, by 343 the trust anchor CA. 345 { 346 "ietf-voucher:voucher": { 347 "assertion": "verified", 348 "trusted-ca-certificate": "base64-encoded X.509 DER", 349 "domain-certificate-identifier": { 350 "subject": "base64-encoded Subject DER" 351 }, 352 "device-identifier": "JADA123456789", 353 "created-on": "2016-10-07T19:31:42Z" 354 } 355 } 357 5.3. YANG Module 359 file "ietf-voucher@2017-03-13.yang" 361 module ietf-voucher { 362 yang-version 1.1; 364 namespace 365 "urn:ietf:params:xml:ns:yang:ietf-voucher"; 366 prefix "vch"; 368 import ietf-yang-types { 369 prefix yang; 370 reference "RFC 6991: Common YANG Data Types"; 371 } 373 import ietf-restconf { 374 prefix rc; 375 description 376 "This import statement is only present to access the yang-data 377 extension defined in RFC 8040. The yang-data extension doesn't 378 itself have anything to do with RESTCONF, but was placed in the 379 that RFC for convenience. This extension is being tracked to 380 be moved to the next version of the YANG modeling language. 381 Regardless where or how this extension statement is defined, 382 there should not be any impact to a voucher's encoding."; 383 reference "RFC 8040: RESTCONF Protocol"; 384 } 386 organization 387 "IETF ANIMA Working Group"; 389 contact 390 "WG Web: 391 WG List: 392 Author: Kent Watsen 393 394 Author: Max Pritikin 395 396 Author: Michael Richardson 397 "; 399 description 400 "This module defines the format for a voucher, which is produced by 401 a pledge's manufacturer or delegate (MASA) to securely assign one 402 or more pledges to an 'owner', so that the pledges may establish a 403 secure connection to the owner's network infrastructure."; 405 revision "2017-03-13" { 406 description 407 "Initial version"; 408 reference 409 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 410 } 412 rc:yang-data voucher-artifact { 413 uses voucher-grouping; 414 } 416 grouping voucher-grouping { 417 description 418 "Grouping only exists for pyang tree output..."; 420 container voucher { 421 config false; 422 description 423 "A voucher that can be used to assign one or more 424 pledges to an owner."; 426 leaf authority-key-identifier { 427 type binary; 428 description 429 "The Subject Key Identifier of the MASA's leaf certificate. 430 Enables the pledge a definitively identify the voucher's 431 issuer's certificate. This field is optional as not all 432 vouchers will be signed by a private key associated with 433 an X.509 certificate."; 434 } 436 leaf created-on { 437 type yang:date-and-time; 438 mandatory true; 439 description 440 "A value indicating the date this voucher was created. This 441 node is optional because its primary purpose is for human 442 consumption. However, when present, pledges that have 443 reliable clocks SHOULD ensure that this created-on value 444 is not greater than the current time."; 445 } 447 leaf expires-on { 448 type yang:date-and-time; 449 must "not ../nonce"; 450 description 451 "A value indicating when this voucher expires. The node is 452 optional as not all pledges support expirations, such as 453 pledges lacking a reliable clock. 455 If the pledge supports expirations and the expires-on value 456 is less then the current time, then the pledge MUST not 457 process this voucher."; 458 } 460 leaf assertion { 461 type enumeration { 462 enum verified { 463 description 464 "Indicates that the ownership has been positively 465 verified by the MASA (e.g., through sales channel 466 integration)."; 467 } 468 enum logged { 469 description 470 "Indicates that this ownership assignment has been 471 logged into a database maintained by the MASA, after 472 first verifying that there has not been a previous 473 claim in the database for the same pledge (voucher 474 transparency)."; 475 } 476 } 477 mandatory true; 478 description 479 "The assertion is a statement from the MASA regarding how 480 the owner was verified. This statement enables pledges 481 to support more detailed policy checks. Pledges MUST 482 ensure that the assertion provided is acceptable before 483 processing the voucher."; 484 } 486 leaf device-identifier { 487 type string; 488 mandatory true; 489 description 490 "A unique identifier (e.g., serial number) within the scope 491 of the MASA. 493 When processing a vouchers, pledges MUST ensure that their 494 unique identifier matches at least one regular expression in 495 the list. If no matching regular expression is found, the 496 pledge MUST NOT process this voucher."; 497 } 499 leaf trusted-ca-certificate { 500 type binary; 501 mandatory true; 502 description 503 "An X.509 v3 certificate structure as specified by RFC 5280, 504 Section 4 encoded using the ASN.1 distinguished encoding 505 rules (DER), as specified in ITU-T X.690. 507 This certificate is used by a pledge to trust a public key 508 infrastructure, in order to verify a domain certificate 509 supplied to the pledge separately by the bootstrapping 510 protocol. The domain certificate MUST have this certificate 511 somewhere in its chain of certificates. 513 This field is optional because it may not be needed by all 514 bootstrapping protocols. 516 Note: the expiration date of this certificate effectively 517 imposes an upper limit on the voucher's expiration."; 519 reference 520 "RFC 5280: 521 Internet X.509 Public Key Infrastructure Certificate 522 and Certificate Revocation List (CRL) Profile. 523 ITU-T X.690: 524 Information technology - ASN.1 encoding rules: 525 Specification of Basic Encoding Rules (BER), 526 Canonical Encoding Rules (CER) and Distinguished 527 Encoding Rules (DER)."; 528 } 530 // DISCUSS: do we need this anymore, if short-lived vouchers 531 // are expected, shouldn't the leaf certificate be pinned, or 532 // perhaps just the immediate issuer CA? 533 container domain-certificate-identifier { 534 must "../trusted-ca-certificate" { 535 description 536 "A trusted-ca-certificate must be present whenever 537 this node is present"; 538 } 539 description 540 "This container identifies specific values that a domain 541 certificate, provided to the pledge separately by the 542 bootstrapping protocol, MUST contain. This is useful 543 when, for instance, the trust anchor is a long-lived 544 public CA certificate, while the domain certificate is 545 reissued periodically. 547 When provided, the pledge MUST perform RFC 6125 style 548 validation of the domain certificate against all of 549 the provided values. 551 This container is optional because it is unneeded when, 552 for instance, the trusted CA certificate is owned by the 553 domain (i.e. a private PKI), and hence the trust model 554 can be more relaxed."; 556 leaf subject { 557 type binary; 558 description 559 "The certificate's entire subject field MUST match 560 this value. This value is the Subject structure, as 561 specified by RFC ???? Section ???, encoded using the 562 ASN.1 distinguished encoding rules (DER), as specified 563 in ITU-T X.690."; 564 } 565 leaf cn-id { 566 type string; 567 description 568 "The certificate's subject field's 'common name' value 569 MUST match this value."; 570 } 571 leaf dns-id { 572 type string; 573 description 574 "A subjectAltName entry of type dNSName in the 575 certificate MUST match this value."; 576 } 577 } 579 // DISCUSS: does the transition to 'pinning' model mean we can 580 // drop this leaf for now? future proofing allows it to be added 581 // if needed but its a edge condition? 582 // 583 // DISCUSS: there must be such future proofing. not clear where 584 // to add it in the voucher document. This is probably the most 585 // important point of these discusses 586 leaf assert-certificate-revocations { 587 type boolean; 588 must "../expires-on"; 589 default true; 590 description 591 "A processing instruction to the device that it should 592 verify revocation information for the PKIX certificates 593 involved in bootstrapping. This is available only if 594 the pledge has a real-time-clock. This is in addition 595 to any revocation checks performed by the MASA."; 597 // DISCUSS: should this be a boolean or an enum indicating 598 // "fail open" vs "fail closed" to make the meaning clearer. 599 } 601 leaf nonce { 602 type binary { 603 length "8..32"; 604 } 605 must "not ../expires-on"; 606 description 607 "A value that can be used by a pledge in some bootstrapping 608 protocols to enable anti-replay protection. This node is 609 optional because it is not used by all bootstrapping 610 protocols. 612 When present, the pledge MUST compare the provided nonce 613 value with another value that the pledge randomly generated 614 and sent to a bootstrap server in an earlier bootstrapping 615 message. If the values do not match, then the pledge MUST 616 NOT process this voucher."; 617 } 619 leaf last-renewal-date { 620 type yang:date-and-time; 621 must "../expires-on"; 622 description 623 "The last date that the MASA projects to be the last date it 624 will renew a voucher on (assuming the same validity duration 625 used in this voucher. This field is merely infomrative, it 626 is not processed by pledges. 628 Circustances may occur after when a voucher was generated 629 that can alter a voucher's validity period. For instance, 630 a vendor may associate validity periods with support 631 contracts, which may be terminated or extended over time."; 632 } 634 } // end voucher 635 } // end voucher-grouping 636 } 638 640 6. Design Considerations 642 6.1. Renewals instead of Revocations 644 A revocation artifact is generally used to verify the continued 645 validity of an assertion such as a PKIX certificate, web token, or a 646 "voucher". Conceptually revocation allows for issuance of assertions 647 using long lifetimes and thereby avoiding ongoing protocol operations 648 to renew the assertion. In practice the use of revocation artifacts 649 increases the solution complexity. Rather than a single protocol, or 650 operation, to obtain or renew the assertion the resulting solution 651 instead has two or more protocols: one for assertion maintanence and 652 the other(s) for revocation verification. 654 The PKIX use of CRLs and OCSP responses provides an illustrative 655 example. Relying parties that verify revocation information must 656 obtain and parse the CRL or OCSP information. Each revocation method 657 has its own validity period that effectively shortens the certificate 658 validity period (since without valid revocation checks the 659 certificate would be rejected). In addition to having multiple 660 revocation protocol options the resulting space is further 661 complicated by inline distribution of the revocation information. 662 The TLS extension "Certificate Status Request" [RFC6066] for when 663 "constrained clients may wish to use a certificate-status protocol" 664 is an example of this. Including revocation information into 665 Cryptographic Message Syntax [RFC5652] is another example. 667 If vouchers included revocation similar complexities would propagate 668 to all related voucher distribution and assertion protocols. Instead 669 vouchers do not support revocation. Instead of the asserting party, 670 or relying party, obtaining and distributing revocation information 671 the asserting party MUST obtain an up-to-date valid voucher. The 672 protocol and operations infrastructures for this are expected to be 673 the same as the initial methods used to obtain a voucher in the first 674 place, with one important clarification: the MASA services MUST issue 675 updated validity period vouchers to the same Registrar ID with 676 minimal friction. This is similar to how an OCSP revocation system 677 is always willing to confirm that a certificate is not revoked. 678 There is no requirement implied that vouchers be contiguously 679 renewed. For example if a two-week lifetime voucher is not used 680 before it expires there is no requirement that it be still valid when 681 renewed. The domain MAY renew an expired voucher at any time. The 682 MASA always has authoritative control and MAY reject such renewals 683 (such as when requested by domain owner's to "block" renewals or if 684 the device has been successfully claimed by an alternate domain). 685 Allowing non-contiguous lifetimes significantly reduces the 686 operational load on the domain as it is not required to maintain 687 valid vouchers; only to ensure a valid voucher is available during 688 the time window in which it needs to be used. 690 [[EDNOTE: It might be worth including an indication of maximum 691 lifetime for which such automated renewal is available. If so the 692 language we'd use would be similar to the RFC5280 statement that 693 certificate validity period is "the time interval during which the CA 694 warrants that it will maintain information about the status of the 695 certificate" only here used to inform the Registrar of "the time 696 interval during which the MASA warrants that it will maintain 697 information about the status of the ownership claim". Such a field 698 would be independent of the actual validity period of the voucher and 699 is not intended for consumption by the Pledge. A suggested name for 700 this field would be "last-renewal-date".]] 702 The communications to the MASA service regarding claiming and 703 blocking of devices is out of scope of this specification. Similarly 704 if revocation methods had been described, the method of reporting a 705 revocation would have been out-of-scope. 707 The lifetimes of vouchers may vary. In some bootstrapping protocols 708 the vouchers may be ephemeral, whereas in others the vouchers may be 709 potentially long-lived. For bootstrapping protocols that support 710 ephemeral vouchers, there is no need to support renewal. For 711 bootstrapping protocols that support long-lived vouchers, final 712 protocol complexity is reduced when short lifetime vouchers are 713 easily renewed rather than layering on additional revocation methods. 714 Manufacturers MAY issue long-lived vouchers to customers if required 715 but no revocation method is described. 717 6.2. Voucher Per Pledge 719 The solution originally enabled a single voucher to apply to many 720 pledges, using lists of regular expressions to represent ranges of 721 serial numbers. However, it was determined that blocking the renewal 722 of a voucher that applied to many devices, would be excessive when 723 only the ownership for a single pledge needed to be blocked. 725 7. Security Considerations 727 7.1. Clock Sensitivity 729 This document defines artifacts containing time values for voucher 730 expirations, which require an accurate clock in order to be processed 731 correctly. Vendors planning on issuing vouchers with expiration 732 values MUST ensure devices have an accurate clock when shipped from 733 manufacturing facilities, and take steps to prevent clock tampering. 734 If it is not possible to ensure clock accuracy then vouchers with 735 expirations SHOULD NOT be issued. 737 7.2. Protect Voucher PKI in HSM 739 This document favors using voucher-renewals over needing to support 740 voucher-revocations (Section 6.1). However, a voucher may be signed 741 by a chain of intermediate CAs leading to the trust anchor known to a 742 pledge. Revocation checking of these certificates is similarly 743 difficult. The current voucher format supports the existing PKIX 744 revocation information distribution within the limits of the current 745 PKI technology; but pledges MAY accept vouchers without checking 746 X.509 certificate revocation. Without revocation checking, a 747 compromized MASA keychain could be used to issue vouchers ad 748 infinitum without recourse. For this reason, MASA implementations 749 SHOULD ensure that all the CA private keys are protected by hardware 750 security modules (HSMs). 752 7.3. Test Domain Certificate Validity when Signing 754 If a domain certificate is compromised, then any outstanding vouchers 755 for that domain could be used by the attacker. The domain 756 administrator is clearly expected to initiate revocation of any 757 domain identity certificates (as in normal in PKI solutions). 758 Similarly they are expected to contact the MASA to indicate that an 759 outstanding (presumably short lifetime) voucher be blocked from 760 automated renewal. Protocols for voucher distribution are 761 RECOMMENDED to check for revocation of any domain identity 762 certificates before automated renewal of vouchers. 764 8. IANA Considerations 766 8.1. The IETF XML Registry 768 This document registers a URIs in the IETF XML registry [RFC3688]. 769 Following the format in [RFC3688], the following registration is 770 requested: 772 URI: urn:ietf:params:xml:ns:yang:ietf-voucher 773 Registrant Contact: The ANIMA WG of the IETF. 774 XML: N/A, the requested URI is an XML namespace. 776 8.2. The YANG Module Names Registry 778 This document registers a YANG module in the YANG Module Names 779 registry [RFC6020]. Following the format defined in [RFC6020], the 780 the following registration is requested: 782 name: ietf-voucher 783 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher 784 prefix: vch 785 reference: RFC XXXX 787 9. References 789 9.1. Normative References 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, 794 . 796 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 797 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 798 . 800 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 801 the Network Configuration Protocol (NETCONF)", RFC 6020, 802 DOI 10.17487/RFC6020, October 2010, 803 . 805 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 806 RFC 7950, DOI 10.17487/RFC7950, August 2016, 807 . 809 9.2. Informative References 811 [I-D.bjorklund-netmod-yang-tree-diagrams] 812 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", 2017. 814 [I-D.ietf-6tisch-dtsecurity-secure-join] 815 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 816 6tisch-dtsecurity-secure-join-01 (work in progress), 817 February 2017. 819 [I-D.ietf-anima-bootstrapping-keyinfra] 820 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 821 S., and K. Watsen, "Bootstrapping Remote Secure Key 822 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 823 keyinfra-04 (work in progress), October 2016. 825 [I-D.ietf-netconf-zerotouch] 826 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 827 for NETCONF or RESTCONF based Management", draft-ietf- 828 netconf-zerotouch-12 (work in progress), January 2017. 830 [imprinting] 831 Wikipedia, , "Wikipedia article: Imprinting", July 2015, 832 . 834 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 835 DOI 10.17487/RFC3688, January 2004, 836 . 838 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 839 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 840 December 2014, . 842 [Stajano99theresurrecting] 843 Stajano, F. and R. Anderson, "The resurrecting duckling: 844 security issues for ad-hoc wireless networks", 1999, 845 . 848 Appendix A. Acknowledgements 850 The authors would like to thank for following for lively discussions 851 on list and in the halls (ordered by last name): 853 Authors' Addresses 855 Kent Watsen 856 Juniper Networks 858 EMail: kwatsen@juniper.net 860 Michael C. Richardson 861 Sandelman Software 863 EMail: mcr+ietf@sandelman.ca 864 URI: http://www.sandelman.ca/ 866 Max Pritikin 867 Cisco Systems 869 EMail: pritikin@cisco.com 871 Toerless Eckert 873 EMail: tte+anima@cs.fau.de