idnits 2.17.00 (12 Aug 2021) /tmp/idnits3109/draft-ietf-netconf-sztp-csr-08.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: ---------------------------------------------------------------------------- == There is 1 instance 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 222 has weird spacing: '...ntifier bin...' == Line 225 has weird spacing: '...ntifier ide...' == Line 296 has weird spacing: '...rmation cms...' == Line 315 has weird spacing: '...ntifier bin...' == Line 318 has weird spacing: '...ntifier ide...' == (2 more instances...) -- The document date (24 August 2021) is 269 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-20 -- 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: 25 February 2022 S. Turner 7 sn3rd 8 24 August 2021 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-ietf-netconf-sztp-csr-08 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- 35 types 37 Artwork in this document contains a placeholder value for the 38 publication date of this draft. Please apply the following 39 replacement: 41 * "2021-08-24" --> the publication date of this draft 43 This document contains references to other drafts in progress, both 44 in the Normative References section, as well as in body text 45 throughout. Please update the following references to reflect their 46 final RFC assignments: 48 * I-D.ietf-netconf-crypto-types 49 * I-D.ietf-netconf-keystore 51 * I-D.ietf-netconf-trust-anchors 53 * I-D.ietf-netmod-factory-default 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on 25 February 2022. 72 Copyright Notice 74 Copyright (c) 2021 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 79 license-info) in effect on the date of publication of this document. 80 Please review these documents carefully, as they describe your rights 81 and restrictions with respect to this document. Code Components 82 extracted from this document must include Simplified BSD License text 83 as described in Section 4.e of the Trust Legal Provisions and are 84 provided without warranty as described in the Simplified BSD License. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 89 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 90 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 91 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 92 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 93 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 94 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 95 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 96 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 98 3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17 99 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 100 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 101 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27 103 4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27 104 4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 27 105 4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28 106 4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 28 107 4.1.5. Selecting the Best Origin Authentication Mechanism . 29 108 4.1.6. Clearing the Private Key and Associated 109 Certificate . . . . . . . . . . . . . . . . . . . . . 29 110 4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 29 111 4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 29 112 4.2.2. Supporting SZTP-Clients that don't trust the 113 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 30 114 4.3. Security Considerations for the "ietf-sztp-csr" YANG 115 Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 4.4. Security Considerations for the "ietf-ztp-types" YANG 117 Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 119 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31 120 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 31 121 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 122 6.1. Normative References . . . . . . . . . . . . . . . . . . 31 123 6.2. Informative References . . . . . . . . . . . . . . . . . 33 124 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 125 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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 bootstraped device to join the production environment with an 142 appropriate identity and other attributes in its LDevID certificate. 144 Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module 145 defines three YANG groupings for the various messages defined in this 146 document. The "ietf-sztp-csr" module augments two groupings into the 147 "get-bootstrapping-data" RPC and defines a YANG Data Structure 148 [RFC8791] around the third grouping. 150 1.2. Terminology 152 This document uses the following terms from [RFC8572]: 154 * Bootstrap Server 155 * Bootstrapping Data 156 * Conveyed Information 157 * Device 158 * Manufacturer 159 * Onboarding Information 160 * Signed Data 162 This document defines the following new terms: 164 SZTP-client The term "SZTP-client" refers to a "device" that is 165 using a "bootstrap server" as a source of "bootstrapping data". 167 SZTP-server The term "SZTP-server" is an alternative term for 168 "bootstrap server" that is symmetric with the "SZTP-client" term. 170 1.3. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 1.4. Conventions 180 Various examples used in this document use a placeholder value for 181 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 182 This placeholder value is used as real base64 encoded structures are 183 often many lines long and hence distracting to the example being 184 presented. 186 2. The "ietf-sztp-csr" Module 188 The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that 189 augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572] 190 and defines a YANG "structure" that is to be conveyed in the "error- 191 info" node defined in Section 7.1 of [RFC8040]. 193 2.1. Data Model Overview 195 The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" 196 module. 198 module: ietf-sztp-csr 200 augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: 201 +---w (msg-type)? 202 +--:(csr-support) 203 | +---w csr-support 204 | +---w key-generation! 205 | | +---w supported-algorithms 206 | | +---w algorithm-identifier* binary 207 | +---w csr-generation 208 | +---w supported-formats 209 | +---w format-identifier* identityref 210 +--:(csr) 211 +---w (csr-type) 212 +--:(p10-csr) 213 | +---w p10-csr? ct:csr 214 +--:(cmc-csr) 215 | +---w cmc-csr? binary 216 +--:(cmp-csr) 217 +---w cmp-csr? binary 219 structure: csr-request 220 +--ro key-generation! 221 | +--ro selected-algorithm 222 | +--ro algorithm-identifier binary 223 +--ro csr-generation 224 | +--ro selected-format 225 | +--ro format-identifier identityref 226 +--ro cert-req-info? ietf-crypto-types:csr-info 228 The augmentation defines two kinds of parameters that an SZTP-client 229 can send to an SZTP-server. The YANG structure defines one 230 collection of parameters that an SZTP-server can send to an SZTP- 231 client. 233 In the order of their intended use: 235 * The "csr-support" node is used by the SZTP-client to signal to the 236 SZTP-server that it supports the ability the generate CSRs. This 237 parameter conveys if the SZTP-client is able to generate an new 238 asymmetric key and, if so, which key algorithms it supports, as 239 well as conveys what kinds of CSR structures the SZTP-client is 240 able to generate. 242 * The "csr-request" structure is used by the SZTP-server to request 243 the SZTP-client to generate a CSR. This structure is used to 244 select the key algorithm the SZTP-client should use to generate a 245 new asymmetric key, if supported, the kind of CSR structure the 246 SZTP-client should generate and, optionally, the content for the 247 CSR itself. 249 * The various "csr" nodes are used by the SZTP-client to communicate 250 a CSR to the SZTP-server. 252 | No data model is defined enabling an SZTP-server to communicate 253 | the signed certificate to the SZTP-client. How to do this is 254 | discussed in Section 2.2. 256 To further illustrate how the augmentation and structure defined by 257 the "ietf-sztp-csr" module are used, below are two additional tree 258 diagrams showing these nodes placed where they are used. 260 The following tree diagram [RFC8340] illustrates SZTP's "get- 261 bootstrapping-data" RPC with the augmentation in place. 263 =============== NOTE: '\' line wrapping per RFC 8792 ================ 265 module: ietf-sztp-bootstrap-server 267 rpcs: 268 +---x get-bootstrapping-data 269 +---w input 270 | +---w signed-data-preferred? empty 271 | +---w hw-model? string 272 | +---w os-name? string 273 | +---w os-version? string 274 | +---w nonce? binary 275 | +---w (sztp-csr:msg-type)? 276 | +--:(sztp-csr:csr-support) 277 | | +---w sztp-csr:csr-support 278 | | +---w sztp-csr:key-generation! 279 | | | +---w sztp-csr:supported-algorithms 280 | | | +---w sztp-csr:algorithm-identifier* bina\ 281 ry 282 | | +---w sztp-csr:csr-generation 283 | | +---w sztp-csr:supported-formats 284 | | +---w sztp-csr:format-identifier* identit\ 285 yref 286 | +--:(sztp-csr:csr) 287 | +---w (sztp-csr:csr-type) 288 | +--:(sztp-csr:p10-csr) 289 | | +---w sztp-csr:p10-csr? ct:csr 290 | +--:(sztp-csr:cmc-csr) 291 | | +---w sztp-csr:cmc-csr? binary 292 | +--:(sztp-csr:cmp-csr) 293 | +---w sztp-csr:cmp-csr? binary 294 +--ro output 295 +--ro reporting-level? enumeration {onboarding-server}? 296 +--ro conveyed-information cms 297 +--ro owner-certificate? cms 298 +--ro ownership-voucher? cms 300 The following tree diagram [RFC8340] illustrates RESTCONF's "errors" 301 RPC-reply message with the "csr-request" structure in place. 303 module: ietf-restconf 304 +--ro errors 305 +--ro error* [] 306 +--ro error-type enumeration 307 +--ro error-tag string 308 +--ro error-app-tag? string 309 +--ro error-path? instance-identifier 310 +--ro error-message? string 311 +--ro error-info 312 +--ro csr-request 313 +--ro key-generation! 314 | +--ro selected-algorithm 315 | +--ro algorithm-identifier binary 316 +--ro csr-generation 317 | +--ro selected-format 318 | +--ro format-identifier identityref 319 +--ro cert-req-info? ct:csr-info 321 2.2. Example Usage 323 | The examples below are encoded using JSON, but they could 324 | equally well be encoded using XML, as is supported by SZTP. 326 An SZTP-client implementing this specification would signal to the 327 bootstrap server its willingness to generate a CSR by including the 328 "csr-support" node in its "get-bootstrapping-data" RPC, as 329 illustrated below. 331 REQUEST 332 =============== NOTE: '\' line wrapping per RFC 8792 ================ 334 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 335 ng-data HTTP/1.1 336 HOST: example.com 337 Content-Type: application/yang.data+json 339 { 340 "ietf-sztp-bootstrap-server:input" : { 341 "hw-model": "model-x", 342 "os-name": "vendor-os", 343 "os-version": "17.3R2.1", 344 "nonce": "extralongbase64encodedvalue=", 345 "ietf-sztp-csr:csr-support": { 346 "key-generation": { 347 "supported-algorithms": { 348 "algorithm-identifier": [ 349 "BASE64VALUE1", 350 "BASE64VALUE2", 351 "BASE64VALUE3" 352 ] 353 } 354 }, 355 "csr-generation": { 356 "supported-formats": { 357 "format-identifier": [ 358 "ietf-ztp-types:p10-csr", 359 "ietf-ztp-types:cmc-csr", 360 "ietf-ztp-types:cmp-csr" 361 ] 362 } 363 } 364 } 365 } 366 } 368 Assuming the SZTP-server wishes to prompt the SZTP-client to provide 369 a CSR, then it would respond with an HTTP 400 Bad Request error code: 371 RESPONSE 372 HTTP/1.1 400 Bad Request 373 Date: Sat, 31 Oct 2015 17:02:40 GMT 374 Server: example-server 375 Content-Type: application/yang.data+json 377 { 378 "ietf-restconf:errors" : { 379 "error" : [ 380 { 381 "error-type": "application", 382 "error-tag": "missing-attribute", 383 "error-message": "Missing input parameter", 384 "error-info": { 385 "ietf-sztp-csr:csr-request": { 386 "key-generation": { 387 "selected-algorithm": { 388 "algorithm-identifier": "BASE64VALUE=" 389 } 390 }, 391 "csr-generation": { 392 "selected-format": { 393 "format-identifier": "ietf-ztp-types:p10-csr" 394 } 395 }, 396 "cert-req-info": "BASE64VALUE=" 397 } 398 } 399 } 400 ] 401 } 402 } 404 Upon being prompted to provide a CSR, the SZTP-client would POST 405 another "get-bootstrapping-data" request, but this time including one 406 of the "csr" nodes to convey its CSR to the SZTP-server: 408 REQUEST 409 =============== NOTE: '\' line wrapping per RFC 8792 ================ 411 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 412 ng-data HTTP/1.1 413 HOST: example.com 414 Content-Type: application/yang.data+json 416 { 417 "ietf-sztp-bootstrap-server:input" : { 418 "hw-model": "model-x", 419 "os-name": "vendor-os", 420 "os-version": "17.3R2.1", 421 "nonce": "extralongbase64encodedvalue=", 422 "ietf-sztp-csr:p10-csr": "BASE64VALUE=" 423 } 424 } 426 At this point, it is expected that the SZTP-server, perhaps in 427 conjunction with other systems, such as a backend CA or RA, will 428 validate the CSR's origin and proof-of-possession and, assuming the 429 CSR is approved, issue a signed certificate for the bootstrapping 430 device. 432 The SZTP-server responds with "onboarding-information" (encoded 433 inside the "conveyed-information" node, shown below) containing a 434 signed identity certificate for the CSR provided by the SZTP-client: 436 RESPONSE 438 HTTP/1.1 200 OK 439 Date: Sat, 31 Oct 2015 17:02:40 GMT 440 Server: example-server 441 Content-Type: application/yang.data+json 443 { 444 "ietf-sztp-bootstrap-server:output" : { 445 "reporting-level": "verbose", 446 "conveyed-information": "BASE64VALUE=" 447 } 448 } 450 How the signed certificate is conveyed inside the onboarding 451 information is outside the scope of this document. Some 452 implementations may choose to convey it inside a script (e.g., SZTP's 453 "pre-configuration-script"), while other implementations may choose 454 to convey it inside the SZTP "configuration" node. SZTP onboarding 455 information is described in Section 2.2 of [RFC8572]. 457 Following are two examples of conveying the signed certificate inside 458 the "configuration" node. Both examples assume that the SZTP-client 459 understands the "ietf-keystore" module defined in 460 [I-D.ietf-netconf-keystore]. 462 This first example illustrates the case where the signed certificate 463 is for the same asymmetric key used by the SZTP-client's 464 manufacturer-generated identity certificate (e.g., an IDevID, from 465 [Std-802.1AR-2018]). As such, the configuration needs to associate 466 the newly signed certificate with the existing asymmetric key: 468 =============== NOTE: '\' line wrapping per RFC 8792 ================ 470 { 471 "ietf-keystore:keystore": { 472 "asymmetric-keys": { 473 "asymmetric-key": [ 474 { 475 "name": "Manufacturer-Generated Hidden Key", 476 "public-key-format": "ietf-crypto-types:subject-public-key\ 477 -info-format", 478 "public-key": "BASE64VALUE=", 479 "hidden-private-key": [null], 480 "certificates": { 481 "certificate": [ 482 { 483 "name": "Manufacturer-Generated IDevID Cert", 484 "cert-data": "BASE64VALUE=" 485 }, 486 { 487 "name": "Newly-Generated LDevID Cert", 488 "cert-data": "BASE64VALUE=" 489 } 490 ] 491 } 492 } 493 ] 494 } 495 } 496 } 498 This second example illustrates the case where the signed certificate 499 is for a newly generated asymmetric key. As such, the configuration 500 needs to associate the newly signed certificate with the newly 501 generated asymmetric key: 503 =============== NOTE: '\' line wrapping per RFC 8792 ================ 505 { 506 "ietf-keystore:keystore": { 507 "asymmetric-keys": { 508 "asymmetric-key": [ 509 { 510 "name": "Manufacturer-Generated Hidden Key", 511 "public-key-format": "ietf-crypto-types:subject-public-key\ 512 -info-format", 513 "public-key": "BASE64VALUE=", 514 "hidden-private-key": [null], 515 "certificates": { 516 "certificate": [ 517 { 518 "name": "Manufacturer-Generated IDevID Cert", 519 "cert-data": "BASE64VALUE=" 520 } 521 ] 522 } 523 }, 524 { 525 "name": "Newly-Generated Hidden Key", 526 "public-key-format": "ietf-crypto-types:subject-public-key\ 527 -info-format", 528 "public-key": "BASE64VALUE=", 529 "hidden-private-key": [null], 530 "certificates": { 531 "certificate": [ 532 { 533 "name": "Newly-Generated LDevID Cert", 534 "cert-data": "BASE64VALUE=" 535 } 536 ] 537 } 538 } 539 ] 540 } 541 } 542 } 544 In addition to configuring the signed certificate, it is often 545 necessary to also configure the Issuer's signing certificate so that 546 the device (i.e., STZP-client) can authenticate certificates 547 presented by peer devices signed by the same issuer as its own. 548 While outside the scope of this document, one way to do this would be 549 to use the "ietf-truststore" module defined in 550 [I-D.ietf-netconf-trust-anchors]. 552 2.3. YANG Module 554 This module augments an RPC defined in [RFC8572]. The module uses a 555 data types and groupings defined in [RFC8572], [RFC8791], and 556 [I-D.ietf-netconf-crypto-types]. The module has additional normative 557 references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015], 558 and an informative reference to [Std-802.1AR-2018]. 560 file "ietf-sztp-csr@2021-08-24.yang" 562 module ietf-sztp-csr { 563 yang-version 1.1; 564 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 565 prefix sztp-csr; 567 import ietf-sztp-bootstrap-server { 568 prefix sztp-svr; 569 reference 570 "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 571 } 573 import ietf-yang-structure-ext { 574 prefix sx; 575 reference 576 "RFC 8791: YANG Data Structure Extensions"; 577 } 579 import ietf-ztp-types { 580 prefix zt; 581 reference 582 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 583 in a Secure Zero Touch Provisioning (SZTP) 584 Bootstrapping Request"; 585 } 587 organization 588 "IETF NETCONF (Network Configuration) Working Group"; 590 contact 591 "WG Web: http://tools.ietf.org/wg/netconf 592 WG List: 593 Authors: Kent Watsen 594 Russ Housley 595 Sean Turner "; 597 description 598 "This module augments the 'get-bootstrapping-data' RPC, 599 defined in the 'ietf-sztp-bootstrap-server' module from 600 SZTP (RFC 8572), enabling the SZTP-client to obtain a 601 signed identity certificate (e.g., an LDevID from IEEE 602 802.1AR) as part of the SZTP onboarding information 603 response. 605 Copyright (c) 2021 IETF Trust and the persons identified 606 as authors of the code. All rights reserved. 608 Redistribution and use in source and binary forms, with 609 or without modification, is permitted pursuant to, and 610 subject to the license terms contained in, the Simplified 611 BSD License set forth in Section 4.c of the IETF Trust's 612 Legal Provisions Relating to IETF Documents 613 (https://trustee.ietf.org/license-info). 615 This version of this YANG module is part of RFC XXXX 616 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 617 itself for full legal notices. 619 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 620 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 621 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 622 document are to be interpreted as described in BCP 14 623 (RFC 2119) (RFC 8174) when, and only when, they appear 624 in all capitals, as shown here."; 626 revision 2021-08-24 { 627 description 628 "Initial version"; 629 reference 630 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 631 in a Secure Zero Touch Provisioning (SZTP) 632 Bootstrapping Request"; 633 } 635 // Protocol-accessible nodes 637 augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { 638 description 639 "This augmentation adds the 'csr-support' and 'csr' nodes to 640 the SZTP (RFC 8572) 'get-bootstrapping-data' request message, 641 enabling the SZTP-client to obtain an identity certificate 642 (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding 643 information response provided by the SZTP-server. 645 The 'csr-support' node enables the SZTP-client to indicate 646 that it supports generating certificate signing requests 647 (CSRs), and to provide details around the CSRs it is able 648 to generate. 650 The 'csr' node enables the SZTP-client to relay a CSR to 651 the SZTP-server."; 652 reference 653 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 654 area networks - Secure Device Identity 655 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 656 choice msg-type { 657 description 658 "Messages are mutually exclusive."; 659 case csr-support { 660 description 661 "Indicates how the SZTP-client supports generating CSRs. 663 If present and a SZTP-server wishes to request the 664 SZTP-client generate a CSR, the SZTP-server MUST 665 respond with HTTP code 400 Bad Request with an 666 'ietf-restconf:errors' message having the 'error-tag' 667 value 'missing-attribute' and the 'error-info' node 668 containing the 'csr-request' structure described 669 in this module."; 670 uses zt:csr-support-grouping; 671 } 672 case csr { 673 description 674 "Provides the CSR generated by the SZTP-client. 676 When present, the SZTP-server SHOULD respond with 677 an SZTP onboarding information message containing 678 a signed certificate for the conveyed CSR. The 679 SZTP-server MAY alternatively respond with another 680 HTTP error containing another 'csr-request', in 681 which case the SZTP-client MUST invalidate the 682 previously generated CSR."; 683 uses zt:csr-grouping; 684 } 685 } 686 } 688 sx:structure csr-request { 689 description 690 "A YANG data structure, per RFC 8791, that specifies 691 details for the CSR that the ZTP-client is to generate."; 692 reference 693 "RFC 8791: YANG Data Structure Extensions"; 694 uses zt:csr-request-grouping; 695 } 697 } 699 701 3. The "ietf-ztp-types" Module 703 This section defines a YANG 1.1 [RFC7950] module that defines three 704 YANG groupings, one each for messages sent between a ZTP-client and 705 ZTP-server. This module is defines independently of the "ietf-sztp- 706 csr" module so that it's groupings may be used by bootstrapping 707 protocols other than SZTP [RFC8572]. 709 3.1. Data Model Overview 711 The following tree diagram [RFC8340] illustrates the three groupings 712 defined in the "ietf-ztp-types" module. 714 module: ietf-ztp-types 716 grouping csr-support-grouping 717 +-- csr-support 718 +-- key-generation! 719 | +-- supported-algorithms 720 | +-- algorithm-identifier* binary 721 +-- csr-generation 722 +-- supported-formats 723 +-- format-identifier* identityref 724 grouping csr-request-grouping 725 +-- key-generation! 726 | +-- selected-algorithm 727 | +-- algorithm-identifier binary 728 +-- csr-generation 729 | +-- selected-format 730 | +-- format-identifier identityref 731 +-- cert-req-info? ct:csr-info 732 grouping csr-grouping 733 +-- (csr-type) 734 +--:(p10-csr) 735 | +-- p10-csr? ct:csr 736 +--:(cmc-csr) 737 | +-- cmc-csr? binary 738 +--:(cmp-csr) 739 +-- cmp-csr? binary 741 3.2. YANG Module 743 This module uses a data types and groupings [RFC8791] and 744 [I-D.ietf-netconf-crypto-types]. The module has additional normative 745 references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], 746 and an informative reference to [Std-802.1AR-2018]. 748 file "ietf-ztp-types@2021-08-24.yang" 750 module ietf-ztp-types { 751 yang-version 1.1; 752 namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; 753 prefix zt; 755 import ietf-crypto-types { 756 prefix ct; 757 reference 758 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 759 } 761 organization 762 "IETF NETCONF (Network Configuration) Working Group"; 764 contact 765 "WG Web: http://tools.ietf.org/wg/netconf 766 WG List: 767 Authors: Kent Watsen 768 Russ Housley 769 Sean Turner "; 771 description 772 "This module defines three groupings that enable 773 bootstrapping devices to 1) indicate if and how they 774 support generating CSRs, 2) obtain a request to 775 generate a CSR, and 3) communicate the requested CSR. 777 The terms 'IDevID' and 'LDevID' are used herein to 778 mean 'initial device identifier' and 'local device 779 identifer'. These terms are defined consistent with 780 the IEEE 802.1AR specification, though there is no 781 requirement that a ZTP-client's identity certificate 782 conform to IEEE 802.1AR. 784 Copyright (c) 2021 IETF Trust and the persons identified 785 as authors of the code. All rights reserved. 787 Redistribution and use in source and binary forms, with 788 or without modification, is permitted pursuant to, and 789 subject to the license terms contained in, the Simplified 790 BSD License set forth in Section 4.c of the IETF Trust's 791 Legal Provisions Relating to IETF Documents 792 (https://trustee.ietf.org/license-info). 794 This version of this YANG module is part of RFC XXXX 795 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 796 itself for full legal notices. 798 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 799 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 800 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 801 document are to be interpreted as described in BCP 14 802 (RFC 2119) (RFC 8174) when, and only when, they appear 803 in all capitals, as shown here."; 805 revision 2021-08-24 { 806 description 807 "Initial version"; 808 reference 809 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 810 in a Secure Zero Touch Provisioning (SZTP) 811 Bootstrapping Request"; 812 } 814 identity certificate-request-format { 815 description 816 "A base identity for the request formats supported 817 by the ZTP-client. 819 Additional derived identities MAY be defined by 820 future efforts."; 821 } 823 identity p10-csr { 824 base certificate-request-format; 825 description 826 "Indicates that the ZTP-client supports generating 827 requests using the 'CertificationRequest' structure 828 defined in RFC 2986."; 829 reference 830 "RFC 2986: PKCS #10: Certification Request Syntax 831 Specification Version 1.7"; 832 } 834 identity cmp-csr { 835 base certificate-request-format; 836 description 837 "Indicates that the ZTP-client supports generating 838 requests using a constrained version of the PKIMessage 839 containing a p10cr structure defined in RFC 4210."; 840 reference 841 "RFC 4210: Internet X.509 Public Key Infrastructure 842 Certificate Management Protocol (CMP)"; 843 } 845 identity cmc-csr { 846 base certificate-request-format; 847 description 848 "Indicates that the ZTP-client supports generating 849 requests using a constrained version of the 'Full 850 PKI Request' structure defined in RFC 5272."; 851 reference 852 "RFC 5272: Certificate Management over CMS (CMC)"; 853 } 855 // Protocol-accessible nodes 857 grouping csr-support-grouping { 858 description 859 "A grouping enabling use by other efforts."; 860 container csr-support { 861 description 862 "Enables a ZTP-client to indicate that it supports 863 generating certificate signing requests (CSRs) and 864 provides details about the CSRs it is able to 865 generate."; 866 container key-generation { 867 presence 868 "Indicates that the ZTP-client is capable of 869 generating a new asymmetric key pair. 871 If this node is not present, the ZTP-server MAY 872 request a CSR using the asymmetric key associated 873 with the device's existing identity certificate 874 (e.g., an IDevID from IEEE 802.1AR)."; 875 description 876 "Specifies details for the ZTP-client's ability to 877 generate a new asymmetric key pair."; 878 container supported-algorithms { 879 description 880 "A list of public key algorithms supported by the 881 ZTP-client for generating a new asymmetric key."; 882 leaf-list algorithm-identifier { 883 type binary; 884 min-elements 1; 885 description 886 "An AlgorithmIdentifier, as defined in RFC 2986, 887 encoded using ASN.1 distinguished encoding rules 888 (DER), as specified in ITU-T X.690."; 889 reference 890 "RFC 2986: PKCS #10: Certification Request Syntax 891 Specification Version 1.7 892 ITU-T X.690: 893 Information technology - ASN.1 encoding rules: 894 Specification of Basic Encoding Rules (BER), 895 Canonical Encoding Rules (CER) and Distinguished 896 Encoding Rules (DER)."; 897 } 898 } 899 } 900 container csr-generation { 901 description 902 "Specifies details for the ZTP-client's ability to 903 generate a certificate signing requests."; 904 container supported-formats { 905 description 906 "A list of certificate request formats supported 907 by the ZTP-client for generating a new key."; 908 leaf-list format-identifier { 909 type identityref { 910 base zt:certificate-request-format; 911 } 912 min-elements 1; 913 description 914 "A certificate request format supported by the 915 ZTP-client."; 916 } 917 } 918 } 919 } 920 } 922 grouping csr-request-grouping { 923 description 924 "A grouping enabling use by other efforts."; 925 container key-generation { 926 presence 927 "Provided by a ZTP-server to indicate that it wishes 928 the ZTP-client to generate a new asymmetric key. 930 This statement is present so the mandatory descendant 931 nodes do not imply that this node must be configured."; 932 description 933 "The key generation parameters selected by the ZTP-server. 935 This leaf MUST only appear if the ZTP-client's 936 'csr-support' included the 'key-generation' node."; 937 container selected-algorithm { 938 description 939 "The key algorithm selected by the ZTP-server. The 940 algorithm MUST be one of the algorithms specified by 941 the 'supported-algorithms' node in the ZTP-client's 942 message containing the 'csr-support' structure."; 943 leaf algorithm-identifier { 944 type binary; 945 mandatory true; 946 description 947 "An AlgorithmIdentifier, as defined in RFC 2986, 948 encoded using ASN.1 distinguished encoding rules 949 (DER), as specified in ITU-T X.690."; 950 reference 951 "RFC 2986: PKCS #10: Certification Request Syntax 952 Specification Version 1.7 953 ITU-T X.690: 954 Information technology - ASN.1 encoding rules: 955 Specification of Basic Encoding Rules (BER), 956 Canonical Encoding Rules (CER) and Distinguished 957 Encoding Rules (DER)."; 958 } 959 } 960 } 961 container csr-generation { 962 description 963 "Specifies details for the CSR that the ZTP-client 964 is to generate."; 965 container selected-format { 966 description 967 "The CSR format selected by the ZTP-server. The 968 format MUST be one of the formats specified by 969 the 'supported-formats' node in the ZTP-client's 970 request message."; 971 leaf format-identifier { 972 type identityref { 973 base zt:certificate-request-format; 974 } 975 mandatory true; 976 description 977 "A certificate request format to be used by the 978 ZTP-client."; 979 } 980 } 982 } 983 leaf cert-req-info { 984 type ct:csr-info; 985 description 986 "A CertificationRequestInfo structure, as defined in 987 RFC 2986, and modeled via a 'typedef' statement by 988 RFC AAAA. 990 Enables the ZTP-server to provide a fully-populated 991 CertificationRequestInfo structure that the ZTP-client 992 only needs to sign in order to generate the complete 993 'CertificationRequest' structure to send to ZTP-server 994 in its next 'get-bootstrapping-data' request message. 996 When provided, the ZTP-client SHOULD use this 997 structure to generate its CSR; failure to do so MAY 998 result in a 400 Bad Request response containing 999 another 'csr-request' structure. 1001 When not provided, the ZTP-client SHOULD generate a 1002 CSR using the same structure defined in its existing 1003 identity certificate (e.g., IDevID). 1005 It is an error if the 'AlgorithmIdentifier' field 1006 contained inside the 'SubjectPublicKeyInfo' field 1007 does not match the algorithm identified by the 1008 'selected-algorithm' node."; 1009 reference 1010 "RFC 2986: 1011 PKCS #10: Certification Request Syntax Specification 1012 RFC AAAA: 1013 YANG Data Types and Groupings for Cryptography"; 1014 } 1015 } 1017 grouping csr-grouping { 1018 description 1019 "Enables a ZTP-client to convey a certificate signing 1020 request, using the encoding format selected by a 1021 ZTP-server's 'csr-request' response to the ZTP-client's 1022 previously sent 'get-bootstrapping-data' request 1023 containing the 'csr-support' node."; 1024 choice csr-type { 1025 mandatory true; 1026 description 1027 "A choice amongst certificate signing request formats. 1029 Additional formats MAY be augmented into this 'choice' 1030 statement by future efforts."; 1031 case p10-csr { 1032 leaf p10-csr { 1033 type ct:csr; 1034 description 1035 "A CertificationRequest structure, per RFC 2986."; 1036 reference 1037 "RFC 2986: PKCS #10: Certification 1038 Request Syntax Specification"; 1039 } 1040 } 1041 case cmc-csr { 1042 leaf cmc-csr { 1043 type binary; 1044 description 1045 "A constrained version of the 'Full PKI Request' 1046 message defined in RFC 5272, encoded using ASN.1 1047 distinguished encoding rules (DER), as specified 1048 in ITU-T X.690. 1050 For asymmetric key-based origin authentication of 1051 a CSR based on the IDevID's private key for the 1052 associated IDevID's public key, the PKIData 1053 contains one reqSequence element and no cmsSequence 1054 or otherMsgSequence elements. The reqSequence is 1055 the TaggedRequest and it is the tcr CHOICE. The 1056 tcr is the TaggedCertificationRequest and it a 1057 bodyPartId and the certificateRequest elements. 1058 The certificateRequest is signed with the IDevID's 1059 private key. The IDevID certificate and optionally 1060 its certificate chain is included in the SignedData 1061 certificates that encapsulates the PKIData. 1063 For asymmetric key-based origin authentication 1064 based on the IDevID's private key that signs the 1065 encapsulated CSR signed by the LDevID's private key, 1066 the PKIData contains one cmsSequence element and no 1067 otherMsgSequence element. The cmsSequence is the 1068 TaggedContentInfo and it includes a bodyPartID 1069 element and a contentInfo. The contentInfo is 1070 a SignedData encapsulating a PKIData with one 1071 reqSequence element and no cmsSequence or 1072 otherMsgSequence elements. The reqSequence is 1073 the TaggedRequest and it is the tcr CHOICE. The 1074 tcr is the TaggedCertificationRequest and it a 1075 bodyPartId and the certificateRequest elements. 1076 The certificateRequest is signed with the LDevID's 1077 private key. The IDevID certificate and optionally 1078 its certificate chain is included in the SignedData 1079 certificates that encapsulates the PKIData. 1081 For shared secret-based origin authentication of a 1082 CSR signed by the LDevID's private key, the PKIData 1083 contains one cmsSequence element and no reqSequence 1084 or otherMsgSequence elements. The cmsSequence is 1085 the TaggedContentInfo and it includes a bodyPartID 1086 element and a contentInfo. The contentInfo is an 1087 AuthenticatedData encapsulating a PKIData with one 1088 reqSequence element and no cmsSequences or 1089 otherMsgSequence elements. The reqSequence is the 1090 TaggedRequest and it is the tcr CHOICE. The tcr is 1091 the TaggedCertificationRequest and it a bodyPartId 1092 and the certificateRequest elements. The 1093 certificateRequest is signed with the LDevID's 1094 private key. The IDevID certificate and optionally 1095 its certificate chain is included in the SignedData 1096 certificates that encapsulates the PKIData."; 1097 reference 1098 "RFC 5272: Certificate Management over CMS (CMC) 1099 ITU-T X.690: 1100 Information technology - ASN.1 encoding rules: 1101 Specification of Basic Encoding Rules (BER), 1102 Canonical Encoding Rules (CER) and Distinguished 1103 Encoding Rules (DER)."; 1104 } 1105 } 1106 case cmp-csr { 1107 leaf cmp-csr { 1108 type binary; 1109 description 1110 "A PKIMessage structure, as defined in RFC 4210, 1111 encoded using ASN.1 distinguished encoding rules 1112 (DER), as specified in ITU-T X.690. 1114 For asymmetric key-based origin authentication of 1115 a CSR based on the IDevID's private key for the 1116 associated IDevID's public key, PKIMessages 1117 contains one PKIMessage with the header and body 1118 elements, no protection element, and should contain 1119 the extraCerts element. The header element contains 1120 the pvno, sender, and recipient elements. The pvno 1121 contains cmp2000, and the sender contains the 1122 subject of the IDevID certificate. The body element 1123 contains a p10cr CHOICE of type CertificationRequet. 1124 It is signed with the IDevID's private key. The 1125 extraCerts element contains the IDevID certificate, 1126 optionally followed by its certificate chain 1127 excluding the trust anchor. 1129 For asymmetric key-based origin authentication 1130 based on the IDevID's private key that signs the 1131 encapsulated CSR signed by the LDevID's private 1132 key, PKIMessages contains one PKIMessage with the 1133 header, body, and protection elements, and should 1134 contain the extraCerts element. The header element 1135 contains the pvno, sender, recipient, protectionAlg, 1136 and optionally senderKID elements. The pvno contains 1137 cmp2000, the sender contains the subject of the 1138 IDevID certificate, the protectionAlg contains the 1139 AlgorithmIdentifier of the used signature algorithm, 1140 and the senderKID contains the subject key 1141 identifier of the IDevID certificate. The body 1142 element contains a p10cr CHOICE of type 1143 CertificationRequet. It is signed with the LDevID's 1144 private key. The protection element contains the 1145 digital signature generated with the IDevID's 1146 private key. The extraCerts element contains the 1147 IDevID certificate, optionally followed by its 1148 certificate chain excluding the trust anchor. 1150 For shared secret-based origin authentication of a 1151 CSR signed by the LDevID's private key, PKIMessages 1152 contains one PKIMessage with the header, body, and 1153 protection element, and no extraCerts element. The 1154 header element contains the pvno, sender, recipient, 1155 protectionAlg, and senderKID elements. The pvno 1156 contains cmp2000, the protectionAlg contains the 1157 AlgorithmIdentifier of the used MAC algorithm, and 1158 the senderKID contains a reference the recipient 1159 can use to identify the shared secret. The body 1160 element contains a p10cr CHOICE of type 1161 CertificationRequet. It is signed with the LDevID's 1162 private key. The protection element contains the 1163 MAC value generated with the shared secret."; 1164 reference 1165 "RFC 4210: 1166 Internet X.509 Public Key Infrastructure 1167 Certificate Management Protocol (CMP) 1168 ITU-T X.690: 1169 Information technology - ASN.1 encoding rules: 1170 Specification of Basic Encoding Rules (BER), 1171 Canonical Encoding Rules (CER) and Distinguished 1172 Encoding Rules (DER)."; 1173 } 1175 } 1176 } 1177 } 1179 } 1181 1183 4. Security Considerations 1185 This document builds on top of the solution presented in [RFC8572] 1186 and therefore all the Security Considerations discussed in RFC 8572 1187 apply here as well. 1189 4.1. SZTP-Client Considerations 1191 4.1.1. Ensuring the Integrity of Asymmetric Private Keys 1193 The private key the SZTP-client uses for the dynamically-generated 1194 identity certificate MUST be protected from inadvertent disclosure in 1195 order to prevent identity fraud. 1197 The security of this private key is essential in order to ensure the 1198 associated identity certificate can be used as a root of trust. 1200 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1201 security module), such as a TPM (trusted platform module), to 1202 generate and forever contain the private key within the security 1203 perimeter of the HSM. In such cases, the private key, and its 1204 associated certificates, MAY have long validity periods. 1206 In cases where the SZTP-client does not possess an HSM, or otherwise 1207 is unable to use an HSM for the private key, it is RECOMMENDED to 1208 regenerate the private key (and associated identity certificates) 1209 periodically. Details for how to generate a new private key and 1210 associate a new identity certificate are outside the scope of this 1211 document. 1213 4.1.2. Reuse of a Manufacturer-generated Private Key 1215 It is RECOMMENDED that a new private key is generated for each CSR 1216 described in this document. 1218 This private key SHOULD be protected as well as the built-in private 1219 key associated with the SZTP-client's initial device identity 1220 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1222 In cases where it is not possible to generate a new private key that 1223 is protected as well as the built-in private key, it is RECOMMENDED 1224 to reuse the built-in private key rather than generate a new private 1225 key that is not as well protected. 1227 4.1.3. Replay Attack Protection 1229 This RFC enables an SZTP-client to announce an ability to generate a 1230 new key to use for its CSR. 1232 When the SZTP-server responds with a request for the SZTP-client to 1233 generate a new key, it is essential that the SZTP-client actually 1234 generates a new key. 1236 Generating a new key each time enables the random bytes used to 1237 create the key to also serve the dual-purpose of acting like a 1238 "nonce" used in other mechanisms to detect replay attacks. 1240 When a fresh public/private key pair is generated for the request, 1241 confirmation to the SZTP-client that the response has not been 1242 replayed is enabled by the SZTP-client's fresh public key appearing 1243 in the signed certificate provided by the SZTP-server. 1245 When a public/private key pair associated with the manufacturer- 1246 generated identity certificate (e.g., IDevID) is used for the 1247 request, there may not be confirmation to the SZTP-client that the 1248 response has not been replayed; however, the worst case result is a 1249 lost certificate that is associated to the private key known only to 1250 the SZTP-client. 1252 4.1.4. Connecting to an Untrusted Bootstrap Server 1254 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1255 by blindly authenticating the SZTP-server's TLS end-entity 1256 certificate. 1258 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1259 client MUST assert that the bootstrapping data returned is signed, if 1260 the SZTP-client is to trust it. 1262 However, the HTTP error message used in this document cannot be 1263 signed data, as described in RFC 8572. 1265 Therefore, the solution presented in this document cannot be used 1266 when the SZTP-client connects to an untrusted SZTP-server. 1268 Consistent with the recommendation presented in Section 9.6 of 1269 [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input 1270 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1271 instead the "signed-data-preferred" input parameter, as discussed in 1272 Appendix B of [RFC8572]. 1274 4.1.5. Selecting the Best Origin Authentication Mechanism 1276 A The CSR's origin SHOULD be verified before a certificate is issued. 1278 When generating a new key, it is important that the SZTP-client be 1279 able to provide additional proof that it was the entity that 1280 generated the key. 1282 The CMP and CMC certificate request formats defined in this document 1283 support origin authentication. A raw PKCS#10 does not support origin 1284 authentication. 1286 The CMP and CMC request formats support origin authentication using 1287 both PKI and shared secret. 1289 Typically, only one possible origin authentication mechanism can 1290 possibly be used but, in the case that the SZTP-client authenticates 1291 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1292 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1293 SZTP-client may need to choose between the two options. 1295 In the case that the SZTP-client must choose between an asymmetric 1296 key option versus a shared secret for origin authentication, it is 1297 RECOMMENDED that the SZTP-client choose using the asymmetric key. 1299 4.1.6. Clearing the Private Key and Associated Certificate 1301 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1302 the deployment-generated identity certificate (e.g., LDevID) and the 1303 associated private key (assuming a new private key was generated for 1304 the purpose), are considered user data and SHOULD be cleared whenever 1305 the SZTP-client is reset to its factory default state, such as by the 1306 "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. 1308 4.2. SZTP-Server Considerations 1310 4.2.1. Verifying Proof of Possession 1312 When the bootstrapping device's manufacturer-generated private key 1313 (e.g., the IDevID key) is reused for the CSR, proof-of-possession is 1314 verified by ensuring the CSR was signed by that key. 1316 When a new asymmetric key is used, proof-of-possession may be 1317 verified, with the CMP or CMC formats, by ensuring the parent ASN.1 1318 structure containing the CSR is signed by the manufacturer-generated 1319 key. 1321 4.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server 1323 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1324 by blindly authenticating the SZTP-server's TLS end-entity 1325 certificate. 1327 As is recommended in Section 4.1.4 in this document, in such cases, 1328 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1330 The reciprocal of this statement is that SZTP-servers, wanting to 1331 support SZTP-clients that don't trust them, SHOULD support the 1332 "signed-data-preferred" input parameter, as discussed in Appendix B 1333 of [RFC8572]. 1335 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module 1337 The recommended format for documenting the Security Considerations 1338 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1339 this module only augments two input parameters into the "get- 1340 bootstrapping-data" RPC in [RFC8572], and therefore only needs to 1341 point to the relevant Security Considerations sections in that RFC. 1343 * Security considerations for the "get-bootstrapping-data" RPC are 1344 described in Section 9.16 of [RFC8572]. 1346 * Security considerations for the "input" parameters passed inside 1347 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1348 [RFC8572]. 1350 4.4. Security Considerations for the "ietf-ztp-types" YANG Module 1352 The recommended format for documenting the Security Considerations 1353 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1354 this module does not define any protocol-accessible nodes (it only 1355 defines "identity" and "grouping" statements) and therefore there are 1356 no Security considerations to report. 1358 5. IANA Considerations 1359 5.1. The "IETF XML" Registry 1361 This document registers two URIs in the "ns" subregistry of the IETF 1362 XML Registry [RFC3688] maintained at 1363 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1364 Following the format in [RFC3688], the following registrations are 1365 requested: 1367 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1368 Registrant Contact: The NETCONF WG of the IETF. 1369 XML: N/A, the requested URI is an XML namespace. 1371 URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1372 Registrant Contact: The NETCONF WG of the IETF. 1373 XML: N/A, the requested URI is an XML namespace. 1375 5.2. The "YANG Module Names" Registry 1377 This document registers two YANG modules in the YANG Module Names 1378 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1379 yang-parameters/yang-parameters.xhtml. Following the format defined 1380 in [RFC6020], the below registrations are requested: 1382 name: ietf-sztp-csr 1383 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1384 prefix: sztp-csr 1385 reference: RFC XXXX 1387 name: ietf-ztp-types 1388 namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1389 prefix: ztp-types 1390 reference: RFC XXXX 1392 6. References 1394 6.1. Normative References 1396 [I-D.ietf-netconf-crypto-types] 1397 Watsen, K., "YANG Data Types and Groupings for 1398 Cryptography", Work in Progress, Internet-Draft, draft- 1399 ietf-netconf-crypto-types-20, 18 May 2021, 1400 . 1403 [ITU.X690.2015] 1404 International Telecommunication Union, "Information 1405 Technology - ASN.1 encoding rules: Specification of Basic 1406 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1407 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1408 X.690, ISO/IEC 8825-1, August 2015, 1409 . 1411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1412 Requirement Levels", BCP 14, RFC 2119, 1413 DOI 10.17487/RFC2119, March 1997, 1414 . 1416 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1417 Request Syntax Specification Version 1.7", RFC 2986, 1418 DOI 10.17487/RFC2986, November 2000, 1419 . 1421 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1422 DOI 10.17487/RFC3688, January 2004, 1423 . 1425 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1426 "Internet X.509 Public Key Infrastructure Certificate 1427 Management Protocol (CMP)", RFC 4210, 1428 DOI 10.17487/RFC4210, September 2005, 1429 . 1431 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1432 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1433 . 1435 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1436 the Network Configuration Protocol (NETCONF)", RFC 6020, 1437 DOI 10.17487/RFC6020, October 2010, 1438 . 1440 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1441 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1442 . 1444 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1445 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1446 . 1448 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1449 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1450 May 2017, . 1452 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1453 Touch Provisioning (SZTP)", RFC 8572, 1454 DOI 10.17487/RFC8572, April 2019, 1455 . 1457 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 1458 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1459 June 2020, . 1461 6.2. Informative References 1463 [I-D.ietf-netconf-keystore] 1464 Watsen, K., "A YANG Data Model for a Keystore", Work in 1465 Progress, Internet-Draft, draft-ietf-netconf-keystore-22, 1466 18 May 2021, . 1469 [I-D.ietf-netconf-trust-anchors] 1470 Watsen, K., "A YANG Data Model for a Truststore", Work in 1471 Progress, Internet-Draft, draft-ietf-netconf-trust- 1472 anchors-15, 18 May 2021, 1473 . 1476 [I-D.ietf-netmod-factory-default] 1477 Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1478 Factory Default Settings", Work in Progress, Internet- 1479 Draft, draft-ietf-netmod-factory-default-15, 25 April 1480 2020, . 1483 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1484 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1485 . 1487 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1488 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1489 DOI 10.17487/RFC8407, October 2018, 1490 . 1492 [Std-802.1AR-2018] 1493 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1494 metropolitan area networks - Secure Device Identity", 14 1495 June 2018, . 1498 Acknowledgements 1500 The authors would like to thank for following for lively discussions 1501 on list and in the halls (ordered by first name): David von Oheimb, 1502 Hendrik Brockhaus, Guy Fedorkow, Joe Clarke, Rich Salz, Rob Wilton, 1503 and Qin Wu. 1505 Contributors 1507 Special thanks goes to David von Oheimb and Hendrik Brockhaus for 1508 helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. 1510 Authors' Addresses 1512 Kent Watsen 1513 Watsen Networks 1515 Email: kent+ietf@watsen.net 1517 Russ Housley 1518 Vigil Security, LLC 1520 Email: housley@vigilsec.com 1522 Sean Turner 1523 sn3rd 1525 Email: sean@sn3rd.com