EPP-基于TCP传输(RFC5734翻译)

本文档描述如何将可扩展配置协议(EPP)会话映射到单个传输控制协议(TCP)连接。这种映射需要使用传输层安全性( TLS)协议来保护EPP客户机和EPP服务器之间交换的信息。本文件废止RFC 4934。

2. 会话管理

1. 创建TCP连接
   客户端必须发出一个活动的OPEN呼叫，服务器必须在IANA分配的标准TCP端口(700)上侦听TCP连接请求。
   在TCP会话建立后，EPP服务器必须向客户端返回EPP <greeting>
2. 关闭TCP连接
   • 客户端发出EPP <logout>命令结束EPP会话。 接收EPP <logout>命令的服务器必须结束EPP会话并通过CLOSE呼叫关闭TCP连接。
   • 客户端发出CLOSE呼叫结束EPP会话。
   • 服务器发出CLOSE call终止TCP连接：EPP会话在服务器定义的时间段内一直处于非活动状态。
   • 服务器终止TCP连接：关闭打开和活动时间超过服务器定义的时间段。

3. 消息交换

                   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

• 除了EPP服务器greeting之外，EPP消息由EPP客户机以EPP命令的形式发起。
• EPP服务器必须在承载该命令的同一TCP连接上向EPP命令返回EPP响应。
• 如果TCP连接中断时，服务器的响应未返回给客户机，服务器可能尝试撤销命令的效果，以确保客户机和服务器之间的状态一致。
• EPP命令是幂等的，因此多次处理命令会对存储库产生与成功处理命令一次相同的净效果。
• EPP客户端在已建立的TCP连接上将EPP命令流式传输到EPP服务器。 客户端不得通过多个TCP连接从单个EPP会话分发命令。 客户端可以建立多个TCP连接以支持多个EPP会话，每个会话映射到单个连接。 服务器应该根据服务器功能和操作负载将客户端限制为最大TCP连接数。
• EPP将客户端 - 服务器交互描述为命令 - 响应交换，其中客户端向服务器发送一个命令，并且服务器向客户端返回一个响应。
• 客户端可能能够通过流水线技术（在收到第一个命令的响应之前发送多个命令）通过TCP传输实现轻微的性能提升，但此功能不会更改基本的单个命令、单个响应操作模式核心协议。
• 每个EPP数据单元必须包含单个EPP消息。 命令必须独立处理，处理顺序与客户端发送的顺序相同。
• 服务器应该对客户端发出格式良好的EPP命令所需的时间量施加限制。 如果在时间限制内没有收到格式正确的命令，服务器应该结束EPP会话并关闭打开的TCP连接。

4. 数据单元格式

EPP数据单元总长度，包含两个字段：

• 头：

  32位，描述数据单元总长度。
  EPP数据单元的总长度以网络(大端)字节顺序测量。该字段也包含在总长度计算中。

• EPP XML实例：

  长度可变，数据单元中携带的EPP XML实例。
  EPP XML实例的长度是通过从数据单元的总长度中减去四个字节来确定的。在处理EPP消息之前，接收方必须成功读取那么多字节才能检索完整的EPP XML实例。

  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                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  

总长度字段（32位）：记录EPP数据单元的总长度，以字节为单位，以网络字节顺序（大端字节顺序）计算。总长度必须包含该字段本身的字节数。
EPP XML实例（可变长度）：数据单元中携带的EPP XML实例。

5. 安全性考虑

EPP核心协议规范[RFC5730]的2.1节描述了协议传输映射要解决的注意事项。本文档通过结合本文档中描述的特性和TCP提供的特性来解决每一个注意事项，如下所示：

