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.htmlhttp://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.