CVS gss/doc/specification

[gss-commit]

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

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


--- /home/cvs/gss/doc/specification/draft-ietf-kitten-gss-naming-00.txt 
2004/12/02 21:28:45     NONE
+++ /home/cvs/gss/doc/specification/draft-ietf-kitten-gss-naming-00.txt 
2004/12/02 21:28:45     1.1
Network Working Group                                         S. Hartman
Internet-Draft                                                       MIT
Expires: May 31, 2005                                  November 30, 2004


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 May 31, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

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.  Some mechanisms such as
   public-key mechanisms do not have a single name to be used across all
   environments.  Other mechanisms such as Kerberos allow names to



Hartman                   Expires May 31, 2005                  [Page 1]

Internet-Draft                 GSS Names                   November 2004


   change as people move around organizations.  This document proposes
   expanding the definition of GSS-API names to deal with these
   situations.
















































Hartman                   Expires May 31, 2005                  [Page 2]

Internet-Draft                 GSS Names                   November 2004


1.  Introduction

   The Generic Security Services API [1] 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 such as 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.

   Inherent in this 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.

   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.

   Also, as GSS-API is used in more complex environments, there is a
   desire to use attribute certificates [5], Kerberos authorization data
   [2], 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 draft discusses two different cases where the current GSS-API
   naming seems inadequate.  Two proposals that have been discussed
   within the IETF Kitten community are discussed.  Finally, the
   problems that need to be resolved to adopt either of these proposals
   are discussed.





Hartman                   Expires May 31, 2005                  [Page 3]

Internet-Draft                 GSS Names                   November 2004


2.  Kerberos Naming

   The Kerberos Referrals draft [3] 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.  So in order to
   canonicalize an enterprise name to get a principal, a service must
   have credentials.  However it may not be desirable to allow services
   to map enterprise names to principal names in the general case.
   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.  Thus, it would be desirable to include 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 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 May 31, 2005                  [Page 4]

Internet-Draft                 GSS Names                   November 2004


3.  X.509 Names

   X.509 names are at least as complex as Kerberos names.  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 [4] 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.  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.
































Hartman                   Expires May 31, 2005                  [Page 5]

Internet-Draft                 GSS Names                   November 2004


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 attribute to name
   2.  Query attributes of name
   3.  Query values of an attribute
   4.  Delete an attribute from a name

4.1  Usage of Name Attributes

   Since attributes are part of GSS-API names, the acceptor can retrieve
   the attributes of the initiator'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.  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
   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

   This section describes parts of the proposal to add attributes to
   names that will need to be explored before the proposal can become a
   protocol specification.

   Are mechanisms expected to be able to carry arbitrary name attributes
   as part of a context establishment?   At first it seems like this
   would be desirable.  However the purpose of GSS-API is to establish
   an authenticated context between two peers.  In particular, a context
   authenticates two named entities to each other.  The names of these
   entities and attributes associated with these names will be used for
   authorization decisions.  If an initiator or acceptor is allowed to



Hartman                   Expires May 31, 2005                  [Page 6]

Internet-Draft                 GSS Names                   November 2004


   assert name attributes and the authenticity of these assertions is
   not validated by the mechanisms, then security problems will result.
   On the other hand, requiring that name attributes be mechanism
   specific and only be carried by mechanisms that understand the name
   attributes and can validate them compromises GSS-API's place as a
   generic API.  Application authors would be forced to understand
   mechanism-specific attributes to make authorization decisions.  In
   addition if mechanisms are not required to transport arbitrary
   attributes, then application authors will need to deal with different
   implementations of the same mechanism that support different sets of
   name attributes.  One possible solution is to carry a source along
   with each name attribute; this source could indicate whether the
   attribute comes from a mechanism data structure or from the other
   party in the authentication.

   Another related question is how will name attributes be mapped into
   their mechanism-specific forms.  For example it would be desirable to
   map many  Kerberos authorization data elements into name attributes.
   In the case of the Microsoft PAC, it would be desirable for some
   applications to get the entire PAC.  However in many cases, the
   specific lists of security IDs contained in the PAC would be more
   directly useful to an application.  So there may not be a good
   one-to-one mapping between the mechanism-specific elements and the
   representation desirable at the GSS-API layer.

   Specific name matching rules need to be developed.  How do names with
   attributes compare?  What is the effect of a name attribute on a
   target name in gss_accept_sec_context?

4.3  Handling gss_export_name

   For many mechanisms, there will be  an obvious choice to use for the
   name exported by gss_export_name.  For example in the case of
   Kerberos, the principal name can continue to be used as the exported
   name.  This will allow applications depending on existing GSS-API
   name-based authorization to continue to work.  However it is probably
   desirable to allow GSS-API mechanisms for which gss_export_name
   cannot meaningfully be defined.  The behavior of gss_export_name in
   such cases should probably be to return some error.  Such mechanisms
   may not work with existing applications and cannot conform to the
   current version of the GSS-API.










Hartman                   Expires May 31, 2005                  [Page 7]

Internet-Draft                 GSS Names                   November 2004


5.  Credential Extensions

   An alternative to the name attributes proposal  is to extend GSS-API
   credentials  with extensions labeled by OIDs.  Interfaces would be
   needed to manipulate these credential extensions and to retrieve the
   credential extensions for credentials used to establish a context.
   Even if name attributes are used, credential extensions may be useful

[326 lines skipped]