• TCP包括可靠性、流量控制、有序交付、拥塞控制等特性。rfc793 [RFC0793]第1.5节详细描述了这些特性;拥塞控制原理在RFC2581 [RFC2581]和RFC2914 [RFC2914]中有进一步的描述。TCP是一种面向连接的协议，本文档的第2节描述了如何将EPP会话映射到TCP连接。
• 本文档的第2节和第3节描述了如何通过托管会话和受控消息交换来保存EPP的有状态特性。
• 本文档的第3节指出，虽然不允许面向批处理(在单个数据单元中组合多个EPP命令)，但使用TCP可以实现命令管道。
• 本文档的第4节通过显式地指定用于表示数据单元的字节数来描述帧数据单元的特性。

6. 国际化考虑

本文档不引入或呈现任何国际化或本地化问题。

7. IANA考虑

IANA已分配系统端口号700，用于将EPP映射到TCP上。
用户端口号3121(用于开发和测试目的)已被IANA回收。

8. 传输安全

EPP 本身仅使用标识符和纯文本密码提供简单的客户端身份验证服务。 被动攻击足以恢复客户端标识符和密码，允许琐碎的命令伪造。 防止大多数其他常见攻击必须由其他分层协议提供。

当通过TCP分层时，传输层安全性（TLS）协议版本1.0 [RFC2246]或其后续版本（如TLS 1.2 [RFC5246] ），使用双方支持的最新版本，必须用于提供完整性，机密性和相互强大的客户端 - 服务器认证 TLS的实现通常包含弱加密模式，不应该用于保护EPP。 希望高安全性的客户端和服务器应该使用TLS和不易受损害的加密算法。

使用TLS握手协议进行身份验证可确认客户端和服务器计算机的身份。 EPP使用额外的客户端标识符和密码来识别和验证客户端对服务器的用户身份，补充TLS提供的机器身份验证。 客户端证书中描述的身份和EPP客户端标识符中描述的身份可以不同，因为服务器可以分配多个用户身份以供任何特定客户端计算机使用。 必须使用带外机制在客户端操作员和服务器操作员之间协商可接受的证书身份。 在授予EPP服务之前，提供的证书身份必须与协商的身份相匹配。

如果客户端在尝试建立EPP会话之前未正确识别服务器，则存在登录凭证受损的风险。 在将登录凭据发送到服务器之前，客户端需要确认在TLS握手中收到的服务器证书是服务器的预期证书。 客户端还需要确认从服务器接收的问候语包含预期的标识信息。 在建立TLS会话并在受保护的TCP连接上接收EPP问候语后，客户端必须将证书主题和/或subjectAltName与预期的服务器标识信息进行比较，并在检测到不匹配时进行中止处理。 如果证书验证成功，则客户端需要确保收到的证书和问候语中包含的信息是一致且适当的。 如上所述，两个检查通常需要在客户端和服务器之间进行带外信息交换，以在尝试带内连接之前识别期望值。

EPP TCP服务器容易受到常见的TCP拒绝服务攻击，包括TCP SYN泛洪。 服务器应该采取措施，使用易于实施的解决方案的组合来最小化拒绝服务攻击的影响，例如部署防火墙技术和边界路由器过滤器，以限制对已知的可信客户端的入站服务器访问。

9. TLS 使用配置

客户端应该发起到服务器的连接，然后发送TLS客户端Hello来开始TLS握手。当TLS握手完成后，客户机就可以发送第一个EPP消息。

TLS实现必须支持已实现版本中指定的强制加密套件：

• TLS 1.0 [RFC2246]: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS 1.1 [RFC4346]: TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS 1.2 [RFC5246]: TLS_RSA_WITH_AES_128_CBC_SHA

本文档假定适用于TLS的未来版本，在这种情况下，必须支持实现版本的强制密码套件。

客户端和服务器之间必须使用TLS握手协议进行相互认证。客户端机器和服务器机器的完整认证路径上的签名必须作为TLS握手的一部分进行验证。客户机和服务器证书中包含的信息(如有效期和机器名称)也必须进行验证。与认证路径验证相关的问题的完整描述可以在RFC5280 [RFC5280]中找到。在成功完成TLS握手和证书验证之前，绝对不能授予EPP服务，确保客户端机器和服务器机器都已经过身份验证，并且加密保护到位。

