From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5178.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc5178.txt (limited to 'doc/rfc/rfc5178.txt') 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 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] + -- cgit v1.2.3