idnits 2.17.1 draft-ietf-weirds-rdap-sec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2012) is 4236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-weirds-json-response-00 == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-00 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-40) exists of draft-ietf-jose-json-web-encryption-05 == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-signature-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Hollenbeck 3 Internet-Draft Verisign Labs 4 Intended status: Standards Track N. Kong 5 Expires: March 23, 2013 CNNIC 6 September 19, 2012 8 Security Services for the Registration Data Access Protocol 9 draft-ietf-weirds-rdap-sec-00 11 Abstract 13 The Registration Data Access Protocol (RDAP) provides "RESTful" web 14 services to retrieve registration metadata from domain name and 15 regional internet registries. This document describes information 16 security services and their application to RDAP. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 23, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 54 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 3 55 3. Information Security Services and RDAP . . . . . . . . . . . . 3 56 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Availability . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Data Confidentiality . . . . . . . . . . . . . . . . . . . 4 59 3.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 5 60 3.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . . 5 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The Registration Data Access Protocol (RDAP) core is specified in two 73 documents: "Unified Registration Data Access Protocol Query Format" 74 [I-D.ietf-weirds-rdap-query] and "JSON Responses for the Registry 75 Data Access Protocol" [I-D.ietf-weirds-json-response]. One goal of 76 RDAP is to provide security services that do not exist in the WHOIS 77 [RFC3912] protocol, including authentication, availability, data 78 confidentiality, data integrity, and non-repudiation (note: some of 79 these might be a stretch). 81 This document describes each of these security services from the 82 perspective of RDAP requirements and applicability. Where 83 applicable, informational references to requirements for a WHOIS 84 replacement service [RFC3707] are noted. 86 2. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2.1. Acronyms and Abbreviations 94 DNR: Domain Name Registry 96 RDAP: Registration Data Access Protocol 98 RIR: Regional Internet Registry 100 3. Information Security Services and RDAP 102 RDAP itself does not include native security services. Instead, RDAP 103 relies on features that are available in other protocol layers to 104 provide needed security services including authentication, 105 availability, data confidentiality, data integrity, and non- 106 repudiation. A description of each of these security services can be 107 found in RFC 4949 [RFC4949]. 109 3.1. Authentication 111 WHOIS does not provide features to identify and authenticate clients. 112 As noted in section 3.1.4.2 of RFC 3707 [RFC3707], there is utility 113 in allowing server operators to offer "varying degrees of access 114 depending on policy and need". Clients have to be identified and 115 authenticated to provide that utility. 117 There are multiple ways to identify and authenticate RDAP clients. 118 Candidate technologies include: 120 - HTTP Basic Authentication [RFC2617]: The "basic" scheme can be 121 used to send a client's user name and password to a server in 122 plaintext, based64-encoded form. If this scheme is used another 123 protocol (such as HTTP Over TLS [RFC2818]) MUST be used to protect 124 the client's credentials from disclosure while in transit. 126 - HTTP Digest Authentication [RFC2617]: The "digest" scheme can be 127 used to authenticate a client without exposing the client's 128 plaintext password. 130 - X.509 Digital Certificates [RFC5280]: The Transport Layer Security 131 Protocol [RFC5246] includes an option to identify and authenticate 132 clients who possess and present a valid X.509 digital certificate. 133 Web clients do not typically possess digital certificates so this 134 option is likely impractical. 136 - OAuth [I-D.ietf-oauth-v2]: The OAuth authorization framework 137 describes a method for clients to access protected web resources 138 using access tokens issued by a third party authorization server 139 with the permission of the resource owner. If widely deployed it 140 would permit clients to access servers without having to manage 141 credentials on a per-server basis. 143 - (What else?) 145 3.2. Availability 147 An RDAP service has to be available to be useful (need to talk about 148 denial of service, anycasting, and anything else that addresses 149 availability). 151 3.3. Data Confidentiality 153 WHOIS does not provide the ability to encrypt data while in transit 154 to protect it from inadvertent disclosure. Web services commonly use 155 HTTP Over TLS [RFC2818] to provide that protection. Examples of data 156 confidentiality utility include: 158 - Encryption to protect plaintext passwords exchanged when using the 159 HTTP "basic" authentication scheme. 161 - Encryption to protect personal or otherwise sensitive data 162 returned in response to RDAP queries. 164 - (What else?) 166 If data confidentiality is useful, we should also plan to review the 167 JSON Web Encryption draft [I-D.ietf-jose-json-web-encryption]. 169 3.4. Data Integrity 171 TBD: is there value in signed responses? If so, the work being done 172 in the JOSE working group (such as what's described in the JSON Web 173 Signature draft [I-D.ietf-jose-json-web-signature]) may be useful. 174 There's no mention of a "signed response" requirement in RFC 3707. 176 3.5. Non-repudiation 178 TBD: does it make sense to talk about proof of integrity and data 179 origin authentication for responses? It might in the context of law 180 enforcement actions. Again, there's no requirement mentioned in RFC 181 3707. 183 4. IANA Considerations 185 This document does not specify any IANA actions. 187 5. Security Considerations 189 TBD 191 6. Acknowledgements 193 The authors would like to acknowledge the following individuals for 194 their contributions to this document: Andrew Newton. 196 7. References 198 7.1. Normative References 200 [I-D.ietf-weirds-json-response] 201 Newton, A. and S. Hollenbeck, "JSON Responses for the 202 Registy Data Access Protocol (RDAP)", 203 draft-ietf-weirds-json-response-00 (work in progress), 204 September 2012. 206 [I-D.ietf-weirds-rdap-query] 207 Newton, A. and S. Hollenbeck, "Unified Registration Data 208 Access Protocol Query Format", 209 draft-ietf-weirds-rdap-query-00 (work in progress), 210 September 2012. 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 216 Leach, P., Luotonen, A., and L. Stewart, "HTTP 217 Authentication: Basic and Digest Access Authentication", 218 RFC 2617, June 1999. 220 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 222 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 223 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 225 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 226 Housley, R., and W. Polk, "Internet X.509 Public Key 227 Infrastructure Certificate and Certificate Revocation List 228 (CRL) Profile", RFC 5280, May 2008. 230 7.2. Informative References 232 [I-D.ietf-jose-json-web-encryption] 233 Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web 234 Encryption (JWE)", draft-ietf-jose-json-web-encryption-05 235 (work in progress), July 2012. 237 [I-D.ietf-jose-json-web-signature] 238 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 239 Signature (JWS)", draft-ietf-jose-json-web-signature-05 240 (work in progress), July 2012. 242 [I-D.ietf-oauth-v2] 243 Hardt, D., "The OAuth 2.0 Authorization Framework", 244 draft-ietf-oauth-v2-31 (work in progress), August 2012. 246 [RFC3707] Newton, A., "Cross Registry Internet Service Protocol 247 (CRISP) Requirements", RFC 3707, February 2004. 249 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 250 September 2004. 252 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 253 RFC 4949, August 2007. 255 Appendix A. Change Log 257 Initial -00: Adopted as working group document. 259 Authors' Addresses 261 Scott Hollenbeck 262 Verisign Labs 263 12061 Bluemont Way 264 Reston, VA 20190 265 US 267 Email: shollenbeck@verisign.com 268 URI: http://www.verisignlabs.com/ 270 Ning Kong 271 China Internet Network Information Center 272 4 South 4th Street, Zhongguancun, Haidian District 273 Beijing 100190 274 China 276 Phone: +86 10 5881 3147 277 Email: nkong@cnnic.cn