Network Working Group S. Hollenbeck
Request for Comments: 5734 VeriSign, Inc.
STD: 69 August 2009
Obsoletes: 4934
Category: Standards Track
Network Working Group S. Hollenbeck
Request for Comments: 5734 VeriSign, Inc.
STD: 69 August 2009
Obsoletes: 4934
Category: Standards Track
Extensible Provisioning Protocol (EPP) Transport over TCP
TCP上的可扩展资源调配协议（EPP）传输
Abstract
摘要
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934.
本文档描述如何将可扩展资源调配协议（EPP）会话映射到单个传输控制协议（TCP）连接。此映射需要使用传输层安全性（TLS）协议来保护EPP客户端和EPP服务器之间交换的信息。本文件淘汰RFC 4934。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Session Management ..............................................2
3. Message Exchange ................................................3
4. Data Unit Format ................................................6
5. Transport Considerations ........................................6
6. Internationalization Considerations .............................7
7. IANA Considerations .............................................7
8. Security Considerations .........................................7
9. TLS Usage Profile ...............................................8
10. Acknowledgements ..............................................11
11. References ....................................................11
11.1. Normative References .....................................11
11.2. Informative References ...................................12
Appendix A. Changes from RFC 4934 ................................13
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Session Management ..............................................2
3. Message Exchange ................................................3
4. Data Unit Format ................................................6
5. Transport Considerations ........................................6
6. Internationalization Considerations .............................7
7. IANA Considerations .............................................7
8. Security Considerations .........................................7
9. TLS Usage Profile ...............................................8
10. Acknowledgements ..............................................11
11. References ....................................................11
11.1. Normative References .....................................11
11.2. Informative References ...................................12
Appendix A. Changes from RFC 4934 ................................13
This document describes how the Extensible Provisioning Protocol (EPP) is mapped onto a single client-server TCP connection. Security services beyond those defined in EPP are provided by the Transport Layer Security (TLS) Protocol [RFC2246]. EPP is described in [RFC5730]. TCP is described in [RFC0793]. This document obsoletes RFC 4934 [RFC4934].
本文档描述如何将可扩展资源调配协议（EPP）映射到单个客户机-服务器TCP连接。EPP中定义的安全服务以外的安全服务由传输层安全（TLS）协议[RFC2246]提供。[RFC5730]中描述了EPP。[RFC0793]中描述了TCP。本文件淘汰了RFC 4934[RFC4934]。
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]中所述进行解释。
Mapping EPP session management facilities onto the TCP service is straightforward. An EPP session first requires creation of a TCP connection between two peers, one that initiates the connection request and one that responds to the connection request. The initiating peer is called the "client", and the responding peer is called the "server". An EPP server MUST listen for TCP connection requests on a standard TCP port assigned by IANA.
将EPP会话管理设施映射到TCP服务非常简单。EPP会话首先需要在两个对等方之间创建TCP连接，一个启动连接请求，另一个响应连接请求。发起方称为“客户机”，响应方称为“服务器”。EPP服务器必须在IANA分配的标准TCP端口上侦听TCP连接请求。
The client MUST issue an active OPEN call, specifying the TCP port number on which the server is listening for EPP connection attempts. The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established.
客户端必须发出活动的OPEN调用，指定服务器正在侦听EPP连接尝试的TCP端口号。TCP会话建立后，EPP服务器必须向客户端返回EPP<greeting>。
An EPP session is normally ended by the client issuing an EPP <logout> command. A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection with a CLOSE call. A client MAY end an EPP session by issuing a CLOSE call.
EPP会话通常由客户端发出EPP<logout>命令来结束。接收EPP<logout>命令的服务器必须结束EPP会话，并通过close调用关闭TCP连接。客户端可以通过发出关闭调用来结束EPP会话。
A server MAY limit the life span of an established TCP connection. EPP sessions that are inactive for more than a server-defined period MAY be ended by a server issuing a CLOSE call. A server MAY also close TCP connections that have been open and active for longer than a server-defined period.
服务器可能会限制已建立TCP连接的寿命。超过服务器定义的时间段处于非活动状态的EPP会话可能会由服务器发出关闭调用来结束。服务器还可以关闭已打开并处于活动状态超过服务器定义时间的TCP连接。
With the exception of the EPP server greeting, EPP messages are initiated by the EPP client in the form of EPP commands. An EPP server MUST return an EPP response to an EPP command on the same TCP connection that carried the command. If the TCP connection is closed after a server receives and successfully processes a command but before the response can be returned to the client, the server MAY attempt to undo the effects of the command to ensure a consistent state between the client and the server. EPP commands are idempotent, so processing a command more than once produces the same net effect on the repository as successfully processing the command once.
除EPP服务器问候语外，EPP消息由EPP客户端以EPP命令的形式启动。EPP服务器必须在承载该命令的同一TCP连接上返回对EPP命令的EPP响应。如果TCP连接在服务器接收并成功处理命令后，但在响应返回到客户端之前关闭，则服务器可能会尝试撤消命令的效果，以确保客户端和服务器之间的状态一致。EPP命令是幂等的，因此多次处理命令会在存储库中产生与成功处理命令一次相同的净效果。
An EPP client streams EPP commands to an EPP server on an established TCP connection. A client MUST NOT distribute commands from a single EPP session over multiple TCP connections. A client MAY establish multiple TCP connections to support multiple EPP sessions with each session mapped to a single connection. A server SHOULD limit a client to a maximum number of TCP connections based on server capabilities and operational load.
EPP客户端通过已建立的TCP连接将EPP命令流式传输到EPP服务器。客户端不得通过多个TCP连接分发来自单个EPP会话的命令。客户端可以建立多个TCP连接以支持多个EPP会话，每个会话映射到单个连接。服务器应根据服务器功能和操作负载将客户端限制为最大TCP连接数。
EPP describes client-server interaction as a command-response exchange where the client sends one command to the server and the server returns one response to the client. A client might be able to realize a slight performance gain by pipelining (sending more than one command before a response for the first command is received) commands with TCP transport, but this feature does not change the basic single command, single response operating mode of the core protocol.
EPP将客户机-服务器交互描述为命令-响应交换，其中客户机向服务器发送一个命令，服务器向客户机返回一个响应。客户机可能能够通过TCP传输管道化（在接收到第一个命令的响应之前发送多个命令）命令来实现轻微的性能提升，但此功能不会改变核心协议的基本单命令、单响应操作模式。
Each EPP data unit MUST contain a single EPP message. Commands MUST be processed independently and in the same order as sent from the client.
每个EPP数据单元必须包含一条EPP消息。命令必须独立处理，处理顺序与从客户端发送的顺序相同。
A server SHOULD impose a limit on the amount of time required for a client to issue a well-formed EPP command. A server SHOULD end an EPP session and close an open TCP connection if a well-formed command is not received within the time limit.
服务器应限制客户端发出格式良好的EPP命令所需的时间。如果在时间限制内未收到格式良好的命令，服务器应结束EPP会话并关闭打开的TCP连接。
A general state machine for an EPP server is described in Section 2 of [RFC5730]. General client-server message exchange using TCP transport is illustrated in Figure 1.
[RFC5730]第2节描述了EPP服务器的通用状态机。使用TCP传输的通用客户机-服务器消息交换如图1所示。
Client Server
| |
| Connect |
| >>------------------------------->> |
| |
| Send Greeting |
| <<-------------------------------<< |
| |
| Send <login> |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command X |
| >>------------------------------->> |
| |
| Send Command Y |
| >>---------------+ |
| | |
| | |
| Send Response X |
| <<---------------(---------------<< |
| | |
| | |
| +--------------->> |
| |
| Send Response Y |
| <<-------------------------------<< |
| |
| Send <logout> |
| >>------------------------------->> |
| |
| Send Response & Disconnect |
| <<-------------------------------<< |
| |
Client Server
| |
| Connect |
| >>------------------------------->> |
| |
| Send Greeting |
| <<-------------------------------<< |
| |
| Send <login> |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command X |
| >>------------------------------->> |
| |
| Send Command Y |
| >>---------------+ |
| | |
| | |
| Send Response X |
| <<---------------(---------------<< |
| | |
| | |
| +--------------->> |
| |
| Send Response Y |
| <<-------------------------------<< |
| |
| Send <logout> |
| >>------------------------------->> |
| |
| Send Response & Disconnect |
| <<-------------------------------<< |
| |
Figure 1: TCP Client-Server Message Exchange
图1:TCP客户机-服务器消息交换
The EPP data unit contains two fields: a 32-bit header that describes the total length of the data unit, and the EPP XML instance. The length of the EPP XML instance is determined by subtracting four octets from the total length of the data unit. A receiver must successfully read that many octets to retrieve the complete EPP XML instance before processing the EPP message.
EPP数据单元包含两个字段：描述数据单元总长度的32位标头和EPP XML实例。EPP XML实例的长度是通过从数据单元的总长度中减去四个八位字节来确定的。在处理EPP消息之前，接收方必须成功读取这么多个八位字节才能检索完整的EPP XML实例。
EPP Data Unit Format (one tick mark represents one bit position):
EPP数据单元格式（一个记号表示一位位置）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EPP XML Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EPP XML Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Total Length (32 bits): The total length of the EPP data unit measured in octets in network (big endian) byte order. The octets contained in this field MUST be included in the total length calculation.
总长度（32位）：EPP数据单元的总长度，以网络（大端）字节顺序的八位字节为单位。此字段中包含的八位字节必须包含在总长度计算中。
EPP XML Instance (variable length): The EPP XML instance carried in the data unit.
EPP XML实例（可变长度）：数据单元中携带的EPP XML实例。
Section 2.1 of the EPP core protocol specification [RFC5730] describes considerations to be addressed by protocol transport mappings. This document addresses each of the considerations using a combination of features described in this document and features provided by TCP as follows:
EPP核心协议规范[RFC5730]第2.1节描述了协议传输映射需要考虑的事项。本文档使用本文档中描述的功能和TCP提供的功能的组合解决了每个注意事项，如下所示：
- TCP includes features to provide reliability, flow control, ordered delivery, and congestion control. Section 1.5 of RFC 793 [RFC0793] describes these features in detail; congestion control principles are described further in RFC 2581 [RFC2581] and RFC 2914 [RFC2914]. TCP is a connection-oriented protocol, and Section 2 of this document describes how EPP sessions are mapped to TCP connections.
- TCP包括提供可靠性、流量控制、有序交付和拥塞控制的功能。RFC 793[RFC0793]第1.5节详细描述了这些特性；RFC 2581[RFC2581]和RFC 2914[RFC2914]中进一步描述了拥塞控制原理。TCP是一种面向连接的协议，本文档第2节描述了如何将EPP会话映射到TCP连接。
- Sections 2 and 3 of this document describe how the stateful nature of EPP is preserved through managed sessions and controlled message exchanges.
- 本文档的第2节和第3节描述了如何通过托管会话和受控消息交换来保持EPP的状态性质。
- Section 3 of this document notes that command pipelining is possible with TCP, though batch-oriented processing (combining multiple EPP commands in a single data unit) is not permitted.
- 本文档第3节指出，尽管不允许面向批处理（在单个数据单元中组合多个EPP命令），但TCP可以实现命令管道化。
- Section 4 of this document describes features to frame data units by explicitly specifying the number of octets used to represent a data unit.
- 本文档第4节通过明确指定用于表示数据单元的八位字节数来描述帧数据单元的功能。
This document does not introduce or present any internationalization or localization issues.
本文件不介绍或提出任何国际化或本地化问题。
System port number 700 has been assigned by the IANA for mapping EPP onto TCP.
IANA已分配系统端口号700，用于将EPP映射到TCP。
User port number 3121 (which was used for development and test purposes) has been reclaimed by the IANA.
IANA已回收用户端口号3121（用于开发和测试目的）。
EPP as-is provides only simple client authentication services using identifiers and plain text passwords. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial command forgery. Protection against most other common attacks MUST be provided by other layered protocols.
EPP原样仅提供使用标识符和纯文本密码的简单客户端身份验证服务。被动攻击足以恢复客户端标识符和密码，从而允许少量命令伪造。针对大多数其他常见攻击的保护必须由其他分层协议提供。
When layered over TCP, the Transport Layer Security (TLS) Protocol version 1.0 [RFC2246] or its successors (such as TLS 1.2 [RFC5246]), using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication. Implementations of TLS often contain a weak cryptographic mode that SHOULD NOT be used to protect EPP. Clients and servers desiring high security SHOULD instead use TLS with cryptographic algorithms that are less susceptible to compromise.
在TCP上分层时，必须使用传输层安全（TLS）协议版本1.0[RFC2246]或其后续版本（如TLS 1.2[RFC5246]），使用双方支持的最新版本，以提供完整性、机密性和相互强大的客户机-服务器身份验证。TLS的实现通常包含不应用于保护EPP的弱加密模式。需要高安全性的客户机和服务器应改为使用TLS和不易被破坏的加密算法。
Authentication using the TLS Handshake Protocol confirms the identity of the client and server machines. EPP uses an additional client identifier and password to identify and authenticate the client's user identity to the server, supplementing the machine authentication provided by TLS. The identity described in the client certificate and the identity described in the EPP client identifier can differ, as a server can assign multiple user identities for use from any particular client machine. Acceptable certificate identities MUST be
使用TLS握手协议的身份验证确认客户端和服务器机器的身份。EPP使用一个附加的客户端标识符和密码来向服务器标识和验证客户端的用户身份，以补充TLS提供的机器身份验证。客户端证书中描述的标识和EPP客户端标识符中描述的标识可能不同，因为服务器可以分配多个用户标识，以便从任何特定的客户端计算机使用。必须使用可接受的证书标识
negotiated between client operators and server operators using an out-of-band mechanism. Presented certificate identities MUST match negotiated identities before EPP service is granted.
使用带外机制在客户端操作员和服务器操作员之间协商。在授予EPP服务之前，提供的证书标识必须与协商的标识匹配。
There is a risk of login credential compromise if a client does not properly identify a server before attempting to establish an EPP session. Before sending login credentials to the server, a client needs to confirm that the server certificate received in the TLS handshake is an expected certificate for the server. A client also needs to confirm that the greeting received from the server contains expected identification information. After establishing a TLS session and receiving an EPP greeting on a protected TCP connection, clients MUST compare the certificate subject and/or subjectAltName to expected server identification information and abort processing if a mismatch is detected. If certificate validation is successful, the client then needs to ensure that the information contained in the received certificate and greeting is consistent and appropriate. As described above, both checks typically require an out-of-band exchange of information between client and server to identify expected values before in-band connections are attempted.
如果客户端在尝试建立EPP会话之前未正确标识服务器，则存在登录凭据泄露的风险。在向服务器发送登录凭据之前，客户端需要确认在TLS握手中接收的服务器证书是服务器的预期证书。客户端还需要确认从服务器接收的问候语是否包含预期的标识信息。在建立TLS会话并在受保护的TCP连接上接收EPP问候语后，客户端必须将证书主题和/或主题名称与预期的服务器标识信息进行比较，并在检测到不匹配时中止处理。如果证书验证成功，则客户端需要确保接收到的证书和问候语中包含的信息一致且适当。如上所述，在尝试带内连接之前，这两种检查通常都需要在客户端和服务器之间进行带外信息交换，以确定预期值。
EPP TCP servers are vulnerable to common TCP denial-of-service attacks including TCP SYN flooding. Servers SHOULD take steps to minimize the impact of a denial-of-service attack using combinations of easily implemented solutions, such as deployment of firewall technology and border router filters to restrict inbound server access to known, trusted clients.
EPP TCP服务器容易受到常见的TCP拒绝服务攻击，包括TCP SYN洪泛攻击。服务器应采取措施，结合使用易于实施的解决方案（如部署防火墙技术和边界路由器过滤器）将拒绝服务攻击的影响降至最低，以限制对已知可信客户端的入站服务器访问。
The client should initiate a connection to the server and then send the TLS Client Hello to begin the TLS handshake. When the TLS handshake has finished, the client can then send the first EPP message.
客户端应启动与服务器的连接，然后发送TLS客户端Hello以开始TLS握手。TLS握手完成后，客户端可以发送第一条EPP消息。
TLS implementations are REQUIRED to support the mandatory cipher suite specified in the implemented version:
TLS实施需要支持实施版本中指定的强制密码套件：
o TLS 1.0 [RFC2246]: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
o TLS 1.0[RFC2246]：TLS_DHE_DSS_与_3DES_EDE_CBC_SHA
o TLS 1.1 [RFC4346]: TLS_RSA_WITH_3DES_EDE_CBC_SHA
o TLS 1.1[RFC4346]：TLS_RSA_与_3DES_EDE_CBC_SHA
o TLS 1.2 [RFC5246]: TLS_RSA_WITH_AES_128_CBC_SHA
o TLS 1.2[RFC5246]：TLS_RSA_与_AES_128_CBC_SHA
This document is assumed to apply to future versions of TLS, in which case the mandatory cipher suite for the implemented version MUST be supported.
本文档假定适用于TLS的未来版本，在这种情况下，必须支持实施版本的强制密码套件。
Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED. Signatures on the complete certification path for both client machine and server machine MUST be validated as part of the TLS handshake. Information included in the client and server certificates, such as validity periods and machine names, MUST also be validated. A complete description of the issues associated with certification path validation can be found in RFC 5280 [RFC5280]. EPP service MUST NOT be granted until successful completion of a TLS handshake and certificate validation, ensuring that both the client machine and the server machine have been authenticated and cryptographic protections are in place.
需要使用TLS握手协议进行客户端和服务器的相互身份验证。客户端计算机和服务器计算机的完整认证路径上的签名必须作为TLS握手的一部分进行验证。还必须验证客户端和服务器证书中包含的信息，如有效期和计算机名称。有关认证路径验证相关问题的完整说明，请参见RFC 5280[RFC5280]。在成功完成TLS握手和证书验证之前，不得授予EPP服务，以确保客户端计算机和服务器计算机都已通过身份验证，并且密码保护已到位。
If the client has external information as to the expected identity of the server, the server name check MAY be omitted. For instance, a client may be connecting to a machine whose address and server name are dynamic, but the client knows the certificate that the server will present. In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man-in-the-middle attacks. In special cases, it might be appropriate for the client to simply ignore the server's identity, but it needs to be understood that this leaves the connection open to active attack.
如果客户机具有关于服务器预期标识的外部信息，则可以省略服务器名称检查。例如，客户机可能正在连接地址和服务器名称为动态的机器，但客户机知道服务器将提供的证书。在这种情况下，必须尽可能缩小可接受证书的范围，以防止中间人攻击。在特殊情况下，客户端可以忽略服务器的标识，但需要理解的是，这会使连接受到主动攻击。
During the TLS negotiation, the EPP client MUST check its understanding of the server name / IP address against the server's identity as presented in the server Certificate message in order to prevent man-in-the-middle attacks. In this section, the client's understanding of the server's identity is called the "reference identity". Checking is performed according to the following rules in the specified order:
在TLS协商期间，EPP客户端必须根据服务器证书消息中显示的服务器身份检查其对服务器名称/IP地址的理解，以防止中间人攻击。在本节中，客户机对服务器标识的理解称为“参考标识”。按照以下规则按指定顺序进行检查：
o If the reference identity is a server name:
o 如果引用标识是服务器名称：
* If a subjectAltName extension of the dNSName [CCITT.X509.1988] type is present in the server's certificate, then it SHOULD be used as the source of the server's identity. Matching is performed as described in Section 7.2 of [RFC5280], with the exception that wildcard matching (see below) is allowed for dNSName type. 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.
* 如果服务器的证书中存在dNSName[CCITT.X509.1988]类型的subjectAltName扩展名，则应将其用作服务器标识的源。按照[RFC5280]第7.2节所述执行匹配，但dNSName类型允许通配符匹配（见下文）除外。如果证书包含多个名称（例如，多个dNSName字段），则认为与任何一个字段的匹配都是可接受的。
* The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
* dNSName类型的subjectAltName值中允许使用“*”（ASCII 42）通配符，然后仅作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.example.com与服务器名a.example.com和b.example.com匹配，但与example.com或a.b.example.com不匹配。
* The server's identity MAY also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in bullet 1 above (including wildcard matching). Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention.
* 还可以通过将参考标识与服务器证书的subjectName字段的叶相对可分辨名称（RDN）中的公共名称（CN）[RFC4519]值进行比较来验证服务器的标识。使用上面项目符号1中的DNS名称比较规则（包括通配符匹配）执行此比较。虽然公共名称值的使用是现有的做法，但不推荐使用，并鼓励证书颁发机构提供subjectAltName值。注意，TLS实现可以根据X.500或其他约定在证书中表示DNs。例如，一些X.500实现使用从左到右（最重要到最不重要）约定而不是LDAP的从右到左约定对DN中的RDN进行排序。
o If the reference identity is an IP address:
o 如果参考标识是IP地址：
* The iPAddress subjectAltName SHOULD be used by the client for comparison. In such a case, the reference identity MUST be converted to the "network byte order" octet string representation. For IP Version 4 (as specified in RFC 791 [RFC0791]), the octet string will contain exactly four octets. For IP Version 6 (as specified in RFC 2460 [RFC2460]), the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
* 客户端应使用iPAddress subjectAltName进行比较。在这种情况下，必须将引用标识转换为“网络字节顺序”八位字节字符串表示形式。对于IP版本4（如RFC 791[RFC0791]中规定），八位字节字符串将正好包含四个八位字节。对于IP版本6（如RFC 2460[RFC2460]中规定），八位字节字符串将正好包含十六个八位字节。然后将此八位组字符串与iPAddress类型的subjectAltName值进行比较。如果引用标识八位字节字符串和值八位字节字符串相同，则会发生匹配。
If the server identity check fails, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the EPP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD return or log an error indicating that the server's identity is suspect and/or SHOULD close the transport connection. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.
如果服务器身份检查失败，面向用户的客户端应该通知用户（在这种情况下，客户端可能会给用户继续EPP会话的机会），或者关闭传输连接并指示服务器的身份可疑。自动客户端应返回或记录一个错误，指示服务器的标识可疑，和/或应关闭传输连接。自动客户端可以提供禁用此检查的配置设置，但必须提供启用此检查的设置。
During the TLS negotiation, the EPP server MUST verify that the client certificate matches the reference identity previously negotiated out of band, as specified in Section 8. The server should match the entire subject name or the subjectAltName as described in RFC 5280. The server MAY enforce other restrictions on the subjectAltName, for example if it knows that a particular client is always connecting from a particular hostname / IP address.
在TLS协商期间，EPP服务器必须验证客户端证书是否与先前在带外协商的参考标识相匹配，如第8节所述。服务器应匹配整个主题名或RFC 5280中描述的主题名。服务器可能会对subjectAltName实施其他限制，例如，如果它知道某个特定的客户端总是从特定的主机名/IP地址连接。
All EPP messages MUST be sent as TLS "application data". It is possible that multiple EPP messages are contained in one TLS record, or that an EPP message is transferred in multiple TLS records.
所有EPP消息必须作为TLS“应用程序数据”发送。一个TLS记录中可能包含多个EPP消息，或者一个EPP消息在多个TLS记录中传输。
When no data is received from a connection for a long time (where the application decides what "long" means), a server MAY close the connection. The server MUST attempt to initiate an exchange of close_notify alerts with the client before closing the connection. Servers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the client side.
当长时间没有从连接接收到数据时（应用程序决定“long”的含义），服务器可能会关闭连接。在关闭连接之前，服务器必须尝试与客户端交换close_notify警报。不准备接收更多数据的服务器可能会在发送close_notify警报后关闭连接，从而在客户端生成不完全关闭。
RFC 3734 is a product of the PROVREG working group, which suggested improvements and provided many invaluable comments. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions. RFC 4934 and this document are individual submissions, based on the work done in RFC 3734.
RFC 3734是PROVREG工作组的产品，该工作组提出了改进建议，并提供了许多宝贵的意见。作者希望感谢工作组主席Edward Lewis和Jaap Akkerhuis的工作过程和编辑贡献。RFC 4934和本文件是基于RFC 3734中所做工作的单独提交。
Specific suggestions that have been incorporated into this document were provided by Chris Bason, Randy Bush, Patrik Faltstrom, Ned Freed, James Gould, Dan Manley, and John Immordino.
Chris Bason、Randy Bush、Patrik Faltstrom、Ned Freed、James Gould、Dan Manley和John Immordino提供了纳入本文件的具体建议。
[CCITT.X509.1988] International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, November 1988.
[CCITT.X509.1988]国际电话电报咨询委员会，“信息技术-开放系统互连-目录：认证框架”，CCITT建议X.509，1988年11月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519]Sciberras，A.，“轻量级目录访问协议（LDAP）：用户应用程序模式”，RFC4519，2006年6月。
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009.
[RFC5730]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，STD 69，RFC 5730，2009年8月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4934] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport Over TCP", RFC 4934, May 2007.
[RFC4934]Hollenbeck，S.，“TCP上的可扩展供应协议（EPP）传输”，RFC 4934，2007年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[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, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
1. Changed "This document obsoletes RFC 3734" to "This document obsoletes RFC 4934".
1. 将“本文件淘汰RFC 3734”更改为“本文件淘汰RFC 4934”。
2. Replaced references to RFC 3280 with references to 5280.
2. 将对RFC 3280的引用替换为对5280的引用。
3. Replaced references to RFC 3734 with references to 4934.
3. 将对RFC 3734的引用替换为对4934的引用。
4. Updated references to RFC 4346 and TLS 1.1 with references to 5246 and TLS 1.2.
4. 更新了对RFC 4346和TLS 1.1的参考，其中参考了5246和TLS 1.2。
5. Replaced references to RFC 4930 with references to 5730.
5. 将对RFC 4930的引用替换为对5730的引用。
6. Added clarifying TLS Usage Profile section and included references.
6. 增加了澄清TLS使用概况部分和包含的参考资料。
7. Moved the paragraph that begins with "Mutual client and server authentication" from the Security Considerations section to the TLS Usage Profile section.
7. 将以“相互客户端和服务器身份验证”开头的段落从安全注意事项部分移至TLS使用概要文件部分。
Author's Address
作者地址
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com