CVS gss/doc/specification

[gss-commit]

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

Added Files:
        draft-ietf-kitten-stackable-pseudo-mechs-00.txt 
Log Message:
Add.


--- 
/home/cvs/gss/doc/specification/draft-ietf-kitten-stackable-pseudo-mechs-00.txt 
    2005/02/15 18:58:38     NONE
+++ 
/home/cvs/gss/doc/specification/draft-ietf-kitten-stackable-pseudo-mechs-00.txt 
    2005/02/15 18:58:38     1.1


NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Expires: August 12, 2005                               February 11, 2005


          Stackable Generic Security Service Pseudo-Mechanisms
            draft-ietf-kitten-stackable-pseudo-mechs-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I 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 August 12, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This document defines and formalizes the concept of stackable
   pseudo-mechanisms, and associated concept of composite mechanisms,
   for the Generic Security Service Application Programming Interface
   (GSS-API), as well as several utility functions.

   Stackable GSS-API pseudo-mechanisms allow for the composition of new
   mechanisms that combine features from multiple mechanisms.  Stackable
   mechanisms that add support for Perfect Forward Security (PFS), data
   compression, additional authentication factors, etc...  are
   facilitated by this document.



Williams                Expires August 12, 2005                 [Page 1]

Internet-Draft            Stackable GSS Mechs              February 2005


Table of Contents

   1.    Conventions used in this document  . . . . . . . . . . . . .  3
   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1   Glossary . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Mechanism Composition Issues . . . . . . . . . . . . . . . .  4
   4.    Mechanism Composition  . . . . . . . . . . . . . . . . . . .  5
   4.1   Construction of Composed Mechanism OIDs  . . . . . . . . . .  5
   4.2   Mechanism Composition Rules  . . . . . . . . . . . . . . . .  6
   4.3   Interfacing with Composite Mechanisms  . . . . . . . . . . .  7
   4.4   Compatibility with the Basic GSS-APIv2u1 Interfaces  . . . .  7
   4.5   Processing of Tokens for Composite Mechanisms  . . . . . . .  8
   5.    New GSS-API Interfaces . . . . . . . . . . . . . . . . . . .  8
   5.1   New GSS-API Function Interfaces  . . . . . . . . . . . . . .  9
   5.1.1 GSS_Compose_oid()  . . . . . . . . . . . . . . . . . . . . .  9
   5.1.2 GSS_Decompose_oid()  . . . . . . . . . . . . . . . . . . . . 10
   5.1.3 GSS_Release_oid()  . . . . . . . . . . . . . . . . . . . . . 10
   5.1.4 GSS_Indicate_negotiable_mechs()  . . . . . . . . . . . . . . 11
   5.1.5 GSS_Negotiate_mechs()  . . . . . . . . . . . . . . . . . . . 12
   5.1.6 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.    Negotiation of Composite Mechanisms  . . . . . . . . . . . . 13
   6.1   Negotiation of Composite Mechanisms Through SPNEGO . . . . . 14
   7.    Requirements for Mechanism Designers . . . . . . . . . . . . 14
   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 14
   9.    Security considerations  . . . . . . . . . . . . . . . . . . 14
   10.   Normative  . . . . . . . . . . . . . . . . . . . . . . . . . 14
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
         Intellectual Property and Copyright Statements . . . . . . . 16























Williams                Expires August 12, 2005                 [Page 2]

Internet-Draft            Stackable GSS Mechs              February 2005


1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Recent discussions within the IETF have shown the need for a
   refactoring of the features that GSS-API mechanisms may provide and a
   way to compose new mechanisms from smaller components.

   One way to do this is to "stack" multiple mechanisms on top of each
   other such that the features of all of them are summed into a new,
   composite mechanism.

   One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially
   stacked over another, SPKM-3 [LIPKEY] (although LIPKEY does not
   conform to the stackable pseduo-mechanism framework described
   herein).

   The first truly stackable pseudo-mechanism proposed, CCM [CCM], is
   intended for signalling, during negotiation of mechanisms, the
   willingness of an initiator and/or acceptor to utilize channel
   bindings

   Since then other similar mechanism compositing needs and ideas have
   come up, along with problems such as "what combinations are possible,
   useful, reasonable and secure?"  This document addresses those
   problems.  It introduces the concepts of stackable pseudo-mechanisms,
   composite mechanisms and mechanism features or attributes, as well as
   new inquiry and related interfaces to help in the mechanism
   compositing.

   (Mechanism features are more formally referred to as "mechanism
   attributes" below.  The terms "feature" and mechanism attribute" are
   sometimes used interchangeably.)

