idnits 2.17.1 draft-dukhovni-using-wildcard-a-rrsets-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Dukhovni 3 Internet-Draft 4 Intended status: BCP N. Williams, Ed. 5 Expires: April 30, 2015 Cryptonector 6 October 27, 2014 8 Using Wildcard A and AAAA Resource Records in the DNS for Per-User Host- 9 Based Services 10 draft-dukhovni-using-wildcard-a-rrsets-01 12 Abstract 14 This document describes how the use of wildcard A and AAAA resource 15 records (RRs) in the Domain Name System (DNS), optionally coupled 16 with self-service key management for host names that match the 17 wildcards, to create per-user services. This memo describes what 18 should be a best current practice. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 30, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Wildcard A/AAAA RRs in DNS for Per-User Host-Based 55 Services (PUHBSs) . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions used in this document . . . . . . . . . . . . . 3 57 3. Provisioning of Service Credentials, or Self-Service 58 Key Management . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Requirements and Recommendations . . . . . . . . . . . . . 4 60 3.2. Sample Use Case: per-User Web Services . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . 5 62 4.1. Man-in-the-Middle Attacks by Local Users . . . . . . . . . 5 63 4.1.1. Security Considerations for Per-User HTTP Services . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 7 70 1. Wildcard A/AAAA RRs in DNS for Per-User Host-Based Services (PUHBSs) 72 Often users need to run services (often on multi-user systems) that 73 need host-based service principal names. We describe a method for 74 arranging this without having to share sensitive cryptographic host 75 credentials with users: 77 1. Publish in the DNS [RFC1034] [RFC1035] a wildcard A and/or AAAA 78 RRset for every hostname on which self-service per-user services 79 will be permitted. 81 This means that for any host named, say, "foo.bar.example", one 82 would publish "*.foo.bar.example.", with the same A and/or AAAA 83 RRset as "foo.bar.example.". 85 2. Provision users with credentials for host-based service names on 86 hostnames of the form: .. 88 This allows users to publish "." as their 89 services' hostname. 91 For the rest of this document we shorten "per-user host-based service 92 principal" to "PUHBSP". 94 And that's it. The difficult part, of course, is (2), but it is 95 possible to adjust existing provisioning systems and/or build new 96 ones to address this. See Section 3 98 2. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Provisioning of Service Credentials, or Self-Service Key Management 106 Existing standard and non-standard Kerberos [RFC4120] administration 107 and PKIX [RFC5280] online certification authority (CA) protocols may 108 be used for self-service key management of PUHBSP credentials with 109 minimal changes. The main change that is needed is an authorization 110 change on the server-side. 112 Example protocols whose services may be modified to suit this 113 purpose: 115 o The "Microsoft Windows 2000 Kerberos Change Password and Set 116 Password Protocols" [RFC3244] and its non-standard predecessors. 117 o The various other non-standard Kerberos administration protocols 118 that provide interfaces for creating principals and setting their 119 credentials. For example: 120 * 121 * 122 * and others. 123 o kx509 [RFC6717] (a kerberized online CA). 124 o Any protocol using PKCS#10 [RFC2986]. 126 The principle is general, applying to any authentication mechanism 127 that can authenticate host-based services, not just Kerberos or PKIX. 129 3.1. Requirements and Recommendations 131 Three different sorts of authorization decisions are involved: 133 1. DNS zone administrators decide which hosts get wildcard A/AAAA 134 RRsets. 136 DNS zone administrators MAY safely publish wildcard A and AAAA 137 RRsets for all hostnames in their zones, but they may also keep a 138 white-list of such hostnames. 140 2. The PUHBSP's credential issuer MUST decide whether to issue 141 credentials for any given sub-domain of a given hostname. 143 This decision MUST be based on and constrained by the requestor's 144 credentials. For example, the issuer might require that a client 145 authenticate with a user and a host-based service credential or 146 that a user have opted-in any given host whose credentials will 147 be used to acquire the PUHBSP's credentials, it might require 148 that the username label of the PUHBSP correspond to an existing 149 user, and so on. 151 Credential issuers SHOULD NOT issue PUHBSP credentials for 152 hostnames with more than one sub-domain label of the actual 153 host's hostname. 155 3. Hosts themselves SHOULD authorize local requests by local users/ 156 processes for credentials for any given sub-domain of the host's 157 hostname. 159 For example, a host might authenticate local users using traditional 160 operating system facilities (e.g., processes' credentials), then 161 decide whether the local user gets to have a requested sub-domain of 162 the host's hostname. 164 3.2. Sample Use Case: per-User Web Services 166 In our deployment it is trivial for users to run their own web 167 services: 169 o pick an available port number, 170 o locally request credentials (server certificates and/or Kerberos 171 keys) for running a web service on ".:" (for example, 173 https://jdoe.someserver.foo.example:3000/), 174 o configure the web service to start on the chosen port number and 175 with the given credentials, 176 o then start the service. 178 In this use case no credential acquisition protocols were modified. 179 Instead their services were modified to permit clients with host- 180 based service credentials to acquire credentials for PUHBSPs whose 181 hostname component is a sub-domain of the actual host's. 183 4. Security Considerations 185 Some hostnames may be meaningful (e.g., "irc.foo.bar.example" might 186 be taken to mean that an IRC [RFC2812] server is located at that 187 hostname). Users may need to be educated as to how to determine that 188 a fully-qualified hostname is a per-user one. 190 Credential issuers SHOULD keep white-lists of users and hostnames 191 that are permitted to have PUHBSPs, though not necessarily white- 192 lists of {username, hostname} that are permitted to have PUHBSPs. 194 Self-service key management services for PKIX [RFC5280] SHOULD use an 195 intermediate, online certification authority (CA), rather than a top- 196 level CA, so as to make it possible to revoke the online CA's 197 certificate. (This is good advice for any CA anyways.) 199 Note that this scheme does not support users from more than one realm 200 having PUHBSPs on the same host. 202 4.1. Man-in-the-Middle Attacks by Local Users 204 Note that a large number of port numbers for running services are 205 available to all users on most operating systems. This means that a 206 local user could start a proxy on one port and forward to another 207 port on the same host, where the second port is a service run by a 208 different user. Mutual authentication generally protects against 209 this attack. 211 4.1.1. Security Considerations for Per-User HTTP Services 213 Hypertext Transfer Protocol (HTTP) [RFC2616] used with the SPNEGO- 214 based [RFC4178] HTTP authentication method [RFC4559] is quite common 215 in some environments. Negotiate does not make use of session keys to 216 protect HTTP data and metadata. To safeguard against this, per-user 217 HTTP services MUST use Transport Layer Security (TLS) [RFC5246], not 218 just SPNEGO. 220 5. IANA Considerations 222 There are no IANA considerations in this document. 224 6. References 226 6.1. Normative References 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, March 1997. 231 6.2. Informative References 233 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 234 STD 13, RFC 1034, November 1987. 236 [RFC1035] Mockapetris, P., "Domain names - implementation and 237 specification", STD 13, RFC 1035, November 1987. 239 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 240 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 241 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 243 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", 244 RFC 2812, April 2000. 246 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 247 Request Syntax Specification Version 1.7", RFC 2986, 248 November 2000. 250 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 251 2000 Kerberos Change Password and Set Password Protocols", 252 RFC 3244, February 2002. 254 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 255 Kerberos Network Authentication Service (V5)", RFC 4120, 256 July 2005. 258 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 259 Simple and Protected Generic Security Service Application 260 Program Interface (GSS-API) Negotiation Mechanism", 261 RFC 4178, October 2005. 263 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 264 Kerberos and NTLM HTTP Authentication in Microsoft 265 Windows", RFC 4559, June 2006. 267 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 268 Housley, R., and W. Polk, "Internet X.509 Public Key 269 Infrastructure Certificate and Certificate Revocation List 270 (CRL) Profile", RFC 5280, May 2008. 272 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 273 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 275 [RFC6717] Hotz, H. and R. Allbery, "kx509 Kerberized Certificate 276 Issuance Protocol in Use in 2012", RFC 6717, August 2012. 278 Authors' Addresses 280 Viktor Dukhovni 282 Email: ietf-dane@dukhovni.org 284 Nicolas Williams (editor) 285 Cryptonector, LLC 287 Email: nico@cryptonector.com