rfc2743.txt

RFC 的详细文档！

Network Working Group                                            J. Linn
Request for Comments: 2743                              RSA Laboratories
Obsoletes: 2078                                             January 2000
Category: Standards Track


         Generic Security Service Application Program Interface
                          Version 2, Update 1


Status of this Memo

   This document 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" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The Generic Security Service Application Program Interface (GSS-API),
   Version 2, as defined in [RFC-2078], 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

   This memo obsoletes [RFC-2078], making specific, incremental changes
   in response to implementation experience and liaison requests. It is
   intended, therefore, that this memo or a successor version thereto
   will become the basis for subsequent progression of the GSS-API
   specification on the standards track.





Linn                        Standards Track                     [Page 1]

RFC 2743                        GSS-API                     January 2000


TABLE OF CONTENTS

   1: GSS-API Characteristics and Concepts . . . . . . . . . . . .  4
   1.1: GSS-API Constructs . . . . . . . . . . . . . . . . . . . .  6
   1.1.1:  Credentials . . . . . . . . . . . . . . . . . . . . . .  6
   1.1.1.1: Credential Constructs and Concepts . . . . . . . . . .  6
   1.1.1.2: Credential Management  . . . . . . . . . . . . . . . .  7
   1.1.1.3: Default Credential Resolution  . . . . . . . . . . . .  8
   1.1.2: Tokens . . . . . . . . . . . . . . . . . . . . . . . . .  9
   1.1.3:  Security Contexts . . . . . . . . . . . . . . . . . . . 11
   1.1.4:  Mechanism Types . . . . . . . . . . . . . . . . . . . . 12
   1.1.5:  Naming  . . . . . . . . . . . . . . . . . . . . . . . . 13
   1.1.6:  Channel Bindings  . . . . . . . . . . . . . . . . . . . 16
   1.2:  GSS-API Features and Issues . . . . . . . . . . . . . . . 17
   1.2.1:  Status Reporting  and Optional Service Support  . . . . 17
   1.2.1.1: Status Reporting . . . . . . . . . . . . . . . . . . . 17
   1.2.1.2: Optional Service Support . . . . . . . . . . . . . . . 19
   1.2.2: Per-Message Security Service Availability  . . . . . . . 20
   1.2.3: Per-Message Replay Detection and Sequencing  . . . . . . 21
   1.2.4:  Quality of Protection . . . . . . . . . . . . . . . . . 24
   1.2.5: Anonymity Support  . . . . . . . . . . . . . . . . . . . 25
   1.2.6: Initialization . . . . . . . . . . . . . . . . . . . . . 25
   1.2.7: Per-Message Protection During Context Establishment  . . 26
   1.2.8: Implementation Robustness  . . . . . . . . . . . . . . . 27
   1.2.9: Delegation . . . . . . . . . . . . . . . . . . . . . . . 28
   1.2.10: Interprocess Context Transfer . . . . . . . . . . . . . 28
   2:  Interface Descriptions  . . . . . . . . . . . . . . . . . . 29
   2.1:  Credential management calls . . . . . . . . . . . . . . . 31
   2.1.1:  GSS_Acquire_cred call . . . . . . . . . . . . . . . . . 31
   2.1.2:  GSS_Release_cred call . . . . . . . . . . . . . . . . . 34
   2.1.3:  GSS_Inquire_cred call . . . . . . . . . . . . . . . . . 35
   2.1.4:  GSS_Add_cred call . . . . . . . . . . . . . . . . . . . 37
   2.1.5:  GSS_Inquire_cred_by_mech call . . . . . . . . . . . . . 40
   2.2:  Context-level calls . . . . . . . . . . . . . . . . . . . 41
   2.2.1:  GSS_Init_sec_context call . . . . . . . . . . . . . . . 42
   2.2.2:  GSS_Accept_sec_context call . . . . . . . . . . . . . . 49
   2.2.3:  GSS_Delete_sec_context call . . . . . . . . . . . . . . 53
   2.2.4:  GSS_Process_context_token call  . . . . . . . . . . . . 54
   2.2.5:  GSS_Context_time call . . . . . . . . . . . . . . . . . 55
   2.2.6:  GSS_Inquire_context call  . . . . . . . . . . . . . . . 56
   2.2.7:  GSS_Wrap_size_limit call  . . . . . . . . . . . . . . . 57
   2.2.8:  GSS_Export_sec_context call . . . . . . . . . . . . . . 59
   2.2.9:  GSS_Import_sec_context call . . . . . . . . . . . . . . 61
   2.3:  Per-message calls . . . . . . . . . . . . . . . . . . . . 62
   2.3.1:  GSS_GetMIC call . . . . . . . . . . . . . . . . . . . . 63
   2.3.2:  GSS_VerifyMIC call  . . . . . . . . . . . . . . . . . . 64
   2.3.3:  GSS_Wrap call . . . . . . . . . . . . . . . . . . . . . 65
   2.3.4:  GSS_Unwrap call . . . . . . . . . . . . . . . . . . . . 66



Linn                        Standards Track                     [Page 2]

