idnits 2.17.1 draft-ietf-kitten-gssapi-domain-based-names-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 310. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 12, 2006) is 6436 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2831 (Obsoleted by RFC 6331) == Outdated reference: A later version (-08) exists of draft-ietf-sasl-gssapi-06 -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Informational September 12, 2006 5 Expires: March 16, 2007 7 GSS-API Domain-Based Service Names and Name Type 8 draft-ietf-kitten-gssapi-domain-based-names-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 16, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes domainname-based service principal names and 42 the corresponding name type for the Generic Security Service 43 Application Programming Interface (GSS-API). 45 Domain-based service names are similar to host-based service names, 46 but using a domain name (not necessarily an Internet domain name) in 47 addition to a hostname. The primary purpose of domain-based names is 48 to provide a measure of protection to applications that utilize 49 insecure service discovery protocols. This is achieved by providing 50 a way to name clustered services after the "domain" which they 51 service, thereby allowing their clients to authorize the service's 52 servers based on authentication of their service names. 54 Table of Contents 56 1. Conventions used in this document . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 5 59 4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . 6 60 4.1. Examples of domain-based names . . . . . . . . . . . . . . . 6 61 5. Application protocol examples . . . . . . . . . . . . . . . 7 62 5.1. NFSv4 domain-wide namespace root server discovery . . . . . 7 63 5.2. LDAP server discovery . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 67 7.2. Informative References . . . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 69 Intellectual Property and Copyright Statements . . . . . . . 11 71 1. Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 Some applications need to discover the names of servers for a 80 specific resource. Some common methods for server discovery are 81 insecure, e.g., queries for DNS [RFC1035] SRV resource records 82 [RFC2782] without using DNSSEC [RFC4033] and subject to attacks 83 whereby a client can be re-directed to incorrect and possibly 84 malicious servers. A client may even be re-directed to a server that 85 has credentials for itself and may thus authenticate itself to the 86 client, and yet it could be incorrect or malicious (because it has 87 been compromised, say). 89 Domain-based names allow for GSS-API [RFC2743] initiator applications 90 (clients) to authorize acceptor principals (servers) to serve the 91 resource for which the client used insecure server discovery without 92 either securing the server discovery method nor requiring an 93 additional protocol for server authorization -- either a discovered 94 server has credentials for authenticating the domain-based service 95 names that it is intended to respond to, or it does not. 96 Availability of valid credentials for authenticating domain-based 97 names embodies the authorization of a given server to a domain-wide 98 service. 100 A domain-based name consists of three required elements: 102 o a service name 104 o a domain name 106 o a hostname 108 For the purposes of domain-based names a "domain" is defined by the 109 applications that use domain-based names. An application protocol 110 might use a simple DNS domainname, such as "example.com" for naming, 111 while another it might use the DNS domainname of the SRV RRs it 112 queries (e.g., "_tcp._foo.example.com"), and yet another may use 113 something that does not resemble a DNS domainname. Application 114 protocol specifications that provide for use of domain-based service 115 names MUST define the domain-portion of their domain-based names. 117 Note that domain-based naming isn't new. According to a report to 118 the KITTEN WG mailing list there exists at least one implementation 119 of LDAP which uses domain-based service naming, and the DIGEST-MD5 120 HTTP/SASL mechanism [RFC2831] describes a similar notion (see section 121 2.1.2, description of the "serv-name" field of the digest-response). 123 3. Name Type OID and Symbolic Name 125 The new name type has an OID of 127 [NOTE: OID assignment to be made with IANA.] 129 {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss- 130 domain-based(5)} 132 The recommended symbolic name for this GSS-API name type is 133 "GSS_C_NT_DOMAINBASED_SERVICE". 135 4. Query and Display Syntaxes 137 There is a single name syntax for domain-based names. 139 The syntax is: 141 domain-based-name := 143 '@' '@' 145 Note that for Internet domain names the trailing '.' MUST NOT be 146 included in the hostname part of the display form GSS-API domain- 147 based MNs; hostnames MUST NOT contain '@'. 149 4.1. Examples of domain-based names 151 These examples are not normative: 153 o ldap@example.tld@ds1.example.tld 155 o nfs@example.tld@nfsroot1.example.tld 157 5. Application protocol examples 159 The following examples are not normative. They describe how the 160 author envisions two applications' use of domain-based names. 162 5.1. NFSv4 domain-wide namespace root server discovery 164 Work is ongoing to provide a method for constructing domain-wide 165 NFSv4 [RFC3530] filesystem namespaces where there is a single "root" 166 with one or more servers (replicas) and multiple filesystems glued 167 into the namespace through use of "referrals." Clients could then 168 construct a "global" namespace through use of the DNS domain 169 hierarchy. 171 Here clients would always know, from context, when they need to find 172 the root servers for a given DNS domain. Root server discovery would 173 be performed using DNS SRV RR lookups, without using DNSSEC where 174 DNSSEC has not been deployed. 176 When using RPCSEC_GSS [RFC2203] for security NFSv4 clients would then 177 use domain-based names to ensure that that the servers named in the 178 SRV RRs are in fact authorized to be the NFSv4 root servers for the 179 target domain. 181 5.2. LDAP server discovery 183 LDAP clients using the GSS-API through SASL too would benefit from 184 use of domain-based names to protect server discovery through 185 insecure DNS SRV RR lookups, much as described above. 187 Unlike NFSv4 clients, not all LDAP clients may always know from 188 context when they should use domain-based names. That's because 189 existing clients may use host-based naming to authenticate servers 190 discovered through SRV RR lookups. Changing such clients to use 191 domain-based naming when domain-based acceptor credentials have not 192 been deployed to LDAP servers, or when LDAP servers have not been 193 modified to allow use of domain-based naming, would break 194 interoperability. That is, there is a legacy server interoperability 195 issue here. Therefore LDAP clients may require additional 196 configuration at deployment time to enable (or disable) use of 197 domain-based naming. 199 Note: whether SASL [RFC4422] or its GSS-API bridges 200 [I-D.ietf-sasl-gssapi] [I-D.josefsson-sasl-gs2] require updates in 201 order allow use of domain-based names is not relevant to the theory 202 of how domain-based naming would protect LDAP clients' server 203 discovery. 205 6. Security Considerations 207 Use of GSS-API domain-based names may not be negotiable by some GSS- 208 API mechanisms, and some acceptors may not support GSS-API domain- 209 based names. In such cases initiators are left to fallback on the 210 use of hostbased names, in which case the initiators MUST also verify 211 that the acceptor's hostbased name is authorized to provide the given 212 service for the domain that the initiator had wanted. 214 The above security consideration also applies to all GSS-API 215 initiators who lack support for domain-based service names. 217 7. References 219 7.1. Normative References 221 [RFC1035] Mockapetris, P., "Domain names - implementation and 222 specification", STD 13, RFC 1035, November 1987. 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC2743] Linn, J., "Generic Security Service Application Program 228 Interface Version 2, Update 1", RFC 2743, January 2000. 230 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 231 specifying the location of services (DNS SRV)", RFC 2782, 232 February 2000. 234 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 235 SASL Mechanism", RFC 2831, May 2000. 237 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 238 Rose, "DNS Security Introduction and Requirements", 239 RFC 4033, March 2005. 241 7.2. Informative References 243 [I-D.ietf-sasl-gssapi] 244 Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism", 245 draft-ietf-sasl-gssapi-06 (work in progress), June 2006. 247 [I-D.josefsson-sasl-gs2] 248 Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 249 Mechanism Family", draft-josefsson-sasl-gs2-00 (work in 250 progress), November 2005. 252 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 253 Specification", RFC 2203, September 1997. 255 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 256 Beame, C., Eisler, M., and D. Noveck, "Network File System 257 (NFS) version 4 Protocol", RFC 3530, April 2003. 259 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 260 Security Layer (SASL)", RFC 4422, June 2006. 262 Author's Address 264 Nicolas Williams 265 Sun Microsystems 266 5300 Riata Trace Ct 267 Austin, TX 78727 268 US 270 Email: Nicolas.Williams@sun.com 272 Full Copyright Statement 274 Copyright (C) The Internet Society (2006). 276 This document is subject to the rights, licenses and restrictions 277 contained in BCP 78, and except as set forth therein, the authors 278 retain all their rights. 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Intellectual Property 290 The IETF takes no position regarding the validity or scope of any 291 Intellectual Property Rights or other rights that might be claimed to 292 pertain to the implementation or use of the technology described in 293 this document or the extent to which any license under such rights 294 might or might not be available; nor does it represent that it has 295 made any independent effort to identify any such rights. Information 296 on the procedures with respect to rights in RFC documents can be 297 found in BCP 78 and BCP 79. 299 Copies of IPR disclosures made to the IETF Secretariat and any 300 assurances of licenses to be made available, or the result of an 301 attempt made to obtain a general license or permission for the use of 302 such proprietary rights by implementers or users of this 303 specification can be obtained from the IETF on-line IPR repository at 304 http://www.ietf.org/ipr. 306 The IETF invites any interested party to bring to its attention any 307 copyrights, patents or patent applications, or other proprietary 308 rights that may cover technology that may be required to implement 309 this standard. Please address the information to the IETF at 310 ietf-ipr@ietf.org. 312 Acknowledgment 314 Funding for the RFC Editor function is provided by the IETF 315 Administrative Support Activity (IASA).