--- 1/draft-ietf-netconf-server-model-00.txt 2014-06-02 17:14:23.423912810 -0700 +++ 2/draft-ietf-netconf-server-model-01.txt 2014-06-02 17:14:23.475914036 -0700 @@ -1,19 +1,19 @@ NETCONF Working Group K. Watsen Internet-Draft Juniper Networks Intended status: Standards Track J. Schoenwaelder -Expires: November 02, 2014 Jacobs University Bremen - May 2014 +Expires: December 03, 2014 Jacobs University Bremen + June 2014 NETCONF Server Configuration Model - draft-ietf-netconf-server-model-00 + draft-ietf-netconf-server-model-01 Abstract This draft defines a NETCONF server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports it supports, what ports they listen on, whether they support device-initiated connections, and associated parameters. Status of This Memo @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 02, 2014. + This Internet-Draft will expire on December 03, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,43 +58,44 @@ 2.2. Align Transport-Specific Configurations . . . . . . . . . 4 2.3. Support both Listening for Connections and Call Home . . 4 2.4. For Call Home Connections . . . . . . . . . . . . . . . . 4 2.4.1. Support More than One Application . . . . . . . . . . 4 2.4.2. Support Applications Having More than One Server . . 4 2.4.3. Support a Reconnection Strategy . . . . . . . . . . . 4 2.4.4. Support both Persistent and Periodic Connections . . 5 2.4.5. Reconnection Strategy for Periodic Connections . . . 5 2.4.6. Keep-Alives for Persistent Connections . . . . . . . 5 2.4.7. Customizations for Periodic Connections . . . . . . . 5 - 3. Keep-Alives for SSH and TLS . . . . . . . . . . . . . . . . . 6 - 3.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4. Support for Virtual Routing and Forwarding . . . . . . . . . 7 - 5. The "ietf-netconf-server" Data Model . . . . . . . . . . . . 7 - 5.1. The "listen" Grouping . . . . . . . . . . . . . . . . . . 7 - 5.2. The "call-home" Grouping . . . . . . . . . . . . . . . . 8 - 6. The "ietf-system-tls-auth" Data Model . . . . . . . . . . . . 9 - 7. The "ietf-netconf-server" YANG Module . . . . . . . . . . . . 9 - 8. The "ietf-system-tls-auth" YANG Module . . . . . . . . . . . 18 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 - 12.2. Informative References . . . . . . . . . . . . . . . . . 25 - Appendix A. Example: SSH Transport Configuration . . . . . . . . 25 - Appendix B. Example: TLS Transport Configuration . . . . . . . . 26 - Appendix C. Example: TLS Authentication Configuration . . . . . 27 - Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 28 - D.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 28 - - Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . 28 + 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Keep-Alives for SSH and TLS . . . . . . . . . . . . . . . . . 16 + 4.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. User Authentication for TLS . . . . . . . . . . . . . . . . . 17 + 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 17 + 5.2. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 + 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 10.2. Informative References . . . . . . . . . . . . . . . . . 26 + Appendix A. Example: SSH Transport Configuration . . . . . . . . 26 + Appendix B. Example: TLS Transport Configuration . . . . . . . . 27 + Appendix C. Example: TLS Authentication Configuration . . . . . 28 + Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 29 + D.1. I-D to 00 . . . . . . . . . . . . . . . . . . . . . . . . 29 + D.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 29 + Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . 29 1. Introduction This draft defines a NETCONF [RFC6241] server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports are supported, what ports does the server listen on, whether call-home is supported, and associated parameters. 1.1. Terminology @@ -231,77 +232,23 @@ to it. A common communication pattern is that one data transmission is many times closely followed by another. For instance, if the device needs to send a notification message, there's a high probability that it will send another shortly thereafter. Likewise, the application may have a sequence of pending messages to send. Thus, it should be possible for a device to hold a connection open until some amount of time of no data being transmitted as transpired. -3. Keep-Alives for SSH and TLS - - One the objectives listed above, Keep-Alives for Persistent - Connections (Section 2.4.6) indicates a need for a "keep-alive" - mechanism. This section specifies how the NETCONF keep-alive - mechanism is to be implemented. - - Both SSH and TLS have the ability to support keep-alives. Using - these mechanisms, the keep-alive messages are sent inside the - encrypted tunnel, thus thwarting spoof attacks. - -3.1. SSH - - The SSH keep-alive solution that is expected to be used when - configured using the data model defined in this document is - ubiquitous in practice, though never being explicitly defined in an - RFC. The strategy used is to purposely send a malformed request - message with a flag set to ensure a response. More specifically, per - section 4 of [RFC4253], either SSH peer can send a - SSH_MSG_GLOBAL_REQUEST message with "want reply" set to '1' and that, - if there is an error, will get back a SSH_MSG_REQUEST_FAILURE - response. Similarly, section 5 of [RFC4253] says that either SSH - peer can send a SSH_MSG_CHANNEL_REQUEST message with "want reply" set - to '1' and that, if there is an error, will get back a - SSH_MSG_CHANNEL_FAILURE response. - - To ensure that the request will fail, current implementations send an - invalid "request name" or "request type", respectively. Abiding to - the extensibility guidelines specified in Section 6 of [RFC4251], - these implementations use the "name@domain". For instance, when - configured to send keep-alives, OpenSSH sends the string - "keepalive@openssh.com". In order to remain compatible with existing - implementations, this draft does not require a specific "request - name" or "request type" string be used. - -3.2. TLS - - The TLS keep-alive solution is defined in [RFC6520]. This solution - allows both peers to advertise if they can receive heartbeat request - messages from its peer. For standard NETCONF over TLS connections, - devices SHOULD advertise "peer_allowed_to_send", as per [RFC6520]. - This advertisement is not a "MUST" in order to grandfather existing - NETCONF over TLS implementations. For NETCONF over TLS Call Home, - the network management system MUST advertise "peer_allowed_to_send" - per [RFC6520]. This is a "MUST" so as to ensure devices can depend - in it always being there for call home connections, which is - conveniently when keep-alives are needed the most. - -4. Support for Virtual Routing and Forwarding - - The YANG module define herein does not itself support virtual routing - and forwarding (VRF). It is expected that other modules with augment - in a VRF designation when needed. - -5. The "ietf-netconf-server" Data Model +3. Data Model -5.1. The "listen" Grouping +3.1. Overview To enable transports to configure listening on one or more ports in a common way, this grouping is defined. This grouping defines SSH and TLS specific containers, each of which refines the default listening port appropriately. Further, each of these transport specific containers use a feature statement, enabling NETCONF servers to accurately advertise what they support. module: ietf-netconf-server +--rw netconf-server @@ -316,22 +263,20 @@ | +--rw port? inet:port-number +--rw tls {tls-listen}? +--rw (one-or-many)? +--:(one-port) | +--rw port? inet:port-number +--:(many-ports) +--rw interface* [address] +--rw address inet:host +--rw port? inet:port-number -5.2. The "call-home" Grouping - To enable transports to configure initiating connections to remote applications in a common way, this grouping is defined. This grouping configures a list of network-managers, each with some transport-specific configuration augmented in. Each of the transport specific containers use a feature statement, enabling NETCONF servers to accurately advertise what they support. module: ietf-netconf-server +--rw netconf-server +--rw call-home @@ -358,60 +303,37 @@ | | +--rw count-max? uint8 | +--:(periodic-connection) | +--rw periodic | +--rw timeout-mins? uint8 | +--rw linger-secs? uint8 +--rw reconnect-strategy +--rw start-with? enumeration +--rw interval-secs? uint8 +--rw count-max? uint8 -6. The "ietf-system-tls-auth" Data Model - - This data model augments the "ietf-system" module defined in - [draft-ietf-netmod-system-mgmt] by adding some configuration nodes - under its "/system/authentication" subtree. - - module: ietf-system-tls-auth - augment /sys:system/sys:authentication: - +--rw tls - +--rw cert-maps {tls-map-certificates}? - | +--rw cert-to-name* [id] - | +--rw id uint32 - | +--rw fingerprint x509c2n:tls-fingerprint - | +--rw map-type identityref - | +--rw name string - +--rw psk-maps {tls-map-pre-shared-keys}? - +--rw psk-map* [psk-identity] - +--rw psk-identity string - +--rw user-name nacm:user-name-type - +--rw not-valid-before? yang:date-and-time - +--rw not-valid-after? yang:date-and-time - +--rw key yang:hex-string - -7. The "ietf-netconf-server" YANG Module +3.2. YANG Module This YANG module imports YANG types from [RFC6991]. RFC Ed.: update the date below with the date of RFC publication and remove this note. - file "ietf-system-tls-auth.@2014-05-16.yang" + file "ietf-netconf-server.@2014-05-16.yang" module ietf-netconf-server { + namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server"; prefix "ncserver"; import ietf-inet-types { prefix inet; // RFC 6991 } - organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Mehmet Ersue @@ -804,35 +723,124 @@ } container call-home { uses call-home-config; } } } -8. The "ietf-system-tls-auth" YANG Module +4. Keep-Alives for SSH and TLS + + One the objectives listed above, Keep-Alives for Persistent + Connections (Section 2.4.6) indicates a need for a "keep-alive" + mechanism. This section specifies how the NETCONF keep-alive + mechanism is to be implemented. + + Both SSH and TLS have the ability to support keep-alives. Using + these mechanisms, the keep-alive messages are sent inside the + encrypted tunnel, thus thwarting spoof attacks. + +4.1. SSH + + The SSH keep-alive solution that is expected to be used when + configured using the data model defined in this document is + ubiquitous in practice, though never being explicitly defined in an + RFC. The strategy used is to purposely send a malformed request + message with a flag set to ensure a response. More specifically, per + section 4 of [RFC4253], either SSH peer can send a + SSH_MSG_GLOBAL_REQUEST message with "want reply" set to '1' and that, + if there is an error, will get back a SSH_MSG_REQUEST_FAILURE + response. Similarly, section 5 of [RFC4253] says that either SSH + peer can send a SSH_MSG_CHANNEL_REQUEST message with "want reply" set + to '1' and that, if there is an error, will get back a + SSH_MSG_CHANNEL_FAILURE response. + + To ensure that the request will fail, current implementations send an + invalid "request name" or "request type", respectively. Abiding to + the extensibility guidelines specified in Section 6 of [RFC4251], + these implementations use the "name@domain". For instance, when + configured to send keep-alives, OpenSSH sends the string + "keepalive@openssh.com". In order to remain compatible with existing + implementations, this draft does not require a specific "request + name" or "request type" string be used. + +4.2. TLS + + The TLS keep-alive solution is defined in [RFC6520]. This solution + allows both peers to advertise if they can receive heartbeat request + messages from its peer. For standard NETCONF over TLS connections, + devices SHOULD advertise "peer_allowed_to_send", as per [RFC6520]. + This advertisement is not a "MUST" in order to grandfather existing + NETCONF over TLS implementations. For NETCONF over TLS Call Home, + the network management system MUST advertise "peer_allowed_to_send" + per [RFC6520]. This is a "MUST" so as to ensure devices can depend + in it always being there for call home connections, which is + conveniently when keep-alives are needed the most. + +5. User Authentication for TLS + +5.1. Introduction + + The NETCONF Server Module defined in this draft focuses on the + configuration the SSH and TLS transports. This module does not + define a means to configure User Authentication, as that is a stated + focus for [draft-ietf-netmod-system-mgmt], however, that draft does + not define configuration nodes for TLS client authentication. Thus, + this draft also includes the following YANG module to augment TLS + client authentication into the "ietf-system" module defined in + [draft-ietf-netmod-system-mgmt]. + +5.2. Data Model Overview + + This data model augments the "ietf-system" module defined in + [draft-ietf-netmod-system-mgmt] by adding some configuration nodes + under its "/system/authentication" subtree. + + module: ietf-system-tls-auth + augment /sys:system/sys:authentication: + +--rw tls + +--rw trusted-ca-certs + | +--rw trusted-ca-cert* binary + +--rw trusted-client-certs + | +--rw trusted-client-cert* binary + +--rw cert-maps {tls-map-certificates}? + | +--rw cert-to-name* [id] + | +--rw id uint32 + | +--rw fingerprint x509c2n:tls-fingerprint + | +--rw map-type identityref + | +--rw name string + +--rw psk-maps {tls-map-pre-shared-keys}? + +--rw psk-map* [psk-identity] + +--rw psk-identity string + +--rw user-name nacm:user-name-type + +--rw not-valid-before? yang:date-and-time + +--rw not-valid-after? yang:date-and-time + +--rw key yang:hex-string + +5.3. YANG Module This YANG module imports YANG extensions from [RFC6536], and imports YANG types from [RFC6991] and a YANG grouping from [I-D.ietf-netmod-snmp-cfg]. RFC Ed.: update the date below with the date of RFC publication and remove this note. - file "ietf-netconf-server.@2014-05-16.yang" + file "ietf-system-tls-auth.@2014-05-16.yang" module ietf-system-tls-auth { namespace "urn:ietf:params:xml:ns:yang:ietf-system-tls-auth"; prefix "system-tls-auth"; + import ietf-system { // draft-ietf-netmod-system-mgmt prefix "sys"; } import ietf-netconf-acm { prefix nacm; // RFC 6536 } import ietf-yang-types { prefix yang; // RFC 6991 } import ietf-x509-cert-to-name { @@ -896,20 +904,66 @@ } feature tls-map-pre-shared-keys { description "The tls-map-pre-shared-keys feature indicates that the NETCONF server implements mapping TLS pre-shared keys to NETCONF usernames."; } grouping tls-global-config { + + container trusted-ca-certs { + description + "A list of Certificate Authority (CA) certificates that a + NETCONF server can use to authenticate a NETCONF client's + certificate. A client's certificate is authenticated if + its Issuer matches one of the configured trusted CA + certificates."; + leaf-list trusted-ca-cert { + type binary; + ordered-by system; + description + "The binary certificate structure, as + specified by RFC 5246, Section 7.4.6, i.e.,: + + opaque ASN.1Cert<1..2^24>; + + "; + reference + "RFC 5246: The Transport Layer Security (TLS) + Protocol Version 1.2"; + } + } + + container trusted-client-certs { + description + "A list of client certificates that a NETCONF server can + use to authenticate a NETCONF client's certificate. A + client's certificate is authenticated if it is an exact + match to one of the configured trusted client certificates."; + leaf-list trusted-client-cert { + type binary; + ordered-by system; + description + "The binary certificate structure, as + specified by RFC 5246, Section 7.4.6, i.e.,: + + opaque ASN.1Cert<1..2^24>; + + "; + reference + "RFC 5246: The Transport Layer Security (TLS) + Protocol Version 1.2"; + } + } + // Objects for deriving NETCONF usernames from X.509 // certificates. container cert-maps { if-feature tls-map-certificates; uses x509c2n:cert-to-name; description "The cert-maps container is used by a NETCONF server to map the NETCONF client's presented X.509 certificate to a NETCONF username. @@ -977,35 +1030,31 @@ nacm:default-deny-all; description "The key associated with the PSK identity"; reference "RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)"; } } } } - augment "/sys:system/sys:authentication" { container tls { uses tls-global-config; - // leaf test { - // type string; - // } } } } -9. Security Considerations +6. Security Considerations The YANG modules defined in this memo are designed to be accessed via the NETCONF protocol [RFC6241]. Authorization for access to specific portions of conceptual data and operations within this module is provided by the NETCONF access control model (NACM) [RFC6536]. There are a number of data nodes defined in the "ietf-netconf-server" and "ietf-system-tls-auth" YANG modules which are writable/creatable/ deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network @@ -1022,21 +1071,21 @@ o /system/authentication/tls/psk-maps/psk-map/user-name: This leaf node contains a user name that some deployments may consider sensitive information. o /system/authentication/tls/psk-maps/psk-map/key: This leaf node contains a shared key that remote clients use to authenticate themselves to the system. This value should not be readable or writable by anyone by default. -10. IANA Considerations +7. IANA Considerations This document registers two URIs in the IETF XML registry [RFC2119]. Following the format in [RFC3688], the following registrations are requested: URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-system-tle-auth @@ -1049,34 +1098,40 @@ name: ietf-netconf-server namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server prefix: ncserver reference: RFC XXXX name: ietf-system-tls-auth namespace: urn:ietf:params:xml:ns:yang:ietf-system-tls-auth prefix: sys-tls-auth reference: RFC XXXX -11. Acknowledgements +8. Other Considerations + + The YANG module define herein does not itself support virtual routing + and forwarding (VRF). It is expected that external modules will + augment in VRF designations when needed. + +9. Acknowledgements The authors would like to thank for following for lively discussions on list and in the halls (ordered by last name): Andy Bierman, Martin Bjorklund, Benoit Claise, David Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch, and Phil Shafer. Juergen Schoenwaelder and was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme. -12. References +10. References -12.1. Normative References +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels ", BCP 14, RFC 2119, March 1997. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture ", RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol ", RFC 4253, January 2006. @@ -1115,21 +1170,21 @@ [draft-ieft-netconf-reverse-ssh] Watsen, K., "NETCONF over SSH Call Home ", draft-ieft- netconf-reverse-ssh-00 (work in progress), May 2014. [draft-ietf-netmod-system-mgmt] Bierman, A., "A YANG Data Model for System Management ", draft-ieft-netmod-system-mgmt-16 (work in progress), May 2014. -12.2. Informative References +10.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. Appendix A. Example: SSH Transport Configuration 831 @@ -1227,20 +1282,35 @@ Appendix C. Example: TLS Authentication Configuration + + + QW4gRWFzdGVyIGVnZywgZm9yIHRob3NlIHdobyBtaWdodCBsb29rICA6KQo= + + + + + + SSBhbSB0aGUgZWdnIG1hbiwgdGhleSBhcmUgdGhlIGVnZyBtZW4uCg== + + + SSBhbSB0aGUgd2FscnVzLCBnb28gZ29vIGcnam9vYi4K + + + 1 11:0A:05:11:00 x509c2n:san-any 2 11:0A:05:11:00 x509c2n:specified @@ -1275,20 +1343,27 @@ o Added section "Keep-Alives for SSH and TLS" o Updated the Security Considerations section o Added text for supporting VRFs via augments o Factored the TLS-AUTH config into another module augmenting the "ietf-system" module +D.2. 00 to 01 + + o Restructured document so it flows better + + o Added trusted-ca-certs and trusted-client-certs objects into the + ietf-system-tls-auth module + Appendix E. Open Issues o NETCONF implementations typically have config parameters such as session timeouts or hello timeouts. Shall they be included in this model? o Do we need knobs to enable/disable call-home without the need to remove all the call-home client configuration? Authors' Addresses