idnits 2.17.00 (12 Aug 2021) /tmp/idnits13481/draft-ietf-netconf-sztp-csr-06.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 (15 August 2021) is 278 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: 16 February 2022 S. Turner 7 sn3rd 8 15 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-06 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-15" --> 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 16 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. Conveying Proof of Possession to a CA . . . . . . . . 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 csr-parameters? 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 csr-parameters? 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 "csr-parameters": "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 The SZTP-server responds with "onboarding-information" (encoded 427 inside the "conveyed-information" node) containing a signed identity 428 certificate for the CSR provided by the SZTP-client: 430 RESPONSE 432 HTTP/1.1 200 OK 433 Date: Sat, 31 Oct 2015 17:02:40 GMT 434 Server: example-server 435 Content-Type: application/yang.data+json 437 { 438 "ietf-sztp-bootstrap-server:output" : { 439 "reporting-level": "verbose", 440 "conveyed-information": "BASE64VALUE=" 441 } 442 } 444 How the signed certificate is conveyed inside the onboarding 445 information is outside the scope of this document. Some 446 implementations may choose to convey it inside a script (e.g., SZTP's 447 "pre-configuration-script"), while other implementations may choose 448 to convey it inside the SZTP "configuration" node. SZTP onboarding 449 information is described in Section 2.2 of [RFC8572]. 451 Following are two examples of conveying the signed certificate inside 452 the "configuration" node. Both examples assume that the SZTP-client 453 understands the "ietf-keystore" module defined in 454 [I-D.ietf-netconf-keystore]. 456 This first example illustrates the case where the signed certificate 457 is for the same asymmetric key used by the SZTP-client's 458 manufacturer-generated identity certificate (e.g., an IDevID, from 459 [Std-802.1AR-2018]). As such, the configuration needs to associate 460 the newly signed certificate with the existing asymmetric key: 462 =============== NOTE: '\' line wrapping per RFC 8792 ================ 464 { 465 "ietf-keystore:keystore": { 466 "asymmetric-keys": { 467 "asymmetric-key": [ 468 { 469 "name": "Manufacturer-Generated Hidden Key", 470 "public-key-format": "ietf-crypto-types:subject-public-key\ 471 -info-format", 472 "public-key": "BASE64VALUE=", 473 "hidden-private-key": [null], 474 "certificates": { 475 "certificate": [ 476 { 477 "name": "Manufacturer-Generated IDevID Cert", 478 "cert-data": "BASE64VALUE=" 479 }, 480 { 481 "name": "Newly-Generated LDevID Cert", 482 "cert-data": "BASE64VALUE=" 483 } 484 ] 485 } 486 } 487 ] 488 } 489 } 490 } 492 This second example illustrates the case where the signed certificate 493 is for a newly generated asymmetric key. As such, the configuration 494 needs to associate the newly signed certificate with the newly 495 generated asymmetric key: 497 =============== NOTE: '\' line wrapping per RFC 8792 ================ 499 { 500 "ietf-keystore:keystore": { 501 "asymmetric-keys": { 502 "asymmetric-key": [ 503 { 504 "name": "Manufacturer-Generated Hidden Key", 505 "public-key-format": "ietf-crypto-types:subject-public-key\ 506 -info-format", 507 "public-key": "BASE64VALUE=", 508 "hidden-private-key": [null], 509 "certificates": { 510 "certificate": [ 511 { 512 "name": "Manufacturer-Generated IDevID Cert", 513 "cert-data": "BASE64VALUE=" 514 } 515 ] 516 } 517 }, 518 { 519 "name": "Newly-Generated Hidden Key", 520 "public-key-format": "ietf-crypto-types:subject-public-key\ 521 -info-format", 522 "public-key": "BASE64VALUE=", 523 "hidden-private-key": [null], 524 "certificates": { 525 "certificate": [ 526 { 527 "name": "Newly-Generated LDevID Cert", 528 "cert-data": "BASE64VALUE=" 529 } 530 ] 531 } 532 } 533 ] 534 } 535 } 536 } 538 In addition to configuring the signed certificate, it is often 539 necessary to also configure the Issuer's signing certificate so that 540 the device (i.e., STZP-client) can authenticate certificates 541 presented by peer devices signed by the same issuer as its own. 542 While outside the scope of this document, one way to do this would be 543 to use the "ietf-truststore" module defined in 544 [I-D.ietf-netconf-trust-anchors]. 546 2.3. YANG Module 548 This module augments an RPC defined in [RFC8572]. The module uses a 549 data types and groupings defined in [RFC8572], [RFC8791], and 550 [I-D.ietf-netconf-crypto-types]. The module has additional normative 551 references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015], 552 and an informative reference to [Std-802.1AR-2018]. 554 file "ietf-sztp-csr@2021-08-15.yang" 556 module ietf-sztp-csr { 557 yang-version 1.1; 558 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 559 prefix sztp-csr; 561 import ietf-sztp-bootstrap-server { 562 prefix sztp-svr; 563 reference 564 "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 565 } 567 import ietf-yang-structure-ext { 568 prefix sx; 569 reference 570 "RFC 8791: YANG Data Structure Extensions"; 571 } 573 import ietf-ztp-types { 574 prefix zt; 575 reference 576 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 577 in a Secure Zero Touch Provisioning (SZTP) 578 Bootstrapping Request"; 579 } 581 organization 582 "IETF NETCONF (Network Configuration) Working Group"; 584 contact 585 "WG Web: http://tools.ietf.org/wg/netconf 586 WG List: 587 Authors: Kent Watsen 588 Russ Housley 589 Sean Turner "; 591 description 592 "This module augments the 'get-bootstrapping-data' RPC, 593 defined in the 'ietf-sztp-bootstrap-server' module from 594 SZTP (RFC 8572), enabling the SZTP-client to obtain a 595 signed identity certificate (e.g., an LDevID from IEEE 596 802.1AR) as part of the SZTP onboarding information 597 response. 599 Copyright (c) 2021 IETF Trust and the persons identified 600 as authors of the code. All rights reserved. 602 Redistribution and use in source and binary forms, with 603 or without modification, is permitted pursuant to, and 604 subject to the license terms contained in, the Simplified 605 BSD License set forth in Section 4.c of the IETF Trust's 606 Legal Provisions Relating to IETF Documents 607 (https://trustee.ietf.org/license-info). 609 This version of this YANG module is part of RFC XXXX 610 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 611 itself for full legal notices. 613 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 614 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 615 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 616 document are to be interpreted as described in BCP 14 617 (RFC 2119) (RFC 8174) when, and only when, they appear 618 in all capitals, as shown here."; 620 revision 2021-08-15 { 621 description 622 "Initial version"; 623 reference 624 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 625 in a Secure Zero Touch Provisioning (SZTP) 626 Bootstrapping Request"; 627 } 629 // Protocol-accessible nodes 631 augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { 632 description 633 "This augmentation adds the 'csr-support' and 'csr' nodes to 634 the SZTP (RFC 8572) 'get-bootstrapping-data' request message, 635 enabling the SZTP-client to obtain an identity certificate 636 (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding 637 information response provided by the SZTP-server. 639 The 'csr-support' node enables the SZTP-client to indicate 640 that it supports generating certificate signing requests 641 (CSRs), and to provide details around the CSRs it is able 642 to generate. 644 The 'csr' node enables the SZTP-client to relay a CSR to 645 the SZTP-server."; 646 reference 647 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 648 area networks - Secure Device Identity 649 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 650 choice msg-type { 651 description 652 "Messages are mutually exclusive."; 653 case csr-support { 654 description 655 "Indicates how the SZTP-client supports generating CSRs. 657 If present and a SZTP-server wishes to request the 658 SZTP-client generate a CSR, the SZTP-server MUST 659 respond with HTTP code 400 Bad Request with an 660 'ietf-restconf:errors' message having the 'error-tag' 661 value 'missing-attribute' and the 'error-info' node 662 containing the 'csr-request' structure described 663 in this module."; 664 uses zt:csr-support-grouping; 665 } 666 case csr { 667 description 668 "Provides the CSR generated by the SZTP-client. 670 When present, the SZTP-server SHOULD respond with 671 an SZTP onboarding information message containing 672 a signed certificate for the conveyed CSR. The 673 SZTP-server MAY alternatively respond with another 674 HTTP error containing another 'csr-request', in 675 which case the SZTP-client MUST invalidate the 676 previously generated CSR."; 677 uses zt:csr-grouping; 678 } 679 } 680 } 682 sx:structure csr-request { 683 description 684 "A YANG data structure, per RFC 8791, that specifies 685 details for the CSR that the ZTP-client is to generate."; 686 reference 687 "RFC 8791: YANG Data Structure Extensions"; 688 uses zt:csr-request-grouping; 689 } 691 } 693 695 3. The "ietf-ztp-types" Module 697 This section defines a YANG 1.1 [RFC7950] module that defines three 698 YANG groupings, one each for messages sent between a ZTP-client and 699 ZTP-server. This module is defines independently of the "ietf-sztp- 700 csr" module so that it's groupings may be used by bootstrapping 701 protocols other than SZTP [RFC8572]. 703 3.1. Data Model Overview 705 The following tree diagram [RFC8340] illustrates the three groupings 706 defined in the "ietf-ztp-types" module. 708 module: ietf-ztp-types 710 grouping csr-support-grouping 711 +-- csr-support 712 +-- key-generation! 713 | +-- supported-algorithms 714 | +-- algorithm-identifier* binary 715 +-- csr-generation 716 +-- supported-formats 717 +-- format-identifier* identityref 718 grouping csr-request-grouping 719 +-- key-generation! 720 | +-- selected-algorithm 721 | +-- algorithm-identifier binary 722 +-- csr-generation 723 | +-- selected-format 724 | +-- format-identifier identityref 725 +-- csr-parameters? ct:csr-info 726 grouping csr-grouping 727 +-- (csr-type) 728 +--:(p10-csr) 729 | +-- p10-csr? ct:csr 730 +--:(cmc-csr) 731 | +-- cmc-csr? binary 732 +--:(cmp-csr) 733 +-- cmp-csr? binary 735 3.2. YANG Module 737 This module uses a data types and groupings [RFC8791] and 738 [I-D.ietf-netconf-crypto-types]. The module has additional normative 739 references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], 740 and an informative reference to [Std-802.1AR-2018]. 742 file "ietf-ztp-types@2021-08-15.yang" 744 module ietf-ztp-types { 745 yang-version 1.1; 746 namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; 747 prefix zt; 749 import ietf-crypto-types { 750 prefix ct; 751 reference 752 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 753 } 755 organization 756 "IETF NETCONF (Network Configuration) Working Group"; 758 contact 759 "WG Web: http://tools.ietf.org/wg/netconf 760 WG List: 761 Authors: Kent Watsen 762 Russ Housley 763 Sean Turner "; 765 description 766 "This module defines three groupings that enable 767 bootstrapping devices to 1) indicate if and how they 768 support generating CSRs, 2) obtain a request to 769 generate a CSR, and 3) communicate the requested CSR. 771 The terms 'IDevID' and 'LDevID' are used herein to 772 mean 'initial device identifier' and 'local device 773 identifer'. These terms are defined consistent with 774 the IEEE 802.1AR specification, though there is no 775 requirement that a ZTP-client's identity certificate 776 conform to IEEE 802.1AR. 778 Copyright (c) 2021 IETF Trust and the persons identified 779 as authors of the code. All rights reserved. 781 Redistribution and use in source and binary forms, with 782 or without modification, is permitted pursuant to, and 783 subject to the license terms contained in, the Simplified 784 BSD License set forth in Section 4.c of the IETF Trust's 785 Legal Provisions Relating to IETF Documents 786 (https://trustee.ietf.org/license-info). 788 This version of this YANG module is part of RFC XXXX 789 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 790 itself for full legal notices. 792 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 793 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 794 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 795 document are to be interpreted as described in BCP 14 796 (RFC 2119) (RFC 8174) when, and only when, they appear 797 in all capitals, as shown here."; 799 revision 2021-08-15 { 800 description 801 "Initial version"; 802 reference 803 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 804 in a Secure Zero Touch Provisioning (SZTP) 805 Bootstrapping Request"; 806 } 808 identity certificate-request-format { 809 description 810 "A base identity for the request formats supported 811 by the ZTP-client. 813 Additional derived identities MAY be defined by 814 future efforts."; 815 } 817 identity p10-csr { 818 base certificate-request-format; 819 description 820 "Indicates that the ZTP-client supports generating 821 requests using the 'CertificationRequest' structure 822 defined in RFC 2986."; 823 reference 824 "RFC 2986: PKCS #10: Certification Request Syntax 825 Specification Version 1.7"; 826 } 828 identity cmp-csr { 829 base certificate-request-format; 830 description 831 "Indicates that the ZTP-client supports generating 832 requests using a constrained version of the PKIMessage 833 containing a p10cr structure defined in RFC 4210."; 834 reference 835 "RFC 4210: Internet X.509 Public Key Infrastructure 836 Certificate Management Protocol (CMP)"; 837 } 839 identity cmc-csr { 840 base certificate-request-format; 841 description 842 "Indicates that the ZTP-client supports generating 843 requests using a constrained version of the 'Full 844 PKI Request' structure defined in RFC 5272."; 845 reference 846 "RFC 5272: Certificate Management over CMS (CMC)"; 847 } 849 // Protocol-accessible nodes 851 grouping csr-support-grouping { 852 description 853 "A grouping enabling use by other efforts."; 854 container csr-support { 855 description 856 "Enables a ZTP-client to indicate that it supports 857 generating certificate signing requests (CSRs) and 858 provides details about the CSRs it is able to 859 generate."; 860 container key-generation { 861 presence 862 "Indicates that the ZTP-client is capable of 863 generating a new asymmetric key pair. 865 If this node is not present, the ZTP-server MAY 866 request a CSR using the asymmetric key associated 867 with the device's existing identity certificate 868 (e.g., an IDevID from IEEE 802.1AR)."; 869 description 870 "Specifies details for the ZTP-client's ability to 871 generate a new asymmetric key pair."; 872 container supported-algorithms { 873 description 874 "A list of public key algorithms supported by the 875 ZTP-client for generating a new asymmetric key."; 876 leaf-list algorithm-identifier { 877 type binary; 878 min-elements 1; 879 description 880 "An AlgorithmIdentifier, as defined in RFC 2986, 881 encoded using ASN.1 distinguished encoding rules 882 (DER), as specified in ITU-T X.690."; 883 reference 884 "RFC 2986: PKCS #10: Certification Request Syntax 885 Specification Version 1.7 886 ITU-T X.690: 887 Information technology - ASN.1 encoding rules: 888 Specification of Basic Encoding Rules (BER), 889 Canonical Encoding Rules (CER) and Distinguished 890 Encoding Rules (DER)."; 891 } 892 } 893 } 894 container csr-generation { 895 description 896 "Specifies details for the ZTP-client's ability to 897 generate a certificate signing requests."; 898 container supported-formats { 899 description 900 "A list of certificate request formats supported 901 by the ZTP-client for generating a new key."; 902 leaf-list format-identifier { 903 type identityref { 904 base zt:certificate-request-format; 905 } 906 min-elements 1; 907 description 908 "A certificate request format supported by the 909 ZTP-client."; 910 } 911 } 912 } 913 } 914 } 916 grouping csr-request-grouping { 917 description 918 "A grouping enabling use by other efforts."; 919 container key-generation { 920 presence 921 "Provided by a ZTP-server to indicate that it wishes 922 the ZTP-client to generate a new asymmetric key. 924 This statement is present so the mandatory descendant 925 nodes do not imply that this node must be configured."; 926 description 927 "The key generation parameters selected by the ZTP-server. 929 This leaf MUST only appear if the ZTP-client's 930 'csr-support' included the 'key-generation' node."; 931 container selected-algorithm { 932 description 933 "The key algorithm selected by the ZTP-server. The 934 algorithm MUST be one of the algorithms specified by 935 the 'supported-algorithms' node in the ZTP-client's 936 message containing the 'csr-support' structure."; 937 leaf algorithm-identifier { 938 type binary; 939 mandatory true; 940 description 941 "An AlgorithmIdentifier, as defined in RFC 2986, 942 encoded using ASN.1 distinguished encoding rules 943 (DER), as specified in ITU-T X.690."; 944 reference 945 "RFC 2986: PKCS #10: Certification Request Syntax 946 Specification Version 1.7 947 ITU-T X.690: 948 Information technology - ASN.1 encoding rules: 949 Specification of Basic Encoding Rules (BER), 950 Canonical Encoding Rules (CER) and Distinguished 951 Encoding Rules (DER)."; 952 } 953 } 954 } 955 container csr-generation { 956 description 957 "Specifies details for the CSR that the ZTP-client 958 is to generate."; 959 container selected-format { 960 description 961 "The CSR format selected by the ZTP-server. The 962 format MUST be one of the formats specified by 963 the 'supported-formats' node in the ZTP-client's 964 request message."; 965 leaf format-identifier { 966 type identityref { 967 base zt:certificate-request-format; 968 } 969 mandatory true; 970 description 971 "A certificate request format to be used by the 972 ZTP-client."; 973 } 974 } 976 } 977 leaf csr-parameters { 978 type ct:csr-info; 979 description 980 "A CertificationRequestInfo structure, as defined in 981 RFC 2986, and modeled via a 'typedef' statement by 982 RFC AAAA. 984 Enables the ZTP-server to provide a fully-populated 985 CertificationRequestInfo structure that the ZTP-client 986 only needs to sign in order to generate the complete 987 'CertificationRequest' structure to send to ZTP-server 988 in its next 'get-bootstrapping-data' request message. 990 When provided, the ZTP-client SHOULD use this 991 structure to generate its CSR; failure to do so MAY 992 result in a 400 Bad Request response containing 993 another 'csr-request' structure. 995 When not provided, the ZTP-client SHOULD generate a 996 CSR using the same structure defined in its existing 997 identity certificate (e.g., IDevID). 999 It is an error if the 'AlgorithmIdentifier' field 1000 contained inside the 'SubjectPublicKeyInfo' field 1001 does not match the algorithm identified by the 1002 'selected-algorithm' node."; 1003 reference 1004 "RFC 2986: 1005 PKCS #10: Certification Request Syntax Specification 1006 RFC AAAA: 1007 YANG Data Types and Groupings for Cryptography"; 1008 } 1009 } 1011 grouping csr-grouping { 1012 description 1013 "Enables a ZTP-client to convey a certificate signing 1014 request, using the encoding format selected by a 1015 ZTP-server's 'csr-request' response to the ZTP-client's 1016 previously sent 'get-bootstrapping-data' request 1017 containing the 'csr-support' node."; 1018 choice csr-type { 1019 mandatory true; 1020 description 1021 "A choice amongst certificate signing request formats. 1023 Additional formats MAY be augmented into this 'choice' 1024 statement by future efforts."; 1025 case p10-csr { 1026 leaf p10-csr { 1027 type ct:csr; 1028 description 1029 "A CertificationRequest structure, per RFC 2986."; 1030 reference 1031 "RFC 2986: PKCS #10: Certification 1032 Request Syntax Specification"; 1033 } 1034 } 1035 case cmc-csr { 1036 leaf cmc-csr { 1037 type binary; 1038 description 1039 "A constrained version of the 'Full PKI Request' 1040 message defined in RFC 5272, encoded using ASN.1 1041 distinguished encoding rules (DER), as specified 1042 in ITU-T X.690. 1044 For asymmetric key-based origin authentication of 1045 a CSR based on the IDevID's private key for the 1046 associated IDevID's public key, the PKIData 1047 contains one reqSequence element and no cmsSequence 1048 or otherMsgSequence elements. The reqSequence is 1049 the TaggedRequest and it is the tcr CHOICE. The 1050 tcr is the TaggedCertificationRequest and it a 1051 bodyPartId and the certificateRequest elements. 1052 The certificateRequest is signed with the IDevID's 1053 private key. The IDevID certificate and optionally 1054 its certificate chain is included in the SignedData 1055 certificates that encapsulates the PKIData. 1057 For asymmetric key-based origin authentication 1058 based on the IDevID's private key that signs the 1059 encapsulated CSR signed by the LDevID's private key, 1060 the PKIData contains one cmsSequence element and no 1061 otherMsgSequence element. The cmsSequence is the 1062 TaggedContentInfo and it includes a bodyPartID 1063 element and a contentInfo. The contentInfo is 1064 a SignedData encapsulating a PKIData with one 1065 reqSequence element and no cmsSequence or 1066 otherMsgSequence elements. The reqSequence is 1067 the TaggedRequest and it is the tcr CHOICE. The 1068 tcr is the TaggedCertificationRequest and it a 1069 bodyPartId and the certificateRequest elements. 1070 The certificateRequest is signed with the LDevID's 1071 private key. The IDevID certificate and optionally 1072 its certificate chain is included in the SignedData 1073 certificates that encapsulates the PKIData. 1075 For shared secret-based origin authentication of a 1076 CSR signed by the LDevID's private key, the PKIData 1077 contains one cmsSequence element and no reqSequence 1078 or otherMsgSequence elements. The cmsSequence is 1079 the TaggedContentInfo and it includes a bodyPartID 1080 element and a contentInfo. The contentInfo is an 1081 AuthenticatedData encapsulating a PKIData with one 1082 reqSequence element and no cmsSequences or 1083 otherMsgSequence elements. The reqSequence is the 1084 TaggedRequest and it is the tcr CHOICE. The tcr is 1085 the TaggedCertificationRequest and it a bodyPartId 1086 and the certificateRequest elements. The 1087 certificateRequest is signed with the LDevID's 1088 private key. The IDevID certificate and optionally 1089 its certificate chain is included in the SignedData 1090 certificates that encapsulates the PKIData."; 1091 reference 1092 "RFC 5272: Certificate Management over CMS (CMC) 1093 ITU-T X.690: 1094 Information technology - ASN.1 encoding rules: 1095 Specification of Basic Encoding Rules (BER), 1096 Canonical Encoding Rules (CER) and Distinguished 1097 Encoding Rules (DER)."; 1098 } 1099 } 1100 case cmp-csr { 1101 leaf cmp-csr { 1102 type binary; 1103 description 1104 "A PKIMessage structure, as defined in RFC 4210, 1105 encoded using ASN.1 distinguished encoding rules 1106 (DER), as specified in ITU-T X.690. 1108 For asymmetric key-based origin authentication of 1109 a CSR based on the IDevID's private key for the 1110 associated IDevID's public key, PKIMessages 1111 contains one PKIMessage with the header and body 1112 elements, no protection element, and should contain 1113 the extraCerts element. The header element contains 1114 the pvno, sender, and recipient elements. The pvno 1115 contains cmp2000, and the sender contains the 1116 subject of the IDevID certificate. The body element 1117 contains a p10cr CHOICE of type CertificationRequet. 1118 It is signed with the IDevID's private key. The 1119 extraCerts element contains the IDevID certificate, 1120 optionally followed by its certificate chain 1121 excluding the trust anchor. 1123 For asymmetric key-based origin authentication 1124 based on the IDevID's private key that signs the 1125 encapsulated CSR signed by the LDevID's private 1126 key, PKIMessages contains one PKIMessage with the 1127 header, body, and protection elements, and should 1128 contain the extraCerts element. The header element 1129 contains the pvno, sender, recipient, protectionAlg, 1130 and optionally senderKID elements. The pvno contains 1131 cmp2000, the sender contains the subject of the 1132 IDevID certificate, the protectionAlg contains the 1133 AlgorithmIdentifier of the used signature algorithm, 1134 and the senderKID contains the subject key 1135 identifier of the IDevID certificate. The body 1136 element contains a p10cr CHOICE of type 1137 CertificationRequet. It is signed with the LDevID's 1138 private key. The protection element contains the 1139 digital signature generated with the IDevID's 1140 private key. The extraCerts element contains the 1141 IDevID certificate, optionally followed by its 1142 certificate chain excluding the trust anchor. 1144 For shared secret-based origin authentication of a 1145 CSR signed by the LDevID's private key, PKIMessages 1146 contains one PKIMessage with the header, body, and 1147 protection element, and no extraCerts element. The 1148 header element contains the pvno, sender, recipient, 1149 protectionAlg, and senderKID elements. The pvno 1150 contains cmp2000, the protectionAlg contains the 1151 AlgorithmIdentifier of the used MAC algorithm, and 1152 the senderKID contains a reference the recipient 1153 can use to identify the shared secret. The body 1154 element contains a p10cr CHOICE of type 1155 CertificationRequet. It is signed with the LDevID's 1156 private key. The protection element contains the 1157 MAC value generated with the shared secret."; 1158 reference 1159 "RFC 4210: 1160 Internet X.509 Public Key Infrastructure 1161 Certificate Management Protocol (CMP) 1162 ITU-T X.690: 1163 Information technology - ASN.1 encoding rules: 1164 Specification of Basic Encoding Rules (BER), 1165 Canonical Encoding Rules (CER) and Distinguished 1166 Encoding Rules (DER)."; 1167 } 1169 } 1170 } 1171 } 1173 } 1175 1177 4. Security Considerations 1179 This document builds on top of the solution presented in [RFC8572] 1180 and therefore all the Security Considerations discussed in RFC 8572 1181 apply here as well. 1183 4.1. SZTP-Client Considerations 1185 4.1.1. Ensuring the Integrity of Asymmetric Private Keys 1187 The private key the SZTP-client uses for the dynamically-generated 1188 identity certificate MUST be protected from inadvertent disclosure in 1189 order to prevent identity fraud. 1191 The security of this private key is essential in order to ensure the 1192 associated identity certificate can be used as a root of trust. 1194 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1195 security module), such as a TPM (trusted platform module), to 1196 generate and forever contain the private key within the security 1197 perimeter of the HSM. In such cases, the private key, and its 1198 associated certificates, MAY have long validity periods. 1200 In cases where the SZTP-client does not possess an HSM, or otherwise 1201 is unable to use an HSM for the private key, it is RECOMMENDED to 1202 regenerate the private key (and associated identity certificates) 1203 periodically. Details for how to generate a new private key and 1204 associate a new identity certificate are outside the scope of this 1205 document. 1207 4.1.2. Reuse of a Manufacturer-generated Private Key 1209 It is RECOMMENDED that a new private key is generated for each CSR 1210 described in this document. 1212 This private key SHOULD be protected as well as the built-in private 1213 key associated with the SZTP-client's initial device identity 1214 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1216 In cases where it is not possible to generate a new private key that 1217 is protected as well as the built-in private key, it is RECOMMENDED 1218 to reuse the built-in private key rather than generate a new private 1219 key that is not as well protected. 1221 4.1.3. Replay Attack Protection 1223 This RFC enables an SZTP-client to announce an ability to generate a 1224 new key to use for its CSR. 1226 When the SZTP-server responds with a request for the SZTP-client to 1227 generate a new key, it is essential that the SZTP-client actually 1228 generates a new key. 1230 Generating a new key each time enables the random bytes used to 1231 create the key to also serve the dual-purpose of acting like a 1232 "nonce" used in other mechanisms to detect replay attacks. 1234 When a fresh public/private key pair is generated for the request, 1235 confirmation to the SZTP-client that the response has not been 1236 replayed is enabled by the SZTP-client's fresh public key appearing 1237 in the signed certificate provided by the SZTP-server. 1239 When a public/private key pair associated with the manufacturer- 1240 generated identity certificate (e.g., IDevID) is used for the 1241 request, there may not be confirmation to the SZTP-client that the 1242 response has not been replayed; however, the worst case result is a 1243 lost certificate that is associated to the private key known only to 1244 the SZTP-client. 1246 4.1.4. Connecting to an Untrusted Bootstrap Server 1248 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1249 by blindly authenticating the SZTP-server's TLS end-entity 1250 certificate. 1252 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1253 client MUST assert that the bootstrapping data returned is signed, if 1254 the SZTP-client is to trust it. 1256 However, the HTTP error message used in this document cannot be 1257 signed data, as described in RFC 8572. 1259 Therefore, the solution presented in this document cannot be used 1260 when the SZTP-client connects to an untrusted SZTP-server. 1262 Consistent with the recommendation presented in Section 9.6 of 1263 [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input 1264 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1265 instead the "signed-data-preferred" input parameter, as discussed in 1266 Appendix B of [RFC8572]. 1268 4.1.5. Selecting the Best Origin Authentication Mechanism 1270 When generating a new key, it is important that the client be able to 1271 provide additional proof to the CA that it was the entity that 1272 generated the key. 1274 All the certificate request formats defined in this document (e.g., 1275 CMC, CMP, etc.), not including a raw PKCS#10, support origin 1276 authentication. 1278 These formats support origin authentication using both PKI and shared 1279 secret. 1281 Typically, only one possible origin authentication mechanism can 1282 possibly be used but, in the case that the SZTP-client authenticates 1283 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1284 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1285 SZTP-client may need to choose between the two options. 1287 In the case that the SZTP-client must choose between the asymmetric 1288 key option versus a shared secret for origin authentication, it is 1289 RECOMMENDED that the SZTP-client choose using the asymmetric key 1290 option. 1292 4.1.6. Clearing the Private Key and Associated Certificate 1294 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1295 the deployment-generated identity certificate (e.g., LDevID) and the 1296 associated private key (assuming a new private key was generated for 1297 the purpose), are considered user data and SHOULD be cleared whenever 1298 the SZTP-client is reset to its factory default state, such as by the 1299 "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. 1301 4.2. SZTP-Server Considerations 1303 4.2.1. Conveying Proof of Possession to a CA 1305 When the bootstrapping device's manufacturer-generated private key 1306 (e.g., the IDevID key) is reused, a CA may validate that the CSR was 1307 signed by that key. 1309 Both the CMP and CMC formats entail the bootstrapping device signing 1310 the request once with its (e.g., LDevID) key and then again with its 1311 (e.g., IDevID) key, which enables a downstream CA to be assured that 1312 the bootstrapping device possesses the public key being signed. 1314 4.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server 1316 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1317 by blindly authenticating the SZTP-server's TLS end-entity 1318 certificate. 1320 As is recommended in Section 4.1.4 in this document, in such cases, 1321 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1323 The reciprocal of this statement is that SZTP-servers, wanting to 1324 support SZTP-clients that don't trust them, SHOULD support the 1325 "signed-data-preferred" input parameter, as discussed in Appendix B 1326 of [RFC8572]. 1328 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module 1330 The recommended format for documenting the Security Considerations 1331 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1332 this module only augments two input parameters into the "get- 1333 bootstrapping-data" RPC in [RFC8572], and therefore only needs to 1334 point to the relevant Security Considerations sections in that RFC. 1336 * Security considerations for the "get-bootstrapping-data" RPC are 1337 described in Section 9.16 of [RFC8572]. 1339 * Security considerations for the "input" parameters passed inside 1340 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1341 [RFC8572]. 1343 4.4. Security Considerations for the "ietf-ztp-types" YANG Module 1345 The recommended format for documenting the Security Considerations 1346 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1347 this module does not define any protocol-accessible nodes (it only 1348 defines "identity" and "grouping" statements) and therefore there are 1349 no Security considerations to report. 1351 5. IANA Considerations 1352 5.1. The "IETF XML" Registry 1354 This document registers two URIs in the "ns" subregistry of the IETF 1355 XML Registry [RFC3688] maintained at 1356 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1357 Following the format in [RFC3688], the following registrations are 1358 requested: 1360 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1361 Registrant Contact: The NETCONF WG of the IETF. 1362 XML: N/A, the requested URI is an XML namespace. 1364 URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1365 Registrant Contact: The NETCONF WG of the IETF. 1366 XML: N/A, the requested URI is an XML namespace. 1368 5.2. The "YANG Module Names" Registry 1370 This document registers two YANG modules in the YANG Module Names 1371 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1372 yang-parameters/yang-parameters.xhtml. Following the format defined 1373 in [RFC6020], the below registrations are requested: 1375 name: ietf-sztp-csr 1376 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1377 prefix: sztp-csr 1378 reference: RFC XXXX 1380 name: ietf-ztp-types 1381 namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1382 prefix: ztp-types 1383 reference: RFC XXXX 1385 6. References 1387 6.1. Normative References 1389 [I-D.ietf-netconf-crypto-types] 1390 Watsen, K., "YANG Data Types and Groupings for 1391 Cryptography", Work in Progress, Internet-Draft, draft- 1392 ietf-netconf-crypto-types-20, 18 May 2021, 1393 . 1396 [ITU.X690.2015] 1397 International Telecommunication Union, "Information 1398 Technology - ASN.1 encoding rules: Specification of Basic 1399 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1400 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1401 X.690, ISO/IEC 8825-1, August 2015, 1402 . 1404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1405 Requirement Levels", BCP 14, RFC 2119, 1406 DOI 10.17487/RFC2119, March 1997, 1407 . 1409 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1410 Request Syntax Specification Version 1.7", RFC 2986, 1411 DOI 10.17487/RFC2986, November 2000, 1412 . 1414 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1415 DOI 10.17487/RFC3688, January 2004, 1416 . 1418 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1419 "Internet X.509 Public Key Infrastructure Certificate 1420 Management Protocol (CMP)", RFC 4210, 1421 DOI 10.17487/RFC4210, September 2005, 1422 . 1424 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1425 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1426 . 1428 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1429 the Network Configuration Protocol (NETCONF)", RFC 6020, 1430 DOI 10.17487/RFC6020, October 2010, 1431 . 1433 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1434 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1435 . 1437 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1438 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1439 . 1441 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1442 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1443 May 2017, . 1445 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1446 Touch Provisioning (SZTP)", RFC 8572, 1447 DOI 10.17487/RFC8572, April 2019, 1448 . 1450 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 1451 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1452 June 2020, . 1454 6.2. Informative References 1456 [I-D.ietf-netconf-keystore] 1457 Watsen, K., "A YANG Data Model for a Keystore", Work in 1458 Progress, Internet-Draft, draft-ietf-netconf-keystore-22, 1459 18 May 2021, . 1462 [I-D.ietf-netconf-trust-anchors] 1463 Watsen, K., "A YANG Data Model for a Truststore", Work in 1464 Progress, Internet-Draft, draft-ietf-netconf-trust- 1465 anchors-15, 18 May 2021, 1466 . 1469 [I-D.ietf-netmod-factory-default] 1470 Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1471 Factory Default Settings", Work in Progress, Internet- 1472 Draft, draft-ietf-netmod-factory-default-15, 25 April 1473 2020, . 1476 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1477 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1478 . 1480 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1481 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1482 DOI 10.17487/RFC8407, October 2018, 1483 . 1485 [Std-802.1AR-2018] 1486 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1487 metropolitan area networks - Secure Device Identity", 14 1488 June 2018, . 1491 Acknowledgements 1493 The authors would like to thank for following for lively discussions 1494 on list and in the halls (ordered by first name): David von Oheimb, 1495 Hendrik Brockhaus, Guy Fedorkow, Joe Clarke, Rich Salz, Rob Wilton, 1496 and Qin Wu. 1498 Contributors 1500 Special thanks goes to David von Oheimb and Hendrik Brockhaus for 1501 helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. 1503 Authors' Addresses 1505 Kent Watsen 1506 Watsen Networks 1508 Email: kent+ietf@watsen.net 1510 Russ Housley 1511 Vigil Security, LLC 1513 Email: housley@vigilsec.com 1515 Sean Turner 1516 sn3rd 1518 Email: sean@sn3rd.com