One document matched: draft-ietf-netconf-call-home-14.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY rfc4252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4252.xml">
<!ENTITY rfc4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY rfc4254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4254.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY rfc6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY rfc6187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6187.xml">
<!ENTITY rfc6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY rfc6242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY rfc6335 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY rfc6520 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6520.xml">
<!ENTITY rfc7589 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7589.xml">
<!ENTITY rfc7616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7616.xml">
<!ENTITY rfc7617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7617.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc category="std"
ipr="trust200902"
docName="draft-ietf-netconf-call-home-14">
<front>
<title>NETCONF Call Home and RESTCONF Call Home</title>
<author initials="K.W." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
<address>
<email>kwatsen@juniper.net</email>
</address>
</author>
<date/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>call-home</keyword>
<abstract>
<t>This RFC presents NETCONF Call Home and RESTCONF Call Home,
which enable a NETCONF or RESTCONF server to initiate a secure
connection to a NETCONF or RESTCONF client respectively.</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. Please note that no other
RFC Editor instructions are specified anywhere else in this document.</t>
<t>Artwork in this document contains placeholder references for this draft.
Please apply the following replacement:
<list style="symbols">
<t><spanx style="verb">XXXX</spanx> --> the assigned RFC value for this draft</t>
</list>
</t>
<t>This document contains references to another draft in progress, both in
the Normative References section, as well as in body text throughout.
Please update the following reference to reflect its final RFC assignment:
<list style="symbols">
<t>draft-ietf-netconf-restconf</t>
</list>
</t>
<t>Artwork in this document contains placeholder values for ports pending IANA assignment
from "draft-ietf-netconf-call-home". Please apply the following replacements:
<list style="symbols">
<t><spanx style="verb">PORT-X</spanx> --> the assigned port value for "netconf-ch-ssh"</t>
<t><spanx style="verb">PORT-Y</spanx> --> the assigned port value for "netconf-ch-tls"</t>
<t><spanx style="verb">PORT-Z</spanx> --> the assigned port value for "restconf-ch-tls"</t>
</list>
</t>
<t>The following two Appendix sections are to be removed prior to publication:
<list style="symbols">
<t>Appendix A. Change Log</t>
<t>Appendix B. Open Issues</t>
</list>
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>This RFC presents NETCONF Call Home and RESTCONF Call Home,
which enable a NETCONF or RESTCONF server to initiate a secure
connection to a NETCONF or RESTCONF client respectively.</t>
<t>NETCONF Call Home supports both of the secure transports used
by the NETCONF protocol <xref target="RFC6241"/>, SSH and TLS.
The NETCONF protocol's binding to SSH is defined in <xref target="RFC6242"/>.
The NETCONF protocol's binding to TLS is defined in
<xref target="RFC7589"/>.</t>
<t>RESTCONF Call Home only supports TLS, the same as the RESTCONF protocol
<xref target="draft-ietf-netconf-restconf"/>. The RESTCONF protocol's
binding to TLS is defined in <xref target="draft-ietf-netconf-restconf"/>.</t>
<t>The SSH protocol is defined in <xref target="RFC4253"/>. The TLS
protocol is defined in <xref target="RFC5246"/>. Both the SSH and TLS
protocols are layered on top of the TCP protocol, which is defined in
<xref target="RFC793"/>.</t>
<t>Both NETCONF Call Home and RESTCONF Call Home preserve all but one
of the client/server roles in their respective protocol stacks, as
compared to client-initiated NETCONF and RESTCONF connections. The one and only
role reversal that occurs is at the TCP layer; that is, which peer is
the TCP-client and which is the TCP-server.</t>
<t>For example, a network element is traditionally the TCP-server.
However, when calling home, the network element becomes the TCP-client.
The network element's secure transport layer roles (SSH-server,
TLS-server) and its application layer roles (NETCONF-server,
RESTCONF-server) both remain the same.</t>
<t>Having consistency in both the secure transport layer (SSH, TLS) and
application layer (NETCONF, RESTCONF) roles conveniently enables deployed
network management infrastructure to support call home also. For instance,
existing certificate chains and user authentication mechanisms are
unaffected by call home.</t>
<section title="Motivation" anchor="motivation">
<t>Call home is generally useful for both the initial deployment
and on-going management of networking elements. Here are some
scenarios enabled by call home:
<list style="symbols">
<t>The network element may proactively call home after
being powered on for the first time in order to register
itself with its management system.</t>
<t>The network element may access the network in a way that
dynamically assigns it an IP address, but does not register
its assigned IP address to a mapping service (e.g., dynamic DNS).</t>
<t>The network element may be deployed behind a firewall
that implements network address translation (NAT)
for all internal network IP addresses.</t>
<t>The network element may be deployed behind a firewall
that doesn't allow any management access to the internal
network.</t>
<t>The network element may be configured in "stealth mode"
and thus doesn't have any open ports for the management
system to connect to.</t>
<t>The operator may prefer to have network elements initiate
management connections, believing it is easier to secure one
open port in the data center than to have an open port on
each network element in the network.</t>
</list>
</t>
</section>
<section title="Requirements Terminology">
<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 RFC 2119 <xref target="RFC2119"/>.</t>
</section>
<section title="Applicability Statement">
<t>The techniques described in this document are
suitable for network management scenarios such
as the ones described in <xref target="motivation"/>. However,
these techniques are only defined for NETCONF Call Home
and RESTCONF Call Home, as described in this document.</t>
<t>The reason for this restriction is that different
protocols have different security assumptions. The NETCONF
and RESTCONF protocols require clients and servers to
verify the identity of the other party. This requirement
is specified for the NETCONF protocol in Section 2.2 of
<xref target="RFC6241"/>, and is specified for the RESTCONF
protocol in Sections 2.4 and 2.5 of
<xref target="draft-ietf-netconf-restconf"/>).</t>
<t>This contrasts with the base SSH and TLS protocols, which
do not require programmatic verification of the other party
(section 9.3.4 of <xref target="RFC4251"/>, section 4 of
<xref target="RFC4252"/>, and section 7.3 of <xref target="RFC5246"/>).
In such circumstances, allowing the SSH/TLS server to contact the
SSH/TLS client would open new vulnerabilities. Any use of call home
with SSH/TLS for purposes other than NETCONF or RESTCONF will need
a thorough contextual risk assessment. A risk assessment for this
RFC is in the Security Considerations section (<xref target="sec-con"/>).</t>
</section>
<section title="Relation to RFC 4253">
<t>This document uses the SSH Transport Layer Protocol
<xref target="RFC4253"/> with the exception that the statement "The client
initiates the connection" made in Section 4 (Connection Setup) does not apply.
Assuming the reference to client means "SSH client" and
the reference to connection means "TCP connection", this statement
doesn't hold true in call home, where the network element is the
SSH server and yet still initiates the TCP connection. Security
implications related to this change are discussed in Security
Considerations (<xref target="sec-con"/>).</t>
</section>
<section title="The NETCONF/RESTCONF Convention">
<t>Throughout the remainder of this document, the term "NETCONF/RESTCONF"
is used as an abbreviation in place of the text "the NETCONF or the RESTCONF".
The NETCONF/RESTCONF abbreviation is not intended to require or to imply that
a client or server must implement both the NETCONF standard and the RESTCONF
standard.</t>
<t><vspace blankLines="3"/></t>
</section>
</section>
<section title="Solution Overview">
<t>The diagram below illustrates call home
from a protocol layering perspective:</t>
<figure>
<artwork><![CDATA[
NETCONF/RESTCONF NETCONF/RESTCONF
Server Client
| |
| 1. TCP |
|----------------------------------->|
| |
| |
| 2. SSH/TLS |
|<-----------------------------------|
| |
| |
| 3. NETCONF/RESTCONF |
|<-----------------------------------|
| |
Note: arrows point from the "client" to
the "server" at each protocol layer
]]></artwork>
</figure>
<t>This diagram makes the following points:
<list style="numbers">
<t>The NETCONF/RESTCONF server begins by initiating a TCP connection to the NETCONF/RESTCONF client.</t>
<t>Using this TCP connection, the NETCONF/RESTCONF client initiates a SSH/TLS session to the NETCONF/RESTCONF server.</t>
<t>Using this SSH/TLS session, the NETCONF/RESTCONF client intiates a NETCONF/RESTCONF session to the NETCONF/RESTCONF server.</t>
</list>
</t>
<t><vspace blankLines="2"/></t>
</section>
<section title="The NETCONF or RESTCONF Client">
<t>The term "client" is defined in <xref target="RFC6241"/>, Section 1.1 "client". In the context of network management, the NETCONF/RESTCONF client might be a network management system.</t>
<section title="Protocol Operation">
<t>
<list style="format C%d">
<t>The NETCONF/RESTCONF client listens for TCP connection requests
from NETCONF/RESTCONF servers. The client MUST support accepting
TCP connections on the IANA-assigned ports defined in <xref
target="iana-con"/>, but MAY be configured to listen a defferent port.</t>
<t>The NETCONF/RESTCONF client accepts an incoming TCP
connection request and a TCP connection is established.</t>
<t>Using this TCP connection, the NETCONF/RESTCONF client
starts either the SSH-client <xref target="RFC4253"/> or the TLS-client
<xref target="RFC5246"/> protocol. For example, assuming the use of the
IANA-assigned ports, the SSH-client protocol is started when the connection
is accepted on port PORT-X and the TLS-client protocol is started when the
connection is accepted on either port PORT-Y or PORT-Z.</t>
<t>If using TLS, the NETCONF/RESTCONF client MUST advertise
"peer_allowed_to_send", as defined by <xref target="RFC6520"/>. This is
required so NETCONF/RESTCONF servers can depend on it being there for
call home connections, when keep-alives are needed the most.</t>
<t>As part of establishing an SSH or TLS connection, the NETCONF/RESTCONF
client MUST validate the server's presented host key or certificate.
This validation MAY be accomplished by certificate path validation or by
comparing the host key or certificate to a previously trusted or
"pinned" value. If a certificate is presented and it contains
revocation checking information, the NETCONF/RESTCONF client
SHOULD check the revocation status of the certificate. If it is
determined that a certificate has been revoked, the client MUST
immediately close the connection.</t>
<t>If certificate path validation is used, the NETCONF/RESTCONF client MUST
ensure that the presented certificate has a valid chain of trust to a
preconfigured Issuer and that the presented certificate encodes an
"identifier" <xref target="RFC6125"/> that the client had awareness
of prior to the connection attempt. Clients SHOULD ensure that the
Issuer used to authenticate the presented certificate defines the
namespace for the identifiers of interest.
How identifiers are encoded in certificates MAY be
determined by a policy associated with the certificate's Issuer.
For instance, a given Issuer may be known to only sign IDevID
certificates <xref target="Std-802.1AR-2009"/> having a unique identifier
(e.g., serial number) in the X.509 certificate's "CommonName" field.</t>
<t>After the server's host key or certificate is validated, the SSH or TLS
protocol proceeds as normal to establish a SSH or TLS connection.
When performing client-authentcation with the NETCONF/RESTCONF
server, the NETCONF/RESTCONF client MUST ensure to only use
credentials that it had previously associated for the NETCONF/RESTCONF
server’s presented host key or server certificate.</t>
<t>Once the SSH or TLS connection is established, the NETCONF/RESTCONF client
starts either the NETCONF-client <xref target="RFC6241"/>
or RESTCONF-client <xref target="draft-ietf-netconf-restconf"/> protocol.
Assuming the use of the IANA-assigned ports, the NETCONF-client protocol is
started when the connection is accepted on either port PORT-X or PORT-Y and
the RESTCONF-client protocol is started when the connection is accepted
on port PORT-Z.</t>
</list>
</t>
</section>
<section title="Configuration Data Model">
<t>How a NETCONF or RESTCONF client is configured is outside the
scope of this document. For instance, such configuration might
be used to enable listening for call home connections, configuring
trust anchors, or configuring identifiers for expected connections.</t>
<t><vspace blankLines="2"/></t>
</section>
</section>
<section title="The NETCONF or RESTCONF Server">
<t>The term "server" is defined in <xref target="RFC6241"/>, Section 1.1 "server". In the context of network management, the NETCONF/RESTCONF server might be a network element or a device.</t>
<section title="Protocol Operation">
<t>
<list style="format S%d">
<t>The NETCONF/RESTCONF server initiates a TCP connection request to
the NETCONF/RESTCONF client. The server MUST support connecting
to one of the IANA-assigned ports defined in <xref target="iana-con"/>,
but MAY be configured to connect to a different port. Using the IANA-assigned
ports, the server connects to port PORT-X for NETCONF over SSH, port
PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF over TLS.</t>
<t>The TCP connection request is accepted and a TCP connection is
established.</t>
<t>Using this TCP connection, the NETCONF/RESTCONF server
starts either the SSH-server <xref target="RFC4253"/> or the TLS-server
<xref target="RFC5246"/> protocol, depending on how it is configured. For
example, assuming the use of the IANA-assigned ports, the SSH-server protocol
is used after connecting to the remote port PORT-X and the TLS-server protocol
is used after connecting to one of the remote ports PORT-Y or PORT-Z.</t>
<t>As part of establishing the SSH or TLS connection, the NETCONF/RESTCONF
server will send its host key or certificate to the client. If a certificate
is sent, the server MUST also send all intermediate certificates leading up
to the certificate's trust anchor. How to send a list of certificates is
defined for SSH in <xref target="RFC6187"/> Section 2.1, and for TLS in
<xref target="RFC5246"/> Section 7.4.2.</t>
<t>Establishing an SSH or TLS session requires server authentication
of client credentials in all cases except with RESTCONF, where some
client authentication schemes occur after the secure transport connection
(TLS) has been established. If transport (SSH or TLS) level client authentication is required, and
the client is unable to successfully authenticate itself to the server
in an amount of time defined by local policy, the server MUST close the
connection.</t>
<t>Once the SSH or TLS connection is established, the NETCONF/RESTCONF server
starts either the NETCONF-server <xref target="RFC6241"/>
or RESTCONF-server <xref target="draft-ietf-netconf-restconf"/> protocol,
depending on how it is configured. Assuming the use of the IANA-assigned
ports, the NETCONF-server protocol is used after connecting to remote
port PORT-X or PORT-Y, and the RESTCONF-server protocol is used after
connecting to remote port PORT-Z.</t>
<t>If a persistent connection is desired, the NETCONF/RESTCONF server,
as the connection initiator, SHOULD actively test the aliveness of
the connection using a keep-alive mechanism. For TLS based connections,
the NETCONF/RESTCONF server
SHOULD send HeartbeatRequest messages, as defined by <xref target="RFC6520"/>.
For SSH based connections, per Section 4 of <xref target="RFC4254"/>, the
NETCONF/RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message
with a purposely nonexistent "request name" value (e.g., keepalive@ietf.org)
and the "want reply" value set to '1'.</t>
</list>
</t>
</section>
<section title="Configuration Data Model">
<t>How a NETCONF or RESTCONF server is configured is outside the
scope of this document. This includes configuration that might
be used to specify hostnames, IP addresses, ports, algorithms,
or other relevant parameters. That said, a YANG <xref target="RFC6020"/>
model for configuring NETCONF and RESTCONF servers, including call home,
is provided in <xref target="draft-ietf-netconf-server-model"/>.</t>
</section>
</section>
<section anchor="sec-con" title="Security Considerations">
<t>The security considerations described in <xref target="RFC6242"/>
and <xref target="RFC7589"/>, and by extension <xref target="RFC4253"/>,
<xref target="RFC5246"/>, and <xref target="draft-ietf-netconf-restconf"/>
apply here as well.</t>
<t>This RFC deviates from standard SSH and TLS usage by having the
SSH/TLS server initiate the underlying TCP connection. This reversal
is incongruous with <xref target="RFC4253"/>, which says "the client
initiates the connection" and also <xref target="RFC6125"/>, which says
"the client MUST construct a list of acceptable reference identifiers,
and MUST do so independently of the identifiers presented by the service."</t>
<t>Risks associated with these variances are centered around server
authentication and the inability for clients to compare an independently
constructed reference idenitifier to one presented by the server.
To mitigate these risks, this RFC requires that the
NETCONF/RESTCONF client validate the server's SSH host key or
certificate, by certificate path validation to a preconfigured Issuer
certificate, or by comparing the host key or certificate to a
previously trusted or "pinned" value. Furthermore, when a certificate
is used, this RFC requires that the client be able to match an
identifier encoded in the presented certificate with an identifier
the client was preconfigured to expect (e.g., serial number).</t>
<t>For cases when the NETCONF/RESTCONF server presents an X.509
certificate, NETCONF/RESTCONF clients should ensure that the
Issuer certificate used for certificate path validation is
unique to the manufacturer of the server. That is, the certificate
should not belong to a 3rd-party certificate authority that
might issue intermediate certificates for more than one manufacturer.
This is especially important when a client-authentication mechanism
passing a shared secret (e.g., a password) to the server is used.
Not doing so could otherwise lead to a case where the client sends
the shared secret to another server that happens to have the same
identity (e.g., serial number) as the server the client was
configured to expect.</t>
<t>Considerations not associated with server authentication follow next.</t>
<t>Internet facing hosts running NETCONF or RESTCONF call home
will be fingerprinted via scanning tools such as `zmap`
<xref target="zmap"/>. Both SSH and TLS provide many ways
in which a host can be fingerprinted. SSH and TLS servers
are fairly mature and able to withstand attacks, but SSH and TLS
clients may not be as robust. Implementers and deployments
need to ensure that software update mechanisms are provided
so that vulnerabilities can be fixed in a timely fashion.</t>
<t>An attacker could launch a denial of service (DoS) attack
on the NETCONF/RESTCONF client by having it perform
computationally expensive operations, before deducing that
the attacker doesn't posses a valid key. For instance, in
TLS 1.3 <xref target="draft-ietf-tls-tls13"/>, the ClientHello
message contains a Key Share value based on an expensive
asymmetric key operation. Common precautions mitigating DoS
attacks are recommended, such as temporarily blacklisting
the source address after a set number of unsuccessful login
attempts.</t>
<t>When using call home with the RESTCONF protocol, special
care is required when using some HTTP authentication schemes,
especially the Basic <xref target="RFC7617"/> and Digest
<xref target="RFC7616"/> schemes, which convey a shared key.
Implementations and deployments should be sure to review the
Security Considerations section in the RFC for any HTTP client
authentication scheme used.</t>
</section>
<section title="IANA Considerations" anchor="iana-con">
<t>This RFC requests that IANA assigns three TCP port numbers
in the "Registered Port Numbers" range with the service names
"netconf-ch-ssh", "netconf-ch-tls", and "restconf-ch-tls". These
ports will be the default ports for NETCONF Call Home and RESTCONF
Call Home protocols. Below is the registration template following
the rules in <xref target="RFC6335"/>.</t>
<t>
<figure align="center">
<artwork><![CDATA[
Service Name: netconf-ch-ssh
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: NETCONF Call Home (SSH)
Reference: RFC XXXX
Port Number: PORT-X
Service Name: netconf-ch-tls
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: NETCONF Call Home (TLS)
Reference: RFC XXXX
Port Number: PORT-Y
Service Name: restconf-ch-tls
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: RESTCONF Call Home (TLS)
Reference: RFC XXXX
Port Number: PORT-Z
]]></artwork>
</figure>
</t>
</section>
<section title="Acknowledgements">
<t>The author would like to thank the following for
lively discussions on list and in the halls (ordered
by last name): Andy Bierman, Martin Bjorklund, Mehmet Ersue,
Wes Hardaker, Stephen Hanna, David Harrington, Jeffrey Hutzelman,
Radek Krejci, Alan Luchuk, Mouse, Russ Mundy, Tom Petch,
Juergen Schoenwaelder, Peter Saint-Andre, Joe Touch,
Hannes Tschofenig, Sean Turner, and Bert Wijnen.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC793" target="https://www.ietf.org/rfc/rfc793.txt">
<front>
<title>TRANSMISSION CONTROL PROTOCOL</title>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1981" month="September"/>
</front>
<seriesInfo name="STD" value="7"/>
</reference>
&rfc2119;
&rfc4251;
&rfc4252;
&rfc4253;
&rfc4254;
&rfc5246;
&rfc6125;
&rfc6187;
&rfc6241;
&rfc6242;
&rfc6335;
&rfc6520;
&rfc7589;
<reference anchor="draft-ietf-netconf-restconf" target="https://tools.ietf.org/html/draft-ietf-netconf-restconf">
<front>
<title>
RESTCONF Protocol
</title>
<author initials='A.B.' surname='Bierman'
fullname='Andy Bierman'>
<organization>YumaWorks</organization>
</author>
<author initials='M.B.' surname='Bjorklund'
fullname='Martin Bjorklund'>
<organization>Tail-f Systems</organization>
</author>
<author initials='K.W.' surname='Watsen'
fullname='Kent Watsen'>
<organization>Juniper Networks</organization>
</author>
<date year='2014' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-ieft-netconf-restconf-04' />
</reference>
</references>
<references title="Informative References">
&rfc6020;
&rfc7616;
&rfc7617;
<reference anchor="Std-802.1AR-2009" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE Standard for Local and metropolitan area networks - Secure Device Identity</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="December" year="2009"/>
</front>
</reference>
<reference anchor="draft-ietf-tls-tls13" target="http://tools.ietf.org/html/draft-ietf-tls-tls13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E.R." surname="Rescorla"
fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<date year="2015" />
</front>
</reference>
<reference anchor="draft-ietf-netconf-server-model" target="http://tools.ietf.org/html/draft-ietf-netconf-server-model">
<front>
<title>NETCONF Server Configuration Model</title>
<author initials="K.W." surname="Watsen"
fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<author initials="J.S." surname="Schoenwaelder"
fullname="Juergen Schoenwaelder">
<organization>Jacobs University</organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="zmap" target="https://zmap.io/paper.html">
<front>
<title>ZMap: Fast Internet-Wide Scanning and its Security Applications</title>
<author initials="Z.D." surname="Durumeric" fullname="Zakir Durumeric"/>
<author initials="E.W." surname="Wustrow" fullname="Eric Wustrow"/>
<author initials="J.H." surname="Halderman" fullname="J. Alex Halderman"/>
<date year="2013" />
</front>
<annotation>In proceedings of the 22nd USENIX Security Symposium</annotation>
</reference>
</references>
<section title="Change Log">
<section title="00 to 01">
<t>
<list style="symbols">
<t>The term "TCP connection" is now used throughout.</t>
<t>The terms "network element" and "management system" are now only used in the Motivation section.</t>
<t>Restructured doc a little to create an Introduction section.</t>
<t>Fixed reference in Applicability Statement so it would work
equally well for SSH and TLS.</t>
<t>Fixed reported odd wording and three references.</t>
</list>
</t>
</section>
<section title="01 to 02">
<t>
<list style="symbols">
<t>Added call home support for the RESTCONF protocol.</t>
<t>Fixed paragraph 3 of Security Considerations to equally
apply to the TLS protocol.</t>
</list>
</t>
</section>
<section title="02 to 03">
<t>
<list style="symbols">
<t>Tried to improve readability (issue #6)</t>
<t>Removed "FIXME" in section 1.3 (issue #7)</t>
<t>Added RFC Editor notes (issue #8)</t>
<t>Removed "TCP session" term (issue #9)</t>
<t>Improved language for usage of IANA-assigned ports (issue #10)</t>
</list>
</t>
</section>
<section title="03 to 04">
<t>
<list style="symbols">
<t>Replaced "verify credentials" with "verify identity" (issue #11)</t>
</list>
</t>
</section>
<section title="04 to 05">
<t>
<list style="symbols">
<t>Applied many suggestions from WGLC</t>
<t>Removed essay like "Server Identification and Verification" section</t>
<t>Added text about keep-alives</t>
<t>Added Configuration Data Model section for client protocol</t>
<t>Improved Security Considerations section</t>
</list>
</t>
</section>
<section title="05 to 06">
<t>
<list style="symbols">
<t>Addressed comments raised by Alan Luchuk.</t>
</list>
</t>
</section>
<section title="06 to 07">
<t>
<list style="symbols">
<t>replaced "reference identifier" with "identifier"</t>
<t>added reference to RFC6125</t>
<t>moved reference to 6020 to Informative section</t>
</list>
</t>
</section>
<section title="07 to 08">
<t>
<list style="symbols">
<t>Added text regarding client authentication</t>
<t>Now says client-initiated (not standard) NETCONF/RESTCONF connections</t>
<t>Now says server must send all (not any) intermediate certificates</t>
<t>Improved wording based on suggestions from Jonathan and Tom</t>
</list>
</t>
</section>
<section title="08 to 09">
<t>
<list style="symbols">
<t>Added dynamic DNS as an example for an IP mapping service</t>
<t>Replaced draft-ietf-netconf-rfc5539bis with RFC7589</t>
<t>Recharacterized this draft's relationship to RFC4253</t>
</list>
</t>
</section>
<section title="09 to 10">
<t>
<list style="symbols">
<t>Updates from AD review</t>
</list>
</t>
</section>
<section title="10 to 11">
<t>
<list style="symbols">
<t>Fixed typo introduced in -10</t>
</list>
</t>
</section>
<section title="11 to 12">
<t>
<list style="symbols">
<t>Addresses DISCUSS and COMMENTS from IESG review.</t>
</list>
</t>
</section>
<section title="12 to 13">
<t>
<list style="symbols">
<t>Fixed a couple typos and removed the VeriSign example</t>
</list>
</t>
</section>
<section title="13 to 14">
<t>
<list style="symbols">
<t>Addressed final DISCUSS item from IESG review</t>
</list>
</t>
</section>
</section>
<section title="Open Issues">
<t>All issues with this draft are tracked using GitHub issues. Please see: https://github.com/netconf-wg/call-home/issues to see currently opened issues.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:00:32 |