Skip to main content

Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type
draft-ietf-kitten-gssapi-domain-based-names-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    kitten mailing list <kitten@ietf.org>, 
    kitten chair <kitten-chairs@tools.ietf.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

Ballot Text

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.

RFC Editor Note