idnits 2.17.1 draft-ietf-netconf-ssh-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 date (November 3, 2016) is 2728 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 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 G. Wu 5 Expires: May 7, 2017 Cisco Networks 6 November 3, 2016 8 SSH Client and Server Models 9 draft-ietf-netconf-ssh-client-server-01 11 Abstract 13 This document defines two YANG modules, one defines groupings for a 14 generic SSH client and the other defines groupings for a generic SSH 15 server. It is intended that these groupings will be used by 16 applications using the SSH protocol. 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. No other RFC 23 Editor instructions are specified elsewhere in this document. 25 This document contains references to other drafts in progress, both 26 in the Normative References section, as well as in body text 27 throughout. Please update the following references to reflect their 28 final RFC assignments: 30 o draft-ietf-netconf-keystore 32 Artwork in this document contains shorthand references to drafts in 33 progress. Please apply the following replacements: 35 o "XXXX" --> the assigned RFC value for this draft 37 o "YYYY" --> the assigned RFC value for draft-ietf-netconf-keystore 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-11-02" --> 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 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 SSH Client Model . . . . . . . . . . . . . . . . . . . . 4 88 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 89 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6 90 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 6 91 3. The SSH Server Model . . . . . . . . . . . . . . . . . . . . 11 92 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 11 93 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 94 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13 95 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 98 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 99 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 100 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 102 7.2. Informative References . . . . . . . . . . . . . . . . . 18 103 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 104 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 20 105 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 20 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 108 1. Introduction 110 This document defines two YANG [RFC6020] modules, one defines 111 groupings for a generic SSH client and the other defines groupings 112 for a generic SSH server (SSH is defined in [RFC4252], [RFC4253], and 113 [RFC4254]). It is intended that these groupings will be used by 114 applications using the SSH protocol. For instance, these groupings 115 could be used to help define the data model for an OpenSSH [OPENSSH] 116 server or a NETCONF over SSH [RFC6242] 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 SSH 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 SSH Client Model 161 The SSH client model presented in this section contains two YANG 162 groupings, one for a client that initiates the underlying TCP 163 connection and another for a client that has had the TCP connection 164 opened for it already (e.g., call home). 166 Both of these groupings reference data nodes defined by the Keystore 167 model [draft-ietf-netconf-keystore]. For instance, a reference to 168 the keystore model is made to indicate which trusted CA certificate a 169 client should use to authenticate X.509v3 certificate based host keys 170 [RFC6187]. 172 2.1. Tree Diagram 174 The following tree diagram presents the data model for the two 175 groupings defined in the ietf-ssh-client module. 177 module: ietf-ssh-client 178 groupings: 179 initiating-ssh-client-grouping 180 +---- server-auth 181 | +---- trusted-ssh-host-keys? -> /ks:keystore/trusted-ssh-hos 182 t-keys/name 183 | +---- trusted-ca-certs? -> /ks:keystore/trusted-certifi 184 cates/name {ssh-x509-certs}? 185 | +---- trusted-server-certs? -> /ks:keystore/trusted-certifi 186 cates/name 187 +---- client-auth 188 +---- matches* [name] 189 +---- name? string 190 +---- match* [name] 191 | +---- name? string 192 | +---- trusted-ssh-host-keys? -> /ks:keystore/trusted-s 193 sh-host-keys/name 194 | +---- trusted-ca-certs? -> /ks:keystore/trusted-c 195 ertificates/name 196 | +---- trusted-server-certs? -> /ks:keystore/trusted-c 197 ertificates/name 198 +---- user-auth-credentials? -> /ks:keystore/user-auth-cr 199 edentials/user-auth-credential/username 201 listening-ssh-client-grouping 202 +---- address? inet:ip-address 203 +---- port? inet:port-number 204 +---- server-auth 205 | +---- trusted-ssh-host-keys? -> /ks:keystore/trusted-ssh-hos 206 t-keys/name 207 | +---- trusted-ca-certs? -> /ks:keystore/trusted-certifi 208 cates/name {ssh-x509-certs}? 209 | +---- trusted-server-certs? -> /ks:keystore/trusted-certifi 210 cates/name 211 +---- client-auth 212 +---- matches* [name] 213 +---- name? string 214 +---- match* [name] 215 | +---- name? string 216 | +---- trusted-ssh-host-keys? -> /ks:keystore/trusted-s 217 sh-host-keys/name 218 | +---- trusted-ca-certs? -> /ks:keystore/trusted-c 219 ertificates/name 220 | +---- trusted-server-certs? -> /ks:keystore/trusted-c 221 ertificates/name 222 +---- user-auth-credentials? -> /ks:keystore/user-auth-cr 223 edentials/user-auth-credential/username 225 2.2. Example Usage 227 This section shows how it would appear if the initiating-ssh-client- 228 grouping were populated with some data. This example is consistent 229 with the examples presented in Section 2.2 of 230 [draft-ietf-netconf-keystore]. 232 FIXME (how to do an example for a module that only has groupings?) 234 2.3. YANG Model 236 This YANG module has a normative references to [RFC6991] and 237 [draft-ietf-netconf-keystore]. 239 file "ietf-ssh-client@2016-11-02.yang" 241 module ietf-ssh-client { 242 yang-version 1.1; 244 namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-client"; 245 prefix "sshc"; 247 import ietf-inet-types { 248 prefix inet; 249 reference 250 "RFC 6991: Common YANG Data Types"; 251 } 253 import ietf-keystore { 254 prefix ks; 255 reference 256 "RFC YYYY: Keystore Model"; 257 } 259 organization 260 "IETF NETCONF (Network Configuration) Working Group"; 262 contact 263 "WG Web: 264 WG List: 266 WG Chair: Mehmet Ersue 267 269 WG Chair: Mahesh Jethanandani 270 272 Author: Kent Watsen 273 275 Author: Gary Wu 276 "; 278 description 279 "This module defines a reusable grouping for a SSH client that 280 can be used as a basis for specific SSH client instances. 282 Copyright (c) 2014 IETF Trust and the persons identified as 283 authors of the code. All rights reserved. 285 Redistribution and use in source and binary forms, with or 286 without modification, is permitted pursuant to, and subject 287 to the license terms contained in, the Simplified BSD 288 License set forth in Section 4.c of the IETF Trust's 289 Legal Provisions Relating to IETF Documents 290 (http://trustee.ietf.org/license-info). 292 This version of this YANG module is part of RFC XXXX; see 293 the RFC itself for full legal notices."; 295 revision "2016-11-02" { 296 description 297 "Initial version"; 298 reference 299 "RFC XXXX: SSH Client and Server Models"; 300 } 302 feature ssh-x509-certs { 303 description 304 "The ssh-x509-certs feature indicates that the SSH 305 client supports RFC 6187"; 306 reference 307 "RFC 6187: X.509v3 Certificates for Secure Shell 308 Authentication"; 309 } 311 grouping initiating-ssh-client-grouping { 312 description 313 "A reusable grouping for a SSH client that initiates the 314 underlying TCP transport connection."; 316 container server-auth { 317 description 318 "Trusted server identities."; 320 leaf trusted-ssh-host-keys { 321 type leafref { 322 path "/ks:keystore/ks:trusted-ssh-host-keys/ks:name"; 323 } 324 description 325 "A reference to a list of SSH host keys used by the 326 SSH client to authenticate SSH server host keys. 327 A server host key is authenticate if it is an exact 328 match to a configured trusted SSH host key."; 329 } 331 leaf trusted-ca-certs { 332 if-feature ssh-x509-certs; 333 type leafref { 334 path "/ks:keystore/ks:trusted-certificates/ks:name"; 335 } 336 description 337 "A reference to a list of certificate authority (CA) 338 certificates used by the SSH client to authenticate 339 SSH server certificates."; 340 } 342 leaf trusted-server-certs { 343 type leafref { 344 path "/ks:keystore/ks:trusted-certificates/ks:name"; 345 } 346 description 347 "A reference to a list of server certificates used by 348 the SSH client to authenticate SSH server certificates. 349 A server certificate is authenticated if it is an 350 exact match to a configured trusted server certificate."; 351 } 352 } 354 container client-auth { 355 description 356 "The credentials used by the client to authenticate to 357 the SSH server."; 359 list matches { 360 key name; 361 description 362 "A matches expression, which performs like a firewall 363 rulebase in that each matches expression is considered 364 for a match before moving onto the next matches 365 expression. The first matching expression terminates 366 the search, and its 'user-auth-credentials' are used 367 to log into the SSH server."; 369 leaf name { 370 type string; 371 description 372 "An arbitrary name for this matches expression."; 373 } 374 list match { 375 key name; 376 description 377 "A match rule. The presented SSH server's host key 378 is matched against possible trusted SSH host keys 379 and certificates. If a match is found, the specified 380 'user-auth-credentials' is used to log into the 381 SSH server."; 382 leaf name { 383 type string; 384 description 385 "An arbitrary name for this match rule."; 386 } 387 leaf trusted-ssh-host-keys { 388 type leafref { 389 path "/ks:keystore/ks:trusted-ssh-host-keys/ks:name"; 390 } 391 description 392 "A test to see if the presented SSH host key 393 matches any of the host keys in the specified 394 'trusted-ssh-host-keys' list maintained by the 395 keystore module."; 396 } 397 leaf trusted-ca-certs { 398 type leafref { 399 path "/ks:keystore/ks:trusted-certificates/ks:name"; 400 } 401 description 402 "A test to see if the presented SSH host key matches 403 any of the trusted CA certificates in the specified 404 'trusted-certificates' list maintained by the 405 keystore module."; 406 } 407 leaf trusted-server-certs { 408 type leafref { 409 path "/ks:keystore/ks:trusted-certificates/ks:name"; 410 } 411 description 412 "A test to see if the presented SSH host key matches 413 any of the trusted server certificates in the specified 414 'trusted-certificates' list maintained by the 415 keystore module."; 416 } 418 } 419 leaf user-auth-credentials { 420 type leafref { 421 path "/ks:keystore/ks:user-auth-credentials/" 422 + "ks:user-auth-credential/ks:username"; 423 } 424 description 425 "The specific user authentication credentials to use if 426 all of the above 'match' expressions match."; 427 } 428 } 429 } 430 } // end initiating-ssh-client-grouping 432 grouping listening-ssh-client-grouping { 433 description 434 "A reusable grouping for a SSH client that does not 435 the underlying TCP transport connection have been 436 established using some other mechanism."; 437 leaf address { 438 type inet:ip-address; 439 description 440 "The IP address to listen for call-home connections on."; 441 } 442 leaf port { 443 type inet:port-number; 444 description 445 "The port number to listen for call-home connections. 446 When this grouping is used, it is RECOMMENED that 447 refine statement is used to either set a default port 448 value or to set mandatory true."; 449 } 450 uses initiating-ssh-client-grouping; 451 } 453 } 455 457 3. The SSH Server Model 459 The SSH server model presented in this section contains two YANG 460 groupings, one for a server that opens a socket to accept TCP 461 connections and another for a server that has had the TCP connection 462 opened for it already (e.g., inetd). 464 Both of these groupings reference data nodes defined by the Keystore 465 model [draft-ietf-netconf-keystore]. For instance, a reference to 466 the keystore model is made to indicate which host key a server should 467 present. 469 3.1. Tree Diagram 471 The following tree diagram presents the data model for the two 472 groupings defined in the ietf-ssh-server module. 474 module: ietf-ssh-server 475 groupings: 476 listening-ssh-server-grouping 477 +---- address? inet:ip-address 478 +---- port? inet:port-number 479 +---- host-keys 480 | +---- host-key* [name] 481 | +---- name? string 482 | +---- (host-key-type) 483 | +--:(public-key) 484 | | +---- public-key? -> /ks:keystore/private-keys/pri 485 vate-key/name 486 | +--:(certificate) 487 | +---- certificate? -> /ks:keystore/private-keys/pri 488 vate-key/certificate-chains/certificate-chain/name {ssh-x509-certs}? 489 +---- client-cert-auth {ssh-x509-certs}? 490 +---- trusted-ca-certs? -> /ks:keystore/trusted-certific 491 ates/name 492 +---- trusted-client-certs? -> /ks:keystore/trusted-certific 493 ates/name 495 non-listening-ssh-server-grouping 496 +---- host-keys 497 | +---- host-key* [name] 498 | +---- name? string 499 | +---- (host-key-type) 500 | +--:(public-key) 501 | | +---- public-key? -> /ks:keystore/private-keys/pri 502 vate-key/name 503 | +--:(certificate) 504 | +---- certificate? -> /ks:keystore/private-keys/pri 505 vate-key/certificate-chains/certificate-chain/name {ssh-x509-certs}? 506 +---- client-cert-auth {ssh-x509-certs}? 507 +---- trusted-ca-certs? -> /ks:keystore/trusted-certific 508 ates/name 509 +---- trusted-client-certs? -> /ks:keystore/trusted-certific 510 ates/name 512 3.2. Example Usage 514 This section shows how it would appear if the listening-ssh-server- 515 grouping were populated with some data. This example is consistent 516 with the examples presented in Section 2.2 of 517 [draft-ietf-netconf-keystore]. 519 521 830 522 523 524 deployment-specific-certificate 525 ex-key-sect571r1-cert 526 527 528 529 530 531 deployment-specific-ca-certs 532 533 534 explicitly-trusted-client-certs 535 536 537 539 3.3. YANG Model 541 This YANG module has a normative references to [RFC4253], [RFC6991], 542 and [draft-ietf-netconf-keystore]. 544 file "ietf-ssh-server@2016-11-02.yang" 546 module ietf-ssh-server { 547 yang-version 1.1; 549 namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-server"; 550 prefix "sshs"; 552 import ietf-inet-types { 553 prefix inet; 554 reference 555 "RFC 6991: Common YANG Data Types"; 556 } 558 import ietf-keystore { 559 prefix ks; 560 reference 561 "RFC YYYY: Keystore Model"; 562 } 564 organization 565 "IETF NETCONF (Network Configuration) Working Group"; 567 contact 568 "WG Web: 569 WG List: 571 WG Chair: Mehmet Ersue 572 574 WG Chair: Mahesh Jethanandani 575 577 Editor: Kent Watsen 578 "; 580 description 581 "This module defines a reusable grouping for a SSH server that 582 can be used as a basis for specific SSH server instances. 584 Copyright (c) 2014 IETF Trust and the persons identified as 585 authors of the code. All rights reserved. 587 Redistribution and use in source and binary forms, with or 588 without modification, is permitted pursuant to, and subject 589 to the license terms contained in, the Simplified BSD 590 License set forth in Section 4.c of the IETF Trust's 591 Legal Provisions Relating to IETF Documents 592 (http://trustee.ietf.org/license-info). 594 This version of this YANG module is part of RFC XXXX; see 595 the RFC itself for full legal notices."; 597 revision "2016-11-02" { 598 description 599 "Initial version"; 600 reference 601 "RFC XXXX: SSH Client and Server Models"; 602 } 604 // features 605 feature ssh-x509-certs { 606 description 607 "The ssh-x509-certs feature indicates that the NETCONF 608 server supports RFC 6187"; 609 reference 610 "RFC 6187: X.509v3 Certificates for Secure Shell 611 Authentication"; 612 } 613 // grouping 614 grouping non-listening-ssh-server-grouping { 615 description 616 "A reusable grouping for a SSH server that can be used as a 617 basis for specific SSH server instances."; 619 container host-keys { 620 description 621 "The list of host-keys the SSH server will present when 622 establishing a SSH connection."; 623 list host-key { 624 key name; 625 min-elements 1; 626 ordered-by user; 627 description 628 "An ordered list of host keys the SSH server will use to 629 construct its ordered list of algorithms, when sending 630 its SSH_MSG_KEXINIT message, as defined in Section 7.1 631 of RFC 4253."; 632 reference 633 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 634 leaf name { 635 type string; 636 description 637 "An arbitrary name for this host-key"; 638 } 639 choice host-key-type { 640 mandatory true; 641 description 642 "The type of host key being specified"; 643 leaf public-key { 644 type leafref { 645 path "/ks:keystore/ks:private-keys/ks:private-key/" 646 + "ks:name"; 647 } 648 description 649 "The public key is actually identified by the name of 650 its cooresponding private-key in the keystore."; 651 } 652 leaf certificate { 653 if-feature ssh-x509-certs; 654 type leafref { 655 path "/ks:keystore/ks:private-keys/ks:private-key/" 656 + "ks:certificate-chains/ks:certificate-chain/" 657 + "ks:name"; 658 } 659 description 660 "The name of a certificate in the keystore."; 662 } 663 } 664 } 665 } 667 container client-cert-auth { 668 if-feature ssh-x509-certs; 669 description 670 "A reference to a list of trusted certificate authority (CA) 671 certificates and a reference to a list of trusted client 672 certificates."; 673 leaf trusted-ca-certs { 674 type leafref { 675 path "/ks:keystore/ks:trusted-certificates/ks:name"; 676 } 677 description 678 "A reference to a list of certificate authority (CA) 679 certificates used by the SSH server to authenticate 680 SSH client certificates."; 681 } 683 leaf trusted-client-certs { 684 type leafref { 685 path "/ks:keystore/ks:trusted-certificates/ks:name"; 686 } 687 description 688 "A reference to a list of client certificates used by 689 the SSH server to authenticate SSH client certificates. 690 A clients certificate is authenticated if it is an 691 exact match to a configured trusted client certificate."; 692 } 693 } 694 } 696 grouping listening-ssh-server-grouping { 697 description 698 "A reusable grouping for a SSH server that can be used as a 699 basis for specific SSH server instances."; 700 leaf address { 701 type inet:ip-address; 702 description 703 "The IP address of the interface to listen on. The SSH 704 server will listen on all interfaces if no value is 705 specified. Please note that some addresses have special 706 meanings (e.g., '0.0.0.0' and '::')."; 707 } 708 leaf port { 709 type inet:port-number; 710 description 711 "The local port number on this interface the SSH server 712 listens on. When this grouping is used, it is RECOMMENED 713 that refine statement is used to either set a default port 714 value or to set mandatory true."; 715 } 716 uses non-listening-ssh-server-grouping; 717 } 718 } 720 722 4. Security Considerations 724 5. IANA Considerations 726 5.1. The IETF XML Registry 728 This document registers two URIs in the IETF XML registry [RFC2119]. 729 Following the format in [RFC3688], the following registrations are 730 requested: 732 URI: urn:ietf:params:xml:ns:yang:ietf-ssh-client 733 Registrant Contact: The NETCONF WG of the IETF. 734 XML: N/A, the requested URI is an XML namespace. 736 URI: urn:ietf:params:xml:ns:yang:ietf-ssh-server 737 Registrant Contact: The NETCONF WG of the IETF. 738 XML: N/A, the requested URI is an XML namespace. 740 5.2. The YANG Module Names Registry 742 This document registers two YANG modules in the YANG Module Names 743 registry [RFC6020]. Following the format in [RFC6020], the the 744 following registrations are requested: 746 name: ietf-ssh-client 747 namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-client 748 prefix: sshc 749 reference: RFC XXXX 751 name: ietf-ssh-server 752 namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-server 753 prefix: sshs 754 reference: RFC XXXX 756 6. Acknowledgements 758 The authors would like to thank for following for lively discussions 759 on list and in the halls (ordered by last name): Andy Bierman, Martin 760 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 761 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder, Phil 762 Shafer, Sean Turner, Michal Vasko, and Bert Wijnen. 764 7. References 766 7.1. Normative References 768 [draft-ietf-netconf-keystore] 769 Watsen, K., "Keystore Model", draft-ieft-netconf- 770 keystore-00 (work in progress), 2016, 771 . 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, 776 DOI 10.17487/RFC2119, March 1997, 777 . 779 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 780 the Network Configuration Protocol (NETCONF)", RFC 6020, 781 DOI 10.17487/RFC6020, October 2010, 782 . 784 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 785 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 786 March 2011, . 788 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 789 RFC 6991, DOI 10.17487/RFC6991, July 2013, 790 . 792 7.2. Informative References 794 [draft-ietf-netconf-call-home] 795 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 796 draft-ieft-netconf-call-home-17 (work in progress), 2015, 797 . 800 [OPENSSH] "OpenSSH", 2016, . 802 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 803 DOI 10.17487/RFC3688, January 2004, 804 . 806 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 807 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 808 January 2006, . 810 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 811 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 812 January 2006, . 814 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 815 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 816 January 2006, . 818 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 819 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 820 . 822 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 823 September 1981, . 825 Appendix A. Change Log 827 A.1. server-model-09 to 00 829 o This draft was split out from draft-ietf-netconf-server-model-09. 831 o Added in previously missing ietf-ssh-client module. 833 o Noted that '0.0.0.0' and '::' might have special meanings. 835 Appendix B. Open Issues 837 Please see: https://github.com/netconf-wg/ssh-client-server/issues. 839 Authors' Addresses 841 Kent Watsen 842 Juniper Networks 844 EMail: kwatsen@juniper.net 846 Gary Wu 847 Cisco Networks 849 EMail: garywu@cisco.com