One document matched: draft-ietf-netconf-tls-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc4741 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4741.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4642 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4642.xml'>
<!ENTITY rfc4741 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4741.xml'>
<!ENTITY rfc4742 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4742.xml'>
<!ENTITY rfc5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc5277 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5277.xml'>
<!ENTITY rfc5280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
]>
<rfc category="std" docName="draft-ietf-netconf-tls-07.txt"
ipr="trust200811">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<front>
<title abbrev="NETCONF over TLS">
NETCONF Over Transport Layer Security (TLS)
</title>
<author fullname="Mohamad Badra" initials="M."
surname="Badra">
<organization>CNRS/LIMOS Laboratory</organization>
<address>
<postal>
<street>Campus de cezeaux, Bat. ISIMA</street>
<city>Aubiere</city>
<region></region>
<code>63170</code>
<country>Fance</country>
</postal>
<email>badra@isima.fr</email>
</address>
</author>
<date month="February" year="2009" />
<area>Management</area>
<workgroup>NETCONF Working Group</workgroup>
<note title="">
<t> This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the IETF
Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside
the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. </t>
</note>
<abstract>
<t>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 secure NETCONF exchanges.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The NETCONF protocol <xref target="RFC4741"/> defines a mechanism
through which a network device can be managed. NETCONF is
connection-oriented, requiring a persistent connection between
peers. This connection must provide reliable, sequenced data
delivery, integrity and confidentiality and peers authentication.</t>
<t>This document defines "NETCONF over TLS", which includes 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, described in <xref
target="RFC5246"/>.</t>
<t>Throughout this document, the terms "client" and "server" are
used to refer to the two ends of the TLS connection. The client
actively opens the TLS connection, and the server passively
listens for the incoming TLS connection. The terms "manager" and
"agent" are used to refer to the two ends of the NETCONF protocol
session. The manager issues NETCONF remote procedure call (RPC)
commands, and the agent replies to those commands. When NETCONF
is run over TLS using the mapping defined in this document, the
client is always the manager, and the server is always the agent.</t>
<section title="Conventions Used in this Document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"></xref>.
</t>
</section>
</section>
<section title="NETCONF over TLS">
<t>
Since TLS is application protocol-independent, NETCONF can
operate on top of the TLS protocol transparently. This document
defines how NETCONF can be used within a TLS session.
</t>
<section title="Connection Initiation">
<t>The peer acting as the NETCONF manager MUST also act as the TLS
client. It MUST connect to the server that passively listens for
the incoming TLS connection on the TCP port <IANA-to-be-assigned>.
(Note to RFC Editor: please replace <IANA-to-be-assigned> with the
IANA-assigned value, and remove this note).
It MUST therefore send the TLS ClientHello message to begin the TLS
handshake. Once the TLS handshake has finished, the client and
the server MAY begin to exchange NETCONF data. In particular,
the client will send complete XML documents to the server
containing <rpc> elements, and the server will respond with
complete XML documents containing <rpc-reply> elements. The
client MAY indicate interest in receiving event notifications
from a server by creating a subscription to receive event
notifications <xref target="RFC5277"/>, in which case the server
replies to indicate whether the subscription request was
successful and, if it was successful, begins sending the event
notifications to the client as the events occur within the
system.</t>
<t>All NETCONF messages MUST be sent as TLS "application data". It
is possible that multiple NETCONF messages be contained in one
TLS record, or that a NETCONF message be transferred in multiple
TLS records.</t>
<t>This document uses the same delimiter sequence ("]]>]]>") defined
in <xref target="RFC4742"/>, which MUST be sent by both the
client and the server after each XML document in the NETCONF
exchange. Since this character sequence can legally appear in
plain XML in attribute values, comments, and processing
instructions, implementations of this document MUST ensure that
this character sequence is never part of a NETCONF message.</t>
<t>Implementation of the protocol specified in this document MAY
implement any TLS cipher suite that provides certificate-based
mutual authentication <xref target="RFC5246"/>.</t>
<t>
Implementations MUST support TLS 1.2 <xref target="RFC5246"/> and
are REQUIRED to support the mandatory to implement cipher suite,
which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed
to apply to future versions of TLS, in which case the mandatory
to implement cipher suite for the implemented version MUST be
supported.
</t>
</section>
<section title="Connection Closure">
<t>
A TLS client (NETCONF manager) MUST close the associated TLS
connection if the connection is not expected to issue any NETCONF
RPC commands later. It MUST send a TLS close_notify alert before
closing the connection. The TLS client MAY choose to not wait
for the TLS server (NETCONF agent) close_notify alert and simply
close the connection, thus generating an incomplete close on the
TLS server side. Once the TLS server gets a close_notify from
the TLS client, it MUST reply with a close_notify unless it
becomes aware that the connection has already been closed by the
TLS client (e.g., the closure was indicated by TCP).
</t>
<t>
When no data is received from a connection for a long time (where
the application decides what "long" means), a NETCONF peer MAY
close the connection. The NETCONF peer MUST attempt to initiate
an exchange of close_notify alerts with the other NETCONF peer
before closing the connection. The close_notify's sender that is
unprepared to receive any more data MAY close the connection
after sending the close_notify alert, thus generating an
incomplete close on the close_notify's receiver side.
</t>
</section>
</section>
<section title="Endpoint Authentication and Identification">
<section title="Server Identity">
<t>
During the TLS negotiation, the client MUST carefully examine the
certificate presented by the server to determine if it meets
their expectations. Particularly, the client MUST check its
understanding of the server hostname against the server's
identity as presented in the server Certificate message, in order
to prevent man-in-the-middle attacks.
</t>
<t>
Matching is performed according to the rules below (following the
example of <xref target="RFC4642"/>):
<list style="symbols">
<t>The client MUST use the server hostname it used to open the
connection (or the hostname specified in TLS "server_name"
extension <xref target="RFC5246"/>) as the value to compare
against the server name as expressed in the server
certificate. The client MUST NOT use any form of the
server hostname derived from an insecure remote source
(e.g., insecure DNS lookup). CNAME canonicalization is not
done.</t>
<t>If a subjectAltName extension of type dNSName is present in
the certificate, it MUST be used as the source of the
server's identity.</t>
<t>Matching is case-insensitive.</t>
<t>A "*" wildcard character MAY be used as the leftmost name
component in the certificate. For example, *.example.com
would match a.example.com, foo.example.com, etc., but would
not match example.com.</t>
<t>If the certificate contains multiple names (e.g., more than
one dNSName field), then a match with any one of the fields
is considered acceptable.</t>
</list>
If the match fails, the client MUST either ask for explicit user
confirmation or terminate the connection and indicate the
server's identity is suspect.
</t>
<t>
Additionally, clients MUST verify the binding between the
identity of the servers to which they connect and the public keys
presented by those servers. Clients SHOULD implement the
algorithm in Section 6 of <xref target="RFC5280"/> for general
certificate validation, but MAY supplement that algorithm with
other validation methods that achieve equivalent levels of
verification (such as comparing the server certificate against a
local store of already-verified certificates and identity bindings).
</t>
<t>
If the client has external information as to the expected
identity of the server, the hostname check MAY be omitted.
</t>
</section>
<section title="Client Identity">
<t>
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.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
The security considerations described throughout <xref target="RFC5246"/>
and <xref target="RFC4741"/> apply here as well.
</t>
<t>
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.
</t>
<t>
An attacker might be able to inject arbitrary NETCONF messages
via some application that does not carefully check exchanged
messages or deliberately insert the delimiter sequence in a
NETCONF message to create a DoS attack. Hence, applications and
NETCONF APIs MUST ensure that the delimiter sequence defined in
Section 2.1 never appears in NETCONF messages; otherwise, those
messages can be dropped, garbled or mis-interpreted. If the
delimiter sequence is found in a NETCONF message by the
sender side, a robust implementation of this document should warn
the user that illegal characters have been discovered. If the
delimiter sequence is found in a NETCONF message by the receiver
side (including any XML attribute values, XML comments or
processing instructions) a robust implementation of this document
must silently discard the message without further processing and
then stop the NETCONF session.
</t>
<t>
Finally, this document does not introduce any new security
considerations compared to <xref target="RFC4742"/>.
</t>
</section>
<section title="IANA Considerations">
<t>
IANA is requested to assign a TCP port number in the "Registered
Port Numbers" range with the name "netconf-tls". This port will
be the default port for NETCONF over TLS, as defined in this
document.
<figure>
<artwork>
<![CDATA[
Registration Contact: Mohamad Badra, badra@isima.fr.
Transport Protocol: TCP.
Port Number: TBA-by-IANA (if possible, please assign 6513).
Broadcast, Multicast or Anycast: No.
Port Name: netconf-tls.
Service Name: netconf.
Reference: draft-ietf-netconf-tls-07.
]]>
</artwork>
</figure>
</t>
</section>
<section title="Acknowledgements">
<t>
A significant amount of the text in Section 3 was lifted from
<xref target="RFC4642"/>.
</t>
<t>
The author would like to acknowledge David Harrington, Miao
Fuyou, Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson,
Olivier Coupelon, Alfred Hoenes and the NETCONF mailing list
members for their comments on the document. The author
appreciates also Bert Wijnen, Mehmet Ersue and Dan Romascanu for
their efforts on issues resolving discussion, and Charlie
Kaufman, Pasi Eronen and Tim Polk for the thorough review of this
document.
</t>
</section>
<section title="Contributor's Address">
<figure>
<artwork>
Ibrahim Hajjeh
Ineovation
France
E-mail: ibrahim.hajjeh@ineovation.fr
</artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4642;
&rfc4741;
&rfc4742;
&rfc5246;
&rfc5277;
&rfc5280;
</references>
<section title="Change Log (to be removed by RFC Editor before publication)">
<section title="06-07">
<t>
New trust boilerplate introduced.
</t>
<t>
Section 2.1: reworded the text related to the delimiter sequence and highlighted
that implementations MUST ensure that delimiter sequence is never part of a NETCONF message.
</t>
<t>
Section 2.2: Obselete RFC4366 is replaced with RFC5246.
</t>
<t>
Section 2.2: s/to issues any NETCONF commands/to issue any NETCONF commands/
</t>
<t>
Section 3.2: "Typically, the server has no external knowledge" is replaced with
"The server may have no external knowledge"
</t>
<t>
Section 4 : text added to the Security Considerations section to describe security
threads and to give recommendations on the sender and receiver behaviour in case
they detect the delimiter sequence in between a NETCONF message.
</t>
</section>
<section title="05-06">
<t>
Section 5 (IANA Considerations Section): "Anycast" is replaced with "No".
</t>
</section>
<section title="04-05">
<t>
Removed any text related to PSK based authentication.
</t>
<t>
Revised to TLS with certificate-based mutual authentication.
</t>
<t>
Removed Cipher Suite Requirements section which was redundant with TLS.
</t>
<t>
Added small clarifications to the "Introduction" and
"Endpoint Authentication and Identification" sections.
</t>
<t>
Section 2.1: Included mandatory to implement cipher suites that track
future versions of the TLS.
</t>
<t>
Section 2.2: Revised the connection closure session with regards to TLS 1.2.
</t>
<t>
Section 5: Revised to help IANA with the port assignment.
</t>
<t>
Section 8: Removed RFC4086 and RFC4279 from the reference section
</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:40:17 |