idnits 2.17.1 draft-vanrein-dnstxt-krb1-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 : ---------------------------------------------------------------------------- ** 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 115: '... adhere to this syntax, it MUST NOT be...' RFC 2119 keyword, line 116: '...is specification, but this MUST NOT be...' RFC 2119 keyword, line 119: '... application MAY release a warning m...' RFC 2119 keyword, line 123: '...gnise a tag name MUST silently discard...' RFC 2119 keyword, line 159: '... the SRV queries MUST be used in the p...' (12 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 19, 2014) is 3475 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2782' is mentioned on line 157, but not defined == Unused Reference: 'RFC4033' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC4343' is defined on line 461, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 5 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: Experimental October 19, 2014 5 Expires: April 22, 2015 7 Finding the Kerberos Realm of a Service in DNS 8 draft-vanrein-dnstxt-krb1-00 10 Abstract 12 This specification defines methods to determine realm names for 13 services being contacted by their DNS name. Currently, finding realm 14 names is done through guessing or local configuration. DNS can make 15 this process more dynamic, provided that DNSSEC is used to ensure 16 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 22, 2015. 35 Copyright Notice 37 Copyright (c) 2014 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. Kerberos TXT record syntax . . . . . . . . . . . . . . . . . 3 54 3. Defining Home Records and Home Tags . . . . . . . . . . . . . 3 55 4. Querying Realm Descriptions . . . . . . . . . . . . . . . . . 4 56 4.1. Querying a Domain's Realm Descriptions . . . . . . . . . 4 57 4.2. Querying a Host's Realm Descriptions . . . . . . . . . . 5 58 5. Publishing Realm Descriptions . . . . . . . . . . . . . . . . 5 59 6. Realm Descriptor Tags . . . . . . . . . . . . . . . . . . . . 6 60 6.1. Realm Descriptor Tag "realm" . . . . . . . . . . . . . . 6 61 6.2. Realm Descriptor tag "service" . . . . . . . . . . . . . 7 62 6.3. Realm Descriptor Tag "user" . . . . . . . . . . . . . . . 8 63 7. Efficiency Considerations . . . . . . . . . . . . . . . . . . 8 64 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 11.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 When a client contacts a Kerberised service, it needs to obtain a 75 service ticket, and for that it needs to contact the realm under 76 which the service is run. To map a service name into a realm name 77 and then into a KDC, the client uses local mappings, or it can 78 contact its KDC which look into its local mappings. Through DNS, 79 such mappings could be dynamically expanded, thus permitting more 80 flexibility without explicit configuration. 82 There are two important mappings that are needed for the given 83 scenario. One is a mapping from the FQDN of a service to its realm 84 name; the other is a mapping from the realm name to the 85 Kerberos5-specific services such as the KDC. The latter mapping is 86 published in SRV records [RFC4120] and the traffic is protected by 87 the protocols themselves. The first mapping however, has never been 88 standardised and are ill-advised because unsecured DNS cannot be 89 considered a reliable source. 91 With the recent rise of DNSSEC however, it is possible to make a 92 reliable judgement on the authenticity of such data, which enables 93 the standardisation of the first mapping in the form of TXT records 94 in DNS. This specification defines how to publish and process such 95 records. 97 Each TXT record holds of a series of tagged string values. A few of 98 these are defined below, others may be added by future 99 specifications. 101 2. Kerberos TXT record syntax 103 The TXT record for Kerberos is a simple sequence of ABNF terminals: 105 "v" "=" "krb1" *( ";" tag "=" value ) 107 The initial v=krb1 is used as a hint to applications that this 108 specification is followed. Space and tab character sequences after 109 terminals are ignored; a tag is a sequence of letters, digits, dashes 110 and underscores; a value is anything but whitespace or semicolons. 111 Note that the entire TXT record is case-insensitive. TODO: Really? 112 "The ASCII case insensitivity conventions only apply to ASCII labels" 113 [Section 3.2 of [RFC4343]] 115 When a TXT record does not adhere to this syntax, it MUST NOT be 116 processed as described in this specification, but this MUST NOT be 117 fatal to the processing of other TXT records. When the initial 118 v=krb1 matches the syntax but the rest does not, then a processing 119 application MAY release a warning message. 121 Tags are registered with IANA, and this document defines the first 122 few. New additions are always optional. An application that does 123 not recognise a tag name MUST silently discard it. 125 Multiple TXT records may be supplied under a queried name, and there 126 may be multiple that adhere to this syntax; these present 127 alternatives that can be tried. Since DNS does not supply them in 128 any order, the DNS client can choose freely in what order to process 129 these records. When no TXT record adheres to this syntax, then no 130 alternative is available through DNS. 132 3. Defining Home Records and Home Tags 134 The TXT records defined here may be used to define realm names that 135 do not look similar to the FQDN at which it is found. Other TXT 136 records may define one domain-styled [Section 6.1 of [RFC4120]] realm 137 name that translates back to the FQDN at which the TXT record was 138 found. The latter category of TXT record is called a "home record" 139 in this specification. 141 TXT records which are not home records can be used to reference from 142 a DNS name to a realm that maps onto another DNS name. The use of 143 DNSSEC makes this safe; the same party that masters the server 144 settings also determines the authentication service to use. 146 Some tags may be defined to be used in home record only. Such tags 147 are defined by the term "home tags". Specification whether a tag is 148 a home tag is intended to avoid claims about realms being made 149 outside its control. 151 4. Querying Realm Descriptions 153 The following subsections define two procedures for finding a 154 Kerberos realm. One procedure starts from a domain name, the other 155 starts from the hostame of a server. 157 When dealing with services found through DNS SRV [RFC 2782], a choice 158 between the use of a domain name or hostname is possible. In these 159 situations, the FQDN of the SRV queries MUST be used in the procedure 160 for domain name queries. 162 Since DNS in general cannot be considered secure, the client MUST 163 dismiss any DNS responses that are not Insecure, Bogus or 164 Indeterminite [Section 5 of [RFC4033]]. Only Secure responses are 165 taken into account. This specification does not prescribe that the 166 client validates the responses by itself, but the deployment used 167 SHOULD NOT accept validation states of DNS responses from a reliable 168 validating source over unreliable communication channels. 170 The result may contain TXT records that do not adhere to the syntax 171 of this specification; such TXT records MUST be removed from the 172 result. Within the syntax, there may be tags that are unknown; such 173 tags and their value MUST be ignored when further processing the 174 results. Finally, some tags are defined as "home tags", and those 175 MUST be ignored if the TXT record is not a home record. 177 When no Secure DNS responses are received, this procedure MUST be 178 terminated without extracting realm descriptive information from DNS. 179 Such termination need not be fatal; other procedures may exist to 180 find a realm name. 182 4.1. Querying a Domain's Realm Descriptions 184 To find the Kerberos realm definition for a domain name, a DNS client 185 conducts a TXT query targeted at the domain name. 187 Where this specification speaks of querying a domain, its 188 interpretation of a domain is that of a name space, which may or may 189 not have a host attached, but which is likely to have services 190 attached, for instance through MX or SRV records. Domain names also 191 occur in many naming schemes after an optional username and @ symbol, 192 such as the domain name (that also happens to be termed "realm", but 193 without connection to Kerberos realms) in a Network Access Identifier 194 [RFC4282]. 196 4.2. Querying a Host's Realm Descriptions 198 The query of a hostname may be done at two levels, namely the 199 hostname itself and the apex of the zone holding the hostname. The 200 latter requires a signed denial for the hostname; the signature of 201 this denial holds a field named the "Signer's Name" which must 202 contain the zone name [Section 3.1.7 of [RFC4034]], which is used for 203 the second query if the name differs from the initial hostname. 205 Note that most name servers will also return a SOA record with a 206 negative response; this addition however, is not guaranteed and it 207 may be removed from the response due to frame size constraints. This 208 is why the SOA record is not preferred for finding the secondary 209 description. 211 5. Publishing Realm Descriptions 213 The default position for realm-descriptive TXT records is in the apex 214 of a zone. These may be home records, but that is not a requirement; 215 it is possible to authenticate multiple domain names with a single 216 Kerberos realm. 218 It is possible to override entries underneath the zone apex. This 219 may be done for individual host names, or through a wildcard that 220 catches a range of undefined names. Note that wildcards receive 221 special treatment [RFC4592] when used with DNSSEC, but that they are 222 supported. 224 The various entries in DNS override each other in a particular order; 225 the zone apex is the fallback default; wildcards cator to unspecific 226 subordinate names, and an accurately matched hostname has the highest 227 priority. 229 Note that a domain is not always the same as a zone apex. So, when 230 querying a domain name as specified in Section 4.1, there will be no 231 fallback to a zone apex. An entry similar to the one in a zone apex 232 should then be defined; and similarly, it may be overridden with 233 wildcards and hostnames that define subordinate DNS names. 235 The syntax supports TXT records that define no realm at all. These 236 are interpreted as the absense of Kerberos for the given name. 238 6. Realm Descriptor Tags 240 The names of tags fall apart in two types: 242 o "General tags" can be used in any v=krb1 TXT records; 244 o "Home tags" can only be used in TXT records that describe a realm 245 that matches the FQDN of the TXT record. 247 When home tags occur in a TXT record that does not define a realm 248 name that matches the FQDN of the TXT record, then these home tags 249 MUST be ignored. 251 6.1. Realm Descriptor Tag "realm" 253 The tag "realm" MAY be present in all TXT records that adhere to this 254 specification, and it MUST be processed by implementations of this 255 specification. 257 The value of a "realm" tag names a realm connected to the TXT 258 record's FQDN. Since the content of a TXT record is case- 259 insensitive, a mapping to case-sensitive realm names is needed. In 260 this mapping, a realm-value letter is mapped to a lowercase letter if 261 it is preceded by an equals sign and mapped to an uppercase letter if 262 not; equals signs are not mapped to realm characters; all other 263 characters are mapped without modification. The result MUST be a 264 domain-style realm name [Section 6.1 of [RFC4120] to be accepted for 265 further processing along the lines of this specification. 267 When multiple "realm" tags occur in one TXT record, then they present 268 alternative suggestions to combine with all other tags in the same 269 TXT record. Note that a TXT record with multiple "realm" tags is 270 never a home record. 272 The absense of a "realm" tag in a TXT record conforms to this 273 specification; it does not provide any realm names for the given FQDN 274 in DNS. One such TXT record can be used to specify the absense of 275 Kerberos tickets for the FQDN of that TXT record; this can be used to 276 override TXT records in a wildcard or at the zone apex. 278 An example use of the "realm" tag in a TXT record is 280 example.com. IN TXT "v=krb1; realm=EXAMPLE.COM" 282 Since the FQDN of this TXT record is example.com, this TXT record may 283 also hold home tags. 285 In addtion to the previous example, the following tag indicates that 286 there is no realm, and so it is useless to lookup a Kerberos ticket 287 for ftp.example.com: 289 ftp.example.com. IN TXT "v=krb1" 291 6.2. Realm Descriptor tag "service" 293 The tag "service" MAY be present in any TXT record that adheres to 294 this specification, and it SHOULD be recognised by implementations of 295 this specification. The tag is optional. 297 The value of a "service" tag is the name of a service, as used in 298 principal names. This can be used as a hint to clients that need to 299 match service tags. The occurrence of a service tag and a realm tag 300 in the same TXT record may be read to suggest that a principal ticket 301 for the combination exists. Since service names are used to match, 302 and act as a hint, their representation without case in DNS is not a 303 problem; they are matched through case-insensitive comparison. 305 The purpose of this tag is to enable clients an early selection 306 between alternatives that it may wish to pursue; adding a service tag 307 may improve the speed of resolution when multilple alternatives are 308 listed in DNS, especially when future initatives would require public 309 key cryptography for realm crossover. Since the tag is optional and 310 its presence may not lead to a single combination of realm, service 311 and FQDN, clients must still be prepared to iterate over 312 alternatives. 314 When multiple "service" tags occur in one TXT record, then they 315 present alternative suggestions to combine with all other tags in the 316 same TXT record. The set is then to be considered complete; that is, 317 when one or more "service" tags occur but none matches to a service 318 that a client requires, then the realm description in that TXT record 319 does not apply. 321 An example use of this tag in a TXT record is 323 www.example.com. IN TXT "v=krb1; realm=example.com; 324 realm=example.org; service=http; service=ftp" 326 This would match with the following principal names: 328 o HTTP/www.example.com@EXAMPLE.COM 330 o HTTP/www.example.com@EXAMPLE.ORG 332 o ftp/www.example.com@EXAMPLE.COM 333 o ftp/www.example.com@EXAMPLE.ORG 335 A service named "krbtgt" is not offered for this service name, as far 336 as this TXT record is concerned. 338 6.3. Realm Descriptor Tag "user" 340 TODO: Also define a "user" tag? RFC 3645 uses DNS@ krb4-style names, 341 but in general I doubt if users should occur in DNS? 343 7. Efficiency Considerations 345 The TXT records introduced in this specification are useful to define 346 realm names for servers whose DNS information is not statically 347 configured in a Kerberos setup. This may release the pressure on 348 such local configurations, and it may introduce more dynamicity, 349 which may be useful for such things as realm crossover. 351 Since realm names cannot always be derived from DNS names, clients 352 tend to construct various principal names by attaching all the realm 353 names that they can think of, and attempting to obtain a service 354 ticket for each in turn, until one is found. The KDC may also 355 perform such actions, and return a reference [RFC6806] to a realm for 356 consideration. In general, the list of service ticket names that may 357 be considered can be relatively long. 359 Limiting the length of the list of ticket requests is going to be 360 especially useful for situations with realm crossover when this 361 involves public-key cryptography, as such algorithms are much slower 362 than the symmetric algorithms normally used for Kerberos. 364 The use of "realm" tags can help the client to focus on those realms 365 for which a service has a name defined. Similarly, the use of 366 "service" tags is helpful to select only those TXT records that hold 367 the service name sought by an application. The presence of multiple 368 "realm" and/or multiple "service" tags in one TXT record enables 369 iteration over multiple combinations, without a need to store the 370 resulting cartesian product in DNS. 372 8. Privacy Considerations 374 It is common to spread service information in DNS, but for internal 375 use this may be considered less desirable. This is why the "service" 376 tag, as specified in Section 6.2, is optional. 378 9. Security Considerations 380 This specification defines a mechanism to redirect from a FQDN to a 381 realm that may be located elsewhere, or to indicate that no realm is 382 available for that FQDN. Publishing such a realm definition is the 383 prerogative of the service administrator, and is therefore well- 384 positioned in a DNS record at the same FQDN as the service, or at its 385 zone apex. 387 However, when an attacker would be permitted to spoof such a record 388 in a victim's DNS, then it could be possible for the attacker to 389 convince the client that the attacker is the authentic provider for 390 the service. Additional spoofing of hostname references could then 391 complete the attack. This has been mitigated by requiring DNSSEC for 392 all such TXT records. 394 Another angle of attack could be due to suppression of a TXT record, 395 for instance for a hostname. Such attacks could direct a client to 396 rely on the information stored in the zone apex, which may differ 397 from an overridden value that is less desirable to the attacker. 398 Such attacks have been mitigated by insisting on signed denials, and 399 by stating that a non-responsive DNS server should not lead to the 400 assumption that one can move up in the DNS hierarchy. 402 The process of finding the zone apex relies on a strict prescription 403 in DNSSEC standards. The field from which it is taken is 404 incorporated into the RRSIG record that holds it TODO:check, so this 405 does not provide an opening to redirect the TXT queries to a domain 406 of choice either. 408 The ability to create a TXT record that references a realm operated 409 under another DNS name introduces a potential of setting flags for 410 that remote realm that may be counter-productive. Given the open- 411 endedness of the registry for these, problems due to this are 412 mitigated by ignoring unknown tags, and treating known tags 413 differently when they are registered as "home" tags; such tags are 414 not processed for references to realms operated under another DNS 415 name. 417 10. IANA Considerations 419 This specification establishes a new registry with IANA, whose 420 entries are subject to expert review and whose definition must be 421 described in a publicly available specification. The new registry 422 will be known as the "Kerberos DNS TXT Tag Registry". Each entry 423 must provide a flag to indicate if the tag may only be interpreted in 424 home tags. 426 The initial entries for this new registry introduced by this 427 specification are: 429 +----------+-----------+--------------------------------+ 430 | Tag name | Home tag? | Definition | 431 +----------+-----------+--------------------------------+ 432 | v | N/A | Not to be used [TBD:THIS-SPEC] | 433 | realm | No | [TBD:THIS-SPEC] | 434 | service | No | [TBD:THIS-SPEC] | 435 +----------+-----------+--------------------------------+ 437 Tag names are case-insensitive. The tag name "v" is reserved, and 438 shall not be assigned. 440 In addition to the foregoing, tag names starting with "x-" are 441 reserved for experimental use, for which no registration is possible, 442 or required. For these unregistered tags there will be no protection 443 from name clashes. 445 11. References 447 11.1. Normative References 449 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 450 Rose, "DNS Security Introduction and Requirements", RFC 451 4033, March 2005. 453 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 454 Rose, "Resource Records for the DNS Security Extensions", 455 RFC 4034, March 2005. 457 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 458 Kerberos Network Authentication Service (V5)", RFC 4120, 459 July 2005. 461 [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity 462 Clarification", RFC 4343, January 2006. 464 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 465 System", RFC 4592, July 2006. 467 11.2. Informative References 469 [RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal 470 Name Canonicalization and Cross-Realm Referrals", RFC 471 6806, November 2012. 473 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 474 Network Access Identifier", RFC 4282, December 2005. 476 Author's Address 478 Rick van Rein 479 ARPA2.net 480 Haarlebrink 5 481 Enschede, Overijssel 7544 WP 482 The Netherlands 484 Email: rick@openfortress.nl