[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet-Draft                        D. Barton (CRC for DST)
<draft-barton-gss-api-sec-party-00.txt>      22 February 1996

           Multi-party Security Contexts Within the GSS-API

STATUS OF THIS MEMO

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

ABSTRACT

   The Generic Security Service Application Program Interface (GSS-API),
   as defined in RFC-1508 and subsequent Internet Draft documents,
   provides security services to callers (applications) in a generic
   fashion, supportable with a range of underlying mechanisms and
   technologies, allowing source-level portability of applications to
   different environments.

   Multi-party security contexts, where security context information is
   shared amongst more than two session peers, have received little
   consideration within the scope of the GSS-API.  This document
   describes details of one approach for supporting multi-party security
   services within the GSS-API.


















Barton    Document Expiration: 22 August 1996    [Page 1]


Internet-Draft                          22 February, 1995


1.  Introduction

   Multi-party security contexts have been overlooked in the past,
   possibly due in part to the emphasis on the client-server paradigm
   where only two parties need be involved in the context.  There is a
   growing need for the ability to seamlessly include multiple parties
   in a single security context.  This draft defines a number of simple
   modifications and additions to the GSS-API enabling multi-party
   context support.

2.  Multi-party security

   In some situations it is desirable to share security context
   information between a group of parties (entities, individuals, peers,
   what have you).  For example, multi-object bindings, secure
   conversations or even electronic contract negotiation may require
   multi-party security contexts for authentication, confidentiality,
   integrity, and other security services.

   The existing specifications for the GSS-API provide no support for
   multi-party contexts.  Separate contexts must be set up between each
   pair of parties, simulating multi-party contexts.  This approach
   requires N(N-1)/2 contexts, where N is the number of parties.  As N
   increases the management complexity and overheads increase to
   unmanagable levels.  This is a limiting factor in scaling this
   "solution".  The method proposed within this document provides a
   single context handle for each multi-party context, simplifying the
   management required by the application, and maintaining the paradigm
   of the GSS-API.

   There are two methods of establishing a multi-party security context.
   Firstly, initiating a context directly with all of the parties via a
   single call, and secondly, establishing a two or more party context
   and subsequently adding parties to the context over time.  These
   approaches are respectively called "static" and "dynamic".
   Definitions for calls supporting both approaches will be provided in
   the following sections, with discussion of each call's behaviour,
   input and output parameters.

   Throughout the following discussion the term "party" will be used to
   refer to a participating, authenticated entity.  The GSS-API terms
   these entities as "peers" or "principals", and other systems may use
   other names.  The term "party" is intended to be interchangeable with
   any of these terms.









Barton    Document Expiration: 22 August 1996    [Page 2]


Internet-Draft                          22 February, 1996


2.1  Static Multi-party Contexts

   Static multi-party context establishment occurs via a single call
   interface, yielding a handle to context data which, upon successful
   completion of the initialisation process, is shared by all
   participating parties.  This behaviour is a generalisation of the
   standard GSS-API context initialisation interface enables context
   initialisation between two parties.  The interface for this call is
   based largely on the gss_init_sec_context() call.


   Only one call is required for static multi-party context initiation.
   Without the additional extensions defined for dynamic security
   contexts, the group of parties involved in the context cannot change,
   hence the term "static".

   A new call for the GSS-API is defined which enables multi-party
   context initialisation.  This call is named
   gss_init_group_sec_context() and has the following interface
   characteristics:

   Inputs:

   o  name_list NAME_LIST,

   o  other inputs as per gss_init_sec_context().

   Outputs:

   o  all outputs correspond to gss_init_sec_context().

   This call processes the input parameter, name_list, and attempts to
   initialise a security context shared with each nominated party.
   Network interactions (where necessary) may cause this call to block
   as is the case with gss_init_sec_context().

   Return major_status codes:

   o  GSS_S_GROUP_UNSUPPORTED indicates that the underlying mechanism
      has no support for multi-party contexts.

   o  others as per gss_init_sec_context().

   This call behaves similarly in all ways to the gss_init_sec_context()
   call.  The initiator calls this function, supplying a list of names
   for inclusion in the context.  A token is returned which must be
   passed to all named parties for context acceptance.  Multi-phase
   token exchange (continuation) may occur between the initiator and
   acceptors if required.




Barton    Document Expiration: 22 August 1996    [Page 3]


Internet-Draft                          22 February, 1996


2.2  Dynamic Multi-party Contexts

   Dynamic multi-party contexts are somewhat more complicated than
   standard two party or static multi-party contexts due to extra
   management and maintenance requirements.  Addition of new parties
   requires access control and a process by which a party external to
   the context may gain entry to the context.  Context data must be
   maintained consistently across the group of parties in the context,
   and parties should have a simple way of determining the list of
   parties with whom they are sharing the context.  Specifications are
   given below for the interface characteristics of three calls
   supporting some of the services mentioned previously;
   gss_add_party(), gss_vote() and gss_context_parties() respectively.

   The gss_add_party() call effectively performs a context initiation
   with the nominated party using existing context data.  This call will
   therefore behave similarly to the gss_init_sec_context() call in many
   ways.  Continuation may occur in the intialisation phase, and
   multi-phase token exchange may be required for context data
   initialisation (sharing).  The gss_add_party() call is intended to
   yield tokens which can be fed as input directly into the
   gss_accept_sec_context() call by the acceptor, rather than requiring
   a separate API call for accepting addition to a context.

   The gss_add_party() call:

   Inputs:

   o  new_member_name INTERNAL NAME specifies the name of the new
      member to add to the group.

   o  context_handle CONTEXT HANDLE group context data established using
      gss_init_group_sec_context() or gss_init_sec_context().

   o  output_token OCTET STRING context token generated by successful
      call, to be passed to the new peer for processing by
      gss_accept_sec_context() or used as input data for multi-phase
      initiation (continuation).

   Outputs:

   o  output_token OCTET STRING as above.

   Return major_status codes:

   o  GSS_S_SUCCESS Successful completion

   o  GSS_S_FAILURE Failure. See minor_status for more information.

   o  GSS_S_CONTEXT_EXPIRED The context has already expired



Barton    Document Expiration: 22 August 1996    [Page 4]


Internet-Draft                          22 February, 1996


   o  GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
      associated credentials have expired

   o  GSS_S_NO_CONTEXT The context_handle parameter did not identify a
      valid context

   o  GSS_S_NO_CRED The supplied credentials did not reference any
      credentials.

   o  GSS_S_BAD_NAME The target_name value provided in the input_token
      was ill-formed.

   o  GSS_S_VOTING_INCOMPLETE Indicates that voting is not yet
      finalised.

   o  GSS_S_CONTINUE_NEEDED as per gss_init_sec_context().

   The initiator calls gss_add_party(), supplying the context handle and
   details of the party to be added.  The initiator must then pass an
   application message to all other parties, voters, informing them, at
   the application level, that an add request has been made.  The voters
   must then register their vote using gss_vote().  Meanwhile the
   initiator is polling the mechanism using gss_add_party(), and
   continues to do so until all votes are registered.  Once all votes
   are registered, addition success can be determined.  If addition is
   successful, gss_add_party() returns a token which must be passed to
   the party being added, for context acceptance using
   gss_accept_sec_context().

   The process by which the application calling gss_vote() determines
   the value of the vote it casts can be determined in a number of ways.
   Firstly, the application could arbitrarily acknowledge all add
   requests.  Secondly, an access control list or trust scheme may be
   used to determine whether or not to acknowledge an add request.
   Alternatively, the user (if the application is a user-level process)
   may be prompted for a response, particularly in the case of an
   on-line, multi-party conversation.

   The gss_vote() call:

   Inputs:

   o  context_handle CONTEXT HANDLE group context data established using
      gss_init_group_sec_context or gss_init_sec_context.

   o  vote_status BOOLEAN indicating either "yes"/TRUE or "no"/FALSE
      response to the addition of the specified party.

   Outputs:

   o none


Barton    Document Expiration: 22 August 1996    [Page 5]


Internet-Draft                          22 February, 1996


   Return major_status codes:

   o  GSS_S_SUCCESS Successful completion

   o  GSS_S_FAILURE Failure.  See minor_status for more information.

   o  GSS_S_CONTEXT_EXPIRED The context has already expired

   o  GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
      associated credentials have expired

   o  GSS_S_NO_CONTEXT The context_handle parameter did not identify a
      valid context

   o  GSS_S_NO_CRED The supplied credentials did not reference any
      credentials.

   There are alternatives to the voting-based style of access control.
   Access control lists could be used, trust-based methods or even
   simply security policy.  However, the design attempts to allow for
   the greatest flexibility, whilst providing a useful means of access
   control.  The voting scheme was seen to satisfactorily address these
   requirements.

   The third call defined for the dynamic multi-party contexts
   specification enables a party to determine the list of parties
   sharing the context.  The gss_context_parties() call consults the
   mechanism for an authoritative reply as to the participating members
   of the context at the current time.  On successful completion the
   call returns a list of the names of all context members.

   The gss_context_parties() call:

   Inputs:

   o  context_handle CONTEXT HANDLE group context data established
      using gss_init_group_sec_context() or gss_init_sec_context().

   Outputs:

   o  party_list NAME LIST The list of internal names of all parties
      sharing the context data

   Return major_status codes:

   o  GSS_S_SUCCESS Successful completion

   o  GSS_S_FAILURE Failure.  See minor_status for more information.

   o  GSS_S_CONTEXT_EXPIRED The context has already expired



Barton    Document Expiration: 22 August 1996    [Page 6]


Internet-Draft                          22 February, 1996


   o  GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
      associated credentials have expired

   o  GSS_S_NO_CONTEXT The context_handle parameter did not identify a
      valid context

   o  GSS_S_NO_CRED The supplied credentials did not reference any
      credentials.

3  New Data Structures

   A new data structure is necessary for multi-party context support to
   enable a list of names to be passed into the
   gss_init_group_sec_context() call and return from
   gss_context_parties().  This data structure is a compound of an
   existing GSS-API structure in a basic list data type.  A C binding
   for this data structure might be defined as follows:

   typedef struct _name_list {
                        gss_name_type     name;
                        struct _name_list *next;
                  }
           name_list;

   Only one other possible change to GSS-API data structures might be
   required.  The context data structure is typically highly mechanism
   dependant, but generally contains the names of all parties involved
   in the context.  This data structure may, in some cases, need to be
   generalised to enable the storage of more than two party names,
   typically in the form of a single local name, and a list of the names
   of all other parties in the context.  This data type must also be
   dynamic and able to be updated throughout the lifetime of the
   context, to enable appropriate handling of addition of new parties to
   the context.

4  References

   Linn, J., "Generic Security Service Application Program Interface",
   RFC 1508, September 1993.

   Wray, J., "Generic Security Service API : C-Bindings", RFC 1509,
   September 1993.

5 Acknowledgements

   The author would like to acknowledge the assistance in preparing this
   draft and designing the original forms of multi-party security for
   implementation.  The thanks of the author are extended to: Dr. Luke
   O'Connor (DSTC), Gary Gaskell (DSTC), John Linn (OpenVision), David
   Arnold (DSTC) and many others.



Barton    Document Expiration: 22 August 1996    [Page 7]


Internet-Draft                          22 February, 1996


6  Appendix A : C-Bindings

OM_uint32 gss_init_group_sec_context(
            OM_uint32*,       /* minor_status */
            gss_cred_id_t,    /* claimant_cred_handle */
            gss_ctx_id_t*,    /* context_handle */
            gss_name_list_t,  /* target_name list */
            const_gss_OID,    /* mech_type */
            int,              /* req_flags */
            OM_uint32,        /* time_req */
            gss_channel_bindings_t,
                              /* input_chan_bindings */
            gss_buffer_t,     /* input_token */
            gss_OID*,         /* actual_mech_type */
            gss_buffer_t,     /* output_token */
            int*,             /* ret_flags */
            OM_uint32*        /* time_rec */
          );

OM_uint32 gss_add_party(
            OM_uint32*,       /* minor_status */
            gss_name_t,       /* add party's name */
            gss_ctx_id_t,     /* context_handle */
            gss_buffer_t*     /* return GSS token */
          );

OM_uint32 gss_vote(
            OM_uint32*,       /* minor_status */
            gss_ctx_id_t,     /* context_handle */
            OM_uint32,        /* operation ADD/DELETE/ETC */
            OM_uint32         /* vote preference */
          );

OM_uint32 gss_context_parties(
            OM_uint32*,       /* minor_status */
            gss_ctx_id_t,     /* context_handle */
          );
















Barton    Document Expiration: 22 August 1996    [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/