diff options
Diffstat (limited to 'doc/rfc/rfc7481.txt')
| -rw-r--r-- | doc/rfc/rfc7481.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7481.txt b/doc/rfc/rfc7481.txt new file mode 100644 index 0000000..a7e4093 --- /dev/null +++ b/doc/rfc/rfc7481.txt @@ -0,0 +1,731 @@ + + + + + + +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) + +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. + +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. + + 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. + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + + + +Hollenbeck & Kong Standards Track [Page 1] + +RFC 7481 RDAP Security Services March 2015 + + +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 + + 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]. + + 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. + +2. Conventions Used in This Document + + 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]. + + + + + + + + +Hollenbeck & Kong Standards Track [Page 2] + +RFC 7481 RDAP Security Services March 2015 + + +2.1. Acronyms and Abbreviations + + DNR: Domain Name Registry + + HTTP: Hypertext Transfer Protocol + + JSON: JavaScript Object Notation + + RDAP: Registration Data Access Protocol + + RIR: Regional Internet Registry + + TLS: Transport Layer Security + +3. Information Security Services and RDAP + + 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. + +3.1. Access Control + + 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. + +3.2. Authentication + + 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. + + + + + +Hollenbeck & Kong Standards Track [Page 3] + +RFC 7481 RDAP Security Services March 2015 + + + 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. + + 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). + + 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. + + 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. + + 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. + + Work on HTTP authentication methods continues. RDAP is designed to + be agile enough to support additional methods as they are defined. + +3.2.1. Federated Authentication + + 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 + + + +Hollenbeck & Kong Standards Track [Page 4] + +RFC 7481 RDAP Security Services March 2015 + + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + 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 + + + +Hollenbeck & Kong Standards Track [Page 5] + +RFC 7481 RDAP Security Services March 2015 + + + certificate-based mechanism is supported by HTTPS and can be used + with RDAP. + +3.3. Authorization + + 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). + + 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: + + - 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]. + +3.4. Availability + + 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. + + 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 + + + +Hollenbeck & Kong Standards Track [Page 6] + +RFC 7481 RDAP Security Services March 2015 + + + 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. + +3.5. Data Confidentiality + + 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. + + There are no current requirements for object-level data + confidentiality using encryption. Support for this feature could be + added to RDAP in the future. + + 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. + + 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. + +3.6. Data Integrity + + 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 + + + +Hollenbeck & Kong Standards Track [Page 7] + +RFC 7481 RDAP Security Services March 2015 + + + 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. + + 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. + + 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. + +4. Privacy Threats Associated with Registration Data + + 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. + + 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 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 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 + + + + +Hollenbeck & Kong Standards Track [Page 8] + +RFC 7481 RDAP Security Services March 2015 + + + 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. + + 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. + +5. Security Considerations + + 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. + + 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. + + 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 + + + +Hollenbeck & Kong Standards Track [Page 9] + +RFC 7481 RDAP Security Services March 2015 + + + 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. + + 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]. + + 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. + +6. References + +6.1. Normative References + + [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>. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, + <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>. + + [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>. + + [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>. + + + + +Hollenbeck & Kong Standards Track [Page 10] + +RFC 7481 RDAP Security Services March 2015 + + + [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>. + + [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access + Protocol (RDAP) Query Format", RFC 7482, March 2015, + <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>. + +6.2. Informative References + + [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", + December 2007, <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>. + + [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, + September 2004, <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>. + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI + 36, RFC 4949, August 2007, + <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>. + + [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>. + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, October 2012, + <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>. + + + +Hollenbeck & Kong Standards Track [Page 11] + +RFC 7481 RDAP Security Services March 2015 + + + [SAML] OASIS, "Security Assertion Markup Language (SAML) v2.0", + March 2005, <https://www.oasis-open.org/ + standards#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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck & Kong Standards Track [Page 12] + +RFC 7481 RDAP Security Services March 2015 + + +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 + + 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 + + Phone: +86 10 5881 3147 + EMail: nkong@cnnic.cn + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck & Kong Standards Track [Page 13] + |