idnits 2.17.00 (12 Aug 2021) /tmp/idnits15028/draft-ietf-netconf-sztp-csr-12.txt: -(1532): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8572, but the abstract doesn't seem to directly say this. It does mention RFC8572 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 224 has weird spacing: '...ntifier bin...' == Line 227 has weird spacing: '...ntifier ide...' == Line 317 has weird spacing: '...rmation cms...' == Line 336 has weird spacing: '...ntifier bin...' == Line 339 has weird spacing: '...ntifier ide...' == (2 more instances...) -- The document date (3 December 2021) is 168 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 (-22) exists of draft-ietf-netconf-crypto-types-21 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-24) exists of draft-ietf-netconf-keystore-22 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-trust-anchors-15 == Outdated reference: draft-ietf-netmod-factory-default has been published as RFC 8808 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Updates: 8572 (if approved) R. Housley 5 Intended status: Standards Track Vigil Security, LLC 6 Expires: 6 June 2022 S. Turner 7 sn3rd 8 3 December 2021 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-ietf-netconf-sztp-csr-12 14 Abstract 16 This draft extends the "get-bootstrapping-data" RPC defined in RFC 17 8572 to include an optional certificate signing request (CSR), 18 enabling a bootstrapping device to additionally obtain an identity 19 certificate (e.g., an LDevID from IEEE 802.1AR) as part of the 20 "onboarding information" response provided in the RPC-reply. 22 Editorial Note (To be removed by RFC Editor) 24 This draft contains many placeholder values that need to be replaced 25 with finalized values at the time of publication. This note 26 summarizes all of the substitutions that are needed. No other RFC 27 Editor instructions are specified elsewhere in this document. 29 Artwork in this document contains shorthand references to drafts in 30 progress. Please apply the following replacements: 32 * XXXX --> the assigned numerical RFC value for this draft 34 * AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types 36 Artwork in this document contains a placeholder value for the 37 publication date of this draft. Please apply the following 38 replacement: 40 * 2021-12-03 --> the publication date of this draft 42 This document contains references to other drafts in progress, both 43 in the Normative References section, as well as in body text 44 throughout. Please update the following references to reflect their 45 final RFC assignments: 47 * I-D.ietf-netconf-crypto-types 48 * I-D.ietf-netconf-keystore 50 * I-D.ietf-netconf-trust-anchors 52 * I-D.ietf-netmod-factory-default 54 Status of This Memo 56 This Internet-Draft is submitted in full conformance with the 57 provisions of BCP 78 and BCP 79. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF). Note that other groups may also distribute 61 working documents as Internet-Drafts. The list of current Internet- 62 Drafts is at https://datatracker.ietf.org/drafts/current/. 64 Internet-Drafts are draft documents valid for a maximum of six months 65 and may be updated, replaced, or obsoleted by other documents at any 66 time. It is inappropriate to use Internet-Drafts as reference 67 material or to cite them other than as "work in progress." 69 This Internet-Draft will expire on 6 June 2022. 71 Copyright Notice 73 Copyright (c) 2021 IETF Trust and the persons identified as the 74 document authors. All rights reserved. 76 This document is subject to BCP 78 and the IETF Trust's Legal 77 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 78 license-info) in effect on the date of publication of this document. 79 Please review these documents carefully, as they describe your rights 80 and restrictions with respect to this document. Code Components 81 extracted from this document must include Revised BSD License text as 82 described in Section 4.e of the Trust Legal Provisions and are 83 provided without warranty as described in the Revised BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 89 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 90 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 91 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 92 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 93 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 94 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 95 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 97 3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17 98 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 99 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27 102 4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27 103 4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 28 104 4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28 105 4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 29 106 4.1.5. Selecting the Best Origin Authentication Mechanism . 29 107 4.1.6. Clearing the Private Key and Associated 108 Certificate . . . . . . . . . . . . . . . . . . . . . 30 109 4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 30 110 4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30 111 4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 30 112 4.2.3. Supporting SZTP-Clients that don't trust the 113 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 31 114 4.3. Security Considerations for the "ietf-sztp-csr" YANG 115 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 4.4. Security Considerations for the "ietf-ztp-types" YANG 117 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 119 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31 120 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 32 121 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 122 6.1. Normative References . . . . . . . . . . . . . . . . . . 32 123 6.2. Informative References . . . . . . . . . . . . . . . . . 33 124 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35 125 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 128 1. Introduction 130 1.1. Overview 132 This draft extends the "get-bootstrapping-data" RPC defined in 133 [RFC8572] to include an optional certificate signing request (CSR) 134 [RFC2986], enabling a bootstrapping device to additionally obtain an 135 identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of 136 the "onboarding information" response provided in the RPC-reply. 138 The ability to provision an identity certificate that is purpose- 139 built for a production environment during the bootstrapping process 140 removes reliance on the manufacturer CA, and it also enables the 141 bootstrapped device to join the production environment with an 142 appropriate identity and other attributes in its identity certificate 143 (e.g., an LDevID). 145 Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module 146 defines three YANG groupings for the various messages defined in this 147 document. The "ietf-sztp-csr" module augments two groupings into the 148 "get-bootstrapping-data" RPC and defines a YANG Data Structure 149 [RFC8791] around the third grouping. 151 1.2. Terminology 153 This document uses the following terms from [RFC8572]: 155 * Bootstrap Server 156 * Bootstrapping Data 157 * Conveyed Information 158 * Device 159 * Manufacturer 160 * Onboarding Information 161 * Signed Data 163 This document defines the following new terms: 165 SZTP-client The term "SZTP-client" refers to a "device" that is 166 using a "bootstrap server" as a source of "bootstrapping data". 168 SZTP-server The term "SZTP-server" is an alternative term for 169 "bootstrap server" that is symmetric with the "SZTP-client" term. 171 1.3. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 1.4. Conventions 181 Various examples used in this document use a placeholder value for 182 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 183 This placeholder value is used as real base64 encoded structures are 184 often many lines long and hence distracting to the example being 185 presented. 187 2. The "ietf-sztp-csr" Module 189 The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that 190 augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572] 191 and defines a YANG "structure" that is to be conveyed in the "error- 192 info" node defined in Section 7.1 of [RFC8040]. 194 2.1. Data Model Overview 196 The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" 197 module. 199 module: ietf-sztp-csr 201 augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: 202 +---w (msg-type)? 203 +--:(csr-support) 204 | +---w csr-support 205 | +---w key-generation! 206 | | +---w supported-algorithms 207 | | +---w algorithm-identifier* binary 208 | +---w csr-generation 209 | +---w supported-formats 210 | +---w format-identifier* identityref 211 +--:(csr) 212 +---w (csr-type) 213 +--:(p10-csr) 214 | +---w p10-csr? ct:csr 215 +--:(cmc-csr) 216 | +---w cmc-csr? binary 217 +--:(cmp-csr) 218 +---w cmp-csr? binary 219 module: ietf-sztp-csr 221 structure: csr-request 222 +--ro key-generation! 223 | +--ro selected-algorithm 224 | +--ro algorithm-identifier binary 225 +--ro csr-generation 226 | +--ro selected-format 227 | +--ro format-identifier identityref 228 +--ro cert-req-info? ct:csr-info 230 augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: 231 +---w (msg-type)? 232 +--:(csr-support) 233 | +---w csr-support 234 | +---w key-generation! 235 | | +---w supported-algorithms 236 | | +---w algorithm-identifier* binary 237 | +---w csr-generation 238 | +---w supported-formats 239 | +---w format-identifier* identityref 240 +--:(csr) 241 +---w (csr-type) 242 +--:(p10-csr) 243 | +---w p10-csr? ct:csr 244 +--:(cmc-csr) 245 | +---w cmc-csr? binary 246 +--:(cmp-csr) 247 +---w cmp-csr? binary 249 The augmentation defines two kinds of parameters that an SZTP-client 250 can send to an SZTP-server. The YANG structure defines one 251 collection of parameters that an SZTP-server can send to an SZTP- 252 client. 254 In the order of their intended use: 256 * The "csr-support" node is used by the SZTP-client to signal to the 257 SZTP-server that it supports the ability the generate CSRs. This 258 parameter conveys if the SZTP-client is able to generate an new 259 asymmetric key and, if so, which key algorithms it supports, as 260 well as conveys what kinds of CSR structures the SZTP-client is 261 able to generate. 263 * The "csr-request" structure is used by the SZTP-server to request 264 the SZTP-client to generate a CSR. This structure is used to 265 select the key algorithm the SZTP-client should use to generate a 266 new asymmetric key, if supported, the kind of CSR structure the 267 SZTP-client should generate and, optionally, the content for the 268 CSR itself. 270 * The various "csr" nodes are used by the SZTP-client to communicate 271 a CSR to the SZTP-server. 273 | No data model is defined enabling an SZTP-server to communicate 274 | the signed certificate to the SZTP-client. How to do this is 275 | discussed in Section 2.2. 277 To further illustrate how the augmentation and structure defined by 278 the "ietf-sztp-csr" module are used, below are two additional tree 279 diagrams showing these nodes placed where they are used. 281 The following tree diagram [RFC8340] illustrates SZTP's "get- 282 bootstrapping-data" RPC with the augmentation in place. 284 =============== NOTE: '\' line wrapping per RFC 8792 ================ 286 module: ietf-sztp-bootstrap-server 288 rpcs: 289 +---x get-bootstrapping-data 290 +---w input 291 | +---w signed-data-preferred? empty 292 | +---w hw-model? string 293 | +---w os-name? string 294 | +---w os-version? string 295 | +---w nonce? binary 296 | +---w (sztp-csr:msg-type)? 297 | +--:(sztp-csr:csr-support) 298 | | +---w sztp-csr:csr-support 299 | | +---w sztp-csr:key-generation! 300 | | | +---w sztp-csr:supported-algorithms 301 | | | +---w sztp-csr:algorithm-identifier* bina\ 302 ry 303 | | +---w sztp-csr:csr-generation 304 | | +---w sztp-csr:supported-formats 305 | | +---w sztp-csr:format-identifier* identit\ 306 yref 307 | +--:(sztp-csr:csr) 308 | +---w (sztp-csr:csr-type) 309 | +--:(sztp-csr:p10-csr) 310 | | +---w sztp-csr:p10-csr? ct:csr 311 | +--:(sztp-csr:cmc-csr) 312 | | +---w sztp-csr:cmc-csr? binary 313 | +--:(sztp-csr:cmp-csr) 314 | +---w sztp-csr:cmp-csr? binary 315 +--ro output 316 +--ro reporting-level? enumeration {onboarding-server}? 317 +--ro conveyed-information cms 318 +--ro owner-certificate? cms 319 +--ro ownership-voucher? cms 321 The following tree diagram [RFC8340] illustrates RESTCONF's "errors" 322 RPC-reply message with the "csr-request" structure in place. 324 module: ietf-restconf 325 +--ro errors 326 +--ro error* [] 327 +--ro error-type enumeration 328 +--ro error-tag string 329 +--ro error-app-tag? string 330 +--ro error-path? instance-identifier 331 +--ro error-message? string 332 +--ro error-info 333 +--ro csr-request 334 +--ro key-generation! 335 | +--ro selected-algorithm 336 | +--ro algorithm-identifier binary 337 +--ro csr-generation 338 | +--ro selected-format 339 | +--ro format-identifier identityref 340 +--ro cert-req-info? ct:csr-info 342 2.2. Example Usage 344 | The examples below are encoded using JSON, but they could 345 | equally well be encoded using XML, as is supported by SZTP. 347 An SZTP-client implementing this specification would signal to the 348 bootstrap server its willingness to generate a CSR by including the 349 "csr-support" node in its "get-bootstrapping-data" RPC. In the 350 example below, the SZTP-client additionally indicates that it is able 351 to generate keys and provides a list of key algorithms it supports, 352 as well as provide a list of certificate formats it supports. 354 REQUEST 355 =============== NOTE: '\' line wrapping per RFC 8792 ================ 357 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 358 ng-data HTTP/1.1 359 HOST: example.com 360 Content-Type: application/yang.data+json 362 { 363 "ietf-sztp-bootstrap-server:input" : { 364 "hw-model": "model-x", 365 "os-name": "vendor-os", 366 "os-version": "17.3R2.1", 367 "nonce": "extralongbase64encodedvalue=", 368 "ietf-sztp-csr:csr-support": { 369 "key-generation": { 370 "supported-algorithms": { 371 "algorithm-identifier": [ 372 "BASE64VALUE1", 373 "BASE64VALUE2", 374 "BASE64VALUE3" 375 ] 376 } 377 }, 378 "csr-generation": { 379 "supported-formats": { 380 "format-identifier": [ 381 "ietf-ztp-types:p10-csr", 382 "ietf-ztp-types:cmc-csr", 383 "ietf-ztp-types:cmp-csr" 384 ] 385 } 386 } 387 } 388 } 389 } 391 Assuming the SZTP-server wishes to prompt the SZTP-client to provide 392 a CSR, then it would respond with an HTTP 400 Bad Request error code. 393 In the example below, the SZTP-server specifies that it wishes the 394 SZTP-client to generate a key using a specific algorithm and generate 395 a P10-based CSR containing specific content. 397 RESPONSE 398 HTTP/1.1 400 Bad Request 399 Date: Sat, 31 Oct 2015 17:02:40 GMT 400 Server: example-server 401 Content-Type: application/yang.data+json 403 { 404 "ietf-restconf:errors" : { 405 "error" : [ 406 { 407 "error-type": "application", 408 "error-tag": "missing-attribute", 409 "error-message": "Missing input parameter", 410 "error-info": { 411 "ietf-sztp-csr:csr-request": { 412 "key-generation": { 413 "selected-algorithm": { 414 "algorithm-identifier": "BASE64VALUE=" 415 } 416 }, 417 "csr-generation": { 418 "selected-format": { 419 "format-identifier": "ietf-ztp-types:p10-csr" 420 } 421 }, 422 "cert-req-info": "BASE64VALUE=" 423 } 424 } 425 } 426 ] 427 } 428 } 430 Upon being prompted to provide a CSR, the SZTP-client would POST 431 another "get-bootstrapping-data" request, but this time including one 432 of the "csr" nodes to convey its CSR to the SZTP-server: 434 REQUEST 435 =============== NOTE: '\' line wrapping per RFC 8792 ================ 437 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 438 ng-data HTTP/1.1 439 HOST: example.com 440 Content-Type: application/yang.data+json 442 { 443 "ietf-sztp-bootstrap-server:input" : { 444 "hw-model": "model-x", 445 "os-name": "vendor-os", 446 "os-version": "17.3R2.1", 447 "nonce": "extralongbase64encodedvalue=", 448 "ietf-sztp-csr:p10-csr": "BASE64VALUE=" 449 } 450 } 452 At this point, it is expected that the SZTP-server, perhaps in 453 conjunction with other systems, such as a backend CA or RA, will 454 validate the CSR's origin and proof-of-possession and, assuming the 455 CSR is approved, issue a signed certificate for the bootstrapping 456 device. 458 The SZTP-server responds with "onboarding-information" (encoded 459 inside the "conveyed-information" node, shown below) containing a 460 signed identity certificate for the CSR provided by the SZTP-client: 462 RESPONSE 464 HTTP/1.1 200 OK 465 Date: Sat, 31 Oct 2015 17:02:40 GMT 466 Server: example-server 467 Content-Type: application/yang.data+json 469 { 470 "ietf-sztp-bootstrap-server:output" : { 471 "reporting-level": "verbose", 472 "conveyed-information": "BASE64VALUE=" 473 } 474 } 476 How the signed certificate is conveyed inside the onboarding 477 information is outside the scope of this document. Some 478 implementations may choose to convey it inside a script (e.g., SZTP's 479 "pre-configuration-script"), while other implementations may choose 480 to convey it inside the SZTP "configuration" node. SZTP onboarding 481 information is described in Section 2.2 of [RFC8572]. 483 Following are two examples of conveying the signed certificate inside 484 the "configuration" node. Both examples assume that the SZTP-client 485 understands the "ietf-keystore" module defined in 486 [I-D.ietf-netconf-keystore]. 488 This first example illustrates the case where the signed certificate 489 is for the same asymmetric key used by the SZTP-client's 490 manufacturer-generated identity certificate (e.g., an IDevID, from 491 [Std-802.1AR-2018]). As such, the configuration needs to associate 492 the newly signed certificate with the existing asymmetric key: 494 =============== NOTE: '\' line wrapping per RFC 8792 ================ 496 { 497 "ietf-keystore:keystore": { 498 "asymmetric-keys": { 499 "asymmetric-key": [ 500 { 501 "name": "Manufacturer-Generated Hidden Key", 502 "public-key-format": "ietf-crypto-types:subject-public-key\ 503 -info-format", 504 "public-key": "BASE64VALUE=", 505 "hidden-private-key": [null], 506 "certificates": { 507 "certificate": [ 508 { 509 "name": "Manufacturer-Generated IDevID Cert", 510 "cert-data": "BASE64VALUE=" 511 }, 512 { 513 "name": "Newly-Generated LDevID Cert", 514 "cert-data": "BASE64VALUE=" 515 } 516 ] 517 } 518 } 519 ] 520 } 521 } 522 } 524 This second example illustrates the case where the signed certificate 525 is for a newly generated asymmetric key. As such, the configuration 526 needs to associate the newly signed certificate with the newly 527 generated asymmetric key: 529 =============== NOTE: '\' line wrapping per RFC 8792 ================ 531 { 532 "ietf-keystore:keystore": { 533 "asymmetric-keys": { 534 "asymmetric-key": [ 535 { 536 "name": "Manufacturer-Generated Hidden Key", 537 "public-key-format": "ietf-crypto-types:subject-public-key\ 538 -info-format", 539 "public-key": "BASE64VALUE=", 540 "hidden-private-key": [null], 541 "certificates": { 542 "certificate": [ 543 { 544 "name": "Manufacturer-Generated IDevID Cert", 545 "cert-data": "BASE64VALUE=" 546 } 547 ] 548 } 549 }, 550 { 551 "name": "Newly-Generated Hidden Key", 552 "public-key-format": "ietf-crypto-types:subject-public-key\ 553 -info-format", 554 "public-key": "BASE64VALUE=", 555 "hidden-private-key": [null], 556 "certificates": { 557 "certificate": [ 558 { 559 "name": "Newly-Generated LDevID Cert", 560 "cert-data": "BASE64VALUE=" 561 } 562 ] 563 } 564 } 565 ] 566 } 567 } 568 } 570 In addition to configuring the signed certificate, it is often 571 necessary to also configure the Issuer's signing certificate so that 572 the device (i.e., STZP-client) can authenticate certificates 573 presented by peer devices signed by the same issuer as its own. 574 While outside the scope of this document, one way to do this would be 575 to use the "ietf-truststore" module defined in 576 [I-D.ietf-netconf-trust-anchors]. 578 2.3. YANG Module 580 This module augments an RPC defined in [RFC8572]. The module uses a 581 data types and groupings defined in [RFC8572], [RFC8791], and 582 [I-D.ietf-netconf-crypto-types]. The module has additional normative 583 references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015], 584 and an informative reference to [Std-802.1AR-2018]. 586 file "ietf-sztp-csr@2021-12-03.yang" 588 module ietf-sztp-csr { 589 yang-version 1.1; 590 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 591 prefix sztp-csr; 593 import ietf-sztp-bootstrap-server { 594 prefix sztp-svr; 595 reference 596 "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 597 } 599 import ietf-yang-structure-ext { 600 prefix sx; 601 reference 602 "RFC 8791: YANG Data Structure Extensions"; 603 } 605 import ietf-ztp-types { 606 prefix zt; 607 reference 608 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 609 in a Secure Zero Touch Provisioning (SZTP) 610 Bootstrapping Request"; 611 } 613 organization 614 "IETF NETCONF (Network Configuration) Working Group"; 616 contact 617 "WG Web: http://tools.ietf.org/wg/netconf 618 WG List: 619 Authors: Kent Watsen 620 Russ Housley 621 Sean Turner "; 623 description 624 "This module augments the 'get-bootstrapping-data' RPC, 625 defined in the 'ietf-sztp-bootstrap-server' module from 626 SZTP (RFC 8572), enabling the SZTP-client to obtain a 627 signed identity certificate (e.g., an LDevID from IEEE 628 802.1AR) as part of the SZTP onboarding information 629 response. 631 Copyright (c) 2021 IETF Trust and the persons identified 632 as authors of the code. All rights reserved. 634 Redistribution and use in source and binary forms, with 635 or without modification, is permitted pursuant to, and 636 subject to the license terms contained in, the Simplified 637 BSD License set forth in Section 4.c of the IETF Trust's 638 Legal Provisions Relating to IETF Documents 639 (https://trustee.ietf.org/license-info). 641 This version of this YANG module is part of RFC XXXX 642 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 643 itself for full legal notices. 645 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 646 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 647 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 648 document are to be interpreted as described in BCP 14 649 (RFC 2119) (RFC 8174) when, and only when, they appear 650 in all capitals, as shown here."; 652 revision 2021-12-03 { 653 description 654 "Initial version"; 655 reference 656 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 657 in a Secure Zero Touch Provisioning (SZTP) 658 Bootstrapping Request"; 659 } 661 // Protocol-accessible nodes 663 augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { 664 description 665 "This augmentation adds the 'csr-support' and 'csr' nodes to 666 the SZTP (RFC 8572) 'get-bootstrapping-data' request message, 667 enabling the SZTP-client to obtain an identity certificate 668 (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding 669 information response provided by the SZTP-server. 671 The 'csr-support' node enables the SZTP-client to indicate 672 that it supports generating certificate signing requests 673 (CSRs), and to provide details around the CSRs it is able 674 to generate. 676 The 'csr' node enables the SZTP-client to relay a CSR to 677 the SZTP-server."; 678 reference 679 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 680 area networks - Secure Device Identity 681 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 682 choice msg-type { 683 description 684 "Messages are mutually exclusive."; 685 case csr-support { 686 description 687 "Indicates how the SZTP-client supports generating CSRs. 689 If present and a SZTP-server wishes to request the 690 SZTP-client generate a CSR, the SZTP-server MUST 691 respond with HTTP code 400 Bad Request with an 692 'ietf-restconf:errors' message having the 'error-tag' 693 value 'missing-attribute' and the 'error-info' node 694 containing the 'csr-request' structure described 695 in this module."; 696 uses zt:csr-support-grouping; 697 } 698 case csr { 699 description 700 "Provides the CSR generated by the SZTP-client. 702 When present, the SZTP-server SHOULD respond with 703 an SZTP onboarding information message containing 704 a signed certificate for the conveyed CSR. The 705 SZTP-server MAY alternatively respond with another 706 HTTP error containing another 'csr-request', in 707 which case the SZTP-client MUST invalidate the 708 previously generated CSR."; 709 uses zt:csr-grouping; 710 } 711 } 712 } 714 sx:structure csr-request { 715 description 716 "A YANG data structure, per RFC 8791, that specifies 717 details for the CSR that the ZTP-client is to generate."; 718 reference 719 "RFC 8791: YANG Data Structure Extensions"; 720 uses zt:csr-request-grouping; 721 } 723 } 725 727 3. The "ietf-ztp-types" Module 729 This section defines a YANG 1.1 [RFC7950] module that defines three 730 YANG groupings, one each for messages sent between a ZTP-client and 731 ZTP-server. This module is defines independently of the "ietf-sztp- 732 csr" module so that it's groupings may be used by bootstrapping 733 protocols other than SZTP [RFC8572]. 735 3.1. Data Model Overview 737 The following tree diagram [RFC8340] illustrates the three groupings 738 defined in the "ietf-ztp-types" module. 740 module: ietf-ztp-types 742 grouping csr-support-grouping 743 +-- csr-support 744 +-- key-generation! 745 | +-- supported-algorithms 746 | +-- algorithm-identifier* binary 747 +-- csr-generation 748 +-- supported-formats 749 +-- format-identifier* identityref 750 grouping csr-request-grouping 751 +-- key-generation! 752 | +-- selected-algorithm 753 | +-- algorithm-identifier binary 754 +-- csr-generation 755 | +-- selected-format 756 | +-- format-identifier identityref 757 +-- cert-req-info? ct:csr-info 758 grouping csr-grouping 759 +-- (csr-type) 760 +--:(p10-csr) 761 | +-- p10-csr? ct:csr 762 +--:(cmc-csr) 763 | +-- cmc-csr? binary 764 +--:(cmp-csr) 765 +-- cmp-csr? binary 767 3.2. YANG Module 769 This module uses a data types and groupings [RFC8791] and 770 [I-D.ietf-netconf-crypto-types]. The module has additional normative 771 references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], 772 and an informative reference to [Std-802.1AR-2018]. 774 file "ietf-ztp-types@2021-12-03.yang" 776 module ietf-ztp-types { 777 yang-version 1.1; 778 namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; 779 prefix zt; 781 import ietf-crypto-types { 782 prefix ct; 783 reference 784 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 785 } 787 organization 788 "IETF NETCONF (Network Configuration) Working Group"; 790 contact 791 "WG Web: http://tools.ietf.org/wg/netconf 792 WG List: 793 Authors: Kent Watsen 794 Russ Housley 795 Sean Turner "; 797 description 798 "This module defines three groupings that enable 799 bootstrapping devices to 1) indicate if and how they 800 support generating CSRs, 2) obtain a request to 801 generate a CSR, and 3) communicate the requested CSR. 803 Copyright (c) 2021 IETF Trust and the persons identified 804 as authors of the code. All rights reserved. 806 Redistribution and use in source and binary forms, with 807 or without modification, is permitted pursuant to, and 808 subject to the license terms contained in, the Simplified 809 BSD License set forth in Section 4.c of the IETF Trust's 810 Legal Provisions Relating to IETF Documents 811 (https://trustee.ietf.org/license-info). 813 This version of this YANG module is part of RFC XXXX 814 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 815 itself for full legal notices. 817 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 818 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 819 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 820 document are to be interpreted as described in BCP 14 821 (RFC 2119) (RFC 8174) when, and only when, they appear 822 in all capitals, as shown here."; 824 revision 2021-12-03 { 825 description 826 "Initial version"; 827 reference 828 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 829 in a Secure Zero Touch Provisioning (SZTP) 830 Bootstrapping Request"; 831 } 833 identity certificate-request-format { 834 description 835 "A base identity for the request formats supported 836 by the ZTP-client. 838 Additional derived identities MAY be defined by 839 future efforts."; 840 } 842 identity p10-csr { 843 base certificate-request-format; 844 description 845 "Indicates that the ZTP-client supports generating 846 requests using the 'CertificationRequest' structure 847 defined in RFC 2986."; 848 reference 849 "RFC 2986: PKCS #10: Certification Request Syntax 850 Specification Version 1.7"; 851 } 853 identity cmp-csr { 854 base certificate-request-format; 855 description 856 "Indicates that the ZTP-client supports generating 857 requests using a constrained version of the PKIMessage 858 containing a p10cr structure defined in RFC 4210."; 859 reference 860 "RFC 4210: Internet X.509 Public Key Infrastructure 861 Certificate Management Protocol (CMP)"; 862 } 863 identity cmc-csr { 864 base certificate-request-format; 865 description 866 "Indicates that the ZTP-client supports generating 867 requests using a constrained version of the 'Full 868 PKI Request' structure defined in RFC 5272."; 869 reference 870 "RFC 5272: Certificate Management over CMS (CMC)"; 871 } 873 // Protocol-accessible nodes 875 grouping csr-support-grouping { 876 description 877 "A grouping enabling use by other efforts."; 878 container csr-support { 879 description 880 "Enables a ZTP-client to indicate that it supports 881 generating certificate signing requests (CSRs) and 882 provides details about the CSRs it is able to 883 generate."; 884 container key-generation { 885 presence 886 "Indicates that the ZTP-client is capable of 887 generating a new asymmetric key pair. 889 If this node is not present, the ZTP-server MAY 890 request a CSR using the asymmetric key associated 891 with the device's existing identity certificate 892 (e.g., an IDevID from IEEE 802.1AR)."; 893 description 894 "Specifies details for the ZTP-client's ability to 895 generate a new asymmetric key pair."; 896 container supported-algorithms { 897 description 898 "A list of public key algorithms supported by the 899 ZTP-client for generating a new asymmetric key."; 900 leaf-list algorithm-identifier { 901 type binary; 902 min-elements 1; 903 description 904 "An AlgorithmIdentifier, as defined in RFC 2986, 905 encoded using ASN.1 distinguished encoding rules 906 (DER), as specified in ITU-T X.690."; 907 reference 908 "RFC 2986: PKCS #10: Certification Request Syntax 909 Specification Version 1.7 910 ITU-T X.690: 912 Information technology - ASN.1 encoding rules: 913 Specification of Basic Encoding Rules (BER), 914 Canonical Encoding Rules (CER) and Distinguished 915 Encoding Rules (DER)."; 916 } 917 } 918 } 919 container csr-generation { 920 description 921 "Specifies details for the ZTP-client's ability to 922 generate a certificate signing requests."; 923 container supported-formats { 924 description 925 "A list of certificate request formats supported 926 by the ZTP-client for generating a new key."; 927 leaf-list format-identifier { 928 type identityref { 929 base zt:certificate-request-format; 930 } 931 min-elements 1; 932 description 933 "A certificate request format supported by the 934 ZTP-client."; 935 } 936 } 937 } 938 } 939 } 941 grouping csr-request-grouping { 942 description 943 "A grouping enabling use by other efforts."; 944 container key-generation { 945 presence 946 "Provided by a ZTP-server to indicate that it wishes 947 the ZTP-client to generate a new asymmetric key. 949 This statement is present so the mandatory descendant 950 nodes do not imply that this node must be configured."; 951 description 952 "The key generation parameters selected by the ZTP-server. 954 This leaf MUST only appear if the ZTP-client's 955 'csr-support' included the 'key-generation' node."; 956 container selected-algorithm { 957 description 958 "The key algorithm selected by the ZTP-server. The 959 algorithm MUST be one of the algorithms specified by 960 the 'supported-algorithms' node in the ZTP-client's 961 message containing the 'csr-support' structure."; 962 leaf algorithm-identifier { 963 type binary; 964 mandatory true; 965 description 966 "An AlgorithmIdentifier, as defined in RFC 2986, 967 encoded using ASN.1 distinguished encoding rules 968 (DER), as specified in ITU-T X.690."; 969 reference 970 "RFC 2986: PKCS #10: Certification Request Syntax 971 Specification Version 1.7 972 ITU-T X.690: 973 Information technology - ASN.1 encoding rules: 974 Specification of Basic Encoding Rules (BER), 975 Canonical Encoding Rules (CER) and Distinguished 976 Encoding Rules (DER)."; 977 } 978 } 979 } 980 container csr-generation { 981 description 982 "Specifies details for the CSR that the ZTP-client 983 is to generate."; 984 container selected-format { 985 description 986 "The CSR format selected by the ZTP-server. The 987 format MUST be one of the formats specified by 988 the 'supported-formats' node in the ZTP-client's 989 request message."; 990 leaf format-identifier { 991 type identityref { 992 base zt:certificate-request-format; 993 } 994 mandatory true; 995 description 996 "A certificate request format to be used by the 997 ZTP-client."; 998 } 999 } 1000 } 1001 leaf cert-req-info { 1002 type ct:csr-info; 1003 description 1004 "A CertificationRequestInfo structure, as defined in 1005 RFC 2986, and modeled via a 'typedef' statement by 1006 RFC AAAA. 1008 Enables the ZTP-server to provide a fully-populated 1009 CertificationRequestInfo structure that the ZTP-client 1010 only needs to sign in order to generate the complete 1011 'CertificationRequest' structure to send to ZTP-server 1012 in its next 'get-bootstrapping-data' request message. 1014 When provided, the ZTP-client SHOULD use this structure 1015 to generate its CSR; failure to do so MAY result in a 1016 400 Bad Request response containing another 'csr-request' 1017 structure. 1019 When not provided, the ZTP-client SHOULD generate a CSR 1020 using the same structure defined in its existing identity 1021 certificate (e.g., an IDevID from IEEE 802.1AR). 1023 If the 'AlgorithmIdentifier' field contained inside the 1024 certificate 'SubjectPublicKeyInfo' field does not match 1025 the algorithm identified by the 'selected-algorithm' node, 1026 then the client MUST reject the certificate and raise an 1027 error."; 1029 reference 1030 "RFC 2986: 1031 PKCS #10: Certification Request Syntax Specification 1032 RFC AAAA: 1033 YANG Data Types and Groupings for Cryptography"; 1034 } 1035 } 1037 grouping csr-grouping { 1038 description 1039 "Enables a ZTP-client to convey a certificate signing 1040 request, using the encoding format selected by a 1041 ZTP-server's 'csr-request' response to the ZTP-client's 1042 previously sent 'get-bootstrapping-data' request 1043 containing the 'csr-support' node."; 1044 choice csr-type { 1045 mandatory true; 1046 description 1047 "A choice amongst certificate signing request formats. 1049 Additional formats MAY be augmented into this 'choice' 1050 statement by future efforts."; 1051 case p10-csr { 1052 leaf p10-csr { 1053 type ct:csr; 1054 description 1055 "A CertificationRequest structure, per RFC 2986. 1057 Encoding details are defined in the 'ct:csr' 1058 typedef defined in RFC AAAA. 1060 A raw P10 does not support origin authentication in 1061 the CSR structure. External origin authentication 1062 may be provided via the ZTP-client's authentication 1063 to the ZTP-server at the transport layer (e.g., TLS)."; 1064 reference 1065 "RFC 2986: PKCS #10: Certification Request Syntax 1066 Specification 1067 RFC AAAA: YANG Data Types and Groupings for 1068 Cryptography"; 1069 } 1070 } 1071 case cmc-csr { 1072 leaf cmc-csr { 1073 type binary; 1074 description 1075 "A constrained version of the 'Full PKI Request' 1076 message defined in RFC 5272, encoded using ASN.1 1077 distinguished encoding rules (DER), as specified 1078 in ITU-T X.690. 1080 For asymmetric key-based origin authentication of a 1081 CSR based on the initial device identity certificate's 1082 private key for the associated identity certificate's 1083 public key, the PKIData contains one reqSequence 1084 element and no cmsSequence or otherMsgSequence 1085 elements. The reqSequence is the TaggedRequest and it 1086 is the tcr CHOICE. The tcr is the 1087 TaggedCertificationRequest and it a bodyPartId and the 1088 certificateRequest elements. The certificateRequest 1089 is signed with the initial device identity 1090 certificate's private key. The initial device identity 1091 certificate and optionally its certificate chain is 1092 included in the SignedData certificates that 1093 encapsulates the PKIData. 1095 For asymmetric key-based origin authentication based on 1096 the initial device identity certificate's private key 1097 that signs the encapsulated CSR signed by the local 1098 device identity certificate's private key, the PKIData 1099 contains one cmsSequence element and no 1100 otherMsgSequence element. The cmsSequence is the 1101 TaggedContentInfo and it includes a bodyPartID element 1102 and a contentInfo. The contentInfo is a SignedData 1103 encapsulating a PKIData with one reqSequence element 1104 and no cmsSequence or otherMsgSequence elements. The 1105 reqSequence is the TaggedRequest and it is the tcr 1106 CHOICE. The tcr is the TaggedCertificationRequest and 1107 it a bodyPartId and the certificateRequest elements. 1108 The certificateRequest is signed with the local device 1109 identity certificate's private key. The initial device 1110 identity certificate and optionally its certificate 1111 chain is included in the SignedData certificates that 1112 encapsulates the PKIData. 1114 For shared secret-based origin authentication of a 1115 CSR signed by the local device identity certificate's 1116 private key, the PKIData contains one cmsSequence 1117 element and no reqSequence or otherMsgSequence 1118 elements. The cmsSequence is the TaggedContentInfo 1119 and it includes a bodyPartID element and a contentInfo. 1120 The contentInfo is an AuthenticatedData encapsulating 1121 a PKIData with one reqSequence element and no 1122 cmsSequences or otherMsgSequence elements. The 1123 reqSequence is the TaggedRequest and it is the tcr 1124 CHOICE. The tcr is the TaggedCertificationRequest and 1125 it a bodyPartId and the certificateRequest elements. 1126 The certificateRequest is signed with the local device 1127 identity certificate's private key. The initial device 1128 identity certificate and optionally its certificate 1129 chain is included in the SignedData certificates that 1130 encapsulates the PKIData."; 1131 reference 1132 "RFC 5272: Certificate Management over CMS (CMC) 1133 ITU-T X.690: 1134 Information technology - ASN.1 encoding rules: 1135 Specification of Basic Encoding Rules (BER), 1136 Canonical Encoding Rules (CER) and Distinguished 1137 Encoding Rules (DER)."; 1138 } 1139 } 1140 case cmp-csr { 1141 leaf cmp-csr { 1142 type binary; 1143 description 1144 "A PKIMessage structure, as defined in RFC 4210, 1145 encoded using ASN.1 distinguished encoding rules 1146 (DER), as specified in ITU-T X.690. 1148 For asymmetric key-based origin authentication of a 1149 CSR based on the initial device identity certificate's 1150 private key for the associated initial device identity 1151 certificate's public key, PKIMessages contains one 1152 PKIMessage with the header and body elements, no 1153 protection element, and should contain the extraCerts 1154 element. The header element contains the pvno, sender, 1155 and recipient elements. The pvno contains cmp2000, and 1156 the sender contains the subject of the initial device 1157 identity certificate. The body element contains a p10cr 1158 CHOICE of type CertificationRequest. It is signed with 1159 the initial device identity certificate's private key. 1160 The extraCerts element contains the initial device 1161 identity certificate, optionally followed by its 1162 certificate chain excluding the trust anchor. 1164 For asymmetric key-based origin authentication based on 1165 the initial device identity certificate's private key 1166 that signs the encapsulated CSR signed by the local 1167 device identity certificate's private key, PKIMessages 1168 contains one PKIMessage with the header, body, and 1169 protection elements, and should contain the extraCerts 1170 element. The header element contains the pvno, sender, 1171 recipient, protectionAlg, and optionally senderKID 1172 elements. The pvno contains cmp2000, the sender 1173 contains the subject of the initial device identity 1174 certificate, the protectionAlg contains the 1175 AlgorithmIdentifier of the used signature algorithm, 1176 and the senderKID contains the subject key identifier 1177 of the initial device identity certificate. The body 1178 element contains a p10cr CHOICE of type 1179 CertificationRequest. It is signed with the local device 1180 identity certificate's private key. The protection 1181 element contains the digital signature generated with 1182 the initial device identity certificate's private key. 1183 The extraCerts element contains the initial device 1184 identity certificate, optionally followed by its 1185 certificate chain excluding the trust anchor. 1187 For shared secret-based origin authentication of a 1188 CSR signed by the local device identity certificate's 1189 private key, PKIMessages contains one PKIMessage with 1190 the header, body, and protection element, and no 1191 extraCerts element. The header element contains the 1192 pvno, sender, recipient, protectionAlg, and senderKID 1193 elements. The pvno contains cmp2000, the protectionAlg 1194 contains the AlgorithmIdentifier of the used MAC 1195 algorithm, and the senderKID contains a reference 1196 the recipient can use to identify the shared secret. 1197 The body element contains a p10cr CHOICE of type 1198 CertificationRequest. It is signed with the local 1199 device identity certificate's private key. The 1200 protection element contains the MAC value generated 1201 with the shared secret."; 1202 reference 1203 "RFC 4210: 1204 Internet X.509 Public Key Infrastructure 1205 Certificate Management Protocol (CMP) 1206 ITU-T X.690: 1207 Information technology - ASN.1 encoding rules: 1208 Specification of Basic Encoding Rules (BER), 1209 Canonical Encoding Rules (CER) and Distinguished 1210 Encoding Rules (DER)."; 1211 } 1212 } 1213 } 1214 } 1216 } 1218 1220 4. Security Considerations 1222 This document builds on top of the solution presented in [RFC8572] 1223 and therefore all the Security Considerations discussed in RFC 8572 1224 apply here as well. 1226 4.1. SZTP-Client Considerations 1228 4.1.1. Ensuring the Integrity of Asymmetric Private Keys 1230 The private key the SZTP-client uses for the dynamically-generated 1231 identity certificate MUST be protected from inadvertent disclosure in 1232 order to prevent identity fraud. 1234 The security of this private key is essential in order to ensure the 1235 associated identity certificate can be used as a root of trust. 1237 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1238 security module), such as a TPM (trusted platform module), to 1239 generate and forever contain the private key within the security 1240 perimeter of the HSM. In such cases, the private key, and its 1241 associated certificates, MAY have long validity periods. 1243 In cases where the SZTP-client does not possess an HSM, or is unable 1244 to use an HSM to protect the private key, it is RECOMMENDED to 1245 periodically reset the private key (and associated identity 1246 certificates) in order to minimize the lifetime of unprotected 1247 private keys. For instance, an NMS controller/orchestrator 1248 application could periodically prompt the SZTP-client to generate a 1249 new private key and provide a certificate signing request (CSR) or, 1250 alternatively, push both the key and an identity certificate to the 1251 SZTP-client using, e.g., a PKCS #12 [RFC7292]. In another example, 1252 the SZTP-client could be configured to periodically reset the 1253 configuration to its factory default, thus causing removal of the 1254 private key and associated identity certificates and reexecution of 1255 the SZTP protocol. 1257 4.1.2. Reuse of a Manufacturer-generated Private Key 1259 It is RECOMMENDED that a new private key is generated for each CSR 1260 described in this document. 1262 Implementations must randomly generate nonces and private keys. The 1263 use of inadequate pseudo-random number generators (PRNGs) to generate 1264 cryptographic keys can result in little or no security. An attacker 1265 may find it much easier to reproduce the PRNG environment that 1266 produced the keys, searching the resulting small set of 1267 possibilities, rather than brute force searching the whole key space. 1268 As an example of predictable random numbers see CVE-2008-0166 1269 [CVE-2008-0166], and some consequences of low-entropy random numbers 1270 are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation 1271 of quality random numbers is difficult. [ISO.20543-2019], 1272 [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and 1273 others offer valuable guidance in this area. 1275 This private key SHOULD be protected as well as the built-in private 1276 key associated with the SZTP-client's initial device identity 1277 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1279 In cases where it is not possible to generate a new private key that 1280 is protected as well as the built-in private key, it is RECOMMENDED 1281 to reuse the built-in private key rather than generate a new private 1282 key that is not as well protected. 1284 4.1.3. Replay Attack Protection 1286 This RFC enables an SZTP-client to announce an ability to generate a 1287 new key to use for its CSR. 1289 When the SZTP-server responds with a request for the SZTP-client to 1290 generate a new key, it is essential that the SZTP-client actually 1291 generates a new key. 1293 Generating a new key each time enables the random bytes used to 1294 create the key to also serve the dual-purpose of acting like a 1295 "nonce" used in other mechanisms to detect replay attacks. 1297 When a fresh public/private key pair is generated for the request, 1298 confirmation to the SZTP-client that the response has not been 1299 replayed is enabled by the SZTP-client's fresh public key appearing 1300 in the signed certificate provided by the SZTP-server. 1302 When a public/private key pair associated with the manufacturer- 1303 generated identity certificate (e.g., IDevID) is used for the 1304 request, there may not be confirmation to the SZTP-client that the 1305 response has not been replayed; however, the worst case result is a 1306 lost certificate that is associated to the private key known only to 1307 the SZTP-client. 1309 4.1.4. Connecting to an Untrusted Bootstrap Server 1311 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1312 by blindly authenticating the SZTP-server's TLS end-entity 1313 certificate. 1315 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1316 client MUST assert that the bootstrapping data returned is signed, if 1317 the SZTP-client is to trust it. 1319 However, the HTTP error message used in this document cannot be 1320 signed data, as described in RFC 8572. 1322 Therefore, the solution presented in this document cannot be used 1323 when the SZTP-client connects to an untrusted SZTP-server. 1325 Consistent with the recommendation presented in Section 9.6 of 1326 [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input 1327 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1328 instead the "signed-data-preferred" input parameter, as discussed in 1329 Appendix B of [RFC8572]. 1331 4.1.5. Selecting the Best Origin Authentication Mechanism 1333 The origin of the CSR must be verified before a certificate is 1334 issued. 1336 When generating a new key, it is important that the SZTP-client be 1337 able to provide additional proof that it was the entity that 1338 generated the key. 1340 The CMP and CMC certificate request formats defined in this document 1341 support origin authentication. A raw PKCS#10 does not support origin 1342 authentication. 1344 The CMP and CMC request formats support origin authentication using 1345 both PKI and shared secret. 1347 Typically, only one possible origin authentication mechanism can 1348 possibly be used but, in the case that the SZTP-client authenticates 1349 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1350 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1351 SZTP-client may need to choose between the two options. 1353 In the case that the SZTP-client must choose between an asymmetric 1354 key option versus a shared secret for origin authentication, it is 1355 RECOMMENDED that the SZTP-client choose using the asymmetric key. 1357 4.1.6. Clearing the Private Key and Associated Certificate 1359 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1360 the deployment-generated identity certificate (e.g., LDevID) and the 1361 associated private key (assuming a new private key was generated for 1362 the purpose), are considered user data and SHOULD be cleared whenever 1363 the SZTP-client is reset to its factory default state, such as by the 1364 "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. 1366 4.2. SZTP-Server Considerations 1368 4.2.1. Verifying Proof of Possession 1370 Regardless if using a new asymmetric key or the bootstrapping 1371 device's manufacturer-generated key (e.g., the IDevID key), the 1372 public key is placed in the CSR and the CSR is signed by that private 1373 key. Proof-of-possession of the private key is verified by ensuring 1374 the signature over the CSR using the public key placed in the CSR. 1376 4.2.2. Verifying Proof of Origin 1378 When the bootstrapping device's manufacturer-generated private key 1379 (e.g., the IDevID key) is reused for the CSR, proof-of-origin is 1380 verified by validating the IDevID-issuer cert and ensuring that the 1381 CSR uses the same key pair. 1383 When a new asymmetric key is used, with the CMP or CMC formats, the 1384 parent ASN.1 structure of the CSR provides origin authentication 1385 using either the manufacturer-generated private key or a shared 1386 secret. In this way the proof-of-possession of the CSR is directly 1387 linked to the proof-or-origin provided by the parent ASN.1 structure. 1389 4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server 1391 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1392 by blindly authenticating the SZTP-server's TLS end-entity 1393 certificate. 1395 As is recommended in Section 4.1.4 in this document, in such cases, 1396 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1398 The reciprocal of this statement is that SZTP-servers, wanting to 1399 support SZTP-clients that don't trust them, SHOULD support the 1400 "signed-data-preferred" input parameter, as discussed in Appendix B 1401 of [RFC8572]. 1403 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module 1405 The recommended format for documenting the Security Considerations 1406 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1407 this module only augments two input parameters into the "get- 1408 bootstrapping-data" RPC in [RFC8572], and therefore only needs to 1409 point to the relevant Security Considerations sections in that RFC. 1411 * Security considerations for the "get-bootstrapping-data" RPC are 1412 described in Section 9.16 of [RFC8572]. 1414 * Security considerations for the "input" parameters passed inside 1415 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1416 [RFC8572]. 1418 4.4. Security Considerations for the "ietf-ztp-types" YANG Module 1420 The recommended format for documenting the Security Considerations 1421 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1422 this module does not define any protocol-accessible nodes (it only 1423 defines "identity" and "grouping" statements) and therefore there are 1424 no Security considerations to report. 1426 5. IANA Considerations 1428 5.1. The "IETF XML" Registry 1430 This document registers two URIs in the "ns" subregistry of the IETF 1431 XML Registry [RFC3688] maintained at 1432 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1433 Following the format in [RFC3688], the following registrations are 1434 requested: 1436 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1437 Registrant Contact: The NETCONF WG of the IETF. 1438 XML: N/A, the requested URI is an XML namespace. 1440 URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1441 Registrant Contact: The NETCONF WG of the IETF. 1442 XML: N/A, the requested URI is an XML namespace. 1444 5.2. The "YANG Module Names" Registry 1446 This document registers two YANG modules in the YANG Module Names 1447 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1448 yang-parameters/yang-parameters.xhtml. Following the format defined 1449 in [RFC6020], the below registrations are requested: 1451 name: ietf-sztp-csr 1452 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1453 prefix: sztp-csr 1454 reference: RFC XXXX 1456 name: ietf-ztp-types 1457 namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1458 prefix: ztp-types 1459 reference: RFC XXXX 1461 6. References 1463 6.1. Normative References 1465 [I-D.ietf-netconf-crypto-types] 1466 Watsen, K., "YANG Data Types and Groupings for 1467 Cryptography", Work in Progress, Internet-Draft, draft- 1468 ietf-netconf-crypto-types-21, 14 September 2021, 1469 . 1472 [ITU.X690.2015] 1473 International Telecommunication Union, "Information 1474 Technology - ASN.1 encoding rules: Specification of Basic 1475 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1476 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1477 X.690, ISO/IEC 8825-1, August 2015, 1478 . 1480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1481 Requirement Levels", BCP 14, RFC 2119, 1482 DOI 10.17487/RFC2119, March 1997, 1483 . 1485 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1486 Request Syntax Specification Version 1.7", RFC 2986, 1487 DOI 10.17487/RFC2986, November 2000, 1488 . 1490 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1491 DOI 10.17487/RFC3688, January 2004, 1492 . 1494 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1495 "Internet X.509 Public Key Infrastructure Certificate 1496 Management Protocol (CMP)", RFC 4210, 1497 DOI 10.17487/RFC4210, September 2005, 1498 . 1500 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1501 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1502 . 1504 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1505 the Network Configuration Protocol (NETCONF)", RFC 6020, 1506 DOI 10.17487/RFC6020, October 2010, 1507 . 1509 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1510 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1511 . 1513 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1514 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1515 . 1517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1518 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1519 May 2017, . 1521 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1522 Touch Provisioning (SZTP)", RFC 8572, 1523 DOI 10.17487/RFC8572, April 2019, 1524 . 1526 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 1527 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1528 June 2020, . 1530 6.2. Informative References 1532 [AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI), 1533 "Application Notes and Interpretation of the Scheme (AIS) 1534 31 - Functionality Classes and Evaluation Methodology for 1535 Physical Random Number Generators", 25 September 2001. 1537 [CVE-2008-0166] 1538 National Institute of Science and Technology (NIST), 1539 "National Vulnerability Database - CVE-2008-0166", 13 May 1540 2008, . 1542 [I-D.ietf-netconf-keystore] 1543 Watsen, K., "A YANG Data Model for a Keystore", Work in 1544 Progress, Internet-Draft, draft-ietf-netconf-keystore-22, 1545 18 May 2021, . 1548 [I-D.ietf-netconf-trust-anchors] 1549 Watsen, K., "A YANG Data Model for a Truststore", Work in 1550 Progress, Internet-Draft, draft-ietf-netconf-trust- 1551 anchors-15, 18 May 2021, 1552 . 1555 [I-D.ietf-netmod-factory-default] 1556 Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1557 Factory Default Settings", Work in Progress, Internet- 1558 Draft, draft-ietf-netmod-factory-default-15, 25 April 1559 2020, . 1562 [ISO.20543-2019] 1563 International Organization for Standardization (ISO), 1564 "Information technology -- Security techniques -- Test and 1565 analysis methods for random bit generators within ISO/IEC 1566 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, 1567 October 2019. 1569 [MiningPsQs] 1570 Security'12: Proceedings of the 21st USENIX conference on 1571 Security symposium, Heninger, N., Durumeric, Z., Wustrow, 1572 E., and J. A. Halderman, "Mining Your Ps and Qs: Detection 1573 of Widespread Weak Keys in Network Devices", August 2012, 1574 . 1577 [NIST.SP.800-90Ar1] 1578 Barker, Elaine B. and John M. Kelsey, "Recommendation for 1579 Random Number Generation Using Deterministic Random Bit 1580 Generators", DOI 10.6028/NIST.SP.800-90Ar1, NIST NIST SP 1581 800-90Ar1, June 2015, 1582 . 1585 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1586 "Randomness Requirements for Security", BCP 106, RFC 4086, 1587 DOI 10.17487/RFC4086, June 2005, 1588 . 1590 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 1591 and M. Scott, "PKCS #12: Personal Information Exchange 1592 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 1593 . 1595 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1596 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1597 . 1599 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1600 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1601 DOI 10.17487/RFC8407, October 2018, 1602 . 1604 [Std-802.1AR-2018] 1605 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1606 metropolitan area networks - Secure Device Identity", 14 1607 June 2018, . 1610 Acknowledgements 1612 The authors would like to thank for following for lively discussions 1613 on list and in the halls (ordered by first name): David von Oheimb, 1614 Hendrik Brockhaus, Guy Fedorkow, Joe Clarke, Rich Salz, Rob Wilton, 1615 and Qin Wu. 1617 Contributors 1619 Special thanks goes to David von Oheimb and Hendrik Brockhaus for 1620 helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. 1622 Authors' Addresses 1624 Kent Watsen 1625 Watsen Networks 1627 Email: kent+ietf@watsen.net 1628 Russ Housley 1629 Vigil Security, LLC 1631 Email: housley@vigilsec.com 1633 Sean Turner 1634 sn3rd 1636 Email: sean@sn3rd.com