summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5178.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5178.txt')
-rw-r--r--doc/rfc/rfc5178.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5178.txt b/doc/rfc/rfc5178.txt
new file mode 100644
index 0000000..ae43afc
--- /dev/null
+++ b/doc/rfc/rfc5178.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group N. Williams
+Request for Comments: 5178 Sun
+Category: Standards Track A. Melnikov
+ Isode Ltd.
+ May 2008
+
+
+ Generic Security Service Application Program Interface (GSS-API)
+ Internationalization and Domain-Based Service Names and Name Type
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document describes domain-name-based service principal names and
+ the corresponding name type for the Generic Security Service
+ Application Programming Interface (GSS-API). Internationalization of
+ the GSS-API is also covered.
+
+ Domain-based service names are similar to host-based service names,
+ but using a domain name (not necessarily an Internet domain name) in
+ addition to a hostname. The primary purpose of domain-based names is
+ to provide a measure of protection to applications that utilize
+ insecure service discovery protocols. This is achieved by providing
+ a way to name clustered services after the "domain" which they
+ service, thereby allowing their clients to authorize the service's
+ servers based on authentication of their service names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 1]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . . 4
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Name Type OID . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.2. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 4
+ 4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . 4
+ 4.1. Examples of Domain-Based Names . . . . . . . . . . . . . . 5
+ 5. Internationalization (I18N) Considerations . . . . . . . . . . 5
+ 5.1. Importing Internationalized Names . . . . . . . . . . . . . 5
+ 5.2. Displaying Internationalized Names . . . . . . . . . . . . 5
+ 6. Application Protocol Examples . . . . . . . . . . . . . . . . . 6
+ 6.1. NFSv4 Domain-Wide Namespace Root Server Discovery . . . . . 6
+ 6.2. LDAP Server Discovery . . . . . . . . . . . . . . . . . . . 6
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 2]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+1. Introduction
+
+ Some applications need to discover the names of servers for a
+ specific resource. Some common methods for server discovery are
+ insecure, e.g., queries for DNS [RFC1035] SRV resource records
+ [RFC2782] without using DNSSEC [RFC4033], and are subject to attacks
+ whereby a client can be re-directed to incorrect and possibly
+ malicious servers. A client may even be re-directed to a server that
+ has credentials for itself and thus may authenticate itself to the
+ client, and yet it could be incorrect or malicious (because it has
+ been compromised, say).
+
+ Domain-based names allow for GSS-API [RFC2743] initiator applications
+ (clients) to authorize acceptor principals (servers) to serve the
+ resource for which the client used insecure server discovery without
+ either securing the server discovery method or requiring an
+ additional protocol for server authorization. That is, either a
+ discovered server has credentials for authenticating the domain-based
+ service names that it is intended to respond to, or it does not.
+ Availability of valid credentials for authenticating domain-based
+ names embodies the authorization of a given server to a domain-wide
+ service.
+
+ A domain-based name consists of three required elements:
+
+ o a service name
+
+ o a domain name
+
+ o a hostname
+
+ The domain name and the hostname should be Domain Name System (DNS)
+ names, though domain-based names could be used in non-DNS
+ environments. Because of the use of DNS names we must also provide
+ for internationalization of the GSS-API.
+
+ Note that domain-based naming isn't new. According to a report to
+ the KITTEN WG mailing list, there exists at least one implementation
+ of LDAP which uses domain-based service naming, and the DIGEST-MD5
+ HTTP / Simple Authentication and Security Layer (SASL) mechanism
+ [RFC2831] describes a similar notion. (See section 2.1.2 of
+ [RFC2831] for a description of the "serv-name" field of the digest-
+ response.)
+
+
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 3]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. IANA Considerations
+
+3.1. Name Type OID
+
+ The IANA has recorded the following new name-type OID in IANA's "SMI
+ Security for Name System Designators Codes (nametypes)" registry:
+
+ 5 gss-domain-based-services [RFC5178]
+
+3.2. Name Type OID and Symbolic Name
+
+ This document creates a new GSS-API name-type, with a symbolic name
+ of "GSS_C_NT_DOMAINBASED_SERVICE" and this OID:
+
+ {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
+ domain-based(5)}
+
+
+4. Query and Display Syntaxes
+
+ There is a single name syntax for domain-based names. It is
+ expressed using the ABNF [RFC5234].
+
+ The syntax is:
+
+ domain-based-name = service "@" domain "@" hostname
+
+ hostname = domain
+
+ domain = sub-domain 1*("." sub-domain)
+
+ sub-domain = Let-dig [Ldh-str]
+
+ Let-dig = ALPHA / DIGIT
+
+ Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
+
+ Where <service> is defined in Section 4.1 of [RFC2743]. Other rules
+ not defined above are defined in Appendix B.1 of [RFC5234].
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 4]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+4.1. Examples of Domain-Based Names
+
+ These examples are not normative:
+
+ o ldap@somecompany.example@ds1.somecompany.example
+
+ o nfs@somecompany.example@nfsroot1.somecompany.example
+
+ The .example top-level domain is used here in accordance with
+ [RFC2606].
+
+5. Internationalization (I18N) Considerations
+
+ We introduce new versions of GSS_Import_name() and GSS_Display_name()
+ to better support Unicode. Additionally, we provide for the use of
+ ASCII Compatible Encoding (ACE)-encoded DNS in the non-
+ internationalized interfaces [RFC3490].
+
+5.1. Importing Internationalized Names
+
+ When the input_name_type parameter is the
+ GSS_C_NT_DOMAINBASED_SERVICE OID, then GSS_Import_name()
+ implementations and GSS-API mechanisms MUST accept ACE-encoded
+ internationalized domain names in the hostname and domain name slots
+ of the given domain-based name string.
+
+ Support for non-ASCII internationalized domain names SHOULD also be
+ provided through a new function, GSS_Import_name_utf8(), that
+ operates exactly like GSS_Import_name() (with the same input and
+ output parameters and behavior), except that it MUST accept
+ internationalized domain names both as UTF-8 strings and as ACE-
+ encoded strings via its input_name_string argument.
+
+5.2. Displaying Internationalized Names
+
+ Implementations of GSS_Display_name() MUST only output US-ASCII or
+ ACE-encoded internationalized domain names in the hostname and domain
+ name slots of domain-based names (or mechanism names (MN) that
+ conform to the mechanism's form for domain-based names).
+
+ Support for non-ASCII internationalized domain names SHOULD also be
+ provided through a new function, GSS_Display_name_utf8(), that
+ operates exactly like GSS_Display_name() (with the same input and
+ output parameters and behavior), except that it outputs UTF-8 strings
+ via its name_string output argument. GSS_Display_name_utf8() MUST
+ NOT output ACE-encoded internationalized domain names.
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 5]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+6. Application Protocol Examples
+
+ The following examples are not normative. They describe how the
+ authors envision two applications' use of domain-based names.
+
+6.1. NFSv4 Domain-Wide Namespace Root Server Discovery
+
+ Work is ongoing to provide a method for constructing domain-wide
+ NFSv4 [RFC3530] filesystem namespaces where there is a single "root"
+ with one or more servers (replicas) and multiple filesystems glued
+ into the namespace through use of "referrals". Clients could then
+ construct a "global" namespace through use of the DNS domain
+ hierarchy.
+
+ Here, clients would always know, from context, when they need to find
+ the root servers for a given DNS domain. Root server discovery would
+ be performed using DNS SRV RR lookups, without using DNSSEC where
+ DNSSEC has not been deployed.
+
+ When using RPCSEC_GSS [RFC2203] for security, NFSv4 clients would use
+ domain-based names to ensure that the servers named in the SRV RRs
+ are in fact authorized to be the NFSv4 root servers for the target
+ domain.
+
+6.2. LDAP Server Discovery
+
+ LDAP clients using the GSS-API through SASL would also benefit from
+ use of domain-based names to protect server discovery through
+ insecure DNS SRV RR lookups, much as described above.
+
+ Unlike NFSv4 clients, not all LDAP clients always know from context
+ when they should use domain-based names. That's because existing
+ clients may use host-based naming to authenticate servers discovered
+ through SRV RR lookups. Changing such clients to use domain-based
+ naming when domain-based acceptor credentials have not been deployed
+ to LDAP servers, or when LDAP servers have not been modified to allow
+ use of domain-based naming, would break interoperability. That is,
+ there is a legacy server interoperability issue here. Therefore,
+ LDAP clients may require additional configuration at deployment time
+ to enable (or disable) use of domain-based naming.
+
+ Note: whether SASL [RFC4422] or its GSS-API bridges [RFC4752] [GS2]
+ require updates in order allow use of domain-based names is not
+ relevant to the theory of how domain-based naming would protect LDAP
+ clients' server discovery.
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 6]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+7. Security Considerations
+
+ Use of GSS-API domain-based names may not be negotiable by some GSS-
+ API mechanisms, and some acceptors may not support GSS-API domain-
+ based names. In such cases, the initiators are left to fall back on
+ the use of host-based names, so the initiators MUST also verify that
+ the acceptor's host-based name is authorized to provide the given
+ service for the domain that the initiator had wanted.
+
+ The above security consideration also applies to all GSS-API
+ initiators who lack support for domain-based service names.
+
+ Note that, as with all service names, the mere existence of a domain-
+ based service name conveys meaningful information that may be used by
+ initiators for making authorization decisions; therefore,
+ administrators of distributed authentication services should be aware
+ of the significance of the service names for which they create
+ acceptor credentials.
+
+8. References
+
+8.1. Normative References
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2743] Linn, J., "Generic Security Service Application Program
+ Interface Version 2, Update 1", RFC 2743, January 2000.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
+ SASL Mechanism", RFC 2831, May 2000.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)",
+ RFC 3490, March 2003.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 7]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+8.2. Informative References
+
+ [GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2
+ Mechanism Family", Work in Progress, October 2007.
+
+ [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
+ Specification", RFC 2203, September 1997.
+
+ [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+ Names", BCP 32, RFC 2606, June 1999.
+
+ [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
+ Beame, C., Eisler, M., and D. Noveck, "Network File System
+ (NFS) version 4 Protocol", RFC 3530, April 2003.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
+ Security Layer (SASL)", RFC 4422, June 2006.
+
+ [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
+ Authentication and Security Layer (SASL) Mechanism",
+ RFC 4752, November 2006.
+
+Authors' Addresses
+
+ Nicolas Williams
+ Sun Microsystems
+ 5300 Riata Trace Ct.
+ Austin, TX 78727
+ US
+
+ EMail: Nicolas.Williams@sun.com
+
+
+ Alexey Melnikov
+ Isode Ltd.
+ 5 Castle Business Village,
+ 36 Station Road
+ Hampton, Middlesex TW12 2BX
+ United Kingdom
+
+ EMail: Alexey.Melnikov@isode.com
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 8]
+
+RFC 5178 GSS Domain-Based Names May 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Melnikov Standards Track [Page 9]
+