Internet DRAFT - draft-barton-gss-api-sec-party
draft-barton-gss-api-sec-party
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:45:18 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 02 Mar 1996 13:55:40 GMT
ETag: "304ad5-3fa8-3138535c"
Accept-Ranges: bytes
Content-Length: 16296
Connection: close
Content-Type: text/plain
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]
