Generic Security Service API : C-bindings
RFC 1509

Document Type RFC - Proposed Standard (September 1993; No errata)
Obsoleted by RFC 2744
Author John Wray 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1509 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            J. Wray
Request for Comments: 1509                 Digital Equipment Corporation
                                                          September 1993

               Generic Security Service API : C-bindings

Status of this Memo

   This RFC specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.


   This document specifies C language bindings for the Generic Security
   Service Application Program Interface (GSS-API), which is described
   at a language-independent conceptual level in other documents.

   The Generic Security Service Application Programming Interface (GSS-
   API) provides security services to its callers, and is intended for
   implementation atop alternative underlying cryptographic mechanisms.
   Typically, GSS-API callers will be application protocols into which
   security enhancements are integrated through invocation of services
   provided by the GSS-API. The GSS-API allows a caller application to
   authenticate a principal identity associated with a peer application,
   to delegate rights to a peer, and to apply security services such as
   confidentiality and integrity on a per-message basis.


   The Generic Security Service Application Programming Interface [1]
   provides security services to calling applications.  It allows a
   communicating application to authenticate the user associated with
   another application, to delegate rights to another application, and
   to apply security services such as confidentiality and integrity on a
   per-message basis.

   There are four stages to using the GSSAPI:

   (a) The application acquires a set of credentials with which it may
       prove its identity to other processes.  The application's
       credentials vouch for its global identity, which may or may not
       be related to the local username under which it is running.

Wray                                                            [Page 1]
RFC 1509            GSSAPI - Overview and C bindings      September 1993

   (b) A pair of communicating applications establish a joint security
       context using their credentials.  The security context is a
       pair of GSSAPI data structures that contain shared state
       information, which is required in order that per-message
       security services may be provided.  As part of the
       establishment of a security context, the context initiator is
       authenticated to the responder, and may require that the
       responder is authenticated in turn.  The initiator may
       optionally give the responder the right to initiate further
       security contexts.  This transfer of rights is termed
       delegation, and is achieved by creating a set of credentials,
       similar to those used by the originating application, but which
       may be used by the responder.  To establish and maintain the
       shared information that makes up the security context, certain
       GSSAPI calls will return a token data structure, which is a
       cryptographically protected opaque data type.  The caller of
       such a GSSAPI routine is responsible for transferring the token
       to the peer application, which should then pass it to a
       corresponding GSSAPI routine which will decode it and extract
       the information.

   (c) Per-message services are invoked to apply either:

       (i) integrity and data origin authentication, or

       (ii) confidentiality, integrity and data origin authentication
            to application data, which are treated by GSSAPI as
            arbitrary octet-strings.  The application transmitting a
            message that it wishes to protect will call the appropriate
            GSSAPI routine (sign or seal) to apply protection, specifying
            the appropriate security context, and send the result to the
            receiving application.  The receiver will pass the received
            data to the corresponding decoding routine (verify or unseal)
            to remove the protection and validate the data.

   (d) At the completion of a communications session (which may extend
       across several connections), the peer applications call GSSAPI
       routines to delete the security context.  Multiple contexts may
       also be used (either successively or simultaneously) within a
       single communications association.

2. GSSAPI Routines

   This section lists the functions performed by each of the GSSAPI
   routines and discusses their major parameters, describing how they
   are to be passed to the routines.  The routines are listed in figure

Wray                                                            [Page 2]
Show full document text