idnits 2.17.1 draft-vanrein-dnstxt-krb1-09.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 124: '...e; invalid names SHOULD be ignored. T...' RFC 2119 keyword, line 129: '...tations of this specification MUST NOT...' RFC 2119 keyword, line 134: '...master zone files SHOULD NOT introduce...' RFC 2119 keyword, line 198: '...eros TXT records SHOULD protect them w...' RFC 2119 keyword, line 200: '... Operators SHOULD NOT define more th...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2016) is 2713 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4033' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RFC6806' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC6840' is defined on line 357, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3655 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft ARPA2.net 4 Intended status: Informational October 24, 2016 5 Expires: April 27, 2017 7 Declaring Kerberos Realm Names in DNS (_kerberos TXT) 8 draft-vanrein-dnstxt-krb1-09 10 Abstract 12 This specification defines a method to determine Kerberos realm names 13 for services that are known by their DNS name. Currently, such 14 information can only be found in static mappings or through educated 15 guesses. DNS can make this process more flexible, provided that 16 DNSSEC is used to assure authenticity of resource records. 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 April 27, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Defining _kerberos TXT Resource Records . . . . . . . . . . . 3 54 3. Publishing Kerberos Realm Names . . . . . . . . . . . . . . . 5 55 4. Querying Kerberos Realm Names . . . . . . . . . . . . . . . . 5 56 5. Efficiency Considerations . . . . . . . . . . . . . . . . . . 6 57 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 9.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 When a Kerberos client contacts a service, it needs to acquire a 69 service ticket, and for that it needs to contact the KDC for a realm 70 under which the service is run. To map a service name into a realm 71 name and then into a KDC, clients tend to use static mappings or 72 educated guesses; the client's KDC may or may not be involved in this 73 process. Through DNS, the static mappings could be replaced by 74 dynamic lookups, and migrate from local client configuration into the 75 hands of the party administrating a server's presence in DNS. This 76 brings improved flexibility and centralisation, which is 77 operationally desirable. 79 Two mappings are needed for a client to contact a service. One is a 80 mapping from the FQDN of a service to its realm name; the other is a 81 mapping from the realm name to the Kerberos-specific services such as 82 the KDC. The latter mapping is published in SRV records [RFC4120] 83 and such traffic is usually protected by Kerberos itself. The first 84 mapping however, has hitherto not been standardised and is ill- 85 advised over unsecured DNS because the published information is then 86 neither validated by DNS nor does it lead to a protocol that could 87 provide end-to-end validation for it. 89 With the recent uprise of DNSSEC, it is now possible to make a 90 reliable judgement on the authenticity of data in DNS, which enables 91 the standardisation of the first mapping in the form of resource 92 records under DNSSEC. 94 This specification defines a method to publish and process Kerberos 95 realm names in TXT resource records. These records hold a case- 96 sensitive string with the realm name. This has been informally 97 described and practiced, but generally considered insecure; adding 98 DNSSEC means that much of this existing practice can now be trusted. 100 It is suggested to use the name "_kerberos TXT" to informally refer 101 to the style of using DNS that is introduced in this specification. 103 2. Defining _kerberos TXT Resource Records 105 This specification uses the TXT resource record type in DNS to 106 represent a Kerberos realm name. The corresponding RDATA format is 107 as follows: 109 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 110 / REALMNAME / 111 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 113 The REALMNAME is represented as a [RFC1035] which 114 starts with a single-byte length, followed by as many bytes of realm 115 name as the length byte's value. The RDATA field therefore has a 116 length of 1 up to 256 bytes, to hold a realm name of 0 up to 255 117 bytes. For instance, a realm EXAMPLE.ORG would be represented with 118 the following RDATA, written in the notation for unkonwn resource 119 record types [RFC3597]: 121 \# 12 ( 0b 45 58 41 4d 50 4c 45 2e 4f 52 47 ) 123 The REALMNAME represents a Kerberos realm name [Section 6.1 of 124 [RFC4120]], not a DNS name; invalid names SHOULD be ignored. The 125 empty string is considered an invalid REALMNAME, and it should be 126 noted that a REALMNAME may exceed the size constraints of a DNS name. 128 The TXT record can hold one or more values in an 129 ordered sequence, and implementations of this specification MUST NOT 130 reject TXT records with multiple s. This 131 specification only describes the meaning of the first as a REALMNAME, and leaves the interpretation of further 133 s to future specifications. Until these 134 specifications are adopted, master zone files SHOULD NOT introduce 135 these extra s. If such future specifications 136 intend to specify Kerberos aspects that do not include a realm name, 137 then they can mention an invalid realm name such as an empty 138 . 140 Though any style of realm name may be published as _kerberos TXT, it 141 is common for realm names in Kerberos to follow the domain style 142 [Section 6.1 of [RFC4120]], in which case they look like DNS names 143 but are case sensitive; unlike the DNS names used as lookup keys in 144 the DNS hierarchy, the REALMNAME format follows the format in being case-sensitive. Even for domain-style realm 146 names, there is no required relationship (such as partial overlap) 147 between the realm name and the DNS name at which a TXT record is 148 found. 150 In fact, the format is a binary format, and DNS 151 notation \DDD [Section 5.1 of [RFC1035]] exists to put arbitrary 152 bytes in the string notation. This binary format leaves the door 153 ajar for future internationalisation of Kerberos realm names. Realm 154 names are defined with the KerberosString type [Section 5.2.1 of 155 [RFC4120]] which is an ASN.1 GeneralString, but its specification 156 currently advises to constrain the use of this string type to an 157 IA5String (basically using only the first 128 codes of the ASCII 158 table) to avoid interoperability problems. After the 's length byte, the REALMNAME holds the value of the 160 GeneralString, but not its preceding ASN.1 tag and length. 162 It is worth noting that the ESC "%" "G" prefix [TODO:xref 163 target="ISO2022"/] can be used to introduce an UTF8String in a 164 GeneralString, and that implementations exist that insert UTF8String 165 values in KerberosString fields without even that escape. All this 166 precedes formal standardisation of internationalisation, but it 167 suggests that the RDATA definition for TXT can be supportive of 168 future internationalisation of realm names, even if the current 169 advised use is limited to the value of an IA5String. 171 It is possible to create a TXT record for any _kerberos-prefixed DNS 172 name, but this specification only provides query procedures for host 173 names and domain names. The use with a domain name has the 174 additional use of denoting the precise spelling for a realm name 175 under its DNS-mapped name. DNS-mapped names currently would not 176 modify more than the case of a DNS name, and even that is only done 177 as the result of DNS compression [RFC4343]; but in a future with 178 internationalised realm names there might be more to reconstruct, in 179 which case this facility is likely to be helpful. 181 The format for the resource data in master zone files is standard for 182 DNS [RFC1035]. The TXT record is a general record and was not 183 especially designed for this purpose. The reason to use it 184 nonetheless is that it is an existing practice; the particular use 185 specified here is distinguished from comments in TXT records by 186 always prefixing a _kerberos label to a DNS name. An example 187 declaration of realm name EXAMPLE.ORG for a server named 188 imap.example.org would be: 190 imap.example.org. IN AAAA 2001:db8::143 191 _kerberos.imap.example.org. IN TXT "EXAMPLE.ORG" 192 The RDATA for this TXT record is shown above, in the generic RDATA 193 section notation. 195 3. Publishing Kerberos Realm Names 197 Zones that intend to provide applications with Kerberos realm names 198 through _kerberos TXT records SHOULD protect them with DNSSEC. 200 Operators SHOULD NOT define more than one valid realm name for a 201 given domain or host name. 203 Note that _kerberos TXT records with wildcard names will not work. 204 All host names and most domain names define at least one resource 205 record (of any type) with the name that the wildcard should cover. 206 These defined names cause the wildcards to be suppressed [RFC4592] 207 from DNS responses, even when querying a non-existent TXT record. 209 4. Querying Kerberos Realm Names 211 This section defines a procedure for determining the Kerberos realm 212 names for a server with a given host name or domain name, as well as 213 for a DNS-mapped realm name. This specification does not impose any 214 restriction on the additional use of other-than-DNS methods for for 215 obtaining a realm name. 217 When applications know their server host name, perhaps because it is 218 mentioned in a URL or in a ticket as a service principal name, or 219 when applications know a domain name for which they intend to learn 220 the realm name, they resolve the TXT record in DNS at the server host 221 name, prefixed with a _kerberos label. 223 Since DNS in general cannot be considered secure, the client MUST 224 validate DNSSEC and it MUST dismiss any DNS responses that are 225 Insecure, Bogus or Indeterminate [Section 5 of [RFC4033]]. Only the 226 remaining Secure responses are to be taken into account. This 227 specification does not require that the DNS client validates the 228 responses by itself, but a deployment of _kerberos TXT records SHOULD 229 NOT accept DNS responses from a trusted validating DNS resolver over 230 untrusted communication channels. 232 In addition to the above, the absense of a _kerberos DNS record may 233 be meaningful for security decisions. If such cases, the only denial 234 of existence of the _kerberos TXT records MUST be authenticated 235 denial. 237 Only the first lt;character-string> of a _kerberos TXT record is 238 considered; any further ones are silently ignored under this 239 specification. In addition, invalid realm names such as they empty 240 string are silently ignored. 242 To give one possible implementation, a Kerberos client or its KDC may 243 send DNS queries with the Authentic Data (AD) bit set to enable 244 DNSSEC [Section 5.7 of [RFC6840]], and thereby request that the 245 Authenticated Data bit is set in the response to indicate [RFC3655] 246 the Secure state for answer and authority sections of the response. 247 When the DNS traffic to and from the validating resolver is 248 protected, for instance because the validating resolver is reached 249 over a loopback interface, then the Kerberos client or its KDC has 250 implemented the requirements for Secure use of the answer and 251 authority sections in DNS responses. 253 When no Secure DNS responses are received when the DNS query times 254 out, then the TXT query MUST be terminated without extracting realm 255 names from DNS. This termination MAY be done immediately upon 256 receiving Secure denial for the requested TXT record. TXT query 257 termination need not be fatal; non-DNS procedures may exist to find a 258 realm name, including the current practice of static mappings and 259 educated guessing. 261 5. Efficiency Considerations 263 The lookup of _kerberos TXT records can be done by the Ticket 264 Granting Service of a KDC, which can respond with a Server Referral 265 [Section 8 of [RFC6806]] to Kerberos clients that enable 266 canonicalization. This can be used for clients that are not setup to 267 query DNS as specified above, and that will assume that a service is 268 running under the client's realm. The caching of DNS records, their 269 validation and possibly realm-crossover caching at the KDC can all 270 benefit the response time for future lookups by other Kerberos 271 clients. 273 6. Privacy Considerations 275 This specification barely publishes new information in DNS, with the 276 exception of markation of Kerberised services. When this is 277 considered unattractive from a privacy viewpoint, it may be better to 278 rely on the existing static tables for spreading this information in 279 a more controlled manner. 281 7. Security Considerations 283 There is no restriction for _kerberos TXT records to mention realm 284 names that map back to DNS names in a disjoint part of the DNS 285 hierarcy. The records could therefore specify realm names for a 286 service even if the service is not recognised by the realm. The KDC 287 for the appointed realm would be very clear about that when trying to 288 procure a service ticket, so there is no anticipated security issue 289 with such misguided use of _kerberos TXT records. 291 The general point is that the use of DNSSEC makes Kerberos accept 292 authentic information from the party that publishes the _kerberos TXT 293 record, and that party could specify improper realm names or drop 294 realm names that are vital to the client. This is not expected to be 295 a security risk either; the party publishing the _kerberos TXT record 296 is the same party that publishes the service's records, namely its 297 DNS operator. By publishing the service's record in DNS, this 298 operator already has potential control over service denial and other 299 man-in-the-middle attacks, so the _kerberos TXT record does not add 300 any new powers of abuse. 302 When an external attacker would be permitted to spoof a _kerberos TXT 303 record in a victim's DNS, then it could be possible for that attacker 304 to convince the client that the attacker is the authentic provider 305 for the service. Additional spoofing of host name references could 306 then complete the attack. This has been mitigated by strictly 307 requiring Secure validation results from a DNSSEC-aware resolver for 308 all _kerberos TXT records. 310 8. IANA Considerations 312 None. 314 9. References 316 9.1. Normative References 318 [RFC1035] Mockapetris, P., "Domain names - implementation and 319 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 320 November 1987, . 322 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 323 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 324 2003, . 326 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 327 Rose, "DNS Security Introduction and Requirements", 328 RFC 4033, DOI 10.17487/RFC4033, March 2005, 329 . 331 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 332 Kerberos Network Authentication Service (V5)", RFC 4120, 333 DOI 10.17487/RFC4120, July 2005, 334 . 336 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 337 Insensitivity Clarification", RFC 4343, 338 DOI 10.17487/RFC4343, January 2006, 339 . 341 [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos 342 Principal Name Canonicalization and Cross-Realm 343 Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, 344 . 346 9.2. Informative References 348 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 349 Authenticated Data (AD) bit", RFC 3655, 350 DOI 10.17487/RFC3655, November 2003, 351 . 353 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 354 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 355 . 357 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 358 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 359 DOI 10.17487/RFC6840, February 2013, 360 . 362 Appendix A. Acknowledgements 364 Thanks are due to the Kitten Workgroup for discussions during the 365 creation of this document. Especially Greg Hudson, Nico Williams and 366 Viktor Dukhovni have provided useful input. 368 This work was conducted under a grant from the programme "[veilig] 369 door innovatie" from the government of the Netherlands. It has also 370 been liberally supported by the NLnet Foundation. 372 Author's Address 374 Rick van Rein 375 ARPA2.net 376 Haarlebrink 5 377 Enschede, Overijssel 7544 WP 378 The Netherlands 380 Email: rick@openfortress.nl