idnits 2.17.1 draft-ietf-krb-wg-krb-dns-locate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1510], [RFC2052], [RFC1035], [RFC2246], [KERB-CHG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 20 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 80: '... a "_udp" record MUST be included. If...' RFC 2119 keyword, line 81: '...ts TCP transport, a "_tcp" record MUST...' RFC 2119 keyword, line 84: '...tls._tcp" record MUST be specified for...' RFC 2119 keyword, line 122: '... The Proto MUST be "_udp"....' RFC 2119 keyword, line 142: '... a "_tcp" record MUST be included. If...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2052' is mentioned on line 135, but not defined ** Obsolete undefined reference: RFC 2052 (Obsoleted by RFC 2782) == Missing Reference: 'RFC 1035' is mentioned on line 168, but not defined == Unused Reference: 'RFC2782' is defined on line 288, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. 'KERB-CHG' ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Ken Hornstein 3 NRL 4 July 29, 2002 Jeffrey Altman 5 Expires: January 29, 2003 Columbia University 7 Distributing Kerberos KDC and Realm Information with DNS 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. It is filed as , and expires on January 29, 2003. 32 Please send comments to the authors. 34 Abstract 36 Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- 37 col [RFC????] describe any mechanism for clients to learn critical 38 configuration information necessary for proper operation of the pro- 39 tocol. Such information includes the location of Kerberos key dis- 40 tribution centers or a mapping between DNS domains and Kerberos 41 realms. 43 Current Kerberos implementations generally store such configuration 44 information in a file on each client machine. Experience has shown 45 this method of storing configuration information presents problems 46 with out-of-date information and scaling problems, especially when 48 RFC DRAFT July 29, 2002 50 using cross-realm authentication. 52 This memo describes a method for using the Domain Name System 53 [RFC1035] for storing such configuration information. Specifically, 54 methods for storing KDC location and hostname/domain name to realm 55 mapping information are discussed. 57 DNS vs. Kerberos - Case Sensitivity of Realm Names 59 In Kerberos, realm names are case sensitive. While it is strongly 60 encouraged that all realm names be all upper case this recommendation 61 has not been adopted by all sites. Some sites use all lower case 62 names and other use mixed case. DNS on the other hand is case insen- 63 sitive for queries but is case preserving for responses to TXT 64 queries. Since "MYREALM", "myrealm", and "MyRealm" are all different 65 it is necessary that only one of the possible combinations of upper 66 and lower case characters be used. This restriction may be lifted in 67 the future as the DNS naming scheme is expanded to support non-ASCII 68 names. 70 Overview - KDC location information 72 KDC location information is to be stored using the DNS SRV RR [RFC 73 2052]. The format of this RR is as follows: 75 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 77 The Service name for Kerberos is always "_kerberos". 79 The Proto can be either "_udp", "_tcp", or "_tls._tcp". If these SRV 80 records are to be used, a "_udp" record MUST be included. If the 81 Kerberos implementation supports TCP transport, a "_tcp" record MUST 82 be included. When using "_tcp" with "_kerberos", this indicates a 83 "raw" TCP connection without any additional encapsulation. A 84 "_tls._tcp" record MUST be specified for all Kerberos implementations 85 that support communication with the KDC across TCP sockets encapsu- 86 lated using TLS [RFC2246]. 88 The Realm is the Kerberos realm that this record corresponds to. 90 TTL, Class, SRV, Priority, Weight, and Target have the standard mean- 91 ing as defined in RFC 2052. 93 As per RFC 2052 the Port number should be the value assigned to "ker- 94 beros" by the Internet Assigned Number Authority (88). 96 RFC DRAFT July 29, 2002 98 Example - KDC location information 100 These are DNS records for a Kerberos realm ASDF.COM. It has two Ker- 101 beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be 102 directed to kdc1.asdf.com first as per the specified priority. 103 Weights are not used in these records. 105 _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 106 _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 107 _kerberos._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 108 _kerberos._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 109 _kerberos._tls._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 110 _kerberos._tls._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 112 Overview - Kerberos password changing server location information 114 Kerberos password changing server [KERB-CHG] location is to be stored 115 using the DNS SRV RR [RFC 2052]. The format of this RR is as fol- 116 lows: 118 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 120 The Service name for the password server is always "_kpasswd". 122 The Proto MUST be "_udp". 124 The Realm is the Kerberos realm that this record corresponds to. 126 TTL, Class, SRV, Priority, Weight, and Target have the standard mean- 127 ing as defined in RFC 2052. 129 As per RFC 2052 the Port number should be the value assigned to 130 "kpasswd" by the Internet Assigned Number Authority (464). 132 Overview - Kerberos admin server location information 134 Kerberos admin location information is to be stored using the DNS SRV 135 RR [RFC 2052]. The format of this RR is as follows: 137 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 139 The Service name for the admin server is always "_kerberos-adm". 141 The Proto can be either "_udp" or "_tcp". If these records are to be 142 used, a "_tcp" record MUST be included. If the Kerberos admin imple- 143 mentation supports UDP transport, a "_udp" record SHOULD be included. 145 The Realm is the Kerberos realm that this record corresponds to. 147 RFC DRAFT July 29, 2002 149 TTL, Class, SRV, Priority, Weight, and Target have the standard mean- 150 ing as defined in RFC 2052. 152 As per RFC 2052 the Port number should be the value assigned to 153 "kerberos-adm" by the Internet Assigned Number Authority (749). 155 Note that there is no formal definition of a Kerberos admin protocol, 156 so the use of this record is optional and implementation-dependent. 158 Example - Kerberos administrative server location information 160 These are DNS records for a Kerberos realm ASDF.COM. It has one 161 administrative server, kdc1.asdf.com. 163 _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 749 kdc1.asdf.com. 165 Overview - Hostname/domain name to Kerberos realm mapping 167 Information on the mapping of DNS hostnames and domain names to Ker- 168 beros realms is stored using DNS TXT records [RFC 1035]. These 169 records have the following format. 171 Service.Name TTL Class TXT Realm 173 The Service field is always "_kerberos", and prefixes all entries of 174 this type. 176 The Name is a DNS hostname or domain name. This is explained in 177 greater detail below. 179 TTL, Class, and TXT have the standard DNS meaning as defined in RFC 180 1035. 182 The Realm is the data for the TXT RR, and consists simply of the Ker- 183 beros realm that corresponds to the Name specified. 185 When a Kerberos client wishes to utilize a host-specific service, it 186 will perform a DNS TXT query, using the hostname in the Name field of 187 the DNS query. If the record is not found, the first label of the 188 name is stripped and the query is retried. 190 Compliant implementations MUST query the full hostname and the most 191 specific domain name (the hostname with the first label removed). 192 Compliant implementations SHOULD try stripping all subsequent labels 193 until a match is found or the Name field is empty. 195 RFC DRAFT July 29, 2002 197 Example - Hostname/domain name to Kerberos realm mapping 199 For the previously mentioned ASDF.COM realm and domain, some sample 200 records might be as follows: 202 _kerberos.asdf.com. IN TXT "ASDF.COM" 203 _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM" 204 _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM" 206 Let us suppose that in this case, a Kerberos client wishes to use a 207 Kerberized service on the host foo.asdf.com. It would first query: 209 _kerberos.foo.asdf.com. IN TXT 211 Finding no match, it would then query: 213 _kerberos.asdf.com. IN TXT 215 And find an answer of ASDF.COM. This would be the realm that 216 foo.asdf.com resides in. 218 If another Kerberos client wishes to use a Kerberized service on the 219 host salesserver.asdf.com, it would query: 221 _kerberos.salesserver.asdf.com IN TXT 223 And find an answer of SALES.ASDF.COM. 225 Security considerations 227 As DNS is deployed today, it is an unsecure service. Thus the infor- 228 mation returned by it cannot be trusted. 230 Current practice for REALM to KDC mapping is to use hostnames to 231 indicate KDC hosts (stored in some implementation-dependent location, 232 but generally a local config file). These hostnames are vulnerable 233 to the standard set of DNS attacks (denial of service, spoofed 234 entries, etc). The design of the Kerberos protocol limits attacks of 235 this sort to denial of service. However, the use of SRV records does 236 not change this attack in any way. They have the same vulnerabili- 237 ties that already exist in the common practice of using hostnames for 238 KDC locations. 240 Current practice for HOSTNAME to REALM mapping is to provide a local 241 configuration of mappings of hostname or domain name to realm which 242 are then mapped to KDCs. But this again is vulnerable to spoofing 243 via CNAME records that point to hosts in other domains. This has the 244 same effect as when a TXT record is spoofed. In a realm with no 246 RFC DRAFT July 29, 2002 248 cross-realm trusts this is a DoS attack. However, when cross-realm 249 trusts are used it is possible to redirect a client to use a comprom- 250 ised realm. 252 What this implies is that it is possible to cause a client to be 253 authenticated to a host other than the one desired by the end user. 254 In a single realm scenario a spoofed DNS response can cause a client 255 to be redirected to an attacker's host, but the authentication would 256 fail. However, in the cross-realm scenario an attacker who has 257 administrative control over a realm that has a cross-realm trust 258 established with the local realm, the attacker can redirect the 259 client to a host for which valid credentials would be issued by the 260 attacker's KDC. Since the credentials are valid there are no authen- 261 tication failures and the client believes they are connected to the 262 desired host. 264 This is not an exploit of the Kerberos protocol but of the Kerberos 265 trust model. The same can be done to any application that must 266 resolve the hostname in order to determine which domain a non-FQDN 267 belongs to. 269 Implementations SHOULD provide a way of specifying this information 270 locally without the use of DNS. However, to make this feature 271 worthwhile a lack of any configuration information on a client should 272 be interpretted as permission to use DNS. 274 Expiration 276 This Internet-Draft expires on January 29, 2003. 278 References 280 [RFC1510] 281 The Kerberos Network Authentication System; Kohl, Newman; Sep- 282 tember 1993. 284 [RFC1035] 285 Domain Names - Implementation and Specification; Mockapetris; 286 November 1987 288 [RFC2782] 289 A DNS RR for specifying the location of services (DNS SRV); Gul- 290 brandsen, Vixie; Feburary 2000 292 [KERB-CHG] 293 Kerberos Change Password Protocol; Horowitz; 294 ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg- 296 RFC DRAFT July 29, 2002 298 password-02.txt 300 [RFC2246] 301 The TLS Protocol - Version 1.0 (TLS); Dierks, Allen; January 302 1999 304 Authors' Addresses 306 Ken Hornstein 307 US Naval Research Laboratory 308 Bldg A-49, Room 2 309 4555 Overlook Avenue 310 Washington DC 20375 USA 312 Phone: +1 (202) 404-4765 313 EMail: kenh@cmf.nrl.navy.mil 315 Jeffrey Altman 316 The Kermit Project 317 Columbia University 318 612 West 115th Street #716 319 New York NY 10025-7799 USA 321 Phone: +1 (212) 854-1344 322 EMail: jaltman@columbia.edu