Protocol Action: 'NETCONF Over Transport Layer Security (TLS)' to Proposed Standard

[The IESG <[e-mail]>]

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.