CVS gss/doc/specification

[gss-commit]

Update of /home/cvs/gss/doc/specification
In directory dopio:/tmp/cvs-serv5833

Added Files:
        draft-ietf-kitten-gss-naming-02.txt 
Log Message:
Add.


--- /home/cvs/gss/doc/specification/draft-ietf-kitten-gss-naming-02.txt 
2005/06/03 22:12:59     NONE
+++ /home/cvs/gss/doc/specification/draft-ietf-kitten-gss-naming-02.txt 
2005/06/03 22:12:59     1.1




Network Working Group                                         S. Hartman
Internet-Draft                                                       MIT
Expires: December 4, 2005                                   June 2, 2005


                 Desired Enhancements to GSSAPI Naming
                  draft-ietf-kitten-gss-naming-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 4, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 to make authorization decisions.  Advances in
   security mechanisms and the way implementers wish to use GSS-API
   require this model to be extended.  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



Hartman                 Expires December 4, 2005                [Page 1]

Internet-Draft                  GSS Names                      June 2005


   have a single name to be used across all environments.  Other
   mechanisms such as Kerberos include 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                 Expires December 4, 2005                [Page 2]

Internet-Draft                  GSS Names                      June 2005


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 flatten 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 another entity 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.

   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
   architecture is too restrictive.  In some cases it is not always
   possible to canonicalize any name that is imported.  In other cases
   there is no single canonical name.

   Also, as GSS-API is used in more complex environments, there is a
   desire to use attribute certificates [6], Kerberos authorization data
   [3], or other non-name-based authorization models.  GSS-API needs to
   be enhanced in order to support these uses in a mechanism-independent
   manner.

   This document discusses the particular naming problems with two
   important classes of GSS-API mechanisms.  It also discusses the set
   of proposed solutions and open issues with these solutions.  This



Hartman                 Expires December 4, 2005                [Page 3]

Internet-Draft                  GSS Names                      June 2005


   draft limits discussion to these solutions and provides a description
   of the problem against which the solutions can be judged.

















































Hartman                 Expires December 4, 2005                [Page 4]

Internet-Draft                  GSS Names                      June 2005


2.  Kerberos Naming

   The Kerberos mechanism demonstrates both the naming stability problem
   and the authorization extension problem.

   The Kerberos Referrals draft [4] proposes a new type of Kerberos name
   called an enterprise name.  The intent is that the enterprise name is
   an alias that the user knows for themselves and can use to login.
   The Kerberos KDC translates this name into a normal Kerberos
   principal and gives the user tickets for this principal.  This normal
   principal is used for authorization.  The intent is that the
   enterprise name tracks the user as they move throughout the
   organization, even if they move to parts of the organization that
   have different naming policies.  The name they type at login remains
   constant, but the Kerberos principal used to authenticate them to
   services changes.

   Performing a mapping from enterprise  name to principal name is not
   generally possible for unauthenticated services.  Even authenticated
   services may not be authorized to perform this mapping except for
   their own name.  Also, Kerberos does not (and does not plan to)
   provide a mechanism for mapping enterprise names to principals
   besides authentication as the enterprise name.  Thus, any such
   mapping would be vendor-specific.  With this feature in Kerberos, it
   is not possible to implement gss_canonicalize_name for enterprise
   name types.

   Another issue arises with enterprise names.  IN some cases it would
   be desirable to put   the enterprise name on the ACL instead of a
   principal name for greater ACL stability.  At first glance this could
   be accomplished by including the enterprise name in the name exported
   by gss_export_name.  Unfortunately, if this were done, the exported
   name would change whenever the mapping changed, invalidating any ACL
   entries based off the old exported name and defeating the purpose  of
   including the enterprise name in the exported name.  In some cases it
   would be desirable to have the exported name be based on the
   enterprise name and in others based on the principal name, but this
   is not permitted by the current GSS-API.

   Another development also complicates GSS-API naming for Kerberos.
   Several vendors have been looking at mechanisms to include group
   membership information in Kerberos authorization data.  It is
   desirable to put these group names on ACLs.  Again, GSS-API currently
   has no mechanism to use this information.







