NETCONF over Transport Layer Security (TLS)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, netconf mailing list <email@example.com>, netconf chair <firstname.lastname@example.org> Subject: Protocol Action: 'NETCONF Over Transport Layer Security (TLS)' to Proposed Standard The IESG has approved the following document: - 'NETCONF Over Transport Layer Security (TLS) ' <draft-ietf-netconf-tls-07.txt> as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt
Technical Summary The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to provide a secure connection for the transport of NETCONF messages. The mechanisms defined in this document include the support for certificate-based mutual authentication and key derivation, utilizing the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS (Transport Layer Security) protocol. Working Group Summary Many WG member were thinking that password-based authentication is already handled well enough by the existing NETCONF transports (SSH and BEEP), and the NETCONF-over- TLS specification does not need to handle passwords. It has been recommended to scope the document to certificate- based authentication. There was also some controversy on the use of pre-shared keys (PSKs) derived from passwords. Based on this dicussion the Working Group decided to remove the text related to PSK based- authentication. See http://www.ietf.org/mail-archive/web/netconf/current/msg03856.html There was some controversal discussion about the Connection Closure. The consensus was that the document adopts the closure mechanism from draft-ietf-syslog-transport-tls-, Section 4.4. There was also some controversy about the use of a dedicated port of NETCONF over TLS. The consensus was that a dedicated port should be requested. The summary of the last changes can be found in: http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html There were many WG members who did not strongly support or object to the document. Nobody objected to the document during or after the WGLC. The level of review in the WG was adequate , with several independent reviews by WG members. There is WG consensus to publish the document. Document Quality No vendors have announced that they will utilize this protocol. Two implementations with independent code-base and initiated by the document author are available as open source. The author ensures that the two implementations have been tested as interoperable. Personnel The document was reviewed by Eric Rescorla, Juergen Schoenwaelder, David Harrington, the WG security advisor Charlie Kaufman, and the security ADs Pasi Eronen and Tim Polk. Mehmet Ersue is the document shepherd, and Dan Romascanu the shepherding AD. RFC Editor Note Please make the following changes to draft-07: 1. In Section 2.1: OLD: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. NEW: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. The server MUST support certificate-based client authentication. 2. In Section 3.2 OLD: The server may have no external knowledge on client's identity and identity checks might not be possible (unless the client has a certificate chain rooted in an appropriate CA). If a server has knowledge on client's identity (typically from some source external to NETCONF or TLS) it MUST check the identity as described above. NEW: The server MUST verify the identity of the client with certificate-based authentication and according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. 3. In Section 4: OLD: This document in its current version does not support third party authentication due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third party authentication is needed, BEEP or SSH transport can be used. NEW: This document in its current version does not support third party authentication (e.g., backend AAA servers) due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third party authentication is needed, BEEP or SSH transport can be used. 4. Please create an Informative References section and move RFC4642 and RFC5277 from the Normative References section to this new section.