1 NETWORK WORKING GROUP N. Williams
3 Expires: December 28, 2006 June 26, 2006
6 GSS-API Domain-Based Service Names and Name Type
7 draft-ietf-kitten-gssapi-domain-based-names-02.txt
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on December 28, 2006.
36 Copyright (C) The Internet Society (2006).
40 This document describes domainname-based service principal names and
41 the corresponding name type for the Generic Security Service
42 Application Programming Interface (GSS-API).
44 Domain-based service names are similar to host-based service names,
45 but using a domain name (not necessarily an Internet domain name)
46 instead of or in addition to a hostname. The primary purpose of
47 domain-based service names is to provide a way to name clustered
48 services after the domain which they service, thereby allowing their
52 Williams Expires December 28, 2006 [Page 1]
54 Internet-Draft GSS Domain Based Names June 2006
57 clients to authorize the service's servers based on authentication of
63 1. Conventions used in this document . . . . . . . . . . . . . 3
64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
65 3. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 5
66 4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . 6
67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
68 6. Security Considerations . . . . . . . . . . . . . . . . . . 8
69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
70 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 9
71 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . . 9
72 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
73 Intellectual Property and Copyright Statements . . . . . . . 11
108 Williams Expires December 28, 2006 [Page 2]
110 Internet-Draft GSS Domain Based Names June 2006
113 1. Conventions used in this document
115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
117 document are to be interpreted as described in [RFC2119].
164 Williams Expires December 28, 2006 [Page 3]
166 Internet-Draft GSS Domain Based Names June 2006
171 The use of hostbased principal names for domain-wide services
172 presents the problem of how to distinguish between an instance of a
173 hostbased service that is authorized to respond for a domain and one
176 Consider LDAP. LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V
177 mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased
178 principal with a service name of "ldap", a reasonable approach,
179 provided there is only one logical LDAP directory in a Kerberos
180 realm's domain, and that all ldap servers in that realm serve that
181 one LDAP directory. An network might have multiple, distinct LDAP
182 services, but only one LDAP "name service"; if so then clients could
183 not tell which LDAP service principals are authorized to serve which
184 directory, not without assuming a secure method for finding LDAP
185 servers (e.g., DNSSEC). This is a significant, and oft-unstated
186 restriction on users of LDAP.
188 Domain based names can eliminate this problem: the use of domain-
189 based names should imply that the given host is a server for the
190 official LDAP name service of the given domain.
192 Notwithstanding the LDAP example the use of domain-based principal
193 names for LDAP is not actually specified here and will be specified
194 in a separate document.
196 A domain-based name consists of three required elements:
220 Williams Expires December 28, 2006 [Page 4]
222 Internet-Draft GSS Domain Based Names June 2006
225 3. Name Type OID and Symbolic Name
227 The new name type has an OID of
229 [NOTE: OID assignment to be made with IANA.]
231 {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
234 The recommended symbolic name for this GSS-API name type is
235 "GSS_C_NT_DOMAINBASED_SERVICE".
276 Williams Expires December 28, 2006 [Page 5]
278 Internet-Draft GSS Domain Based Names June 2006
281 4. Query and Display Syntaxes
283 There is a single name syntax for domain-based names.
289 | <service> '@' <domain> '@' <hostname>
291 Note that for Internet domain names the trailing '.' is not and MUST
292 NOT be included in the domain name (or hostname) parts of the display
293 form GSS-API domain-based MNs.
332 Williams Expires December 28, 2006 [Page 6]
334 Internet-Draft GSS Domain Based Names June 2006
339 o ldap@example.tld@ds1.example.tld
341 o kadmin@example.tld@kdc1.example.tld
388 Williams Expires December 28, 2006 [Page 7]
390 Internet-Draft GSS Domain Based Names June 2006
393 6. Security Considerations
395 Use of GSS-API domain-based names may not be negotiable by some GSS-
396 API mechanisms, and some acceptors may not support GSS-API domain-
397 based names. In such cases initiators are left to fallback on the
398 use of hostbased names, in which case the initiators MUST also verify
399 that the acceptor's hostbased name is authorized to provide the given
400 service for the domain that the initiator had wanted.
402 The above security consideration also applies to all GSS-API
403 initiators who lack support for domain-based service names.
444 Williams Expires December 28, 2006 [Page 8]
446 Internet-Draft GSS Domain Based Names June 2006
453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
454 Requirement Levels", BCP 14, RFC 2119, March 1997.
456 [RFC2743] Linn, J., "Generic Security Service Application Program
457 Interface Version 2, Update 1", RFC 2743, January 2000.
461 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
464 [RFC2222] Myers, J., "Simple Authentication and Security Layer
465 (SASL)", RFC 2222, October 1997.
467 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
468 Protocol (v3): Technical Specification", RFC 3377,
500 Williams Expires December 28, 2006 [Page 9]
502 Internet-Draft GSS Domain Based Names June 2006
513 Email: Nicolas.Williams@sun.com
556 Williams Expires December 28, 2006 [Page 10]
558 Internet-Draft GSS Domain Based Names June 2006
561 Intellectual Property Statement
563 The IETF takes no position regarding the validity or scope of any
564 Intellectual Property Rights or other rights that might be claimed to
565 pertain to the implementation or use of the technology described in
566 this document or the extent to which any license under such rights
567 might or might not be available; nor does it represent that it has
568 made any independent effort to identify any such rights. Information
569 on the procedures with respect to rights in RFC documents can be
570 found in BCP 78 and BCP 79.
572 Copies of IPR disclosures made to the IETF Secretariat and any
573 assurances of licenses to be made available, or the result of an
574 attempt made to obtain a general license or permission for the use of
575 such proprietary rights by implementers or users of this
576 specification can be obtained from the IETF on-line IPR repository at
577 http://www.ietf.org/ipr.
579 The IETF invites any interested party to bring to its attention any
580 copyrights, patents or patent applications, or other proprietary
581 rights that may cover technology that may be required to implement
582 this standard. Please address the information to the IETF at
586 Disclaimer of Validity
588 This document and the information contained herein are provided on an
589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
591 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
592 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
593 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
599 Copyright (C) The Internet Society (2006). This document is subject
600 to the rights, licenses and restrictions contained in BCP 78, and
601 except as set forth therein, the authors retain all their rights.
606 Funding for the RFC Editor function is currently provided by the
612 Williams Expires December 28, 2006 [Page 11]