Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, kitten mailing list <email@example.com>, kitten chair <firstname.lastname@example.org> Subject: Protocol Action: 'Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type' to Proposed Standard The IESG has approved the following documents: - 'Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type ' <draft-ietf-kitten-gssapi-domain-based-names-07.txt> as a Proposed Standard - 'Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism ' <draft-ietf-kitten-krb5-gssapi-domain-based-names-06.txt> as a Proposed Standard These documents are products of the Kitten (GSS-API Next Generation) Working Group. The IESG contact persons are Sam Hartman and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-07.txt
Technical Summary This documentset describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API) and the GSS-API Kerberos 5 mechanism. 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. Working Group Summary The Kitten Working Group has achieved consensus that this document should be published as a Proposed Standard. Two weeks of discussion of the document and how applications would need to be modified to make use if its specification were extended by an additional week in order to reach consensus on additional examples. Protocol Quality This document has been reviewed by Sam Hartman for the IESG. Note to RFC Editor Please modify draft-ietf-kitten-gssapi-domain-based-names as follows: (1) Insert a new section 3.1 Name Type OID and renumber the current section 3.1 as 3.2. (2) Insert the following text as the body of the new section 3.1 The IANA should record the following new name-type OID in the IANA's "SMI Security for Name System Designators Codes (nametypes)" registry: 5 gss-domain-based-services [RFCxxxx] (3) In section 3.2, delete the following text: allocated manually with RFC2743 as the authoritative "registry" -- there is no IANA registry for GSS-API name types at this time. Therefore there are no IANA considerations in this document. (4) Please append a new closing paragraph at the end of Section 7 Security Considerations: 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." (5) Note: this RFC Editor note does not modify draft-ietf-kitten-krb5-gssapi-domain-based-names.