idnits 2.17.1 draft-ietf-netconf-sztp-csr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 218 has weird spacing: '...ntifier bin...' == Line 221 has weird spacing: '...ntifier ide...' == Line 258 has weird spacing: '...rmation cms...' == Line 277 has weird spacing: '...ntifier bin...' == Line 280 has weird spacing: '...ntifier ide...' -- The document date (16 November 2020) is 1250 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 (-34) exists of draft-ietf-netconf-crypto-types-18 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-20 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-13 Summary: 1 error (**), 0 flaws (~~), 9 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: 20 May 2021 S. Turner 7 sn3rd 8 16 November 2020 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-ietf-netconf-sztp-csr-01 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 * "2020-11-16" --> 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 20 May 2021. 72 Copyright Notice 74 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . 3 91 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 92 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 93 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 4 94 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7 95 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 96 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23 97 3.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 23 98 3.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 23 99 3.1.2. Reuse of a Manufacturer-generated Private Key . . . . 23 100 3.1.3. Replay Attack Protection . . . . . . . . . . . . . . 23 101 3.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 24 102 3.1.5. Selecting the Best Origin Authentication Mechanism . 24 103 3.1.6. Clearing the Private Key and Associated 104 Certificate . . . . . . . . . . . . . . . . . . . . . 25 105 3.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 25 106 3.2.1. Conveying Proof of Possession to a CA . . . . . . . . 25 107 3.2.2. Supporting SZTP-Clients that don't trust the 108 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 25 109 3.2.3. YANG Module Considerations . . . . . . . . . . . . . 26 110 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 111 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 26 112 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 26 113 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 114 5.1. Normative References . . . . . . . . . . . . . . . . . . 26 115 5.2. Informative References . . . . . . . . . . . . . . . . . 27 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 118 1. Introduction 120 1.1. Overview 122 This draft extends the "get-bootstrapping-data" RPC defined in 123 [RFC8572] to include an optional certificate signing request (CSR) 124 [RFC2986], enabling a bootstrapping device to additionally obtain an 125 identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of 126 the "onboarding information" response provided in the RPC-reply. 128 1.2. Terminology 130 This document uses the following terms from [RFC8572]: 132 * Bootstrap Server 133 * Bootstrapping Data 134 * Conveyed Information 135 * Device 136 * Manufacturer 137 * Onboarding Information 138 * Signed Data 140 This document defines the following new terms: 142 SZTP-client The term "SZTP-client" refers to a "device" that is 143 using a "bootstrap server" as a source of "bootstrapping data". 145 SZTP-server The term "SZTP-server" is an alternative term for 146 "bootstrap server" that is symmetric with the "SZTP-client" term. 148 1.3. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2. The "ietf-sztp-csr" Module 158 This section defines a YANG 1.1 [RFC7950] module that augments the 159 "ietf-sztp-bootstrap-server" module defined in [RFC8572] and defines 160 a YANG "structure". 162 The augmentation adds two nodes ("csr-support" and "csr") to the 163 "input" parameter of the "get-bootstrapping-data" RPC defined in 164 [RFC8572]. 166 The YANG structure, "request-info", defines data returned in the 167 "error-info" node defined in Section 7.1 of [RFC8040]. 169 2.1. Data Model Overview 171 The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" 172 module. The diagram shows the definition of an augmentation adding 173 descendent nodes "csr-support" and "csr" and the definition of a 174 structure called "request-info". 176 In the order of their intended use: 178 * The "csr-support" node is used by the SZTP-client to signal to the 179 SZTP-server that it supports the ability the generate CSRs, per 180 this specification. The "csr-support" parameter carries details 181 regarding the SZTP-client's ability to generate CSRs. 183 * The "request-info" structure is used by the SZTP-server to signal 184 back to the SZTP-client its desire to sign a CSR. The "request- 185 info" structure additionally communicates details about the CSR 186 the SZTP-client is to generate. 188 * The "csr" node is used by the SZTP-client to communicate its CSR 189 to the SZTP-server. Not shown is how the SZTP-server communicates 190 the signed certificate to the SZTP-client; how to do this is 191 discussed later in this document. 193 =============== NOTE: '\' line wrapping per RFC 8792 ================ 195 module: ietf-sztp-csr 197 augment /ietf-sztp-bootstrap-server:get-bootstrapping-data/ietf-sz\ 198 tp-bootstrap-server:input: 199 +---- csr-support! 200 | +---- key-generation! 201 | | +---- supported-algorithms 202 | | +---- algorithm-identifier* binary 203 | +---- csr-generation 204 | +---- supported-formats 205 | +---- format-identifier* identityref 206 +---- csr! 207 +---- (request-type) 208 +--:(p10) 209 | +---- p10? ietf-crypto-types:csr 210 +--:(cmc) 211 | +---- cmc? binary 212 +--:(cmp) 213 +---- cmp? binary 215 structure: request-info 216 +-- key-generation! 217 | +-- selected-algorithm 218 | +-- algorithm-identifier binary 219 +-- csr-generation 220 | +-- selected-format 221 | +-- format-identifier identityref 222 +-- cert-req-info? ietf-crypto-types:csr-info 224 To further illustrate how the augmentation and structure defined by 225 the "ietf-sztp-csr" module are used, below are two additional tree 226 diagrams showing these nodes placed where they are used. 228 The following tree diagram [RFC8340] illustrates SZTP's "get- 229 bootstrapping-data" RPC with the augmentation in place. 231 module: ietf-sztp-bootstrap-server 233 rpcs: 234 +---x get-bootstrapping-data 235 +---w input 236 | +---w signed-data-preferred? empty 237 | +---w hw-model? string 238 | +---w os-name? string 239 | +---w os-version? string 240 | +---w nonce? binary 241 | +---w sztp-csr:csr-support! 242 | | +---w sztp-csr:key-generation! 243 | | | +---w sztp-csr:supported-algorithms 244 | | | +---w sztp-csr:algorithm-identifier* binary 245 | | +---w sztp-csr:csr-generation 246 | | +---w sztp-csr:supported-formats 247 | | +---w sztp-csr:format-identifier* identityref 248 | +---w sztp-csr:csr! 249 | +---w (sztp-csr:request-type) 250 | +--:(sztp-csr:p10) 251 | | +---w sztp-csr:p10? ct:csr 252 | +--:(sztp-csr:cmc) 253 | | +---w sztp-csr:cmc? binary 254 | +--:(sztp-csr:cmp) 255 | +---w sztp-csr:cmp? binary 256 +--ro output 257 +--ro reporting-level? enumeration {onboarding-server}? 258 +--ro conveyed-information cms 259 +--ro owner-certificate? cms 260 +--ro ownership-voucher? cms 262 The following tree diagram [RFC8340] illustrates RESTCONF's "errors" 263 RPC-reply message with the "request-info" structure in place. 265 module: ietf-restconf 266 +--ro errors 267 +--ro error* [] 268 +--ro error-type enumeration 269 +--ro error-tag string 270 +--ro error-app-tag? string 271 +--ro error-path? instance-identifier 272 +--ro error-message? string 273 +--ro error-info 274 +--ro request-info 275 +--ro key-generation! 276 | +--ro selected-algorithm 277 | +--ro algorithm-identifier binary 278 +--ro csr-generation 279 | +--ro selected-format 280 | +--ro format-identifier identityref 281 +--ro cert-req-info? ct:csr-info 283 2.2. Example Usage 285 | The examples below are encoded using JSON, but they could 286 | equally well be encoded using XML, as is supported by SZTP. 288 An SZTP-client implementing this specification would signal to the 289 bootstrap server its willingness to generate a CSR by including the 290 "csr-support" node in its "get-bootstrapping-data" RPC, as 291 illustrated below. 293 REQUEST 294 =============== NOTE: '\' line wrapping per RFC 8792 ================ 296 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 297 ng-data HTTP/1.1 298 HOST: example.com 299 Content-Type: application/yang.data+json 301 { 302 "ietf-sztp-bootstrap-server:input" : { 303 "hw-model": "model-x", 304 "os-name": "vendor-os", 305 "os-version": "17.3R2.1", 306 "nonce": "extralongbase64encodedvalue=", 307 "ietf-sztp-csr:csr-support": { 308 "key-generation": { 309 "supported-algorithms": { 310 "algorithm-identifier": [ 311 "base64encodedvalue1=", 312 "base64encodedvalue2=", 313 "base64encodedvalue3=" 314 ] 315 } 316 }, 317 "csr-generation": { 318 "supported-formats": { 319 "format-identifier": [ 320 "ietf-sztp-csr:p10", 321 "ietf-sztp-csr:cmc", 322 "ietf-sztp-csr:cmp" 323 ] 324 } 325 } 326 } 327 } 328 } 330 Assuming the SZTP-server wishes to prompt the SZTP-client to provide 331 a CSR, then it would respond with an HTTP 400 (Bad Request) error 332 code: 334 RESPONSE 335 HTTP/1.1 400 Bad Request 336 Date: Sat, 31 Oct 2015 17:02:40 GMT 337 Server: example-server 338 Content-Type: application/yang.data+json 340 { 341 "ietf-restconf:errors" : { 342 "error" : [ 343 { 344 "error-type": "application", 345 "error-tag": "missing-attribute", 346 "error-message": "Missing input parameter", 347 "error-info": { 348 "ietf-sztp-csr:request-info": { 349 "key-generation": { 350 "selected-algorithm": { 351 "algorithm-identifier": "base64EncodedValue==" 352 } 353 }, 354 "csr-generation": { 355 "selected-format": { 356 "format-identifier": "ietf-sztp-csr:cmc" 357 } 358 }, 359 "cert-req-info": "base64EncodedValue==" 360 } 361 } 362 } 363 ] 364 } 365 } 367 Upon being prompted to provide a CSR, the SZTP-client would POST 368 another "get-bootstrapping-data" request, but this time including the 369 "csr" node to convey its CSR to the SZTP-server: 371 REQUEST 372 =============== NOTE: '\' line wrapping per RFC 8792 ================ 374 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 375 ng-data HTTP/1.1 376 HOST: example.com 377 Content-Type: application/yang.data+json 379 { 380 "ietf-sztp-bootstrap-server:input" : { 381 "hw-model": "model-x", 382 "os-name": "vendor-os", 383 "os-version": "17.3R2.1", 384 "nonce": "extralongbase64encodedvalue=", 385 "ietf-sztp-csr:csr": { 386 "p10": "base64encodedvalue==" 387 } 388 } 389 } 391 The SZTP-server responds with "onboarding-information" (conveyed 392 encoded inside the "conveyed-information" node) containing a signed 393 identity certificate for the CSR provided by the SZTP-client: 395 RESPONSE 397 HTTP/1.1 200 OK 398 Date: Sat, 31 Oct 2015 17:02:40 GMT 399 Server: example-server 400 Content-Type: application/yang.data+json 402 { 403 "ietf-sztp-bootstrap-server:output" : { 404 "reporting-level": "verbose", 405 "conveyed-information": "base64encodedvalue==" 406 } 407 } 409 How the signed certificate is conveyed inside the onboarding 410 information is outside the scope of this document. Some 411 implementations may choose to convey it inside a script (e.g., SZTP's 412 "pre-configuration-script"), while other implementations convey it 413 inside the SZTP "configuration" node. 415 Following are two examples of conveying the signed certificate inside 416 the "configuration" node. Both examples assume that the SZTP-client 417 understands the "ietf-keystore" module defined in 418 [I-D.ietf-netconf-keystore]. 420 This first example illustrates the case where the signed certificate 421 is for the same asymmetric key used by the SZTP-client's 422 manufacturer-generated identity certificate (e.g., an IDevID, from 423 [Std-802.1AR-2018]). As such, the configuration needs to associate 424 the newly signed certificate with the existing asymmetric key: 426 =============== NOTE: '\' line wrapping per RFC 8792 ================ 428 { 429 "ietf-keystore:keystore": { 430 "asymmetric-keys": { 431 "asymmetric-key": [ 432 { 433 "name": "Manufacturer-Generated Hidden Key", 434 "public-key-format": "ietf-crypto-types:subject-public-key\ 435 -info-format", 436 "public-key": "base64encodedvalue==", 437 "hidden-private-key": [null], 438 "certificates": { 439 "certificate": [ 440 { 441 "name": "Manufacturer-Generated IDevID Cert", 442 "cert-data": "base64encodedvalue==" 443 }, 444 { 445 "name": "Newly-Generated LDevID Cert", 446 "cert-data": "base64encodedvalue==" 447 } 448 ] 449 } 450 } 451 ] 452 } 453 } 454 } 456 This second example illustrates the case where the signed certificate 457 is for a newly generated asymmetric key. As such, the configuration 458 needs to associate the newly signed certificate with the newly 459 generated asymmetric key: 461 =============== NOTE: '\' line wrapping per RFC 8792 ================ 463 { 464 "ietf-keystore:keystore": { 465 "asymmetric-keys": { 466 "asymmetric-key": [ 467 { 468 "name": "Manufacturer-Generated Hidden Key", 469 "public-key-format": "ietf-crypto-types:subject-public-key\ 470 -info-format", 471 "public-key": "base64encodedvalue==", 472 "hidden-private-key": [null], 473 "certificates": { 474 "certificate": [ 475 { 476 "name": "Manufacturer-Generated IDevID Cert", 477 "cert-data": "base64encodedvalue==" 478 } 479 ] 480 } 481 }, 482 { 483 "name": "Newly-Generated Hidden Key", 484 "public-key-format": "ietf-crypto-types:subject-public-key\ 485 -info-format", 486 "public-key": "base64encodedvalue==", 487 "hidden-private-key": [null], 488 "certificates": { 489 "certificate": [ 490 { 491 "name": "Newly-Generated LDevID Cert", 492 "cert-data": "base64encodedvalue==" 493 } 494 ] 495 } 496 } 497 ] 498 } 499 } 500 } 502 In addition to configuring the signed certificate, it is often 503 necessary to also configure the Issuer's signing certificate so that 504 the the device (i.e., STZP-client) can authenticate certificates 505 presented by peer devices signed by the same issuer as its own. 506 While outside the scope of this document, one way to do this would be 507 to use the "ietf-truststore" module defined in 508 [I-D.ietf-netconf-trust-anchors]. 510 2.3. YANG Module 512 This module augments an RPC defined in [RFC8572], uses a data type 513 defined in [I-D.ietf-netconf-crypto-types], has an normative 514 references to [RFC2986] and [ITU.X690.2015], and an informative 515 reference to [Std-802.1AR-2018]. 517 file "ietf-sztp-csr@2020-11-16.yang" 519 module ietf-sztp-csr { 520 yang-version 1.1; 521 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 522 prefix sztp-csr; 524 import ietf-sztp-bootstrap-server { 525 prefix sztp-svr; 526 reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 527 } 529 import ietf-yang-structure-ext { 530 prefix sx; 531 reference "RFC BBBB:YANG Data Structure Extensions"; 532 } 534 import ietf-crypto-types { 535 prefix ct; 536 reference 537 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 538 } 540 organization 541 "IETF NETCONF (Network Configuration) Working Group"; 543 contact 544 "WG Web: http://tools.ietf.org/wg/netconf 545 WG List: 546 Authors: Kent Watsen 547 Russ Housley 548 Sean Turner "; 550 description 551 "This module augments the 'get-bootstrapping-data' RPC, 552 defined in the 'ietf-sztp-bootstrap-server' module from 553 SZTP (RFC 8572), enabling the SZTP-client to obtain a 554 signed identity certificate (e.g., an LDevID from IEEE 555 802.1AR) as part of the SZTP 'onboarding-information' 556 response. 558 Copyright (c) 2020 IETF Trust and the persons identified 559 as authors of the code. All rights reserved. 561 Redistribution and use in source and binary forms, with 562 or without modification, is permitted pursuant to, and 563 subject to the license terms contained in, the Simplified 564 BSD License set forth in Section 4.c of the IETF Trust's 565 Legal Provisions Relating to IETF Documents 566 (https://trustee.ietf.org/license-info). 568 This version of this YANG module is part of RFC XXXX 569 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 570 itself for full legal notices. 572 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 573 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 574 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 575 document are to be interpreted as described in BCP 14 576 (RFC 2119) (RFC 8174) when, and only when, they appear 577 in all capitals, as shown here."; 579 revision 2020-11-16 { 580 description 581 "Initial version"; 582 reference 583 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 584 in a Secure Zero Touch Provisioning (SZTP) 585 Bootstrapping Request"; 586 } 588 identity certificate-request-format { 589 description 590 "A base identity for the request formats supported 591 by the SZTP-client. 593 Additional derived identities MAY be defined by 594 future efforts."; 595 } 597 identity p10 { 598 base "certificate-request-format"; 599 description 600 "Indicates that the SZTP-client supports generating 601 requests using the 'CertificationRequest' structure 602 defined in RFC 2986."; 603 reference 604 "RFC 2986: PKCS #10: Certification Request Syntax 605 Specification Version 1.7"; 607 } 609 identity cmc { 610 base "certificate-request-format"; 611 description 612 "Indicates that the SZTP-client supports generating 613 requests using a constrained version of the 'Full 614 PKI Request' structure defined in RFC 5272."; 615 reference 616 "RFC 5272: Certificate Management over CMS (CMC)"; 617 } 619 identity cmp { 620 base "certificate-request-format"; 621 description 622 "Indicates that the SZTP-client supports generating 623 requests that contain a PKCS#10 Certificate Signing 624 Request (p10cr), as defined in RFC 2986, encapsulated 625 in a Nested Message Content (nested), as defined in 626 RFC 4210."; 627 reference 628 "RFC 2986: PKCS #10: Certification Request Syntax 629 Specification Version 1.7 630 RFC 4210: Internet X.509 Public Key Infrastructure 631 Certificate Management Protocol (CMP)"; 632 } 634 // Protocol-accessible nodes 636 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."; 653 reference 654 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 655 area networks - Secure Device Identity 656 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 658 container csr-support { 659 presence 660 "Indicates that the SZTP-client is capable of sending CSRs."; 661 description 662 "The 'csr-support' node enables the SZTP-client to indicate 663 that it supports generating certificate signing requests 664 (CSRs), and to provide details around the CSRs it is able 665 to generate. 667 When present, the SZTP-server MAY respond with the HTTP 668 error 400 (Bad Request) with an 'ietf-restconf:errors' 669 document having the 'error-tag' value 'missing-attribute' 670 and the 'error-info' node containing the 'request-info' 671 structure described in this module."; 672 container key-generation { 673 presence 674 "Indicates that the SZTP-client is capable of 675 generating a new asymmetric key pair. 677 If this node is not present, the SZTP-server MAY 678 request a CSR using the asymmetric key associated 679 with the device's existing identity certificate 680 (e.g., an IDevID from IEEE 802.1AR)."; 681 description 682 "Specifies details for the SZTP-client's ability to 683 generate a new asymmetric key pair."; 684 container supported-algorithms { 685 description 686 "A list of public key algorithms supported by the 687 SZTP-client for generating a new key."; 688 leaf-list algorithm-identifier { 689 type binary; 690 min-elements 1; 691 description 692 "An AlgorithmIdentifier, as defined in RFC 2986, 693 encoded using ASN.1 distinguished encoding rules 694 (DER), as specified in ITU-T X.690."; 695 reference 696 "RFC 2986: PKCS #10: Certification Request Syntax 697 Specification Version 1.7 698 ITU-T X.690: 699 Information technology - ASN.1 encoding rules: 700 Specification of Basic Encoding Rules (BER), 701 Canonical Encoding Rules (CER) and Distinguished 702 Encoding Rules (DER)."; 703 } 704 } 705 } 706 container csr-generation { 707 description 708 "Specifies details for the SZTP-client's ability to 709 generate a certificate signing requests."; 710 container supported-formats { 711 description 712 "A list of certificate request formats supported 713 by the SZTP-client for generating a new key."; 714 leaf-list format-identifier { 715 type identityref { 716 base certificate-request-format; 717 } 718 min-elements 1; 719 description 720 "A certificate request format supported by the 721 SZTP-client."; 722 } 723 } 724 } 725 } 727 container csr { 728 presence 729 "Indicates that the SZTP-client has sent a CSR."; 730 description 731 "The 'csr' node enables the SZTP-client to convey 732 a certificate signing request, using the encoding 733 format selected by the SZT-server's 'request-info' 734 response to the SZTP-client's previously sent 735 'get-bootstrapping-data' request containing the 736 'csr-support' node. 738 When present, the SZTP-server SHOULD respond with 739 an SZTP 'onboarding-information' message containing 740 a signed certificate for the conveyed CSR. The 741 SZTP-server MAY alternatively respond with another 742 HTTP error containing another 'request-info', in 743 which case the SZTP-client MUST invalidate the CSR 744 sent in this node."; 745 choice request-type { 746 mandatory true; 747 description 748 "A choice amongst certificate signing request formats. 750 Additional formats MAY be augmented into this 'choice' 751 statement by future efforts."; 752 case p10 { 753 leaf p10 { 754 type ct:csr; 755 description 756 "A CertificationRequest structure, per RFC 2986. 757 Please see 'csr' in RFC AAAA for encoding details."; 758 reference 759 "RFC 2986: 760 PKCS #10: Certification Request Syntax Specification 761 RFC AAAA: 762 YANG Data Types and Groupings for Cryptography"; 763 } 764 } 765 case cmc { 766 leaf cmc { 767 type binary; 768 description 769 "A constrained version of the 'Full PKI Request' 770 message defined in RFC 5272, encoded using ASN.1 771 distinguished encoding rules (DER), as specified 772 in ITU-T X.690. 774 For asymmetric key-based origin authentication 775 of a CSR based on the IDevID's private key for the 776 associated IDevID's public key, the PKIData contains 777 one reqSequence element and no controlSequence, 778 cmsSequence, or otherMsgSequence elements. The 779 reqSequence is the TaggedRequest and it is the tcr 780 CHOICE. The tcr is the TaggedCertificationRequest 781 and it a bodyPartId and the certificateRequest 782 elements. The certificateRequest is signed with 783 the IDevID's private key. 785 For asymmetric key-based origin authentication 786 based on the IDevID's private key that encapsulates 787 a CSR signed by the LDevID's private key, the 788 PKIData contains one cmsSequence element and no 789 controlSequence, reqSequence, or otherMsgSequence 790 elements. The cmsSequence is the TaggedContentInfo 791 and it includes a bodyPartID element and a 792 contentInfo. The contentInfo is a SignedData 793 encapsulating a PKIData with one reqSequence 794 element and no controlSequence, cmsSequence, or 795 otherMsgSequence elements. The reqSequence is 796 the TaggedRequest and it is the tcr CHOICE. The 797 tcr is the TaggedCertificationRequest and it a 798 bodyPartId and the certificateRequest elements. 799 The certificateRequest is signed with the LDevID's 800 private key. 802 For shared secret-based origin authentication of 803 a CSR signed by the LDevID's private key, the 804 PKIData contains one cmsSequence element and no 805 controlSequence, reqSequence, or otherMsgSequence 806 elements. The cmsSequence is the TaggedContentInfo 807 and it includes a bodyPartID element and a 808 contentInfo. The contentInfo is an AuthenticatedData 809 encapsulating a PKIData with one reqSequence 810 element and no controlSequence, cmsSequence, or 811 otherMsgSequence elements. The reqSequence is the 812 TaggedRequest and it is the tcr CHOICE. The tcr 813 is the TaggedCertificationRequest and it a 814 bodyPartId and the certificateRequest elements. 815 The certificateRequest is signed with the LDevID's 816 private key."; 817 reference 818 "RFC 5272: Certificate Management over CMS (CMC) 819 ITU-T X.690: 820 Information technology - ASN.1 encoding rules: 821 Specification of Basic Encoding Rules (BER), 822 Canonical Encoding Rules (CER) and Distinguished 823 Encoding Rules (DER)."; 824 } 825 } 826 case cmp { 827 leaf cmp { 828 type binary; 829 description 830 "A PKIMessage structure, as defined in RFC 4210, 831 encoded using ASN.1 distinguished encoding rules 832 (DER), as specified in ITU-T X.690. 834 The PKIMessage structure contains a PKCS#10 835 Certificate Signing Request (p10cr), as defined in 836 RFC 2986, encapsulated in a Nested Message Content 837 (nested) structure, as defined in RFC 4210. 839 For asymmetric key-based origin authentication of 840 a CSR based on the IDevID's private key for the 841 associated IDevID's public key, PKIMessages contains 842 one PKIMessage with one body element, a header 843 element that is an empty sequence, and no protection 844 or extraCerts elements. The body element contains a 845 p10cr CHOICE. 847 For asymmetric key-based origin authentication based 848 on the IDevID's private key that encapsulates a CSR 849 signed by the LDevID's private key, PKIMessages 850 contains one PKIMessage with one header element, 851 one body element, one protection element, and one 852 extraCerts element. The header element contains 853 pvno, sender, recipient, and protectionAlg elements 854 and no other elements. The body element contains the 855 nested CHOICE. The nested element's PKIMessages 856 contains one PKIMessage with one body element, one 857 header element that is an empty sequence, and no 858 protection or extraCerts elements. The nested 859 element's body element contains a p10cr CHOICE. The 860 protection element contains the digital signature 861 generated with the IDevID's private key. The 862 extraCerts element contains the IDevID certificate. 864 For shared secret-based origin authentication of a 865 CSR signed by the LDevID's private key, PKIMessages 866 contains one PKIMessage with one header element, 867 one body element, one protection element, and no 868 extraCerts element. The header element contains 869 pvno, sender, recipient, and protectionAlg elements 870 and no other elements. The body element contains 871 the nested CHOICE. The nested element's PKIMessages 872 contains one PKIMessage with one body element, one 873 header element that is an empty sequence, and no 874 protection or extraCerts elements. The body element 875 contains a p10cr CHOICE. The protection element 876 contains the MAC value generated with the shared 877 secret."; 878 reference 879 "RFC 2986: 880 PKCS #10: Certification Request Syntax 881 Specification Version 1.7 882 RFC 4210: 883 Internet X.509 Public Key Infrastructure 884 Certificate Management Protocol (CMP) 885 ITU-T X.690: 886 Information technology - ASN.1 encoding rules: 887 Specification of Basic Encoding Rules (BER), 888 Canonical Encoding Rules (CER) and Distinguished 889 Encoding Rules (DER)."; 890 } 891 } 892 } 893 } 894 } 895 sx:structure request-info { 896 container key-generation { 897 presence 898 "Indicates that the SZTP-client is to generate a new 899 asymmetric key. If missing, then the SZTP-client 900 MUST reuse the key associated with its existing 901 identity certificate (e.g., IDevID). 903 This leaf MUST only appear if the SZTP-clients 904 'csr-support' included the 'key-generation' node."; 905 description 906 "Specifies details for the key that the SZTP-client 907 is to generate."; 908 container selected-algorithm { 909 description 910 "The key algorithm selected by the SZTP-server. The 911 algorithm MUST be one of the algorithms specified 912 by the 'supported-algorithms' node in the 913 SZTP-client's request message."; 914 leaf algorithm-identifier { 915 type binary; 916 mandatory true; 917 description 918 "An AlgorithmIdentifier, as defined in RFC 2986, 919 encoded using ASN.1 distinguished encoding rules 920 (DER), as specified in ITU-T X.690."; 921 reference 922 "RFC 2986: PKCS #10: Certification Request Syntax 923 Specification Version 1.7 924 ITU-T X.690: 925 Information technology - ASN.1 encoding rules: 926 Specification of Basic Encoding Rules (BER), 927 Canonical Encoding Rules (CER) and Distinguished 928 Encoding Rules (DER)."; 929 } 930 } 931 } 932 container csr-generation { 933 description 934 "Specifies details for the CSR that the SZTP-client 935 is to generate."; 936 container selected-format { 937 description 938 "The CSR format selected by the SZTP-server. The 939 format MUST be one of the formats specified by 940 the 'supported-formats' node in the SZTP-client's 941 request message."; 942 leaf format-identifier { 943 type identityref { 944 base certificate-request-format; 945 } 946 mandatory true; 947 description 948 "A certificate request format to be used by the 949 SZTP-client."; 950 } 951 } 952 } 953 leaf cert-req-info { 954 type ct:csr-info; 955 description 956 "A CertificationRequestInfo structure, as defined in 957 RFC 2986. 959 Enables the SZTP-server to provide a fully-populated 960 CertificationRequestInfo structure that the SZTP-client 961 only needs to sign in order to generate the complete 962 'CertificationRequest' structure to send to SZTP-server 963 in its next 'get-bootstrapping-data' request message. 965 When provided, the SZTP-client SHOULD use this 966 structure to generate its CSR; failure to do so MAY 967 result in another 400 (Bad Request) response. 969 When not provided, the SZTP-client SHOULD generate a 970 CSR using the same structure defined in its existing 971 identity certificate (e.g., IDevID). 973 It is an error if the 'AlgorithmIdentifier' field 974 contained inside the 'SubjectPublicKeyInfo' field 975 does not match the algorithm identified by the 976 'selected-algorithm' node."; 977 reference 978 "RFC 2986: 979 PKCS #10: Certification Request Syntax Specification 980 RFC AAAA: 981 YANG Data Types and Groupings for Cryptography"; 982 } 983 } 984 } 986 988 3. Security Considerations 990 This document builds on top of the solution presented in [RFC8572] 991 and therefore all the Security Considerations discussed in RFC 8572 992 apply here as well. 994 3.1. SZTP-Client Considerations 996 3.1.1. Ensuring the Integrity of Asymmetric Private Keys 998 The private key the SZTP-client uses for the dynamically-generated 999 identity certificate MUST be protected from inadvertent disclosure in 1000 order to prevent identity fraud. 1002 The security of this private key is essential in order to ensure the 1003 associated identity certificate can be used as a root of trust. 1005 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1006 security module), such as a TPM (trusted platform module), to 1007 generate and forever contain the private key within the security 1008 perimeter of the HSM. In such cases, the private key, and its 1009 associated certificates, MAY have long validity periods. 1011 In cases where the device does not possess an HSM, or otherwise is 1012 unable to use an HSM for the private key, it is RECOMMENDED to 1013 regenerate the private key (and associated identity certificates) 1014 periodically. Details for how to generate a new private key and 1015 associate a new identity certificate are outside the scope of this 1016 document. 1018 3.1.2. Reuse of a Manufacturer-generated Private Key 1020 It is RECOMMENDED that a new private key is generated for each CSR 1021 described in this document. 1023 This private key SHOULD be protected as well as the built-in private 1024 key associated with the device's initial secure device identity 1025 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1027 In cases where it it not possible to generate a new private key that 1028 is protected as well as the built-in private key, it is RECOMMENDED 1029 to reuse the built-in private key rather then generate a new private 1030 key that is not as well protected. 1032 3.1.3. Replay Attack Protection 1034 This RFC enables an SZTP-client to announce an ability to generate 1035 new key to use for its CSR. 1037 When the SZTP-server responds with a request for the device to 1038 generate a new key, it is essential that the device actually 1039 generates a new key. 1041 Generating a new key each time enables the random bytes used to 1042 create the key to serve the dual-purpose of also acting like a 1043 "nonce" used in other mechanisms to detect replay attacks. 1045 When a fresh public/private key pair is generated for the request, 1046 confirmation to the SZTP-client that the response has not been 1047 replayed is enabled by the SZTP-client's fresh public key appearing 1048 in the signed certificate provided by the SZTP-server. 1050 When a public/private key pair associated with the IDevID used for 1051 the request, there may not be confirmation to the SZTP-client that 1052 the response has not been replayed; however, the worst case result is 1053 a lost certificate that is associated to the private key known only 1054 to the SZTP-client. 1056 3.1.4. Connecting to an Untrusted Bootstrap Server 1058 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1059 by blindly authenticating the SZTP-server's TLS end-entity 1060 certificate. 1062 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1063 client MUST assert that the bootstrapping data returned is signed, if 1064 the SZTP-client is to trust it. 1066 However, the HTTP error message used in this document cannot be 1067 signed data, as described in RFC 8572. 1069 Therefore, the solution presented in this document cannot be used 1070 when the SZTP-client connects to an untrusted SZTP-server. 1072 Consistent with the recommendation presented in Section 9.6 of 1073 [RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input 1074 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1075 instead the "signed-data-preferred" input parameter, as discussed in 1076 Appendix B of [RFC8572]. 1078 3.1.5. Selecting the Best Origin Authentication Mechanism 1080 When generating a new key, it is important that the client be able to 1081 provide additional proof to the CA that it was the entity that 1082 generated the key. 1084 All of the certificate request formats defined in this document 1085 (e.g., CMC, CMP, etc.), not including a raw PKCS#10, support origin 1086 authentication. 1088 These formats support origin authentication using both PKI and shared 1089 secret. 1091 Typically only one possible origin authentication mechanism can 1092 possibly be used but, in the case that the SZTP-client authenticates 1093 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1094 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1095 SZTP-client may need to choose between the two options. 1097 In the case the SZTP-client must choose between the asymmetric key 1098 option versus a shared secret for origin authentication, it is 1099 RECOMMENDED that the SZTP-client choose using the asymmetric key 1100 option. 1102 3.1.6. Clearing the Private Key and Associated Certificate 1104 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1105 the deployment-generated identity certificate (e.g., LDevID) and the 1106 associated private key (assuming a new private key was generated for 1107 the purpose), are considered user data and SHOULD be cleared whenever 1108 the device is reset to its factory default state, such as by the 1109 "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. 1111 3.2. SZTP-Server Considerations 1113 3.2.1. Conveying Proof of Possession to a CA 1115 3.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server 1117 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1118 by blindly authenticating the SZTP-server's TLS end-entity 1119 certificate. 1121 As is recommended in Section 3.1.4 in this document, in such cases, 1122 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1124 The reciprocal of this statement is that SZTP-servers, wanting to 1125 support SZTP-clients that don't trust them, SHOULD support the 1126 "signed-data-preferred" input parameter, as discussed in Appendix B 1127 of [RFC8572]. 1129 3.2.3. YANG Module Considerations 1131 The recommended format for documenting the Security Considerations 1132 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1133 the module defined in this document only augments two input 1134 parameters into the "get-bootstrapping-data" RPC in [RFC8572], and 1135 therefore only needs to point to the relevant Security Considerations 1136 sections in that RFC. 1138 * Security considerations for the "get-bootstrapping-data" RPC are 1139 described in Section 9.16 of [RFC8572]. 1141 * Security considerations for the "input" parameters passed inside 1142 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1143 [RFC8572]. 1145 4. IANA Considerations 1147 4.1. The "IETF XML" Registry 1149 This document registers one URI in the "ns" subregistry of the IETF 1150 XML Registry [RFC3688] maintained at 1151 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1152 Following the format in [RFC3688], the following registration is 1153 requested: 1155 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1156 Registrant Contact: The NETCONF WG of the IETF. 1157 XML: N/A, the requested URI is an XML namespace. 1159 4.2. The "YANG Module Names" Registry 1161 This document registers one YANG module in the YANG Module Names 1162 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1163 yang-parameters/yang-parameters.xhtml. Following the format defined 1164 in [RFC6020], the below registration is requested: 1166 name: ietf-sztp-csr 1167 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1168 prefix: sztp-csr 1169 reference: RFC XXXX 1171 5. References 1173 5.1. Normative References 1175 [I-D.ietf-netconf-crypto-types] 1176 Watsen, K., "YANG Data Types and Groupings for 1177 Cryptography", Work in Progress, Internet-Draft, draft- 1178 ietf-netconf-crypto-types-18, 20 August 2020, 1179 . 1182 [ITU.X690.2015] 1183 International Telecommunication Union, "Information 1184 Technology - ASN.1 encoding rules: Specification of Basic 1185 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1186 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1187 X.690, ISO/IEC 8825-1, August 2015, 1188 . 1190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1191 Requirement Levels", BCP 14, RFC 2119, 1192 DOI 10.17487/RFC2119, March 1997, 1193 . 1195 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1196 Request Syntax Specification Version 1.7", RFC 2986, 1197 DOI 10.17487/RFC2986, November 2000, 1198 . 1200 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1201 the Network Configuration Protocol (NETCONF)", RFC 6020, 1202 DOI 10.17487/RFC6020, October 2010, 1203 . 1205 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1206 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1207 . 1209 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1210 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1211 . 1213 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1214 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1215 May 2017, . 1217 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1218 Touch Provisioning (SZTP)", RFC 8572, 1219 DOI 10.17487/RFC8572, April 2019, 1220 . 1222 5.2. Informative References 1224 [I-D.ietf-netconf-keystore] 1225 Watsen, K., "A YANG Data Model for a Keystore", Work in 1226 Progress, Internet-Draft, draft-ietf-netconf-keystore-20, 1227 20 August 2020, . 1230 [I-D.ietf-netconf-trust-anchors] 1231 Watsen, K., "A YANG Data Model for a Truststore", Work in 1232 Progress, Internet-Draft, draft-ietf-netconf-trust- 1233 anchors-13, 20 August 2020, . 1236 [I-D.ietf-netmod-factory-default] 1237 WU, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1238 Factory Default Settings", Work in Progress, Internet- 1239 Draft, draft-ietf-netmod-factory-default-15, 25 April 1240 2020, . 1243 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1244 DOI 10.17487/RFC3688, January 2004, 1245 . 1247 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1248 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1249 . 1251 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1252 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1253 DOI 10.17487/RFC8407, October 2018, 1254 . 1256 [Std-802.1AR-2018] 1257 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1258 metropolitan area networks - Secure Device Identity", 14 1259 June 2018, . 1262 Authors' Addresses 1264 Kent Watsen 1265 Watsen Networks 1267 Email: kent+ietf@watsen.net 1268 Russ Housley 1269 Vigil Security, LLC 1271 Email: housley@vigilsec.com 1273 Sean Turner 1274 sn3rd 1276 Email: sean@sn3rd.com