draft-ietf-weirds-rdap-sec-11.txt   draft-ietf-weirds-rdap-sec-12.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: May 22, 2015 CNNIC Expires: June 5, 2015 CNNIC
November 18, 2014 December 2, 2014
Security Services for the Registration Data Access Protocol Security Services for the Registration Data Access Protocol
draft-ietf-weirds-rdap-sec-11 draft-ietf-weirds-rdap-sec-12
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 access control, authentication,
availability, data confidentiality, and data integrity for RDAP. authorization, availability, data confidentiality, and data integrity
for RDAP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 22, 2015. This Internet-Draft will expire on June 5, 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 40 skipping to change at page 2, line 40
1. Introduction 1. Introduction
The Registration Data Access Protocol (RDAP) is specified in multiple The Registration Data Access Protocol (RDAP) is specified in multiple
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 access control,
authorization, availability, data confidentiality, and data authentication, authorization, availability, data confidentiality,
integrity. This document describes how each of these services is and data integrity. This document describes how each of these
achieved by RDAP using features that are available in other protocol services is achieved by RDAP using features that are available in
layers. Additional or alternative mechanisms can be added in the other protocol layers. Additional or alternative mechanisms can be
future. Where applicable, informational references to requirements added in the future. Where applicable, informational references to
for a WHOIS replacement service [RFC3707] are noted. 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 9, line 30 skipping to change at page 9, line 30
RDAP uses the jCard [RFC7095] standard format for entity RDAP uses the jCard [RFC7095] standard format for entity
representation. Operators may find that many of the jCard fields are representation. Operators may find that many of the jCard fields are
irrelevant for registry operation purposes or that they have no irrelevant for registry operation purposes or that they have no
reason to collect information from registrants that would correspond reason to collect information from registrants that would correspond
to certain fields. Operators wishing to reduce privacy risks for to certain fields. Operators wishing to reduce privacy risks for
registrants may restrict which information they collect and/or which registrants may restrict which information they collect and/or which
fields they populate in responses. fields they populate in responses.
In addition to privacy risks to registrants, there are also potential In addition to privacy risks to registrants, there are also potential
privacy risks for those who query registration data. For example, privacy risks for those who query registration data. For example,
the fact that a law enforcement officer performs a particular query the fact that a registry employee performs a particular query may
may reveal information about the officer's activities that he or she reveal information about the employee's activities that he or she
would have preferred to keep private. RDAP supports the use of HTTP would have preferred to keep private. RDAP supports the use of HTTP
over TLS to provide privacy protection for those querying registrant over TLS to provide privacy protection for those querying registrant
data as well as registrants. data as well as registrants, unless operational constraints make it
impossible to meet this requirement.
6. Security Considerations 6. Security Considerations
One of the goals of RDAP is to provide security services that do not One of the goals of RDAP is to provide security services that do not
exist in the WHOIS protocol. This document describes the security exist in the WHOIS protocol. This document describes the security
services provided by RDAP and associated protocol layers, including services provided by RDAP and associated protocol layers, including
authentication, authorization, availability, data confidentiality, authentication, authorization, availability, data confidentiality,
and data integrity. Non-repudiation services were also considered and data integrity. Non-repudiation services were also considered
and ultimately rejected due to a lack of requirements. There are, and ultimately rejected due to a lack of requirements. There are,
however, currently-deployed WHOIS servers that can return signed however, currently-deployed WHOIS servers that can return signed
skipping to change at page 10, line 23 skipping to change at page 10, line 24
implement federated authentication. There is a risk of too- implement federated authentication. There is a risk of too-
promiscuous, or even rogue, CAs being included in the list of promiscuous, or even rogue, CAs being included in the list of
acceptable CAs that the TLS server sends the client as part of the acceptable CAs that the TLS server sends the client as part of the
TLS client-authentication handshake and lending the appearance of TLS client-authentication handshake and lending the appearance of
trust to certificates signed by those CAs. Periodic monitoring of trust to certificates signed by those CAs. Periodic monitoring of
the list of CAs that RDAP servers trust for client authentication can the list of CAs that RDAP servers trust for client authentication can
help reduce this risk. help reduce this risk.
The Transport Layer Security Protocol [RFC5246] includes a null The Transport Layer Security Protocol [RFC5246] includes a null
cipher suite that does not encrypt data and thus does not provide cipher suite that does not encrypt data and thus does not provide
data confidentiality. This option must not be used when data data confidentiality. This option MUST NOT be used when data
confidentiality services are needed. Additional considerations for confidentiality services are needed. Additional considerations for
secure use of TLS are described in [I-D.ietf-uta-tls-bcp]. secure use of TLS are described in [I-D.ietf-uta-tls-bcp].
Data integrity services are sometimes mistakenly associated with Data integrity services are sometimes mistakenly associated with
directory service operational policy requirements focused on data directory service operational policy requirements focused on data
accuracy. "Accuracy" refers to the truthful association of data accuracy. "Accuracy" refers to the truthful association of data
elements (such as names, addresses, and telephone numbers) in the elements (such as names, addresses, and telephone numbers) in the
context of a particular directory object (such as a domain name). context of a particular directory object (such as a domain name).
Accuracy requirements are out of scope for this protocol. Accuracy requirements are out of scope for this protocol.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Byron Ellacott, Stephen Farrell, Tony Hansen, Peter Koch, Murray Byron Ellacott, Stephen Farrell, Tony Hansen, Peter Koch, Murray
Kucherawy, Barry Leiba, Andrew Newton, and Linlin Zhou. Kucherawy, Barry Leiba, Andrew Newton, and Linlin Zhou.
8. References 8. References
8.1. Normative References 8.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-11 (work in progress), October 2014. weirds-json-response-12 (work in progress), November 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-16 Protocol Query Format", draft-ietf-weirds-rdap-query-16
(work in progress), October 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-14 (work in progress), October 2014. weirds-using-http-15 (work in progress), November 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 13, line 18 skipping to change at page 13, line 18
recommend the use of HTTP over TLS. Modified Section 3.3 to recommend the use of HTTP over TLS. Modified Section 3.3 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. -10: Address IETF last call comments.
-11: Address IESG review comments. -11: Address IESG review comments.
-12: Added "access control" where it was missing in the abstract and
introduction. Minor IESG DISCUSS edits.
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. 11 change blocks. 
19 lines changed or deleted 23 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/