Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type
RFC 5178
|
| Document |
Type |
|
RFC - Proposed Standard
(May 2008; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5178 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Sam Hartman
|
|
IESG note |
|
Proto Shepherd: Shawn.Emery@Sun.COM
|
|
Send notices to |
|
(None)
|
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
Show full document text