idnits 2.17.1 draft-ietf-netconf-ssh-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 date (July 8, 2016) is 2848 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: January 9, 2017 Cisco Networks 6 July 8, 2016 8 SSH Client and Server Models 9 draft-ietf-netconf-ssh-client-server-00 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-system-keychain 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-system- 38 keychain 40 Artwork in this document contains placeholder values for the date of 41 publication of this draft. Please apply the following replacement: 43 o "2016-07-08" --> the publication date of this draft 45 The following two Appendix sections are to be removed prior to 46 publication: 48 o Appendix A. Change Log 49 o Appendix B. Open Issues 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on January 9, 2017. 68 Copyright Notice 70 Copyright (c) 2016 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 87 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 88 2. The SSH Client Model . . . . . . . . . . . . . . . . . . . . 4 89 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 90 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6 91 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 6 92 3. The SSH Server Model . . . . . . . . . . . . . . . . . . . . 11 93 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 11 94 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 95 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13 96 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 99 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 100 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 103 7.2. Informative References . . . . . . . . . . . . . . . . . 18 104 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 105 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 20 106 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 20 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 109 1. Introduction 111 This document defines two YANG [RFC6020] modules, one defines 112 groupings for a generic SSH client and the other defines groupings 113 for a generic SSH server (SSH is defined in [RFC4252], [RFC4253], and 114 [RFC4254]). It is intended that these groupings will be used by 115 applications using the SSH protocol. For instance, these groupings 116 could be used to help define the data model for an OpenSSH [OPENSSH] 117 server or a NETCONF over SSH [RFC6242] based server. 119 The two YANG modules in this document each define two groupings. One 120 grouping defines everything other than what's needed for the TCP 121 [RFC793] protocol layer. The other grouping uses the first grouping 122 while adding TCP layer specifics (e.g., addresses to connect to, 123 ports to listen on, etc.). This separation is done in order to 124 enable applications the opportunity to define their own strategy for 125 how the underlying TCP connection is established. For instance, 126 applications supporting NETCONF Call Home 127 [draft-ietf-netconf-call-home] could use the first grouping for the 128 SSH parts it provides, while adding data nodes for the reversed TCP 129 layer. 131 1.1. Terminology 133 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 1.2. Tree Diagrams 139 A simplified graphical representation of the data models is used in 140 this document. The meaning of the symbols in these diagrams is as 141 follows: 143 o Brackets "[" and "]" enclose list keys. 145 o Braces "{" and "}" enclose feature names, and indicate that the 146 named feature must be present for the subtree to be present. 148 o Abbreviations before data node names: "rw" means configuration 149 (read-write) and "ro" state data (read-only). 151 o Symbols after data node names: "?" means an optional node, "!" 152 means a presence container, and "*" denotes a list and leaf-list. 154 o Parentheses enclose choice and case nodes, and case nodes are also 155 marked with a colon (":"). 157 o Ellipsis ("...") stands for contents of subtrees that are not 158 shown. 160 2. The SSH Client Model 162 The SSH client model presented in this section contains two YANG 163 groupings, one for a client that initiates the underlying TCP 164 connection and another for a client that has had the TCP connection 165 opened for it already (e.g., call home). 167 Both of these groupings reference data nodes defined by the System 168 Keychain model [draft-ietf-netconf-system-keychain]. For instance, a 169 reference to the keychain model is made to indicate which trusted CA 170 certificate a client should use to authenticate X.509v3 certificate 171 based host keys [RFC6187]. 173 2.1. Tree Diagram 175 The following tree diagram presents the data model for the two 176 groupings defined in the ietf-ssh-client module. 178 module: ietf-ssh-client 179 groupings: 180 initiating-ssh-client-grouping 181 +---- server-auth 182 | +---- trusted-ssh-host-keys? -> /kc:keychain/trusted-ssh-host 183 -keys/name 184 | +---- trusted-ca-certs? -> /kc:keychain/trusted-certific 185 ates/name {ssh-x509-certs}? 186 | +---- trusted-server-certs? -> /kc:keychain/trusted-certific 187 ates/name 188 +---- client-auth 189 +---- matches* [name] 190 +---- name? string 191 +---- match* [name] 192 | +---- name? string 193 | +---- trusted-ssh-host-keys? -> /kc:keychain/trusted-ss 194 h-host-keys/name 195 | +---- trusted-ca-certs? -> /kc:keychain/trusted-ce 196 rtificates/name 197 | +---- trusted-server-certs? -> /kc:keychain/trusted-ce 198 rtificates/name 199 +---- user-auth-credentials? -> /kc:keychain/user-auth-cre 200 dentials/user-auth-credential/username 202 listening-ssh-client-grouping 203 +---- address? inet:ip-address 204 +---- port? inet:port-number 205 +---- server-auth 206 | +---- trusted-ssh-host-keys? -> /kc:keychain/trusted-ssh-host 207 -keys/name 208 | +---- trusted-ca-certs? -> /kc:keychain/trusted-certific 209 ates/name {ssh-x509-certs}? 210 | +---- trusted-server-certs? -> /kc:keychain/trusted-certific 211 ates/name 212 +---- client-auth 213 +---- matches* [name] 214 +---- name? string 215 +---- match* [name] 216 | +---- name? string 217 | +---- trusted-ssh-host-keys? -> /kc:keychain/trusted-ss 218 h-host-keys/name 219 | +---- trusted-ca-certs? -> /kc:keychain/trusted-ce 220 rtificates/name 221 | +---- trusted-server-certs? -> /kc:keychain/trusted-ce 222 rtificates/name 223 +---- user-auth-credentials? -> /kc:keychain/user-auth-cre 224 dentials/user-auth-credential/username 226 2.2. Example Usage 228 This section shows how it would appear if the initiating-ssh-client- 229 grouping were populated with some data. This example is consistent 230 with the examples presented in Section 2.2 of 231 [draft-ietf-netconf-system-keychain]. 233 FIXME (how to do an example for a module that only has groupings?) 235 2.3. YANG Model 237 This YANG module has a normative references to [RFC6991] and 238 [draft-ietf-netconf-system-keychain]. 240 file "ietf-ssh-client@2016-07-08.yang" 242 module ietf-ssh-client { 243 yang-version 1.1; 245 namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-client"; 246 prefix "sshc"; 248 import ietf-inet-types { 249 prefix inet; 250 reference 251 "RFC 6991: Common YANG Data Types"; 252 } 254 import ietf-system-keychain { 255 prefix kc; 256 reference 257 "RFC YYYY: System Keychain Model"; 258 } 260 organization 261 "IETF NETCONF (Network Configuration) Working Group"; 263 contact 264 "WG Web: 265 WG List: 267 WG Chair: Mehmet Ersue 268 270 WG Chair: Mahesh Jethanandani 271 273 Author: Kent Watsen 274 276 Author: Gary Wu 277 "; 279 description 280 "This module defines a reusable grouping for a SSH client that 281 can be used as a basis for specific SSH client instances. 283 Copyright (c) 2014 IETF Trust and the persons identified as 284 authors of the code. All rights reserved. 286 Redistribution and use in source and binary forms, with or 287 without modification, is permitted pursuant to, and subject 288 to the license terms contained in, the Simplified BSD 289 License set forth in Section 4.c of the IETF Trust's 290 Legal Provisions Relating to IETF Documents 291 (http://trustee.ietf.org/license-info). 293 This version of this YANG module is part of RFC XXXX; see 294 the RFC itself for full legal notices."; 296 revision "2016-07-08" { 297 description 298 "Initial version"; 299 reference 300 "RFC XXXX: SSH Client and Server Models"; 301 } 303 feature ssh-x509-certs { 304 description 305 "The ssh-x509-certs feature indicates that the SSH 306 client supports RFC 6187"; 307 reference 308 "RFC 6187: X.509v3 Certificates for Secure Shell 309 Authentication"; 310 } 312 grouping initiating-ssh-client-grouping { 313 description 314 "A reusable grouping for a SSH client that initiates the 315 underlying TCP transport connection."; 317 container server-auth { 318 description 319 "Trusted server identities."; 321 leaf trusted-ssh-host-keys { 322 type leafref { 323 path "/kc:keychain/kc:trusted-ssh-host-keys/kc:name"; 324 } 325 description 326 "A reference to a list of SSH host keys used by the 327 SSH client to authenticate SSH server host keys. 328 A server host key is authenticate if it is an exact 329 match to a configured trusted SSH host key."; 330 } 332 leaf trusted-ca-certs { 333 if-feature ssh-x509-certs; 334 type leafref { 335 path "/kc:keychain/kc:trusted-certificates/kc:name"; 336 } 337 description 338 "A reference to a list of certificate authority (CA) 339 certificates used by the SSH client to authenticate 340 SSH server certificates."; 341 } 343 leaf trusted-server-certs { 344 type leafref { 345 path "/kc:keychain/kc:trusted-certificates/kc:name"; 346 } 347 description 348 "A reference to a list of server certificates used by 349 the SSH client to authenticate SSH server certificates. 350 A server certificate is authenticated if it is an 351 exact match to a configured trusted server certificate."; 352 } 353 } 355 container client-auth { 356 description 357 "The credentials used by the client to authenticate to 358 the SSH server."; 360 list matches { 361 key name; 362 description 363 "A matches expression, which performs like a firewall 364 rulebase in that each matches expression is considered 365 for a match before moving onto the next matches 366 expression. The first matching expression terminates 367 the search, and its 'user-auth-credentials' are used 368 to log into the SSH server."; 370 leaf name { 371 type string; 372 description 373 "An arbitrary name for this matches expression."; 374 } 375 list match { 376 key name; 377 description 378 "A match rule. The presented SSH server's host key 379 is matched against possible trusted SSH host keys 380 and certificates. If a match is found, the specified 381 'user-auth-credentials' is used to log into the 382 SSH server."; 383 leaf name { 384 type string; 385 description 386 "An arbitrary name for this match rule."; 387 } 388 leaf trusted-ssh-host-keys { 389 type leafref { 390 path "/kc:keychain/kc:trusted-ssh-host-keys/kc:name"; 391 } 392 description 393 "A test to see if the presented SSH host key 394 matches any of the host keys in the specified 395 'trusted-ssh-host-keys' list maintained by the 396 system-keychain module."; 397 } 398 leaf trusted-ca-certs { 399 type leafref { 400 path "/kc:keychain/kc:trusted-certificates/kc:name"; 401 } 402 description 403 "A test to see if the presented SSH host key matches 404 any of the trusted CA certificates in the specified 405 'trusted-certificates' list maintained by the 406 system-keychain module."; 407 } 408 leaf trusted-server-certs { 409 type leafref { 410 path "/kc:keychain/kc:trusted-certificates/kc:name"; 411 } 412 description 413 "A test to see if the presented SSH host key matches 414 any of the trusted server certificates in the specified 415 'trusted-certificates' list maintained by the 416 system-keychain module."; 417 } 419 } 420 leaf user-auth-credentials { 421 type leafref { 422 path "/kc:keychain/kc:user-auth-credentials/" 423 + "kc:user-auth-credential/kc:username"; 424 } 425 description 426 "The specific user authentication credentials to use if 427 all of the above 'match' expressions match."; 428 } 429 } 430 } 431 } // end initiating-ssh-client-grouping 433 grouping listening-ssh-client-grouping { 434 description 435 "A reusable grouping for a SSH client that does not 436 the underlying TCP transport connection have been 437 established using some other mechanism."; 438 leaf address { 439 type inet:ip-address; 440 description 441 "The IP address to listen for call-home connections on."; 442 } 443 leaf port { 444 type inet:port-number; 445 description 446 "The port number to listen for call-home connections. 447 When this grouping is used, it is RECOMMENED that 448 refine statement is used to either set a default port 449 value or to set mandatory true."; 450 } 451 uses initiating-ssh-client-grouping; 452 } 454 } 456 458 3. The SSH Server Model 460 The SSH server model presented in this section contains two YANG 461 groupings, one for a server that opens a socket to accept TCP 462 connections and another for a server that has had the TCP connection 463 opened for it already (e.g., inetd). 465 Both of these groupings reference data nodes defined by the System 466 Keychain model [draft-ietf-netconf-system-keychain]. For instance, a 467 reference to the keychain model is made to indicate which host key a 468 server should present. 470 3.1. Tree Diagram 472 The following tree diagram presents the data model for the two 473 groupings defined in the ietf-ssh-server module. 475 module: ietf-ssh-server 476 groupings: 477 listening-ssh-server-grouping 478 +---- address? inet:ip-address 479 +---- port? inet:port-number 480 +---- host-keys 481 | +---- host-key* [name] 482 | +---- name string 483 | +---- (type)? 484 | +--:(public-key) 485 | | +---- public-key? -> /kc:keychain/private-keys/priv 486 ate-key/name 487 | +--:(certificate) 488 | +---- certificate? -> /kc:keychain/private-keys/priv 489 ate-key/certificate-chains/certificate-chain/name {ssh-x509-certs}? 490 +---- client-cert-auth {ssh-x509-certs}? 491 +---- trusted-ca-certs? -> /kc:keychain/trusted-certifica 492 tes/name 493 +---- trusted-client-certs? -> /kc:keychain/trusted-certifica 494 tes/name 496 non-listening-ssh-server-grouping 497 +---- host-keys 498 | +---- host-key* [name] 499 | +---- name string 500 | +---- (type)? 501 | +--:(public-key) 502 | | +---- public-key? -> /kc:keychain/private-keys/priv 503 ate-key/name 504 | +--:(certificate) 505 | +---- certificate? -> /kc:keychain/private-keys/priv 506 ate-key/certificate-chains/certificate-chain/name {ssh-x509-certs}? 507 +---- client-cert-auth {ssh-x509-certs}? 508 +---- trusted-ca-certs? -> /kc:keychain/trusted-certifica 509 tes/name 510 +---- trusted-client-certs? -> /kc:keychain/trusted-certifica 511 tes/name 513 3.2. Example Usage 515 This section shows how it would appear if the listening-ssh-server- 516 grouping were populated with some data. This example is consistent 517 with the examples presented in Section 2.2 of 518 [draft-ietf-netconf-system-keychain]. 520 522 830 523 524 525 deployment-specific-certificate 526 ex-key-sect571r1-cert 527 528 529 530 531 532 deployment-specific-ca-certs 533 534 535 explicitly-trusted-client-certs 536 537 538 540 3.3. YANG Model 542 This YANG module has a normative references to [RFC4253], [RFC6991], 543 and [draft-ietf-netconf-system-keychain]. 545 file "ietf-ssh-server@2016-07-08.yang" 547 module ietf-ssh-server { 548 yang-version 1.1; 550 namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-server"; 551 prefix "sshs"; 553 import ietf-inet-types { 554 prefix inet; 555 reference 556 "RFC 6991: Common YANG Data Types"; 557 } 559 import ietf-system-keychain { 560 prefix kc; 561 reference 562 "RFC YYYY: System Keychain Model"; 563 } 565 organization 566 "IETF NETCONF (Network Configuration) Working Group"; 568 contact 569 "WG Web: 570 WG List: 572 WG Chair: Mehmet Ersue 573 575 WG Chair: Mahesh Jethanandani 576 578 Editor: Kent Watsen 579 "; 581 description 582 "This module defines a reusable grouping for a SSH server that 583 can be used as a basis for specific SSH server instances. 585 Copyright (c) 2014 IETF Trust and the persons identified as 586 authors of the code. All rights reserved. 588 Redistribution and use in source and binary forms, with or 589 without modification, is permitted pursuant to, and subject 590 to the license terms contained in, the Simplified BSD 591 License set forth in Section 4.c of the IETF Trust's 592 Legal Provisions Relating to IETF Documents 593 (http://trustee.ietf.org/license-info). 595 This version of this YANG module is part of RFC XXXX; see 596 the RFC itself for full legal notices."; 598 revision "2016-07-08" { 599 description 600 "Initial version"; 601 reference 602 "RFC XXXX: SSH Client and Server Models"; 603 } 605 // features 606 feature ssh-x509-certs { 607 description 608 "The ssh-x509-certs feature indicates that the NETCONF 609 server supports RFC 6187"; 610 reference 611 "RFC 6187: X.509v3 Certificates for Secure Shell 612 Authentication"; 613 } 614 // grouping 615 grouping non-listening-ssh-server-grouping { 616 description 617 "A reusable grouping for a SSH server that can be used as a 618 basis for specific SSH server instances."; 620 container host-keys { 621 description 622 "The list of host-keys the SSH server will present when 623 establishing a SSH connection."; 624 list host-key { 625 key name; 626 min-elements 1; 627 ordered-by user; 628 description 629 "An ordered list of host keys the SSH server will use to 630 construct its ordered list of algorithms, when sending 631 its SSH_MSG_KEXINIT message, as defined in Section 7.1 632 of RFC 4253."; 633 reference 634 "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; 635 leaf name { 636 type string; 637 mandatory true; 638 description 639 "An arbitrary name for this host-key"; 640 } 641 choice type { 642 description 643 "The type of host key being specified"; 644 leaf public-key { 645 type leafref { 646 path "/kc:keychain/kc:private-keys/kc:private-key/" 647 + "kc:name"; 648 } 649 description 650 "The public key is actually identified by the name of 651 its cooresponding private-key in the keychain."; 652 } 653 leaf certificate { 654 if-feature ssh-x509-certs; 655 type leafref { 656 path "/kc:keychain/kc:private-keys/kc:private-key/" 657 + "kc:certificate-chains/kc:certificate-chain/" 658 + "kc:name"; 659 } 660 description 661 "The name of a certificate in the keychain."; 663 } 664 } 665 } 666 } 668 container client-cert-auth { 669 if-feature ssh-x509-certs; 670 description 671 "A reference to a list of trusted certificate authority (CA) 672 certificates and a reference to a list of trusted client 673 certificates."; 674 leaf trusted-ca-certs { 675 type leafref { 676 path "/kc:keychain/kc:trusted-certificates/kc:name"; 677 } 678 description 679 "A reference to a list of certificate authority (CA) 680 certificates used by the SSH server to authenticate 681 SSH client certificates."; 682 } 684 leaf trusted-client-certs { 685 type leafref { 686 path "/kc:keychain/kc:trusted-certificates/kc:name"; 687 } 688 description 689 "A reference to a list of client certificates used by 690 the SSH server to authenticate SSH client certificates. 691 A clients certificate is authenticated if it is an 692 exact match to a configured trusted client certificate."; 693 } 694 } 695 } 697 grouping listening-ssh-server-grouping { 698 description 699 "A reusable grouping for a SSH server that can be used as a 700 basis for specific SSH server instances."; 701 leaf address { 702 type inet:ip-address; 703 description 704 "The IP address of the interface to listen on. The SSH 705 server will listen on all interfaces if no value is 706 specified. Please note that some addresses have special 707 meanings (e.g., '0.0.0.0' and '::')."; 708 } 709 leaf port { 710 type inet:port-number; 711 description 712 "The local port number on this interface the SSH server 713 listens on. When this grouping is used, it is RECOMMENED 714 that refine statement is used to either set a default port 715 value or to set mandatory true."; 716 } 717 uses non-listening-ssh-server-grouping; 718 } 719 } 721 723 4. Security Considerations 725 5. IANA Considerations 727 5.1. The IETF XML Registry 729 This document registers two URIs in the IETF XML registry [RFC2119]. 730 Following the format in [RFC3688], the following registrations are 731 requested: 733 URI: urn:ietf:params:xml:ns:yang:ietf-ssh-client 734 Registrant Contact: The NETCONF WG of the IETF. 735 XML: N/A, the requested URI is an XML namespace. 737 URI: urn:ietf:params:xml:ns:yang:ietf-ssh-server 738 Registrant Contact: The NETCONF WG of the IETF. 739 XML: N/A, the requested URI is an XML namespace. 741 5.2. The YANG Module Names Registry 743 This document registers two YANG modules in the YANG Module Names 744 registry [RFC6020]. Following the format in [RFC6020], the the 745 following registrations are requested: 747 name: ietf-ssh-client 748 namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-client 749 prefix: sshc 750 reference: RFC XXXX 752 name: ietf-ssh-server 753 namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-server 754 prefix: sshs 755 reference: RFC XXXX 757 6. Acknowledgements 759 The authors would like to thank for following for lively discussions 760 on list and in the halls (ordered by last name): Andy Bierman, Martin 761 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, 762 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder, Phil 763 Shafer, Sean Turner, and Bert Wijnen. 765 7. References 767 7.1. Normative References 769 [draft-ietf-netconf-system-keychain] 770 Watsen, K., "System Keychain Model", draft-ieft-netconf- 771 system-keychain-00 (work in progress), 2016, 772 . 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, 777 DOI 10.17487/RFC2119, March 1997, 778 . 780 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 781 the Network Configuration Protocol (NETCONF)", RFC 6020, 782 DOI 10.17487/RFC6020, October 2010, 783 . 785 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 786 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 787 March 2011, . 789 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 790 RFC 6991, DOI 10.17487/RFC6991, July 2013, 791 . 793 7.2. Informative References 795 [draft-ietf-netconf-call-home] 796 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 797 draft-ieft-netconf-call-home-17 (work in progress), 2015, 798 . 801 [OPENSSH] "OpenSSH", 2016, . 803 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 804 DOI 10.17487/RFC3688, January 2004, 805 . 807 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 808 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 809 January 2006, . 811 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 812 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 813 January 2006, . 815 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 816 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 817 January 2006, . 819 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 820 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 821 . 823 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 824 September 1981, . 826 Appendix A. Change Log 828 A.1. server-model-09 to 00 830 o This draft was split out from draft-ietf-netconf-server-model-09. 832 o Added in previously missing ietf-ssh-client module. 834 o Noted that '0.0.0.0' and '::' might have special meanings. 836 Appendix B. Open Issues 838 Please see: https://github.com/netconf-wg/ssh-client-server/issues. 840 Authors' Addresses 842 Kent Watsen 843 Juniper Networks 845 EMail: kwatsen@juniper.net 847 Gary Wu 848 Cisco Networks 850 EMail: garywu@cisco.com