draft-ietf-weirds-rdap-sec-08.txt   draft-ietf-weirds-rdap-sec-09.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: February 19, 2015 CNNIC Expires: March 26, 2015 CNNIC
August 18, 2014 September 22, 2014
Security Services for the Registration Data Access Protocol Security Services for the Registration Data Access Protocol
draft-ietf-weirds-rdap-sec-08 draft-ietf-weirds-rdap-sec-09
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 February 19, 2015. This Internet-Draft will expire on March 26, 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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3
3. Information Security Services and RDAP . . . . . . . . . . . 3 3. Information Security Services and RDAP . . . . . . . . . . . 3
3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 3 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Federated Authentication . . . . . . . . . . . . . . 4 3.1.1. Federated Authentication . . . . . . . . . . . . . . 4
3.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Data Confidentiality . . . . . . . . . . . . . . . . . . 6 3.4. Data Confidentiality . . . . . . . . . . . . . . . . . . 6
3.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . 6 3.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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].
skipping to change at page 3, line 31 skipping to change at page 3, line 31
RDAP itself does not include native security services. Instead, RDAP RDAP itself does not include native security services. Instead, RDAP
relies on features that are available in other protocol layers to relies on features that are available in other protocol layers to
provide needed security services including authentication, provide needed security services including authentication,
authorization, availability, data confidentiality, and data authorization, availability, data confidentiality, and data
integrity. A description of each of these security services can be integrity. A description of each of these security services can be
found in "Internet Security Glossary, Version 2" [RFC4949]. No found in "Internet Security Glossary, Version 2" [RFC4949]. No
requirements have been identified for other security services. requirements have been identified for other security services.
3.1. Authentication 3.1. Authentication
This section describes security authentication mechanisms and their
need for implementation by authorization policies. 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.
WHOIS does not provide features to identify and authenticate clients. WHOIS does not provide features to identify and authenticate clients.
As noted in section 3.1.4.2 of "Cross Registry Internet Service As noted in section 3.1.4.2 of "Cross Registry Internet Service
Protocol (CRISP) Requirements" [RFC3707], there is utility in Protocol (CRISP) Requirements" [RFC3707], there is utility in
allowing server operators to offer "varying degrees of access allowing server operators to offer "varying degrees of access
depending on policy and need". Clients have to be identified and depending on policy and need". Clients have to be identified and
authenticated to provide that utility. authenticated to provide that utility.
RDAP's authentication framework needs to accommodate anonymous access RDAP's authentication framework needs to accommodate anonymous access
as well as verification of identities using a range of authentication as well as verification of identities using a range of authentication
methods and credential services. To that end, RDAP clients and methods and credential services. To that end, RDAP clients and
skipping to change at page 4, line 33 skipping to change at page 4, line 44
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 are OPTIONAL. If
used, they MUST be fully supported by HTTP. OAuth, OpenID, and CA- used, they MUST be fully supported by HTTP. OAuth, OpenID, and CA-
based mechanisms are three possible approaches to provide federated based mechanisms are three possible approaches to provide federated
authentication. 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 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.
skipping to change at page 5, line 28 skipping to change at page 5, line 43
3.2. Authorization 3.2. Authorization
WHOIS does not provide services to grant different levels of access WHOIS does not provide services to grant different levels of access
to clients based on a client's authenticated identity. As noted in to clients based on a client's authenticated identity. As noted in
section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP) section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP)
Requirements" [RFC3707], there is utility in allowing server Requirements" [RFC3707], there is utility in allowing server
operators to offer "varying degrees of access depending on policy and operators to offer "varying degrees of access depending on policy and
need". Access control decisions can be made once a client's identity need". Access control decisions can be made once a client's identity
has been established and authenticated (see Section 3.1). has been established and authenticated (see Section 3.1).
Server operators SHOULD offer varying degrees of access depending on Server operators MAY offer varying degrees of access depending on
policy and need in conjunction with the authentication methods policy and need in conjunction with the authentication methods
described in Section 3.1. If such varying degrees of access are described in Section 3.1. If such varying degrees of access are
supported, an RDAP server MUST provide granular access controls (that supported, an RDAP server MUST provide granular access controls (that
is, on a per registration data object basis) in order to implement is, on a per registration data object basis) in order to implement
authorization policies. Some examples: authorization policies. Some examples:
- Clients will be allowed access only to data for which they have a - Clients will be allowed access only to data for which they have a
relationship. relationship.
- Unauthenticated or anonymous access status may not yield any - Unauthenticated or anonymous access status may not yield any
skipping to change at page 8, line 48 skipping to change at page 9, line 16
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-08 (work in progress), August 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-11 Protocol Query Format", draft-ietf-weirds-rdap-query-13
(work in progress), July 2014. (work in progress), August 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-09 (work in progress), August 2014. weirds-using-http-11 (work in progress), September 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 10, line 39 skipping to change at page 11, line 4
on a per registration data object basis) in order to implement on a per registration data object basis) in order to implement
authorization policies"; move RFCs 4732, 5280, and 6749 from authorization policies"; move RFCs 4732, 5280, and 6749 from
normative to informative subsection. normative to informative subsection.
-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.
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. 14 change blocks. 
14 lines changed or deleted 30 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/