Security Services for the Registration Data Access Protocol (RDAP)
also
- std-95
Extracted elements (25)
Federated authentication (OAuth, OpenID, SAML, or CA-based) allows clients to use one credential to access multiple RDAP servers, reducing credential management complexity as the number of RDAP servers increases.
Non-repudiation services were considered and ultimately rejected due to a lack of requirements, though existing WHOIS servers can return signed responses providing non-repudiation with proof of origin.
RDAP itself does not include native security services; instead it relies on features available in other protocol layers (HTTP, TLS) to provide access control, authentication, authorization, availability, data confidentiality, and data integrity.
OAuth and OpenID do not consistently require data confidentiality services; HTTP over TLS can be used as needed to provide protection against man-in-the-middle attacks when using these federated authentication mechanisms.
RDAP's authentication framework is designed to be agile enough to support additional HTTP authentication methods as they are defined in the future, beyond Basic, Digest, and TLS client certificates.
An RDAP service MAY use an HTTP throttling mechanism; if used, the server SHOULD return HTTP 429 (Too Many Requests). A client receiving a 429 SHOULD decrease its query rate and honor the Retry-After header field if present.
Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP.
HTTP over TLS MUST be used to protect all client-server exchanges unless operational constraints make it impossible to meet this requirement.
If the HTTP 'basic' authentication scheme is used, HTTP over TLS (RFC 2818) MUST be used to protect the client's credentials from disclosure while in transit.
If the server operator's policy requires encryption to protect client-server data exchanges, HTTP over TLS MUST be used to protect those exchanges.
If the server operator's policy requires message integrity for client-server data exchanges, HTTP over TLS MUST be used to protect those exchanges.
If varying degrees of access are supported, an RDAP server MUST provide granular access controls (per registration data object) to implement authorization policies.
RDAP clients and servers MUST implement the authentication framework specified in HTTP/1.1 Authentication (RFC 7235).
RDAP MAY include a federated authentication mechanism that permits a client to access multiple RDAP servers in the same federation with one credential.
Server operators MAY offer varying degrees of access depending on policy and need in conjunction with the authentication methods described in Section 3.2.
Servers MUST support either Basic or Digest authentication. Clients MUST support both to interoperate with servers that support one or the other.
Support for TLS client certificate authentication (X.509) is OPTIONAL.
The TLS null cipher suite MUST NOT be used when data confidentiality services are needed.
Operators wishing to reduce privacy risks may use jCard fields selectively, restricting which information is collected from registrants and which fields are populated in responses.
Querying registration data may itself reveal private information about the querier (e.g., a registry employee's activities). RDAP supports HTTP over TLS to provide privacy protection for those querying registrant data as well as for registrants.
Registration data has historically included personal data about registrants made public via WHOIS, creating privacy risks. RDAP provides authentication and tiered access mechanisms that can restrict personal data to specifically privileged clients, and status values ('private', 'redacted', 'obscured', 'proxy') to indicate restricted data.
RDAP uses response status values (defined in RFC 7483 Section 10.2.2) to clearly mark information returned to a client, identifying the level of access granted and whether data has been made private, redacted, obscured, or registered by a proxy.
HTTP 429 throttling is not a defense against denial-of-service attacks since a malicious client could ignore the response code and continue sending queries at high rates.
RDAP is susceptible to code injection attacks (SQL injection, shell injection, HTML-script injection, etc.). Data confidentiality and integrity services provide a measure of defense against man-in-the-middle injection attacks, but vulnerabilities in client- and server-side software can still allow injection to succeed.
When using digital certificates for federated authentication, there is a risk of overly permissive or rogue CAs being trusted by TLS servers. Periodic monitoring of the CA list trusted by RDAP servers for client authentication can reduce this risk.