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