idnits 2.17.1 draft-ietf-kitten-krb-service-discovery-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 Security Considerations section. ** The abstract seems to contain references ([RFC4120]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to directly say this. It does mention RFC4120 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4120, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2017) is 2604 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MS-KKDCP' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 3244 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 7553 Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. McCallum 3 Internet-Draft M. Rogers 4 Updates: 4120 (if approved) Red Hat, Inc. 5 Intended status: Standards Track February 9, 2017 6 Expires: August 13, 2017 8 Kerberos Service Discovery using DNS 9 draft-ietf-kitten-krb-service-discovery-00 11 Abstract 13 This document proposes defines a new mechanism for discovering 14 Kerberos services using DNS. This new mechanism extends the 15 mechanism already defined in Kerberos V5 [RFC4120] and has four 16 goals. First, reduce the number of DNS queries required to discover 17 a Kerberos KDC. Second, provide DNS administrators more control over 18 client behavior. Third, provide support for discovery of the MS- 19 KKDCP transport. Fourth, define a discovery procedure for Kerberos 20 password services. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 13, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 58 3. Realm to Domain Translation . . . . . . . . . . . . . . . . . 3 59 4. Required URI Format . . . . . . . . . . . . . . . . . . . . . 3 60 4.1. Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4.2.1. Master Flag . . . . . . . . . . . . . . . . . . . . . 4 63 4.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.4. Residual . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Kerberos V5 KDC Service Discovery . . . . . . . . . . . . . . 4 66 6. Kerberos Password Service Discovery . . . . . . . . . . . . . 4 67 7. Kerberos Admin Service Discovery . . . . . . . . . . . . . . 5 68 8. Relationship to Existing Mechanism . . . . . . . . . . . . . 5 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 9.1. Kerberos Server Discovery Flags . . . . . . . . . . . . . 5 71 9.1.1. Registration Template . . . . . . . . . . . . . . . . 5 72 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 6 73 9.2. Kerberos Server Discovery Transport Types . . . . . . . . 6 74 9.2.1. Registration Template . . . . . . . . . . . . . . . . 6 75 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 6 76 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 10.1. URI Format Examples . . . . . . . . . . . . . . . . . . 7 78 11. Normative References . . . . . . . . . . . . . . . . . . . . 7 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Section 7.2.3 of Kerberos V5 [RFC4120] defines a procedure for 85 discovering a KDC based on DNS SRV records. This method has three 86 drawbacks. First, two DNS queries are required to locate a single 87 service (one for UDP and one for TCP). Second, specifying UDP and 88 TCP in separate records means that the DNS administrator has no 89 control over client preferences for TCP or UDP. Third, any new 90 transports for reaching the KDC (such as MS-KKDCP) will require new 91 records and additional DNS queries. 93 The Kerberos Password [RFC3244] protocol has no defined procedure for 94 discovery similar to the KDC method described above. Implementations 95 have largely chosen a similar method to section 7.2.3 of Kerberos V5 96 [RFC4120], inheriting the same drawbacks outlined above. 98 This RFC defines three new URI DNS records [RFC7553]; one each for 99 KDC, Kerberos Password, and Kerberos Admin service discovery. 101 2. Document Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 3. Realm to Domain Translation 109 This document does not define a new mechanism for translating 110 Kerberos realms to DNS domains. The existing mechanism as defined in 111 section 7.2.3.1 of Kerberos V5 [RFC4120] MUST be followed. 113 4. Required URI Format 115 The following URI format MUST be supported by clients. 117 The URI format is comprised of text fields delimited by a colon (":") 118 character. 120 krb5srv:[flags]:transport:residual 122 See the Appendix for examples. 124 4.1. Scheme 126 This field identifies the URI scheme. Its value MUST be the string 127 "krb5srv". 129 4.2. Flags 131 This field contains a sequence of zero or more case-insensitive 132 characters used individually to convey server attributes or feature 133 support (eg. "XYZ" indicates support for features X, Y, and Z.) for 134 the purpose of organizing the lookup results. 136 This field MUST be present even when no flags are provided, appearing 137 as two colons seperating the scheme and transport fields (eg. 138 "krb5srv::tcp:host"). 140 Flags are not considered critical, therefore flags that are not used 141 or unknown to the implementation SHOULD be ignored. 143 4.2.1. Master Flag 145 The "m" flag signifies that the discovered server is a master server. 146 The client SHOULD consider this server as one that would immediately 147 see password changes and use it as a fallback for incorrect password 148 errors. 150 4.3. Transport 152 This field contains a string to indicate the transport method to use 153 when contacting the host specified in the URI. 155 4.4. Residual 157 This field contains information specific to the transport. It may 158 contain sub-fields where such are defined in the transport 159 specification. 161 5. Kerberos V5 KDC Service Discovery 163 In order to discover a KDC service location, the client MUST query 164 the following URI DNS [RFC7553] record (REALM indicates the 165 translation of the Kerberos realm to a DNS domain): 167 _kerberos.REALM 169 TTL, Class, URI, Priority, Weight and Target have the standard 170 meanings as defined in RFC 2782 [RFC2782] and the URI DNS record type 171 [RFC7553]. Target SHOULD contain one of the URI formats specified in 172 this document. 174 6. Kerberos Password Service Discovery 176 In order to discover a password service location, the client MUST 177 query the following URI DNS [RFC7553] record (REALM indicates the 178 translation of the Kerberos realm to a DNS domain): 180 _kpasswd.REALM 182 TTL, Class, URI, Priority, Weight and Target have the standard 183 meanings as defined in RFC 2782 [RFC2782] and the URI DNS record type 184 [RFC7553]. Target SHOULD contain one of the URI formats specified in 185 this document. 187 7. Kerberos Admin Service Discovery 189 In order to discover an admin service location, the client MUST query 190 the following URI DNS [RFC7553] record (REALM indicates the 191 translation of the Kerberos realm to a DNS domain): 193 _kerberos-adm.REALM 195 TTL, Class, URI, Priority, Weight and Target have the standard 196 meanings as defined in RFC 2782 [RFC2782] and the URI DNS record type 197 [RFC7553]. Target SHOULD contain one of the URI formats specified in 198 this document. 200 8. Relationship to Existing Mechanism 202 If an existing discovery protocol is supported by a client, the 203 client SHOULD perform the URI lookup as defined in this document 204 first. If no URI record is found, the client MAY attempt discovery 205 using another protocol. 207 9. IANA Considerations 209 This document establishes two registries with the following 210 procedure, in accordance with [RFC5226]: 212 Registry entries are to be evaluated using the Specification Required 213 method. All specifications must be be published prior to entry 214 inclusion in the registry. There will be a three-week review period 215 by Designated Experts on the kitten@ietf.org mailing list. Prior to 216 the end of the review, the Designated Experts must approve or deny 217 the request. This decision is to be conveyed to both the IANA and 218 the list, and should include reasonably detailed explanation in the 219 case of a denial as well as whether the request can be resubmitted. 221 9.1. Kerberos Server Discovery Flags 223 This section species the IANA "Kerberos Server Discovery Flags" 224 registry. This registry records the value and description for each 225 flag. 227 9.1.1. Registration Template 229 Value: A single unique ASCII character that identifies the entry, 230 excluding the colon character (":") since it is used as a field 231 delimiter in the scheme outlined in this document. 233 Description: A brief description of the meaning of the value when it 234 appears in the flags field. 236 Reference: A reference to the details of the flag. 238 9.1.2. Initial Registry Contents 240 o Value: m 241 o Description: The target is a master server. 242 o Reference: TBD 244 9.2. Kerberos Server Discovery Transport Types 246 This section specifies the IANA "Kerberos Server Discovery Transport 247 Types" registry. This registry records the value, description, 248 residual format, case-sensitive residual elements, default ports, and 249 a reference for each type. 251 9.2.1. Registration Template 253 Value: A unique value to identify the transport type within the 254 transport field. 256 Description: The name or description of the transport type. 258 Residual Format: The format of the residual field that specifies the 259 discovered target URL. Optional parts of the URL are enclosed in 260 brackets. 262 Case Sensitive: If any part of the residual format is case- 263 sensitive, it is specified here. 265 Default KDC Port: A number in the range of 1-65535 as the port used 266 to contact the target URL when no port is specified and the lookup 267 result is for a Kerberos server. 269 Default Admin Service Port: A number in the range of 1-65535 as the 270 port used to contact the target URL when no port is specified and 271 the lookup result is for a Kerberos Admin server. 273 Default Password Service Port: A number in the range of 1-65535 as 274 the port used to contact the target URL when no port is specified 275 and the lookup result is for a Kerberos Password server. 277 Reference: A reference to the details of the transport type. 279 9.2.2. Initial Registry Contents 280 o Value: "udp" 281 o Description: User Datagram Protocol 282 o Residual Format: "host[:port]" 283 o Case Sensitive: None 284 o Default KDC Port: 88 285 o Default Admin Service Port: 749 286 o Default Password Service Port: 464 287 o Reference: [RFC0768] 289 o Value: "tcp" 290 o Description: Transport Control Protocol 291 o Residual Format: "host[:port]" 292 o Case Sensitive: None 293 o Default KDC Port: 88 294 o Default Admin Service Port: 749 295 o Default Password Service Port: 464 296 o Reference: [RFC0793] 298 o Value: "kkdcp" 299 o Description: Kerberos Key Distribution Center Proxy Protocol 300 o Residual Format: https://host[:port][/path] 301 o Case Sensitive: [/path] 302 o Default KDC Port: 443 303 o Default Admin Service Port: 443 304 o Default Password Service Port: 443 305 o Reference: [MS-KKDCP] 307 10. Appendix 309 10.1. URI Format Examples 311 o krb5srv:m:kkdcp:https://kdc.example.com:8080/path 312 o krb5srv:m:udp:kdc.example.com 313 o krb5srv::kkdcp:https://kdc2.example.com/path 314 o krb5srv::tcp:192.168.1.20:1000 316 11. Normative References 318 [MS-KKDCP] 319 Microsoft, "[MS-KKDCP]: Kerberos Key Distribution Center 320 (KDC) Proxy Protocol", May 2014, 321 . 323 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 324 DOI 10.17487/RFC0768, August 1980, 325 . 327 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 328 RFC 793, DOI 10.17487/RFC0793, September 1981, 329 . 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 337 specifying the location of services (DNS SRV)", RFC 2782, 338 DOI 10.17487/RFC2782, February 2000, 339 . 341 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 342 2000 Kerberos Change Password and Set Password Protocols", 343 RFC 3244, DOI 10.17487/RFC3244, February 2002, 344 . 346 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 347 Kerberos Network Authentication Service (V5)", RFC 4120, 348 DOI 10.17487/RFC4120, July 2005, 349 . 351 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 352 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 353 DOI 10.17487/RFC5226, May 2008, 354 . 356 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 357 Identifier (URI) DNS Resource Record", RFC 7553, 358 DOI 10.17487/RFC7553, June 2015, 359 . 361 Appendix A. Acknowledgements 363 Simo Sorce (Red Hat) 364 Nico Williams (Cryptonector) 366 Authors' Addresses 368 Nathaniel McCallum 369 Red Hat, Inc. 370 100 East Davie Street 371 Raleigh, NC 27601 372 USA 374 EMail: npmccallum@redhat.com 376 Matt Rogers 377 Red Hat, Inc. 378 100 East Davie Street 379 Raleigh, NC 27601 380 USA 382 EMail: mrogers@redhat.com