draft-ietf-weirds-rdap-sec-09.txt   draft-ietf-weirds-rdap-sec-10.txt 
Internet Engineering Task Force S. Hollenbeck Internet Engineering Task Force S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track N. Kong Intended status: Standards Track N. Kong
Expires: March 26, 2015 CNNIC Expires: April 30, 2015 CNNIC
September 22, 2014 October 27, 2014
Security Services for the Registration Data Access Protocol Security Services for the Registration Data Access Protocol
draft-ietf-weirds-rdap-sec-09 draft-ietf-weirds-rdap-sec-10
Abstract Abstract
The Registration Data Access Protocol (RDAP) provides "RESTful" web The Registration Data Access Protocol (RDAP) provides "RESTful" web
services to retrieve registration metadata from domain name and services to retrieve registration metadata from domain name and
regional internet registries. This document describes information regional internet registries. This document describes information
security services including authentication, authorization, security services including authentication, authorization,
availability, data confidentiality, and data integrity for RDAP. availability, data confidentiality, and data integrity for RDAP.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 26, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
documents, including "Registration Data Access Protocol Lookup documents, including "Registration Data Access Protocol Lookup
Format" [I-D.ietf-weirds-rdap-query], "JSON Responses for the Format" [I-D.ietf-weirds-rdap-query], "JSON Responses for the
Registration Data Access Protocol (RDAP)" Registration Data Access Protocol (RDAP)"
[I-D.ietf-weirds-json-response], and "HTTP usage in the Registration [I-D.ietf-weirds-json-response], and "HTTP usage in the Registration
Data Access Protocol (RDAP)" [I-D.ietf-weirds-using-http]. Data Access Protocol (RDAP)" [I-D.ietf-weirds-using-http].
One goal of RDAP is to provide security services that do not exist in One goal of RDAP is to provide security services that do not exist in
the WHOIS [RFC3912] protocol, including authentication, the WHOIS [RFC3912] protocol, including authentication,
authorization, availability, data confidentiality, and data authorization, availability, data confidentiality, and data
integrity. This document describes how each of these services is integrity. This document describes how each of these services is
achieved by RDAP. Where applicable, informational references to achieved by RDAP using features that are available in other protocol
requirements for a WHOIS replacement service [RFC3707] are noted. layers. Additional or alternative mechanisms can be added in the
future. Where applicable, informational references to requirements
for a WHOIS replacement service [RFC3707] are noted.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.1. Acronyms and Abbreviations 2.1. Acronyms and Abbreviations
DNR: Domain Name Registry DNR: Domain Name Registry
skipping to change at page 4, line 27 skipping to change at page 4, line 27
feature to identify and authenticate clients who possess and present feature to identify and authenticate clients who possess and present
a valid X.509 digital certificate [RFC5280]. Support for this a valid X.509 digital certificate [RFC5280]. Support for this
feature is OPTIONAL. feature is OPTIONAL.
RDAP does not impose any unique server authentication requirements. RDAP does not impose any unique server authentication requirements.
The server authentication provided by TLS fully addresses the needs The server authentication provided by TLS fully addresses the needs
of RDAP. In general, transports for RDAP must either provide a TLS- of RDAP. In general, transports for RDAP must either provide a TLS-
protected transport (e.g., HTTPS) or a mechanism that provides an protected transport (e.g., HTTPS) or a mechanism that provides an
equivalent level of server authentication. equivalent level of server authentication.
Work on HTTP authentication methods continues. RDAP ought to be Work on HTTP authentication methods continues. RDAP is designed to
agile enough to support additional methods as they are defined. be agile enough to support additional methods as they are defined.
3.1.1. Federated Authentication 3.1.1. Federated Authentication
The traditional client-server authentication model requires clients The traditional client-server authentication model requires clients
to maintain distinct credentials for every RDAP server. This to maintain distinct credentials for every RDAP server. This
situation can become unwieldy as the number of RDAP servers situation can become unwieldy as the number of RDAP servers
increases. Federated authentication mechanisms allow clients to use increases. Federated authentication mechanisms allow clients to use
one credential to access multiple RDAP servers and reduce client one credential to access multiple RDAP servers and reduce client
credential management complexity. RDAP MAY include a federated credential management complexity. RDAP MAY include a federated
authentication mechanism that permits a client to access multiple authentication mechanism that permits a client to access multiple
RDAP servers in the same federation with one credential. RDAP servers in the same federation with one credential.
Federated authentication mechanisms used by RDAP are OPTIONAL. If Federated authentication mechanisms used by RDAP MUST be fully
used, they MUST be fully supported by HTTP. OAuth, OpenID, and CA- supported by HTTP. OAuth, OpenID, and CA-based mechanisms are three
based mechanisms are three possible approaches to provide federated possible approaches to provide federated authentication. At the time
authentication. At the time of this document's publication, of this document's publication, negotiation or advertisement of
negotiation or advertisement of federated authentication services is federated authentication services is still an undefined mechanism by
still an undefined mechanism by the noted federated authentication the noted federated authentication protocols. Developing this
protocols. Developing this mechanism is beyond the scope of this mechanism is beyond the scope of this document.
document.
The OAuth authorization framework [RFC6749] describes a method for The OAuth authorization framework [RFC6749] describes a method for
users to access protected web resources without having to hand out users to access protected web resources without having to hand out
their credentials. Instead, clients are issued access tokens by their credentials. Instead, clients are issued access tokens by
authorization servers with the permission of the resource owners. authorization servers with the permission of the resource owners.
Using OAuth, multiple RDAP servers can form a federation and the Using OAuth, multiple RDAP servers can form a federation and the
clients can access any server in the same federation by providing one clients can access any server in the same federation by providing one
credential registered in any server in that federation. The OAuth credential registered in any server in that federation. The OAuth
authorization framework is designed for use with HTTP and thus can be authorization framework is designed for use with HTTP and thus can be
used with RDAP. used with RDAP.
OpenID [OpenID] is a decentralized single sign-on authentication OpenID [OpenID] is a decentralized single sign-on authentication
system that allows users to log in at multiple web sites with one ID 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 instead of having to create multiple unique accounts. An end user
can freely choose which OpenID provider to use, and can preserve can freely choose which OpenID provider to use, and can preserve
skipping to change at page 6, line 22 skipping to change at page 6, line 22
operator to the next. operator to the next.
3.3. Availability 3.3. Availability
An RDAP service has to be available to be useful. There are no RDAP- An RDAP service has to be available to be useful. There are no RDAP-
unique requirements to provide availability, but as a general unique requirements to provide availability, but as a general
security consideration a service operator needs to be aware of the security consideration a service operator needs to be aware of the
issues associated with denial of service. A thorough reading of issues associated with denial of service. A thorough reading of
"Internet Denial-of-Service Considerations" [RFC4732] is advised. "Internet Denial-of-Service Considerations" [RFC4732] is advised.
An RDAP service MAY use a throttling mechanism to limit the number of An RDAP service MAY use an HTTP throttling mechanism to limit the
queries that a single client can send in a given period of time. If number of queries that a single client can send in a given period of
used, the server SHOULD return a 429 response code as described in time. If used, the server SHOULD return an HTTP 429 (Too Many
"Additional HTTP Status Codes" [RFC6585]. A client that receives a Requests) response code as described in "Additional HTTP Status
429 response SHOULD decrease its query rate, and honor the Retry- Codes" [RFC6585]. A client that receives a 429 response SHOULD
After header field if one is present. Note that this is not a decrease its query rate, and honor the Retry-After header field if
defense against denial-of-service attacks, since a malicious client one is present. Note that this is not a defense against denial-of-
could ignore the code and continue to send queries at a high rate. A service attacks, since a malicious client could ignore the code and
server might use another response code if it did not wish to reveal continue to send queries at a high rate. A server might use another
to a client that rate limiting is the reason for the denial of a response code if it did not wish to reveal to a client that rate
reply. limiting is the reason for the denial of a reply.
3.4. Data Confidentiality 3.4. Data Confidentiality
WHOIS does not provide the ability to protect data from inadvertent WHOIS does not provide the ability to protect data from inadvertent
disclosure while in transit. Web services such as RDAP commonly use disclosure while in transit. RDAP uses HTTP Over TLS [RFC2818] to
HTTP Over TLS [RFC2818] to provide that protection by encrypting all provide that protection by encrypting all traffic sent on the
traffic sent on the connection between client and server. It is also connection between client and server. It is also possible to encrypt
possible to encrypt discrete objects (such as command path segments discrete objects (such as command path segments and JSON-encoded
and JSON-encoded response objects) at one endpoint, send them to the response objects) at one endpoint, send them to the other endpoint
other endpoint via an unprotected transport protocol, and decrypt the via an unprotected transport protocol, and decrypt the object on
object on receipt. Encryption algorithms as described in "Internet receipt. Encryption algorithms as described in "Internet Security
Security Glossary, Version 2" [RFC4949] are commonly used to provide Glossary, Version 2" [RFC4949] are commonly used to provide data
data confidentiality at the object level. confidentiality at the object level.
There are no current requirements for object-level data There are no current requirements for object-level data
confidentiality using encryption. Support for this feature could be confidentiality using encryption. Support for this feature could be
added to RDAP in the future. added to RDAP in the future.
As noted in Section 3.1, the HTTP "basic" authentication scheme can As noted in Section 3.1, the HTTP "basic" authentication scheme can
be used to authenticate a client. When this scheme is used, HTTP be used to authenticate a client. When this scheme is used, HTTP
Over TLS MUST be used to protect the client's credentials from Over TLS MUST be used to protect the client's credentials from
disclosure while in transit. If the policy of the server operator disclosure while in transit. If the policy of the server operator
requires encryption to protect client-server data exchanges (such as requires encryption to protect client-server data exchanges (such as
skipping to change at page 9, line 12 skipping to change at page 9, line 12
Stephen Farrell, Tony Hansen, Peter Koch, Murray Kucherawy, Barry Stephen Farrell, Tony Hansen, Peter Koch, Murray Kucherawy, Barry
Leiba, Andrew Newton, and Linlin Zhou. Leiba, Andrew Newton, and Linlin Zhou.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-weirds-json-response] [I-D.ietf-weirds-json-response]
Newton, A. and S. Hollenbeck, "JSON Responses for the Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-json-response-08 (work in progress), August 2014. weirds-json-response-10 (work in progress), October 2014.
[I-D.ietf-weirds-rdap-query] [I-D.ietf-weirds-rdap-query]
Newton, A. and S. Hollenbeck, "Registration Data Access Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol Query Format", draft-ietf-weirds-rdap-query-13 Protocol Query Format", draft-ietf-weirds-rdap-query-15
(work in progress), August 2014. (work in progress), October 2014.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-using-http-11 (work in progress), September 2014. weirds-using-http-13 (work in progress), October 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012. Codes", RFC 6585, April 2012.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
skipping to change at page 11, line 7 skipping to change at page 11, line 7
-05: Address IETF last call comments: Added text to Section 3.1.1 to -05: Address IETF last call comments: Added text to Section 3.1.1 to
recommend the use of HTTP over TLS. Modified Section 3.2 to recommend the use of HTTP over TLS. Modified Section 3.2 to
clarify granular access control text. Added additional Security clarify granular access control text. Added additional Security
Considerations. Made references to RFC 5246 and OpenID Considerations. Made references to RFC 5246 and OpenID
informative. Minor typo fixes. informative. Minor typo fixes.
-06: Keepalive refresh. No content updates. -06: Keepalive refresh. No content updates.
-07: Keepalive refresh. No content updates. -07: Keepalive refresh. No content updates.
-08: Updated HTTP references. 2616 -> 7231, 2617 -> 7235. -08: Updated HTTP references. 2616 -> 7231, 2617 -> 7235.
-09: Address WG last call comments. -09: Address WG last call comments.
-10: Address IETF last call comments.
Authors' Addresses Authors' Addresses
Scott Hollenbeck Scott Hollenbeck
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
US US
Email: shollenbeck@verisign.com Email: shollenbeck@verisign.com
 End of changes. 13 change blocks. 
40 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/