RFC 2743                        GSS-API                     January 2000


   2.4:  Support calls . . . . . . . . . . . . . . . . . . . . . . 68
   2.4.1:  GSS_Display_status call . . . . . . . . . . . . . . . . 68
   2.4.2:  GSS_Indicate_mechs call . . . . . . . . . . . . . . . . 69
   2.4.3:  GSS_Compare_name call . . . . . . . . . . . . . . . . . 70
   2.4.4:  GSS_Display_name call . . . . . . . . . . . . . . . . . 71
   2.4.5:  GSS_Import_name call  . . . . . . . . . . . . . . . . . 72
   2.4.6:  GSS_Release_name call . . . . . . . . . . . . . . . . . 73
   2.4.7:  GSS_Release_buffer call . . . . . . . . . . . . . . . . 74
   2.4.8:  GSS_Release_OID_set call  . . . . . . . . . . . . . . . 74
   2.4.9:  GSS_Create_empty_OID_set call . . . . . . . . . . . . . 75
   2.4.10: GSS_Add_OID_set_member call . . . . . . . . . . . . . . 76
   2.4.11: GSS_Test_OID_set_member call  . . . . . . . . . . . . . 76
   2.4.12: GSS_Inquire_names_for_mech call . . . . . . . . . . . . 77
   2.4.13: GSS_Inquire_mechs_for_name call . . . . . . . . . . . . 77
   2.4.14: GSS_Canonicalize_name call  . . . . . . . . . . . . . . 78
   2.4.15: GSS_Export_name call  . . . . . . . . . . . . . . . . . 79
   2.4.16: GSS_Duplicate_name call . . . . . . . . . . . . . . . . 80
   3: Data Structure Definitions for GSS-V2 Usage  . . . . . . . . 81
   3.1: Mechanism-Independent Token Format . . . . . . . . . . . . 81
   3.2: Mechanism-Independent Exported Name Object Format  . . . . 84
   4: Name Type Definitions  . . . . . . . . . . . . . . . . . . . 85
   4.1: Host-Based Service Name Form . . . . . . . . . . . . . . . 85
   4.2: User Name Form . . . . . . . . . . . . . . . . . . . . . . 86
   4.3: Machine UID Form . . . . . . . . . . . . . . . . . . . . . 87
   4.4: String UID Form  . . . . . . . . . . . . . . . . . . . . . 87
   4.5: Anonymous Nametype . . . . . . . . . . . . . . . . . . . . 87
   4.6: GSS_C_NO_OID . . . . . . . . . . . . . . . . . . . . . . . 88
   4.7: Exported Name Object . . . . . . . . . . . . . . . . . . . 88
   4.8: GSS_C_NO_NAME  . . . . . . . . . . . . . . . . . . . . . . 88
   5:  Mechanism-Specific Example Scenarios  . . . . . . . . . . . 88
   5.1: Kerberos V5, single-TGT  . . . . . . . . . . . . . . . . . 89
   5.2: Kerberos V5, double-TGT  . . . . . . . . . . . . . . . . . 89
   5.3:  X.509 Authentication Framework  . . . . . . . . . . . . . 90
   6:  Security Considerations . . . . . . . . . . . . . . . . . . 91
   7:  Related Activities  . . . . . . . . . . . . . . . . . . . . 92
   8:  Referenced Documents  . . . . . . . . . . . . . . . . . . . 93
   Appendix A: Mechanism Design Constraints  . . . . . . . . . . . 94
   Appendix B: Compatibility with GSS-V1 . . . . . . . . . . . . . 94
   Appendix C: Changes Relative to RFC-2078  . . . . . . . . . . . 96
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . .100
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . .101










Linn                        Standards Track                     [Page 3]

RFC 2743                        GSS-API                     January 2000


1: GSS-API Characteristics and Concepts

   GSS-API operates in the following paradigm.  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 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
   (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_GetMIC() and GSS_VerifyMIC() calls)
   for messages subsequently transferred in conjunction with that
   context.  (The definition for the peer entity authentication service,
   and other definitions used in this document, corresponds to that
   provided in [ISO-7498-2].) When establishing a security context, the
   GSS-API enables a context initiator to optionally permit its
   credentials to be delegated, meaning that the context acceptor may
   initiate further security contexts on behalf of the initiating
   caller. Per-message GSS_Wrap() and GSS_Unwrap() calls provide the
   data origin authentication and data integrity services which
   GSS_GetMIC() and GSS_VerifyMIC() 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 also 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 some 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



Linn                        Standards Track                     [Page 4]

RFC 2743                        GSS-API                     January 2000


   output_token to be passed to the server, and indicates
   GSS_S_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_S_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_S_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
   included in the token in order to achieve mutual authentication from
   the client's viewpoint. This call to GSS_Init_sec_context() returns
   GSS_S_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_Wrap().
   GSS_Wrap() performs data origin authentication, data integrity, and
   (optionally) confidentiality processing on the message and
   encapsulates the result into output_message, indicating
   GSS_S_COMPLETE status. The client sends the output_message to the
   server.

   The server passes the received message to GSS_Unwrap().  GSS_Unwrap()
   inverts the encapsulation performed by GSS_Wrap(), deciphers the
   message if the optional confidentiality feature was applied, and
   validates the data origin authentication and data integrity checking
   quantities. GSS_Unwrap() indicates successful validation by returning
   GSS_S_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.  Optionally, the server-side application
   may provide a token buffer to GSS_Delete_sec_context(), to receive a
   context_token to be transferred to the client in order to request