idnits 2.17.1 draft-ietf-netconf-tls-client-server-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (November 3, 2016) is 2730 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 November 3, 2016 5 Expires: May 7, 2017 7 TLS Client and Server Models 8 draft-ietf-netconf-tls-client-server-01 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-keystore 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-keystore 38 Artwork in this document contains placeholder values for the date of 39 publication of this draft. Please apply the following replacement: 41 o "2016-11-02" --> the publication date of this draft 43 The following two Appendix sections are to be removed prior to 44 publication: 46 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 May 7, 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 . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 8 95 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 97 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 11 98 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 12 99 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 100 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 102 7.2. Informative References . . . . . . . . . . . . . . . . . 13 103 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 104 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 14 105 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 14 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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 Keystore 169 model [draft-ietf-netconf-keystore]. For instance, a reference to 170 the keystore model is made to indicate which trusted CA certificate a 171 client should use to authenticate the server's certificate. 173 2.1. Tree Diagram 175 The following tree diagram presents the data model for the two 176 groupings defined in the ietf-tls-client module. 178 module: ietf-tls-client 179 groupings: 180 initiating-tls-client-grouping 181 +---- some-TBD-tcp-client-stuff? string 182 +---- some-TBD-tls-client-stuff? string 184 non-initiating-tls-client-grouping 185 +---- some-TBD-tls-client-stuff? string 187 2.2. Example Usage 189 This section shows how it would appear if the initiating-tls-client- 190 grouping were populated with some data. This example is consistent 191 with the examples presented in Section 2.2 of 192 [draft-ietf-netconf-keystore]. 194 FIXME 196 2.3. YANG Model 198 This YANG module has a normative references to [RFC6991] and 199 [draft-ietf-netconf-keystore]. 201 file "ietf-tls-client@2016-11-02.yang" 203 // Editor's Note: 204 // This module is incomplete at this time. Below is 205 // just a skeleton so there's something in the draft. 206 // Please ignore this module for now! 208 module ietf-tls-client { 209 yang-version 1.1; 211 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client"; 212 prefix "tlsc"; 213 /* 214 import ietf-inet-types { 215 prefix inet; 216 reference 217 "RFC 6991: Common YANG Data Types"; 218 } 220 import ietf-keystore { 221 prefix ks; 222 reference 223 "RFC YYYY: Keystore Model"; 224 } 225 */ 226 organization 227 "IETF NETCONF (Network Configuration) Working Group"; 229 contact 230 "WG Web: 231 WG List: 233 WG Chair: Mehmet Ersue 234 236 WG Chair: Mahesh Jethanandani 237 239 Editor: Kent Watsen 240 "; 242 description 243 "This module defines a reusable grouping for a TLS client that 244 can be used as a basis for specific TLS client instances. 246 Copyright (c) 2014 IETF Trust and the persons identified as 247 authors of the code. All rights reserved. 249 Redistribution and use in source and binary forms, with or 250 without modification, is permitted pursuant to, and subject 251 to the license terms contained in, the Simplified BSD 252 License set forth in Section 4.c of the IETF Trust's 253 Legal Provisions Relating to IETF Documents 254 (http://trustee.ietf.org/license-info). 256 This version of this YANG module is part of RFC XXXX; see 257 the RFC itself for full legal notices."; 259 revision "2016-11-02" { 260 description 261 "Initial version"; 262 reference 263 "RFC XXXX: TLS Client and Server Models"; 264 } 266 grouping initiating-tls-client-grouping { 267 description 268 "A reusable grouping for a TLS client that initiates the 269 underlying TCP transport connection."; 270 leaf some-TBD-tcp-client-stuff { 271 type string; 272 description ""; 273 } 274 uses non-initiating-tls-client-grouping; 275 } 277 grouping non-initiating-tls-client-grouping { 278 description 279 "A reusable grouping for a TLS client that does not initiate 280 the underlying TCP transport connection."; 281 leaf some-TBD-tls-client-stuff { 282 type string; 283 description ""; 284 } 285 } 287 } 288 290 3. The TLS Server Model 292 The TLS server model presented in this section contains two YANG 293 groupings, one for a server that opens a socket to accept TCP 294 connections and another for a server that has had the TCP connection 295 opened for it already (e.g., inetd). 297 Both of these groupings reference data nodes defined by the Keystore 298 model [draft-ietf-netconf-keystore]. For instance, a reference to 299 the keystore model is made to indicate the certificate a server 300 should present. 302 3.1. Tree Diagram 304 The following tree diagram presents the data model for the two 305 groupings defined in the ietf-tls-server module. 307 module: ietf-tls-server 308 groupings: 309 listening-tls-server-grouping 310 +---- address? inet:ip-address 311 +---- port? inet:port-number 312 +---- certificates 313 | +---- certificate* [name] 314 | +---- name? -> /ks:keystore/private-keys/private-key/cert 315 ificate-chains/certificate-chain/name 316 +---- client-auth 317 +---- trusted-ca-certs? -> /ks:keystore/trusted-certific 318 ates/name 319 +---- trusted-client-certs? -> /ks:keystore/trusted-certific 320 ates/name 322 non-listening-tls-server-grouping 323 +---- certificates 324 | +---- certificate* [name] 325 | +---- name? -> /ks:keystore/private-keys/private-key/cert 326 ificate-chains/certificate-chain/name 327 +---- client-auth 328 +---- trusted-ca-certs? -> /ks:keystore/trusted-certific 329 ates/name 330 +---- trusted-client-certs? -> /ks:keystore/trusted-certific 331 ates/name 333 3.2. Example Usage 335 This section shows how it would appear if the listening-tls-server- 336 grouping were populated with some data. This example is consistent 337 with the examples presented in Section 2.2 of 338 [draft-ietf-netconf-keystore]. 340 342 6513 343 344 345 ex-key-sect571r1-cert 346 347 348 349 350 deployment-specific-ca-certs 351 352 353 explicitly-trusted-client-certs 354 355 356 358 3.3. YANG Model 360 This YANG module has a normative references to [RFC6991], and 361 [draft-ietf-netconf-keystore]. 363 file "ietf-tls-server@2016-11-02.yang" 365 module ietf-tls-server { 366 yang-version 1.1; 368 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server"; 369 prefix "tlss"; 371 import ietf-inet-types { 372 prefix inet; 373 reference 374 "RFC 6991: Common YANG Data Types"; 375 } 377 import ietf-keystore { 378 prefix ks; 379 reference 380 "RFC YYYY: Keystore Model"; 381 } 383 organization 384 "IETF NETCONF (Network Configuration) Working Group"; 386 contact 387 "WG Web: 388 WG List: 390 WG Chair: Mehmet Ersue 391 393 WG Chair: Mahesh Jethanandani 394 396 Editor: Kent Watsen 397 "; 399 description 400 "This module defines a reusable grouping for a TLS server that 401 can be used as a basis for specific TLS server instances. 403 Copyright (c) 2014 IETF Trust and the persons identified as 404 authors of the code. All rights reserved. 406 Redistribution and use in source and binary forms, with or 407 without modification, is permitted pursuant to, and subject 408 to the license terms contained in, the Simplified BSD 409 License set forth in Section 4.c of the IETF Trust's 410 Legal Provisions Relating to IETF Documents 411 (http://trustee.ietf.org/license-info). 413 This version of this YANG module is part of RFC XXXX; see 414 the RFC itself for full legal notices."; 416 revision "2016-11-02" { 417 description 418 "Initial version"; 419 reference 420 "RFC XXXX: TLS Client and Server Models"; 421 } 423 // grouping 424 grouping non-listening-tls-server-grouping { 425 description 426 "A reusable grouping for a TLS server that can be used as a 427 basis for specific TLS server instances."; 428 container certificates { 429 description 430 "The list of certificates the TLS server will present when 431 establishing a TLS connection in its Certificate message, 432 as defined in Section 7.4.2 in RRC 5246."; 433 reference 434 "RFC 5246: 435 The Transport Layer Security (TLS) Protocol Version 1.2"; 436 list certificate { 437 key name; 438 min-elements 1; 439 description 440 "An unordered list of certificates the TLS server can pick 441 from when sending its Server Certificate message."; 442 reference 443 "RFC 5246: The TLS Protocol, Section 7.4.2"; 444 leaf name { 445 type leafref { 446 path "/ks:keystore/ks:private-keys/ks:private-key/" 447 + "ks:certificate-chains/ks:certificate-chain/" 448 + "ks:name"; 449 } 450 description 451 "The name of the certificate in the keystore."; 452 } 453 } 454 } 456 container client-auth { 457 description 458 "A reference to a list of trusted certificate authority (CA) 459 certificates and a reference to a list of trusted client 460 certificates."; 461 leaf trusted-ca-certs { 462 type leafref { 463 path "/ks:keystore/ks:trusted-certificates/ks:name"; 464 } 465 description 466 "A reference to a list of certificate authority (CA) 467 certificates used by the TLS server to authenticate 468 TLS client certificates."; 469 } 471 leaf trusted-client-certs { 472 type leafref { 473 path "/ks:keystore/ks:trusted-certificates/ks:name"; 475 } 476 description 477 "A reference to a list of client certificates used by 478 the TLS server to authenticate TLS client certificates. 479 A clients certificate is authenticated if it is an 480 exact match to a configured trusted client certificate."; 481 } 482 } 483 } 485 grouping listening-tls-server-grouping { 486 description 487 "A reusable grouping for a TLS server that can be used as a 488 basis for specific TLS server instances."; 489 leaf address { 490 type inet:ip-address; 491 description 492 "The IP address of the interface to listen on. The TLS 493 server will listen on all interfaces if no value is 494 specified. Please note that some addresses have special 495 meanings (e.g., '0.0.0.0' and '::')."; 496 } 497 leaf port { 498 type inet:port-number; 499 description 500 "The local port number on this interface the TLS server 501 listens on. When this grouping is used, it is RECOMMENDED 502 that refine statement is used to either set a default port 503 value or to set mandatory true."; 504 } 505 uses non-listening-tls-server-grouping; 506 } 507 } 509 511 4. Security Considerations 513 5. IANA Considerations 515 5.1. The IETF XML Registry 517 This document registers two URIs in the IETF XML registry [RFC2119]. 518 Following the format in [RFC3688], the following registrations are 519 requested: 521 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client 522 Registrant Contact: The NETCONF WG of the IETF. 523 XML: N/A, the requested URI is an XML namespace. 525 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server 526 Registrant Contact: The NETCONF WG of the IETF. 527 XML: N/A, the requested URI is an XML namespace. 529 5.2. The YANG Module Names Registry 531 This document registers two YANG modules in the YANG Module Names 532 registry [RFC6020]. Following the format in [RFC6020], the the 533 following registrations are requested: 535 name: ietf-tls-client 536 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client 537 prefix: tlsc 538 reference: RFC XXXX 540 name: ietf-tls-server 541 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server 542 prefix: tlss 543 reference: RFC XXXX 545 6. Acknowledgements 547 The authors would like to thank for following for lively discussions 548 on list and in the halls (ordered by last name): Andy Bierman, Martin 549 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 550 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder, Phil 551 Shafer, Sean Turner, and Bert Wijnen. 553 7. References 555 7.1. Normative References 557 [draft-ietf-netconf-keystore] 558 Watsen, K., "Keystore Model", draft-ieft-netconf- 559 keystore-00 (work in progress), 2016, 560 . 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, 565 DOI 10.17487/RFC2119, March 1997, 566 . 568 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 569 the Network Configuration Protocol (NETCONF)", RFC 6020, 570 DOI 10.17487/RFC6020, October 2010, 571 . 573 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 574 RFC 6991, DOI 10.17487/RFC6991, July 2013, 575 . 577 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 578 NETCONF Protocol over Transport Layer Security (TLS) with 579 Mutual X.509 Authentication", RFC 7589, 580 DOI 10.17487/RFC7589, June 2015, 581 . 583 7.2. Informative References 585 [draft-ietf-netconf-call-home] 586 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 587 draft-ieft-netconf-call-home-17 (work in progress), 2015, 588 . 591 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 592 DOI 10.17487/RFC2818, May 2000, 593 . 595 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 596 DOI 10.17487/RFC3688, January 2004, 597 . 599 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 600 (TLS) Protocol Version 1.2", RFC 5246, 601 DOI 10.17487/RFC5246, August 2008, 602 . 604 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 605 September 1981, . 607 Appendix A. Change Log 609 A.1. server-model-09 to 00 611 o This draft was split out from draft-ietf-netconf-server-model-09. 613 o Noted that '0.0.0.0' and '::' might have special meanings. 615 Appendix B. Open Issues 617 Please see: https://github.com/netconf-wg/tls-client-server/issues. 619 Author's Address 621 Kent Watsen 622 Juniper Networks 624 EMail: kwatsen@juniper.net