idnits 2.17.1 draft-ietf-netconf-tls-client-server-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2016) is 2847 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) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track July 8, 2016 5 Expires: January 9, 2017 7 TLS Client and Server Models 8 draft-ietf-netconf-tls-client-server-00 10 Abstract 12 This document defines two YANG modules, one defines groupings for a 13 generic TLS client and the other defines groupings for a generic TLS 14 server. It is intended that these groupings will be used by 15 applications using the TLS protocol. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains many placeholder values that need to be replaced 20 with finalized values at the time of publication. This note 21 summarizes all of the substitutions that are needed. No other RFC 22 Editor instructions are specified elsewhere in this document. 24 This document contains references to other drafts in progress, both 25 in the Normative References section, as well as in body text 26 throughout. Please update the following references to reflect their 27 final RFC assignments: 29 o draft-ietf-netconf-system-keychain 31 Artwork in this document contains shorthand references to drafts in 32 progress. Please apply the following replacements: 34 o "XXXX" --> the assigned RFC value for this draft 36 o "YYYY" --> the assigned RFC value for draft-ietf-netconf-system- 37 keychain 39 Artwork in this document contains placeholder values for the date of 40 publication of this draft. Please apply the following replacement: 42 o "2016-07-08" --> the publication date of this draft 44 The following two Appendix sections are to be removed prior to 45 publication: 47 o Appendix A. Change Log 48 o Appendix B. Open Issues 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at http://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on January 9, 2017. 67 Copyright Notice 69 Copyright (c) 2016 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 87 2. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4 88 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 89 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 90 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 5 91 3. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 7 92 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 93 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 94 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 9 95 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 97 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 12 98 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 13 99 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 100 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 102 7.2. Informative References . . . . . . . . . . . . . . . . . 14 103 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 104 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 15 105 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 15 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 108 1. Introduction 110 This document defines two YANG [RFC6020] modules, one defines 111 groupings for a generic TLS client and the other defines groupings 112 for a generic TLS server (TLS is defined in [RFC5246]). It is 113 intended that these groupings will be used by applications using the 114 TLS protocol. For instance, these groupings could be used to help 115 define the data model for an HTTPS [RFC2818] server or a NETCONF over 116 TLS [RFC7589] based server. 118 The two YANG modules in this document each define two groupings. One 119 grouping defines everything other than what's needed for the TCP 120 [RFC793] protocol layer. The other grouping uses the first grouping 121 while adding TCP layer specifics (e.g., addresses to connect to, 122 ports to listen on, etc.). This separation is done in order to 123 enable applications the opportunity to define their own strategy for 124 how the underlying TCP connection is established. For instance, 125 applications supporting NETCONF Call Home 126 [draft-ietf-netconf-call-home] could use the first grouping for the 127 TLS parts it provides, while adding data nodes for the reversed TCP 128 layer. 130 1.1. Terminology 132 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 1.2. Tree Diagrams 138 A simplified graphical representation of the data models is used in 139 this document. The meaning of the symbols in these diagrams is as 140 follows: 142 o Brackets "[" and "]" enclose list keys. 144 o Braces "{" and "}" enclose feature names, and indicate that the 145 named feature must be present for the subtree to be present. 147 o Abbreviations before data node names: "rw" means configuration 148 (read-write) and "ro" state data (read-only). 150 o Symbols after data node names: "?" means an optional node, "!" 151 means a presence container, and "*" denotes a list and leaf-list. 153 o Parentheses enclose choice and case nodes, and case nodes are also 154 marked with a colon (":"). 156 o Ellipsis ("...") stands for contents of subtrees that are not 157 shown. 159 2. The TLS Client Model 161 EDITOR NOTE: Please ignore this section, it is incomplete. 163 The TLS client model presented in this section contains two YANG 164 groupings, one for a client that initiates the underlying TCP 165 connection and another for a client that has had the TCP connection 166 opened for it already (e.g., call home). 168 Both of these groupings reference data nodes defined by the System 169 Keychain model [draft-ietf-netconf-system-keychain]. For instance, a 170 reference to the keychain model is made to indicate which trusted CA 171 certificate a client should use to authenticate the server's 172 certificate. 174 2.1. Tree Diagram 176 The following tree diagram presents the data model for the two 177 groupings defined in the ietf-tls-client module. 179 module: ietf-tls-client 180 groupings: 181 initiating-tls-client-grouping 182 +---- some-TBD-tcp-client-stuff? string 183 +---- some-TBD-tls-client-stuff? string 185 non-initiating-tls-client-grouping 186 +---- some-TBD-tls-client-stuff? string 188 2.2. Example Usage 190 This section shows how it would appear if the initiating-tls-client- 191 grouping were populated with some data. This example is consistent 192 with the examples presented in Section 2.2 of 193 [draft-ietf-netconf-system-keychain]. 195 FIXME 197 2.3. YANG Model 199 This YANG module has a normative references to [RFC6991] and 200 [draft-ietf-netconf-system-keychain]. 202 file "ietf-tls-client@2016-07-08.yang" 204 // Editor's Note: 205 // This module is incomplete at this time. Below is 206 // just a skeleton so there's something in the draft. 207 // Please ignore this module for now! 209 module ietf-tls-client { 210 yang-version 1.1; 212 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 213 prefix "tlsc"; 214 /* 215 import ietf-inet-types { 216 prefix inet; 217 reference 218 "RFC 6991: Common YANG Data Types"; 219 } 221 import ietf-system-keychain { 222 prefix kc; 223 reference 224 "RFC YYYY: System Keychain Model"; 225 } 226 */ 227 organization 228 "IETF NETCONF (Network Configuration) Working Group"; 230 contact 231 "WG Web: 232 WG List: 234 WG Chair: Mehmet Ersue 235 237 WG Chair: Mahesh Jethanandani 238 240 Editor: Kent Watsen 241 "; 243 description 244 "This module defines a reusable grouping for a TLS client that 245 can be used as a basis for specific TLS client instances. 247 Copyright (c) 2014 IETF Trust and the persons identified as 248 authors of the code. All rights reserved. 250 Redistribution and use in source and binary forms, with or 251 without modification, is permitted pursuant to, and subject 252 to the license terms contained in, the Simplified BSD 253 License set forth in Section 4.c of the IETF Trust's 254 Legal Provisions Relating to IETF Documents 255 (http://trustee.ietf.org/license-info). 257 This version of this YANG module is part of RFC XXXX; see 258 the RFC itself for full legal notices."; 260 revision "2016-07-08" { 261 description 262 "Initial version"; 263 reference 264 "RFC XXXX: TLS Client and Server Models"; 265 } 267 grouping initiating-tls-client-grouping { 268 description 269 "A reusable grouping for a TLS client that initiates the 270 underlying TCP transport connection."; 271 leaf some-TBD-tcp-client-stuff { 272 type string; 273 description ""; 274 } 275 uses non-initiating-tls-client-grouping; 276 } 278 grouping non-initiating-tls-client-grouping { 279 description 280 "A reusable grouping for a TLS client that does not initiate 281 the underlying TCP transport connection."; 283 leaf some-TBD-tls-client-stuff { 284 type string; 285 description ""; 286 } 287 } 289 } 291 293 3. The TLS Server Model 295 The TLS server model presented in this section contains two YANG 296 groupings, one for a server that opens a socket to accept TCP 297 connections and another for a server that has had the TCP connection 298 opened for it already (e.g., inetd). 300 Both of these groupings reference data nodes defined by the System 301 Keychain model [draft-ietf-netconf-system-keychain]. For instance, a 302 reference to the keychain model is made to indicate the certificate a 303 server should present. 305 3.1. Tree Diagram 307 The following tree diagram presents the data model for the two 308 groupings defined in the ietf-tls-server module. 310 module: ietf-tls-server 311 groupings: 312 listening-tls-server-grouping 313 +---- address? inet:ip-address 314 +---- port? inet:port-number 315 +---- certificates 316 | +---- certificate* [name] 317 | +---- name? -> /kc:keychain/private-keys/private-key/certi 318 ficate-chains/certificate-chain/name 319 +---- client-auth 320 +---- trusted-ca-certs? -> /kc:keychain/trusted-certifica 321 tes/name 322 +---- trusted-client-certs? -> /kc:keychain/trusted-certifica 323 tes/name 325 non-listening-tls-server-grouping 326 +---- certificates 327 | +---- certificate* [name] 328 | +---- name? -> /kc:keychain/private-keys/private-key/certi 329 ficate-chains/certificate-chain/name 330 +---- client-auth 331 +---- trusted-ca-certs? -> /kc:keychain/trusted-certifica 332 tes/name 333 +---- trusted-client-certs? -> /kc:keychain/trusted-certifica 334 tes/name 336 3.2. Example Usage 338 This section shows how it would appear if the listening-tls-server- 339 grouping were populated with some data. This example is consistent 340 with the examples presented in Section 2.2 of 341 [draft-ietf-netconf-system-keychain]. 343 345 6513 346 347 348 ex-key-sect571r1-cert 349 350 351 352 353 deployment-specific-ca-certs 354 355 356 explicitly-trusted-client-certs 357 358 359 361 3.3. YANG Model 363 This YANG module has a normative references to [RFC6991], and 364 [draft-ietf-netconf-system-keychain]. 366 file "ietf-tls-server@2016-07-08.yang" 368 module ietf-tls-server { 369 yang-version 1.1; 371 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 372 prefix "tlss"; 374 import ietf-inet-types { 375 prefix inet; 376 reference 377 "RFC 6991: Common YANG Data Types"; 378 } 380 import ietf-system-keychain { 381 prefix kc; 382 reference 383 "RFC YYYY: System Keychain Model"; 384 } 386 organization 387 "IETF NETCONF (Network Configuration) Working Group"; 389 contact 390 "WG Web: 391 WG List: 393 WG Chair: Mehmet Ersue 394 396 WG Chair: Mahesh Jethanandani 397 399 Editor: Kent Watsen 400 "; 402 description 403 "This module defines a reusable grouping for a TLS server that 404 can be used as a basis for specific TLS server instances. 406 Copyright (c) 2014 IETF Trust and the persons identified as 407 authors of the code. All rights reserved. 409 Redistribution and use in source and binary forms, with or 410 without modification, is permitted pursuant to, and subject 411 to the license terms contained in, the Simplified BSD 412 License set forth in Section 4.c of the IETF Trust's 413 Legal Provisions Relating to IETF Documents 414 (http://trustee.ietf.org/license-info). 416 This version of this YANG module is part of RFC XXXX; see 417 the RFC itself for full legal notices."; 419 revision "2016-07-08" { 420 description 421 "Initial version"; 422 reference 423 "RFC XXXX: TLS Client and Server Models"; 424 } 426 // grouping 427 grouping non-listening-tls-server-grouping { 428 description 429 "A reusable grouping for a TLS server that can be used as a 430 basis for specific TLS server instances."; 431 container certificates { 432 description 433 "The list of certificates the TLS server will present when 434 establishing a TLS connection in its Certificate message, 435 as defined in Section 7.4.2 in RRC 5246."; 437 reference 438 "RFC 5246: 439 The Transport Layer Security (TLS) Protocol Version 1.2"; 440 list certificate { 441 key name; 442 min-elements 1; 443 description 444 "An unordered list of certificates the TLS server can pick 445 from when sending its Server Certificate message."; 446 reference 447 "RFC 5246: The TLS Protocol, Section 7.4.2"; 448 leaf name { 449 type leafref { 450 path "/kc:keychain/kc:private-keys/kc:private-key/" 451 + "kc:certificate-chains/kc:certificate-chain/" 452 + "kc:name"; 453 } 454 description 455 "The name of the certificate in the keychain."; 456 } 457 } 458 } 460 container client-auth { 461 description 462 "A reference to a list of trusted certificate authority (CA) 463 certificates and a reference to a list of trusted client 464 certificates."; 465 leaf trusted-ca-certs { 466 type leafref { 467 path "/kc:keychain/kc:trusted-certificates/kc:name"; 468 } 469 description 470 "A reference to a list of certificate authority (CA) 471 certificates used by the TLS server to authenticate 472 TLS client certificates."; 473 } 475 leaf trusted-client-certs { 476 type leafref { 477 path "/kc:keychain/kc:trusted-certificates/kc:name"; 478 } 479 description 480 "A reference to a list of client certificates used by 481 the TLS server to authenticate TLS client certificates. 482 A clients certificate is authenticated if it is an 483 exact match to a configured trusted client certificate."; 484 } 486 } 487 } 489 grouping listening-tls-server-grouping { 490 description 491 "A reusable grouping for a TLS server that can be used as a 492 basis for specific TLS server instances."; 493 leaf address { 494 type inet:ip-address; 495 description 496 "The IP address of the interface to listen on. The TLS 497 server will listen on all interfaces if no value is 498 specified. Please note that some addresses have special 499 meanings (e.g., '0.0.0.0' and '::')."; 500 } 501 leaf port { 502 type inet:port-number; 503 description 504 "The local port number on this interface the TLS server 505 listens on. When this grouping is used, it is RECOMMENDED 506 that refine statement is used to either set a default port 507 value or to set mandatory true."; 508 } 509 uses non-listening-tls-server-grouping; 510 } 511 } 513 515 4. Security Considerations 517 5. IANA Considerations 519 5.1. The IETF XML Registry 521 This document registers two URIs in the IETF XML registry [RFC2119]. 522 Following the format in [RFC3688], the following registrations are 523 requested: 525 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 526 Registrant Contact: The NETCONF WG of the IETF. 527 XML: N/A, the requested URI is an XML namespace. 529 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 530 Registrant Contact: The NETCONF WG of the IETF. 531 XML: N/A, the requested URI is an XML namespace. 533 5.2. The YANG Module Names Registry 535 This document registers two YANG modules in the YANG Module Names 536 registry [RFC6020]. Following the format in [RFC6020], the the 537 following registrations are requested: 539 name: ietf-tls-client 540 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 541 prefix: tlsc 542 reference: RFC XXXX 544 name: ietf-tls-server 545 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 546 prefix: tlss 547 reference: RFC XXXX 549 6. Acknowledgements 551 The authors would like to thank for following for lively discussions 552 on list and in the halls (ordered by last name): Andy Bierman, Martin 553 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 554 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder, Phil 555 Shafer, Sean Turner, and Bert Wijnen. 557 7. References 559 7.1. Normative References 561 [draft-ietf-netconf-system-keychain] 562 Watsen, K., "System Keychain Model", draft-ieft-netconf- 563 system-keychain-00 (work in progress), 2016, 564 . 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 573 the Network Configuration Protocol (NETCONF)", RFC 6020, 574 DOI 10.17487/RFC6020, October 2010, 575 . 577 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 578 RFC 6991, DOI 10.17487/RFC6991, July 2013, 579 . 581 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 582 NETCONF Protocol over Transport Layer Security (TLS) with 583 Mutual X.509 Authentication", RFC 7589, 584 DOI 10.17487/RFC7589, June 2015, 585 . 587 7.2. Informative References 589 [draft-ietf-netconf-call-home] 590 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 591 draft-ieft-netconf-call-home-17 (work in progress), 2015, 592 . 595 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 596 DOI 10.17487/RFC2818, May 2000, 597 . 599 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 600 DOI 10.17487/RFC3688, January 2004, 601 . 603 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 604 (TLS) Protocol Version 1.2", RFC 5246, 605 DOI 10.17487/RFC5246, August 2008, 606 . 608 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 609 September 1981, . 611 Appendix A. Change Log 613 A.1. server-model-09 to 00 615 o This draft was split out from draft-ietf-netconf-server-model-09. 617 o Noted that '0.0.0.0' and '::' might have special meanings. 619 Appendix B. Open Issues 621 Please see: https://github.com/netconf-wg/tls-client-server/issues. 623 Author's Address 625 Kent Watsen 626 Juniper Networks 628 EMail: kwatsen@juniper.net