如果客户端有关于预期的服务器标识的外部信息，服务器名称检查可以省略。例如，客户端可能连接到一台地址和服务器名是动态的机器，但是客户端知道服务器将提供的证书。在这种情况下，重要的是要尽可能地缩小可接受证书的范围，以防止中间人攻击。在特殊情况下，客户机可能适当地忽略服务器的标识，但需要理解的是，这将使连接容易受到主动攻击。

在TLS协商过程中，EPP客户端必须根据服务器证书消息中提供的服务器身份来检查其对服务器名称/ IP地址的理解，以防止中间人攻击。在本节中，客户机对服务器标识的理解称为“引用标识”。检查的顺序如下：

• 如果引用标识是一个服务器名称：
  • 如果服务器的证书中存在dNSName [ccit . x509 .1988]类型的subjectAltName扩展名，那么应该将其用作服务器标识的源。匹配如[RFC5280]章节7.2所述，除了通配符匹配(见下文)允许用于dNSName类型。如果证书包含多个名称(例如，多个dNSName字段)，那么与任何一个字段的匹配都被认为是可接受的。
  • '’ (ASCII 42)通配符允许在dNSName类型的subjectAltName值中使用，并且只能作为该值中最左边(最不重要)的DNS标签。这个通配符匹配服务器名称中最左边的DNS标签。也就是说，主题.example.com匹配服务器名称a.example.com和b.example.com，但不匹配example.com或a.b.example.com。
  • 服务器的身份也可以通过与服务器证书的subjectName字段的叶子相对区别名(RDN)中的公共名称(CN) [RFC4519]值进行比较来验证。这个比较是使用上面项目1中的DNS名称比较规则(包括通配符匹配)来执行的。虽然使用Common Name值是现有的实践，但不建议使用，建议证书颁发机构提供subjectAltName值。注意，TLS实现可以根据X.500或其他约定在证书中表示DNs。例如，一些X.500实现使用从左到右(最重要的到最不重要的)约定来排序DN中的rdn，而不是使用从右到左的约定。
• 如果引用标识是IP地址：
  • iPAddress subjectAltName应该被客户端用于比较。在这种情况下，引用标识必须转换为“网络字节顺序”八位字符串表示。对于IP版本4(在rfc791 [RFC0791]中指定)，字节串将恰好包含四个字节。对于IP版本6(在RFC2460 [RFC2460]中指定)，八位字符串将包含正好16个八位。然后将这个八位字符串与iPAddress类型的subjectAltName值进行比较。如果引用标识字节串和值字节串完全相同，则发生匹配。

如果服务器身份检查失败，面向用户的客户端应该通知用户(在这种情况下，客户端可能给用户继续EPP会话的机会)，或者关闭传输连接并指出服务器的身份可疑。自动化客户端应该返回或记录一个错误，表明服务器的标识可疑和/或应该关闭传输连接。自动化客户端可以提供禁用此检查的配置设置，但必须提供启用此检查的设置。

在TLS协商期间，EPP服务器必须验证客户端证书是否与之前在带外协商的引用标识匹配，如第8节中所指定的。服务器应该匹配RFC 5280中描述的整个主题名称或subjectAltName。服务器可能对subjectAltName实施其他限制，例如，如果它知道特定的客户机总是从特定的主机名/ IP地址连接。

所有EPP消息必须作为TLS“应用程序数据”发送。一个TLS记录中可能包含多个EPP消息，或者一个EPP消息在多个TLS记录中传输。

当长时间没有从连接接收到数据时(应用程序决定“长”的含义)，服务器可能会关闭连接。在关闭连接之前，服务器必须尝试与客户端发起一个close_notify警报交换。没有准备接收更多数据的服务器可能会在发送close_notify警报后关闭连接，从而在客户端生成一个不完整的关闭。