Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 7481 Verisign Labs
Category: Standards Track N. Kong
ISSN: 2070-1721 CNNIC
March 2015
Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 7481 Verisign Labs
Category: Standards Track N. Kong
ISSN: 2070-1721 CNNIC
March 2015
Security Services for the Registration Data Access Protocol (RDAP)
注册数据访问协议（RDAP）的安全服务
Abstract
摘要
The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.
注册数据访问协议（RDAP）提供“RESTful”web服务，从域名和区域Internet注册中心检索注册元数据。本文档描述了信息安全服务，包括RDAP的访问控制、身份验证、授权、可用性、数据机密性和数据完整性。
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/rfc7481.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7481.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3
3. Information Security Services and RDAP . . . . . . . . . . . 3
3.1. Access Control . . . . . . . . . . . . . . . . . . . . . 3
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. Federated Authentication . . . . . . . . . . . . . . 4
3.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Availability . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Data Confidentiality . . . . . . . . . . . . . . . . . . 7
3.6. Data Integrity . . . . . . . . . . . . . . . . . . . . . 7
4. Privacy Threats Associated with Registration Data . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3
3. Information Security Services and RDAP . . . . . . . . . . . 3
3.1. Access Control . . . . . . . . . . . . . . . . . . . . . 3
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. Federated Authentication . . . . . . . . . . . . . . 4
3.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Availability . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Data Confidentiality . . . . . . . . . . . . . . . . . . 7
3.6. Data Integrity . . . . . . . . . . . . . . . . . . . . . 7
4. Privacy Threats Associated with Registration Data . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
The Registration Data Access Protocol (RDAP) is specified in multiple documents, including "Registration Data Access Protocol (RDAP) Query Format" [RFC7482], "JSON Responses for the Registration Data Access Protocol (RDAP)" [RFC7483], and "HTTP Usage in the Registration Data Access Protocol (RDAP)" [RFC7480].
注册数据访问协议（RDAP）在多个文档中指定，包括“注册数据访问协议（RDAP）查询格式”[RFC7482]、“注册数据访问协议（RDAP）的JSON响应”[RFC7483]和“注册数据访问协议（RDAP）中的HTTP用法”[RFC7480]。
One goal of RDAP is to provide security services that do not exist in the WHOIS [RFC3912] protocol, including access control, authentication, authorization, availability, data confidentiality, and data integrity. This document describes how each of these services is achieved by RDAP using features that are available in other protocol layers. Additional or alternative mechanisms can be added in the future. Where applicable, informative references to requirements for a WHOIS replacement service [RFC3707] are noted.
RDAP的一个目标是提供WHOIS[RFC3912]协议中不存在的安全服务，包括访问控制、身份验证、授权、可用性、数据机密性和数据完整性。本文档描述了RDAP如何使用其他协议层中可用的功能实现这些服务。将来可以添加其他或替代机制。在适用的情况下，注明WHOIS更换服务[RFC3707]要求的参考资料。
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]中所述进行解释。
DNR: Domain Name Registry
域名注册
HTTP: Hypertext Transfer Protocol
HTTP：超文本传输协议
JSON: JavaScript Object Notation
JSON:JavaScript对象表示法
RDAP: Registration Data Access Protocol
注册数据访问协议
RIR: Regional Internet Registry
RIR：区域互联网注册处
TLS: Transport Layer Security
传输层安全
RDAP itself does not include native security services. Instead, RDAP relies on features that are available in other protocol layers to provide needed security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity. A description of each of these security services can be found in "Internet Security Glossary, Version 2" [RFC4949]. No requirements have been identified for other security services.
RDAP本身不包括本机安全服务。相反，RDAP依赖于其他协议层中可用的功能来提供所需的安全服务，包括访问控制、身份验证、授权、可用性、数据机密性和数据完整性。这些安全服务的描述可在“Internet安全词汇表，版本2”[RFC4949]中找到。尚未确定其他安全服务的要求。
WHOIS does not include specific features to control access to registration information. As described in the following sections, RDAP includes features to identify, authenticate, and authorize clients, allowing server operators to control access to information based on a client's identity and associated authorizations. Information returned to a client can be clearly marked with a status value (see Section 10.2.2 of [RFC7483]) that identifies the access granted to the client.
WHOIS不包括控制注册信息访问的特定功能。如以下章节所述，RDAP包括识别、验证和授权客户端的功能，允许服务器操作员根据客户端的身份和相关授权控制对信息的访问。返回给客户的信息可以清楚地标记为状态值（见[RFC7483]第10.2.2节），该状态值标识授予客户的访问权限。
This section describes security authentication mechanisms and the need for authorization policies to include them. It describes requirements for the implementations of clients and servers but does not dictate the policies of server operators. For example, a server operator with no policy regarding differentiated or tiered access to data will have no authorization mechanisms and will have no need for any type of authentication. A server operator with policies on differentiated access will have to construct an authorization scheme and will need to follow the specified authentication requirements.
本节介绍安全身份验证机制以及授权策略包含这些机制的必要性。它描述了客户机和服务器实现的要求，但没有规定服务器操作员的策略。例如，没有针对数据的差异化或分层访问策略的服务器运营商将没有授权机制，也不需要任何类型的身份验证。具有区分访问策略的服务器运营商必须构建授权方案，并且需要遵循指定的身份验证要求。
WHOIS does not provide features to identify and authenticate clients. As noted in Section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP) Requirements" [RFC3707], there is utility in allowing server operators to offer "varying degrees of access depending on policy and need." Clients have to be identified and authenticated to provide that utility.
WHOIS不提供识别和验证客户端的功能。如“跨注册表互联网服务协议（CRISP）要求”[RFC3707]第3.1.4.2节所述，允许服务器运营商“根据策略和需要提供不同程度的访问”是有用的。必须识别和验证客户端以提供该实用程序。
RDAP's authentication framework needs to accommodate anonymous access as well as verification of identities using a range of authentication methods and credential services. To that end, RDAP clients and servers MUST implement the authentication framework specified in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]. The "basic" scheme can be used to send a client's user name and password to a server in plaintext, base64-encoded form. The "digest" scheme can be used to authenticate a client without exposing the client's plaintext password. If the "basic" scheme is used, HTTP over TLS [RFC2818] MUST be used to protect the client's credentials from disclosure while in transit (see Section 3.5).
RDAP的身份验证框架需要适应匿名访问以及使用一系列身份验证方法和凭证服务验证身份。为此，RDAP客户端和服务器必须实现“超文本传输协议（HTTP/1.1）：身份验证”[RFC7235]中指定的身份验证框架。“基本”方案可用于将客户端的用户名和密码以明文base64编码形式发送到服务器。“摘要”方案可用于对客户端进行身份验证，而无需公开客户端的明文密码。如果使用“基本”方案，则必须使用HTTP over TLS[RFC2818]来保护客户的凭证在传输过程中不被泄露（参见第3.5节）。
Servers MUST support either Basic or Digest authentication; they are not required to support both. Clients MUST support both to interoperate with servers that support one or the other. Servers may provide a login page that triggers HTTP authentication. Clients should continue sending the HTTP authentication header once they receive an initial 401 (Unauthorized) response from the HTTP server as long as the scheme portion of the URL doesn't change.
服务器必须支持基本或摘要身份验证；它们不需要同时支持这两个方面。客户端必须同时支持这两者，才能与支持这两者的服务器进行互操作。服务器可以提供触发HTTP身份验证的登录页面。只要URL的scheme部分没有更改，客户端在收到HTTP服务器的初始401（未经授权）响应后应继续发送HTTP身份验证标头。
The Transport Layer Security protocol [RFC5246] includes an optional feature to identify and authenticate clients who possess and present a valid X.509 digital certificate [RFC5280]. Support for this feature is OPTIONAL.
传输层安全协议[RFC5246]包括一个可选功能，用于识别和验证拥有并提供有效X.509数字证书[RFC5280]的客户端。对该功能的支持是可选的。
RDAP does not impose any unique server authentication requirements. The server authentication provided by TLS fully addresses the needs of RDAP. In general, transports for RDAP must either provide a TLS-protected transport (e.g., HTTPS) or a mechanism that provides an equivalent level of server authentication.
RDAP不强加任何唯一的服务器身份验证要求。TLS提供的服务器身份验证完全满足了RDAP的需求。通常，RDAP的传输必须提供TLS保护的传输（例如HTTPS）或提供同等级别的服务器身份验证的机制。
Work on HTTP authentication methods continues. RDAP is designed to be agile enough to support additional methods as they are defined.
HTTP身份验证方法的工作仍在继续。RDAP的设计足够灵活，可以支持定义的其他方法。
The traditional client-server authentication model requires clients to maintain distinct credentials for every RDAP server. This situation can become unwieldy as the number of RDAP servers increases. Federated authentication mechanisms allow clients to use one credential to access multiple RDAP servers and reduce client
传统的客户机-服务器身份验证模型要求客户机为每个RDAP服务器维护不同的凭据。随着RDAP服务器数量的增加，这种情况可能会变得难以处理。联合身份验证机制允许客户端使用一个凭据访问多个RDAP服务器，并减少客户端访问量
credential management complexity. RDAP MAY include a federated authentication mechanism that permits a client to access multiple RDAP servers in the same federation with one credential.
凭证管理的复杂性。RDAP可以包括联邦身份验证机制，该机制允许客户端使用一个凭证访问同一联邦中的多个RDAP服务器。
Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP. OAuth, OpenID, Security Assertion Markup Language (SAML), and mechanisms based on Certification Authority (CA) are all possible approaches to provide federated authentication. At the time of this document's publication, negotiation or advertisement of federated authentication services is still an undefined mechanism by the noted federated authentication protocols. Developing this mechanism is beyond the scope of this document.
HTTP必须完全支持RDAP使用的联合身份验证机制。OAuth、OpenID、安全断言标记语言（SAML）和基于证书颁发机构（CA）的机制都是提供联合身份验证的可能方法。在本文档发布时，联邦身份验证服务的协商或公布仍然是未定义的机制。开发这一机制超出了本文件的范围。
The OAuth authorization framework [RFC6749] describes a method for users to access protected web resources without having to hand out their credentials. Instead, clients are issued access tokens by authorization servers with the permission of the resource owners. Using OAuth, multiple RDAP servers can form a federation, and the clients can access any server in the same federation by providing one credential registered in any server in that federation. The OAuth authorization framework is designed for use with HTTP and thus can be used with RDAP.
OAuth授权框架[RFC6749]描述了一种用户访问受保护的web资源的方法，而无需交出他们的凭证。相反，授权服务器在资源所有者的许可下向客户端颁发访问令牌。使用OAuth，多个RDAP服务器可以组成一个联合体，客户端可以通过提供在该联合体的任何服务器中注册的一个凭据来访问同一联合体中的任何服务器。OAuth授权框架设计用于HTTP，因此可以与RDAP一起使用。
OpenID [OpenID] is a decentralized single sign-on authentication system that allows users to log in at multiple web sites with one ID instead of having to create multiple unique accounts. An end user can freely choose which OpenID provider to use and can preserve their Identifier if they switch OpenID providers.
OpenID[OpenID]是一个分散的单点登录身份验证系统，允许用户使用一个ID登录多个网站，而无需创建多个唯一帐户。最终用户可以自由选择使用哪个OpenID提供程序，如果切换OpenID提供程序，则可以保留其标识符。
Note that OAuth and OpenID do not consistently require data confidentiality services to protect interactions between providers and consumers. HTTP over TLS [RFC2818] can be used as needed to provide protection against man-in-the-middle attacks.
注意，OAuth和OpenID并不总是要求数据保密服务来保护提供者和使用者之间的交互。TLS上的HTTP[RFC2818]可以根据需要提供保护，防止中间人攻击。
SAML 2.0 [SAML] is an XML-based protocol that can be used to implement web-based authentication and authorization services, including single sign on. It uses security tokens containing assertions to exchange information about an end user between an identity provider and a service provider.
SAML2.0[SAML]是一种基于XML的协议，可用于实现基于web的身份验证和授权服务，包括单点登录。它使用包含断言的安全令牌在身份提供者和服务提供者之间交换有关最终用户的信息。
The Transport Layer Security protocol describes the specification of a client certificate in Section 7.4.6 of [RFC5246]. Clients who possess and present a valid X.509 digital certificate, issued by a CA, could be identified and authenticated by a server who trusts the corresponding CA. A certificate authentication method can be used to achieve federated authentication in which multiple RDAP servers all trust the same CAs, and then any client with a certificate issued by a trusted CA can access any RDAP server in the federation. This
传输层安全协议描述了[RFC5246]第7.4.6节中的客户端证书规范。拥有并提供由CA颁发的有效X.509数字证书的客户端可由信任相应CA的服务器进行识别和身份验证。证书身份验证方法可用于实现联合身份验证，其中多个RDAP服务器都信任同一CA，然后，任何拥有可信CA颁发的证书的客户端都可以访问联合体中的任何RDAP服务器。这
certificate-based mechanism is supported by HTTPS and can be used with RDAP.
HTTPS支持基于证书的机制，并可与RDAP一起使用。
WHOIS does not provide services to grant different levels of access to clients based on a client's authenticated identity. As noted in Section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP) Requirements" [RFC3707], there is utility in allowing server operators to offer "varying degrees of access depending on policy and need." Access control decisions can be made once a client's identity has been established and authenticated (see Section 3.2).
WHOIS不提供基于客户端的身份验证授予不同级别的客户端访问权限的服务。如“跨注册表互联网服务协议（CRISP）要求”[RFC3707]第3.1.4.2节所述，允许服务器运营商“根据策略和需要提供不同程度的访问”是有用的。一旦客户身份被确定和验证，就可以做出访问控制决策（见第3.2节）。
Server operators MAY offer varying degrees of access depending on policy and need in conjunction with the authentication methods described in Section 3.2. If such varying degrees of access are supported, an RDAP server MUST provide granular access controls (that is, per registration data object) in order to implement authorization policies. Some examples:
服务器运营商可根据策略和需要以及第3.2节所述的认证方法提供不同程度的访问。如果支持这种不同程度的访问，RDAP服务器必须提供细粒度的访问控制（即每个注册数据对象），以便实现授权策略。一些例子：
- Clients will be allowed access only to data for which they have a relationship.
- 客户端将只允许访问与其有关系的数据。
- Unauthenticated or anonymous access status may not yield any contact information.
- 未经验证或匿名访问状态可能不会产生任何联系信息。
- Full access may be granted to a special group of authenticated clients.
- 可以将完全访问权限授予一组经过身份验证的特殊客户端。
The type of access allowed by a server will most likely vary from one operator to the next. A description of the response privacy considerations associated with different levels of authorization can be found in Section 13 of [RFC7483].
服务器允许的访问类型很可能因运营商而异。与不同授权级别相关的响应隐私注意事项说明见[RFC7483]第13节。
An RDAP service has to be available to be useful. There are no RDAP-unique requirements to provide availability, but as a general security consideration, a service operator needs to be aware of the issues associated with denial of service. A thorough reading of "Internet Denial-of-Service Considerations" [RFC4732] is advised.
RDAP服务必须可用才能发挥作用。RDAP没有提供可用性的独特要求，但作为一般安全考虑，服务运营商需要了解与拒绝服务相关的问题。建议全面阅读“互联网拒绝服务注意事项”[RFC4732]。
An RDAP service MAY use an HTTP throttling mechanism to limit the number of queries that a single client can send in a given period of time. If used, the server SHOULD return an HTTP 429 (Too Many Requests) response code as described in "Additional HTTP Status Codes" [RFC6585]. A client that receives a 429 response SHOULD decrease its query rate and honor the Retry-After header field if one
RDAP服务可以使用HTTP限制机制来限制单个客户端在给定时间段内可以发送的查询数。如果使用，服务器应返回“附加HTTP状态代码”[RFC6585]中所述的HTTP 429（太多请求）响应代码。收到429响应的客户机应降低其查询速率，并在出现以下情况时遵守“重试后”标题字段
is present. Note that this is not a defense against denial-of-service attacks, since a malicious client could ignore the code and continue to send queries at a high rate. A server might use another response code if it did not wish to reveal to a client that rate limiting is the reason for the denial of a reply.
他在场。请注意，这不是针对拒绝服务攻击的防御措施，因为恶意客户端可能会忽略代码并继续以高速率发送查询。如果服务器不希望向客户端透露速率限制是拒绝回复的原因，则可能会使用另一个响应代码。
WHOIS does not provide the ability to protect data from inadvertent disclosure while in transit. RDAP uses HTTP over TLS [RFC2818] to provide that protection by encrypting all traffic sent on the connection between client and server. HTTP over TLS MUST be used to protect all client-server exchanges unless operational constraints make it impossible to meet this requirement. It is also possible to encrypt discrete objects (such as command path segments and JSON-encoded response objects) at one endpoint, send them to the other endpoint via an unprotected transport protocol, and decrypt the object on receipt. Encryption algorithms as described in "Internet Security Glossary, Version 2" [RFC4949] are commonly used to provide data confidentiality at the object level.
WHOIS不提供在传输过程中保护数据不被无意泄露的能力。RDAP使用HTTP over TLS[RFC2818]通过加密客户端和服务器之间连接上发送的所有通信量来提供这种保护。必须使用HTTP over TLS来保护所有客户机-服务器交换，除非操作限制使其无法满足此要求。还可以在一个端点加密离散对象（如命令路径段和JSON编码的响应对象），通过不受保护的传输协议将它们发送到另一个端点，并在接收时解密对象。“Internet安全术语表，版本2”[RFC4949]中描述的加密算法通常用于在对象级别提供数据机密性。
There are no current requirements for object-level data confidentiality using encryption. Support for this feature could be added to RDAP in the future.
对于使用加密的对象级数据保密性，目前没有任何要求。对该特性的支持可以在将来添加到RDAP中。
As noted in Section 3.2, the HTTP "basic" authentication scheme can be used to authenticate a client. When this scheme is used, HTTP over TLS MUST be used to protect the client's credentials from disclosure while in transit. If the policy of the server operator requires encryption to protect client-server data exchanges (such as to protect non-public data that cannot be accessed without client identification and authentication), HTTP over TLS MUST be used to protect those exchanges.
如第3.2节所述，HTTP“基本”身份验证方案可用于对客户端进行身份验证。使用此方案时，必须使用HTTP over TLS来保护客户端的凭据在传输过程中不被泄露。如果服务器运营商的策略要求加密以保护客户机-服务器数据交换（例如保护在没有客户机标识和身份验证的情况下无法访问的非公共数据），则必须使用HTTP over TLS来保护这些交换。
A description of privacy threats that can be addressed with confidentiality services can be found in Section 4. Section 10.2.2 of [RFC7483] describes status values that can be used to describe operator actions used to protect response data from disclosure to unauthorized clients.
第4节介绍了可通过保密服务解决的隐私威胁。[RFC7483]第10.2.2节描述了可用于描述操作员操作的状态值，操作员操作用于保护响应数据不被泄露给未经授权的客户端。
WHOIS does not provide the ability to protect data from modification while in transit. Web services such as RDAP commonly use HTTP over TLS [RFC2818] to provide that protection by using a keyed Message Authentication Code (MAC) to detect modifications. It is also possible to sign discrete objects (such as command path segments and JSON-encoded response objects) at one endpoint, send them to the
WHOIS不提供在传输过程中保护数据不被修改的能力。诸如RDAP之类的Web服务通常使用HTTP over TLS[RFC2818]通过使用密钥消息身份验证码（MAC）检测修改来提供这种保护。还可以在一个端点对离散对象（如命令路径段和JSON编码的响应对象）进行签名，然后将它们发送到
other endpoint via a transport protocol, and validate the signature of the object on receipt. Digital signature algorithms as described in "Internet Security Glossary, Version 2" [RFC4949] are commonly used to provide data integrity at the object level.
其他端点通过传输协议，并在接收时验证对象的签名。“Internet安全术语表，版本2”[RFC4949]中描述的数字签名算法通常用于在对象级别提供数据完整性。
There are no current requirements for object-level data integrity using digital signatures. Support for this feature could be added to RDAP in the future.
对于使用数字签名的对象级数据完整性，目前没有任何要求。对该特性的支持可以在将来添加到RDAP中。
The most specific need for this service is to provide assurance that HTTP 30x redirection hints [RFC7231] and response elements returned from the server are not modified while in transit. If the policy of the server operator requires message integrity for client-server data exchanges, HTTP over TLS MUST be used to protect those exchanges.
此服务最具体的需求是确保HTTP 30x重定向提示[RFC7231]和从服务器返回的响应元素在传输过程中不会被修改。如果服务器操作员的策略要求客户端-服务器数据交换具有消息完整性，则必须使用HTTP over TLS来保护这些交换。
Registration data has historically included personal data about registrants. WHOIS services have historically made this information available to the public, creating a privacy risk by revealing the personal details of registrants. WHOIS services have not had the benefit of authentication or access control mechanisms to gate access to registration data. As a result of this, proxy and privacy services have arisen to shield the identities of registrants.
注册数据历来包括注册人的个人数据。WHOIS服务历来向公众提供这些信息，通过披露注册人的个人详细信息造成了隐私风险。WHOIS服务没有使用身份验证或访问控制机制来阻止对注册数据的访问。因此，代理和隐私服务应运而生，以保护注册人的身份。
The standardization of RDAP does not change or impact the data that operators may require to be collected from registrants, but it provides support for a number of mechanisms that may be used to mitigate privacy threats to registrants should operators choose to use them.
RDAP的标准化不会改变或影响运营商可能需要从注册人处收集的数据，但它提供了一系列机制的支持，这些机制可用于在运营商选择使用注册人时缓解对注册人的隐私威胁。
RDAP includes mechanisms that can be used to authenticate clients, allowing servers to support tiered access based on local policy. This means that all registration data need no longer be public, and personal data or data that may be considered more sensitive can have its access restricted to specifically privileged clients.
RDAP包括可用于对客户端进行身份验证的机制，允许服务器支持基于本地策略的分层访问。这意味着所有注册数据不再需要公开，个人数据或可能被认为更敏感的数据可以限制特定特权客户访问。
RDAP data structures allow servers to indicate via status values when data returned to clients has been made private, redacted, obscured, or registered by a proxy. "Private" means that the data is not designated for public consumption. "Redacted" means that some registration data fields are not being made available. "Obscured" means that data has been altered for the purposes of not readily revealing the actual registration information. One option that operators have available to them to reduce privacy risks to registrants is to adopt policies that make use of these status values to restrict the registrant data shared with any or all clients
RDAP数据结构允许服务器在返回给客户端的数据被代理设置为私有、编辑、隐藏或注册时通过状态值进行指示。“私人”是指数据未指定用于公共消费。“修订”表示某些注册数据字段不可用。“模糊”是指为了不容易披露实际注册信息而对数据进行了修改。运营商为降低注册人的隐私风险而提供的一种选择是，采用利用这些状态值的政策来限制与任何或所有客户共享的注册人数据
according to the sensitivity of the data, the privileges of the clients, or some other heuristics.
根据数据的敏感性、客户端的权限或其他一些启发式方法。
RDAP uses the jCard [RFC7095] standard format for entity representation. Operators may find that many of the jCard fields are irrelevant for registry operation purposes or that they have no reason to collect information from registrants that would correspond to certain fields. Operators wishing to reduce privacy risks for registrants may restrict which information they collect and/or which fields they populate in responses.
RDAP使用jCard[RFC7095]标准格式表示实体。操作员可能会发现许多jCard字段与注册表操作目的无关，或者他们没有理由从注册人处收集与某些字段对应的信息。希望降低注册人隐私风险的运营商可能会限制他们收集哪些信息和/或在回复中填写哪些字段。
In addition to privacy risks to registrants, there are also potential privacy risks for those who query registration data. For example, the fact that a registry employee performs a particular query may reveal information about the employee's activities that he or she would have preferred to keep private. RDAP supports the use of HTTP over TLS to provide privacy protection for those querying registrant data as well as registrants, unless operational constraints make it impossible to meet this requirement.
除了注册人的隐私风险外，查询注册数据的人也存在潜在的隐私风险。例如，登记处员工执行特定查询的事实可能会透露有关员工活动的信息，而他或她本希望将这些信息保密。RDAP支持使用HTTP over TLS为查询注册人数据以及注册人提供隐私保护，除非操作限制使其无法满足此要求。
One of the goals of RDAP is to provide security services that do not exist in the WHOIS protocol. This document describes the security services provided by RDAP and associated protocol layers, including authentication, authorization, availability, data confidentiality, and data integrity. Non-repudiation services were also considered and ultimately rejected due to a lack of requirements. There are, however, currently deployed WHOIS servers that can return signed responses that provide non-repudiation with proof of origin. RDAP might need to be extended to provide this service in the future.
RDAP的目标之一是提供WHOIS协议中不存在的安全服务。本文档描述了RDAP和相关协议层提供的安全服务，包括身份验证、授权、可用性、数据机密性和数据完整性。还考虑了不可否认性服务，最终由于缺乏要求而被拒绝。但是，目前部署的WHOIS服务器可以返回签名响应，这些响应提供不可否认性和来源证明。将来可能需要扩展RDAP以提供此服务。
As an HTTP-based protocol, RDAP is susceptible to code injection attacks. Code injection refers to adding code into a computer system or program to alter the course of execution. There are many types of code injection, including SQL injection, dynamic variable or function injection, include-file injection, shell injection, and HTML-script injection, among others. Data confidentiality and integrity services provide a measure of defense against man-in-the-middle injection attacks, but vulnerabilities in both client- and server-side software make it possible for injection attacks to succeed. Consistently checking and validating server credentials can help detect man-in-the-middle attacks.
作为一种基于HTTP的协议，RDAP容易受到代码注入攻击。代码注入是指将代码添加到计算机系统或程序中以改变执行过程。有许多类型的代码注入，包括SQL注入、动态变量或函数注入、文件注入、shell注入和HTML脚本注入等。数据机密性和完整性服务提供了一种防御中间人注入攻击的措施，但客户端和服务器端软件中的漏洞使注入攻击有可能成功。一致地检查和验证服务器凭据有助于检测中间人攻击。
As noted in Section 3.2.1, digital certificates can be used to implement federated authentication. There is a risk of too promiscuous, or even rogue, CAs being included in the list of acceptable CAs that the TLS server sends the client as part of the
如第3.2.1节所述，数字证书可用于实现联合身份验证。TLS服务器向客户机发送的可接受CA列表中包含的CA可能过于杂乱，甚至流氓
TLS client-authentication handshake and lending the appearance of trust to certificates signed by those CAs. Periodic monitoring of the list of CAs that RDAP servers trust for client authentication can help reduce this risk.
TLS客户端身份验证握手，并使这些CA签署的证书看起来可信。定期监视RDAP服务器信任用于客户端身份验证的CA列表有助于降低此风险。
The Transport Layer Security protocol [RFC5246] includes a null cipher suite that does not encrypt data and thus does not provide data confidentiality. This option MUST NOT be used when data confidentiality services are needed. Additional considerations for secure use of TLS are described in [SECURE-TLS-DTLS].
传输层安全协议[RFC5246]包括一个空密码套件，该套件不加密数据，因此不提供数据机密性。当需要数据保密服务时，不得使用此选项。[secure-TLS-DTLS]中描述了安全使用TLS的其他注意事项。
Data integrity services are sometimes mistakenly associated with directory service operational policy requirements focused on data accuracy. "Accuracy" refers to the truthful association of data elements (such as names, addresses, and telephone numbers) in the context of a particular directory object (such as a domain name). Accuracy requirements are out of scope for this protocol.
数据完整性服务有时会错误地与注重数据准确性的目录服务操作策略要求相关联。“准确性”是指数据元素（如名称、地址和电话号码）在特定目录对象（如域名）上下文中的真实关联。精度要求超出本协议的范围。
Additional security considerations are described in the specifications for HTTP [RFC7231], HTTP Basic and Digest access authentication [RFC7235], HTTP over TLS [RFC2818], and additional HTTP status codes [RFC6585]. Security considerations for federated authentication systems can be found in the OAuth [RFC6749] and OpenID [OpenID] specifications.
HTTP[RFC7231]、HTTP基本和摘要访问身份验证[RFC7235]、HTTP over TLS[RFC2818]和其他HTTP状态码[RFC6585]的规范中描述了其他安全注意事项。联邦身份验证系统的安全注意事项可以在OAuth[RFC6749]和OpenID[OpenID]规范中找到。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, April 2012, <http://www.rfc-editor.org/info/rfc6585>.
[RFC6585]诺丁汉，M.和R.菲尔丁，“附加HTTP状态代码”，RFC6585，2012年4月<http://www.rfc-editor.org/info/rfc6585>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, March 2015, <http://www.rfc-editor.org/info/rfc7480>.
[RFC7480]Newton，A.，Ellacott，B.，和N.Kong，“注册数据访问协议（RDAP）中的HTTP使用”，RFC 7480，2015年3月<http://www.rfc-editor.org/info/rfc7480>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, March 2015, <http://www.rfc-editor.org/info/rfc7482>.
[RFC7482]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）查询格式”，RFC 7482，2015年3月<http://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, March 2015, <http://www.rfc-editor.org/info/rfc7483>.
[RFC7483]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）的JSON响应”，RFC 7483，2015年3月<http://www.rfc-editor.org/info/rfc7483>.
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", December 2007, <http://specs.openid.net/auth/2.0>.
[ OpenID ] OpenID基金会，“OpenID认证2 -最终”，2007年12月，<http://specs.openid.net/auth/2.0>.
[RFC3707] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004, <http://www.rfc-editor.org/info/rfc3707>.
[RFC3707]Newton，A.，“跨注册互联网服务协议（CRISP）要求”，RFC 3707，2004年2月<http://www.rfc-editor.org/info/rfc3707>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004, <http://www.rfc-editor.org/info/rfc3912>.
[RFC3912]Daigle，L.，“WHOIS协议规范”，RFC 3912，2004年9月<http://www.rfc-editor.org/info/rfc3912>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006, <http://www.rfc-editor.org/info/rfc4732>.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月<http://www.rfc-editor.org/info/rfc4732>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 49492007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，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, 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 52802008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, January 2014, <http://www.rfc-editor.org/info/rfc7095>.
[RFC7095]Kewisch，P.，“jCard:vCard的JSON格式”，RFC7095，2014年1月<http://www.rfc-editor.org/info/rfc7095>.
[SAML] OASIS, "Security Assertion Markup Language (SAML) v2.0", March 2005, <https://www.oasis-open.org/ standards#samlv2.0>.
[SAML]OASIS，“安全断言标记语言（SAML）v2.0”，2005年3月<https://www.oasis-open.org/ 标准#samlv2.0>。
[SECURE-TLS-DTLS] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of TLS and DTLS", Work in Progress, draft-ietf-uta-tls-bcp-09, February 2015.
[SECURE-TLS-DTLS]谢弗，Y.，霍尔茨，R.，和P.圣安德烈，“TLS和DTLS的安全使用建议”，正在进行的工作，草案-ietf-uta-TLS-bcp-092015年2月。
Acknowledgements
致谢
The authors would like to acknowledge the following individuals for their contributions to this document: Richard Barnes, Marc Blanchet, Alissa Cooper, Ernie Dainow, Spencer Dawkins, Jean-Philippe Dionne, Byron Ellacott, Stephen Farrell, Tony Hansen, Peter Koch, Murray Kucherawy, Barry Leiba, Andrew Newton, and Linlin Zhou.
作者感谢以下个人对本文件的贡献：理查德·巴恩斯、马克·布兰切特、艾莉莎·库珀、厄尼·戴诺、斯宾塞·道金斯、让·菲利普·迪翁、拜伦·埃拉科特、斯蒂芬·法雷尔、托尼·汉森、彼得·科赫、默里·库奇拉维、巴里·莱巴、安德鲁·牛顿和周林林。
Authors' Addresses
作者地址
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
Scott Hollenbeck Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿20190
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/
Ning Kong China Internet Network Information Center 4 South 4th Street, Zhongguancun, Haidian District Beijing 100190 China
中国北京市海淀区中关村南四街4号宁空中国互联网信息中心100190
Phone: +86 10 5881 3147
EMail: nkong@cnnic.cn
Phone: +86 10 5881 3147
EMail: nkong@cnnic.cn