Internet Engineering Task Force (IETF) M. Badra
Request for Comments: 7589 Zayed University
Obsoletes: 5539 A. Luchuk
Category: Standards Track SNMP Research, Inc.
ISSN: 2070-1721 J. Schoenwaelder
Jacobs University Bremen
June 2015
Internet Engineering Task Force (IETF) M. Badra
Request for Comments: 7589 Zayed University
Obsoletes: 5539 A. Luchuk
Category: Standards Track SNMP Research, Inc.
ISSN: 2070-1721 J. Schoenwaelder
Jacobs University Bremen
June 2015
Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication
在传输层安全性（TLS）上使用NETCONF协议并进行相互X.509身份验证
Abstract
摘要
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.
网络配置协议（NETCONF）提供了安装、操作和删除网络设备配置的机制。本文档描述了如何使用传输层安全（TLS）协议和相互X.509身份验证来保护NETCONF消息的交换。RFC 5539的这一版本记录了NETCONF 1.1使用的新消息框架，它淘汰了RFC 5539。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7589.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7589.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Connection Initiation . . . . . . . . . . . . . . . . . . . . 3
3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3
4. Connection Closure . . . . . . . . . . . . . . . . . . . . . 4
5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4
6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4
7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4
8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Connection Initiation . . . . . . . . . . . . . . . . . . . . 3
3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3
4. Connection Closure . . . . . . . . . . . . . . . . . . . . . 4
5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4
6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4
7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4
8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
The NETCONF protocol [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.
NETCONF协议[RFC6241]定义了一种管理网络设备的机制。NETCONF是面向连接的，需要对等方之间的持久连接。此连接必须提供完整性、机密性、对等身份验证以及可靠的顺序数据传递。
This document defines how NETCONF messages can be exchanged over Transport Layer Security (TLS) [RFC5246]. Implementations MUST support mutual TLS certificate-based authentication [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.
本文档定义了如何通过传输层安全性（TLS）[RFC5246]交换NETCONF消息。实现必须支持相互TLS基于证书的身份验证[RFC5246]。这将确保NETCONF服务器具有希望操纵管理信息的主体的身份。它还向NETCONF客户机保证它希望为其操作管理信息的服务器的标识。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
作为NETCONF客户端的对等方必须作为TLS客户端。TLS客户端主动打开TLS连接，TLS服务器被动侦听传入的TLS连接。NETCONF服务器使用众所周知的TCP端口号6513来侦听NETCONF通过TLS客户端建立的TCP连接。TLS客户端必须发送TLS ClientHello消息才能开始TLS握手。TLS服务器必须发送CertificateRequest才能从TLS客户端请求证书。一旦TLS握手完成，客户端和服务器就可以开始交换NETCONF消息。在发送NETCONF<hello>消息之前完成客户端和服务器身份验证。这意味着身份验证在NETCONF会话启动之前完成。
All NETCONF messages MUST be sent as TLS "application data". It is possible for multiple NETCONF messages to be contained in one TLS record, or for a NETCONF message to be transferred in multiple TLS records.
所有NETCONF消息必须作为TLS“应用程序数据”发送。可以在一个TLS记录中包含多个NETCONF消息，也可以在多个TLS记录中传输一个NETCONF消息。
The previous version of this specification [RFC5539] used the framing sequence defined in [RFC4742]. This version aligns with [RFC6242] and adopts the framing protocol defined in [RFC6242] as follows:
本规范的早期版本[RFC5539]使用了[RFC4742]中定义的帧序列。此版本与[RFC6242]一致，并采用[RFC6242]中定义的帧协议，如下所示：
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 [RFC6242] is used for the remainder of the NETCONF session. Otherwise, the old end-of-message-based mechanism (see Section 4.3 of [RFC6242]) is used.
NETCONF<hello>消息后面必须跟字符序列]]>]]>。在接收到<hello>消息后，对等方将检查宣布的功能。如果：base:1.1功能由两个对等方公布，则[RFC6242]第4.2节中定义的分块成帧机制将用于NETCONF会话的其余部分。否则，将使用旧的基于消息端的机制（参见[RFC6242]第4.3节）。
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 [RFC5246].
NETCONF服务器将按照接收顺序处理来自NETCONF客户端的NETCONF消息。使用<close session>操作关闭NETCONF会话。当NETCONF服务器处理<close session>操作时，NETCONF服务器应响应并关闭[RFC5246]第7.2.1节所述的TLS会话。
Both peers MUST use X.509 certificate path validation [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 [RFC5246].
两个对等方都必须使用X.509证书路径验证[RFC5280]来验证对等方提供的证书的完整性。如果提供的X.509证书与通过另一个受信任机制（如使用本地配置的证书指纹）获得的证书相匹配，则也可以认为该证书有效。如果X.509证书路径验证失败，并且提供的X.509证书与受信任机制获得的证书不匹配，则必须按照[RFC5246]中的定义终止连接。
The NETCONF client MUST check the identity of the server according to Section 6 of [RFC6125].
NETCONF客户端必须根据[RFC6125]第6节检查服务器的标识。
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.
NETCONF服务器必须验证NETCONF客户端的身份，以确保在NETCONF会话启动之前，建立NETCONF会话的传入请求是合法的。
The NETCONF protocol [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
NETCONF协议[RFC6241]要求传输协议的身份验证过程产生一个经过身份验证的NETCONF客户端标识，服务器知道该标识的权限。客户机的身份验证通常称为NETCONF用户名。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 [RFC6353] and in the ietf-x509-cert-to-name YANG module defined in [RFC7407].)
服务器从证书派生NETCONF用户名。（请注意，以下算法与[RFC6353]中定义的SNMP-TLS-TM-MIB MIB模块和[RFC7407]中定义的ietf-x509-cert-to-name模块中描述的算法相同。）
(a) The server maintains an ordered list of mappings of certificates to NETCONF usernames. Each list entry contains
(a) 服务器维护证书到NETCONF用户名的有序映射列表。每个列表条目包含
* a certificate fingerprint (used for matching the presented certificate),
* 证书指纹（用于匹配提交的证书），
* a map type (indicates how the NETCONF username is derived from the certificate), and
* 映射类型（指示如何从证书派生NETCONF用户名），以及
* optional auxiliary data (used to carry a NETCONF username if the map type indicates the username is explicitly configured).
* 可选辅助数据（如果映射类型表明已显式配置用户名，则用于携带NETCONF用户名）。
(b) 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:
(b) NETCONF用户名是通过按顺序考虑每个列表条目而获得的。当前列表项的指纹成员确定当前列表项是否匹配：
1. If the list entry's fingerprint value matches the fingerprint of the presented certificate, then consider the list entry as a successful match.
1. 如果列表条目的指纹值与所提交证书的指纹匹配，则将列表条目视为成功匹配。
2. If the list entry's fingerprint value matches that of a locally held copy of a trusted certification authority (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.
2. 如果列表条目的指纹值与可信证书颁发机构（CA）证书的本地持有副本相匹配，CA证书是CA证书链到所提交证书的一部分，则将列表条目视为成功匹配。
(c) 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:
(c) 找到匹配的列表项后，将使用当前列表项的映射类型来确定如何确定与证书关联的用户名。可能的映射选项包括：
A. The username is taken from the auxiliary data of the current list entry. This means the username is explicitly configured (map type 'specified').
A.用户名取自当前列表条目的辅助数据。这意味着用户名已显式配置（映射类型为“指定”）。
B. 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.
B.subjectAltName的rfc822Name字段映射到用户名（映射类型为“san-rfc822-name”）。RFC822名称的本地部分使用不变，但名称的主机部分必须转换为小写。
C. The subjectAltName's dNSName is mapped to the username (map type 'san-dns-name'). The characters of the dNSName are converted to lowercase.
C.subjectAltName的dNSName映射到用户名（映射类型为“san dns名称”）。dNSName的字符转换为小写。
D. 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.
D.subjectAltName的ip地址映射到用户名（映射类型为“san ip地址”）。IPv4地址转换为十进制虚线四元表示法（例如，“192.0.2.1”）。IPv6地址转换为32个字符的全小写十六进制字符串，不带任何冒号分隔符。
E. The rfc822Name, dNSName, or iPAddress of the subjectAltName 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.
E.subjectAltName的rfc822Name、dNSName或IP地址映射到用户名（映射类型为“san any”）。派生名称时，必须使用在上述类型的证书中找到的第一个匹配subjectAltName值。
F. 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.
F.证书的CommonName映射到用户名（映射类型为“CommonName”）。CommonName转换为UTF-8编码。不推荐使用CommonName，并鼓励用户改用subjectAltName映射方法。
(d) 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 to look for another potential match. Similarly, if the username does not comply to the NETCONF requirements on usernames [RFC6241], then additional list entries MUST be searched to look for another potential match. If there are no further list entries, the TLS session MUST be terminated.
(d) 如果无法根据列表项的数据和证书中显示的数据确定用户名，则必须搜索其他列表项以查找其他可能的匹配项。类似地，如果用户名不符合NETCONF对用户名的要求[RFC6241]，则必须搜索其他列表项以查找其他可能的匹配项。如果没有其他列表条目，则必须终止TLS会话。
The username provided by the NETCONF over TLS implementation will be made available to the NETCONF message layer as the NETCONF username without modification.
NETCONF over TLS实现提供的用户名将作为NETCONF用户名提供给NETCONF消息层，无需修改。
The NETCONF server configuration data model [NETCONF-RESTCONF] covers NETCONF over TLS and provides further details such as certificate fingerprint formats exposed to network configuration systems.
NETCONF服务器配置数据模型[NETCONF-RESTCONF]涵盖了TLS上的NETCONF，并提供了进一步的详细信息，如向网络配置系统公开的证书指纹格式。
Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory-to-implement cipher suite. Implementations MAY implement additional TLS cipher suites that provide mutual authentication [RFC5246] and confidentiality as required by NETCONF [RFC6241]. Implementations SHOULD follow the recommendations given in [RFC7525].
实现必须支持TLS 1.2[RFC5246]，并且必须支持强制实现密码套件。实现可以实现额外的TLS密码套件，这些套件按照NETCONF[RFC6241]的要求提供相互认证[RFC5246]和机密性。实施应遵循[RFC7525]中给出的建议。
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.
NETCONF用于访问配置和状态信息以及修改配置信息，因此访问此协议的能力应限于有权查看NETCONF服务器的配置和状态或修改NETCONF服务器配置的用户和系统。
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 [RFC5246] and NETCONF [RFC6241] apply here as well.
配置或状态数据可能包括敏感信息，如用户名或安全密钥。因此，NETCONF需要为数据隐私提供强加密的通信通道。本文档定义了NETCONF over TLS映射，该映射提供了对强加密和身份验证的支持。TLS[RFC5246]和NETCONF[RFC6241]的安全注意事项也适用于此处。
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 Section 7). 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.
TLS上的NETCONF需要相互身份验证。任何一方都不应在对方建立具有未知、意外或不正确标识的NETCONF over TLS连接。请注意，是否接受客户端提供的证书取决于可信CA证书是否为白名单（请参阅第7节）。如果部署使用此选项，建议仅使用白名单CA证书颁发用于访问NETCONF服务器的证书。如果CA证书用于为其他目的颁发证书，则NETCONF服务器也将接受为其他目的创建的所有证书，这可能不合适。
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 Secure Shell (SSH) transport [RFC6242] can be used.
本文档不支持第三方身份验证（例如，后端身份验证、授权和记帐（AAA）服务器），因为TLS没有指定这种身份验证方式，并且NETCONF依赖于身份验证服务的传输协议。如果需要第三方身份验证，则可以使用安全Shell（SSH）传输[RFC6242]。
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 the :base:1.1 capability, a proper framing protocol (chunked framing mechanism; see Section 3) is used for the rest of the NETCONF session, to avoid injection attacks.
RFC 5539假定消息结束（EOM）序列]]>]]>不能出现在任何格式良好的XML文档中，这被证明是错误的。如果故意在NETCONF消息中发送，EOM序列可能会导致操作问题和攻击空间。然而，据信相关的威胁不是很高。本文档仍然使用EOM序列作为初始<hello>消息，以避免与现有实现不兼容。当两个对等方都实现：base:1.1功能时，NETCONF会话的其余部分将使用适当的帧协议（分块帧机制；请参见第3节），以避免注入攻击。
Per RFC 5539, IANA assigned TCP port number (6513) in the "Registered Port Numbers" range with the service name "netconf-tls". This port is the default port for NETCONF over TLS, as defined in Section 2. Below is the registration template following the rules in [RFC6335].
根据RFC 5539，IANA在“注册端口号”范围内为TCP端口号（6513）分配了服务名称“netconf tls”。此端口是NETCONF over TLS的默认端口，如第2节所定义。以下是遵循[RFC6335]中规则的注册模板。
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 7589
Port Number: 6513
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 7589
Port Number: 6513
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <http://www.rfc-editor.org/info/rfc6242>.
[RFC6242]Wasserman，M.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<http://www.rfc-editor.org/info/rfc6242>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[NETCONF-RESTCONF] Watsen, K. and J. Schoenwaelder, "NETCONF Server and RESTCONF Server Configuration Models", Work in Progress, draft-ietf-netconf-server-model-06, February 2015.
[NETCONF-RESTCONF]Watsen，K.和J.Schoenwaeld，“NETCONF服务器和RESTCONF服务器配置模型”，正在进行的工作，草稿-ietf-NETCONF-Server-model-06，2015年2月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, DOI 10.17487/RFC4742, December 2006, <http://www.rfc-editor.org/info/rfc4742>.
[RFC4742]Wasserman，M.和T.Goddard，“在安全外壳（SSH）上使用NETCONF配置协议”，RFC 4742，DOI 10.17487/RFC4742，2006年12月<http://www.rfc-editor.org/info/rfc4742>.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, DOI 10.17487/RFC5539, May 2009, <http://www.rfc-editor.org/info/rfc5539>.
[RFC5539]Badra，M.，“传输层安全（TLS）上的网络配置”，RFC 5539，DOI 10.17487/RFC5539，2009年5月<http://www.rfc-editor.org/info/rfc5539>.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <http://www.rfc-editor.org/info/rfc6353>.
[RFC6353]Hardaker，W.“简单网络管理协议（SNMP）的传输层安全（TLS）传输模型”，STD 78，RFC 6353，DOI 10.17487/RFC6353，2011年7月<http://www.rfc-editor.org/info/rfc6353>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, December 2014, <http://www.rfc-editor.org/info/rfc7407>.
[RFC7407]Bjorklund，M.和J.Schoenwaeld，“SNMP配置的YANG数据模型”，RFC 7407，DOI 10.17487/RFC7407，2014年12月<http://www.rfc-editor.org/info/rfc7407>.
This section summarizes major changes between this document and RFC 5539.
本节总结了本文件与RFC 5539之间的主要变化。
o Documented that NETCONF over TLS uses the new message framing if both peers support the :base:1.1 capability.
o 有文件证明，如果两个对等方都支持：base:1.1功能，则通过TLS的NETCONF将使用新的消息帧。
o Removed redundant text that can be found in the TLS and NETCONF specifications and restructured the text. Alignment with [RFC6125].
o 删除了TLS和NETCONF规范中的冗余文本，并重新构造了文本。与[RFC6125]对齐。
o Added a high-level description on how NETCONF usernames are derived from certificates.
o 添加了关于如何从证书派生NETCONF用户名的高级描述。
o Removed the reference to BEEP.
o 删除了对BEEP的引用。
Acknowledgements
致谢
The authors like to acknowledge Martin Bjorklund, Olivier Coupelon, Pasi Eronen, Mehmet Ersue, Stephen Farrell, Miao Fuyou, Ibrahim Hajjeh, David Harrington, Sam Hartman, Alfred Hoenes, Simon Josefsson, Charlie Kaufman, Barry Leiba, Tom Petch, Tim Polk, Eric Rescorla, Dan Romascanu, Kent Watsen, Bert Wijnen, Stefan Winter, and the NETCONF mailing list members for their comments on this document.
作者希望感谢马丁·比约克隆德、奥利维尔·库佩隆、帕西·埃隆、默米特·厄苏、斯蒂芬·法雷尔、缪福佑、易卜拉欣·哈杰、大卫·哈林顿、萨姆·哈特曼、阿尔弗雷德·霍恩斯、西蒙·约瑟夫松、查理·考夫曼、巴里·莱巴、汤姆·佩奇、蒂姆·波尔克、埃里克·雷索拉、丹·罗马斯坎努、肯特·沃特森、伯特·维恩、斯特凡·温特、，以及NETCONF邮件列表成员对本文件的评论。
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme.
Juergen Schoenwaeld的部分资金来自Flamingo，这是一个卓越网络项目（ICT-318488），由欧盟委员会在其第七个框架计划下支持。
Authors' Addresses
作者地址
Mohamad Badra Zayed University P.O. Box 19282 Dubai, United Arab Emirates
穆罕默德·巴德拉·扎耶德大学邮政信箱19282阿拉伯联合酋长国迪拜
Phone: +971 4 4021879
EMail: mohamad.badra@zu.ac.ae
URI: http://www.zu.ac.ae
Phone: +971 4 4021879
EMail: mohamad.badra@zu.ac.ae
URI: http://www.zu.ac.ae
Alan Luchuk SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920 United States
Alan Luchuk SNMP Research，Inc.美国田纳西州诺克斯维尔金伯利高地路3001号，邮编37920
Phone: +1 865 573 1434
EMail: luchuk@snmp.com
URI: http://www.snmp.com/
Phone: +1 865 573 1434
EMail: luchuk@snmp.com
URI: http://www.snmp.com/
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28759 Bremen Germany
德国不来梅大学校园环128759
Phone: +49 421 200 3587
EMail: j.schoenwaelder@jacobs-university.de
URI: http://www.jacobs-university.de/
Phone: +49 421 200 3587
EMail: j.schoenwaelder@jacobs-university.de
URI: http://www.jacobs-university.de/