draft-ietf-weirds-rdap-sec-07.txt   draft-ietf-weirds-rdap-sec-08.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 6, 2015 CNNIC Expires: February 19, 2015 CNNIC
August 5, 2014 August 18, 2014
Security Services for the Registration Data Access Protocol Security Services for the Registration Data Access Protocol
draft-ietf-weirds-rdap-sec-07 draft-ietf-weirds-rdap-sec-08
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 6, 2015. This Internet-Draft will expire on February 19, 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 3, line 43 skipping to change at page 3, line 43
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
servers MUST implement the authentication framework specified in servers MUST implement the authentication framework specified in
"HTTP Authentication: Basic and Digest Access Authentication" "HTTP Authentication: Basic and Digest Access Authentication"
[RFC2617]. The "basic" scheme can be used to send a client's user [RFC7235]. The "basic" scheme can be used to send a client's user
name and password to a server in plaintext, based64-encoded form. name and password to a server in plaintext, based64-encoded form.
The "digest" scheme can be used to authenticate a client without The "digest" scheme can be used to authenticate a client without
exposing the client's plaintext password. If the "basic" scheme is exposing the client's plaintext password. If the "basic" scheme is
used, HTTP Over TLS [RFC2818] MUST be used to protect the client's used, HTTP Over TLS [RFC2818] MUST be used to protect the client's
credentials from disclosure while in transit (see Section 3.4). credentials from disclosure while in transit (see Section 3.4).
Servers MUST support either Basic or Digest authentication; they are Servers MUST support either Basic or Digest authentication; they are
not required to support both. Clients MUST support both to not required to support both. Clients MUST support both to
interoperate with servers that support one or the other. interoperate with servers that support one or the other.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
other endpoint via a transport protocol, and validate the signature other endpoint via a transport protocol, and validate the signature
of the object on receipt. Digital signature algorithms as described of the object on receipt. Digital signature algorithms as described
in "Internet Security Glossary, Version 2" [RFC4949] are commonly in "Internet Security Glossary, Version 2" [RFC4949] are commonly
used to provide data integrity at the object level. used to provide data integrity at the object level.
There are no current requirements for object-level data integrity There are no current requirements for object-level data integrity
using digital signatures. Support for this feature could be added to using digital signatures. Support for this feature could be added to
RDAP in the future. RDAP in the future.
The most specific need for this service is to provide assurance that The most specific need for this service is to provide assurance that
HTTP 30x redirection hints [RFC2616] and response elements returned HTTP 30x redirection hints [RFC7231] and response elements returned
from the server are not modified while in transit. If the policy of from the server are not modified while in transit. If the policy of
the server operator requires message integrity for client-server data the server operator requires message integrity for client-server data
exchanges, HTTP Over TLS MUST be used to protect those exchanges. exchanges, HTTP Over TLS MUST be used to protect those exchanges.
4. IANA Considerations 4. IANA Considerations
This document does not specify any IANA actions. This section can be This document does not specify any IANA actions. This section can be
removed if this document is published as an RFC. removed if this document is published as an RFC.
5. Security Considerations 5. Security Considerations
skipping to change at page 8, line 23 skipping to change at page 8, line 23
confidentiality services are needed. confidentiality services are needed.
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.
Additional security considerations are described in the Additional security considerations are described in the
specifications for HTTP [RFC2616], HTTP basic and digest access specifications for HTTP [RFC7231], HTTP basic and digest access
authentication [RFC2617], HTTP Over TLS [RFC2818], and additional authentication [RFC7235], HTTP Over TLS [RFC2818], and additional
HTTP status codes [RFC6585]. Security considerations for federated HTTP status codes [RFC6585]. Security considerations for federated
authentication systems can be found in the OAuth [RFC6749] and OpenID authentication systems can be found in the OAuth [RFC6749] and OpenID
[OpenID] specifications. [OpenID] specifications.
6. Acknowledgements 6. Acknowledgements
The authors would like to acknowledge the following individuals for The authors would like to acknowledge the following individuals for
their contributions to this document: Richard Barnes, Marc Blanchet, their contributions to this document: Richard Barnes, Marc Blanchet,
Ernie Dainow, Spencer Dawkins, Jean-Philippe Dionne, Byron Ellacott, Ernie Dainow, Spencer Dawkins, Jean-Philippe Dionne, Byron Ellacott,
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-07 (work in progress), April 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-11
(work in progress), July 2014. (work in progress), July 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-08 (work in progress), February 2014. weirds-using-http-09 (work in progress), August 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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[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
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
7.2. Informative References 7.2. Informative References
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final",
December 2007, <http://specs.openid.net/auth/2.0>. December 2007, <http://specs.openid.net/auth/2.0>.
[RFC3707] Newton, A., "Cross Registry Internet Service Protocol [RFC3707] Newton, A., "Cross Registry Internet Service Protocol
(CRISP) Requirements", RFC 3707, February 2004. (CRISP) Requirements", RFC 3707, February 2004.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004. September 2004.
skipping to change at page 10, line 42 skipping to change at page 10, line 39
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.
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 17 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/