Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming
RFC 4768

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                         S. Hartman
Request for Comments: 4768                                           MIT
Category: Informational                                    December 2006

                        Desired Enhancements to
   Generic Security Services Application Program Interface (GSS-API)
                            Version 3 Naming

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   The Generic Security Services API (GSS-API) provides a naming
   architecture that supports name-based authorization.  GSS-API
   authenticates two named parties to each other.  Names can be stored
   on access control lists (ACLs) to make authorization decisions.
   Advances in security mechanisms and the way implementers wish to use
   GSS-API require this model to be extended for the next version of
   GSS-API.  As people move within an organization or change their
   names, the name authenticated by GSS-API may change.  Using some sort
   of constant identifier would make ACLs more stable.  Some mechanisms,
   such as public-key mechanisms, do not have a single name to be used
   across all environments.  Other mechanisms, such as Kerberos, may
   include group membership or role information as part of
   authentication.  This document motivates extensions to GSS-API naming
   and describes the extensions under discussion.

Hartman                      Informational                      [Page 1]
RFC 4768                       GSS Names                   December 2006

Table of Contents

   1. Introduction ....................................................2
   2. Kerberos Naming .................................................3
   3. X.509 Names .....................................................4
   4. Composite Names .................................................5
      4.1. Usage of Name Attributes ...................................6
      4.2. Open Issues ................................................6
      4.3. Handling gss_export_name ...................................7
   5. Credential Extensions ...........................................7
   6. Mechanisms for Export Name ......................................8
   7. Selection of Source Identity ....................................8
   8. Compatibility with GSS-API V2 ...................................9
   9. Security Considerations .........................................9
   10. Acknowledgements ..............................................10
   11. Informative References ........................................10

1.  Introduction

   The Generic Security Services API [2] authenticates two named parties
   to each other.  GSS names can be imported in a variety of formats
   through the gss_import_name call.  Several mechanism-independent name
   formats are provided, including GSS_C_NT_HOSTBASED_SERVICE for
   services running on an Internet host, and GSS_C_NT_USER_NAME for the
   names of users.  Other mechanism-specific name types are also
   provided.  By the time a name is used in acquiring a mechanism-
   specific credential or establishing a security context, it has been
   transformed into one of these mechanism-specific name types.  In
   addition, the GSS-API provides a function called gss_export_name that
   will transform a GSS-API name into a binary blob suitable for
   comparisons.  This binary blob can be stored on ACLs and then
   authorization decisions can be made simply by comparing the name
   exported from a newly accepted context to the name on the ACL.

   Storing names on ACLs can be problematic because names tend to change
   over time.  If the name contains organizational information, such as
   a domain part or an indication of what department someone works for,
   this changes as the person moves around the organization.  Even if no
   organizational information is included in the name, the name will
   change as people change their names.  Updating ACLs to reflect name
   changes is difficult.  Another significant problem is that names can
   be reused to apply to an entity other than the entity to which they
   originally applied.  For example, if a Unix user ID is placed on an
   ACL, the account deleted and then a new user assigned the old ID,
   then that new user may gain privileges intended for the old user.

Hartman                      Informational                      [Page 2]
RFC 4768                       GSS Names                   December 2006

   Inherent in the GSS naming model is the idea that mechanism names
   need to be able to be represented in a single canonical form.  Anyone
   importing that name needs to be able to retrieve the canonical form
   of that name.

   Several security mechanisms have been proposed for which this naming