2.1  Glossary

   Concrete GSS-API mechanism
      A mechanism which can be used standalone.  Examples include: the
      Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY].

   GSS-API Pseudo-mechanism
      A mechanism which uses other mechanisms in the construction of its
      context and/or per-message tokens and security contexts.  SPNEGO
      is an example of this.



Williams                Expires August 12, 2005                 [Page 3]

Internet-Draft            Stackable GSS Mechs              February 2005


   Stackable GSS-API pseudo-mechanism
      A mechanism which uses a single other mechanism in the
      construction of its tokens such that the OID of the composite
      result can be constructed by prepending the OID of the stackable
      pseudo-mechanism to the OID of the mechanism to be used by it.

   Mechanism-negotiation GSS-API pseudo-mechanism
      A GSS-API mechanism that negotiates the use of GSS-API mechanisms.
      SPNEGO [SPNEGO] is an example of this.

3.  Mechanism Composition Issues

   Interfacing with composite mechanisms through the existing GSS-API
   interfaces and the handling of composite mechanism tokens is
   straightforward enough and described in Section 4.

   However, the concepts of stackable and composite mechanisms do give
   rise to several minor problems:

   o  How to determine allowable combinations of mechanisms;
   o  How to encode composite mechanism OIDs;
   o  How to decompose the OID of a composite mechanism and process its
      tokens properly;
   o  Application interfacing issues such as:

      *  Whether and/or which composite mechanisms should be listed by
         GSS_Indicate_mechs();
      *  Whether and/or which composite mechanisms not listed by
         GSS_Indicate_mechs() may nonetheless be available for use by
         applications and how applications can detect their
         availability;
      *  What additional, if any, interfaces should be provided to help
         applications select appropriate mechanisms;
   o

      Mechanism negotiation issues (related to the application interface
      issues listed above), such as: vspace blankLines='1'/>
      *  Should applications advertise composite mechanisms in SPNEGO or
         other application-specific mechanism negotiation contexts?
      *  Or should applications implicitly advertise composite
         mechanisms by advertising concrete and stackable
         pseudo-mechanisms in SPNEGO or other application-specific
         mechanism negotiation contexts?

   Section 4 addresses the OID composition, decomposition and encoding
   issues, as well as basic interfacing and token handling issues.

   Section 5 addresses interfacing issues more generally through the



Williams                Expires August 12, 2005                 [Page 4]

Internet-Draft            Stackable GSS Mechs              February 2005


   specification of additional, optional APIs.

   Section 6 addresses mechanism negotiation issues.

4.  Mechanism Composition

   Mechanism composition by stacking pseudo-mechanisms on a concrete
   mechanism is conceptually simple: join the OIDs of the several
   mechanisms in question and process GSS-API tokens and routine calls
   through the top-most pseudo-mechanism in a stack, which can then, if
   necessary, recursively call the GSS-API to process any tokens for the
   remainder of the stack.

   Some stackable pseudo-mechanisms may do nothing more than perform
   transformations on application data (e.g., compression); such
   pseudo-mechanisms will generally chain the processing of tokens and
   routine calls to the mechanisms below them in the stack.

   Other stackable pseudo-mechanisms may utilize the mechanisms below
   them only during security context setup.  For example, a stackable
   pseudo-mechanism could perform a Diffie-Hellman key exchange and
   authenticate it by binding a security context established with the
   mechanism stacked below it; such a mechanism would provide its own
   per-message tokens.

4.1  Construction of Composed Mechanism OIDs

   Composition of mechanism OIDs is simple: prepend the OID of one
   pseudo-mechanism to the OID of another mechanism (composite or
   otherwise), but there MUST always be at least one final mechanism OID
   and it MUST be useful standalone (i.e., it MUST NOT be a
   pseudo-mechanism).  A composite mechanism OID forms, essentially, a
   stack.

   The encoding of composed mechanism OIDs is not quite the
   concatenation of the component OIDs' encodings, however.  This is
   because the first two arcs of ASN.1 OIDs are encoded differently from
   subsequent arcs (the first two arcs have a limited namespace and are
   encoded as a single octet), so were composite mechanism OIDs to be
   encoded as the concatenation of the component OIDs the result would
   not decode as the concatenation of the component OIDs.  To avoid this
   problem the first two arcs of each component of a composite mechanism
   OID, other than the leading component, will be encoded as other arcs
   would.

   Decomposition of composite mechanism OIDs is similar, with each
   pseudo-mechanism in the stack being able to determine the OID suffix
   from knowledge of its own OID(s).



Williams                Expires August 12, 2005                 [Page 5]

