idnits 2.17.1 draft-mccallum-kitten-krb-service-discovery-02.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 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 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 (May 16, 2016) is 2901 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' ** Downref: Normative reference to an Informational RFC: RFC 3244 ** Downref: Normative reference to an Informational RFC: RFC 7553 Summary: 5 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 Red Hat, Inc. 4 Updates: 4120 (if approved) May 16, 2016 5 Intended status: Standards Track 6 Expires: November 17, 2016 8 Kerberos Service Discovery using DNS 9 draft-mccallum-kitten-krb-service-discovery-02 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 November 17, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 2 58 3. Realm to Domain Translation . . . . . . . . . . . . . . . . . 2 59 4. Required URI Formats . . . . . . . . . . . . . . . . . . . . 3 60 5. Optional URI Formats . . . . . . . . . . . . . . . . . . . . 3 61 5.1. MS-KKDCP . . . . . . . . . . . . . . . . . . . . . . . . 3 62 6. Kerberos V5 KDC Service Discovery . . . . . . . . . . . . . . 3 63 7. Kerberos Password Service Discovery . . . . . . . . . . . . . 3 64 8. Relationship to Existing Mechanism . . . . . . . . . . . . . 4 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 Section 7.2.3 of Kerberos V5 [RFC4120] defines a procedure for 71 discovering a KDC based on DNS SRV records. This method has three 72 drawbacks. First, two DNS queries are required to locate a single 73 service (one for UDP and one for TCP). Second, specifying UDP and 74 TCP in separate records means that the DNS administrator has no 75 control over client preferences for TCP or UDP. Third, any new 76 transports for reaching the KDC (such as MS-KKDCP) will require new 77 records and additional DNS queries. 79 The Kerberos Password [RFC3244] protocol has no defined procedure for 80 discovery similar to the KDC method described above. Implementations 81 have largely chosen a similar method to section 7.2.3 of Kerberos V5 82 [RFC4120], inheriting the same drawbacks outlined above. 84 This RFC defines two new URI DNS records [RFC7553]; one each for KDC 85 and Kerberos Password service discovery. 87 2. Document Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 3. Realm to Domain Translation 94 This document does not define a new mechanism for translating 95 Kerberos realms to DNS domains. The existing mechanism as defined in 96 section 7.2.3.1 of Kerberos V5 [RFC4120] MUST be followed. 98 4. Required URI Formats 100 The following URI formats MUST be supported by clients. These 101 formats indicate support for the standard UDP and TCP transports. 102 The port number is optional. If the port is not specified, the 103 client MUST default to the standard port of the service (Kerberos V5 104 or Kerberos Password). 106 udp://host[:port] 108 tcp://host[:port] 110 5. Optional URI Formats 112 The following URI formats MAY be supported by clients. 114 5.1. MS-KKDCP 116 These URIs indicate support for the MS-KKDCP [MS-KKDCP] protocol. 117 The port number is optional. If the port is not specified, the 118 client MUST default to the standard port of the transport (HTTP or 119 HTTPS). The path is also optional. 121 http://host[:port][path] 123 https://host[:port][path] 125 6. Kerberos V5 KDC Service Discovery 127 In order to discover a KDC service location, the client MUST query 128 the following URI DNS [RFC7553] record (REALM indicates the 129 translation of the Kerberos realm to a DNS domain): 131 _kerberos.REALM 133 TTL, Class, URI, Priority, Weight and Target have the standard 134 meanings as defined in RFC 2782 [RFC2782] and the URI DNS record type 135 [RFC7553]. Target SHOULD contain one of the URI formats specified in 136 this document. 138 7. Kerberos Password Service Discovery 139 In order to discover a password service location, the client MUST 140 query the following URI DNS [RFC7553] record (REALM indicates the 141 translation of the Kerberos realm to a DNS domain): 143 _kpasswd.REALM 145 TTL, Class, URI, Priority, Weight and Target have the standard 146 meanings as defined in RFC 2782 [RFC2782] and the URI DNS record type 147 [RFC7553]. Target SHOULD contain one of the URI formats specified in 148 this document. 150 8. Relationship to Existing Mechanism 152 If an existing discovery protocol is supported by a client, the 153 client SHOULD perform the URI lookup as defined in this document 154 first. If no URI record is found, the client MAY attempt discovery 155 using another protocol. 157 9. Normative References 159 [MS-KKDCP] 160 Microsoft, "[MS-KKDCP]: Kerberos Key Distribution Center 161 (KDC) Proxy Protocol", May 2014, 162 . 164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 165 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 166 RFC2119, March 1997, 167 . 169 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 170 specifying the location of services (DNS SRV)", RFC 2782, 171 DOI 10.17487/RFC2782, February 2000, 172 . 174 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 175 2000 Kerberos Change Password and Set Password Protocols", 176 RFC 3244, DOI 10.17487/RFC3244, February 2002, 177 . 179 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 180 Kerberos Network Authentication Service (V5)", RFC 4120, 181 DOI 10.17487/RFC4120, July 2005, 182 . 184 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 185 Identifier (URI) DNS Resource Record", RFC 7553, DOI 186 10.17487/RFC7553, June 2015, 187 . 189 Appendix A. Acknowledgements 191 Simo Sorce (Red Hat) 192 Nico Williams (Cryptonector) 194 Author's Address 196 Nathaniel McCallum 197 Red Hat, Inc. 198 100 East Davie Street 199 Raleigh, NC 27601 200 USA 202 EMail: npmccallum@redhat.com