RFC 7481
Security Services for the Registration Data Access Protocol (RDAP)
Security Services for the Registration Data Access Protocol (RDAP) 💖
RFC 7481 is a Standards Track doc from the IETF, bestie 🎀 It's dated March 2015 with ISSN 2070-1721, and it was written by S. Hollenbeck (Verisign Labs) and N. Kong (CNNIC). The title block doesn't list anything it obsoletes or updates, so this one stands on its own ✨
Here's the full table of contents, exactly as written:
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 . . . . . . . . . . . . . . . . . . . . . . . 13Abstract ✨
So RDAP gives you "RESTful" web services to pull registration metadata from Domain Name and Regional Internet Registries 🌸 This doc is all about the security side of things: access control, authentication, authorization, availability, data confidentiality, and data integrity. Literally the whole security glow-up 💅
Status of This Memo 📜
This is an Internet Standards Track document.
This doc is a product of the IETF, and it represents the consensus of the IETF community. It got public review and was approved for publication by the IESG (Internet Engineering Steering Group). If you want more on Internet Standards, check out Section 2 of RFC 5741. 🧚
For the current status, any errata, and how to send feedback, head to 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. Please actually read these, ngl, because they spell out your rights and restrictions for this document. If you extract Code Components from it, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶
1. Introduction 🦋
So RDAP is specified across a few docs: "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 big goal of RDAP is to offer security services that WHOIS [RFC3912] just doesn't have. That's access control, authentication, authorization, availability, data confidentiality, and data integrity. This doc explains how RDAP achieves each of these using features that already exist in other protocol layers. More mechanisms can be added or swapped in later on ✨ And where it fits, there are informative references to the requirements for a WHOIS replacement service [RFC3707], so you can see the bigger picture 🌈
2. Conventions Used in This Document 💅
Okay, key words time 💜 When you see "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc, they're interpreted as described in [RFC2119]. Don't skip them!
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 doesn't have any native security services of its own, no cap 🙈 Instead, it leans on features from other protocol layers to get the job done. That covers access control, authentication, authorization, availability, data confidentiality, and data integrity. You can find a description of each of these in "Internet Security Glossary, Version 2" [RFC4949]. No requirements have been identified for any other security services, so that's the whole list for now 🎀
3.1. Access Control 🔐
WHOIS doesn't have specific features for controlling access to registration information. RDAP does, and it's giving control 👑 As the next sections explain, RDAP includes features to identify, authenticate, and authorize clients. That means server operators can control access based on a client's identity and its associated authorizations. Information sent back to a client can be clearly marked with a status value (see Section 10.2.2 of [RFC7483]) that shows what access the client was granted.
3.2. Authentication 🫧
This section covers security authentication mechanisms and why authorization policies need to include them. It lays out requirements for clients and servers, but it doesn't tell server operators what their policies should be. For example, if a server operator has no policy about differentiated or tiered access to data, they won't have any authorization mechanisms, and they won't need any type of authentication. But if a server operator has policies for differentiated access, they'll have to build an authorization scheme and follow the authentication requirements that come with it 🌸
WHOIS doesn't have features to identify and authenticate clients. As noted in Section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP) Requirements" [RFC3707], there's real value in letting server operators offer "varying degrees of access depending on policy and need." To make that happen, clients have to be identified and authenticated ✨
RDAP's authentication framework has to accommodate anonymous access, and it also has to verify identities using a range of authentication methods and credential services. So RDAP clients and servers MUST implement the authentication framework specified in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]. The "basic" scheme can send a client's user name and password to a server in plaintext, base64-encoded form. The "digest" scheme can authenticate a client without exposing the client's plaintext password 🔑 If the "basic" scheme is used, then HTTP over TLS [RFC2818] MUST be used to protect the client's credentials from disclosure while they're in transit (see Section 3.5). This part is non-negotiable, bestie 😭
Servers MUST support either Basic or Digest authentication, but they are not required to support both. Clients MUST support both so they can interoperate with servers that support one or the other 🦋 Servers may provide a login page that triggers HTTP authentication. Clients should keep sending the HTTP authentication header once they get 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 have and present a valid X.509 digital certificate [RFC5280]. Support for this feature is OPTIONAL 🍓
RDAP doesn't add any unique server authentication requirements of its own. The server authentication that TLS provides fully covers what RDAP needs 💖 In general, transports for RDAP must either be TLS-protected (e.g., HTTPS) or use a mechanism that provides an equivalent level of server authentication.
Work on HTTP authentication methods is still going, and RDAP is designed to be agile enough to support additional methods as they get defined 🌈
3.2.1. Federated Authentication ✨
okay so picture this bestie 🫶 the old-school client-server way means a client has to keep a separate set of credentials for every single RDAP server 😭 and as the number of servers grows, that gets SO unwieldy. enter federated authentication 🦋 which lets a client use one credential to get into multiple RDAP servers, so way less credential juggling. it's giving main character energy 💅 and RDAP MAY include a federated authentication mechanism that lets a client access multiple RDAP servers in the same federation with one credential.
BUT hear me out: any federated authentication mechanism RDAP uses MUST be fully supported by HTTP 🔥 OAuth, OpenID, Security Assertion Markup Language (SAML), and mechanisms based on Certification Authority (CA) are all possible ways to do federated auth 💖 ngl though, at the time of this document's publication, how you negotiate or advertise federated auth services is still undefined by those protocols 💀 and building that mechanism is beyond the scope of this document 🙈
OAuth [RFC6749] is the vibe for letting users access protected web resources WITHOUT handing out their credentials 🌸 instead, authorization servers issue access tokens to clients with the resource owner's permission 👑 so multiple RDAP servers can form a federation, and a client can reach any server in that federation using one credential registered in any server there 🧚 OAuth is designed for HTTP, so it works with RDAP too 💜
OpenID [OpenID] is a decentralized single sign-on system 🍓 it lets users log in at multiple websites with one ID instead of making a bunch of unique accounts. an end user can freely pick which OpenID provider to use, and can keep their Identifier if they switch providers 🌈
Note that OAuth and OpenID do not consistently require data confidentiality services to protect interactions between providers and consumers 😭 so HTTP over TLS [RFC2818] can be used as needed to protect against man-in-the-middle attacks 🔒✨
SAML 2.0 [SAML] is an XML-based protocol for web-based authentication and authorization, including single sign on 🎀 it uses security tokens containing assertions to swap info about an end user between an identity provider and a service provider 💅
The Transport Layer Security protocol describes a client certificate in Section 7.4.6 of [RFC5246] 🫶 clients who have and present a valid X.509 digital certificate, issued by a CA, can be identified and authenticated by a server that trusts that CA 🦋 a certificate authentication method can be used for federated auth too: multiple RDAP servers all trust the same CAs, so any client with a certificate from a trusted CA can get into any RDAP server in the federation 👑 this certificate-based mechanism is supported by HTTPS and can be used with RDAP ✨
3.3. Authorization 🎀
okay so WHOIS doesn't give different access levels based on who you are once you're authenticated 🙈 Section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP) Requirements" [RFC3707] says there's utility in letting server operators 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, together with the authentication methods in Section 3.2 🌸 if they do, an RDAP server MUST provide granular access controls (that is, per registration data object) 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 a server allows will most likely vary from one operator to the next 🍓 for the response privacy considerations tied to different authorization levels, check Section 13 of [RFC7483] 🌈
3.4. Availability ✨
an RDAP service has to be available to be useful 💖 there are no RDAP-unique requirements for availability, but as a general security consideration, a service operator needs to be aware of denial of service issues 😭 a thorough reading of "Internet Denial-of-Service Considerations" [RFC4732] is advised 🫶
an RDAP service MAY use an HTTP throttling mechanism to limit how many queries a single client can send in a given time period 🦋 if it does, the server SHOULD return an HTTP 429 (Too Many Requests) response code, as described in "Additional HTTP Status Codes" [RFC6585] 🔥 a client that gets a 429 SHOULD decrease its query rate and honor the Retry-After header field if one is present 🎀 but heads up: this is NOT a defense against denial-of-service attacks, since a malicious client could ignore the code and keep sending queries at a high rate 💀 also, a server might use another response code if it didn't want to reveal to a client that rate limiting was the reason for denying a reply 🙈
3.5. Data Confidentiality 🔒
WHOIS doesn't protect data from inadvertent disclosure while in transit 😭 RDAP uses HTTP over TLS [RFC2818] for that protection, encrypting all traffic 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's also possible to encrypt discrete objects (like command path segments and JSON-encoded response objects) at one endpoint, send them over an unprotected transport, and decrypt on receipt 🧚 encryption algorithms described in "Internet Security Glossary, Version 2" [RFC4949] are commonly used for object-level confidentiality 🌸
there are no current requirements for object-level data confidentiality using encryption, but support for this 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 it's used, HTTP over TLS MUST be used to protect the client's credentials from disclosure in transit 🔥 if the server operator's policy requires encryption for client-server exchanges (like protecting non-public data that can't be accessed without identification and authentication), HTTP over TLS MUST be used to protect those exchanges 💅
privacy threats that confidentiality services can address are described in Section 4 🌈 Section 10.2.2 of [RFC7483] describes status values operators can use to protect response data from disclosure to unauthorized clients 💖
3.6. Data Integrity 🛡️
WHOIS doesn't protect data from modification in transit 😭 web services like RDAP commonly use HTTP over TLS [RFC2818] for that, using a keyed Message Authentication Code (MAC) to detect modifications 🦋 it's also possible to sign discrete objects (like command path segments and JSON-encoded response objects) at one endpoint, send them over a transport protocol, and validate the signature on receipt 🫶 digital signature algorithms described in "Internet Security Glossary, Version 2" [RFC4949] are commonly used for object-level integrity 🌸
there are no current requirements for object-level data integrity using digital signatures, but support for this could be added to RDAP in the future 🧚
the most specific need here is making sure HTTP 30x redirection hints [RFC7231] and response elements returned from the server aren't modified in transit 👑 if the server operator's policy requires message integrity for client-server 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 made this info public, which created a privacy risk by revealing registrants' personal details 😭 WHOIS also didn't have authentication or access control mechanisms to gate access to registration data 💀 so proxy and privacy services popped up to shield registrants' identities 🧚
the standardization of RDAP doesn't change or impact the data operators may require to be collected from registrants, but it supports a bunch of mechanisms that can mitigate privacy threats to registrants if operators choose to use them ✨
RDAP includes mechanisms to authenticate clients, letting servers support tiered access based on local policy 🎀 so all registration data no longer needs to be public, and personal or more sensitive data can have its access restricted to specifically privileged clients 👑
RDAP data structures let servers indicate via status values when data returned to clients has been made private, redacted, obscured, or registered by a proxy 🦋 "Private" means the data isn't designated for public consumption 🔒 "Redacted" means some registration data fields aren't being made available 🫶 "Obscured" means data has been altered so the actual registration information isn't readily revealed 🌸 one option operators have to reduce privacy risks for registrants is adopting policies that use these status values to restrict registrant data shared with any or all clients, based on data sensitivity, client privileges, or other heuristics 💜
RDAP uses the jCard [RFC7095] standard format for entity representation 🌈 operators may find many jCard fields are irrelevant for registry operation, or that they have no reason to collect info from registrants that would match certain fields 🍓 operators who want to reduce privacy risks for registrants may restrict which info they collect and/or which fields they populate in responses 💖
there are also potential privacy risks for people who query registration data, not just registrants 👀 for example, the fact that a registry employee performs a particular query may reveal info about the employee's activities that they'd have preferred to keep private 🙈 RDAP supports HTTP over TLS to give privacy protection to those querying registrant data as well as to registrants, unless operational constraints make it impossible to meet this requirement 🫶✨
5. Security Considerations 🔐
Okay bestie, security is where RDAP really gets to be the main character 💅. One of its big goals is offering security services that WHOIS never had ✨. This section covers the ones RDAP and its associated protocol layers provide: authentication, authorization, availability, data confidentiality, and data integrity 🛡️. Non-repudiation got considered too, but it was rejected because there weren't enough requirements for it 🙃. Real talk though, some WHOIS servers that are already out there can return signed responses that give non-repudiation with proof of origin 👀. So RDAP might need to be extended to offer that someday 🦋.
As an HTTP-based protocol, RDAP is open to code injection attacks 😭. Code injection means sneaking code into a computer system or program to change how it runs 💀. There are lots of flavours: SQL injection, dynamic variable or function injection, include-file injection, shell injection, HTML-script injection, and more 🕷️. Data confidentiality and integrity services give you some defence against man-in-the-middle injection attacks, but bugs in client-side and server-side software mean injection attacks can still succeed 🙈. Consistently checking and validating server credentials can help catch man-in-the-middle attacks 🔍.
As noted in Section 3.2.1, digital certificates can power federated authentication 🎀. The risk is that too promiscuous, or even rogue, CAs could end up on the list of acceptable CAs that the TLS server sends the client during the TLS client-authentication handshake. That gives certificates signed by those CAs a fake air of trust 😤. Periodically keeping an eye on the list of CAs that RDAP servers trust for client authentication can help lower this risk 👀.
The Transport Layer Security protocol [RFC5246] includes a null cipher suite that doesn't encrypt anything, so it gives you zero data confidentiality 🙅♀️. This option MUST NOT be used when data confidentiality services are needed. Additional considerations for secure TLS use are described in [SECURE-TLS-DTLS] 📚.
Data integrity services are sometimes mixed up with directory service operational policy requirements about data accuracy 🙄. "Accuracy" refers to the truthful association of data elements (like names, addresses, and telephone numbers) with a particular directory object (like a domain name) 📇. Accuracy requirements are out of scope for this protocol 🚫.
More security considerations live in the specs for HTTP [RFC7231], HTTP Basic and Digest access authentication [RFC7235], HTTP over TLS [RFC2818], and additional HTTP status codes [RFC6585] 📖. For federated authentication systems, check out 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>.
[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>.
[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.Acknowledgements 🫶
The authors want to give a huge shout-out to these people 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📦 where this page comes from
- ietf: rfc7481 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms