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