Hartman                 Expires December 4, 2005                [Page 5]

Internet-Draft                  GSS Names                      June 2005


3.  X.509 Names

   X.509 names are more complicated than Kerberos names.  In the
   Kerberos case there is a single principal carried in all Kerberos
   messages.  X.509 certificates have multiple options.  It seems  the
   subject name might be the appropriate name to use as the name to be
   exported in a GSS-API mechanism.  However RFC 3280 [5] does not even
   require the subject name to be a non-empty sequence.  Instead there
   are cases where the subjectAltName extension is the only thing to
   identify the subject of the certificate.  As in the case of Kerberos
   group memberships, there may be many subjectAltName extensions
   available in a certificate.  Different applications will care about
   different extensions.  One possible candidate for an exported name
   would be all the names and SubjectAltName extensions from a
   certificate.  However as new names are added then existing ACL
   entries would be invalidated; this is undesirable.  Thus there is no
   single value that can be  defined as the exported GSS-API name that
   will be useful in all environments.

   A profile of a particular X.509  GSS-API mechanism could require a
   specific name be used.  However this would limit that mechanism to
   require a particular type of certificate.  There is interest in being
   able to use arbitrary X.509 certificates with GSS-API for some
   applications.

   Experience so far has not lead to sufficient interoperability with
   GSS-API X.509 mechanisms.  Even if the subject name is used, there is
   ambiguity in how to handle sorting of name components.  Martin Rex
   said that he was aware of several SPKM [1] implementations but no two
   were fully interoperable on names.

   Also, as discussed in the introduction, it is desirable to support
   X.509 attribute certificates.


















Hartman                 Expires December 4, 2005                [Page 6]

Internet-Draft                  GSS Names                      June 2005


4.  Composite Names

   One proposal to solve these problems is to extend the concept of a
   GSS-API name to include a set of name attributes.  Each attribute
   would be an octet-string labeled by an OID.  Examples of attributes
   would include Kerberos enterprise names, group memberships in an
   authorization infrastructure, Kerberos authorization data attributes
   and subjectAltName attributes in a certificate.  Several new
   operations would be needed:

   1.  Add an  attribute to name.

   2.  Query attributes of name.

   3.  Query values of an attribute.

   4.  Delete an attribute from a name.

   5.  Export a complete composite name and all its attributes for
       transport between processes.

   Note that an exported composite name would not generally be suitable
   for binary comparison.  Avoiding confusion between this operation and
   the existing gss_export_name operation will require careful work.

   Additional utility operations will probably be needed depending on
   the implementation of name attributes.

4.1  Usage of Name Attributes

   Since attributes are part of GSS-API names, the acceptor can retrieve
   the attributes of the initiator's and acceptor's name from the
   context.  These attributes can then be used for authorization.

   Most name attributes will probably not come from explicit operations
   to add attributes to a name.  Instead, name attributes will probably
   come from mechanism specific credentials.  Components of these
   mechanism specific credentials may come from platform or environment-
   specific names.  Mechanism specific naming and group membership can
   be  mapped into name attributes by the mechanism implementation.  The
   specific form of this mapping will generally require protocol
   specification for each mechanism.

   The value of many  name attributes may be suitable for use in binary
   comparison.  This should enable applications to use these name
   attributes on ACLs the same way exported names are now used on ACLs.
   For example if a particular Subjectaltname extension contains the
   appropriate  identity for an application, then  the name attribute



Hartman                 Expires December 4, 2005                [Page 7]

Internet-Draft                  GSS Names                      June 2005


   for this Subjectaltname can be placed on the ACL.  This is only true
   if the name attribute is stored in some canonical form.

4.2  Open issues

[442 lines skipped]