The operational paradigm in which GSS-API operates is as follows. A
   typical GSS-API caller is itself a communications protocol, calling
   on GSS-API in order to protect its communications with
   authentication, integrity, and/or confidentiality security services.
   A GSS-API caller accepts tokens provided to it by its local GSS-API
   implementation and transfers the tokens to a peer on a remote system;
   that peer passes the received tokens to its local GSS-API
   implementation for processing. The security services available
   through GSS-API in this fashion are implementable (and have been




 
RFC 1508               Generic Security Interface         September 1993


   implemented) over a range of underlying mechanisms based on secret-
   key and public-key cryptographic technologies.

   The GSS-API separates the operations of initializing a security
   context between peers, achieving peer entity authentication (This
   security service definition, and other definitions used in this
   document, corresponds to that provided in International Standard ISO
   7498-2-1988(E), Security Architecture.) (GSS_Init_sec_context() and
   GSS_Accept_sec_context() calls), from the operations of providing
   per-message data origin authentication and data integrity protection
   (GSS_Sign() and GSS_Verify() calls) for messages subsequently
   transferred in conjunction with that context. Per-message GSS_Seal()
   and GSS_Unseal() calls provide the data origin authentication and
   data integrity services which GSS_Sign() and GSS_Verify() offer, and
   also support selection of confidentiality services as a caller
   option.  Additional calls provide supportive functions to the GSS-
   API's users.

   The following paragraphs provide an example illustrating the
   dataflows involved in use of the GSS-API by a client and server in a
   mechanism-independent fashion, establishing a security context and
   transferring a protected message. The example assumes that credential
   acquisition has already been completed.  The example assumes that the
   underlying authentication technology is capable of authenticating a
   client to a server using elements carried within a single token, and
   of authenticating the server to the client (mutual authentication)
   with a single returned token; this assumption holds for presently-
   documented CAT mechanisms but is not necessarily true for other
   cryptographic technologies and associated protocols.

   The client calls GSS_Init_sec_context()  to establish a security
   context to the server identified by targ_name, and elects to set the
   mutual_req_flag so that mutual authentication is performed in the
   course of context establishment. GSS_Init_sec_context()  returns an
   output_token to be passed to the server, and indicates
   GSS_CONTINUE_NEEDED status pending completion of the mutual
   authentication sequence. Had mutual_req_flag not been set, the
   initial call to GSS_Init_sec_context()  would have returned
   GSS_COMPLETE status. The client sends the output_token to the server.

   The server passes the received token as the input_token parameter to
   GSS_Accept_sec_context().  GSS_Accept_sec_context indicates
   GSS_COMPLETE status, provides the client's authenticated identity in
   the src_name result, and provides an output_token to be passed to the
   client. The server sends the output_token to the client.

   The client passes the received token as the input_token parameter to
   a successor call to GSS_Init_sec_context(),  which processes data




 
RFC 1508               Generic Security Interface         September 1993


   included in the token in order to achieve mutual authentication from
   the client's viewpoint. This call to GSS_Init_sec_context()  returns
   GSS_COMPLETE status, indicating successful mutual authentication and
   the completion of context establishment for this example.

   The client generates a data message and passes it to GSS_Seal().
   GSS_Seal() performs data origin authentication, data integrity, and
   (optionally) confidentiality processing on the message and
   encapsulates the result into output_message, indicating GSS_COMPLETE
   status. The client sends the output_message to the server.

   The server passes the received message to GSS_Unseal().  GSS_Unseal
   inverts the encapsulation performed by GSS_Seal(),  deciphers the
   message if the optional confidentiality feature was applied, and
   validates the data origin authentication and data integrity checking
   quantities. GSS_Unseal()  indicates successful validation by
   returning GSS_COMPLETE status along with the resultant
   output_message.

   For purposes of this example, we assume that the server knows by
   out-of-band means that this context will have no further use after
   one protected message is transferred from client to server. Given
   this premise, the server now calls GSS_Delete_sec_context() to flush
   context-level information. GSS_Delete_sec_context() returns a
   context_token for the server to pass to the client.