rfc1508.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,393 行 · 第 1/5 页

Network Working Group                                            J. Linn
Request for Comments: 1508                         Geer Zolot Associates
                                                          September 1993


         Generic Security Service Application Program Interface

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.

Abstract

   This Generic Security Service Application Program Interface (GSS-API)
   definition provides security services to callers in a generic
   fashion, supportable with a range of underlying mechanisms and
   technologies and hence allowing source-level portability of
   applications to different environments. This specification defines
   GSS-API services and primitives at a level independent of underlying
   mechanism and programming language environment, and is to be
   complemented by other, related specifications:

        documents defining specific parameter bindings for particular
        language environments

        documents defining token formats, protocols, and procedures to
        be implemented in order to realize GSS-API services atop
        particular security mechanisms

Table of Contents

   1. GSS-API Characteristics and Concepts .......................    2
   1.1. GSS-API Constructs .......................................    5
   1.1.1.  Credentials ...........................................    5
   1.1.2.  Tokens ................................................    6
   1.1.3.  Security Contexts .....................................    7
   1.1.4.  Mechanism Types .......................................    8
   1.1.5.  Naming ................................................    9
   1.1.6.  Channel Bindings ......................................   10
   1.2.  GSS-API Features and Issues .............................   11
   1.2.1.  Status Reporting ......................................   11
   1.2.2.  Per-Message Security Service Availability .............   12
   1.2.3.  Per-Message Replay Detection and Sequencing ...........   13
   1.2.4.  Quality of Protection .................................   15



Linn                                                            [Page 1]

RFC 1508               Generic Security Interface         September 1993


   2. Interface Descriptions .....................................   15
   2.1.  Credential management calls .............................   17
   2.1.1.  GSS_Acquire_cred call .................................   17
   2.1.2.  GSS_Release_cred call .................................   19
   2.1.3.  GSS_Inquire_cred call .................................   20
   2.2.  Context-level calls .....................................   21
   2.2.1.  GSS_Init_sec_context call .............................   21
   2.2.2.  GSS_Accept_sec_context call ...........................   26
   2.2.3.  GSS_Delete_sec_context call ...........................   29
   2.2.4.  GSS_Process_context_token call ........................   30
   2.2.5.  GSS_Context_time call .................................   31
   2.3.  Per-message calls .......................................   32
   2.3.1.  GSS_Sign call .........................................   32
   2.3.2.  GSS_Verify call .......................................   33
   2.3.3.  GSS_Seal call .........................................   35
   2.3.4.  GSS_Unseal call .......................................   36
   2.4.  Support calls ...........................................   37
   2.4.1.  GSS_Display_status call ...............................   37
   2.4.2.  GSS_Indicate_mechs call ...............................   38
   2.4.3.  GSS_Compare_name call .................................   38
   2.4.4.  GSS_Display_name call .................................   39
   2.4.5.  GSS_Import_name call ..................................   40
   2.4.6.  GSS_Release_name call .................................   41
   2.4.7.  GSS_Release_buffer call ...............................   41
   2.4.8.  GSS_Release_oid_set call ..............................   42
   3. Mechanism-Specific Example Scenarios .......................   42
   3.1.  Kerberos V5, single-TGT .................................   43
   3.2.  Kerberos V5, double-TGT .................................   43
   3.3.  X.509 Authentication Framework ..........................   44
   4. Related Activities .........................................   45
   5. Acknowledgments ............................................   46
   6. Security Considerations ....................................   46
   7. Author's Address ...........................................   46
   Appendix A ....................................................   47
   Appendix B ....................................................   48
   Appendix C ....................................................   49

1. GSS-API Characteristics and Concepts

   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



Linn                                                            [Page 2]

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



Linn                                                            [Page 3]

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.

   The client passes the returned context_token to
   GSS_Process_context_token(),  which returns GSS_COMPLETE status after
   deleting context-level information at the client system.

   The GSS-API design assumes and addresses several basic goals,
   including:

      Mechanism independence: The GSS-API defines an interface to
      cryptographically implemented strong authentication and other
      security services at a generic level which is independent of
      particular underlying mechanisms. For example, GSS-API-provided
      services can be implemented by secret-key technologies (e.g.,
      Kerberos) or public-key approaches (e.g., X.509).

      Protocol environment independence: The GSS-API is independent of
      the communications protocol suites with which it is employed,
      permitting use in a broad range of protocol environments. In
      appropriate environments, an intermediate implementation "veneer"
      which is oriented to a particular communication protocol (e.g.,
      Remote Procedure Call (RPC)) may be interposed between
      applications which call that protocol and the GSS-API, thereby
      invoking GSS-API facilities in conjunction with that protocol's



Linn                                                            [Page 4]

RFC 1508               Generic Security Interface         September 1993


      communications invocations.

      Protocol association independence: The GSS-API's security context
      construct is independent of communications protocol association
      constructs. This characteristic allows a single GSS-API
      implementation to be utilized by a variety of invoking protocol
      modules on behalf of those modules' calling applications. GSS-API
      services can also be invoked directly by applications, wholly
      independent of protocol associations.

      Suitability to a range of implementation placements: GSS-API
      clients are not constrained to reside within any Trusted Computing
      Base (TCB) perimeter defined on a system where the GSS-API is
      implemented; security services are specified in a manner suitable
      to both intra-TCB and extra-TCB callers.

1.1. GSS-API Constructs

   This section describes the basic elements comprising the GSS-API.

1.1.1.  Credentials

   Credentials structures provide the prerequisites enabling peers to
   establish security contexts with each other. A caller may designate
   that its default credential be used for context establishment calls
   without presenting an explicit handle to that credential.
   Alternately, those GSS-API callers which need to make explicit
   selection of particular credentials structures may make references to
   those credentials through GSS-API-provided credential handles
   ("cred_handles").

   A single credential structure may be used for initiation of outbound
   contexts and acceptance of inbound contexts. Callers needing to
   operate in only one of these modes may designate this fact when
   credentials are acquired for use, allowing underlying mechanisms to
   optimize their processing and storage requirements. The credential
   elements defined by a particular mechanism may contain multiple
   cryptographic keys, e.g., to enable authentication and message
   encryption to be performed with different algorithms.

   A single credential structure may accommodate credential information
   associated with multiple underlying mechanisms (mech_types); a
   credential structure's contents will vary depending on the set of
   mech_types supported by a particular GSS-API implementation.
   Commonly, a single mech_type will be used for all security contexts
   established by a particular initiator to a particular target; the
   primary motivation for supporting credential sets representing
   multiple mech_types is to allow initiators on systems which are