Internet-Draft            Stackable GSS Mechs              February 2005


   New pseudo-mechanisms MAY be allocated OIDs from the prefix given
   below as follows by assignment of a sub-string of OID arcs to be
   appended to this prefix.  This prefix OID is:

   <TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA
   TBD]

   All OID allocations below this OID MUST be for stackable pseudo-
   mechanisms and MUST consist of a single arc.  This will make it
   possible to decompose the OIDs of composite mechanisms without
   necessarily knowing a priori the OIDs of the component stackable
   pseudo-mechanisms.

4.2  Mechanism Composition Rules

   All new stackable pseudo-mechanisms MUST specify the rules for
   determining whether they can stack above a given mechanism, composite
   or otherwise.  Such rules may be based on specific mechanism
   attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs
   (composite and otherwise).

   All stackable pseudo-mechanisms MUST have the following mechanism
   composition rule relating to unknown mechanism attributes:

   o  composition with mechanisms supporting unknown mechanism
      attributes MUST NOT be permitted.

   This rule protects against compositions which cannot be considered
   today but which might nonetheless arise due to the introduction of
   new mechanisms and which might turn out to be insecure or otherwise
   undesirable.

   Mechanism composition rules for stackable pseudo-mechanisms MAY and
   SHOULD be updated as new GSS-API mechanism attributes and mechanisms
   sporting them are introduced.  The specifications of mechanisms that
   introduce new mechanism attributes or which otherwise should not be
   combined with others in ways which would be permitted under existing
   rules SHOULD also update the mechanism composition rules of affected
   pseudo-mechanisms.

   A RECOMMENDED way to describe the stacking rules for stackable
   mechanisms is as an ordered sequence of "MAY stack above X
   mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above
   Z mechanism," and/or "MUST NOT stack above a mechanism with Z
   mechanism feature(s)."

   For example a stackable mechanism that provides its own per-msg
   tokens and does not use the underlying mechnism's per-msg token



Williams                Expires August 12, 2005                 [Page 6]

Internet-Draft            Stackable GSS Mechs              February 2005


   facilities might require a rule such as "MUST NOT stack above a
   mechanism with the GSS_C_MA_COMPRESS mechanism feature."

4.3  Interfacing with Composite Mechanisms

   The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or
   provide as output the OID of any stackable pseudo-mechanism.
   Composite mechanisms MUST be treated as concrete mechanisms by the
   basic GSS-API interfaces [RFC2743].

   Thus the way in which a composite mechanism is used by applications
   with the basic GSS-API (version 2, update 1) is straightforward:
   exactly as if composite mechanisms were normal GSS-API mechanisms.

   This is facilitated by the fact that in all cases where the GSS-API
   implementation might need to know how to process or create a token it
   has the necessary contextual information, that is, the mechanism OID,
   available and can decompose composite mechanism OIDs as necessary.

   For example, for initial GSS_Init_sec_context() calls the
   implementation knows the desired mechanism OID, and if it should be
   left unspecified, it can pick a default mechanism given the initiator
   credentials provided by the application (and if none are provided
   other default mechanism and credential selections can still be made).
   For subsequent calls to GSS_Init_sec_context() the implementation
   knows which mechanism to use from the given [partially established]
   security context.  Similarly for GSS_Accept_sec_context, where on
   initial calls the mechanism OID can be determined from the given
   initial context token's framing.

   The manner in which GSS-API implementations and the various
   mechanisms and pseudo-mechanisms interface with one another is left
   as an excercise to implementors.

4.4  Compatibility with the Basic GSS-APIv2u1 Interfaces

   In order to preserve backwards compatibility with applications that
   use only the basic GSS-API interfaces (version 2, update 1), several
   restrictions are imposed on the use of composite and stackable
   pseduo-mechanisms with the basic GSS-API interfaces:

   o  GSS_Indicate_mechs() MUST NOT indicate support for any stackable
      pseduo-mechanisms under any circumstance.
   o  GSS_Indicate_mechs() MAY indicate support for some, all or none of
      the available composite mechanisms.
   o  Which composite mechanisms, if any, are indicated through
      GSS_Indicate_mechs() SHOULD be configurable.
   o  Composite mechanisms which are not indicated by



Williams                Expires August 12, 2005                 [Page 7]

Internet-Draft            Stackable GSS Mechs              February 2005


      GSS_Indicate_mechs() MUST NOT be considered as the default
      mechanism (GSS_C_NULL_OID) or as part of the default mechanism set
      (GSS_C_NULL_OID_SET).
   o  The OIDs of 'stackable' (not composite) pseudo-mechanisms MUST NOT
      be accepted as inputs or produced in the output of any of the

[497 lines skipped]