One document matched: draft-ietf-netconf-rfc5539bis-10.xml
<?xml version="1.0" encoding="US-ASCII" ?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc5539 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5539.xml'>
<!ENTITY rfc6241 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml'>
<!ENTITY rfc6353 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6353.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4742 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4742.xml'>
<!ENTITY rfc6242 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.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'>
<!ENTITY rfc4279 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml'>
<!ENTITY rfc6125 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml'>
<!ENTITY rfc6335 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml'>
<!ENTITY rfc7407 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7407.xml'>
<!ENTITY I-D.ietf-uta-tls-bcp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-uta-tls-bcp">
<!ENTITY I-D.ietf-netconf-server-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-server-model">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-netconf-rfc5539bis-10" ipr="trust200902" obsoletes = "5539">
<front>
<title abbrev="NETCONF over TLS">
Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication
</title>
<author fullname="Mohamad Badra" initials="M."
surname="Badra">
<organization>Zayed University</organization>
<address>
<email>mbadra@gmail.com</email>
</address>
</author>
<author fullname="Alan Luchuk" initials="A."
surname="Luchuk">
<organization>SNMP Research, Inc.</organization>
<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920</code>
<country>USA</country>
</postal>
<phone>+1 865 573 1434</phone>
<email>luchuk@snmp.com</email>
<uri>http://www.snmp.com/</uri>
</address>
</author>
<author fullname="Juergen Schoenwaelder" initials="J."
surname="Schoenwaelder">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>28759 Bremen</city>
<country>Germany</country>
</postal>
<phone>+49 421 200 3587</phone>
<email>j.schoenwaelder@jacobs-university.de</email>
<uri>http://www.jacobs-university.de/</uri>
</address>
</author>
<date year="2015" />
<area>Management</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>NETCONF</keyword>
<keyword>TLS</keyword>
<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 with mutual X.509 authentication to
secure the exchange of NETCONF messages. This revision of RFC
5539 documents the new message framing used by NETCONF 1.1 and
it obsoletes RFC 5539.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The NETCONF protocol <xref target="RFC6241"/> 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
integrity, confidentiality, peer authentication, and reliable,
sequenced data delivery.
</t>
<t>
This document defines how NETCONF messages can be exchanged over
Transport Layer Security (TLS) <xref target="RFC5246"/>.
Implementations MUST support mutual TLS certificate-based
authentication <xref target="RFC5246"/>. This assures the
NETCONF server of the identity of the principal who wishes to
manipulate the management information. It also assures the
NETCONF client of the identity of the server for which it wishes
to manipulate the management information.
</t>
<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 title="Connection Initiation" anchor="initiation">
<t>
The peer acting as the NETCONF client MUST act as the TLS
client. The TLS client actively opens the TLS connection and
the TLS server passively listens for the incoming TLS
connections. The well-known TCP port number 6513 is used by
NETCONF servers to listen for TCP connections established by
NETCONF over TLS clients. The TLS client MUST send the TLS
ClientHello message to begin the TLS handshake. The TLS server
MUST send a CertificateRequest in order to request a certificate
from the TLS client. Once the TLS handshake has finished, the
client and the server MAY begin to exchange NETCONF messages.
Client and server identity verification is done before the
NETCONF <hello> message is sent. This means that the
identity verification is completed before the NETCONF session is
started.
</t>
</section>
<section title="Message Framing" anchor="framing">
<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>
The previous version <xref target="RFC5539"/> of this document
used the framing sequence defined in <xref target="RFC4742"/>,
under the assumption that it could not be found in well-formed
XML documents. However, this assumption is not correct <xref
target="RFC6242"/>. In order to solve this problem, this
document adopts the framing protocol defined in <xref
target="RFC6242"/> as follows:
</t>
-->
<t>
The previous version of this document <xref target="RFC5539"/>
used the framing sequence defined in <xref target="RFC4742"/>.
This version aligns with <xref target="RFC6242"/> and adopts the
framing protocol defined in <xref target="RFC6242"/> as follows:
</t>
<t>
The NETCONF <hello> message MUST be followed by the
character sequence ]]>]]>. Upon reception of the
<hello> message, the peers inspect the announced
capabilities. If the :base:1.1 capability is advertised by both
peers, the chunked framing mechanism defined in Section 4.2 of
<xref target="RFC6242"/> is used for the remainder of the
NETCONF session. Otherwise, the old end-of-message-based
mechanism (see Section 4.3 of <xref target="RFC6242"/>) is used.
</t>
</section>
<section title="Connection Closure">
<t>
A NETCONF server will process NETCONF messages from the NETCONF
client in the order in which they are received. A NETCONF
session is closed using the <close-session> operation.
When the NETCONF server processes a <close-session>
operation, the NETCONF server SHALL respond and close the TLS
session as described in Section 7.2.1 of <xref
target="RFC5246"/>.
</t>
</section>
<section title="Certificate Validation">
<t>
Both peers MUST use X.509 certificate path validation <xref
target="RFC5280"/> to verify the integrity of the certificate
presented by the peer. The presented X.509 certificate may also
be considered valid if it matches one obtained by another
trusted mechanism, such as using a locally configured
certificate fingerprint. If X.509 certificate path validation
fails and the presented X.509 certificate does not match a
certificate obtained by a trusted mechanism, the connection MUST
be terminated as defined in <xref target="RFC5246"/>.
</t>
</section>
<section title="Server Identity">
<!--
<t>
The NETCONF client MUST carefully examine the certificate
presented by the NETCONF server to determine if it meets the
client's expectations. In particular, the NETCONF client MUST
check its understanding of the NETCONF server's reference
identifier (e.g., its hostname) against the server's presented
identity encoded in the certificate presented by the server, in
order to prevent man-in-the-middle attacks <xref
target="RFC6125"/>. If the NETCONF client has external
information as to the expected presented identity of the NETCONF
server, the check of the presented identity against the
reference identity MAY be omitted.
</t>
<t>
Matching is performed according to the rules and guidelines
defined in <xref target="RFC6125"/>. If the match fails, the
NETCONF client MUST either ask for explicit user confirmation or
terminate the connection and indicate the NETCONF server's
identity is suspect.
</t>
-->
<t>
The NETCONF client MUST check the identity of the server
according to Section 6 of <xref target="RFC6125"/>.
</t>
</section>
<section title="Client Identity" anchor="identity">
<t>
The NETCONF server MUST verify the identity of the NETCONF
client to ensure that the incoming request to establish a
NETCONF session is legitimate before the NETCONF session is
started.
</t>
<t>
The NETCONF protocol <xref target="RFC6241"/> requires that the
transport protocol's authentication process results in an
authenticated NETCONF client identity whose permissions are
known to the server. The authenticated identity of a client is
commonly referred to as the NETCONF username. The following
algorithm is used by the NETCONF server to derive a NETCONF
username from a certificate. (Note that the algorithm below is
the same as the one described in the SNMP-TLS-TM-MIB MIB module
defined in <xref target="RFC6353"/> and in the
ietf-x509-cert-to-name YANG module defined in <xref
target="RFC7407"/>.)
<list style="format (%c)">
<t>
The server maintains an ordered list of mappings of
certificates to NETCONF usernames. Each list entry contains
<list style="symbols">
<t>a certificate fingerprint (used for matching the
presented certificate),</t>
<t>a map type (indicates how the NETCONF username is
derived from the certificate), and</t>
<t>optional auxiliary data (used to carry a NETCONF
username if the map type indicates the user name is
explicitly configured).</t>
</list>
</t>
<t>
The NETCONF username is derived by considering each list
entry in order. The fingerprint member of the current list
entry determines whether the current list entry is a match:
<list style="numbers">
<t>
If the list entry's fingerprint value matches the
fingerprint of the presented certificate, then consider
the list entry as a successful match.
</t>
<t>
If the list entry's fingerprint value matches that of a
locally held copy of a trusted CA certificate, and that
CA certificate was part of the CA certificate chain to
the presented certificate, then consider the list entry
as a successful match.
</t>
</list>
</t>
<t>
Once a matching list entry has been found, the map type of
the current list entry is used to determine how the username
associated with the certificate should be
determined. Possible mapping options are:
<list style="letters">
<t>
The username is taken from the auxiliary data of the
current list entry. This means the username is
explicitely configured (map type 'specified').
</t>
<t>
The subjectAltName's rfc822Name field is mapped to the
username (map type 'san-rfc822-name'). The local part of
the rfc822Name is used unaltered but the host-part of
the name must be converted to lowercase.
</t>
<t>
The subjectAltName's dNSName is mapped to the username
(map type 'san-dns-name'). The characters of the dNSName
are converted to lowercase.
</t>
<t>
The subjectAltName's iPAddress is mapped to the username
(map type 'san-ip-address'). IPv4 addresses are
converted into decimal-dotted quad notation (e.g.,
'192.0.2.1'). IPv6 addresses are converted into a
32-character all lowercase hexadecimal string without
any colon separators.
</t>
<t>
Any of the subjectAltName's rfc822Name, dNSName,
iPAddress is mapped to the username (map type
'san-any'). The first matching subjectAltName value
found in the certificate of the above types MUST be used
when deriving the name.
</t>
<t>
The certificate's CommonName is mapped to the username
(map type 'common-name'). The CommonName is converted to
UTF-8 encoding. The usage of CommonNames is deprecated
and users are encouraged to use subjectAltName mapping
methods instead.
</t>
</list>
</t>
<t>
If it is impossible to determine a username from the list
entry's data combined with the data presented in the
certificate, then additional list entries MUST be searched
looking for another potential match. Similarily, if the
username does not comply to the NETCONF requirements on
usernames <xref target="RFC6241"/>, then additional list
entries MUST be searched looking for another potential
match. If there are no further list entries, the TLS
session MUST be terminated.
</t>
</list>
</t>
<t>
The username provided by the NETCONF over TLS implementation
will be made available to the NETCONF message layer as the
NETCONF username without modification.
</t>
<t>
The NETCONF server configuration data model <xref
target="I-D.ietf-netconf-server-model"/> covers NETCONF over TLS
and provides further details such as certificate fingerprint
formats exposed to network configuration systems.
</t>
</section>
<section title="Cipher Suites">
<t>
Implementations MUST support TLS 1.2 <xref target="RFC5246"/>
and are REQUIRED to support the mandatory-to-implement cipher
suite. Implementations MAY implement additional TLS cipher
suites that provide mutual authentication <xref
target="RFC5246"/> and confidentiality as required by NETCONF
<xref target="RFC6241"/>. Implementations SHOULD follow the
recommendations given in <xref target="I-D.ietf-uta-tls-bcp"/>.
</t>
</section>
<section title="Security Considerations">
<t>
NETCONF is used to access configuration and state information
and to modify configuration information, so the ability to
access this protocol should be limited to users and systems that
are authorized to view the NETCONF server's configuration and
state or to modify the NETCONF server's configuration.
</t>
<t>
Configuration or state data may include sensitive information,
such as usernames or security keys. So, NETCONF requires
communications channels that provide strong encryption for data
privacy. This document defines a NETCONF over TLS mapping that
provides for support of strong encryption and authentication.
The security considerations for TLS <xref target="RFC5246"/> and
NETCONF <xref target="RFC6241"/> apply here as well.
</t>
<t>
NETCONF over TLS requires mutual authentication. Neither side
should establish a NETCONF over TLS connection with an unknown,
unexpected, or incorrect identity on the opposite side. Note
that the decision whether a certificate presented by the client
is accepted can depend on whether a trusted CA certificate is
white listed (see <xref target="identity"/>). If deployments
make use of this option, it is recommended that the white listed
CA certificate is used only to issue certificates that are used
for accessing NETCONF servers. Should the CA certificate be used
to issue certificates for other purposes, then all certificates
created for other purposes will be accepted by a NETCONF server
as well, which is likely not suitable.
</t>
<t>
This document does not support third-party authentication (e.g.,
backend Authentication, Authorization, and Accounting (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, the SSH transport <xref
target="RFC6242"/> can be used.
</t>
<t>
RFC 5539 assumes that the end-of-message (EOM) sequence,
]]>]]>, cannot appear in any well-formed XML document,
which turned out to be mistaken. The EOM sequence can cause
operational problems and open space for attacks if sent
deliberately in NETCONF messages. It is however believed that
the associated threat is not very high. This document still
uses the EOM sequence for the initial <hello> message to
avoid incompatibility with existing implementations. When both
peers implement :base:1.1 capability, a proper framing protocol
(chunked framing mechanism; see <xref target="framing"/>) is
used for the rest of the NETCONF session, to avoid injection
attacks.
</t>
</section>
<section title="IANA Considerations">
<t>
Based on the previous version of this document, RFC 5539, IANA
has assigned a TCP port number (6513) in the "Registered Port
Numbers" range with the service name "netconf-tls". This port
will be the default port for NETCONF over TLS, as defined in
<xref target="initiation"/>. Below is the registration
template following the rules in <xref target="RFC6335"/>.
<figure>
<artwork>
<![CDATA[
Service Name: netconf-tls
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: NETCONF over TLS
Reference: RFC XXXX
Port Number: 6513
]]>
</artwork>
</figure>
</t>
<t>
<cref source="JS">
RFC Editor: Please replace XXXX above with the allocated RFC
number and remove this comment.
</cref>
</t>
</section>
<section title="Acknowledgements">
<t>
The authors like to acknowledge Martin Bjorklund, Olivier
Coupelon, Mehmet Ersue, Stephen Farrell, Miao Fuyou, Ibrahim
Hajjeh, David Harrington, Sam Hartman, Alfred Hoenes, Simon
Josefsson, Barry Leiba, Tom Petch, Eric Rescorla, Dan Romascanu,
Kent Watsen, Bert Wijnen, Stefan Winter and the NETCONF mailing
list members for their comments on this document. Charlie
Kaufman, Pasi Eronen, and Tim Polk provided a thorough review of
previous versions of this document.
</t>
<t>
Juergen Schoenwaelder was partly funded by Flamingo, a
Network of Excellence project (ICT-318488) supported by the
European Commission under its Seventh Framework Programme.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6241;
&rfc6242;
<!-- &rfc4279; -->
&rfc5246;
&rfc5280;
&rfc6125;
&rfc6335;
&I-D.ietf-uta-tls-bcp;
</references>
<references title="Informative References">
&rfc4742;
&rfc5539;
&rfc6353;
&rfc7407;
&I-D.ietf-netconf-server-model;
</references>
<section title="Changes from RFC 5539">
<t>
This section summarizes major changes between this document and
RFC 5539.
<list style="symbols">
<t>
Documented that NETCONF over TLS uses the new message
framing if both peers support the :base:1.1 capability.
</t>
<t>
Removed redundant text that can be found in the TLS and
NETCONF specifications and restructured the text. Alignment
with <xref target="RFC6125"/>.
</t>
<t>
Added a high-level description how NETCONF usernames are
derived from certificates.
</t>
<t>
Removed the reference to BEEP.
</t>
</list>
</t>
</section>
<!--
<section title="Change Log">
<t>
<cref source="JS">
RFC Editor: Please remove this appendix before publication.
</cref>
</t>
<section title="draft-ietf-netconf-rfc5539bis-07">
<t>
<list style="symbols">
<t>
Limited the scope of the document to TLS with mutual X.509
authentication.
</t>
<t>
Added a high-level description how NETCONF usernames are
extracted from certificates.
</t>
<t>
Editorial changes
</t>
</list>
</t>
</section>
<section title="draft-ietf-netconf-rfc5539bis-06">
<t>
<list style="symbols">
<t>
Removed all call-home related text.
</t>
<t>
Removed redundant text as discussed at the Toronto IETF
meeting.
</t>
</list>
</t>
</section>
<section title="draft-ietf-netconf-rfc5539bis-05">
<t>
<list style="symbols">
<t>
Removed the YANG configuration data model since it became a
separate document.
</t>
<t>
Added reference to RFC 3234 plus editorial updates.
</t>
</list>
</t>
</section>
<section title="draft-ietf-netconf-rfc5539bis-04">
<t>
<list style="symbols">
<t>
Added the applicability statement proposed by Stephen Hanna.
</t>
<t>
Added call-home configuration objects and a tls-call-home
feature.
</t>
<t>
Rewrote the text such that the role swap happens right
after the TCP connection has been established.
</t>
</list>
</t>
</section>
<section title="draft-ietf-netconf-rfc5539bis-03">
<t>
<list style="symbols">
<t>
Added support for call home (allocation of a new port
number, rewrote text to allow a NETCONF client to be a TLS
server and a NETCONF server to be a TLS client).
</t>
<t>
Merged sections 2 and 3 into a new section 2 and
restructured the text.
</t>
<t>
Extended the IANA considerations section.
</t>
<t>
Using the cert-to-name mapping grouping from the SNMP
configuration data model and updated the examples.
</t>
<t>
Creating an extensible set of YANG (sub)modules for
NETCONF following the (sub)module structure of the SNMP
configuration model.
</t>
</list>
</t>
</section>
<section title="draft-ietf-netconf-rfc5539bis-02">
<t>
<list style="symbols">
<t>
Addressed remaining issues identified at IETF 85
<list style="symbols">
<t>
Harmonized the cert-maps container of the YANG module
in this draft with the tlstm container in the
ietf-snmp-tls sub-module specified in
draft-ietf-netmod-snmp-cfg. Replaced the children of
the cert-maps container with the children copied from
the tlstm container of the ietf-snmp-tls sub-module.
</t>
<t>
Added an overview of data model in the
ietf-netconf-tls YANG module.
</t>
<t>
Added example configurations.
</t>
</list>
</t>
<t>
Addessed issues posted on NETCONF WG E-mail list.
</t>
<t>
Deleted the superfluous tls container that was directly
below the netconf-config container.
</t>
<t>
Added a statement to the text indicating that support for
mapping X.509 certificates to NETCONF usernames is
optional. This is analogous to existing text indicating
that support for mapping pre-shared keys to NETCONF
usernames is optional. Resource-constrained systems now
can omit support for mapping X.509 certificates to NETCONF
usernames and still comply with this specification.
</t>
<t>
Clarified the document structure by promoting the sections
of the document related to the data model.
</t>
<t>
Updated author's addresses.
</t>
</list>
</t>
</section>
<section title="draft-ietf-netconf-rfc5539bis-00">
<t>
<list style="symbols">
<t>
Remove the reference to BEEP.
</t>
<t>
Rename host-part to domain-part in the description of RFC822.
</t>
</list>
</t>
</section>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:06:34 |