Network Working Group J. Linn
Request for Comments: 2743 RSA Laboratories
Obsoletes: 2078 January 2000
Category: Standards Track
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
通用安全服务应用程序接口版本2，更新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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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:
[RFC-2078]中定义的第2版通用安全服务应用程序接口（GSS-API）以通用方式向调用者提供安全服务，可通过一系列底层机制和技术进行支持，从而允许应用程序在源代码级别可移植到不同的环境。本规范在独立于底层机制和编程语言环境的级别上定义GSS-API服务和原语，并由其他相关规范补充：
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
定义令牌格式、协议和过程的文档，以便在特定安全机制上实现GSS-API服务
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.
本备忘录废除了[RFC-2078]，根据实施经验和联络要求进行了具体的增量变更。因此，本备忘录或其后续版本将成为GSS-API规范在标准轨道上后续发展的基础。
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
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
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
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
1: GSS-API Characteristics and Concepts
1:GSS-API特性和概念
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.
GSS-API在以下范例中运行。典型的GSS-API调用方本身就是一个通信协议，调用GSS-API以通过身份验证、完整性和/或机密性安全服务保护其通信。GSS-API调用方接受其本地GSS-API实现提供给它的令牌，并将令牌传输给远程系统上的对等方；该对等方将接收到的令牌传递给其本地GSS-API实现进行处理。通过GSS-API以这种方式提供的安全服务可以在基于密钥和公钥密码技术的一系列底层机制上实现（并且已经实现）。
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.
GSS-API将初始化对等方之间的安全上下文、实现对等实体身份验证（GSS_Init_sec_context（）和GSS_Accept_sec_context（）调用）的操作与提供每消息数据源身份验证和数据完整性保护（GSS_GetMIC（）和GSS_VerifyMIC（）调用）的操作分离开来对于随后与该上下文一起传输的消息。（对等实体认证服务的定义以及本文档中使用的其他定义与[ISO-7498-2]中提供的定义相对应）在建立安全上下文时，GSS-API允许上下文启动器选择性地允许委派其凭据，这意味着上下文接受者可以代表发起调用方发起进一步的安全上下文。每消息GSS_Wrap（）和GSS_Unwrap（）调用提供GSS_GetMIC（）和GSS_VerifyMIC（）提供的数据源身份验证和数据完整性服务，还支持选择保密服务作为调用方选项。其他调用为GSS-API的用户提供支持功能。
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.
以下段落提供了一个示例，说明客户机和服务器以独立于机制的方式使用GSS-API、建立安全上下文和传输受保护消息所涉及的数据流。该示例假设凭证获取已经完成。该示例还假设基础认证技术能够使用单个令牌中携带的元素向服务器认证客户端，并且能够使用单个返回的令牌向客户端认证服务器（相互认证）；这一假设适用于一些目前已记录的CAT机制，但不一定适用于其他密码技术和相关协议。
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
客户端调用GSS_Init_sec_context（）以建立到由target_name标识的服务器的安全上下文，并选择设置mutual_req_标志，以便在上下文建立过程中执行相互身份验证。GSS_Init_sec_context（）返回
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.
输出要传递给服务器的\u令牌，并指示GSS\u S\u CONTINUE\u所需状态，等待相互身份验证序列完成。如果未设置相互请求标志，则对GSS_Init_sec_context（）的初始调用将返回GSS_S_COMPLETE状态。客户端将输出令牌发送到服务器。
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.
服务器将收到的令牌作为输入令牌参数传递给GSS_Accept_sec_context（）。GSS_Accept_sec_上下文指示GSS_S_完成状态，在src_名称结果中提供客户端的身份验证，并提供要传递给客户端的输出_令牌。服务器将输出令牌发送到客户端。
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.
客户端将收到的令牌作为输入令牌参数传递给对GSS_Init_sec_context（）的后续调用，该调用处理令牌中包含的数据，以便从客户端的角度实现相互身份验证。此对GSS_Init_sec_context（）的调用返回GSS_S_COMPLETE状态，表示此示例中的相互身份验证成功并完成了上下文建立。
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.
客户端生成一条数据消息并将其传递给GSS_Wrap（）。GSS_Wrap（）对消息执行数据源身份验证、数据完整性和（可选）机密性处理，并将结果封装到输出消息中，指示GSS_完成状态。客户端将输出消息发送到服务器。
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.
服务器将收到的消息传递给GSS_Unwrap（）。GSS_Unwrap（）反转由GSS_Wrap（）执行的封装，如果应用了可选的保密功能，则解密消息，并验证数据源身份验证和数据完整性检查数量。GSS_Unwrap（）通过返回GSS_S_完成状态以及结果输出_消息，指示验证成功。
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 that client-side context-level information be deleted.
在本例中，我们假设服务器知道带外意味着在一条受保护的消息从客户端传输到服务器后，该上下文将不再有任何用途。基于这个前提，服务器现在调用GSS_Delete_sec_context（）来刷新上下文级别的信息。可选地，服务器端应用程序可以向GSS_Delete_sec_context（）提供令牌缓冲区，以接收要传输到客户端的上下文令牌，以便请求删除客户端上下文级别信息。
If a context_token is transferred, the client passes the context_token to GSS_Process_context_token(), which returns GSS_S_COMPLETE status after deleting context-level information at the client system.
如果传输了上下文\u令牌，则客户端将上下文\u令牌传递给GSS\u进程\u上下文\u令牌（），该令牌在客户端系统中删除上下文级别信息后返回GSS\u S\u完成状态。
The GSS-API design assumes and addresses several basic goals, including:
GSS-API设计假定并实现了几个基本目标，包括：
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 have been implemented using secret-key technologies (e.g., Kerberos, per [RFC-1964]) and with public-key approaches (e.g., SPKM, per [RFC-2025]).
机制独立性：GSS-API在通用级别上定义了一个接口，用于加密实现的强身份验证和其他安全服务，该接口独立于特定的底层机制。例如，GSS API提供的服务已使用密钥技术（如Kerberos，依据[RFC-1964]）和公钥方法（如SPKM，依据[RFC-2025]）实现。
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 may be interposed between applications which call that protocol and the GSS-API (e.g., as defined in [RFC-2203] for Open Network Computing Remote Procedure Call (RPC)), thereby invoking GSS-API facilities in conjunction with that protocol's communications invocations.
协议环境独立性：GSS-API独立于使用它的通信协议套件，允许在广泛的协议环境中使用。在适当的环境中，可以在调用特定通信协议的应用程序和GSS-API（例如，如[RFC-2203]中定义的开放网络计算远程过程调用（RPC））之间插入面向特定通信协议的中间实现“贴面”，从而结合该协议的通信调用调用GSS-API设施。
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.
协议关联独立性：GSS-API的安全上下文构造独立于通信协议关联构造。此特性允许代表这些模块的调用应用程序的各种调用协议模块使用单个GSS-API实现。GSS-API服务也可以由应用程序直接调用，完全独立于协议关联。
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.
适用于一系列实施位置：GSS-API客户端不受限制地驻留在实施GSS-API的系统上定义的任何可信计算基础（TCB）周界内；安全服务的指定方式既适用于TCB内部调用方，也适用于TCB外部调用方。
1.1: GSS-API Constructs
1.1:GSS-API构造
This section describes the basic elements comprising the GSS-API.
本节描述了组成GSS-API的基本要素。
1.1.1: Credentials
1.1.1：证书
1.1.1.1: Credential Constructs and Concepts
1.1.1.1：凭证结构和概念
Credentials provide the prerequisites which permit GSS-API peers to establish security contexts with each other. A caller may designate that the credential elements which are to be applied for context initiation or acceptance be selected by default. Alternately, those GSS-API callers which need to make explicit selection of particular
凭据提供了允许GSS-API对等方彼此建立安全上下文的先决条件。调用者可以指定默认情况下选择要应用于上下文启动或接受的凭证元素。或者，这些GSS-API调用程序需要显式选择特定的
credentials structures may make references to those credentials through GSS-API-provided credential handles ("cred_handles"). In all cases, callers' credential references are indirect, mediated by GSS-API implementations and not requiring callers to access the selected credential elements.
凭证结构可以通过GSS API提供的凭证句柄（“凭证句柄”）引用这些凭证。在所有情况下，调用者的凭证引用都是间接的，由GSS-API实现介导，不要求调用者访问所选凭证元素。
A single credential structure may be used to initiate outbound contexts and to accept 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 GSS-API credential structure may contain multiple credential elements, each containing mechanism-specific information for a particular underlying mechanism (mech_type), but the set of elements within a given credential structure represent a common entity. A credential structure's contents will vary depending on the set of mech_types supported by a particular GSS-API implementation. Each credential element identifies the data needed by its mechanism in order to establish contexts on behalf of a particular principal, and may contain separate credential references for use in context initiation and context acceptance. Multiple credential elements within a given credential having overlapping combinations of mechanism, usage mode, and validity period are not permitted.
GSS-API凭证结构可能包含多个凭证元素，每个元素都包含特定底层机制（mech_类型）的特定机制信息，但给定凭证结构中的元素集表示一个公共实体。凭证结构的内容将根据特定GSS-API实现支持的一组机械类型而有所不同。每个凭证元素标识其机制所需的数据，以便代表特定主体建立上下文，并且可以包含单独的凭证引用，用于上下文启动和上下文接受。不允许给定凭证中具有机制、使用模式和有效期重叠组合的多个凭证元素。
Commonly, a single mech_type will be used for all security contexts established by a particular initiator to a particular target. A major motivation for supporting credential sets representing multiple mech_types is to allow initiators on systems which are equipped to handle multiple types to initiate contexts to targets on other systems which can accommodate only a subset of the set supported at the initiator's system.
通常，单个mech_类型将用于由特定启动器建立到特定目标的所有安全上下文。支持代表多种机械类型的凭证集的一个主要动机是，允许系统上配备有处理多种类型的启动器向其他系统上的目标发起上下文，这些系统只能容纳启动器系统支持的凭证集的一个子集。
1.1.1.2: Credential Management
1.1.1.2：凭证管理
It is the responsibility of underlying system-specific mechanisms and OS functions below the GSS-API to ensure that the ability to acquire and use credentials associated with a given identity is constrained to appropriate processes within a system. This responsibility should be taken seriously by implementors, as the ability for an entity to utilize a principal's credentials is equivalent to the entity's ability to successfully assert that principal's identity.
GSS-API下的底层系统特定机制和操作系统功能负责确保获取和使用与给定身份相关联的凭证的能力受限于系统内的适当流程。实现者应该认真对待这一责任，因为实体利用主体凭证的能力等同于实体成功声明主体身份的能力。
Once a set of GSS-API credentials is established, the transferability of that credentials set to other processes or analogous constructs within a system is a local matter, not defined by the GSS-API. An example local policy would be one in which any credentials received as a result of login to a given user account, or of delegation of rights to that account, are accessible by, or transferable to, processes running under that account.
一旦建立了一组GSS-API凭据，该凭据集到系统内其他进程或类似构造的可转移性是一个局部问题，而不是由GSS-API定义的。本地策略的一个示例是，在该策略中，由于登录到给定用户帐户或授权给该帐户而收到的任何凭据都可由该帐户下运行的进程访问或转移到该帐户。
The credential establishment process (particularly when performed on behalf of users rather than server processes) is likely to require access to passwords or other quantities which should be protected locally and exposed for the shortest time possible. As a result, it will often be appropriate for preliminary credential establishment to be performed through local means at user login time, with the result(s) cached for subsequent reference. These preliminary credentials would be set aside (in a system-specific fashion) for subsequent use, either:
凭证建立过程（特别是代表用户而不是服务器过程执行时）可能需要访问密码或其他数量，这些密码或数量应在本地受到保护，并在尽可能短的时间内公开。因此，在用户登录时通过本地方式执行初步凭证建立通常是合适的，并将结果缓存以供后续参考。这些初步凭证将（以特定于系统的方式）留作后续使用，或者：
to be accessed by an invocation of the GSS-API GSS_Acquire_cred() call, returning an explicit handle to reference that credential
通过调用GSS-API GSS_Acquire_cred（）调用访问，返回引用该凭证的显式句柄
to comprise default credential elements to be installed, and to be used when default credential behavior is requested on behalf of a process
包含要安装的默认凭证元素，并在代表进程请求默认凭证行为时使用
1.1.1.3: Default Credential Resolution
1.1.1.3：默认凭证解析
The GSS_Init_sec_context() and GSS_Accept_sec_context() routines allow the value GSS_C_NO_CREDENTIAL to be specified as their credential handle parameter. This special credential handle indicates a desire by the application to act as a default principal. In support of application portability, support for the default resolution behavior described below for initiator credentials (GSS_Init_sec_context() usage) is mandated; support for the default resolution behavior described below for acceptor credentials (GSS_Accept_sec_context() usage) is recommended. If default credential resolution fails, GSS_S_NO_CRED status is to be returned.
GSS_Init_sec_context（）和GSS_Accept_sec_context（）例程允许将值GSS_C_NO_CREDENTIAL指定为其凭证句柄参数。此特殊凭证句柄表示应用程序希望充当默认主体。为了支持应用程序的可移植性，必须支持下面描述的启动器凭据的默认解析行为（GSS_Init_sec_context（）用法）；建议支持下面描述的默认解析行为，用于接受方凭据（GSS_Accept_sec_context（）用法）。如果默认凭证解析失败，将返回GSS\U S\U NO\U CRED状态。
GSS_Init_sec_context:
GSS_初始_秒_上下文：
(i) If there is only a single principal capable of initiating security contexts that the application is authorized to act on behalf of, then that principal shall be used, otherwise
(i) 如果只有一个主体能够启动授权应用程序代表的安全上下文，则应使用该主体，否则
(ii) If the platform maintains a concept of a default network-identity, and if the application is authorized to act on behalf of that identity for the purpose of initiating security contexts, then the principal corresponding to that identity shall be used, otherwise
（ii）如果平台保持默认网络身份的概念，并且如果应用程序被授权代表该身份启动安全上下文，则应使用与该身份对应的主体，否则
(iii) If the platform maintains a concept of a default local identity, and provides a means to map local identities into network-identities, and if the application is authorized to act on behalf of the network-identity image of the default local identity for the purpose of initiating security contexts, then the principal corresponding to that identity shall be used, otherwise
（iii）如果平台维护默认本地身份的概念，并提供将本地身份映射到网络身份的方法，并且如果应用程序被授权代表默认本地身份的网络身份映像启动安全上下文，则应使用与该身份对应的主体，否则
(iv) A user-configurable default identity should be used.
（iv）应使用用户可配置的默认标识。
GSS_Accept_sec_context:
GSS_接受_秒_上下文：
(i) If there is only a single authorized principal identity capable of accepting security contexts, then that principal shall be used, otherwise
(i) 如果只有一个授权主体标识能够接受安全上下文，则应使用该主体，否则
(ii) If the mechanism can determine the identity of the target principal by examining the context-establishment token, and if the accepting application is authorized to act as that principal for the purpose of accepting security contexts, then that principal identity shall be used, otherwise
（ii）如果机制可以通过检查上下文建立令牌来确定目标主体的身份，并且如果接受应用程序被授权作为该主体来接受安全上下文，则应使用该主体身份，否则
(iii) If the mechanism supports context acceptance by any principal, and mutual authentication was not requested, any principal that the application is authorized to accept security contexts under may be used, otherwise
（iii）如果该机制支持任何主体接受上下文，并且未请求相互认证，则可以使用应用程序被授权接受安全上下文的任何主体，否则
(iv) A user-configurable default identity shall be used.
（iv）应使用用户可配置的默认标识。
The purpose of the above rules is to allow security contexts to be established by both initiator and acceptor using the default behavior wherever possible. Applications requesting default behavior are likely to be more portable across mechanisms and platforms than those that use GSS_Acquire_cred() to request a specific identity.
上述规则的目的是允许发起方和接受方尽可能使用默认行为来建立安全上下文。与使用GSS_Acquire_cred（）请求特定身份的应用程序相比，请求默认行为的应用程序可能更易于跨机制和平台移植。
1.1.2: Tokens
1.1.2：代币
Tokens are data elements transferred between GSS-API callers, and are divided into two classes. Context-level tokens are exchanged in order to establish and manage a security context between peers. Per-message tokens relate to an established context and are exchanged to provide
令牌是GSS-API调用方之间传输的数据元素，分为两类。为了在对等方之间建立和管理安全上下文，需要交换上下文级令牌。每消息令牌与已建立的上下文相关，并进行交换以提供
protective security services (i.e., data origin authentication, integrity, and optional confidentiality) for corresponding data messages.
相应数据消息的保护性安全服务（即数据源身份验证、完整性和可选保密性）。
The first context-level token obtained from GSS_Init_sec_context() is required to indicate at its very beginning a globally-interpretable mechanism identifier, i.e., an Object Identifier (OID) of the security mechanism. The remaining part of this token as well as the whole content of all other tokens are specific to the particular underlying mechanism used to support the GSS-API. Section 3.1 of this document provides, for designers of GSS-API mechanisms, the description of the header of the first context-level token which is then followed by mechanism-specific information.
从GSS_Init_sec_context（）获得的第一个上下文级令牌需要在其开始时指示全局可解释的机制标识符，即安全机制的对象标识符（OID）。此令牌的其余部分以及所有其他令牌的全部内容特定于用于支持GSS-API的特定底层机制。本文件第3.1节为GSS-API机制的设计者提供了第一个上下文级令牌的头部描述，随后是机制特定信息。
Tokens' contents are opaque from the viewpoint of GSS-API callers. They are generated within the GSS-API implementation at an end system, provided to a GSS-API caller to be transferred to the peer GSS-API caller at a remote end system, and processed by the GSS-API implementation at that remote end system.
从GSS-API调用方的角度来看，令牌的内容是不透明的。它们在终端系统的GSS-API实现中生成，提供给GSS-API调用方以传输给远程终端系统的对等GSS-API调用方，并由该远程终端系统的GSS-API实现处理。
Context-level tokens may be output by GSS-API calls (and should be transferred to GSS-API peers) whether or not the calls' status indicators indicate successful completion. Per-message tokens, in contrast, are to be returned only upon successful completion of per-message calls. Zero-length tokens are never returned by GSS routines for transfer to a peer. Token transfer may take place in an in-band manner, integrated into the same protocol stream used by the GSS-API callers for other data transfers, or in an out-of-band manner across a logically separate channel.
无论调用的状态指示符是否指示成功完成，GSS-API调用都可以输出上下文级令牌（并且应该传输给GSS-API对等方）。相反，每消息令牌仅在成功完成每消息调用后返回。GSS例程从不返回零长度令牌以传输到对等方。令牌传输可以以带内方式、集成到GSS-API调用者用于其他数据传输的相同协议流中、或者以带外方式跨逻辑上独立的信道进行。
Different GSS-API tokens are used for different purposes (e.g., context initiation, context acceptance, protected message data on an established context), and it is the responsibility of a GSS-API caller receiving tokens to distinguish their types, associate them with corresponding security contexts, and pass them to appropriate GSS-API processing routines. Depending on the caller protocol environment, this distinction may be accomplished in several ways.
不同的GSS-API令牌用于不同的目的（例如，上下文启动、上下文接受、已建立上下文上的受保护消息数据），接收令牌的GSS-API调用方负责区分其类型，将其与相应的安全上下文关联，并将它们传递给相应的GSS-API处理例程。根据调用方协议环境的不同，这种区别可以通过几种方式实现。
The following examples illustrate means through which tokens' types may be distinguished:
以下示例说明了可以区分令牌类型的方法：
- implicit tagging based on state information (e.g., all tokens on a new association are considered to be context establishment tokens until context establishment is completed, at which point all tokens are considered to be wrapped data objects for that context),
- 基于状态信息的隐式标记（例如，在上下文建立完成之前，新关联上的所有标记都被视为上下文建立标记，此时所有标记都被视为该上下文的包装数据对象），
- explicit tagging at the caller protocol level,
- 调用方协议级别的显式标记，
- a hybrid of these approaches.
- 这些方法的混合。
Commonly, the encapsulated data within a token includes internal mechanism-specific tagging information, enabling mechanism-level processing modules to distinguish tokens used within the mechanism for different purposes. Such internal mechanism-level tagging is recommended to mechanism designers, and enables mechanisms to determine whether a caller has passed a particular token for processing by an inappropriate GSS-API routine.
通常，令牌内的封装数据包括内部机制特定的标记信息，使机制级处理模块能够区分机制内用于不同目的的令牌。建议机制设计者使用这种内部机制级标记，并使机制能够确定调用方是否已传递特定令牌，以便由不适当的GSS-API例程进行处理。
Development of GSS-API mechanisms based on a particular underlying cryptographic technique and protocol (i.e., conformant to a specific GSS-API mechanism definition) does not necessarily imply that GSS-API callers using that GSS-API mechanism will be able to interoperate with peers invoking the same technique and protocol outside the GSS-API paradigm, or with peers implementing a different GSS-API mechanism based on the same underlying technology. The format of GSS-API tokens defined in conjunction with a particular mechanism, and the techniques used to integrate those tokens into callers' protocols, may not be interoperable with the tokens used by non-GSS-API callers of the same underlying technique.
基于特定底层加密技术和协议开发GSS-API机制（即，符合特定GSS-API机制定义）并不一定意味着使用该GSS-API机制的GSS-API调用方将能够与在GSS-API范式之外调用相同技术和协议的对等方互操作，或者与基于相同底层技术实现不同GSS-API机制的对等方互操作。结合特定机制定义的GSS-API令牌的格式，以及用于将这些令牌集成到调用方协议中的技术，可能无法与具有相同底层技术的非GSS API调用方使用的令牌进行互操作。
1.1.3: Security Contexts
1.1.3：安全上下文
Security contexts are established between peers, using credentials established locally in conjunction with each peer or received by peers via delegation. Multiple contexts may exist simultaneously between a pair of peers, using the same or different sets of credentials. Coexistence of multiple contexts using different credentials allows graceful rollover when credentials expire. Distinction among multiple contexts based on the same credentials serves applications by distinguishing different message streams in a security sense.
安全上下文在对等点之间建立，使用与每个对等点一起在本地建立的凭据或对等点通过委派接收的凭据。使用相同或不同的凭据集，一对对等方之间可能同时存在多个上下文。使用不同凭据的多个上下文共存允许在凭据过期时进行优雅的滚动。基于相同凭证的多个上下文之间的区别通过在安全意义上区分不同的消息流为应用程序服务。
The GSS-API is independent of underlying protocols and addressing structure, and depends on its callers to transport GSS-API-provided data elements. As a result of these factors, it is a caller responsibility to parse communicated messages, separating GSS-API-related data elements from caller-provided data. The GSS-API is independent of connection vs. connectionless orientation of the underlying communications service.
GSS-API独立于底层协议和寻址结构，并依赖其调用者传输GSS API提供的数据元素。由于这些因素，调用方负责解析通信消息，将GSS API相关数据元素与调用方提供的数据分离。GSS-API独立于基础通信服务的连接方向与无连接方向。
No correlation between security context and communications protocol association is dictated. (The optional channel binding facility, discussed in Section 1.1.6 of this document, represents an intentional exception to this rule, supporting additional protection
安全上下文和通信协议关联之间没有关联。（本文件第1.1.6节中讨论的可选通道绑定设施表示本规则的故意例外，支持额外保护
features within GSS-API supporting mechanisms.) This separation allows the GSS-API to be used in a wide range of communications environments, and also simplifies the calling sequences of the individual calls. In many cases (depending on underlying security protocol, associated mechanism, and availability of cached information), the state information required for context setup can be sent concurrently with initial signed user data, without interposing additional message exchanges. Messages may be protected and transferred in both directions on an established GSS-API security context concurrently; protection of messages in one direction does not interfere with protection of messages in the reverse direction.
GSS-API支持机制中的功能。）这种分离允许GSS-API在广泛的通信环境中使用，还简化了单个调用的调用序列。在许多情况下（取决于底层安全协议、关联机制和缓存信息的可用性），上下文设置所需的状态信息可以与初始签名用户数据同时发送，而无需插入额外的消息交换。可以在已建立的GSS-API安全上下文上同时在两个方向上保护和传输消息；在一个方向上保护消息不会干扰在相反方向上保护消息。
GSS-API implementations are expected to retain inquirable context data on a context until the context is released by a caller, even after the context has expired, although underlying cryptographic data elements may be deleted after expiration in order to limit their exposure.
GSS-API实现预计将保留上下文上的可查询上下文数据，直到调用方释放该上下文，即使在该上下文已过期之后也是如此，尽管在过期之后可能会删除底层加密数据元素以限制其暴露。
1.1.4: Mechanism Types
1.1.4：机构类型
In order to successfully establish a security context with a target peer, it is necessary to identify an appropriate underlying mechanism type (mech_type) which both initiator and target peers support. The definition of a mechanism embodies not only the use of a particular cryptographic technology (or a hybrid or choice among alternative cryptographic technologies), but also definition of the syntax and semantics of data element exchanges which that mechanism will employ in order to support security services.
为了成功地与目标对等方建立安全上下文，有必要确定启动器和目标对等方都支持的适当的底层机制类型（mech_类型）。机制的定义不仅体现了特定密码技术（或替代密码技术的混合或选择）的使用，还体现了该机制将采用的数据元素交换的语法和语义的定义，以支持安全服务。
It is recommended that callers initiating contexts specify the "default" mech_type value, allowing system-specific functions within or invoked by the GSS-API implementation to select the appropriate mech_type, but callers may direct that a particular mech_type be employed when necessary.
建议发起上下文的调用方指定“默认”mech_类型值，允许GSS-API实现中或由GSS-API实现调用的系统特定函数选择适当的mech_类型，但调用方可以指示在必要时使用特定的mech_类型。
For GSS-API purposes, the phrase "negotiating mechanism" refers to a mechanism which itself performs negotiation in order to select a concrete mechanism which is shared between peers and is then used for context establishment. Only those mechanisms which are defined in their specifications as negotiating mechanisms are to yield selected mechanisms with different identifier values than the value which is input by a GSS-API caller, except for the case of a caller requesting the "default" mech_type.
出于GSS-API的目的，“协商机制”一词指的是一种机制，该机制本身执行协商，以选择在对等方之间共享的具体机制，然后用于建立上下文。只有那些在其规范中定义为协商机制的机制才能产生具有不同于GSS-API调用方输入值的标识符值的选定机制，调用方请求“默认”机制类型的情况除外。
The means for identifying a shared mech_type to establish a security context with a peer will vary in different environments and circumstances; examples include (but are not limited to):
识别共享机制类型以与对等方建立安全上下文的方法在不同的环境和情况下会有所不同；示例包括（但不限于）：
use of a fixed mech_type, defined by configuration, within an environment
在环境中使用由配置定义的固定机械类型
syntactic convention on a target-specific basis, through examination of a target's name lookup of a target's name in a naming service or other database in order to identify mech_types supported by that target
特定于目标的语法约定，通过检查目标的名称在命名服务或其他数据库中查找目标的名称，以识别该目标支持的机械类型
explicit negotiation between GSS-API callers in advance of security context setup
在安全上下文设置之前GSS-API调用方之间的显式协商
use of a negotiating mechanism
使用谈判机制
When transferred between GSS-API peers, mech_type specifiers (per Section 3 of this document, represented as Object Identifiers (OIDs)) serve to qualify the interpretation of associated tokens. (The structure and encoding of Object Identifiers is defined in [ISOIEC-8824] and [ISOIEC-8825].) Use of hierarchically structured OIDs serves to preclude ambiguous interpretation of mech_type specifiers. The OID representing the DASS ([RFC-1507]) MechType, for example, is 1.3.12.2.1011.7.5, and that of the Kerberos V5 mechanism ([RFC-1964]), having been advanced to the level of Proposed Standard, is 1.2.840.113554.1.2.2.
当在GSS-API对等方之间传输时，mech_类型说明符（根据本文件第3节，表示为对象标识符（OID））用于限定相关令牌的解释。（在[ISOIEC-8824]和[ISOIEC-8825]中定义了对象标识符的结构和编码）。使用层次结构OID可以避免对机械类型说明符的模糊解释。例如，表示DAS（[RFC-1507]）机制类型的OID是1.3.12.2.1011.7.5，而已提升到建议标准级别的Kerberos V5机制（[RFC-1964]）的OID是1.2.840.113554.1.2.2。
1.1.5: Naming
1.1.5：命名
The GSS-API avoids prescribing naming structures, treating the names which are transferred across the interface in order to initiate and accept security contexts as opaque objects. This approach supports the GSS-API's goal of implementability atop a range of underlying security mechanisms, recognizing the fact that different mechanisms process and authenticate names which are presented in different forms. Generalized services offering translation functions among arbitrary sets of naming environments are outside the scope of the GSS-API; availability and use of local conversion functions to translate among the naming formats supported within a given end system is anticipated.
GSS-API避免规定命名结构，将通过接口传输的名称视为不透明对象来启动和接受安全上下文。这种方法支持GSS-API在一系列底层安全机制之上实现的目标，认识到不同机制处理和验证以不同形式呈现的名称的事实。在任意命名环境集之间提供转换功能的通用服务不在GSS-API的范围之内；预期本地转换功能的可用性和使用，以在给定终端系统内支持的命名格式之间进行转换。
Different classes of name representations are used in conjunction with different GSS-API parameters:
不同类别的名称表示与不同的GSS-API参数结合使用：
- Internal form (denoted in this document by INTERNAL NAME), opaque to callers and defined by individual GSS-API implementations. GSS-API implementations supporting multiple namespace types must maintain internal tags to disambiguate the interpretation of particular names. A Mechanism Name (MN) is a special case of INTERNAL NAME, guaranteed to contain elements
- 内部形式（在本文档中由内部名称表示），对调用方不透明，由单个GSS-API实现定义。支持多种名称空间类型的GSS-API实现必须维护内部标记，以消除特定名称解释的歧义。机制名称（MN）是内部名称的特例，保证包含元素
corresponding to one and only one mechanism; calls which are guaranteed to emit MNs or which require MNs as input are so identified within this specification.
对应于一个且仅一个机制；保证发出MN或需要MN作为输入的调用在本规范中确定。
- Contiguous string ("flat") form (denoted in this document by OCTET STRING); accompanied by OID tags identifying the namespace to which they correspond. Depending on tag value, flat names may or may not be printable strings for direct acceptance from and presentation to users. Tagging of flat names allows GSS-API callers and underlying GSS-API mechanisms to disambiguate name types and to determine whether an associated name's type is one which they are capable of processing, avoiding aliasing problems which could result from misinterpreting a name of one type as a name of another type.
- 连续字符串（“扁平”）形式（在本文件中用八位字节字符串表示）；伴随OID标记，标识它们所对应的名称空间。根据标记值的不同，平面名称可能是也可能不是可打印的字符串，以供用户直接接受和演示。对平面名称进行标记允许GSS-API调用方和底层GSS-API机制消除名称类型的歧义，并确定关联名称的类型是否是它们能够处理的类型，从而避免因将一种类型的名称误解为另一种类型的名称而导致的别名问题。
- The GSS-API Exported Name Object, a special case of flat name designated by a reserved OID value, carries a canonicalized form of a name suitable for binary comparisons.
- GSS-API导出的名称对象是由保留OID值指定的平面名称的特例，它具有适合于二进制比较的规范化名称形式。
In addition to providing means for names to be tagged with types, this specification defines primitives to support a level of naming environment independence for certain calling applications. To provide basic services oriented towards the requirements of callers which need not themselves interpret the internal syntax and semantics of names, GSS-API calls for name comparison (GSS_Compare_name()), human-readable display (GSS_Display_name()), input conversion (GSS_Import_name()), internal name deallocation (GSS_Release_name()), and internal name duplication (GSS_Duplicate_name()) functions are defined. (It is anticipated that these proposed GSS-API calls will be implemented in many end systems based on system-specific name manipulation primitives already extant within those end systems; inclusion within the GSS-API is intended to offer GSS-API callers a portable means to perform specific operations, supportive of authorization and audit requirements, on authenticated names.)
除了提供用类型标记名称的方法外，本规范还定义了原语，以支持某些调用应用程序的命名环境独立性。为了提供面向调用方的基本服务，这些调用方本身不需要解释名称的内部语法和语义，GSS-API调用名称比较（GSS_Compare_name（））、人类可读显示（GSS_display_name（））、输入转换（GSS_Import_name（））、内部名称解除分配（GSS_Release_name（）），定义了内部名称复制（GSS_Duplicate_name（））函数。（预计这些拟议的GSS-API调用将在许多终端系统中基于这些终端系统中已经存在的系统特定名称操纵原语实现；GSS-API中的包含旨在为GSS-API调用方提供执行特定操作的便携式手段，支持授权和审计要求。）（在经过身份验证的名称上）
GSS_Import_name() implementations can, where appropriate, support more than one printable syntax corresponding to a given namespace (e.g., alternative printable representations for X.500 Distinguished Names), allowing flexibility for their callers to select among alternative representations. GSS_Display_name() implementations output a printable syntax selected as appropriate to their operational environments; this selection is a local matter. Callers desiring portability across alternative printable syntaxes should refrain from implementing comparisons based on printable name forms and should instead use the GSS_Compare_name() call to determine whether or not one internal-format name matches another.
GSS_Import_name（）实现可以在适当的情况下支持与给定名称空间对应的多个可打印语法（例如，X.500可分辨名称的可选可打印表示），从而允许调用方在可选表示中进行灵活选择。GSS_Display_name（）实现输出根据其操作环境选择的可打印语法；这是一个地方性的选择。希望跨可选可打印语法进行移植的调用方应避免基于可打印名称表单实现比较，而应使用GSS_Compare_name（）调用来确定一个内部格式名称是否与另一个匹配。
When used in large access control lists, the overhead of invoking GSS_Import_name() and GSS_Compare_name() on each name from the ACL may be prohibitive. As an alternative way of supporting this case, GSS-API defines a special form of the contiguous string name which may be compared directly (e.g., with memcmp()). Contiguous names suitable for comparison are generated by the GSS_Export_name() routine, which requires an MN as input. Exported names may be re-imported by the GSS_Import_name() routine, and the resulting internal name will also be an MN. The symbolic constant GSS_C_NT_EXPORT_NAME identifies the "export name" type. Structurally, an exported name object consists of a header containing an OID identifying the mechanism that authenticated the name, and a trailer containing the name itself, where the syntax of the trailer is defined by the individual mechanism specification. The precise format of an exported name is defined in Section 3.2 of this specification.
在大型访问控制列表中使用时，对ACL中的每个名称调用GSS_Import_name（）和GSS_Compare_name（）的开销可能会很高。作为支持这种情况的另一种方式，GSS-API定义了一种特殊形式的连续字符串名称，可以直接进行比较（例如，与memcmp（）进行比较）。适合比较的连续名称由GSS_Export_name（）例程生成，该例程需要一个MN作为输入。导出的名称可以通过GSS_Import_name（）例程重新导入，生成的内部名称也将是MN。符号常量GSS_C_NT_EXPORT_NAME标识“EXPORT NAME”类型。从结构上讲，导出的名称对象由一个标头和一个尾部组成，前者包含标识对名称进行身份验证的机制的OID，后者包含名称本身，其中尾部的语法由各个机制规范定义。本规范第3.2节定义了导出名称的精确格式。
Note that the results obtained by using GSS_Compare_name() will in general be different from those obtained by invoking GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the exported names. The first series of operations determines whether two (unauthenticated) names identify the same principal; the second whether a particular mechanism would authenticate them as the same principal. These two operations will in general give the same results only for MNs.
请注意，使用GSS_Compare_name（）获得的结果通常与调用GSS_Canonicalize_name（）和GSS_Export_name（）然后比较导出的名称获得的结果不同。第一系列操作确定两个（未经验证的）名称是否标识相同的主体；第二个问题是特定机制是否将它们作为同一主体进行身份验证。这两种操作通常仅对MNs产生相同的结果。
The following diagram illustrates the intended dataflow among name-related GSS-API processing routines.
下图说明了与名称相关的GSS-API处理例程之间的预期数据流。
GSS-API library defaults
|
|
V text, for
text --------------> internal_name (IN) -----------> display only
import_name() / display_name()
/
/
/
accept_sec_context() /
| /
| /
| / canonicalize_name()
| /
| /
| /
| /
| /
| |
V V <---------------------
single mechanism import_name() exported name: flat
internal_name (MN) binary "blob" usable
----------------------> for access control
export_name()
GSS-API library defaults
|
|
V text, for
text --------------> internal_name (IN) -----------> display only
import_name() / display_name()
/
/
/
accept_sec_context() /
| /
| /
| / canonicalize_name()
| /
| /
| /
| /
| /
| |
V V <---------------------
single mechanism import_name() exported name: flat
internal_name (MN) binary "blob" usable
----------------------> for access control
export_name()
1.1.6: Channel Bindings
1.1.6：通道绑定
The GSS-API accommodates the concept of caller-provided channel binding ("chan_binding") information. Channel bindings are used to strengthen the quality with which peer entity authentication is provided during context establishment, by limiting the scope within which an intercepted context establishment token can be reused by an attacker. Specifically, they enable GSS-API callers to bind the establishment of a security context to relevant characteristics (e.g., addresses, transformed representations of encryption keys) of the underlying communications channel, of protection mechanisms applied to that communications channel, and to application-specific data.
GSS-API包含调用方提供的通道绑定（“chan_绑定”）信息的概念。通道绑定用于通过限制攻击者可以重用截获的上下文建立令牌的范围来增强上下文建立期间提供对等实体身份验证的质量。具体而言，它们使GSS-API调用方能够将安全上下文的建立绑定到底层通信信道的相关特征（例如，地址、加密密钥的转换表示）、应用于该通信信道的保护机制以及特定于应用程序的数据。
The caller initiating a security context must determine the appropriate channel binding values to provide as input to the GSS_Init_sec_context() call, and consistent values must be provided to GSS_Accept_sec_context() by the context's target, in order for both peers' GSS-API mechanisms to validate that received tokens possess correct channel-related characteristics. Use or non-use of the GSS-API channel binding facility is a caller option. GSS-API mechanisms can operate in an environment where NULL channel bindings are presented; mechanism implementors are encouraged, but not
发起安全上下文的调用方必须确定要作为GSS_Init_sec_context（）调用的输入提供的适当通道绑定值，并且上下文的目标必须向GSS_Accept_sec_context（）提供一致的值，为了让两个对等方的GSS-API机制验证接收到的令牌是否具有正确的信道相关特征。使用或不使用GSS-API通道绑定功能是一个调用方选项。GSS-API机制可以在提供空通道绑定的环境中运行；鼓励机制实施者，但不鼓励
required, to make use of caller-provided channel binding data within their mechanisms. Callers should not assume that underlying mechanisms provide confidentiality protection for channel binding information.
必需，以便在其机制中使用调用方提供的通道绑定数据。调用者不应假定底层机制为通道绑定信息提供机密性保护。
When non-NULL channel bindings are provided by callers, certain mechanisms can offer enhanced security value by interpreting the bindings' content (rather than simply representing those bindings, or integrity check values computed on them, within tokens) and will therefore depend on presentation of specific data in a defined format. To this end, agreements among mechanism implementors are defining conventional interpretations for the contents of channel binding arguments, including address specifiers (with content dependent on communications protocol environment) for context initiators and acceptors. (These conventions are being incorporated in GSS-API mechanism specifications and into the GSS-API C language bindings specification.) In order for GSS-API callers to be portable across multiple mechanisms and achieve the full security functionality which each mechanism can provide, it is strongly recommended that GSS-API callers provide channel bindings consistent with these conventions and those of the networking environment in which they operate.
当调用者提供非空通道绑定时，某些机制可以通过解释绑定的内容（而不是简单地在令牌中表示这些绑定或在其上计算的完整性检查值）来提供增强的安全性值，因此将依赖于以定义的格式表示特定数据。为此，机制实现者之间的协议定义了通道绑定参数内容的常规解释，包括上下文启动器和接收器的地址说明符（内容取决于通信协议环境）。（这些约定被纳入GSS-API机制规范和GSS-API C语言绑定规范中。）为了使GSS-API调用者能够跨多个机制进行移植，并实现每个机制可以提供的完整安全功能，强烈建议GSS-API调用者提供与这些约定及其操作的网络环境一致的通道绑定。
1.2: GSS-API Features and Issues
1.2:GSS-API特性和问题
This section describes aspects of GSS-API operations, of the security services which the GSS-API provides, and provides commentary on design issues.
本节描述了GSS-API操作的各个方面、GSS-API提供的安全服务，并对设计问题进行了说明。
1.2.1: Status Reporting and Optional Service Support
1.2.1：状态报告和可选服务支持
1.2.1.1: Status Reporting
1.2.1.1：状态报告
Each GSS-API call provides two status return values. Major_status values provide a mechanism-independent indication of call status (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED), sufficient to drive normal control flow within the caller in a generic fashion. Table 1 summarizes the defined major_status return codes in tabular fashion.
每个GSS-API调用提供两个状态返回值。主要_状态值提供呼叫状态的独立于机制的指示（例如，GSS_S_完成、GSS_S_失败、GSS_S_继续，需要），足以以通用方式驱动调用方内的正常控制流。表1以表格形式总结了定义的主要_状态返回代码。
Sequencing-related informatory major_status codes (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN) can be indicated in conjunction with either GSS_S_COMPLETE or GSS_S_FAILURE status for GSS-API per-message calls. For context establishment calls, these sequencing-related codes will be indicated only in conjunction with GSS_S_FAILURE status (never in
与序列相关的信息主要_状态代码（GSS_S_DUPLICATE_TOKEN、GSS_OLD_TOKEN、GSS_UNSEQ_TOKEN和GSS_GAP_TOKEN）可与GSS-API每消息调用的GSS_COMPLETE或GSS_FAILURE status一起指示。对于上下文建立调用，这些与序列相关的代码将仅与GSS_S_故障状态（从不在
conjunction with GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and, therefore, always correspond to fatal failures if encountered during the context establishment phase.
与GSS_S_COMPLETE或GSS_CONTINUE_NEEDED）结合使用，因此，如果在上下文建立阶段遇到致命故障，则始终对应于致命故障。
Table 1: GSS-API Major Status Codes
表1:GSS-API主要状态代码
FATAL ERROR CODES
致命错误代码
GSS_S_BAD_BINDINGS channel binding mismatch GSS_S_BAD_MECH unsupported mechanism requested GSS_S_BAD_NAME invalid name provided GSS_S_BAD_NAMETYPE name of unsupported type provided GSS_S_BAD_STATUS invalid input status selector GSS_S_BAD_SIG token had invalid integrity check GSS_S_BAD_MIC preferred alias for GSS_S_BAD_SIG GSS_S_CONTEXT_EXPIRED specified security context expired GSS_S_CREDENTIALS_EXPIRED expired credentials detected GSS_S_DEFECTIVE_CREDENTIAL defective credential detected GSS_S_DEFECTIVE_TOKEN defective token detected GSS_S_FAILURE failure, unspecified at GSS-API level GSS_S_NO_CONTEXT no valid security context specified GSS_S_NO_CRED no valid credentials provided GSS_S_BAD_QOP unsupported QOP value GSS_S_UNAUTHORIZED operation unauthorized GSS_S_UNAVAILABLE operation unavailable GSS_S_DUPLICATE_ELEMENT duplicate credential element requested GSS_S_NAME_NOT_MN name contains multi-mechanism elements
GSS_S_BAD_绑定通道绑定不匹配GSS_BAD_机械不受支持机制请求GSS_BAD_名称无效名称提供GSS_BAD_名称类型名称不受支持类型提供GSS_BAD_状态无效输入状态选择器GSS_BAD_SIG令牌完整性检查无效GSS_S_BAD_MIC GSS_BAD_SIG首选别名GSS_BAD_上下文过期指定的安全上下文过期的GSS\U S\U凭据\U过期的凭据检测到GSS\U S\U凭据有缺陷的凭据检测到GSS\U S\U有缺陷的令牌有缺陷的令牌检测到GSS\U S\U故障，GSS-API级别未指定GSS__NO_上下文无有效安全上下文指定GSS_NO_CRED无有效凭据提供GSS_BAD_QOP不受支持的QOP值GSS_未经授权的操作未经授权的GSS_不可用的操作不可用的GSS_重复元素重复凭据元素请求的GSS_名称不包含多机构元件
INFORMATORY STATUS CODES
信息状态代码
GSS_S_COMPLETE normal completion GSS_S_CONTINUE_NEEDED continuation call to routine required GSS_S_DUPLICATE_TOKEN duplicate per-message token detected GSS_S_OLD_TOKEN timed-out per-message token detected GSS_S_UNSEQ_TOKEN reordered (early) per-message token detected GSS_S_GAP_TOKEN skipped predecessor token(s) detected
GSS_S_完成正常完成GSS_S_CONTINUE_需要继续调用例程需要的GSS_S_DUPLICATE_令牌每个消息令牌重复检测到的GSS_S_OLD_令牌每个消息令牌超时检测到的GSS_UNSEQ_令牌每个消息令牌重新排序（早期）检测到的GSS_GAP_令牌跳过了检测到的前置令牌
Minor_status provides more detailed status information which may include status codes specific to the underlying security mechanism. Minor_status values are not specified in this document.
Minor_status提供更详细的状态信息，其中可能包括特定于底层安全机制的状态代码。本文档中未指定次要_状态值。
GSS_S_CONTINUE_NEEDED major_status returns, and optional message outputs, are provided in GSS_Init_sec_context() and GSS_Accept_sec_context() calls so that different mechanisms' employment of different numbers of messages within their authentication sequences need not be reflected in separate code paths within calling applications. Instead, such cases are accommodated with sequences of continuation calls to GSS_Init_sec_context() and GSS_Accept_sec_context(). The same facility is used to encapsulate mutual authentication within the GSS-API's context initiation calls.
GSS_Init_sec_context（）和GSS_Accept_sec_context（）调用中提供了GSS_S_CONTINUE_所需的主要_状态返回和可选消息输出，因此不同机制在其身份验证序列中使用的不同数量的消息不必反映在调用应用程序的单独代码路径中。相反，这种情况是通过对GSS_Init_sec_context（）和GSS_Accept_sec_context（）的连续调用序列来适应的。相同的功能用于在GSS-API的上下文初始化调用中封装相互身份验证。
For mech_types which require interactions with third-party servers in order to establish a security context, GSS-API context establishment calls may block pending completion of such third-party interactions. On the other hand, no GSS-API calls pend on serialized interactions with GSS-API peer entities. As a result, local GSS-API status returns cannot reflect unpredictable or asynchronous exceptions occurring at remote peers, and reflection of such status information is a caller responsibility outside the GSS-API.
对于需要与第三方服务器交互以建立安全上下文的mech_类型，GSS-API上下文建立调用可能会阻止此类第三方交互的挂起完成。另一方面，没有GSS-API调用依赖于与GSS-API对等实体的序列化交互。因此，本地GSS-API状态返回不能反映远程对等点发生的不可预测或异步异常，而反映此类状态信息是GSS-API之外的调用方责任。
1.2.1.2: Optional Service Support
1.2.1.2：可选服务支持
A context initiator may request various optional services at context establishment time. Each of these services is requested by setting a flag in the req_flags input parameter to GSS_Init_sec_context().
上下文启动器可以在上下文建立时请求各种可选服务。通过将req_flags输入参数中的一个标志设置为GSS_Init_sec_context（）来请求这些服务。
The optional services currently defined are:
当前定义的可选服务包括：
- Delegation - The (usually temporary) transfer of rights from initiator to acceptor, enabling the acceptor to authenticate itself as an agent of the initiator.
- 委托-权利从发起人转移到接受人（通常是临时的），使接受人能够将自己作为发起人的代理进行身份验证。
- Mutual Authentication - In addition to the initiator authenticating its identity to the context acceptor, the context acceptor should also authenticate itself to the initiator.
- 相互身份验证-除了启动器向上下文接受者验证其身份外，上下文接受者还应向启动器验证自身身份。
- Replay detection - In addition to providing message integrity services, GSS_GetMIC() and GSS_Wrap() should include message numbering information to enable GSS_VerifyMIC() and GSS_Unwrap() to detect if a message has been duplicated.
- 回放检测-除了提供消息完整性服务外，GSS_GetMIC（）和GSS_Wrap（）还应包括消息编号信息，以使GSS_VerifyMIC（）和GSS_Unwrap（）能够检测消息是否重复。
- Out-of-sequence detection - In addition to providing message integrity services, GSS_GetMIC() and GSS_Wrap() should include message sequencing information to enable GSS_VerifyMIC() and GSS_Unwrap() to detect if a message has been received out of sequence.
- 无序检测-除了提供消息完整性服务外，GSS_GetMIC（）和GSS_Wrap（）还应包括消息序列信息，以使GSS_VerifyMIC（）和GSS_Unwrap（）能够检测消息是否被无序接收。
- Anonymous authentication - The establishment of the security context should not reveal the initiator's identity to the context acceptor.
- 匿名身份验证-安全上下文的建立不应向上下文接受者透露启动器的身份。
- Available per-message confidentiality - requests that per-message confidentiality services be available on the context.
- 每封邮件的可用机密性-请求在上下文中提供每封邮件的机密性服务。
- Available per-message integrity - requests that per-message integrity services be available on the context.
- Available per message integrity-请求在上下文中提供每消息完整性服务。
Any currently undefined bits within such flag arguments should be ignored by GSS-API implementations when presented by an application, and should be set to zero when returned to the application by the GSS-API implementation.
当GSS-API实现由应用程序呈现时，此类标志参数中当前未定义的任何位都应被GSS-API实现忽略，并且当GSS-API实现返回到应用程序时，应将其设置为零。
Some mechanisms may not support all optional services, and some mechanisms may only support some services in conjunction with others. Both GSS_Init_sec_context() and GSS_Accept_sec_context() inform the applications which services will be available from the context when the establishment phase is complete, via the ret_flags output parameter. In general, if the security mechanism is capable of providing a requested service, it should do so, even if additional services must be enabled in order to provide the requested service. If the mechanism is incapable of providing a requested service, it should proceed without the service, leaving the application to abort the context establishment process if it considers the requested service to be mandatory.
有些机制可能不支持所有可选服务，有些机制可能只支持某些服务与其他服务结合使用。GSS_Init_secu_context（）和GSS_Accept_secu_context（）都通过ret_flags输出参数通知应用程序在建立阶段完成时，哪些服务将从上下文中可用。一般来说，如果安全机制能够提供请求的服务，那么它应该这样做，即使为了提供请求的服务必须启用其他服务。如果该机制无法提供请求的服务，则应在不提供该服务的情况下继续，如果应用程序认为请求的服务是强制性的，则允许应用程序中止上下文建立过程。
Some mechanisms may specify that support for some services is optional, and that implementors of the mechanism need not provide it. This is most commonly true of the confidentiality service, often because of legal restrictions on the use of data-encryption, but may apply to any of the services. Such mechanisms are required to send at least one token from acceptor to initiator during context establishment when the initiator indicates a desire to use such a service, so that the initiating GSS-API can correctly indicate whether the service is supported by the acceptor's GSS-API.
一些机制可能指定对某些服务的支持是可选的，并且该机制的实现者不需要提供它。这在保密服务中最常见，通常是因为数据加密的使用受到法律限制，但可能适用于任何服务。当发起方表示希望使用这样的服务时，需要这样的机制在上下文建立期间从接受方向发起方发送至少一个令牌，以便发起GSS-API能够正确指示该服务是否受接受方的GSS-API支持。
1.2.2: Per-Message Security Service Availability
1.2.2：每条消息的安全服务可用性
When a context is established, two flags are returned to indicate the set of per-message protection security services which will be available on the context:
建立上下文时，将返回两个标志以指示上下文中可用的每消息保护安全服务集：
the integ_avail flag indicates whether per-message integrity and data origin authentication services are available
integ_avail标志指示是否提供每消息完整性和数据源身份验证服务
the conf_avail flag indicates whether per-message confidentiality services are available, and will never be returned TRUE unless the integ_avail flag is also returned TRUE
conf_avail标志指示每条消息的机密性服务是否可用，除非integ_avail标志也返回TRUE，否则永远不会返回TRUE
GSS-API callers desiring per-message security services should check the values of these flags at context establishment time, and must be aware that a returned FALSE value for integ_avail means that invocation of GSS_GetMIC() or GSS_Wrap() primitives on the associated context will apply no cryptographic protection to user data messages.
需要每消息安全服务的GSS-API调用方应在上下文建立时检查这些标志的值，并且必须注意，integ_avail返回的假值意味着在关联上下文上调用GSS_GetMIC（）或GSS_Wrap（）原语将不对用户数据消息应用加密保护。
The GSS-API per-message integrity and data origin authentication services provide assurance to a receiving caller that protection was applied to a message by the caller's peer on the security context, corresponding to the entity named at context initiation. The GSS-API per-message confidentiality service provides assurance to a sending caller that the message's content is protected from access by entities other than the context's named peer.
GSS-API每消息完整性和数据源身份验证服务向接收调用者提供保证，即调用者的对等方在安全上下文上对消息应用了保护，对应于上下文启动时命名的实体。GSS-API每消息机密性服务向发送调用方提供保证，即消息的内容受到保护，不被上下文的命名对等方以外的实体访问。
The GSS-API per-message protection service primitives, as the category name implies, are oriented to operation at the granularity of protocol data units. They perform cryptographic operations on the data units, transfer cryptographic control information in tokens, and, in the case of GSS_Wrap(), encapsulate the protected data unit. As such, these primitives are not oriented to efficient data protection for stream-paradigm protocols (e.g., Telnet) if cryptography must be applied on an octet-by-octet basis.
正如类别名称所示，GSS-API每消息保护服务原语面向协议数据单元粒度的操作。它们对数据单元执行加密操作，在令牌中传输加密控制信息，在GSS_Wrap（）的情况下，封装受保护的数据单元。因此，如果必须以八位字节为基础应用加密技术，则这些原语不适用于流范型协议（例如Telnet）的有效数据保护。
1.2.3: Per-Message Replay Detection and Sequencing
1.2.3：每条消息的重播检测和排序
Certain underlying mech_types offer support for replay detection and/or sequencing of messages transferred on the contexts they support. These optionally-selectable protection features are distinct from replay detection and sequencing features applied to the context establishment operation itself; the presence or absence of context-level replay or sequencing features is wholly a function of the underlying mech_type's capabilities, and is not selected or omitted as a caller option.
某些底层mech_类型支持重播检测和/或对在其支持的上下文中传输的消息进行排序。这些可选的保护特性不同于应用于上下文建立操作本身的重播检测和排序特性；上下文级重播或排序功能的存在或不存在完全取决于基础mech_类型的功能，不作为调用方选项选择或省略。
The caller initiating a context provides flags (replay_det_req_flag and sequence_req_flag) to specify whether the use of per-message replay detection and sequencing features is desired on the context being established. The GSS-API implementation at the initiator system can determine whether these features are supported (and whether they are optionally selectable) as a function of the selected mechanism, without need for bilateral negotiation with the target. When enabled, these features provide recipients with indicators as a result of GSS-API processing of incoming messages, identifying whether those messages were detected as duplicates or out-of-sequence. Detection of
发起上下文的调用方提供标志（replay_det_req_标志和sequence_req_标志），以指定是否需要在正在建立的上下文上使用每条消息的replay检测和排序功能。发起方系统上的GSS-API实现可以确定这些功能是否受支持（以及它们是否可选），作为所选机制的一个功能，而无需与目标方进行双边协商。启用后，这些功能将为收件人提供GSS-API处理传入消息的结果指标，以识别这些消息是否被检测为重复消息或顺序错误。检测
such events does not prevent a suspect message from being provided to a recipient; the appropriate course of action on a suspect message is a matter of caller policy.
此类事件不会阻止向收件人提供可疑邮件；对可疑消息的适当操作过程取决于呼叫方策略。
The semantics of the replay detection and sequencing services applied to received messages, as visible across the interface which the GSS-API provides to its clients, are as follows:
应用于接收到的消息的重播检测和排序服务的语义（通过GSS-API提供给其客户端的接口可见）如下所示：
When replay_det_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
当replay_det_state为TRUE时，格式正确且签名正确的消息可能返回的主要_状态如下：
1. GSS_S_COMPLETE, without concurrent indication of GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN, indicates that the message was within the window (of time or sequence space) allowing replay events to be detected, and that the message was not a replay of a previously-processed message within that window.
1. GSS_S_COMPLETE（GSS_S_DUPLICATE_TOKEN或GSS_OLD_TOKEN未同时指示）表示消息在允许检测重播事件的窗口（时间或序列空间）内，并且该消息不是该窗口内先前处理的消息的重播。
2. GSS_S_DUPLICATE_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that the message was recognized as a duplicate of a previously-processed message. In addition to identifying duplicated tokens originated by a context's peer, this status may also be used to identify reflected copies of locally-generated tokens; it is recommended that mechanism designers include within their protocols facilities to detect and report such tokens.
2. GSS_S_DUPLICATE_令牌表示接收到的消息上的加密校验值正确，但该消息被识别为先前处理的消息的副本。除了识别由上下文对等方发起的重复令牌外，该状态还可用于识别本地生成令牌的反映副本；建议机制设计者在其协议中包括检测和报告此类令牌的设施。
3. GSS_S_OLD_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that the message is too old to be checked for duplication.
3. GSS_S_OLD_令牌表示接收到的消息上的加密检查值是正确的，但消息太旧，无法进行重复检查。
When sequence_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
当sequence_state为TRUE时，格式正确且签名正确的消息可能返回的MAJURE_状态如下：
1. GSS_S_COMPLETE, without concurrent indication of GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_GAP_TOKEN, indicates that the message was within the window (of time or sequence space) allowing replay events to be detected, that the message was not a replay of a previously-processed message within that window, and that no predecessor sequenced messages are missing relative to the last received message (if any) processed on the context with a correct cryptographic checkvalue.
1. GSS_S_COMPLETE，不同时指示GSS_S_DUPLICATE_TOKEN、GSS_S_OLD_TOKEN、GSS_UNSEQ_TOKEN或GSS_GAP_TOKEN的GSS_S_COMPLETE，表示消息在允许检测重播事件的窗口（时间或序列空间）内，消息不是该窗口内先前处理的消息的重播，并且相对于在具有正确加密校验值的上下文上处理的最后接收的消息（如果有），没有缺少前置序列消息。
2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value on the received message was correct, but that the message was recognized as a duplicate of a previously-processed message. In addition to identifying duplicated tokens originated by a context's peer, this status may also be used to identify reflected
2. GSS_S_DUPLICATE_令牌表示接收到的消息上的完整性检查值正确，但该消息被识别为先前处理的消息的副本。除了识别由上下文对等方发起的重复令牌外，此状态还可用于识别反射的令牌
copies of locally-generated tokens; it is recommended that mechanism designers include within their protocols facilities to detect and report such tokens.
本地生成令牌的副本；建议机制设计者在其协议中包括检测和报告此类令牌的设施。
3. GSS_S_OLD_TOKEN indicates that the integrity check value on the received message was correct, but that the token is too old to be checked for duplication.
3. GSS_S_OLD_令牌表示接收到的消息上的完整性检查值是正确的，但令牌太旧，无法进行重复检查。
4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that it is earlier in a sequenced stream than a message already processed on the context. [Note: Mechanisms can be architected to provide a stricter form of sequencing service, delivering particular messages to recipients only after all predecessor messages in an ordered stream have been delivered. This type of support is incompatible with the GSS-API paradigm in which recipients receive all messages, whether in order or not, and provide them (one at a time, without intra-GSS-API message buffering) to GSS-API routines for validation. GSS-API facilities provide supportive functions, aiding clients to achieve strict message stream integrity in an efficient manner in conjunction with sequencing provisions in communications protocols, but the GSS-API does not offer this level of message stream integrity service by itself.]
4. GSS_S_UNSEQ_令牌表示接收到的消息上的加密校验值是正确的，但它在序列流中的时间早于已在上下文中处理的消息。[注意：机制的架构可以提供更严格的排序服务形式，只有在有序流中的所有前置消息都已交付之后，才能将特定消息交付给收件人。这种类型的支持与GSS-API范例不兼容，在GSS-API范例中，收件人接收所有消息，无论是否有序，并提供对其进行反编译（一次一个，无GSS API内部消息缓冲）GSS-API设施提供支持性功能，帮助客户端结合通信协议中的排序规定，以高效的方式实现严格的消息流完整性，但GSS-API本身不提供这种级别的消息流完整性服务。]
5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that one or more predecessor sequenced messages have not been successfully processed relative to the last received message (if any) processed on the context with a correct cryptographic checkvalue.
5. GSS_S_GAP_令牌表示接收到的消息上的加密校验值是正确的，但相对于在上下文上处理的具有正确加密校验值的上一个接收到的消息（如果有），尚未成功处理一个或多个前置序列消息。
As the message stream integrity features (especially sequencing) may interfere with certain applications' intended communications paradigms, and since support for such features is likely to be resource intensive, it is highly recommended that mech_types supporting these features allow them to be activated selectively on initiator request when a context is established. A context initiator and target are provided with corresponding indicators (replay_det_state and sequence_state), signifying whether these features are active on a given context.
由于消息流完整性特征（尤其是排序）可能会干扰某些应用程序的预期通信模式，并且由于对此类特征的支持可能是资源密集型的，强烈建议支持这些功能的mech_类型允许在建立上下文时根据启动器请求选择性地激活它们。上下文启动器和目标都提供了相应的指示符（replay_det_state和sequence_state），表示这些功能在给定上下文中是否处于活动状态。
An example mech_type supporting per-message replay detection could (when replay_det_state is TRUE) implement the feature as follows: The underlying mechanism would insert timestamps in data elements output by GSS_GetMIC() and GSS_Wrap(), and would maintain (within a time-limited window) a cache (qualified by originator-recipient pair) identifying received data elements processed by GSS_VerifyMIC() and GSS_Unwrap(). When this feature is active, exception status returns (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when
支持每条消息重播检测的示例mech_类型可以（当重播状态为TRUE时）实现如下功能：底层机制将在GSS_GetMIC（）和GSS_Wrap（）输出的数据元素中插入时间戳，并将（在时间限制窗口内）维护缓存（由发起者-接收者对限定）识别GSS_VerifyMIC（）和GSS_Unwrap（）处理的接收数据元素。当此功能处于活动状态时，将在以下情况下提供异常状态返回（GSS\U S\U DUPLICATE\U TOKEN、GSS\U S\U OLD\U TOKEN）
GSS_VerifyMIC() or GSS_Unwrap() is presented with a message which is either a detected duplicate of a prior message or which is too old to validate against a cache of recently received messages.
GSS_VerifyMIC（）或GSS_Unwrap（）会显示一条消息，该消息可能是检测到的先前消息的副本，或者太旧，无法根据最近接收的消息缓存进行验证。
1.2.4: Quality of Protection
1.2.4：保护质量
Some mech_types provide their users with fine granularity control over the means used to provide per-message protection, allowing callers to trade off security processing overhead dynamically against the protection requirements of particular messages. A per-message quality-of-protection parameter (analogous to quality-of-service, or QOS) selects among different QOP options supported by that mechanism. On context establishment for a multi-QOP mech_type, context-level data provides the prerequisite data for a range of protection qualities.
某些mech_类型为其用户提供了对用于提供每条消息保护的方法的细粒度控制，允许调用者根据特定消息的保护要求动态权衡安全处理开销。每个消息的保护质量参数（类似于服务质量或QOS）在该机制支持的不同QOP选项中进行选择。在为多QOP机械类型建立上下文时，上下文级数据为一系列保护质量提供了前提数据。
It is expected that the majority of callers will not wish to exert explicit mechanism-specific QOP control and will therefore request selection of a default QOP. Definitions of, and choices among, non-default QOP values are mechanism-specific, and no ordered sequences of QOP values can be assumed equivalent across different mechanisms. Meaningful use of non-default QOP values demands that callers be familiar with the QOP definitions of an underlying mechanism or mechanisms, and is therefore a non-portable construct. The GSS_S_BAD_QOP major_status value is defined in order to indicate that a provided QOP value is unsupported for a security context, most likely because that value is unrecognized by the underlying mechanism.
预计大多数调用者不希望施加明确的机制特定的QOP控制，因此将请求选择默认QOP。非默认QOP值的定义和选择是特定于机制的，并且不能假设QOP值的有序序列在不同机制中是等效的。非默认QOP值的有意义使用要求调用方熟悉底层机制的QOP定义，因此是不可移植的构造。定义GSS_S_BAD_QOP major_status值是为了指示安全上下文不支持提供的QOP值，很可能是因为该值无法被底层机制识别。
In the interests of interoperability, mechanisms which allow optional support of particular QOP values shall satisfy one of the following conditions. Either:
为了实现互操作性，允许可选支持特定QOP值的机制应满足以下条件之一。要么：
(i) All implementations of the mechanism are required to be capable of processing messages protected using any QOP value, regardless of whether they can apply protection corresponding to that QOP, or
(i) 该机制的所有实现都需要能够处理使用任何QOP值保护的消息，无论它们是否可以应用与该QOP对应的保护，或者
(ii) The set of mutually-supported receiver QOP values must be determined during context establishment, and messages may be protected by either peer using only QOP values from this mutually-supported set.
（ii）必须在上下文建立期间确定相互支持的接收器QOP值的集合，并且消息可由任一对等方仅使用来自该相互支持集合的QOP值来保护。
NOTE: (i) is just a special-case of (ii), where implementations are required to support all QOP values on receipt.
注：（i）只是（ii）的一个特例，其中要求实现在接收时支持所有QOP值。
1.2.5: Anonymity Support
1.2.5：匿名支持
In certain situations or environments, an application may wish to authenticate a peer and/or protect communications using GSS-API per-message services without revealing its own identity. For example, consider an application which provides read access to a research database, and which permits queries by arbitrary requestors. A client of such a service might wish to authenticate the service, to establish trust in the information received from it, but might not wish to disclose its identity to the service for privacy reasons.
在某些情况或环境中，应用程序可能希望使用GSS-API每消息服务对对等方进行身份验证和/或保护通信，而不暴露其自身身份。例如，考虑一个应用程序，它提供对研究数据库的读取访问，并允许任意请求者查询。此类服务的客户可能希望验证该服务，以建立对从其接收的信息的信任，但出于隐私原因，可能不希望向该服务披露其身份。
In ordinary GSS-API usage, a context initiator's identity is made available to the context acceptor as part of the context establishment process. To provide for anonymity support, a facility (input anon_req_flag to GSS_Init_sec_context()) is provided through which context initiators may request that their identity not be provided to the context acceptor. Mechanisms are not required to honor this request, but a caller will be informed (via returned anon_state indicator from GSS_Init_sec_context()) whether or not the request is honored. Note that authentication as the anonymous principal does not necessarily imply that credentials are not required in order to establish a context.
在一般的GSS-API使用中，作为上下文建立过程的一部分，上下文发起方的标识可供上下文接受者使用。为了提供匿名性支持，提供了一个工具（向GSS_Init_sec_context（）输入anon_req_标志），通过该工具，上下文启动器可以请求不向上下文接受者提供其身份。执行此请求不需要机制，但会通知调用方（通过GSS_Init_sec_context（）返回的一个非状态指示器）请求是否被执行。请注意，作为匿名主体的身份验证并不一定意味着建立上下文不需要凭据。
Section 4.5 of this document defines the Object Identifier value used to identify an anonymous principal.
本文件第4.5节定义了用于标识匿名主体的对象标识符值。
Four possible combinations of anon_state and mutual_state are possible, with the following results:
失谐状态和互谐状态有四种可能的组合，结果如下：
anon_state == FALSE, mutual_state == FALSE: initiator authenticated to target.
anon_状态==FALSE，相互_状态==FALSE：启动器已通过目标身份验证。
anon_state == FALSE, mutual_state == TRUE: initiator authenticated to target, target authenticated to initiator.
anon_state==FALSE，mutual_state==TRUE：启动器已通过目标身份验证，目标已通过启动器身份验证。
anon_state == TRUE, mutual_state == FALSE: initiator authenticated as anonymous principal to target.
anon_state==TRUE，mutual_state==FALSE：启动器作为匿名主体身份验证到目标。
anon_state == TRUE, mutual_state == TRUE: initiator authenticated as anonymous principal to target, target authenticated to initiator.
anon_state==TRUE，mutual_state==TRUE：启动器作为匿名主体身份验证给目标，目标身份验证给启动器。
1.2.6: Initialization
1.2.6：初始化
No initialization calls (i.e., calls which must be invoked prior to invocation of other facilities in the interface) are defined in GSS-API. As an implication of this fact, GSS-API implementations must themselves be self-initializing.
GSS-API中未定义初始化调用（即，在调用接口中的其他设施之前必须调用的调用）。这意味着，GSS-API实现本身必须是自初始化的。
1.2.7: Per-Message Protection During Context Establishment
1.2.7：上下文建立期间的每条消息保护
A facility is defined in GSS-V2 to enable protection and buffering of data messages for later transfer while a security context's establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases where the caller side already possesses the necessary session key to enable this processing. Specifically, a new state Boolean, called prot_ready_state, is added to the set of information returned by GSS_Init_sec_context(), GSS_Accept_sec_context(), and GSS_Inquire_context().
GSS-V2中定义了一种功能，用于在安全上下文的建立处于GSS_s_CONTINUE_NEEDED状态时保护和缓冲数据消息，以便在调用方已经拥有必要的会话密钥以启用此处理的情况下使用。具体来说，一个新的状态布尔值，称为prot_ready_state，被添加到GSS_Init_sec_context（）、GSS_Accept_sec_context（）和GSS_Inquire_context（）返回的信息集中。
For context establishment calls, this state Boolean is valid and interpretable when the associated major_status is either GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both initiators and acceptors) can assume that per-message protection (via GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is available and ready for use if either: prot_ready_state == TRUE, or major_status == GSS_S_COMPLETE, though mutual authentication (if requested) cannot be guaranteed until GSS_S_COMPLETE is returned. Callers making use of per-message protection services in advance of GSS_S_COMPLETE status should be aware of the possibility that a subsequent context establishment step may fail, and that certain context data (e.g., mech_type) as returned for subsequent calls may change.
对于上下文建立调用，当关联的主要_状态为GSS_S_CONTINUE_NEEDED或GSS_S_COMPLETE时，此状态布尔值有效且可解释。GSS-API的调用者（启动器和接受者）可以假设每个消息的保护（通过GSS_Wrap（）、GSS_Unwrap（）、GSS_GetMIC（）和GSS_VerifyMIC（））是可用的，并且可以在以下情况下使用：prot_ready_state==TRUE，或者major_status==GSS_COMPLETE，尽管相互验证（如果请求的话）在返回GSS_S_COMPLETE之前无法保证。在GSS__完成状态之前使用每条消息保护服务的呼叫者应意识到后续上下文建立步骤可能会失败，并且为后续呼叫返回的某些上下文数据（例如，mech_类型）可能会更改。
This approach achieves full, transparent backward compatibility for GSS-API V1 callers, who need not even know of the existence of prot_ready_state, and who will get the expected behavior from GSS_S_COMPLETE, but who will not be able to use per-message protection before GSS_S_COMPLETE is returned.
这种方法为GSS-API V1调用者实现了完全、透明的向后兼容性，这些调用者甚至不需要知道prot_ready_状态的存在，他们将从GSS_S_COMPLETE获得预期的行为，但在返回GSS_S_COMPLETE之前将无法使用每消息保护。
It is not a requirement that GSS-V2 mechanisms ever return TRUE prot_ready_state before completion of context establishment (indeed, some mechanisms will not evolve usable message protection keys, especially at the context acceptor, before context establishment is complete). It is expected but not required that GSS-V2 mechanisms will return TRUE prot_ready_state upon completion of context establishment if they support per-message protection at all (however GSS-V2 applications should not assume that TRUE prot_ready_state will always be returned together with the GSS_S_COMPLETE major_status, since GSS-V2 implementations may continue to support GSS-V1 mechanism code, which will never return TRUE prot_ready_state).
GSS-V2机制不要求在完成上下文建立之前返回真正的prot_ready_状态（事实上，某些机制在上下文建立完成之前不会演化出可用的消息保护密钥，特别是在上下文接受者处）。如果GSS-V2机制完全支持每消息保护，则在完成上下文建立后，GSS-V2机制将返回真正的prot_ready_状态，这是预期的，但不是必需的（但是，GSS-V2应用程序不应假定真正的prot_ready_状态将始终与GSS_完成主要_状态一起返回，因为GSS-V2实现可能会继续支持GSS-V1机制代码，该代码永远不会返回真正的prot_ready_状态）。
When prot_ready_state is returned TRUE, mechanisms shall also set those context service indicator flags (deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, conf_avail, integ_avail) which represent facilities confirmed, at that time, to be available on the context being established. In
当prot_ready_state返回TRUE时，机制还应设置上下文服务指示符标志（deleg_state、mutual_state、replay_det_state、sequence_state、anon_state、trans_state、conf_avail、integ_avail），这些标志表示当时已确认可用于建立上下文的设施。在里面
situations where prot_ready_state is returned before GSS_S_COMPLETE, it is possible that additional facilities may be confirmed and subsequently indicated when GSS_S_COMPLETE is returned.
如果在GSS__完成之前返回保护就绪状态，则可能会在GSS__完成时确认并随后指示其他设施。
1.2.8: Implementation Robustness
1.2.8：实施稳健性
This section recommends aspects of GSS-API implementation behavior in the interests of overall robustness.
本节从整体健壮性的角度介绍GSS-API实现行为的各个方面。
Invocation of GSS-API calls is to incur no undocumented side effects visible at the GSS-API level.
调用GSS-API调用不会产生在GSS-API级别可见的未记录的副作用。
If a token is presented for processing on a GSS-API security context and that token generates a fatal error in processing or is otherwise determined to be invalid for that context, the context's state should not be disrupted for purposes of processing subsequent valid tokens.
如果在GSS-API安全上下文上显示令牌以进行处理，并且该令牌在处理过程中产生致命错误，或者被确定为对该上下文无效，则不应为了处理后续有效令牌而中断该上下文的状态。
Certain local conditions at a GSS-API implementation (e.g., unavailability of memory) may preclude, temporarily or permanently, the successful processing of tokens on a GSS-API security context, typically generating GSS_S_FAILURE major_status returns along with locally-significant minor_status. For robust operation under such conditions, the following recommendations are made:
GSS-API实现中的某些局部条件（例如，内存不可用）可能暂时或永久地妨碍在GSS-API安全上下文上成功处理令牌，通常生成GSS-API故障主要状态返回以及局部重要次要状态。为在此类条件下实现稳健运行，建议如下：
Failing calls should free any memory they allocate, so that callers may retry without causing further loss of resources.
失败的呼叫应释放其分配的所有内存，以便呼叫者可以重试，而不会造成进一步的资源损失。
Failure of an individual call on an established context should not preclude subsequent calls from succeeding on the same context.
单个调用在已建立上下文上失败不应妨碍后续调用在同一上下文上成功。
Whenever possible, it should be possible for GSS_Delete_sec_context() calls to be successfully processed even if other calls cannot succeed, thereby enabling context-related resources to be released.
只要有可能，即使其他调用无法成功，GSS_Delete_sec_context（）调用也应该能够成功处理，从而释放与上下文相关的资源。
A failure of GSS_GetMIC() or GSS_Wrap() due to an attempt to use an unsupported QOP will not interfere with context validity, nor shall such a failure impact the ability of the application to subsequently invoke GSS_GetMIC() or GSS_Wrap() using a supported QOP. Any state information concerning sequencing of outgoing messages shall be unchanged by an unsuccessful call of GSS_GetMIC() or GSS_Wrap().
由于尝试使用不支持的QOP而导致GSS_GetMIC（）或GSS_Wrap（）失败不会干扰上下文有效性，也不会影响应用程序随后使用支持的QOP调用GSS_GetMIC（）或GSS_Wrap（）的能力。任何关于传出消息顺序的状态信息都应通过调用GSS_GetMIC（）或GSS_Wrap（）失败而保持不变。
1.2.9: Delegation
1.2.9：授权
The GSS-API allows delegation to be controlled by the initiating application via a Boolean parameter to GSS_Init_sec_context(), the routine that establishes a security context. Some mechanisms do not support delegation, and for such mechanisms attempts by an application to enable delegation are ignored.
GSS-API允许启动应用程序通过一个布尔参数控制对GSS_Init_sec_context（）的委托，GSS_Init_sec_context（）是建立安全上下文的例程。有些机制不支持委托，对于这种机制，应用程序启用委托的尝试将被忽略。
The acceptor of a security context for which the initiator enabled delegation will receive (via the delegated_cred_handle parameter of GSS_Accept_sec_context()) a credential handle that contains the delegated identity, and this credential handle may be used to initiate subsequent GSS-API security contexts as an agent or delegate of the initiator. If the original initiator's identity is "A" and the delegate's identity is "B", then, depending on the underlying mechanism, the identity embodied by the delegated credential may be either "A" or "B acting for A".
安全上下文的接受者，启用启动器的委派将（通过GSS_Accept_sec_context（）的delegated_cred_handle参数）接收包含委派标识的凭证句柄，此凭证句柄可用于作为启动器的代理或委派启动后续GSS-API安全上下文。如果原始发起人的身份是“A”，而委托人的身份是“B”，则根据基础机制，委托凭证体现的身份可以是“A”或“代表A的B”。
For many mechanisms that support delegation, a simple Boolean does not provide enough control. Examples of additional aspects of delegation control that a mechanism might provide to an application are duration of delegation, network addresses from which delegation is valid, and constraints on the tasks that may be performed by a delegate. Such controls are presently outside the scope of the GSS-API. GSS-API implementations supporting mechanisms offering additional controls should provide extension routines that allow these controls to be exercised (perhaps by modifying the initiator's GSS-API credential prior to its use in establishing a context). However, the simple delegation control provided by GSS-API should always be able to over-ride other mechanism-specific delegation controls; if the application instructs GSS_Init_sec_context() that delegation is not desired, then the implementation must not permit delegation to occur. This is an exception to the general rule that a mechanism may enable services even if they are not requested; delegation may only be provided at the explicit request of the application.
对于许多支持委托的机制，简单的布尔值不能提供足够的控制。机制可能向应用程序提供的委托控制的其他方面的示例包括委托持续时间、委托有效的网络地址以及委托可能执行的任务的约束。此类控制目前不在GSS-API的范围内。支持提供附加控件的机制的GSS-API实现应提供允许执行这些控件的扩展例程（可能是通过在使用发起程序的GSS-API凭据建立上下文之前修改它）。然而，GSS-API提供的简单委托控制应始终能够超越其他机制特定的委托控制；如果应用程序指示GSS_Init_sec_context（）不需要委派，则实现不得允许委派发生。这是一般规则的例外，即即使未请求服务，机制也可以启用服务；授权只能在申请明确要求时提供。
1.2.10: Interprocess Context Transfer
1.2.10：进程间上下文传输
GSS-API V2 provides routines (GSS_Export_sec_context() and GSS_Import_sec_context()) which allow a security context to be transferred between processes on a single machine. The most common use for such a feature is a client-server design where the server is implemented as a single process that accepts incoming security contexts, which then launches child processes to deal with the data on these contexts. In such a design, the child processes must have access to the security context data structure created within the
GSS-API V2提供例程（GSS_导出_sec_context（）和GSS_导入_sec_context（）），允许在一台机器上的进程之间传输安全上下文。这种特性最常见的用途是客户机-服务器设计，其中服务器被实现为单个进程，该进程接受传入的安全上下文，然后启动子进程来处理这些上下文中的数据。在这种设计中，子进程必须能够访问在中创建的安全上下文数据结构
parent by its call to GSS_Accept_sec_context() so that they can use per-message protection services and delete the security context when the communication session ends.
通过对GSS_Accept_sec_context（）的调用创建父对象，以便它们可以使用每条消息保护服务，并在通信会话结束时删除安全上下文。
Since the security context data structure is expected to contain sequencing information, it is impractical in general to share a context between processes. Thus GSS-API provides a call (GSS_Export_sec_context()) that the process which currently owns the context can call to declare that it has no intention to use the context subsequently, and to create an inter-process token containing information needed by the adopting process to successfully import the context. After successful completion of this call, the original security context is made inaccessible to the calling process by GSS-API, and any context handles referring to this context are no longer valid. The originating process transfers the inter-process token to the adopting process, which passes it to GSS_Import_sec_context(), and a fresh context handle is created such that it is functionally identical to the original context.
由于安全上下文数据结构预期包含排序信息，因此在进程之间共享上下文通常是不切实际的。因此，GSS-API提供了一个调用（GSS_Export_sec_context（）），当前拥有该上下文的进程可以调用该调用来声明它无意随后使用该上下文，并创建一个进程间令牌，该令牌包含采用进程成功导入上下文所需的信息。成功完成此调用后，GSS-API将使调用进程无法访问原始安全上下文，并且引用此上下文的任何上下文句柄都不再有效。发起进程将进程间令牌传输给采用进程，采用进程将其传递给GSS_Import_sec_context（），并创建一个新的上下文句柄，使其功能与原始上下文相同。
The inter-process token may contain sensitive data from the original security context (including cryptographic keys). Applications using inter-process tokens to transfer security contexts must take appropriate steps to protect these tokens in transit. Implementations are not required to support the inter-process transfer of security contexts. The ability to transfer a security context is indicated when the context is created, by GSS_Init_sec_context() or GSS_Accept_sec_context() indicating a TRUE trans_state return value.
进程间令牌可能包含来自原始安全上下文（包括加密密钥）的敏感数据。使用进程间令牌传输安全上下文的应用程序必须采取适当的步骤来保护传输中的这些令牌。实现不需要支持安全上下文的进程间传输。在创建上下文时，通过GSS_Init_sec_context（）或GSS_Accept_sec_context（）指示真正的trans_状态返回值来指示传输安全上下文的能力。
2: Interface Descriptions
2：接口说明
This section describes the GSS-API's service interface, dividing the set of calls offered into four groups. Credential management calls are related to the acquisition and release of credentials by principals. Context-level calls are related to the management of security contexts between principals. Per-message calls are related to the protection of individual messages on established security contexts. Support calls provide ancillary functions useful to GSS-API callers. Table 2 groups and summarizes the calls in tabular fashion.
本节描述GSS-API的服务接口，将提供的调用集分为四个组。凭据管理调用与主体获取和释放凭据相关。上下文级调用与主体之间安全上下文的管理相关。每消息调用与在已建立的安全上下文中保护单个消息有关。支持调用提供对GSS-API调用方有用的辅助函数。表2以表格形式对调用进行分组和总结。
Table 2: GSS-API Calls
表2:GSS-API调用
CREDENTIAL MANAGEMENT
凭证管理
GSS_Acquire_cred acquire credentials for use GSS_Release_cred release credentials after use GSS_Inquire_cred display information about credentials
GSS\u获取\u凭据获取使用凭据GSS\u发布\u凭据使用后发布凭据GSS\u查询\u凭据显示有关凭据的信息
GSS_Add_cred construct credentials incrementally GSS_Inquire_cred_by_mech display per-mechanism credential information
GSS\u添加\u凭据构造凭据增量GSS\u查询\u凭据由\u机械显示每个机制凭据信息
CONTEXT-LEVEL CALLS
上下文级调用
GSS_Init_sec_context initiate outbound security context GSS_Accept_sec_context accept inbound security context GSS_Delete_sec_context flush context when no longer needed GSS_Process_context_token process received control token on context GSS_Context_time indicate validity time remaining on context GSS_Inquire_context display information about context GSS_Wrap_size_limit determine GSS_Wrap token size limit GSS_Export_sec_context transfer context to other process GSS_Import_sec_context import transferred context
GSS_Init_sec_context initiate outbound security context GSS_Accept_sec_context Accept inbound security context GSS_Delete_sec_context flush context不再需要时GSS_Process_context_token Process接收到上下文上的控制令牌GSS_context_time指示上下文上剩余的有效时间GSS_Inquire_context显示有关的信息上下文GSS_包装_大小_限制确定GSS_包装令牌大小限制GSS_导出_秒_上下文传输上下文到其他进程GSS_导入_秒_上下文导入传输上下文
PER-MESSAGE CALLS
按消息呼叫
GSS_GetMIC apply integrity check, receive as token separate from message GSS_VerifyMIC validate integrity check token along with message GSS_Wrap sign, optionally encrypt, encapsulate GSS_Unwrap decapsulate, decrypt if needed, validate integrity check
GSS_GetMIC应用完整性检查，作为令牌接收，与消息GSS_VerifyMIC validate integrity check令牌和消息GSS_Wrap sign分开，可选加密、封装GSS_Unwrap decapsulate，必要时解密、验证完整性检查
SUPPORT CALLS
支援电话
GSS_Display_status translate status codes to printable form GSS_Indicate_mechs indicate mech_types supported on local system GSS_Compare_name compare two names for equality GSS_Display_name translate name to printable form GSS_Import_name convert printable name to normalized form GSS_Release_name free storage of normalized-form name GSS_Release_buffer free storage of general GSS-allocated object GSS_Release_OID_set free storage of OID set object GSS_Create_empty_OID_set create empty OID set GSS_Add_OID_set_member add member to OID set GSS_Test_OID_set_member test if OID is member of OID set GSS_Inquire_names_for_mech indicate name types supported by
GSS\u显示\u状态代码转换为可打印表单GSS\u指示\u机械指示本地系统支持的机械类型GSS\u比较\u名称比较两个名称是否相等GSS\u显示\u名称转换名称为可打印表单GSS\u导入\u名称将可打印名称转换为规范化表单GSS\u发布\u名称规范化表单名称的自由存储GSS_释放_常规GSS分配对象的无缓冲区存储GSS_释放_OID_设置OID集对象的自由存储GSS_创建_空_OID_集创建空OID集GSS_添加_OID_集成员添加成员到OID集GSS_测试_OID_集成员测试如果OID是OID集的成员GSS_查询\u名称\u为\u机制指示支持的名称类型
mechanism GSS_Inquire_mechs_for_name indicates mechanisms supporting name type GSS_Canonicalize_name translate name to per-mechanism form GSS_Export_name externalize per-mechanism name GSS_Duplicate_name duplicate name object
机制GSS\U Inquire\U mechs\U for\U name表示支持名称类型GSS\U规范化\U name将名称转换为每个机制表单GSS\U导出\U name外部化每个机制名称GSS\U重复\U name重复名称对象
2.1: Credential management calls
2.1：凭证管理呼叫
These GSS-API calls provide functions related to the management of credentials. Their characterization with regard to whether or not they may block pending exchanges with other network entities (e.g., directories or authentication servers) depends in part on OS-specific (extra-GSS-API) issues, so is not specified in this document.
这些GSS-API调用提供与凭据管理相关的函数。它们是否会阻止与其他网络实体（如目录或身份验证服务器）的未决交换，部分取决于特定于操作系统（额外GSS API）的问题，因此本文档中未规定。
The GSS_Acquire_cred() call is defined within the GSS-API in support of application portability, with a particular orientation towards support of portable server applications. It is recognized that (for certain systems and mechanisms) credentials for interactive users may be managed differently from credentials for server processes; in such environments, it is the GSS-API implementation's responsibility to distinguish these cases and the procedures for making this distinction are a local matter. The GSS_Release_cred() call provides a means for callers to indicate to the GSS-API that use of a credentials structure is no longer required. The GSS_Inquire_cred() call allows callers to determine information about a credentials structure. The GSS_Add_cred() call enables callers to append elements to an existing credential structure, allowing iterative construction of a multi-mechanism credential. The GSS_Inquire_cred_by_mech() call enables callers to extract per-mechanism information describing a credentials structure.
GSS_Acquire_cred（）调用是在GSS-API中定义的，用于支持应用程序的可移植性，特别是面向支持可移植服务器应用程序。人们认识到，（对于某些系统和机制）交互用户的凭据的管理可能不同于服务器进程的凭据；在这种环境中，GSS-API实施部门有责任区分这些情况，而进行区分的程序是本地事务。GSS_Release_cred（）调用为调用者提供了一种方法，可以向GSS-API指示不再需要使用凭据结构。GSS_Inquire_cred（）调用允许调用方确定有关凭据结构的信息。GSS_Add_cred（）调用允许调用方将元素附加到现有凭证结构中，从而允许迭代构造多机制凭证。GSS_Inquire_cred_by_mech（）调用使调用方能够提取描述凭证结构的每个机制的信息。
2.1.1: GSS_Acquire_cred call
2.1.1:GSS_Acquire_cred call
Inputs:
投入：
o desired_name INTERNAL NAME, -- NULL requests locally-determined -- default
o 所需的\u name内部名称，-本地确定的NULL请求--默认值
o lifetime_req INTEGER, -- in seconds; 0 requests default
o 生存期_req整数，以秒为单位；默认为0个请求
o desired_mechs SET OF OBJECT IDENTIFIER, -- NULL requests -- system-selected default
o 所需的对象标识符集，-NULL请求--系统选择的默认值
o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_用法整数--0=INITIATE-AND-ACCEPT，1=INITIATE-ONLY，--2=ACCEPT-ONLY
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL, -- caller must release with GSS_Release_cred()
o output_cred_handle凭证句柄，--如果返回非NULL，--调用方必须使用GSS_release_cred（）释放
o actual_mechs SET OF OBJECT IDENTIFIER, -- if returned non-NULL, -- caller must release with GSS_Release_oid_set()
o 对象标识符的实际\u mechs集，-如果返回非NULL，-调用方必须使用GSS\u release\u oid\u SET（）释放
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec INTEGER--以秒为单位，或保留值--不确定
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that requested credentials were successfully established, for the duration indicated in lifetime_rec, suitable for the usage requested in cred_usage, for the set of mech_types indicated in actual_mechs, and that those credentials can be referenced for subsequent use with the handle returned in output_cred_handle.
o GSS_S_COMPLETE表示请求的凭据已成功建立，持续时间在lifetime_rec中指示，适用于cred_usage中请求的使用，适用于实际_mech中指示的一组mech_类型，并且这些凭据可被引用以供后续使用，句柄在output_cred_handle中返回。
o GSS_S_BAD_MECH indicates that a mech_type unsupported by the GSS-API implementation type was requested, causing the credential establishment operation to fail.
o GSS_S_BAD_MECH表示请求了GSS-API实现类型不支持的MECH_类型，导致凭据建立操作失败。
o GSS_S_BAD_NAMETYPE indicates that the provided desired_name is uninterpretable or of a type unsupported by the applicable underlying GSS-API mechanism(s), so no credentials could be established for the accompanying desired_name.
o GSS_S_BAD_NAMETYPE表示所提供的所需_名称不可解释，或者属于适用的底层GSS-API机制不支持的类型，因此无法为附带的所需_名称建立凭据。
o GSS_S_BAD_NAME indicates that the provided desired_name is inconsistent in terms of internally-incorporated type specifier information, so no credentials could be established for the accompanying desired_name.
o GSS_S_BAD_NAME表示提供的所需_名称在内部合并的类型说明符信息方面不一致，因此无法为附带的所需_名称建立凭据。
o GSS_S_CREDENTIALS_EXPIRED indicates that underlying credential elements corresponding to the requested desired_name have expired, so requested credentials could not be established.
o GSS_S_凭据\u EXPIRED表示与请求的所需\u名称对应的基础凭据元素已过期，因此无法建立请求的凭据。
o GSS_S_NO_CRED indicates that no credential elements corresponding to the requested desired_name and usage could be accessed, so requested credentials could not be established. In particular, this status should be returned upon temporary user-fixable conditions
o GSS_S_NO_CRED表示无法访问与请求的所需_名称和用法对应的凭据元素，因此无法建立请求的凭据。特别是，应在临时用户可修复的条件下返回此状态
preventing successful credential establishment and upon lack of authorization to establish and use credentials associated with the identity named in the input desired_name argument.
阻止成功建立凭据，以及在没有授权时建立和使用与输入所需名称参数中命名的标识相关联的凭据。
o GSS_S_FAILURE indicates that credential establishment failed for reasons unspecified at the GSS-API level.
o GSS_S_失败表示由于GSS-API级别未指定的原因，凭据建立失败。
GSS_Acquire_cred() is used to acquire credentials so that a principal can (as a function of the input cred_usage parameter) initiate and/or accept security contexts under the identity represented by the desired_name input argument. On successful completion, the returned output_cred_handle result provides a handle for subsequent references to the acquired credentials. Typically, single-user client processes requesting that default credential behavior be applied for context establishment purposes will have no need to invoke this call.
GSS_Acquire_cred（）用于获取凭据，以便主体可以（作为input cred_usage参数的函数）根据所需的_name输入参数表示的标识启动和/或接受安全上下文。成功完成后，返回的输出\u cred\u handle结果为后续对获取的凭据的引用提供句柄。通常，请求将默认凭证行为应用于上下文建立目的的单用户客户端进程将无需调用此调用。
A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name, which will be interpreted as a request for a credential handle that will invoke default behavior when passed to GSS_Init_sec_context(), if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or GSS_C_BOTH. It is possible that multiple pre-established credentials may exist for the same principal identity (for example, as a result of multiple user login sessions) when GSS_Acquire_cred() is called; the means used in such cases to select a specific credential are local matters. The input lifetime_req argument to GSS_Acquire_cred() may provide useful information for local GSS-API implementations to employ in making this disambiguation in a manner which will best satisfy a caller's intent.
调用者可以为所需的_名称提供值NULL（GSS_C_NO_NAME），如果cred_用法是GSS_C_inite或GSS_C_inite，或者如果cred_Accept_secu context（），则该值将被解释为对凭证句柄的请求，该凭证句柄将在传递给GSS_Init_secu_context（）时调用默认行为。调用GSS_Acquire_cred（）时，可能存在多个针对同一主体身份的预先建立的凭据（例如，由于多个用户登录会话）；在这种情况下，用于选择特定凭证的方法是本地事务。GSS_Acquire_cred（）的输入生存期_req参数可以为本地GSS-API实现提供有用的信息，以便以最能满足调用方意图的方式进行消歧。
This routine is expected to be used primarily by context acceptors, since implementations are likely to provide mechanism-specific ways of obtaining GSS-API initiator credentials from the system login process. Some implementations may therefore not support the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name resulting from applying GSS_Inquire_context() to an active context, or a name resulting from applying GSS_Inquire_cred() against a credential handle corresponding to default behavior. It is important to recognize that the explicit name which is yielded by resolving a default reference may change over time, e.g., as a result of local credential element management operations outside GSS-API; once resolved, however, the value of such an explicit name will remain constant.
该例程预计主要由上下文接受者使用，因为实现可能提供从系统登录过程获取GSS-API启动器凭据的机制特定方法。因此，某些实现可能不支持通过GSS_Acquire_cred（）获取GSS_C_INITIATE或GSS_C_这两个凭据，以获取除GSS_C_NO_name以外的任何名称，或将GSS_Inquire_context（）应用于活动上下文而产生的名称，或应用GSS_Inquire_cred（）而产生的名称针对与默认行为对应的凭据句柄。必须认识到，通过解析默认引用而产生的显式名称可能会随着时间的推移而改变，例如，由于GSS-API之外的本地凭证元素管理操作；但是，一旦解析，这样一个显式名称的值将保持不变。
The lifetime_rec result indicates the length of time for which the acquired credentials will be valid, as an offset from the present. A mechanism may return a reserved value indicating INDEFINITE if no
lifetime_rec结果表示获取的凭据有效的时间长度，作为与当前凭据的偏移量。机制可能会返回一个保留值，表示如果没有，则不确定
constraints on credential lifetime are imposed. A caller of GSS_Acquire_cred() can request a length of time for which acquired credentials are to be valid (lifetime_req argument), beginning at the present, or can request credentials with a default validity interval. (Requests for postdated credentials are not supported within the GSS-API.) Certain mechanisms and implementations may bind in credential validity period specifiers at a point preliminary to invocation of the GSS_Acquire_cred() call (e.g., in conjunction with user login procedures). As a result, callers requesting non-default values for lifetime_req must recognize that such requests cannot always be honored and must be prepared to accommodate the use of returned credentials with different lifetimes as indicated in lifetime_rec.
对凭证生存期施加限制。GSS_Acquire_cred（）的调用者可以请求从当前开始的获取的凭据的有效时间长度（lifetime_req参数），或者可以请求具有默认有效期间隔的凭据。（GSS-API中不支持对过期凭证的请求。）某些机制和实现可能会在调用GSS_Acquire_cred（）调用之前的某个点绑定凭证有效期说明符（例如，与用户登录过程结合使用）。因此，请求lifetime_req的非默认值的呼叫者必须认识到这些请求不能总是得到满足，并且必须准备好适应lifetime_rec中所示的不同生存期的返回凭据的使用。
The caller of GSS_Acquire_cred() can explicitly specify a set of mech_types which are to be accommodated in the returned credentials (desired_mechs argument), or can request credentials for a system-defined default set of mech_types. Selection of the system-specified default set is recommended in the interests of application portability. The actual_mechs return value may be interrogated by the caller to determine the set of mechanisms with which the returned credentials may be used.
GSS_Acquire_cred（）的调用者可以显式指定一组机械类型，这些类型将包含在返回的凭据（所需的机械参数）中，或者可以请求系统定义的默认机械类型集的凭据。为了应用程序的可移植性，建议选择系统指定的默认集。调用者可以询问实际的_mechs返回值，以确定可使用返回的凭证的机制集。
2.1.2: GSS_Release_cred call
2.1.2:GSS\U发布\U信用呼叫
Input:
输入：
o cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL -- is specified, the call will complete successfully, but -- will have no effect; no credential elements will be -- released.
o cred_handle CREDENTIAL handle——如果指定了GSS_C_NO_CREDENTIAL——调用将成功完成，但——将无效；不会释放任何凭据元素。
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER
o 次要状态整数
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the credentials referenced by the input cred_handle were released for purposes of subsequent access by the caller. The effect on other processes which may be authorized shared access to such credentials is a local matter.
o GSS_S_COMPLETE表示输入cred_句柄引用的凭据已被释放，以便调用者进行后续访问。对可能被授权共享访问此类凭据的其他进程的影响是本地问题。
o GSS_S_NO_CRED indicates that no release operation was performed, either because the input cred_handle was invalid or because the caller lacks authorization to access the referenced credentials.
o GSS_S_NO_CRED表示未执行任何释放操作，这可能是因为输入CRED_句柄无效，或者是因为调用方缺乏访问引用凭据的授权。
o GSS_S_FAILURE indicates that the release operation failed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示释放操作因GSS-API级别未指定的原因而失败。
Provides a means for a caller to explicitly request that credentials be released when their use is no longer required. Note that system-specific credential management functions are also likely to exist, for example to assure that credentials shared among processes are properly deleted when all affected processes terminate, even if no explicit release requests are issued by those processes. Given the fact that multiple callers are not precluded from gaining authorized access to the same credentials, invocation of GSS_Release_cred() cannot be assumed to delete a particular set of credentials on a system-wide basis.
为调用者提供一种方法，当不再需要使用凭据时，调用者可以显式请求释放凭据。请注意，系统特定的凭据管理功能也可能存在，例如，确保在所有受影响的进程终止时正确删除进程之间共享的凭据，即使这些进程没有发出明确的释放请求。鉴于不排除多个调用者获得对同一凭据的授权访问，因此不能假定调用GSS_Release_cred（）会在系统范围内删除一组特定的凭据。
2.1.3: GSS_Inquire_cred call
2.1.3：GSS\u查询\u信用电话
Input:
输入：
o cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL -- is specified, default initiator credentials are queried
o cred_handle凭证句柄——如果指定了GSS_C_NO_凭证，则查询默认启动器凭证
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o cred_name INTERNAL NAME, -- caller must release with -- GSS_Release_name()
o cred_name内部名称，--调用方必须使用--GSS_release_name（）释放
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec INTEGER--以秒为单位，或保留值--不确定
o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_用法整数，--0=启动并接受，1=仅启动，--2=仅接受
o mech_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o 对象标识符的mech_集合--调用方必须释放--使用GSS_release_oid_集合（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the credentials referenced by the input cred_handle argument were valid, and that the output cred_name, lifetime_rec, and cred_usage values represent, respectively, the credentials' associated principal name, remaining lifetime, suitable usage modes, and supported mechanism types.
o GSS_S_COMPLETE表示输入cred_handle参数引用的凭据有效，并且输出cred_name、lifety_rec和cred_usage值分别表示凭据的关联主体名称、剩余生存期、合适的使用模式和支持的机制类型。
o GSS_S_NO_CRED indicates that no information could be returned about the referenced credentials, either because the input cred_handle was invalid or because the caller lacks authorization to access the referenced credentials.
o GSS_S_NO_CRED表示无法返回有关引用凭据的任何信息，这可能是因为输入凭据句柄无效，或者是因为调用方缺乏访问引用凭据的授权。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced credentials are invalid.
o GSS_S_缺陷_凭证表示引用的凭证无效。
o GSS_S_CREDENTIALS_EXPIRED indicates that the referenced credentials have expired.
o GSS\u S\u凭据\u过期表示引用的凭据已过期。
o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示操作因GSS-API级别未指定的原因而失败。
The GSS_Inquire_cred() call is defined primarily for the use of those callers which request use of default credential behavior rather than acquiring credentials explicitly with GSS_Acquire_cred(). It enables callers to determine a credential structure's associated principal name, remaining validity period, usability for security context initiation and/or acceptance, and supported mechanisms.
GSS_Inquire_cred（）调用的定义主要是为了使用那些请求使用默认凭据行为的调用方，而不是使用GSS_Acquire_cred（）显式获取凭据。它使调用者能够确定凭证结构的关联主体名称、剩余有效期、安全上下文启动和/或接受的可用性以及支持的机制。
For a multi-mechanism credential, the returned "lifetime" specifier indicates the shortest lifetime of any of the mechanisms' elements in the credential (for either context initiation or acceptance purposes).
对于多机制凭据，返回的“生存期”说明符指示凭据中任何机制元素的最短生存期（用于上下文启动或接受目的）。
GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for "cred_usage" if both of the following conditions hold:
GSS_Inquire_cred（）应指明“cred_用法”的启动和接受，前提是以下两种情况均成立：
(1) there exists in the credential an element which allows context initiation using some mechanism
(1) 凭证中存在允许使用某种机制启动上下文的元素
(2) there exists in the credential an element which allows context acceptance using some mechanism (allowably, but not necessarily, one of the same mechanism(s) qualifying for (1)).
(2) 凭证中存在一个元素，该元素允许使用某种机制（允许但不一定是符合（1）条件的相同机制之一）接受上下文。
If condition (1) holds but not condition (2), GSS_Inquire_cred() should indicate INITIATE-ONLY for "cred_usage". If condition (2) holds but not condition (1), GSS_Inquire_cred() should indicate ACCEPT-ONLY for "cred_usage".
如果条件（1）有效，但条件（2）无效，则GSS_Inquire_cred（）应为“cred_用法”指示INITIATE-ONLY。如果条件（2）有效，但条件（1）无效，则GSS_Inquire_cred（）应为“cred_用法”指示ACCEPT-ONLY。
Callers requiring finer disambiguation among available combinations of lifetimes, usage modes, and mechanisms should call the GSS_Inquire_cred_by_mech() routine, passing that routine one of the mech OIDs returned by GSS_Inquire_cred().
需要在可用的生命周期、使用模式和机制组合中进行更精确的消歧的调用方应调用GSS_Inquire_cred_by_mech（）例程，并将GSS_Inquire_cred（）返回的机制之一传递给该例程。
2.1.4: GSS_Add_cred call
2.1.4:GSS\u添加\u信用呼叫
Inputs:
投入：
o input_cred_handle CREDENTIAL HANDLE -- handle to credential -- structure created with prior GSS_Acquire_cred() or -- GSS_Add_cred() call; see text for definition of behavior -- when GSS_C_NO_CREDENTIAL provided.
o input_cred_handle CREDENTIAL handle--handle to CREDENTIAL--structure使用先前的GSS_Acquire_cred（）或--GSS_Add_cred（）调用创建；请参阅文本以了解行为定义——当GSS\U C\U未提供凭据时。
o desired_name INTERNAL NAME
o 所需名称内部名称
o initiator_time_req INTEGER -- in seconds; 0 requests default
o 启动器\u时间\u请求整数——以秒为单位；默认为0个请求
o acceptor_time_req INTEGER -- in seconds; 0 requests default
o 接受器\u时间\u请求整数——以秒为单位；默认为0个请求
o desired_mech OBJECT IDENTIFIER
o 所需的机械对象标识符
o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_用法整数--0=INITIATE-AND-ACCEPT，1=INITIATE-ONLY，--2=ACCEPT-ONLY
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_cred_handle CREDENTIAL HANDLE, -- NULL to request that -- credential elements be added "in place" to the credential -- structure identified by input_cred_handle, -- non-NULL pointer to request that -- a new credential structure and handle be created. -- if credential handle returned, caller must release with -- GSS_Release_cred()
o output_cred_handle CREDENTIAL handle，-NULL请求--将凭证元素“就地”添加到凭证--由input_cred_handle标识的结构，-非NULL指针请求--创建新的凭证结构和句柄。-如果返回凭证句柄，调用方必须释放--GSS_release_cred（）
o actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must -- release with GSS_Release_oid_set()
o 对象标识符的实际\u mechs集，--如果返回，调用方必须--release with GSS\u release\u oid\u SET（）
o initiator_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o 启动器\u time\u rec整数--以秒为单位，或保留值--不确定
o acceptor_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o acceptor_time_rec INTEGER--以秒为单位，或保留值--不确定
o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_用法整数，--0=启动并接受，1=仅启动，--2=仅接受
o mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms -- supported by resulting credential.
o 一组对象标识符——一整套机制——由结果凭证支持。
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the credentials referenced by the input_cred_handle argument were valid, and that the resulting credential from GSS_Add_cred() is valid for the durations indicated in initiator_time_rec and acceptor_time_rec, suitable for the usage requested in cred_usage, and for the mechanisms indicated in actual_mechs.
o GSS_S_COMPLETE表示input_cred_handle参数引用的凭据有效，并且GSS_Add_cred（）生成的凭据在启动器_time_rec和接受器_time_rec中指示的持续时间内有效，适用于cred_用法中请求的用法以及实际_机制中指示的机制。
o GSS_S_DUPLICATE_ELEMENT indicates that the input desired_mech specified a mechanism for which the referenced credential already contained a credential element with overlapping cred_usage and validity time specifiers.
o GSS_S_DUPLICATE_元素表示输入所需的_mech指定了一种机制，对于该机制，引用的凭证已包含一个凭证元素，该凭证元素具有重叠的凭证使用和有效期时间说明符。
o GSS_S_BAD_MECH indicates that the input desired_mech specified a mechanism unsupported by the GSS-API implementation, causing the GSS_Add_cred() operation to fail.
o GSS_S_BAD_MECH表示所需的输入_MECH指定了GSS-API实现不支持的机制，导致GSS_Add_cred（）操作失败。
o GSS_S_BAD_NAMETYPE indicates that the provided desired_name is uninterpretable or of a type unsupported by the applicable underlying GSS-API mechanism(s), so the GSS_Add_cred() operation could not be performed for that name.
o GSS_S_BAD_NAMETYPE表示提供的所需名称不可解释，或其类型不受适用的底层GSS-API机制支持，因此无法对该名称执行GSS_Add_cred（）操作。
o GSS_S_BAD_NAME indicates that the provided desired_name is inconsistent in terms of internally-incorporated type specifier information, so the GSS_Add_cred() operation could not be performed for that name.
o GSS_S_BAD_NAME表示提供的所需_名称在内部合并的类型说明符信息方面不一致，因此无法对该名称执行GSS_Add_cred（）操作。
o GSS_S_NO_CRED indicates that the input_cred_handle referenced invalid or inaccessible credentials. In particular, this status should be returned upon temporary user-fixable conditions preventing successful credential establishment or upon lack of authorization to establish or use credentials representing the requested identity.
o GSS_S_NO_CRED表示输入_CRED_句柄引用了无效或不可访问的凭据。特别是，当临时用户可修复的条件阻止成功建立凭据时，或在没有授权建立或使用表示请求的身份的凭据时，应返回此状态。
o GSS_S_CREDENTIALS_EXPIRED indicates that referenced credential elements have expired, so the GSS_Add_cred() operation could not be performed.
o GSS\u S\u CREDENTIALS\u EXPIRED表示引用的凭据元素已过期，因此无法执行GSS\u Add\u cred（）操作。
o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示操作因GSS-API级别未指定的原因而失败。
GSS_Add_cred() enables callers to construct credentials iteratively by adding credential elements in successive operations, corresponding to different mechanisms. This offers particular value in multi-mechanism environments, as the major_status and minor_status values returned on each iteration are individually visible and can therefore be interpreted unambiguously on a per-mechanism basis. A credential element is identified by the name of the principal to which it refers. GSS-API implementations must impose a local access control policy on callers of this routine to prevent unauthorized callers from acquiring credential elements to which they are not entitled. This routine is not intended to provide a "login to the network" function, as such a function would involve the creation of new mechanism-specific authentication data, rather than merely acquiring a GSS-API handle to existing data. Such functions, if required, should be defined in implementation-specific extension routines.
GSS_Add_cred（）允许调用方通过在后续操作中添加凭证元素（对应于不同的机制）来迭代构造凭证。这在多机制环境中提供了特别的价值，因为每次迭代返回的主_状态和次_状态值都是单独可见的，因此可以在每个机制的基础上进行明确的解释。凭证元素由其引用的主体的名称标识。GSS-API实现必须对此例程的调用方强制实施本地访问控制策略，以防止未经授权的调用方获取其无权访问的凭据元素。此例程不打算提供“登录到网络”功能，因为此类功能将涉及创建新的机制特定的身份验证数据，而不仅仅是获取现有数据的GSS-API句柄。如果需要，这些函数应该在特定于实现的扩展例程中定义。
If credential acquisition is time-consuming for a mechanism, the mechanism may choose to delay the actual acquisition until the credential is required (e.g. by GSS_Init_sec_context() or GSS_Accept_sec_context()). Such mechanism-specific implementation decisions should be invisible to the calling application; thus a call of GSS_Inquire_cred() immediately following the call of GSS_Acquire_cred() must return valid credential data, and may therefore incur the overhead of a deferred credential acquisition.
如果某个机制的凭证获取非常耗时，则该机制可以选择延迟实际获取，直到需要凭证为止（例如，通过GSS_Init_sec_context（）或GSS_Accept_sec_context（））。这种特定于机制的实现决策应该对调用应用程序不可见；因此，在调用GSS_Acquire_cred（）之后立即调用GSS_Inquire_cred（）必须返回有效的凭证数据，因此可能导致延迟凭证获取的开销。
If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL output_cred_handle must be supplied. For the case of GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create the credential referenced by its output_cred_handle based on default behavior. That is, the call will have the same effect as if the caller had previously called GSS_Acquire_cred(), specifying the same usage and passing GSS_C_NO_NAME as the desired_name parameter (thereby obtaining an explicit credential handle corresponding to default behavior), had passed that credential handle to GSS_Add_cred(), and had finally called GSS_Release_cred() on the credential handle received from GSS_Acquire_cred().
如果GSS_C_NO_凭证指定为输入\u cred_句柄，则必须提供非空输出\u cred_句柄。对于GSS_C_NO_凭证作为输入\u cred_句柄的情况，GSS_Add_cred（）将根据默认行为创建由其输出\u cred_句柄引用的凭证。也就是说，调用将具有与调用方之前调用GSS_Acquire_cred（）、指定相同用法并将GSS_C_NO_NAME作为所需的_NAME参数传递（从而获得与默认行为相对应的显式凭证句柄）以及将该凭证句柄传递给GSS_Add_cred（）相同的效果，并最终对从GSS_Acquire_cred（）接收的凭据句柄调用了GSS_Release_cred（）。
This routine is expected to be used primarily by context acceptors, since implementations are likely to provide mechanism-specific ways of obtaining GSS-API initiator credentials from the system login process. Some implementations may therefore not support the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name resulting from applying GSS_Inquire_context() to an active context, or a name resulting from applying GSS_Inquire_cred() against a credential handle corresponding to default behavior. It is important to recognize that the explicit name which is yielded by resolving a default reference may change over time, e.g., as a result of local
该例程预计主要由上下文接受者使用，因为实现可能提供从系统登录过程获取GSS-API启动器凭据的机制特定方法。因此，某些实现可能不支持通过GSS_Acquire_cred（）获取GSS_C_INITIATE或GSS_C_这两个凭据，以获取除GSS_C_NO_name以外的任何名称，或将GSS_Inquire_context（）应用于活动上下文而产生的名称，或应用GSS_Inquire_cred（）而产生的名称针对与默认行为对应的凭据句柄。必须认识到，通过解析默认引用而产生的显式名称可能会随着时间的推移而改变，例如，由于本地
credential element management operations outside GSS-API; once resolved, however, the value of such an explicit name will remain constant.
GSS-API之外的凭证元素管理操作；但是，一旦解析，这样一个显式名称的值将保持不变。
A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name, which will be interpreted as a request for a credential handle that will invoke default behavior when passed to GSS_Init_sec_context(), if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or GSS_C_BOTH.
调用者可以为所需的_名称提供值NULL（GSS_C_NO_NAME），如果cred_用法是GSS_C_inite或GSS_C_inite，或者如果cred_Accept_secu context（），则该值将被解释为对凭证句柄的请求，该凭证句柄将在传递给GSS_Init_secu_context（）时调用默认行为。
The same input desired_name, or default reference, should be used on all GSS_Acquire_cred() and GSS_Add_cred() calls corresponding to a particular credential.
与特定凭证对应的所有GSS_Acquire_cred（）和GSS_Add_cred（）调用都应使用相同的输入所需名称或默认引用。
2.1.5: GSS_Inquire_cred_by_mech call
2.1.5：GSS通过机械呼叫查询信用卡
Inputs:
投入：
o cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL -- specified, default initiator credentials are queried
o cred_handle凭证句柄--如果指定了GSS_C_NO_凭证，则查询默认启动器凭证
o mech_type OBJECT IDENTIFIER -- specific mechanism for -- which credentials are being queried
o mech_类型对象标识符--特定机制--正在查询哪些凭据
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o cred_name INTERNAL NAME, -- guaranteed to be MN; caller must -- release with GSS_Release_name()
o cred_name内部名称，保证为MN；调用方必须--release使用GSS\u release\u name（）进行释放
o lifetime_rec_initiate INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec_initiate INTEGER（以秒为单位）或保留值（不确定）
o lifetime_rec_accept INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec_accept INTEGER（以秒为单位）或保留值（不确定）
o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_用法整数，--0=启动并接受，1=仅启动，--2=仅接受
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the credentials referenced by the input cred_handle argument were valid, that the mechanism indicated by the input mech_type was represented with elements within those
o GSS_S_COMPLETE表示由input cred_handle参数引用的凭据有效，表示由input mech_类型指示的机制由这些参数中的元素表示
credentials, and that the output cred_name, lifetime_rec_initiate, lifetime_rec_accept, and cred_usage values represent, respectively, the credentials' associated principal name, remaining lifetimes, and suitable usage modes.
凭据，并且输出凭据名称、lifetime\u rec\u initiate、lifetime\u rec\u accept和cred\u usage值分别表示凭据的关联主体名称、剩余寿命和适当的使用模式。
o GSS_S_NO_CRED indicates that no information could be returned about the referenced credentials, either because the input cred_handle was invalid or because the caller lacks authorization to access the referenced credentials.
o GSS_S_NO_CRED表示无法返回有关引用凭据的任何信息，这可能是因为输入凭据句柄无效，或者是因为调用方缺乏访问引用凭据的授权。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced credentials are invalid.
o GSS_S_缺陷_凭证表示引用的凭证无效。
o GSS_S_CREDENTIALS_EXPIRED indicates that the referenced credentials have expired.
o GSS\u S\u凭据\u过期表示引用的凭据已过期。
o GSS_S_BAD_MECH indicates that the referenced credentials do not contain elements for the requested mechanism.
o GSS_S_BAD_MECH表示引用的凭据不包含请求机制的元素。
o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示操作因GSS-API级别未指定的原因而失败。
The GSS_Inquire_cred_by_mech() call enables callers in multi-mechanism environments to acquire specific data about available combinations of lifetimes, usage modes, and mechanisms within a credential structure. The lifetime_rec_initiate result indicates the available lifetime for context initiation purposes; the lifetime_rec_accept result indicates the available lifetime for context acceptance purposes.
GSS_Inquire_cred_by_mech（）调用使多机制环境中的调用者能够获取有关凭据结构中可用的生命周期、使用模式和机制组合的特定数据。lifetime_rec_initiate结果指示上下文初始化目的的可用生存期；lifetime_rec_accept结果指示用于上下文接受目的的可用生存期。
2.2: Context-level calls
2.2：上下文级调用
This group of calls is devoted to the establishment and management of security contexts between peers. A context's initiator calls GSS_Init_sec_context(), resulting in generation of a token which the caller passes to the target. At the target, that token is passed to GSS_Accept_sec_context(). Depending on the underlying mech_type and specified options, additional token exchanges may be performed in the course of context establishment; such exchanges are accommodated by GSS_S_CONTINUE_NEEDED status returns from GSS_Init_sec_context() and GSS_Accept_sec_context().
这组调用用于在对等点之间建立和管理安全上下文。上下文的启动器调用GSS_Init_sec_context（），从而生成一个令牌，调用者将该令牌传递给目标。在目标位置，该令牌被传递给GSS_Accept_sec_context（）。根据基础mech_类型和指定选项，可在上下文建立过程中执行额外的令牌交换；此类交换由GSS_Init_sec_context（）和GSS_Accept_sec_context（）的GSS_CONTINUE_所需状态返回进行调节。
Either party to an established context may invoke GSS_Delete_sec_context() to flush context information when a context is no longer required. GSS_Process_context_token() is used to process received tokens carrying context-level control information. GSS_Context_time() allows a caller to determine the length of time for which an established context will remain valid.
当不再需要上下文时，已建立上下文的任何一方都可以调用GSS_Delete_sec_context（）来刷新上下文信息。GSS_Process_context_token（）用于处理接收到的带有上下文级控制信息的令牌。GSS_Context_time（）允许调用方确定已建立上下文保持有效的时间长度。
GSS_Inquire_context() returns status information describing context characteristics. GSS_Wrap_size_limit() allows a caller to determine the size of a token which will be generated by a GSS_Wrap() operation. GSS_Export_sec_context() and GSS_Import_sec_context() enable transfer of active contexts between processes on an end system.
GSS_Inquire_context（）返回描述上下文特征的状态信息。GSS_Wrap_size_limit（）允许调用方确定将由GSS_Wrap（）操作生成的令牌的大小。GSS_Export_sec_context（）和GSS_Import_sec_context（）支持在终端系统上的进程之间传输活动上下文。
2.2.1: GSS_Init_sec_context call
2.2.1:GSS_Init_sec_上下文调用
Inputs:
投入：
o claimant_cred_handle CREDENTIAL HANDLE, -- NULL specifies "use -- default"
o 索赔人凭证句柄凭证句柄，-NULL指定“使用--默认”
o input_context_handle CONTEXT HANDLE, -- 0 -- (GSS_C_NO_CONTEXT) specifies "none assigned yet"
o 输入上下文句柄上下文句柄，-0--（GSS\U C\U NO\U context）指定“尚未分配”
o targ_name INTERNAL NAME,
o 目标名称内部名称，
o mech_type OBJECT IDENTIFIER, -- NULL parameter specifies "use -- default"
o 机械类型对象标识符，-NULL参数指定“使用--default”
o deleg_req_flag BOOLEAN,
o deleg_req_标志布尔值，
o mutual_req_flag BOOLEAN,
o 相互请求标志布尔值，
o replay_det_req_flag BOOLEAN,
o replay_det_req_标志布尔值，
o sequence_req_flag BOOLEAN,
o 序列要求标志布尔值，
o anon_req_flag BOOLEAN,
o anon_req_标志布尔值，
o conf_req_flag BOOLEAN,
o conf_req_标志布尔值，
o integ_req_flag BOOLEAN,
o 整数请求标志布尔值，
o lifetime_req INTEGER, -- 0 specifies default lifetime
o 生存期\u req整数，-0指定默认生存期
o chan_bindings OCTET STRING,
o chan_绑定八位字节字符串，
o input_token OCTET STRING -- NULL or token received from target
o input_token八位字节字符串——NULL或从目标接收到的令牌
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_context_handle CONTEXT HANDLE, -- once returned non-NULL, -- caller must release with GSS_Delete_sec_context()
o output_context_handle context handle，--一旦返回非NULL，--调用方必须使用GSS_Delete_sec_context（）释放
o mech_type OBJECT IDENTIFIER, -- actual mechanism always -- indicated, never NULL; caller should treat as read-only -- and should not attempt to release
o 机械类型对象标识符，--始终指示实际机构，从不为空；调用方应将其视为只读，并且不应尝试释放
o output_token OCTET STRING, -- NULL or token to pass to context -- target; caller must release with GSS_Release_buffer()
o 输出令牌八位字符串，-NULL或要传递给上下文的令牌--target；调用方必须使用GSS_release_buffer（）释放
o deleg_state BOOLEAN,
o deleg_状态布尔值，
o mutual_state BOOLEAN,
o 相互状态布尔值，
o replay_det_state BOOLEAN,
o replay_det_state布尔值，
o sequence_state BOOLEAN,
o 序列状态布尔，
o anon_state BOOLEAN,
o 无状态布尔值，
o trans_state BOOLEAN,
o trans_状态布尔值，
o prot_ready_state BOOLEAN, -- see Section 1.2.7
o 保护就绪状态布尔值，--见第1.2.7节
o conf_avail BOOLEAN,
o conf_，
o integ_avail BOOLEAN,
o 整型布尔型，
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec INTEGER--以秒为单位，或保留值--不确定
This call may block pending network interactions for those mech_types in which an authentication server or other network entity must be consulted on behalf of a context initiator in order to generate an output_token suitable for presentation to a specified target.
此调用可能会阻止那些机制类型的挂起网络交互，在这些机制类型中，必须代表上下文启动器咨询身份验证服务器或其他网络实体，以便生成适合呈现给指定目标的输出令牌。
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that context-level information was successfully initialized, and that the returned output_token will provide sufficient information for the target to perform per-message processing on the newly-established context.
o GSS_S_COMPLETE表示上下文级别信息已成功初始化，并且返回的输出_令牌将为目标提供足够的信息，以便在新建立的上下文上执行每条消息处理。
o GSS_S_CONTINUE_NEEDED indicates that control information in the returned output_token must be sent to the target, and that a reply must be received and passed as the input_token argument
o GSS_S_CONTINUE_Required表示返回的输出_令牌中的控制信息必须发送到目标，并且必须接收回复并作为输入_令牌参数传递
to a continuation call to GSS_Init_sec_context(), before per-message processing can be performed in conjunction with this context (unless the prot_ready_state value is concurrently returned TRUE).
在与此上下文一起执行每条消息处理之前（除非prot_ready_state值同时返回TRUE），继续调用GSS_Init_sec_context（）。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the input_token failed, preventing further processing from being performed based on that token.
o GSS_S_DEFECTIVE_TOKEN表示对输入_TOKEN执行的一致性检查失败，从而阻止基于该TOKEN执行进一步的处理。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks performed on the credential structure referenced by claimant_cred_handle failed, preventing further processing from being performed using that credential structure.
o GSS_S_DEFECTIVE_CREDENTIAL表示在索赔人_cred_handle引用的凭证结构上执行的一致性检查失败，从而阻止使用该凭证结构执行进一步的处理。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received input_token contains an incorrect integrity check, so context setup cannot be accomplished.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）表示接收到的输入_令牌包含不正确的完整性检查，因此无法完成上下文设置。
o GSS_S_NO_CRED indicates that no context was established, either because the input cred_handle was invalid, because the referenced credentials are valid for context acceptor use only, because the caller lacks authorization to access the referenced credentials, or because the resolution of default credentials failed.
o GSS_S_NO_CRED表示未建立上下文，原因可能是输入CRED_句柄无效、引用的凭据仅对上下文接受者有效、调用方无权访问引用的凭据，或者默认凭据的解析失败。
o GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided through the input claimant_cred_handle argument are no longer valid, so context establishment cannot be completed.
o GSS_S_CREDENTIALS_EXPIRED表示通过输入请求者_cred_handle参数提供的凭据不再有效，因此无法完成上下文建立。
o GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-provided chan_bindings and those extracted from the input_token was detected, signifying a security-relevant event and preventing context establishment. (This result will be returned by GSS_Init_sec_context() only for contexts where mutual_state is TRUE.)
o GSS_S_BAD_绑定表示检测到调用者提供的chan_绑定与从输入_令牌提取的chan_绑定之间不匹配，表示存在安全相关事件并阻止上下文建立。（此结果将由GSS_Init_sec_context（）返回，仅适用于相互_状态为TRUE的上下文。）
o GSS_S_OLD_TOKEN indicates that the input_token is too old to be checked for integrity. This is a fatal error during context establishment.
o GSS_S_OLD_令牌表示输入_令牌太旧，无法检查完整性。这是上下文建立过程中的一个致命错误。
o GSS_S_DUPLICATE_TOKEN indicates that the input token has a correct integrity check, but is a duplicate of a token already processed. This is a fatal error during context establishment.
o GSS_S_DUPLICATE_令牌表示输入令牌具有正确的完整性检查，但它是已处理令牌的副本。这是上下文建立过程中的一个致命错误。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided; this major status will be returned only for successor calls following GSS_S_CONTINUE_ NEEDED status returns.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文；此主要状态将仅在GSS_S_CONTINUE_所需状态返回后，为后续调用返回。
o GSS_S_BAD_NAMETYPE indicates that the provided targ_name is of a type uninterpretable or unsupported by the applicable underlying GSS-API mechanism(s), so context establishment cannot be completed.
o GSS_S_BAD_NAMETYPE表示提供的targ_名称的类型不可解释或不受适用的底层GSS-API机制支持，因此无法完成上下文建立。
o GSS_S_BAD_NAME indicates that the provided targ_name is inconsistent in terms of internally-incorporated type specifier information, so context establishment cannot be accomplished.
o GSS_S_BAD_NAME表示提供的target_NAME在内部合并的类型说明符信息方面不一致，因此无法完成上下文建立。
o GSS_S_BAD_MECH indicates receipt of a context establishment token or of a caller request specifying a mechanism unsupported by the local system or with the caller's active credentials
o GSS_S_BAD_MECH表示接收到上下文建立令牌或调用方请求，指定本地系统不支持的机制或调用方的活动凭据
o GSS_S_FAILURE indicates that context setup could not be accomplished for reasons unspecified at the GSS-API level, and that no interface-defined recovery action is available.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法完成上下文设置，并且没有接口定义的恢复操作可用。
This routine is used by a context initiator, and ordinarily emits an output_token suitable for use by the target within the selected mech_type's protocol. For the case of a multi-step exchange, this output_token will be one in a series, each generated by a successive call. Using information in the credentials structure referenced by claimant_cred_handle, GSS_Init_sec_context() initializes the data structures required to establish a security context with target targ_name.
此例程由上下文启动器使用，通常会发出一个输出令牌，该令牌适合所选mech_类型的协议内的目标使用。对于多步骤交换的情况，此输出_令牌将是一个系列中的一个，每个由连续调用生成。GSS_Init_sec_context（）使用索赔人_cred_handle引用的凭据结构中的信息初始化使用目标target_name建立安全上下文所需的数据结构。
The targ_name may be any valid INTERNAL NAME; it need not be an MN. In addition to support for other name types, it is recommended (newly as of GSS-V2, Update 1) that mechanisms be able to accept GSS_C_NO_NAME as an input type for targ_name. While recommended, such support is not required, and it is recognized that not all mechanisms can construct tokens without explicitly naming the context target, even when mutual authentication of the target is not obtained. Callers wishing to make use of this facility and concerned with portability should be aware that support for GSS_C_NO_NAME as input targ_name type is unlikely to be provided within mechanism definitions specified prior to GSS-V2, Update 1.
目标名称可以是任何有效的内部名称；它不必是MN。除了支持其他名称类型外，建议（从GSS-V2开始，更新1）机制能够接受GSS_C_NO_name作为目标名称的输入类型。虽然建议这样做，但并不需要这样的支持，而且人们认识到，并非所有机制都可以在不显式命名上下文目标的情况下构造令牌，即使在没有获得目标的相互身份验证的情况下也是如此。希望使用此设施并关心可移植性的呼叫者应注意，在GSS-V2更新1之前指定的机制定义中，不太可能提供对GSS_C_NO_NAME作为输入目标名称类型的支持。
The claimant_cred_handle must correspond to the same valid credentials structure on the initial call to GSS_Init_sec_context() and on any successor calls resulting from GSS_S_CONTINUE_NEEDED status returns; different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED facility will require access to credentials at different points in the context establishment sequence.
在对GSS_Init_sec_context（）的初始调用和由GSS_S_CONTINUE_required status returns产生的任何后续调用中，索赔人_cred_句柄必须与相同的有效凭证结构相对应；由GSS_S_CONTINUE_所需设施建模的不同协议序列将需要在上下文建立序列的不同点访问凭据。
The caller-provided input_context_handle argument is to be 0 (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first GSS_Init_sec_context() call relating to a given context. If successful (i.e., if accompanied by major_status GSS_S_COMPLETE or
在与给定上下文相关的第一个GSS_Init_sec_context（）调用中，调用方提供的输入_context_handle参数为0（GSS_C_NO_context），并指定“尚未分配”。如果成功（即，如果伴随主要状态GSS或完成
GSS_S_CONTINUE_NEEDED), and only if successful, the initial GSS_Init_sec_context() call returns a non-zero output_context_handle for use in future references to this context. Once a non-zero output_context_handle has been returned, GSS-API callers should call GSS_Delete_sec_context() to release context-related resources if errors occur in later phases of context establishment, or when an established context is no longer required. If GSS_Init_sec_context() is passed the handle of a context which is already fully established, GSS_S_FAILURE status is returned.
GSS_S_CONTINUE_NEEDED），并且只有在成功的情况下，初始的GSS_Init_sec_context（）调用才会返回一个非零输出_context_句柄，以供将来引用此上下文时使用。返回非零输出上下文句柄后，如果在上下文建立的后续阶段出现错误，或者不再需要已建立的上下文，则GSS-API调用方应调用GSS_Delete_sec_context（）来释放上下文相关资源。如果向GSS_Init_sec_context（）传递已完全建立的上下文的句柄，则返回GSS_S_故障状态。
When continuation attempts to GSS_Init_sec_context() are needed to perform context establishment, the previously-returned non-zero handle value is entered into the input_context_handle argument and will be echoed in the returned output_context_handle argument. On such continuation attempts (and only on continuation attempts) the input_token value is used, to provide the token returned from the context's target.
当需要继续尝试GSS_Init_sec_context（）以执行上下文建立时，先前返回的非零句柄值将输入到输入上下文句柄参数中，并将在返回的输出上下文句柄参数中回显。在这种继续尝试中（并且仅在继续尝试中），使用输入_令牌值，以提供从上下文目标返回的令牌。
The chan_bindings argument is used by the caller to provide information binding the security context to security-related characteristics (e.g., addresses, cryptographic keys) of the underlying communications channel. See Section 1.1.6 of this document for more discussion of this argument's usage.
调用者使用chan_bindings参数来提供将安全上下文绑定到基础通信信道的安全相关特征（例如，地址、加密密钥）的信息。有关此参数用法的更多讨论，请参见本文件第1.1.6节。
The input_token argument contains a message received from the target, and is significant only on a call to GSS_Init_sec_context() which follows a previous return indicating GSS_S_CONTINUE_NEEDED major_status.
input_token参数包含从目标接收到的消息，仅在调用GSS_Init_sec_context（）时有效，该上下文在前面的返回之后，指示GSS_S_CONTINUE_需要的主要_状态。
It is the caller's responsibility to establish a communications path to the target, and to transmit any returned output_token (independent of the accompanying returned major_status value) to the target over that path. The output_token can, however, be transmitted along with the first application-provided input message to be processed by GSS_GetMIC() or GSS_Wrap() in conjunction with a successfully-established context. (Note: when the GSS-V2 prot_ready_state indicator is returned TRUE, it can be possible to transfer a protected message before context establishment is complete: see also Section 1.2.7)
调用者负责建立到目标的通信路径，并通过该路径将任何返回的输出_令牌（独立于附带的返回的主要_状态值）传输到目标。然而，输出_令牌可以与第一个应用程序提供的输入消息一起传输，该输入消息将由GSS_GetMIC（）或GSS_Wrap（）与成功建立的上下文一起处理。（注意：当GSS-V2 prot_ready_状态指示器返回TRUE时，可以在上下文建立完成之前传输受保护的消息：另请参见第1.2.7节）
The initiator may request various context-level functions through input flags: the deleg_req_flag requests delegation of access rights, the mutual_req_flag requests mutual authentication, the replay_det_req_flag requests that replay detection features be applied to messages transferred on the established context, and the sequence_req_flag requests that sequencing be enforced. (See Section
发起方可通过输入标志请求各种上下文级功能：deleg_req_标志请求访问权的委派，MULTARE_req_标志请求相互认证，RELAY_det_req_标志请求将重播检测功能应用于在已建立上下文上传输的消息，并且sequence_req_标志请求执行排序。（见第节）
1.2.3 for more information on replay detection and sequencing features.) The anon_req_flag requests that the initiator's identity not be transferred within tokens to be sent to the acceptor.
1.2.3 有关重播检测和排序功能的更多信息。）anon_req_标志要求在要发送给接受者的令牌中不传输启动器的身份。
The conf_req_flag and integ_req_flag provide informatory inputs to the GSS-API implementation as to whether, respectively, per-message confidentiality and per-message integrity services will be required on the context. This information is important as an input to negotiating mechanisms. It is important to recognize, however, that the inclusion of these flags (which are newly defined for GSS-V2) introduces a backward incompatibility with callers implemented to GSS-V1, where the flags were not defined. Since no GSS-V1 callers would set these flags, even if per-message services are desired, GSS-V2 mechanism implementations which enable such services selectively based on the flags' values may fail to provide them to contexts established for GSS-V1 callers. It may be appropriate under certain circumstances, therefore, for such mechanism implementations to infer these service request flags to be set if a caller is known to be implemented to GSS-V1.
conf_req_标志和integ_req_标志向GSS-API实现提供信息输入，分别说明上下文是否需要每条消息的机密性和每条消息的完整性服务。这一信息作为谈判机制的一项投入十分重要。但是，必须认识到，包含这些标志（为GSS-V2新定义）会导致与GSS-V1中未定义标志的调用方的向后不兼容。由于没有GSS-V1呼叫者会设置这些标志，即使需要每消息服务，基于标志值选择性启用此类服务的GSS-V2机制实现可能无法将它们提供给为GSS-V1呼叫者建立的上下文。因此，在某些情况下，如果已知调用方已实现GSS-V1，则此类机制实现可以推断要设置的这些服务请求标志。
Not all of the optionally-requestable features will be available in all underlying mech_types. The corresponding return state values deleg_state, mutual_state, replay_det_state, and sequence_state indicate, as a function of mech_type processing capabilities and initiator-provided input flags, the set of features which will be active on the context. The returned trans_state value indicates whether the context is transferable to other processes through use of GSS_Export_sec_context(). These state indicators' values are undefined unless either the routine's major_status indicates GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED major_status; for the latter case, it is possible that additional features, not confirmed or indicated along with TRUE prot_ready_state, will be confirmed and indicated when GSS_S_COMPLETE is subsequently returned.
并非所有可选的可请求功能在所有基础机械类型中都可用。相应的返回状态值deleg_state、mutual_state、replay_det_state和sequence_state表示，作为机械类型处理能力和启动器提供的输入标志的函数，将在上下文中激活的功能集。返回的trans_state值指示上下文是否可以通过使用GSS_Export_sec_context（）转移到其他进程。这些状态指示器的值未定义，除非例程的主要状态指示GSS\U s\U完成，或者返回真正的prot\U ready\U状态以及GSS\U s\U CONTINUE\U所需的主要状态；对于后一种情况，在随后返回GSS_S_COMPLETE时，可能会确认和指示未确认或未与真正的prot_ready_状态一起指示的附加功能。
The returned anon_state and prot_ready_state values are significant for both GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED major_status returns from GSS_Init_sec_context(). When anon_state is returned TRUE, this indicates that neither the current token nor its predecessors delivers or has delivered the initiator's identity. Callers wishing to perform context establishment only if anonymity support is provided should transfer a returned token from GSS_Init_sec_context() to the peer only if it is accompanied by a TRUE anon_state indicator. When prot_ready_state is returned TRUE in conjunction with GSS_S_CONTINUE_NEEDED major_status, this indicates that per-message protection operations may be applied on the context: see Section 1.2.7 for further discussion of this facility.
返回的anon_状态和prot_ready_状态值对于GSS_S_COMPLETE和GSS_CONTINUE_需要从GSS_Init_sec_context（）返回的主要_状态都很重要。当anon_状态返回TRUE时，这表示当前令牌或其前辈均未传递或已传递启动器的标识。仅当提供匿名性支持时，希望执行上下文建立的调用方应将返回的令牌从GSS_Init_sec_context（）传输到对等方，前提是该令牌带有真正的anon_状态指示符。当prot_ready_状态与GSS_S_CONTINUE_Required major_状态一起返回TRUE时，这表明可在上下文中应用每条消息保护操作：有关此功能的进一步讨论，请参阅第1.2.7节。
Failure to provide the precise set of features requested by the caller does not cause context establishment to fail; it is the caller's prerogative to delete the context if the feature set provided is unsuitable for the caller's use.
未能提供调用方请求的精确功能集不会导致上下文建立失败；如果提供的功能集不适合调用者使用，调用者有权删除上下文。
The returned mech_type value indicates the specific mechanism employed on the context; it will never indicate the value for "default". A valid mech_type result must be returned along with a GSS_S_COMPLETE status return; GSS-API implementations may (but are not required to) also return mech_type along with predecessor calls indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is determinable) in conjunction with fatal error cases. For the case of mechanisms which themselves perform negotiation, the returned mech_type result may indicate selection of a mechanism identified by an OID different than that passed in the input mech_type argument, and the returned value may change between successive calls returning GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
返回的mech_type值指示上下文中使用的特定机制；它永远不会指示“默认”的值。有效的机械类型结果必须与GSS_S_完成状态返回一起返回；GSS-API实现还可以（但不要求）返回mech_类型以及指示GSS_S_CONTINUE_所需状态的前置调用，或者（如果机制是可确定的）与致命错误情况一起返回。对于本身执行协商的机制的情况，返回的mech_类型结果可能表示选择了由OID标识的机制，该OID不同于输入mech_类型参数中传递的OID，并且返回值可能在返回GSS_S_CONTINUE_NEEDED的连续调用和返回GSS_S_COMPLETE的最终调用之间发生变化。
The conf_avail return value indicates whether the context supports per-message confidentiality services, and so informs the caller whether or not a request for encryption through the conf_req_flag input to GSS_Wrap() can be honored. In similar fashion, the integ_avail return value indicates whether per-message integrity services are available (through either GSS_GetMIC() or GSS_Wrap()) on the established context. These state indicators' values are undefined unless either the routine's major_status indicates GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED major_status.
conf_avail返回值指示上下文是否支持每条消息的机密性服务，从而通知调用方是否可以接受通过输入到GSS_Wrap（）的conf_req_标志进行加密的请求。以类似的方式，integ_avail返回值指示在已建立的上下文中每消息完整性服务是否可用（通过GSS_GetMIC（）或GSS_Wrap（））。这些状态指示器的值未定义，除非例程的主要状态指示GSS\U s\U完成，或者返回真正的prot\U ready\U状态以及GSS\U s\U CONTINUE\U所需的主要状态。
The lifetime_req input specifies a desired upper bound for the lifetime of the context to be established, with a value of 0 used to request a default lifetime. The lifetime_rec return value indicates the length of time for which the context will be valid, expressed as an offset from the present; depending on mechanism capabilities, credential lifetimes, and local policy, it may not correspond to the value requested in lifetime_req. If no constraints on context lifetime are imposed, this may be indicated by returning a reserved value representing INDEFINITE lifetime_req. The value of lifetime_rec is undefined unless the routine's major_status indicates GSS_S_COMPLETE.
lifetime_req输入指定要建立的上下文的生存期的期望上限，值0用于请求默认生存期。lifetime_rec返回值表示上下文有效的时间长度，表示为与当前的偏移量；根据机制功能、凭据生存期和本地策略，它可能与生存期_req中请求的值不对应。如果没有对上下文生存期施加任何约束，则可以通过返回表示无限生存期的保留值来表示。除非例程的主_状态指示GSS_s_完成，否则生命周期_rec的值未定义。
If the mutual_state is TRUE, this fact will be reflected within the output_token. A call to GSS_Accept_sec_context() at the target in conjunction with such a context will return a token, to be processed by a continuation call to GSS_Init_sec_context(), in order to achieve mutual authentication.
如果相互_状态为TRUE，则此事实将反映在输出_令牌中。在目标位置调用GSS_Accept_sec_context（）并结合此类上下文将返回一个令牌，该令牌将由对GSS_Init_sec_context（）的继续调用处理，以实现相互身份验证。
2.2.2: GSS_Accept_sec_context call
2.2.2:GSS_接受_秒_上下文调用
Inputs:
投入：
o acceptor_cred_handle CREDENTIAL HANDLE, -- NULL specifies -- "use default"
o acceptor_cred_handle凭证句柄，-NULL指定--“使用默认值”
o input_context_handle CONTEXT HANDLE, -- 0 -- (GSS_C_NO_CONTEXT) specifies "not yet assigned"
o 输入上下文句柄上下文句柄，-0--（GSS\U C\U NO\U上下文）指定“尚未分配”
o chan_bindings OCTET STRING,
o chan_绑定八位字节字符串，
o input_token OCTET STRING
o 输入令牌八位字节字符串
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o src_name INTERNAL NAME, -- guaranteed to be MN -- once returned, caller must release with GSS_Release_name()
o src_name INTERNAL name，--保证为MN-一旦返回，调用方必须使用GSS_release_name（）释放
o mech_type OBJECT IDENTIFIER, -- caller should treat as -- read-only; does not need to be released
o mech_类型对象标识符，--调用方应视为--read-only；不需要释放
o output_context_handle CONTEXT HANDLE, -- once returned -- non-NULL in context establishment sequence, caller -- must release with GSS_Delete_sec_context()
o output_context_handle context handle，--一旦返回--在上下文建立序列中为非NULL，调用者--必须使用GSS_Delete_sec_context（）释放
o deleg_state BOOLEAN,
o deleg_状态布尔值，
o mutual_state BOOLEAN,
o 相互状态布尔值，
o replay_det_state BOOLEAN,
o replay_det_state布尔值，
o sequence_state BOOLEAN,
o 序列状态布尔，
o anon_state BOOLEAN,
o 无状态布尔值，
o trans_state BOOLEAN,
o trans_状态布尔值，
o prot_ready_state BOOLEAN, -- see Section 1.2.7 for discussion
o 保护就绪状态布尔值，--见第1.2.7节讨论
o conf_avail BOOLEAN,
o conf_，
o integ_avail BOOLEAN,
o 整型布尔型，
o lifetime_rec INTEGER, -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec INTEGER，-以秒为单位，或为--Unfinite保留值
o delegated_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL, -- caller must release with GSS_Release_cred()
o 委托的\u cred\u handle凭证句柄，-如果返回非NULL，-调用方必须使用GSS\u release\u cred（）释放
o output_token OCTET STRING -- NULL or token to pass to context -- initiator; if returned non-NULL, caller must release with -- GSS_Release_buffer()
o 输出_令牌八位字节字符串——NULL或要传递给上下文的令牌——启动器；如果返回非NULL，则调用方必须使用--GSS_release_buffer（）释放
This call may block pending network interactions for those mech_types in which a directory service or other network entity must be consulted on behalf of a context acceptor in order to validate a received input_token.
此调用可能会阻止这些mech_类型的挂起网络交互，在这些mech_类型中，为了验证接收到的输入_令牌，必须代表上下文接受者咨询目录服务或其他网络实体。
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that context-level data structures were successfully initialized, and that per-message processing can now be performed in conjunction with this context.
o GSS_S_COMPLETE表示上下文级别的数据结构已成功初始化，每个消息处理现在可以与此上下文一起执行。
o GSS_S_CONTINUE_NEEDED indicates that control information in the returned output_token must be sent to the initiator, and that a response must be received and passed as the input_token argument to a continuation call to GSS_Accept_sec_context(), before per-message processing can be performed in conjunction with this context.
o GSS_S_CONTINUE_NEEDED表示返回的输出_令牌中的控制信息必须发送给启动器，并且必须接收响应并将其作为输入_令牌参数传递给GSS_Accept_sec_context（），然后才能结合此上下文执行每条消息处理。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the input_token failed, preventing further processing from being performed based on that token.
o GSS_S_DEFECTIVE_TOKEN表示对输入_TOKEN执行的一致性检查失败，从而阻止基于该TOKEN执行进一步的处理。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks performed on the credential structure referenced by acceptor_cred_handle failed, preventing further processing from being performed using that credential structure.
o GSS_S_DEFECTIVE_CREDENTIAL表示对由acceptor_cred_handle引用的凭据结构执行的一致性检查失败，从而阻止使用该凭据结构执行进一步的处理。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received input_token contains an incorrect integrity check, so context setup cannot be accomplished.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）表示接收到的输入_令牌包含不正确的完整性检查，因此无法完成上下文设置。
o GSS_S_DUPLICATE_TOKEN indicates that the integrity check on the received input_token was correct, but that the input_token was recognized as a duplicate of an input_token already processed. No new context is established.
o GSS_S_DUPLICATE_TOKEN表示对接收到的输入_TOKEN进行的完整性检查是正确的，但输入_TOKEN被识别为已处理的输入_TOKEN的副本。没有建立新的背景。
o GSS_S_OLD_TOKEN indicates that the integrity check on the received input_token was correct, but that the input_token is too old to be checked for duplication against previously-processed input_tokens. No new context is established.
o GSS_S_OLD_令牌表示对接收到的输入_令牌进行的完整性检查是正确的，但输入_令牌太旧，无法与先前处理的输入_令牌进行重复检查。没有建立新的背景。
o GSS_S_NO_CRED indicates that no context was established, either because the input cred_handle was invalid, because the referenced credentials are valid for context initiator use only, because the caller lacks authorization to access the referenced credentials, or because the procedure for default credential resolution failed.
o GSS_S_NO_CRED表示未建立上下文，原因可能是输入CRED_句柄无效、引用的凭据仅对上下文启动器有效、调用方无权访问引用的凭据或默认凭据解析过程失败。
o GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided through the input acceptor_cred_handle argument are no longer valid, so context establishment cannot be completed.
o GSS_S_CREDENTIALS_EXPIRED表示通过输入接受器\u cred_handle参数提供的凭据不再有效，因此无法完成上下文建立。
o GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-provided chan_bindings and those extracted from the input_token was detected, signifying a security-relevant event and preventing context establishment.
o GSS_S_BAD_绑定表示检测到调用者提供的chan_绑定与从输入_令牌提取的chan_绑定之间不匹配，表示存在安全相关事件并阻止上下文建立。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided; this major status will be returned only for successor calls following GSS_S_CONTINUE_ NEEDED status returns.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文；此主要状态将仅在GSS_S_CONTINUE_所需状态返回后，为后续调用返回。
o GSS_S_BAD_MECH indicates receipt of a context establishment token specifying a mechanism unsupported by the local system or with the caller's active credentials.
o GSS_S_BAD_MECH表示接收到上下文建立令牌，该令牌指定本地系统或调用方的活动凭据不支持的机制。
o GSS_S_FAILURE indicates that context setup could not be accomplished for reasons unspecified at the GSS-API level, and that no interface-defined recovery action is available.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法完成上下文设置，并且没有接口定义的恢复操作可用。
The GSS_Accept_sec_context() routine is used by a context target. Using information in the credentials structure referenced by the input acceptor_cred_handle, it verifies the incoming input_token and (following the successful completion of a context establishment sequence) returns the authenticated src_name and the mech_type used. The returned src_name is guaranteed to be an MN, processed by the mechanism under which the context was established. The acceptor_cred_handle must correspond to the same valid credentials structure on the initial call to GSS_Accept_sec_context() and on any successor calls resulting from GSS_S_CONTINUE_NEEDED status returns; different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED mechanism will require access to credentials at different points in the context establishment sequence.
上下文目标使用GSS_Accept_sec_context（）例程。使用输入接受器\u cred\u句柄引用的凭据结构中的信息，它验证传入的输入\u令牌，并（在成功完成上下文建立序列后）返回经过身份验证的src\u名称和使用的机械类型。返回的src_名称保证为MN，由建立上下文的机制处理。acceptor_cred_句柄必须对应于对GSS_Accept_sec_context（）的初始调用和由GSS_S_CONTINUE_Required status returns产生的任何后续调用上的相同有效凭据结构；由GSS_S_CONTINUE_NEEDED机制建模的不同协议序列将需要在上下文建立序列的不同点访问凭据。
The caller-provided input_context_handle argument is to be 0 (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first GSS_Accept_sec_context() call relating to a given context. If successful (i.e., if accompanied by major_status GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the initial GSS_Accept_sec_context() call returns a non-zero output_context_handle for use in future references to this context. Once a non-zero output_context_handle has been returned, GSS-API callers should call GSS_Delete_sec_context() to release context-related resources if errors occur in later phases of context establishment, or when an established context is no longer required. If GSS_Accept_sec_context() is passed the handle of a context which is already fully established, GSS_S_FAILURE status is returned.
在与给定上下文相关的第一个GSS_Accept_sec_context（）调用中，调用方提供的输入_context_handle参数为0（GSS_C_NO_context），并指定“尚未分配”。如果成功（即，如果伴随着主要状态GSS\U S\U COMPLETE或GSS\U S\U CONTINUE\U Required），并且仅当成功时，初始GSS\U Accept\U sec\U context（）调用返回一个非零输出\U context\U句柄，供将来引用此上下文时使用。返回非零输出上下文句柄后，如果在上下文建立的后续阶段出现错误，或者不再需要已建立的上下文，则GSS-API调用方应调用GSS_Delete_sec_context（）来释放上下文相关资源。如果向GSS_Accept_sec_context（）传递已完全建立的上下文的句柄，则返回GSS_S_故障状态。
The chan_bindings argument is used by the caller to provide information binding the security context to security-related characteristics (e.g., addresses, cryptographic keys) of the underlying communications channel. See Section 1.1.6 of this document for more discussion of this argument's usage.
调用者使用chan_bindings参数来提供将安全上下文绑定到基础通信信道的安全相关特征（例如，地址、加密密钥）的信息。有关此参数用法的更多讨论，请参见本文件第1.1.6节。
The returned state results (deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, and prot_ready_state) reflect the same information as described for GSS_Init_sec_context(), and their values are significant under the same return state conditions.
返回的状态结果（deleg_状态、MULTE_状态、RELAY_det_状态、sequence_状态、anon_状态、trans_状态和prot_ready_状态）反映了与GSS_Init_sec_context（）相同的信息，它们的值在相同的返回状态条件下是有效的。
The conf_avail return value indicates whether the context supports per-message confidentiality services, and so informs the caller whether or not a request for encryption through the conf_req_flag input to GSS_Wrap() can be honored. In similar fashion, the integ_avail return value indicates whether per-message integrity services are available (through either GSS_GetMIC() or GSS_Wrap()) on the established context. These values are significant under the same return state conditions as described under GSS_Init_sec_context().
conf_avail返回值指示上下文是否支持每条消息的机密性服务，从而通知调用方是否可以接受通过输入到GSS_Wrap（）的conf_req_标志进行加密的请求。以类似的方式，integ_avail返回值指示在已建立的上下文中每消息完整性服务是否可用（通过GSS_GetMIC（）或GSS_Wrap（））。这些值在GSS_Init_sec_context（）中描述的相同返回状态条件下有效。
The lifetime_rec return value is significant only in conjunction with GSS_S_COMPLETE major_status, and indicates the length of time for which the context will be valid, expressed as an offset from the present.
lifetime_rec返回值仅在GSS_S_COMPLETE major_状态下有效，并指示上下文有效的时间长度，表示为与当前的偏移量。
The returned mech_type value indicates the specific mechanism employed on the context; it will never indicate the value for "default". A valid mech_type result must be returned whenever GSS_S_COMPLETE status is indicated; GSS-API implementations may (but are not required to) also return mech_type along with predecessor calls indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is determinable) in conjunction with fatal error cases. For the case of
返回的mech_type值指示上下文中使用的特定机制；它永远不会指示“默认”的值。每当指示GSS\U S\U完成状态时，必须返回有效的机械类型结果；GSS-API实现还可以（但不要求）返回mech_类型以及指示GSS_S_CONTINUE_所需状态的前置调用，或者（如果机制是可确定的）与致命错误情况一起返回。就
mechanisms which themselves perform negotiation, the returned mech_type result may indicate selection of a mechanism identified by an OID different than that passed in the input mech_type argument, and the returned value may change between successive calls returning GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
机制本身执行协商，返回的mech_类型结果可能表示选择了由OID标识的机制，该OID与输入mech_类型参数中传递的OID不同，并且返回值可能在连续调用返回GSS_S_CONTINUE_NEEDED和最终调用返回GSS_S_COMPLETE之间发生变化。
The delegated_cred_handle result is significant only when deleg_state is TRUE, and provides a means for the target to reference the delegated credentials. The output_token result, when non-NULL, provides a context-level token to be returned to the context initiator to continue a multi-step context establishment sequence. As noted with GSS_Init_sec_context(), any returned token should be transferred to the context's peer (in this case, the context initiator), independent of the value of the accompanying returned major_status.
仅当deleg_状态为TRUE时，委托凭证句柄结果才有效，并为目标提供引用委托凭证的方法。当输出_令牌结果为非NULL时，将提供一个上下文级别的令牌，该令牌将返回给上下文启动器以继续多步骤上下文建立序列。如GSS_Init_sec_context（）所述，任何返回的令牌都应传输到上下文的对等方（在本例中为上下文启动器），而不受附带返回的主要_状态值的影响。
Note: A target must be able to distinguish a context-level input_token, which is passed to GSS_Accept_sec_context(), from the per-message data elements passed to GSS_VerifyMIC() or GSS_Unwrap(). These data elements may arrive in a single application message, and GSS_Accept_sec_context() must be performed before per-message processing can be performed successfully.
注意：目标必须能够区分传递给GSS_Accept_sec_context（）的上下文级输入_令牌与传递给GSS_VerifyMIC（）或GSS_Unwrap（）的每消息数据元素。这些数据元素可能在单个应用程序消息中到达，必须先执行GSS_Accept_sec_context（），然后才能成功执行每条消息的处理。
2.2.3: GSS_Delete_sec_context call
2.2.3:GSS_Delete_sec_上下文调用
Input:
输入：
o context_handle CONTEXT HANDLE
o 上下文句柄上下文句柄
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_context_token OCTET STRING
o 输出\u上下文\u令牌八位字节字符串
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the context was recognized, and that relevant context-specific information was flushed. If the caller provides a non-null buffer to receive an output_context_token, and the mechanism returns a non-NULL token into that buffer, the returned output_context_token is ready for transfer to the context's peer.
o GSS_S_COMPLETE表示上下文已被识别，相关上下文特定信息已刷新。如果调用方提供一个非空缓冲区来接收输出上下文令牌，并且该机制将一个非空令牌返回到该缓冲区中，那么返回的输出上下文令牌就可以传输到上下文的对等方。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided, so no deletion was performed.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文，因此未执行删除。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Delete_sec_context() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_失败表示上下文已被识别，但由于GSS-API级别未指定的原因，无法执行GSS_Delete_sec_context（）操作。
This call can be made by either peer in a security context, to flush context-specific information. Once a non-zero output_context_handle has been returned by context establishment calls, GSS-API callers should call GSS_Delete_sec_context() to release context-related resources if errors occur in later phases of context establishment, or when an established context is no longer required. This call may block pending network interactions for mech_types in which active notification must be made to a central server when a security context is to be deleted.
此调用可以由安全上下文中的任何一个对等方进行，以刷新特定于上下文的信息。一旦上下文建立调用返回了非零输出上下文句柄，GSS-API调用方应调用GSS_Delete_sec_context（），以便在上下文建立的后续阶段发生错误或不再需要已建立的上下文时释放上下文相关资源。此调用可能会阻止mech_类型的挂起网络交互，在这种类型中，当要删除安全上下文时，必须向中央服务器发出活动通知。
If a non-null output_context_token parameter is provided by the caller, an output_context_token may be returned to the caller. If an output_context_token is provided to the caller, it can be passed to the context's peer to inform the peer's GSS-API implementation that the peer's corresponding context information can also be flushed. (Once a context is established, the peers involved are expected to retain cached credential and context-related information until the information's expiration time is reached or until a GSS_Delete_sec_context() call is made.)
如果调用者提供了非空的输出上下文令牌参数，则输出上下文令牌可以返回给调用者。如果向调用方提供了输出上下文令牌，则可以将其传递给上下文的对等方，以通知对等方的GSS-API实现，对等方的相应上下文信息也可以刷新。（一旦建立了上下文，所涉及的对等方将保留缓存的凭据和上下文相关信息，直到信息过期或进行GSS_Delete_sec_context（）调用为止。）
The facility for context_token usage to signal context deletion is retained for compatibility with GSS-API Version 1. For current usage, it is recommended that both peers to a context invoke GSS_Delete_sec_context() independently, passing a null output_context_token buffer to indicate that no context_token is required. Implementations of GSS_Delete_sec_context() should delete relevant locally-stored context information.
为了与GSS-API版本1兼容，保留了使用上下文标记来表示上下文删除的功能。对于当前用法，建议上下文的两个对等方独立调用GSS_Delete_sec_context（），传递空输出_context_令牌缓冲区，以指示不需要上下文_令牌。GSS_Delete_sec_context（）的实现应该删除本地存储的相关上下文信息。
Attempts to perform per-message processing on a deleted context will result in error returns.
尝试对已删除的上下文执行每条消息处理将导致错误返回。
2.2.4: GSS_Process_context_token call
2.2.4:GSS_进程_上下文_令牌调用
Inputs:
投入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
o input_context_token OCTET STRING
o 输入\u上下文\u令牌八位字节字符串
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the input_context_token was successfully processed in conjunction with the context referenced by context_handle.
o GSS_S_COMPLETE表示输入_context_令牌已与context_handle引用的上下文一起成功处理。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the received context_token failed, preventing further processing from being performed with that token.
o GSS_S_DEFECTIVE_TOKEN表示对接收到的上下文_TOKEN执行的一致性检查失败，从而阻止使用该TOKEN执行进一步的处理。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Process_context_token() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_失败表示上下文已被识别，但由于GSS-API级别未指定的原因，无法执行GSS_进程_上下文_令牌（）操作。
This call is used to process context_tokens received from a peer once a context has been established, with corresponding impact on context-level state information. One use for this facility is processing of the context_tokens generated by GSS_Delete_sec_context(); GSS_Process_context_token() will not block pending network interactions for that purpose. Another use is to process tokens indicating remote-peer context establishment failures after the point where the local GSS-API implementation has already indicated GSS_S_COMPLETE status.
此调用用于在建立上下文后处理从对等方接收的上下文\ U令牌，并对上下文级别的状态信息产生相应的影响。此功能的一个用途是处理GSS_Delete_sec_context（）生成的上下文标记；GSS_进程_上下文_令牌（）不会为此阻止挂起的网络交互。另一个用途是在本地GSS-API实现已经指示GSS__完成状态之后，处理指示远程对等上下文建立失败的令牌。
2.2.5: GSS_Context_time call
2.2.5:GSS\U上下文\U时间调用
Input:
输入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec INTEGER--以秒为单位，或保留值--不确定
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the referenced context is valid, and will remain valid for the amount of time indicated in lifetime_rec.
o GSS_S_COMPLETE表示引用的上下文有效，并将在lifetime_rec中指示的时间内保持有效。
o GSS_S_CONTEXT_EXPIRED indicates that data items related to the referenced context have expired.
o GSS_S_CONTEXT_EXPIRED表示与引用的上下文相关的数据项已过期。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示请求的操作因GSS-API级别未指定的原因而失败。
This call is used to determine the amount of time for which a currently established context will remain valid.
此调用用于确定当前建立的上下文保持有效的时间量。
2.2.6: GSS_Inquire_context call
2.2.6:GSS_Inquire_上下文调用
Input:
输入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o src_name INTERNAL NAME, -- name of context initiator, -- guaranteed to be MN; -- caller must release with GSS_Release_name() if returned
o src_name INTERNAL name，--上下文启动器的名称，--保证为MN；--如果返回，调用方必须使用GSS\u release\u name（）释放
o targ_name INTERNAL NAME, -- name of context target, -- guaranteed to be MN; -- caller must release with GSS_Release_name() if returned
o target_name内部名称，--上下文目标的名称，--保证为MN；--如果返回，调用方必须使用GSS\u release\u name（）释放
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE or EXPIRED
o lifetime_rec INTEGER--以秒为单位，或保留值--不确定或过期
o mech_type OBJECT IDENTIFIER, -- the mechanism supporting this -- security context; caller should treat as read-only and not -- attempt to release
o mech_类型的对象标识符——支持该标识符的机制——安全上下文；调用方应将其视为只读，而不是--尝试释放
o deleg_state BOOLEAN,
o deleg_状态布尔值，
o mutual_state BOOLEAN,
o 相互状态布尔值，
o replay_det_state BOOLEAN,
o replay_det_state布尔值，
o sequence_state BOOLEAN,
o 序列状态布尔，
o anon_state BOOLEAN,
o 无状态布尔值，
o trans_state BOOLEAN,
o trans_状态布尔值，
o prot_ready_state BOOLEAN,
o 保护就绪状态布尔值，
o conf_avail BOOLEAN,
o conf_，
o integ_avail BOOLEAN,
o 整型布尔型，
o locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor
o 本地启动布尔值，-如果启动方为TRUE，如果接受方为FALSE
o open BOOLEAN, -- TRUE if context fully established, FALSE -- if partly established (in CONTINUE_NEEDED state)
o open BOOLEAN，-如果上下文完全建立，则为TRUE；如果部分建立，则为FALSE（处于继续状态）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the referenced context is valid and that deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, prot_ready_state, conf_avail, integ_avail, locally_initiated, and open return values describe the corresponding characteristics of the context. If open is TRUE, lifetime_rec is also returned: if open is TRUE and the context peer's name is known, src_name and targ_name are valid in addition to the values listed above. The mech_type value must be returned for contexts where open is TRUE and may be returned for contexts where open is FALSE.
o GSS_S_COMPLETE表示引用的上下文是有效的，并且deleg_状态、mutual_状态、replay_det_状态、sequence_状态、anon_状态、trans_状态、prot_ready_状态、conf_avail、integ_avail、local_initiated和open返回值描述了上下文的相应特征。如果open为TRUE，则还将返回lifetime_rec：如果open为TRUE且上下文对等方的名称已知，则src_name和target_name除上述值外均有效。对于open为TRUE的上下文，必须返回mech_类型值，对于open为FALSE的上下文，可以返回mech_类型值。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_故障表示请求的操作因GSS-API级别未指定的原因而失败。未定义除“主要”和“次要”状态以外的返回值。
This call is used to extract information describing characteristics of a security context. Note that GSS-API implementations are expected to retain inquirable context data on a context until the context is released by a caller, even after the context has expired, although underlying cryptographic data elements may be deleted after expiration in order to limit their exposure.
此调用用于提取描述安全上下文特征的信息。请注意，GSS-API实现预计将保留上下文上的可查询上下文数据，直到调用方释放该上下文，即使在该上下文已过期之后也是如此，尽管在过期之后可能会删除底层加密数据元素以限制其暴露。
2.2.7: GSS_Wrap_size_limit call
2.2.7:GSS_包装_尺寸_限制呼叫
Inputs:
投入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
o conf_req_flag BOOLEAN,
o conf_req_标志布尔值，
o qop INTEGER,
o qop整数，
o output_size INTEGER
o 输出大小整数
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o max_input_size INTEGER
o 最大输入大小整数
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates a successful token size determination: an input message with a length in octets equal to the returned max_input_size value will, when passed to GSS_Wrap() for processing on the context identified by the context_handle parameter with the confidentiality request state as provided in conf_req_flag and with the quality of protection specifier provided in the qop parameter, yield an output token no larger than the value of the provided output_size parameter.
o GSS_S_COMPLETE表示令牌大小确定成功：当传递给GSS_Wrap（）时，长度（以八位字节为单位）等于返回的max_input_size值的输入消息将对于在conf_req_标志中提供的机密性请求状态和qop参数中提供的保护质量说明符的context_handle参数标识的上下文上进行处理，生成的输出令牌不大于所提供的output_size参数的值。
o GSS_S_CONTEXT_EXPIRED indicates that the provided input context_handle is recognized, but that the referenced context has expired. Return values other than major_status and minor_status are undefined.
o GSS_S_CONTEXT_EXPIRED表示提供的输入上下文_句柄已被识别，但引用的上下文已过期。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_BAD_QOP indicates that the provided QOP value is not recognized or supported for the context.
o GSS_S_BAD_QOP表示上下文不识别或不支持提供的QOP值。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_故障表示请求的操作因GSS-API级别未指定的原因而失败。未定义除“主要”和“次要”状态以外的返回值。
This call is used to determine the largest input datum which may be passed to GSS_Wrap() without yielding an output token larger than a caller-specified value.
此调用用于确定可传递给GSS_Wrap（）的最大输入数据，而不会产生大于调用方指定值的输出标记。
2.2.8: GSS_Export_sec_context call
2.2.8:GSS_导出_秒_上下文调用
Inputs:
投入：
o context_handle CONTEXT HANDLE
o 上下文句柄上下文句柄
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o interprocess_token OCTET STRING -- caller must release -- with GSS_Release_buffer()
o 进程间\u令牌八位字节字符串--调用方必须释放--使用GSS\u释放\u缓冲区（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the referenced context has been successfully exported to a representation in the interprocess_token, and is no longer available for use by the caller.
o GSS_S_COMPLETE表示引用的上下文已成功导出到进程间_令牌中的表示，并且不再可供调用方使用。
o GSS_S_UNAVAILABLE indicates that the context export facility is not available for use on the referenced context. (This status should occur only for contexts for which the trans_state value is FALSE.) Return values other than major_status and minor_status are undefined.
o GSS_S_UNAVAILABLE表示上下文导出工具不可用于引用的上下文。（此状态只应出现在trans_状态值为FALSE的上下文中。）未定义除major_status和minor_status之外的返回值。
o GSS_S_CONTEXT_EXPIRED indicates that the provided input context_handle is recognized, but that the referenced context has expired. Return values other than major_status and minor_status are undefined.
o GSS_S_CONTEXT_EXPIRED表示提供的输入上下文_句柄已被识别，但引用的上下文已过期。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的有效上下文。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_故障表示请求的操作因GSS-API级别未指定的原因而失败。未定义除“主要”和“次要”状态以外的返回值。
This call generates an interprocess token for transfer to another process within an end system, in order to transfer control of a security context to that process. The recipient of the interprocess token will call GSS_Import_sec_context() to accept the transfer. The GSS_Export_sec_context() operation is defined for use only with security contexts which are fully and successfully established (i.e., those for which GSS_Init_sec_context() and GSS_Accept_sec_context() have returned GSS_S_COMPLETE major_status).
此调用生成一个进程间令牌，用于传输到终端系统中的另一个进程，以便将安全上下文的控制权传输到该进程。进程间令牌的收件人将调用GSS_Import_sec_context（）来接受传输。GSS_Export_sec_context（）操作定义为仅用于已完全成功建立的安全上下文（即，GSS_Init_sec_context（）和GSS_Accept_sec_context（）已返回GSS_COMPLETE mair_状态的安全上下文）。
A successful GSS_Export_sec_context() operation deactivates the security context for the calling process; for this case, the GSS-API implementation shall deallocate all process-wide resources associated with the security context and shall set the context_handle to GSS_C_NO_CONTEXT. In the event of an error that makes it impossible to complete export of the security context, the GSS-API implementation must not return an interprocess token and should strive to leave the security context referenced by the context_handle untouched. If this is impossible, it is permissible for the implementation to delete the security context, provided that it also sets the context_handle parameter to GSS_C_NO_CONTEXT.
成功的GSS_Export_sec_context（）操作将停用调用进程的安全上下文；对于这种情况，GSS-API实现应解除分配与安全上下文相关的所有进程范围资源，并将上下文句柄设置为GSS\U C\U NO\U上下文。如果出现无法完成安全上下文导出的错误，GSS-API实现不得返回进程间令牌，并应努力保持上下文句柄引用的安全上下文不变。如果这是不可能的，则允许实现删除安全上下文，前提是它还将context\u handle参数设置为GSS\u C\u NO\u context。
Portable callers must not assume that a given interprocess token can be imported by GSS_Import_sec_context() more than once, thereby creating multiple instantiations of a single context. GSS-API implementations may detect and reject attempted multiple imports, but are not required to do so.
可移植调用者不得假定给定的进程间令牌可以由GSS_Import_sec_context（）多次导入，从而创建单个上下文的多个实例化。GSS-API实现可以检测并拒绝尝试的多次导入，但不需要这样做。
The internal representation contained within the interprocess token is an implementation-defined local matter. Interprocess tokens cannot be assumed to be transferable across different GSS-API implementations.
进程间令牌中包含的内部表示是实现定义的本地事务。不能假设进程间令牌可以在不同的GSS-API实现之间转移。
It is recommended that GSS-API implementations adopt policies suited to their operational environments in order to define the set of processes eligible to import a context, but specific constraints in this area are local matters. Candidate examples include transfers between processes operating on behalf of the same user identity, or processes comprising a common job. However, it may be impossible to enforce such policies in some implementations.
建议GSS-API实现采用适合其操作环境的策略，以定义符合导入上下文条件的流程集，但该领域的特定约束是局部问题。候选示例包括代表相同用户身份运行的进程之间的传输，或包含公共作业的进程之间的传输。但是，在某些实现中可能无法强制执行此类策略。
In support of the above goals, implementations may protect the transferred context data by using cryptography to protect data within the interprocess token, or by using interprocess tokens as a means to reference local interprocess communication facilities (protected by other means) rather than storing the context data directly within the tokens.
为了支持上述目标，实现可以通过使用加密来保护进程间令牌内的数据，或者通过使用进程间令牌作为引用本地进程间通信设施（由其他手段保护）的手段来保护传输的上下文数据，而不是将上下文数据直接存储在令牌内。
Transfer of an open context may, for certain mechanisms and implementations, reveal data about the credential which was used to establish the context. Callers should, therefore, be cautious about the trustworthiness of processes to which they transfer contexts. Although the GSS-API implementation may provide its own set of protections over the exported context, the caller is responsible for protecting the interprocess token from disclosure, and for taking care that the context is transferred to an appropriate destination process.
对于某些机制和实现，开放上下文的传输可能会显示用于建立上下文的凭证的数据。因此，调用者应该对其将上下文传输到的进程的可信度保持谨慎。尽管GSS-API实现可以对导出的上下文提供自己的一组保护，但调用方负责保护进程间令牌不被泄露，并负责将上下文传输到适当的目标进程。
2.2.9: GSS_Import_sec_context call
2.2.9:GSS_导入_秒_上下文调用
Inputs:
投入：
o interprocess_token OCTET STRING
o 进程间令牌八位字节字符串
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o context_handle CONTEXT HANDLE -- if successfully returned, -- caller must release with GSS_Delete_sec_context()
o context_handle context handle--如果成功返回，--调用方必须使用GSS_Delete_sec_context（）释放
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the context represented by the input interprocess_token has been successfully transferred to the caller, and is available for future use via the output context_handle.
o GSS_S_COMPLETE表示输入进程间_令牌表示的上下文已成功传输到调用方，并可通过输出上下文_句柄供将来使用。
o GSS_S_NO_CONTEXT indicates that the context represented by the input interprocess_token was invalid. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXT表示由输入进程间_令牌表示的上下文无效。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token was defective. Return values other than major_status and minor_status are undefined.
o GSS_S_DEFECTIVE_令牌表示输入进程间_令牌有缺陷。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_UNAVAILABLE indicates that the context import facility is not available for use on the referenced context. Return values other than major_status and minor_status are undefined.
o GSS_S_UNAVAILABLE表示上下文导入工具不可用于引用的上下文。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_UNAUTHORIZED indicates that the context represented by the input interprocess_token is unauthorized for transfer to the caller. Return values other than major_status and minor_status are undefined.
o GSS_S_UNAUTHORIZED表示输入进程间_令牌表示的上下文未经授权传输到调用方。未定义除“主要”和“次要”状态以外的返回值。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_故障表示请求的操作因GSS-API级别未指定的原因而失败。未定义除“主要”和“次要”状态以外的返回值。
This call processes an interprocess token generated by GSS_Export_sec_context(), making the transferred context available for use by the caller. After a successful GSS_Import_sec_context() operation, the imported context is available for use by the importing process. In particular, the imported context is usable for all per-message operations and may be deleted or exported by its importer. The inability to receive delegated credentials through
此调用处理由GSS_Export_sec_context（）生成的进程间令牌，使传输的上下文可供调用方使用。成功执行GSS_Import_sec_context（）操作后，导入的上下文可供导入进程使用。特别是，导入的上下文可用于所有每消息操作，并可由其导入器删除或导出。无法通过接收委派凭据
gss_import_sec_context() precludes establishment of new contexts based on information delegated to the importer's end system within the context which is being imported, unless those delegated credentials are obtained through separate routines (e.g., XGSS-API calls) outside the GSS-V2 definition.
gss_import_sec_context（）禁止在导入的上下文中基于委托给导入方终端系统的信息建立新上下文，除非这些委托凭证是通过gss-V2定义之外的单独例程（如XGSS-API调用）获得的。
For further discussion of the security and authorization issues regarding this call, please see the discussion in Section 2.2.8.
有关此呼叫的安全和授权问题的进一步讨论，请参阅第2.2.8节中的讨论。
2.3: Per-message calls
2.3：每封邮件呼叫
This group of calls is used to perform per-message protection processing on an established security context. None of these calls block pending network interactions. These calls may be invoked by a context's initiator or by the context's target. The four members of this group should be considered as two pairs; the output from GSS_GetMIC() is properly input to GSS_VerifyMIC(), and the output from GSS_Wrap() is properly input to GSS_Unwrap().
这组调用用于在已建立的安全上下文上执行每条消息的保护处理。这些调用都不会阻止挂起的网络交互。这些调用可以由上下文的启动器调用，也可以由上下文的目标调用。该组的四名成员应视为两对；GSS_GetMIC（）的输出正确输入到GSS_VerifyMIC（），GSS_Wrap（）的输出正确输入到GSS_Unwrap（）。
GSS_GetMIC() and GSS_VerifyMIC() support data origin authentication and data integrity services. When GSS_GetMIC() is invoked on an input message, it yields a per-message token containing data items which allow underlying mechanisms to provide the specified security services. The original message, along with the generated per-message token, is passed to the remote peer; these two data elements are processed by GSS_VerifyMIC(), which validates the message in conjunction with the separate token.
GSS_GetMIC（）和GSS_VerifyMIC（）支持数据源身份验证和数据完整性服务。当对输入消息调用GSS_GetMIC（）时，它会生成一个每消息令牌，其中包含允许底层机制提供指定安全服务的数据项。原始消息以及生成的每消息令牌被传递给远程对等方；这两个数据元素由GSS_VerifyMIC（）处理，它与单独的令牌一起验证消息。
GSS_Wrap() and GSS_Unwrap() support caller-requested confidentiality in addition to the data origin authentication and data integrity services offered by GSS_GetMIC() and GSS_VerifyMIC(). GSS_Wrap() outputs a single data element, encapsulating optionally enciphered user data as well as associated token data items. The data element output from GSS_Wrap() is passed to the remote peer and processed by GSS_Unwrap() at that system. GSS_Unwrap() combines decipherment (as required) with validation of data items related to authentication and integrity.
除了GSS_GetMIC（）和GSS_VerifyMIC（）提供的数据源身份验证和数据完整性服务外，GSS_Wrap（）和GSS_Unwrap（）还支持调用方请求的保密性。GSS_Wrap（）输出单个数据元素，封装可选加密的用户数据以及相关的令牌数据项。GSS_Wrap（）的数据元素输出被传递到远程对等方，并由该系统上的GSS_Unwrap（）进行处理。GSS_Unwrap（）将解密（根据需要）与验证与身份验证和完整性相关的数据项相结合。
Although zero-length tokens are never returned by GSS calls for transfer to a context's peer, a zero-length object may be passed by a caller into GSS_Wrap(), in which case the corresponding peer calling GSS_Unwrap() on the transferred token will receive a zero-length object as output from GSS_Unwrap(). Similarly, GSS_GetMIC() can be called on an empty object, yielding a MIC which GSS_VerifyMIC() will successfully verify against the active security context in conjunction with a zero-length object.
尽管零长度令牌从不由GSS调用返回以传输到上下文的对等方，但零长度对象可能会由调用方传递到GSS_Wrap（），在这种情况下，在传输的令牌上调用GSS_Unwrap（）的对应对等方将从GSS_Unwrap（）接收一个零长度对象作为输出。类似地，可以对空对象调用GSS_GetMIC（），生成一个MIC，GSS_VerifyMIC（）将与零长度对象一起根据活动安全上下文成功验证该MIC。
2.3.1: GSS_GetMIC call
2.3.1:GSS_GetMIC呼叫
Note: This call is functionally equivalent to the GSS_Sign call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Sign are deprecated.
注：此调用在功能上等同于本规范先前版本中定义的GSS_符号调用。为了向后兼容，建议目前实现支持两个名称下的此函数；不推荐将来将此函数引用为GSS_符号。
Inputs:
投入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
o qop_req INTEGER, -- 0 specifies default QOP
o qop_req INTEGER，--0指定默认qop
o message OCTET STRING
o 消息八位组字符串
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o per_msg_token OCTET STRING -- caller must release -- with GSS_Release_buffer()
o per_msg_令牌八位字节字符串--调用方必须释放--使用GSS_release_buffer（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that an integrity check, suitable for an established security context, was successfully applied and that the message and corresponding per_msg_token are ready for transmission.
o GSS_S_COMPLETE表示适用于已建立安全上下文的完整性检查已成功应用，并且消息和相应的per_msg_令牌已准备好传输。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o GSS_S_CONTEXT_EXPIRED表示与上下文相关的数据项已过期，因此无法执行请求的操作。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的上下文。
o GSS_S_BAD_QOP indicates that the provided QOP value is not recognized or supported for the context.
o GSS_S_BAD_QOP表示上下文不识别或不支持提供的QOP值。
o GSS_S_FAILURE indicates that the context is recognized, but that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示上下文已被识别，但由于GSS-API级别未指定的原因，无法执行请求的操作。
Using the security context referenced by context_handle, apply an integrity check to the input message (along with timestamps and/or other data included in support of mech_type-specific mechanisms) and (if GSS_S_COMPLETE status is indicated) return the result in
使用context_handle引用的安全上下文，对输入消息应用完整性检查（以及时间戳和/或支持mech_类型特定机制的其他数据），并（如果指示GSS_S_完成状态）在
per_msg_token. The qop_req parameter, interpretation of which is discussed in Section 1.2.4, allows quality-of-protection control. The caller passes the message and the per_msg_token to the target.
每个消息令牌。第1.2.4节讨论了qop_req参数的解释，该参数允许保护质量控制。调用者将消息和per_msg_令牌传递给目标。
The GSS_GetMIC() function completes before the message and per_msg_token is sent to the peer; successful application of GSS_GetMIC() does not guarantee that a corresponding GSS_VerifyMIC() has been (or can necessarily be) performed successfully when the message arrives at the destination.
GSS_GetMIC（）函数在消息和per_msg_令牌发送到对等方之前完成；成功应用GSS_GetMIC（）并不能保证在消息到达目的地时已成功执行（或必须执行）相应的GSS_VerifyMIC（）。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
如果调用此例程，则不支持每消息保护服务的机制应返回GSS_故障。
2.3.2: GSS_VerifyMIC call
2.3.2:GSS_验证呼叫
Note: This call is functionally equivalent to the GSS_Verify call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Verify are deprecated.
注意：此调用在功能上等同于本规范先前版本中定义的GSS_验证调用。为了向后兼容，建议目前实现支持两个名称下的此函数；不推荐将来在GSS\U验证时引用此函数。
Inputs:
投入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
o message OCTET STRING,
o 消息八位组字符串，
o per_msg_token OCTET STRING
o per_msg_令牌八位字节字符串
Outputs:
产出：
o qop_state INTEGER,
o qop_状态整数，
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the message was successfully verified.
o GSS_S_COMPLETE表示消息已成功验证。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the received per_msg_token failed, preventing further processing from being performed with that token.
o GSS_S_DEFECTIVE_TOKEN表示对收到的per_msg_TOKEN执行的一致性检查失败，从而阻止使用该TOKEN执行进一步的处理。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received per_msg_token contains an incorrect integrity check for the message.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）表示收到的per_msg_令牌包含不正确的消息完整性检查。
o GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN values appear in conjunction with the optional per-message replay detection features described in Section 1.2.3; their semantics are described in that section.
o GSS_S_DUPLICATE_TOKEN、GSS_S_OLD_TOKEN、GSS_UNSEQ_TOKEN和GSS_GAP_TOKEN值与第1.2.3节中描述的可选每条消息重播检测功能一起出现；它们的语义在该部分中进行了描述。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o GSS_S_CONTEXT_EXPIRED表示与上下文相关的数据项已过期，因此无法执行请求的操作。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的上下文。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_VerifyMIC() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_失败表示上下文已被识别，但由于GSS-API级别未指定的原因，无法执行GSS_VerifyMIC（）操作。
Using the security context referenced by context_handle, verify that the input per_msg_token contains an appropriate integrity check for the input message, and apply any active replay detection or sequencing features. Returns an indication of the quality-of-protection applied to the processed message in the qop_state result.
使用context_handle引用的安全上下文，验证输入per_msg_令牌是否包含输入消息的适当完整性检查，并应用任何活动重播检测或排序功能。返回qop_状态结果中应用于已处理消息的保护质量指示。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
如果调用此例程，则不支持每消息保护服务的机制应返回GSS_故障。
2.3.3: GSS_Wrap call
2.3.3:GSS_包裹呼叫
Note: This call is functionally equivalent to the GSS_Seal call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Seal are deprecated.
注：此调用在功能上等同于本规范先前版本中定义的GSS_Seal调用。为了向后兼容，建议目前实现支持两个名称下的此函数；不推荐将来将此功能引用为GSS_Seal。
Inputs:
投入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
o conf_req_flag BOOLEAN,
o conf_req_标志布尔值，
o qop_req INTEGER, -- 0 specifies default QOP
o qop_req INTEGER，--0指定默认qop
o input_message OCTET STRING
o 输入消息八位字节字符串
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o conf_state BOOLEAN,
o 形态状态布尔值，
o output_message OCTET STRING -- caller must release with -- GSS_Release_buffer()
o 输出消息八位字节字符串--调用者必须使用--GSS\u release\u buffer（）释放
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the input_message was successfully processed and that the output_message is ready for transmission.
o GSS_S_COMPLETE表示输入_消息已成功处理，输出_消息已准备好传输。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o GSS_S_CONTEXT_EXPIRED表示与上下文相关的数据项已过期，因此无法执行请求的操作。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的上下文。
o GSS_S_BAD_QOP indicates that the provided QOP value is not recognized or supported for the context.
o GSS_S_BAD_QOP表示上下文不识别或不支持提供的QOP值。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Wrap() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_失败表示上下文已被识别，但由于GSS-API级别未指定的原因，无法执行GSS_Wrap（）操作。
Performs the data origin authentication and data integrity functions of GSS_GetMIC(). If the input conf_req_flag is TRUE, requests that confidentiality be applied to the input_message. Confidentiality may not be supported in all mech_types or by all implementations; the returned conf_state flag indicates whether confidentiality was provided for the input_message. The qop_req parameter, interpretation of which is discussed in Section 1.2.4, allows quality-of-protection control.
执行GSS_GetMIC（）的数据源身份验证和数据完整性功能。如果输入conf_req_标志为TRUE，则请求将机密性应用于输入_消息。并非所有机械类型或所有实现都支持保密性；返回的conf_状态标志指示是否为输入_消息提供了机密性。第1.2.4节讨论了qop_req参数的解释，该参数允许保护质量控制。
When GSS_S_COMPLETE status is returned, the GSS_Wrap() call yields a single output_message data element containing (optionally enciphered) user data as well as control information.
当返回GSS_S_COMPLETE状态时，GSS_Wrap（）调用将生成一个包含（可选加密）用户数据和控制信息的输出消息数据元素。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
如果调用此例程，则不支持每消息保护服务的机制应返回GSS_故障。
2.3.4: GSS_Unwrap call
2.3.4：GSS_展开呼叫
Note: This call is functionally equivalent to the GSS_Unseal call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Unseal are deprecated.
注意：此调用在功能上等同于本规范先前版本中定义的GSS_uncel调用。为了向后兼容，建议目前实现支持两个名称下的此函数；不推荐将来将此函数引用为GSS_uncel。
Inputs:
投入：
o context_handle CONTEXT HANDLE,
o 上下文句柄上下文句柄，
o input_message OCTET STRING
o 输入消息八位字节字符串
Outputs:
产出：
o conf_state BOOLEAN,
o 形态状态布尔值，
o qop_state INTEGER,
o qop_状态整数，
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_message OCTET STRING -- caller must release with -- GSS_Release_buffer()
o 输出消息八位字节字符串--调用者必须使用--GSS\u release\u buffer（）释放
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the input_message was successfully processed and that the resulting output_message is available.
o GSS_S_COMPLETE表示输入_消息已成功处理，并且生成的输出_消息可用。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the per_msg_token extracted from the input_message failed, preventing further processing from being performed.
o GSS_S_DEFECTIVE_TOKEN表示对从输入_消息提取的per_msg_TOKEN执行的一致性检查失败，无法执行进一步的处理。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that an incorrect integrity check was detected for the message.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）表示检测到消息的完整性检查不正确。
o GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN values appear in conjunction with the optional per-message replay detection features described in Section 1.2.3; their semantics are described in that section.
o GSS_S_DUPLICATE_TOKEN、GSS_S_OLD_TOKEN、GSS_UNSEQ_TOKEN和GSS_GAP_TOKEN值与第1.2.3节中描述的可选每条消息重播检测功能一起出现；它们的语义在该部分中进行了描述。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o GSS_S_CONTEXT_EXPIRED表示与上下文相关的数据项已过期，因此无法执行请求的操作。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXT表示未识别提供的输入上下文句柄的上下文。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Unwrap() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_失败表示上下文已被识别，但由于GSS-API级别未指定的原因，无法执行GSS_Unwrap（）操作。
Processes a data element generated (and optionally enciphered) by GSS_Wrap(), provided as input_message. The returned conf_state value indicates whether confidentiality was applied to the input_message. If conf_state is TRUE, GSS_Unwrap() has deciphered the input_message. Returns an indication of the quality-of-protection applied to the processed message in the qop_state result. GSS_Unwrap() performs the data integrity and data origin authentication checking functions of GSS_VerifyMIC() on the plaintext data. Plaintext data is returned in output_message.
处理GSS_Wrap（）生成（并可选加密）的数据元素，该数据元素作为输入_消息提供。返回的conf_state值指示是否对输入_消息应用了机密性。如果conf_state为TRUE，则GSS_Unwrap（）已解密输入_消息。返回qop_状态结果中应用于已处理消息的保护质量指示。GSS_Unwrap（）对明文数据执行GSS_VerifyMIC（）的数据完整性和数据源身份验证检查功能。明文数据在输出消息中返回。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
如果调用此例程，则不支持每消息保护服务的机制应返回GSS_故障。
2.4: Support calls
2.4：支持电话
This group of calls provides support functions useful to GSS-API callers, independent of the state of established contexts. Their characterization with regard to blocking or non-blocking status in terms of network interactions is unspecified.
这组调用提供对GSS-API调用方有用的支持函数，与已建立上下文的状态无关。它们在网络交互方面的阻塞或非阻塞状态的特征尚未确定。
2.4.1: GSS_Display_status call
2.4.1:GSS\U显示\U状态调用
Inputs:
投入：
o status_value INTEGER, -- GSS-API major_status or minor_status -- return value
o 状态\值整数，--GSS-API主要\状态或次要\状态--返回值
o status_type INTEGER, -- 1 if major_status, 2 if minor_status
o 状态\u类型整数，-1如果为主要\u状态，则为2如果为次要\u状态
o mech_type OBJECT IDENTIFIER -- mech_type to be used for -- minor_status translation
o 机械类型对象标识符——用于——次要机械状态转换的机械类型
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o status_string_set SET OF OCTET STRING -- required calls for -- release by caller are specific to language bindings
o status_string_set一组八位字节字符串——调用者释放所需的调用——特定于语言绑定
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that a valid printable status representation (possibly representing more than one status event encoded within the status_value) is available in the returned status_string_set.
o GSS_S_COMPLETE表示返回的状态_字符串_集中存在有效的可打印状态表示（可能表示状态_值中编码的多个状态事件）。
o GSS_S_BAD_MECH indicates that translation in accordance with an unsupported mech_type was requested, so translation could not be performed.
o GSS_S_BAD_MECH表示请求按照不支持的MECH_类型进行翻译，因此无法执行翻译。
o GSS_S_BAD_STATUS indicates that the input status_value was invalid, or that the input status_type carried a value other than 1 or 2, so translation could not be performed.
o GSS_S_BAD_STATUS表示输入状态_值无效，或者输入状态_类型包含的值不是1或2，因此无法执行转换。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Provides a means for callers to translate GSS-API-returned major and minor status codes into printable string representations. Note: some language bindings may employ an iterative approach in order to emit successive status components; this approach is acceptable but not required for conformance with the current specification.
为调用者提供将GSS API返回的主要和次要状态代码转换为可打印字符串表示形式的方法。注意：一些语言绑定可能采用迭代的方法来发出连续的状态组件；这种方法是可以接受的，但不需要符合当前规范。
Although not contemplated in [RFC-2078], it has been observed that some existing GSS-API implementations return GSS_S_CONTINUE_NEEDED status when iterating through successive messages returned from GSS_Display_status(). This behavior is deprecated; GSS_S_CONTINUE_NEEDED should be returned only by GSS_Init_sec_context() and GSS_Accept_sec_context(). For maximal portability, however, it is recommended that defensive callers be able to accept and ignore GSS_S_CONTINUE_NEEDED status if indicated by GSS_Display_status() or any other call other than GSS_Init_sec_context() or GSS_Accept_sec_context().
尽管[RFC-2078]中未考虑，但已经观察到，一些现有的GSS-API实现在迭代从GSS_Display_status（）返回的连续消息时返回GSS_S_CONTINUE_NEEDED status（）。这种行为不受欢迎；所需的GSS_S_CONTINUE_应仅由GSS_Init_sec_context（）和GSS_Accept_sec_context（）返回。但是，为了实现最大的可移植性，建议防御调用方能够接受和忽略GSS_S_CONTINUE_Required status（）或GSS_Init_sec_context（）或GSS_accept_sec_context（）以外的任何其他调用指示的GSS_Display_status（）状态。
2.4.2: GSS_Indicate_mechs call
2.4.2:GSS_指示_机械呼叫
Input:
输入：
o (none)
o （无）
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o mech_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o 对象标识符的mech_集合--调用方必须释放--使用GSS_release_oid_集合（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that a set of available mechanisms has been returned in mech_set.
o GSS_S_COMPLETE表示已在mech_set中返回一组可用机制。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to determine the set of mechanism types available on the local system. This call is intended for support of specialized callers who need to request non-default mech_type sets from GSS-API calls which accept input mechanism type specifiers.
允许调用方确定本地系统上可用的机制类型集。此调用旨在支持需要从接受输入机制类型说明符的GSS-API调用中请求非默认mech_类型集的专用调用方。
2.4.3: GSS_Compare_name call
2.4.3:GSS_比较_名称调用
Inputs:
投入：
o name1 INTERNAL NAME,
o 名称1内部名称，
o name2 INTERNAL NAME
o 名称2内部名称
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o name_equal BOOLEAN
o name_等于布尔值
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that name1 and name2 were comparable, and that the name_equal result indicates whether name1 and name2 represent the same entity.
o GSS_S_COMPLETE表示name1和name2具有可比性，name_equal结果表示name1和name2是否代表同一实体。
o GSS_S_BAD_NAMETYPE indicates that the two input names' types are different and incomparable, so that the comparison operation could not be completed.
o GSS_S_BAD_NAMETYPE表示两个输入名称的类型不同且不可比较，因此无法完成比较操作。
o GSS_S_BAD_NAME indicates that one or both of the input names was ill-formed in terms of its internal type specifier, so the comparison operation could not be completed.
o GSS_S_BAD_NAME表示一个或两个输入名称的内部类型说明符格式不正确，因此无法完成比较操作。
o GSS_S_FAILURE indicates that the call's operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_失败表示由于GSS-API级别未指定的原因，调用的操作无法执行。
Allows callers to compare two internal name representations to determine whether they refer to the same entity. If either name presented to GSS_Compare_name() denotes an anonymous principal, GSS_Compare_name() shall indicate FALSE. It is not required that either or both inputs name1 and name2 be MNs; for some
允许调用方比较两个内部名称表示，以确定它们是否引用同一实体。如果呈现给GSS_Compare_name（）的任一名称表示匿名主体，则GSS_Compare_name（）应表示FALSE。不要求输入name1和name2中的一个或两个都是MNs；对一些人来说
implementations and cases, GSS_S_BAD_NAMETYPE may be returned, indicating name incomparability, for the case where neither input name is an MN.
在实现和案例中，如果两个输入名称都不是MN，则可能会返回GSS_S_BAD_NAMETYPE，表示名称不可比较。
2.4.4: GSS_Display_name call
2.4.4:GSS\u显示\u名称调用
Inputs:
投入：
o name INTERNAL NAME
o 名称内部名称
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o name_string OCTET STRING, -- caller must release -- with GSS_Release_buffer()
o name_string八进制字符串，--调用方必须释放--with GSS_release_buffer（）
o name_type OBJECT IDENTIFIER -- caller should treat -- as read-only; does not need to be released
o name_类型对象标识符——调用方应将其视为——只读；不需要释放
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that a valid printable name representation is available in the returned name_string.
o GSS_S_COMPLETE表示返回的名称字符串中存在有效的可打印名称表示。
o GSS_S_BAD_NAME indicates that the contents of the provided name were inconsistent with the internally-indicated name type, so no printable representation could be generated.
o GSS_S_BAD_NAME表示提供的名称的内容与内部指示的名称类型不一致，因此无法生成可打印的表示。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to translate an internal name representation into a printable form with associated namespace type descriptor. The syntax of the printable form is a local matter.
允许调用方将内部名称表示转换为具有关联命名空间类型描述符的可打印表单。可打印表单的语法是局部问题。
If the input name represents an anonymous identity, a reserved value (GSS_C_NT_ANONYMOUS) shall be returned for name_type.
如果输入名称表示匿名标识，则应为名称类型返回保留值（GSS_C_NT_anonymous）。
The GSS_C_NO_OID name type is to be returned only when the corresponding internal name was created through import with GSS_C_NO_OID. It is acceptable for mechanisms to normalize names imported with GSS_C_NO_OID into other supported types and, therefore, to display them with types other than GSS_C_NO_OID.
仅当通过使用GSS_C_NO_OID导入创建了相应的内部名称时，才会返回GSS_C_NO_OID名称类型。机制可以将使用GSS_C_NO_OID导入的名称规范化为其他受支持的类型，从而使用GSS_C_NO_OID以外的类型显示它们。
2.4.5: GSS_Import_name call
2.4.5:GSS\u导入\u名称调用
Inputs:
投入：
o input_name_string OCTET STRING,
o 输入\u名称\u字符串八位字符串，
o input_name_type OBJECT IDENTIFIER
o 输入\名称\类型对象标识符
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_name INTERNAL NAME -- caller must release with -- GSS_Release_name()
o output_name INTERNAL name--调用方必须使用--GSS_release_name（）释放
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that a valid name representation is output in output_name and described by the type value in output_name_type.
o GSS_S_COMPLETE表示输出_name中输出了有效的名称表示形式，并由输出_name_type中的type值描述。
o GSS_S_BAD_NAMETYPE indicates that the input_name_type is unsupported by the applicable underlying GSS-API mechanism(s), so the import operation could not be completed.
o GSS_S_BAD_NAMETYPE表示适用的底层GSS-API机制不支持输入_name_类型，因此无法完成导入操作。
o GSS_S_BAD_NAME indicates that the provided input_name_string is ill-formed in terms of the input_name_type, so the import operation could not be completed.
o GSS_S_BAD_NAME表示提供的输入_NAME_字符串在输入_NAME_类型方面格式不正确，因此无法完成导入操作。
o GSS_S_BAD_MECH indicates that the input presented for import was an exported name object and that its enclosed mechanism type was not recognized or was unsupported by the GSS-API implementation.
o GSS_S_BAD_MECH表示为导入提供的输入是导出的名称对象，GSS-API实现无法识别或不支持其封闭机制类型。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to provide a name representation as a contiguous octet string, designate the type of namespace in conjunction with which it should be parsed, and convert that representation to an internal form suitable for input to other GSS-API routines. The syntax of the input_name_string is defined in conjunction with its associated name type; depending on the input_name_type, the associated input_name_string may or may not be a printable string. If the input_name_type's value is GSS_C_NO_OID, a mechanism-specific default printable syntax (which shall be specified in the corresponding GSS-V2 mechanism specification) is assumed for the input_name_string;
允许调用方以连续八位字符串的形式提供名称表示，指定名称空间的类型，并将该表示转换为适合输入到其他GSS-API例程的内部形式。输入\名称\字符串的语法与相关名称类型一起定义；根据输入名称类型，关联的输入名称字符串可能是也可能不是可打印字符串。如果输入名称类型的值为GSS\U C\U NO\U OID，则输入名称字符串采用特定于机制的默认可打印语法（应在相应的GSS-V2机制规范中指定）；
other input_name_type values as registered by GSS-API implementations can be used to indicate specific non-default name syntaxes. Note: The input_name_type argument serves to describe and qualify the interpretation of the associated input_name_string; it does not specify the data type of the returned output_name.
GSS-API实现注册的其他输入\名称\类型值可用于指示特定的非默认名称语法。注意：input_name_type参数用于描述和限定关联的input_name_字符串的解释；它不指定返回的输出名称的数据类型。
If a mechanism claims support for a particular name type, its GSS_Import_name() operation shall be able to accept all possible values conformant to the external name syntax as defined for that name type. These imported values may correspond to:
如果机制声明支持特定名称类型，则其GSS_Import_name（）操作应能够接受符合该名称类型定义的外部名称语法的所有可能值。这些导入值可能对应于：
(1) locally registered entities (for which credentials may be acquired),
(1) 在当地注册的实体（可获取证书），
(2) non-local entities (for which local credentials cannot be acquired, but which may be referenced as targets of initiated security contexts or initiators of accepted security contexts), or to
(2) 非本地实体（无法获取本地凭据，但可以作为已启动安全上下文的目标或已接受安全上下文的启动器引用），或
(3) neither of the above.
(3) 以上两项都没有。
Determination of whether a particular name belongs to class (1), (2), or (3) as described above is not guaranteed to be performed by the GSS_Import_name() function.
GSS_Import_name（）函数不保证执行如上所述的特定名称是否属于类（1）、（2）或（3）的确定。
The internal name generated by a GSS_Import_name() operation may be a single-mechanism MN, and is likely to be an MN within a single-mechanism implementation, but portable callers must not depend on this property (and must not, therefore, assume that the output from GSS_Import_name() can be passed directly to GSS_Export_name() without first being processed through GSS_Canonicalize_name()).
GSS_Import_name（）操作生成的内部名称可能是单个机制MN，并且可能是单个机制实现中的MN，但是可移植调用方不能依赖于此属性（因此，不能假设GSS_Import_name（）的输出可以直接传递给GSS_Export_name（）不需要首先通过GSS_规范化_name（））进行处理。
2.4.6: GSS_Release_name call
2.4.6:GSS_发布_名称调用
Inputs:
投入：
o name INTERNAL NAME
o 名称内部名称
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER
o 次要状态整数
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the storage associated with the input name was successfully released.
o GSS_S_COMPLETE表示与输入名称关联的存储已成功释放。
o GSS_S_BAD_NAME indicates that the input name argument did not contain a valid name.
o GSS_S_BAD_NAME表示输入名称参数未包含有效名称。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to release the storage associated with an internal name representation. This call's specific behavior depends on the language and programming environment within which a GSS-API implementation operates, and is therefore detailed within applicable bindings specifications; in particular, implementation and invocation of this call may be superfluous (and may be omitted) within bindings where memory management is automatic.
允许调用者释放与内部名称表示关联的存储。此调用的特定行为取决于GSS-API实现操作的语言和编程环境，因此在适用的绑定规范中有详细说明；特别是，在内存管理是自动的绑定中，此调用的实现和调用可能是多余的（可以省略）。
2.4.7: GSS_Release_buffer call
2.4.7:GSS_释放_缓冲区调用
Inputs:
投入：
o buffer OCTET STRING
o 缓冲八位组串
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER
o 次要状态整数
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the storage associated with the input buffer was successfully released.
o GSS_S_COMPLETE表示与输入缓冲区关联的存储已成功释放。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to release the storage associated with an OCTET STRING buffer allocated by another GSS-API call. This call's specific behavior depends on the language and programming environment within which a GSS-API implementation operates, and is therefore detailed within applicable bindings specifications; in particular, implementation and invocation of this call may be superfluous (and may be omitted) within bindings where memory management is automatic.
允许调用者释放与另一个GSS-API调用分配的八位字节字符串缓冲区关联的存储。此调用的特定行为取决于GSS-API实现操作的语言和编程环境，因此在适用的绑定规范中有详细说明；特别是，在内存管理是自动的绑定中，此调用的实现和调用可能是多余的（可以省略）。
2.4.8: GSS_Release_OID_set call
2.4.8:GSS\U释放\U OID\U集合调用
Inputs:
投入：
o buffer SET OF OBJECT IDENTIFIER
o 对象标识符的缓冲区集
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER
o 次要状态整数
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the storage associated with the input object identifier set was successfully released.
o GSS_S_COMPLETE表示与输入对象标识符集关联的存储已成功释放。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to release the storage associated with an object identifier set object allocated by another GSS-API call. This call's specific behavior depends on the language and programming environment within which a GSS-API implementation operates, and is therefore detailed within applicable bindings specifications; in particular, implementation and invocation of this call may be superfluous (and may be omitted) within bindings where memory management is automatic.
允许调用方释放与另一个GSS-API调用分配的对象标识符集对象关联的存储。此调用的特定行为取决于GSS-API实现操作的语言和编程环境，因此在适用的绑定规范中有详细说明；特别是，在内存管理是自动的绑定中，此调用的实现和调用可能是多余的（可以省略）。
2.4.9: GSS_Create_empty_OID_set call
2.4.9:GSS\u创建\u空\u OID\u集调用
Inputs:
投入：
o (none)
o （无）
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o oid_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o 对象标识符的oid_集--调用方必须释放--使用GSS_release_oid_集（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates successful completion
o GSS_S_COMPLETE表示成功完成
o GSS_S_FAILURE indicates that the operation failed
o GSS_S_故障表示操作失败
Creates an object identifier set containing no object identifiers, to which members may be subsequently added using the GSS_Add_OID_set_member() routine. These routines are intended to be used to construct sets of mechanism object identifiers, for input to GSS_Acquire_cred().
创建不包含对象标识符的对象标识符集，随后可以使用GSS_Add_OID_set_member（）例程将成员添加到该对象标识符集中。这些例程用于构造机制对象标识符集，以输入GSS_Acquire_cred（）。
2.4.10: GSS_Add_OID_set_member call
2.4.10:GSS_添加_OID_集合_成员呼叫
Inputs:
投入：
o member_oid OBJECT IDENTIFIER,
o 成员对象标识符，
o oid_set SET OF OBJECT IDENTIFIER
o oid_对象标识符集
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates successful completion
o GSS_S_COMPLETE表示成功完成
o GSS_S_FAILURE indicates that the operation failed
o GSS_S_故障表示操作失败
Adds an Object Identifier to an Object Identifier set. This routine is intended for use in conjunction with GSS_Create_empty_OID_set() when constructing a set of mechanism OIDs for input to GSS_Acquire_cred().
将对象标识符添加到对象标识符集。此例程旨在与GSS_Create_empty_OID_set（）结合使用，用于构造一组机制OID以输入GSS_Acquire_cred（）。
2.4.11: GSS_Test_OID_set_member call
2.4.11:GSS_测试_OID_集合_成员调用
Inputs:
投入：
o member OBJECT IDENTIFIER,
o 成员对象标识符，
o set SET OF OBJECT IDENTIFIER
o 对象标识符集
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o present BOOLEAN
o 当前布尔值
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates successful completion
o GSS_S_COMPLETE表示成功完成
o GSS_S_FAILURE indicates that the operation failed
o GSS_S_故障表示操作失败
Interrogates an Object Identifier set to determine whether a specified Object Identifier is a member. This routine is intended to be used with OID sets returned by GSS_Indicate_mechs(), GSS_Acquire_cred(), and GSS_Inquire_cred().
询问对象标识符集，以确定指定的对象标识符是否为成员。此例程用于GSS_Indicate_mechs（）、GSS_Acquire_cred（）和GSS_Inquire_cred（）返回的OID集。
2.4.12: GSS_Inquire_names_for_mech call
2.4.12:GSS\U查询\U名称\U机械呼叫
Input:
输入：
o input_mech_type OBJECT IDENTIFIER, -- mechanism type
o 输入机械类型对象标识符，--机械类型
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o name_type_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o 对象标识符的名称\类型\集合--调用方必须释放--使用GSS \释放\ oid\集合（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that the output name_type_set contains a list of name types which are supported by the locally available mechanism identified by input_mech_type.
o GSS_S_COMPLETE表示输出名称_类型_集合包含一个名称类型列表，该列表由输入类型识别的本地可用机制支持。
o GSS_S_BAD_MECH indicates that the mechanism identified by input_mech_type was unsupported within the local implementation, causing the query to fail.
o GSS_S_BAD_MECH表示由input_MECH_type标识的机制在本地实现中不受支持，导致查询失败。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to determine the set of name types which are supportable by a specific locally-available mechanism.
允许调用方确定特定本地可用机制支持的名称类型集。
2.4.13: GSS_Inquire_mechs_for_name call
2.4.13:GSS\U查询\U机械\U名称呼叫
Inputs:
投入：
o input_name INTERNAL NAME,
o 输入\u name内部名称，
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o mech_types SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o 对象标识符的mech_类型集--调用方必须释放--使用GSS_release_oid_SET（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that a set of object identifiers, corresponding to the set of mechanisms suitable for processing the input_name, is available in mech_types.
o GSS_S_COMPLETE表示一组对象标识符，对应于一组适合处理输入_名称的机制，在mech_类型中可用。
o GSS_S_BAD_NAME indicates that the input_name was ill-formed and could not be processed.
o GSS_S_BAD_NAME表示输入的_名称格式错误，无法处理。
o GSS_S_BAD_NAMETYPE indicates that the input_name parameter contained an invalid name type or a name type unsupported by the GSS-API implementation.
o GSS_S_BAD_NAMETYPE表示输入_name参数包含无效的名称类型或GSS-API实现不支持的名称类型。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
This routine returns the mechanism set with which the input_name may be processed.
此例程返回可用于处理输入_名称的机制集。
Each mechanism returned will recognize at least one element within the name. It is permissible for this routine to be implemented within a mechanism-independent GSS-API layer, using the type information contained within the presented name, and based on registration information provided by individual mechanism implementations. This means that the returned mech_types result may indicate that a particular mechanism will understand a particular name when in fact it would refuse to accept that name as input to GSS_Canonicalize_name(), GSS_Init_sec_context(), GSS_Acquire_cred(), or GSS_Add_cred(), due to some property of the particular name rather than a property of the name type. Thus, this routine should be used only as a pre-filter for a call to a subsequent mechanism-specific routine.
返回的每个机制将至少识别名称中的一个元素。允许在独立于机制的GSS-API层中实现此例程，使用所提供名称中包含的类型信息，并基于各个机制实现提供的注册信息。这意味着返回的mech_types结果可能表明特定机制将理解特定名称，而实际上它将拒绝接受该名称作为GSS_Canonicalize_name（）、GSS_Init_sec_context（）、GSS_Acquire_cred（）或GSS_Add_cred（）的输入，由于特定名称的某些属性而不是名称类型的属性。因此，此例程应仅用作调用后续机制特定例程的预过滤器。
2.4.14: GSS_Canonicalize_name call
2.4.14:GSS_规范化_名称调用
Inputs:
投入：
o input_name INTERNAL NAME,
o 输入\u name内部名称，
o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, -- not "default" specifier or identifier of negotiating mechanism
o mech_类型对象标识符——必须是显式机制，而不是“默认”说明符或协商机制的标识符
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_name INTERNAL NAME -- caller must release with -- GSS_Release_name()
o output_name INTERNAL name--调用方必须使用--GSS_release_name（）释放
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that a mechanism-specific reduction of the input_name, as processed by the mechanism identified by mech_type, is available in output_name.
o GSS_S_COMPLETE表示由mech_type标识的机构处理的输入_名称的特定机构缩减在输出_名称中可用。
o GSS_S_BAD_MECH indicates that the identified mechanism is unsupported for this operation; this may correspond either to a mechanism wholly unsupported by the local GSS-API implementation or to a negotiating mechanism with which the canonicalization operation cannot be performed.
o GSS_S_BAD_MECH表示此操作不支持识别的机构；这可能对应于本地GSS-API实现完全不支持的机制，也可能对应于无法执行规范化操作的协商机制。
o GSS_S_BAD_NAMETYPE indicates that the input name does not contain an element with suitable type for processing by the identified mechanism.
o GSS_S_BAD_NAMETYPE表示输入名称不包含适合由标识的机制处理的类型的元素。
o GSS_S_BAD_NAME indicates that the input name contains an element with suitable type for processing by the identified mechanism, but that this element could not be processed successfully.
o GSS_S_BAD_NAME表示输入名称包含一个类型适合由标识的机制处理的元素，但无法成功处理此元素。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
This routine reduces a GSS-API internal name input_name, which may in general contain elements corresponding to multiple mechanisms, to a mechanism-specific Mechanism Name (MN) output_name by applying the translations corresponding to the mechanism identified by mech_type. The contents of input_name are unaffected by the GSS_Canonicalize_name() operation. References to output_name will remain valid until output_name is released, independent of whether or not input_name is subsequently released.
此例程通过应用与mech_类型标识的机构相对应的翻译，将GSS-API内部名称输入_名称（通常可能包含与多个机构相对应的元素）简化为特定于机构的机构名称（MN）输出_名称。输入_name的内容不受GSS_Canonicalize_name（）操作的影响。在释放输出名称之前，对输出名称的引用将保持有效，与随后是否释放输入名称无关。
2.4.15: GSS_Export_name call
2.4.15:GSS_出口_名称呼叫
Inputs:
投入：
o input_name INTERNAL NAME, -- required to be MN
o 输入\u name内部名称，--必须为MN
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o output_name OCTET STRING -- caller must release -- with GSS_Release_buffer()
o 输出_name八位字节字符串--调用方必须释放--使用GSS_release_buffer（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that a flat representation of the input name is available in output_name.
o GSS_S_COMPLETE表示输入名称的平面表示在输出_名称中可用。
o GSS_S_NAME_NOT_MN indicates that the input name contained elements corresponding to multiple mechanisms, so cannot be exported into a single-mechanism flat form.
o GSS_S_NAME_NOT_MN表示输入名称包含对应于多个机制的元素，因此不能导出为单个机制平面形式。
o GSS_S_BAD_NAME indicates that the input name was an MN, but could not be processed.
o GSS_S_BAD_NAME表示输入名称是MN，但无法处理。
o GSS_S_BAD_NAMETYPE indicates that the input name was an MN, but that its type is unsupported by the GSS-API implementation.
o GSS_S_BAD_NAMETYPE表示输入名称是MN，但GSS-API实现不支持其类型。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
This routine creates a flat name representation, suitable for bytewise comparison or for input to GSS_Import_name() in conjunction with the reserved GSS-API Exported Name Object OID, from a internal-form Mechanism Name (MN) as emitted, e.g., by GSS_Canonicalize_name() or GSS_Accept_sec_context().
此例程从内部表单机制名称（MN）创建一个平面名称表示，该名称表示适合于字节比较，或与保留的GSS-API导出名称对象OID一起输入GSS_Import_name（），如通过GSS_Canonicalize_name（）或GSS_Accept_sec_context（）发出。
The emitted GSS-API Exported Name Object is self-describing; no associated parameter-level OID need be emitted by this call. This flat representation consists of a mechanism-independent wrapper layer, defined in Section 3.2 of this document, enclosing a mechanism-defined name representation.
发出的GSS-API导出名称对象是自描述的；此调用不需要发出关联的参数级别OID。该平面表示由一个独立于机制的包装层组成，该包装层在本文档第3.2节中定义，并包含一个机制定义的名称表示。
In all cases, the flat name output by GSS_Export_name() to correspond to a particular input MN must be invariant over time within a particular installation.
在所有情况下，GSS_Export_name（）输出的对应于特定输入MN的平面名称必须在特定安装中随时间保持不变。
The GSS_S_NAME_NOT_MN status code is provided to enable implementations to reject input names which are not MNs. It is not, however, required for purposes of conformance to this specification that all non-MN input names must necessarily be rejected.
GSS_S_NAME_NOT_MN状态代码用于允许实现拒绝非MN的输入名称。然而，为了符合本规范，不要求必须拒绝所有非MN输入名称。
2.4.16: GSS_Duplicate_name call
2.4.16:GSS_重复_姓名呼叫
Inputs:
投入：
o src_name INTERNAL NAME
o src_name内部名称
Outputs:
产出：
o major_status INTEGER,
o 主要状态整数，
o minor_status INTEGER,
o 次_状态整数，
o dest_name INTERNAL NAME -- caller must release -- with GSS_Release_name()
o dest_name内部名称--调用方必须释放--使用GSS_release_name（）
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates that dest_name references an internal name object containing the same name as passed to src_name.
o GSS_S_COMPLETE表示dest_name引用一个内部名称对象，该对象包含传递给src_name的相同名称。
o GSS_S_BAD_NAME indicates that the input name was invalid.
o GSS_S_BAD_NAME表示输入名称无效。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
This routine takes input internal name src_name, and returns another reference (dest_name) to that name which can be used even if src_name is later freed. (Note: This may be implemented by copying or through use of reference counts.)
此例程获取输入的内部名称src_name，并返回该名称的另一个引用（dest_name），即使稍后释放src_name，也可以使用该引用。（注意：这可以通过复制或使用引用计数来实现。）
3: Data Structure Definitions for GSS-V2 Usage
3：GSS-V2使用的数据结构定义
Subsections of this section define, for interoperability and portability purposes, certain data structures for use with GSS-V2.
为了实现互操作性和可移植性，本节的小节定义了与GSS-V2一起使用的某些数据结构。
3.1: Mechanism-Independent Token Format
3.1：独立于机制的令牌格式
This section specifies a mechanism-independent level of encapsulating representation for the initial token of a GSS-API context establishment sequence, incorporating an identifier of the mechanism type to be used on that context and enabling tokens to be interpreted unambiguously at GSS-API peers. Use of this format is required for initial context establishment tokens of Internet standards-track GSS-API mechanisms; use in non-initial tokens is optional.
本节规定了GSS-API上下文建立序列的初始令牌的封装表示的机制独立级别，包括要在该上下文上使用的机制类型的标识符，并允许在GSS-API对等方明确解释令牌。互联网标准跟踪GSS-API机制的初始上下文建立令牌需要使用此格式；在非初始令牌中使用是可选的。
The encoding format for the token tag is derived from ASN.1 and DER (per illustrative ASN.1 syntax included later within this subsection), but its concrete representation is defined directly in terms of octets rather than at the ASN.1 level in order to facilitate interoperable implementation without use of general ASN.1 processing code. The token tag consists of the following elements, in order:
令牌标记的编码格式源自ASN.1和DER（根据本小节后面包含的说明性ASN.1语法），但其具体表示形式直接按照八位字节定义，而不是在ASN.1级别定义，以便于在不使用一般ASN.1处理代码的情况下实现互操作。令牌标记按顺序由以下元素组成：
1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that -- constructed form, definite length encoding follows.
1. 0x60——用于[APPLICATION 0]序列的标记；指示--构造形式，随后是定长编码。
2. Token length octets, specifying length of subsequent data (i.e., the summed lengths of elements 3-5 in this list, and of the mechanism-defined token object following the tag). This element comprises a variable number of octets:
2. 标记长度八位字节，指定后续数据的长度（即，此列表中元素3-5的总长度，以及标记后面的机制定义的标记对象的总长度）。该元素由数量可变的八位字节组成：
2a. If the indicated value is less than 128, it shall be represented in a single octet with bit 8 (high order) set to "0" and the remaining bits representing the value.
2a。如果指示值小于128，则应以单个八位字节表示，位8（高阶）设置为“0”，其余位表示该值。
2b. If the indicated value is 128 or more, it shall be represented in two or more octets, with bit 8 of the first octet set to "1" and the remaining bits of the first octet specifying the number of additional octets. The subsequent octets carry the value, 8 bits per octet, most significant digit first. The minimum number of octets shall be used to encode the length (i.e., no octets representing leading zeros shall be included within the length encoding).
2b。如果指示值为128或更多，则应以两个或更多个八位字节表示，第一个八位字节的第8位设置为“1”，第一个八位字节的剩余位指定额外八位字节的数量。随后的八位字节携带值，每八位字节8位，最高有效位在前。应使用最少数量的八位字节对长度进行编码（即，长度编码中不应包含表示前导零的八位字节）。
3. 0x06 -- Tag for OBJECT IDENTIFIER
3. 0x06--对象标识符的标记
4. Object identifier length -- length (number of octets) of -- the encoded object identifier contained in element 5, -- encoded per rules as described in 2a. and 2b. above.
4. 对象标识符长度——元素5中包含的编码对象标识符的长度（八位字节数），按照2a中描述的规则编码。和2b。在上面
5. Object identifier octets -- variable number of octets, -- encoded per ASN.1 BER rules:
5. 对象标识符八位字节--可变的八位字节数，-按照ASN.1 BER规则编码：
5a. The first octet contains the sum of two values: (1) the top-level object identifier component, multiplied by 40 (decimal), and (2) the second-level object identifier component. This special case is the only point within an object identifier encoding where a single octet represents contents of more than one component.
5a。第一个八位组包含两个值的总和：（1）顶级对象标识符组件乘以40（十进制），以及（2）第二级对象标识符组件。这种特殊情况是对象标识符编码中唯一一个八位字节表示多个组件内容的点。
5b. Subsequent octets, if required, encode successively-lower components in the represented object identifier. A component's encoding may span multiple octets, encoding 7 bits per octet (most significant bits first) and with bit 8 set to "1" on all but the final octet in the component's encoding. The minimum number of octets shall be used to encode each component (i.e., no octets representing leading zeros shall be included within a component's encoding).
5b。如果需要，后续的八位字节会依次对表示的对象标识符中的较低分量进行编码。一个组件的编码可以跨越多个八位字节，每个八位字节编码7位（首先是最高有效位），并且在组件编码中除最后一个八位字节外的所有八位字节上，位8都设置为“1”。应使用最少数量的八位字节对每个组件进行编码（即，组件编码中不应包含代表前导零的八位字节）。
(Note: In many implementations, elements 3-5 may be stored and referenced as a contiguous string constant.)
（注意：在许多实现中，元素3-5可以作为连续字符串常量存储和引用。）
The token tag is immediately followed by a mechanism-defined token object. Note that no independent size specifier intervenes following the object identifier value to indicate the size of the mechanism-defined token object. While ASN.1 usage within mechanism-defined tokens is permitted, there is no requirement that the mechanism-specific innerContextToken, innerMsgToken, and sealedUserData data elements must employ ASN.1 BER/DER encoding conventions.
令牌标记后面紧跟着一个机制定义的令牌对象。请注意，在对象标识符值之后没有独立的大小说明符介入，以指示机制定义的令牌对象的大小。虽然允许在机制定义的令牌中使用ASN.1，但不要求特定于机制的innerContextToken、innerMsgToken和SealeUserData数据元素必须采用ASN.1 BER/DER编码约定。
The following ASN.1 syntax is included for descriptive purposes only, to illustrate structural relationships among token and tag objects. For interoperability purposes, token and tag encoding shall be performed using the concrete encoding procedures described earlier in this subsection.
以下ASN.1语法仅用于说明目的，以说明令牌和标记对象之间的结构关系。出于互操作性目的，应使用本小节前面描述的具体编码程序执行令牌和标签编码。
GSS-API DEFINITIONS ::=
GSS-API DEFINITIONS ::=
BEGIN
开始
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
-- callers must be able to distinguish among
-- InitialContextToken, SubsequentContextToken,
-- PerMsgToken, and SealedMessage data elements
-- based on the usage in which they occur
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
-- callers must be able to distinguish among
-- InitialContextToken, SubsequentContextToken,
-- PerMsgToken, and SealedMessage data elements
-- based on the usage in which they occur
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
innerMsgToken ANY
PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
innerMsgToken ANY
SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
-- ASN.1 structure not required sealedUserData ANY
--ASN.1结构不需要密封SERDATA任何
END
终止
3.2: Mechanism-Independent Exported Name Object Format
3.2：独立于机制的导出名称对象格式
This section specifies a mechanism-independent level of encapsulating representation for names exported via the GSS_Export_name() call, including an object identifier representing the exporting mechanism. The format of names encapsulated via this representation shall be defined within individual mechanism drafts. The Object Identifier value to indicate names of this type is defined in Section 4.7 of this document.
本节指定通过GSS_Export_name（）调用导出的名称的封装表示的独立于机制的级别，包括表示导出机制的对象标识符。通过该表示封装的名称格式应在单独的机构草案中定义。本文件第4.7节定义了用于指示此类名称的对象标识符值。
No name type OID is included in this mechanism-independent level of format definition, since (depending on individual mechanism specifications) the enclosed name may be implicitly typed or may be explicitly typed using a means other than OID encoding.
此独立于机制的格式定义级别中不包括名称类型OID，因为（取决于各个机制规范）所包含的名称可以隐式键入，也可以使用OID编码以外的方式显式键入。
The bytes within MECH_OID_LEN and NAME_LEN elements are represented most significant byte first (equivalently, in IP network byte order).
MECH_OID_LEN和NAME_LEN元素中的字节首先表示为最高有效字节（等效地，以IP网络字节顺序）。
Length Name Description
长度名称描述
2 TOK_ID Token Identifier For exported name objects, this must be hex 04 01. 2 MECH_OID_LEN Length of the Mechanism OID MECH_OID_LEN MECH_OID Mechanism OID, in DER 4 NAME_LEN Length of name NAME_LEN NAME Exported name; format defined in applicable mechanism draft.
2导出名称对象的TOK_ID令牌标识符，必须为hex 04 01。2机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械类机械；适用机制草案中定义的格式。
A concrete example of the contents of an exported name object, derived from the Kerberos Version 5 mechanism, is as follows:
从Kerberos版本5机制派生的导出名称对象内容的具体示例如下：
04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 hx xx xx xl pp qq ... zz
04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 hx xx xl pp qq。。。zz
04 01 mandatory token identifier
04 01强制令牌标识符
00 0B 2-byte length of the immediately following DER-encoded ASN.1 value of type OID, most significant octet first
00 0B紧随其后的DER编码ASN.1类型OID值的2字节长度，最重要的八位字节在前
06 09 2A 86 48 86 F7 12 01 02 02 DER-encoded ASN.1 value of type OID; Kerberos V5 mechanism OID indicates Kerberos V5 exported name
06 09 2A 86 48 86 F7 12 01 02 02 DER编码ASN.1 OID类型值；Kerberos V5机制OID表示Kerberos V5导出的名称
in Detail: 06 Identifier octet (6=OID) 09 Length octet(s) 2A 86 48 86 F7 12 01 02 02 Content octet(s)
详细信息：06标识符八位字节（6=OID）09长度八位字节2A 86 48 86 F7 12 01 02内容八位字节
hx xx xx xl 4-byte length of the immediately following exported name blob, most significant octet first
紧接导出名称blob之后的hx xx xl 4字节长度，最重要的八位字节排在第一位
pp qq ... zz exported name blob of specified length, bits and bytes specified in the (Kerberos 5) GSS-API v2 mechanism spec
pp qq。。。zz导出了（Kerberos 5）GSS-API v2机制规范中指定长度、位和字节的名称blob
4: Name Type Definitions
4：名称类型定义
This section includes definitions for name types and associated syntaxes which are defined in a mechanism-independent fashion at the GSS-API level rather than being defined in individual mechanism specifications.
本节包括在GSS-API级别以独立于机制的方式定义的名称类型和相关语法的定义，而不是在单独的机制规范中定义。
4.1: Host-Based Service Name Form
4.1：基于主机的服务名称表
This name form shall be represented by the Object Identifier:
该名称表应由对象标识符表示：
{iso(1) member-body(2) United States(840) mit(113554) infosys(1) "gssapi(2) generic(1) service_name(4)}.
{iso（1）成员机构（2）美国（840）麻省理工学院（113554）infosys（1）“gssapi（2）通用（1）服务名称（4）}。
The recommended symbolic name for this type is "GSS_C_NT_HOSTBASED_SERVICE".
此类型的建议符号名为“GSS_C_NT_HOSTBASED_SERVICE”。
For reasons of compatibility with existing implementations, it is recommended that this OID be used rather than the alternate value as included in [RFC-2078]:
出于与现有实现兼容的原因，建议使用此OID，而不是[RFC-2078]中包含的替代值：
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
2(gss-host-based-services)}
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
2(gss-host-based-services)}
While it is not recommended that this alternate value be emitted on output by GSS implementations, it is recommended that it be accepted on input as equivalent to the recommended value.
虽然不建议GSS实现在输出时发出此备用值，但建议在输入时将其视为等效于建议值。
This name type is used to represent services associated with host computers. Support for this name form is recommended to mechanism designers in the interests of portability, but is not mandated by this specification. This name form is constructed using two elements, "service" and "hostname", as follows:
此名称类型用于表示与主机关联的服务。出于可移植性的考虑，建议机构设计师支持此名称表单，但本规范不强制要求支持此名称表单。此名称表单使用两个元素“服务”和“主机名”构建，如下所示：
service@hostname
service@hostname
When a reference to a name of this type is resolved, the "hostname" may (as an example implementation strategy) be canonicalized by attempting a DNS lookup and using the fully-qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters.
当解析对该类型名称的引用时，可以通过尝试DNS查找并使用返回的完全限定域名，或者在DNS查找失败时使用提供的“主机名”，来规范化“主机名”（作为示例实施策略）。规范化操作还将主机名映射为小写字符。
The "hostname" element may be omitted. If no "@" separator is included, the entire name is interpreted as the service specifier, with the "hostname" defaulted to the canonicalized name of the local host.
可以省略“hostname”元素。如果未包含“@”分隔符，则整个名称将解释为服务说明符，“主机名”默认为本地主机的规范化名称。
Documents specifying means for GSS integration into a particular protocol should state either:
指定GSS集成到特定协议的方法的文件应说明：
(a) that a specific IANA-registered name associated with that protocol shall be used for the "service" element (this admits, if needed, the possibility that a single name can be registered and shared among a related set of protocols), or
(a) 与该协议相关的特定IANA注册名称应用于“服务”元素（如果需要，允许在相关协议集之间注册和共享单个名称），或
(b) that the generic name "host" shall be used for the "service" element, or
(b) “服务”元素应使用通用名称“主机”，或
(c) that, for that protocol, fallback in specified order (a, then b) or (b, then a) shall be applied.
(c) 对于该协议，应采用规定顺序（a，然后b）或（b，然后a）的回退。
IANA registration of specific names per (a) should be handled in accordance with the "Specification Required" assignment policy, defined by BCP 26, RFC 2434 as follows: "Values and their meaning must be documented in an RFC or other available reference, in sufficient detail so that interoperability between independent implementations is possible."
IANA根据（a）对特定名称的注册应按照BCP 26、RFC 2434规定的“所需规范”分配政策进行处理，规定如下：“必须在RFC或其他可用参考文件中详细记录值及其含义，以便独立实施之间实现互操作性。”
4.2: User Name Form
4.2：用户名表
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) user_name(1)}. The recommended mechanism-independent
symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) user_name(1)}. The recommended mechanism-independent
symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same
name form and OID is defined within the Kerberos V5 GSS-API mechanism, but the symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
名称形式和OID是在Kerberos V5 GSS-API机制中定义的，但此处推荐的符号名称以“GSS_KRB5_NT_”前缀开头。）
This name type is used to indicate a named user on a local system. Its syntax and interpretation may be OS-specific. This name form is constructed as:
此名称类型用于指示本地系统上的命名用户。它的语法和解释可能是特定于操作系统的。此名称表的结构如下：
username
用户名
4.3: Machine UID Form
4.3：机器UID表单
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) machine_uid_name(2)}. The recommended mechanism-independent symbolic name for this type is "GSS_C_NT_MACHINE_UID_NAME". (Note: the same name form and OID is defined within the Kerberos V5 GSS-API mechanism, but the symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
该名称表应以对象标识符{iso（1）成员机构（2）美国麻省理工学院（840）麻省理工学院（113554）infosys（1）gssapi（2）通用（1）机器uid_名称（2）}表示。建议此类型的独立于机制的符号名为“GSS\u C\u NT\u MACHINE\u UID\u name”。（注意：在Kerberos V5 GSS-API机制中定义了相同的名称形式和OID，但此处推荐的符号名称以“GSS_KRB5_NT_”前缀开头。）
This name type is used to indicate a numeric user identifier corresponding to a user on a local system. Its interpretation is OS-specific. The gss_buffer_desc representing a name of this type should contain a locally-significant user ID, represented in host byte order. The GSS_Import_name() operation resolves this uid into a username, which is then treated as the User Name Form.
此名称类型用于指示与本地系统上的用户相对应的数字用户标识符。它的解释是特定于操作系统的。表示此类型名称的gss_buffer_desc应包含本地有效的用户ID，以主机字节顺序表示。GSS_Import_name（）操作将此uid解析为用户名，然后将其视为用户名表单。
4.4: String UID Form
4.4：字符串UID形式
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3)}. The recommended symbolic name for this type is "GSS_C_NT_STRING_UID_NAME". (Note: the same name form and OID is defined within the Kerberos V5 GSS-API mechanism, but the symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
该名称表应以对象标识符{iso（1）成员机构（2）美国麻省理工学院（840）麻省理工学院（113554）信息系统（1）gssapi（2）通用（1）字符串（uid）名称（3）}表示。此类型的建议符号名为“GSS\u C\u NT\u STRING\u UID\u name”。（注意：在Kerberos V5 GSS-API机制中定义了相同的名称形式和OID，但此处推荐的符号名称以“GSS_KRB5_NT_”前缀开头。）
This name type is used to indicate a string of digits representing the numeric user identifier of a user on a local system. Its interpretation is OS-specific. This name type is similar to the Machine UID Form, except that the buffer contains a string representing the user ID.
此名称类型用于指示表示本地系统上用户的数字用户标识符的数字字符串。它的解释是特定于操作系统的。此名称类型类似于机器UID表单，只是缓冲区包含表示用户ID的字符串。
4.5: Anonymous Nametype
4.5：匿名名称类型
The following Object Identifier value is provided as a means to identify anonymous names, and can be compared against in order to determine, in a mechanism-independent fashion, whether a name refers to an anonymous principal:
提供以下对象标识符值作为识别匿名名称的手段，并可与之进行比较，以便以独立于机制的方式确定名称是否引用匿名主体：
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
3(gss-anonymous-name)}
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
3(gss-anonymous-name)}
The recommended symbolic name corresponding to this definition is GSS_C_NT_ANONYMOUS.
与此定义相对应的建议符号名为GSS_C_NT_ANONYMOUS。
4.6: GSS_C_NO_OID
4.6:GSS\U C\U编号
The recommended symbolic name GSS_C_NO_OID corresponds to a null input value instead of an actual object identifier. Where specified, it indicates interpretation of an associated name based on a mechanism-specific default printable syntax.
建议的符号名GSS_C_NO_OID对应于空输入值，而不是实际的对象标识符。如果指定，它表示基于特定于机制的默认可打印语法对关联名称的解释。
4.7: Exported Name Object
4.7：导出的名称对象
Name objects of the Mechanism-Independent Exported Name Object type, as defined in Section 3.2 of this document, will be identified with the following Object Identifier:
本文件第3.2节中定义的独立于机构的导出名称对象类型的名称对象将用以下对象标识符标识：
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
4(gss-api-exported-name)}
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
4(gss-api-exported-name)}
The recommended symbolic name corresponding to this definition is GSS_C_NT_EXPORT_NAME.
与此定义相对应的建议符号名为GSS_C_NT_EXPORT_name。
4.8: GSS_C_NO_NAME
4.8:GSS\U C\U编号\U名称
The recommended symbolic name GSS_C_NO_NAME indicates that no name is being passed within a particular value of a parameter used for the purpose of transferring names. Note: GSS_C_NO_NAME is not an actual name type, and is not represented by an OID; its acceptability in lieu of an actual name is confined to specific calls (GSS_Acquire_cred(), GSS_Add_cred(), and GSS_Init_sec_context()) with usages as identified within this specification.
建议的符号名GSS_C_NO_name表示在用于传输名称的参数的特定值内未传递任何名称。注意：GSS_C_NO_NAME不是实际的名称类型，并且不由OID表示；其代替实际名称的可接受性仅限于特定调用（GSS_Acquire_cred（）、GSS_Add_cred（）和GSS_Init_sec_context（）），其用法如本规范所述。
5: Mechanism-Specific Example Scenarios
5：特定于机制的示例场景
This section provides illustrative overviews of the use of various candidate mechanism types to support the GSS-API. These discussions are intended primarily for readers familiar with specific security technologies, demonstrating how GSS-API functions can be used and implemented by candidate underlying mechanisms. They should not be regarded as constrictive to implementations or as defining the only means through which GSS-API functions can be realized with a particular underlying technology, and do not demonstrate all GSS-API features with each technology.
本节提供了使用各种候选机制类型来支持GSS-API的说明性概述。这些讨论主要针对熟悉特定安全技术的读者，演示GSS-API函数如何通过候选底层机制使用和实现。它们不应被视为对实现的限制，也不应被视为定义GSS-API功能可以通过特定底层技术实现的唯一方法，并且不应在每种技术中演示所有GSS-API功能。
5.1: Kerberos V5, single-TGT
5.1:Kerberos V5，单TGT
OS-specific login functions yield a TGT to the local realm Kerberos server; TGT is placed in a credentials structure for the client. Client calls GSS_Acquire_cred() to acquire a cred_handle in order to reference the credentials for use in establishing security contexts.
特定于操作系统的登录函数向本地域Kerberos服务器生成TGT；TGT被放置在客户端的凭证结构中。客户端调用GSS_Acquire_cred（）来获取cred_句柄，以便引用凭据以用于建立安全上下文。
Client calls GSS_Init_sec_context(). If the requested service is located in a different realm, GSS_Init_sec_context() gets the necessary TGT/key pairs needed to traverse the path from local to target realm; these data are placed in the owner's TGT cache. After any needed remote realm resolution, GSS_Init_sec_context() yields a service ticket to the requested service with a corresponding session key; these data are stored in conjunction with the context. GSS-API code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP response(s) (in the successful case) or KRB_ERROR.
客户端调用GSS_Init_sec_context（）。如果请求的服务位于不同的域中，GSS_Init_sec_context（）将获取从本地域到目标域遍历路径所需的TGT/密钥对；这些数据放在所有者的TGT缓存中。在任何所需的远程领域解析之后，GSS_Init_sec_context（）会向请求的服务生成一个带有相应会话密钥的服务票证；这些数据与上下文一起存储。GSS-API代码发送KRB_TGS_REQ请求并接收KRB_TGS_REP响应（在成功的情况下）或KRB_错误。
Assuming success, GSS_Init_sec_context() builds a Kerberos-formatted KRB_AP_REQ message, and returns it in output_token. The client sends the output_token to the service.
假设成功，GSS_Init_sec_context（）构建Kerberos格式的KRB_AP_REQ消息，并在输出_令牌中返回该消息。客户端向服务发送输出令牌。
The service passes the received token as the input_token argument to GSS_Accept_sec_context(), which verifies the authenticator, provides the service with the client's authenticated name, and returns an output_context_handle.
服务将接收到的令牌作为输入令牌参数传递给GSS_Accept_sec_context（），GSS_Accept_sec_context（）验证身份验证器，为服务提供客户端的身份验证名称，并返回输出上下文句柄。
Both parties now hold the session key associated with the service ticket, and can use this key in subsequent GSS_GetMIC(), GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap() operations.
双方现在都持有与服务票证关联的会话密钥，并且可以在后续的GSS_GetMIC（）、GSS_VerifyMIC（）、GSS_Wrap（）和GSS_Unwrap（）操作中使用该密钥。
5.2: Kerberos V5, double-TGT
5.2:Kerberos V5，双TGT
TGT acquisition as above.
TGT收购如上所述。
Note: To avoid unnecessary frequent invocations of error paths when implementing the GSS-API atop Kerberos V5, it seems appropriate to represent "single-TGT K-V5" and "double-TGT K-V5" with separate mech_types, and this discussion makes that assumption.
注意：为了避免在Kerberos V5上实现GSS-API时不必要地频繁调用错误路径，使用单独的mech_类型表示“单TGT K-V5”和“双TGT K-V5”似乎是合适的，本讨论提出了这一假设。
Based on the (specified or defaulted) mech_type, GSS_Init_sec_context() determines that the double-TGT protocol should be employed for the specified target. GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED major_status, and its returned output_token contains a request to the service for the service's TGT. (If a service TGT with suitably long remaining lifetime already exists in a cache, it may be usable, obviating the need for this step.) The client passes the output_token to the service. Note: this scenario illustrates a different use for the GSS_S_CONTINUE_NEEDED
GSS_Init_sec_context（）根据（指定或默认）mech_类型确定指定目标应使用双TGT协议。GSS_Init_sec_context（）返回GSS_S_CONTINUE_NEEDED major_状态，其返回的output_令牌包含对服务TGT的请求。（如果缓存中已存在剩余生存期适当长的服务TGT，则该服务TGT可能可用，从而无需执行此步骤。）客户端将输出_令牌传递给该服务。注意：此场景说明了所需GSS_S_CONTINUE_的不同用途
status return facility than for support of mutual authentication; note that both uses can coexist as successive operations within a single context establishment operation.
状态返回设施，而不是用于支持相互认证；请注意，这两种使用可以作为单个上下文建立操作中的连续操作共存。
The service passes the received token as the input_token argument to GSS_Accept_sec_context(), which recognizes it as a request for TGT. (Note that current Kerberos V5 defines no intra-protocol mechanism to represent such a request.) GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED major_status and provides the service's TGT in its output_token. The service sends the output_token to the client.
服务将接收到的令牌作为输入令牌参数传递给GSS_Accept_sec_context（），后者将其识别为TGT请求。（请注意，当前的Kerberos V5没有定义表示此类请求的协议内机制。）GSS_Accept_sec_context（）返回GSS_S_CONTINUE_NEEDED major_状态，并在其输出_令牌中提供服务的TGT。服务将输出令牌发送到客户端。
The client passes the received token as the input_token argument to a continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches the received service TGT and uses it as part of a service ticket request to the Kerberos authentication server, storing the returned service ticket and session key in conjunction with the context. GSS_Init_sec_context() builds a Kerberos-formatted authenticator, and returns it in output_token along with GSS_S_COMPLETE return major_status. The client sends the output_token to the service.
客户端将收到的令牌作为输入令牌参数传递给GSS_Init_sec_context（）的延续。GSS_Init_sec_context（）缓存接收到的服务TGT，并将其用作到Kerberos身份验证服务器的服务票证请求的一部分，将返回的服务票证和会话密钥与上下文一起存储。GSS_Init_sec_context（）构建一个Kerberos格式的验证器，并将其与GSS_S_COMPLETE return major_status一起返回到output_令牌中。客户端向服务发送输出令牌。
Service passes the received token as the input_token argument to a continuation call to GSS_Accept_sec_context(). GSS_Accept_sec_context() verifies the authenticator, provides the service with the client's authenticated name, and returns major_status GSS_S_COMPLETE.
服务将收到的令牌作为输入令牌参数传递给对GSS_Accept_sec_context（）的连续调用。GSS_Accept_sec_context（）验证验证器，向服务提供客户端的已验证名称，并返回主要状态GSS_s_COMPLETE。
GSS_GetMIC(), GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap() as above.
GSS_GetMIC（）、GSS_VerifyMIC（）、GSS_Wrap（）和GSS_Unwrap（）如上所述。
5.3: X.509 Authentication Framework
5.3:X.509认证框架
This example illustrates use of the GSS-API in conjunction with public-key mechanisms, consistent with the X.509 Directory Authentication Framework.
此示例说明了GSS-API与公钥机制的结合使用，与X.509目录身份验证框架一致。
The GSS_Acquire_cred() call establishes a credentials structure, making the client's private key accessible for use on behalf of the client.
GSS_Acquire_cred（）调用建立了一个凭据结构，使客户端的私钥可以访问，以便代表客户端使用。
The client calls GSS_Init_sec_context(), which interrogates the Directory to acquire (and validate) a chain of public-key certificates, thereby collecting the public key of the service. The certificate validation operation determines that suitable integrity checks were applied by trusted authorities and that those certificates have not expired. GSS_Init_sec_context() generates a secret key for use in per-message protection operations on the context, and enciphers that secret key under the service's public key.
客户端调用GSS_Init_sec_context（），它查询目录以获取（并验证）公钥证书链，从而收集服务的公钥。证书验证操作确定受信任的机构应用了适当的完整性检查，并且这些证书尚未过期。GSS_Init_sec_context（）生成一个密钥，用于上下文上的每条消息保护操作，并在服务的公钥下对该密钥进行加密。
The enciphered secret key, along with an authenticator quantity signed with the client's private key, is included in the output_token from GSS_Init_sec_context(). The output_token also carries a certification path, consisting of a certificate chain leading from the service to the client; a variant approach would defer this path resolution to be performed by the service instead of being asserted by the client. The client application sends the output_token to the service.
已加密的密钥以及使用客户端私钥签名的身份验证器数量包含在GSS_Init_sec_context（）的输出_令牌中。输出令牌还携带一条认证路径，由从服务到客户端的证书链组成；一种不同的方法将延迟此路径解析由服务执行，而不是由客户端断言。客户端应用程序将输出令牌发送到服务。
The service passes the received token as the input_token argument to GSS_Accept_sec_context(). GSS_Accept_sec_context() validates the certification path, and as a result determines a certified binding between the client's distinguished name and the client's public key. Given that public key, GSS_Accept_sec_context() can process the input_token's authenticator quantity and verify that the client's private key was used to sign the input_token. At this point, the client is authenticated to the service. The service uses its private key to decipher the enciphered secret key provided to it for per-message protection operations on the context.
服务将收到的令牌作为输入令牌参数传递给GSS_Accept_sec_context（）。GSS_Accept_sec_context（）验证认证路径，从而确定客户端的专有名称和客户端公钥之间的认证绑定。给定该公钥，GSS_Accept_sec_context（）可以处理输入_令牌的验证器数量，并验证客户端的私钥是否用于对输入_令牌进行签名。此时，客户机已通过服务的身份验证。该服务使用其私钥解密提供给它的加密密钥，以便在上下文中对每条消息进行保护操作。
The client calls GSS_GetMIC() or GSS_Wrap() on a data message, which causes per-message authentication, integrity, and (optional) confidentiality facilities to be applied to that message. The service uses the context's shared secret key to perform corresponding GSS_VerifyMIC() and GSS_Unwrap() calls.
客户机对数据消息调用GSS_GetMIC（）或GSS_Wrap（），这将导致对该消息应用每消息身份验证、完整性和（可选）机密性功能。该服务使用上下文的共享密钥执行相应的GSS_VerifyMIC（）和GSS_Unwrap（）调用。
6: Security Considerations
第6条：安全考虑
This document specifies a service interface for security facilities and services; as such, security considerations are considered throughout the specification. Nonetheless, it is appropriate to summarize certain specific points relevant to GSS-API implementors and calling applications. Usage of the GSS-API interface does not in itself provide security services or assurance; instead, these attributes are dependent on the underlying mechanism(s) which support a GSS-API implementation. Callers must be attentive to the requests made to GSS-API calls and to the status indicators returned by GSS-API, as these specify the security service characteristics which GSS-API will provide. When the interprocess context transfer facility is used, appropriate local controls should be applied to constrain access to interprocess tokens and to the sensitive data which they contain.
本文件规定了安全设施和服务的服务接口；因此，在整个规范中都考虑了安全因素。尽管如此，总结与GSS-API实现者和调用应用程序相关的某些特定要点是合适的。GSS-API接口的使用本身并不提供安全服务或保证；相反，这些属性依赖于支持GSS-API实现的底层机制。调用者必须注意对GSS-API调用的请求和GSS-API返回的状态指示器，因为它们指定了GSS-API将提供的安全服务特性。使用进程间上下文传输工具时，应应用适当的本地控件来限制对进程间令牌及其包含的敏感数据的访问。
7: Related Activities
7：相关活动
In order to implement the GSS-API atop existing, emerging, and future security mechanisms:
为了在现有、新兴和未来的安全机制之上实施GSS-API：
object identifiers must be assigned to candidate GSS-API mechanisms and the name types which they support
必须将对象标识符分配给候选GSS-API机制及其支持的名称类型
concrete data element formats and processing procedures must be defined for candidate mechanisms
必须为候选机制定义具体的数据元素格式和处理程序
Calling applications must implement formatting conventions which will enable them to distinguish GSS-API tokens from other data carried in their application protocols.
调用应用程序必须实现格式化约定，使它们能够将GSS-API令牌与应用程序协议中携带的其他数据区分开来。
Concrete language bindings are required for the programming environments in which the GSS-API is to be employed, as [RFC-1509] defines for the C programming language and GSS-V1. C Language bindings for GSS-V2 are defined in [RFC-2744].
如[RFC-1509]对C编程语言和GSS-V1的定义，GSS-API将被使用的编程环境需要具体的语言绑定。GSS-V2的C语言绑定在[RFC-2744]中定义。
8: Referenced Documents
8：参考文件
[ISO-7498-2] International Standard ISO 7498-2-1988(E), Security Architecture.
[ISO-7498-2]国际标准ISO 7498-2-1988（E），安全体系结构。
[ISOIEC-8824] ISO/IEC 8824, "Specification of Abstract Syntax Notation One (ASN.1)".
[ISOIEC-8824]ISO/IEC 8824，“抽象语法符号一规范（ASN.1）”。
[ISOIEC-8825] ISO/IEC 8825, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)".)
[ISOIEC-8825]ISO/IEC 8825，“抽象语法符号1（ASN.1）基本编码规则规范”
[RFC-1507]: Kaufman, C., "DASS: Distributed Authentication Security Service", RFC 1507, September 1993.
[RFC-1507]：考夫曼，C.，“DASS：分布式身份验证安全服务”，RFC 15071993年9月。
[RFC-1508]: Linn, J., "Generic Security Service Application Program Interface", RFC 1508, September 1993.
[RFC-1508]：林恩，J.，“通用安全服务应用程序接口”，RFC 1508，1993年9月。
[RFC-1509]: Wray, J., "Generic Security Service API: C-bindings", RFC 1509, September 1993.
[RFC-1509]：Wray，J.，“通用安全服务API:C-绑定”，RFC 15091993年9月。
[RFC-1964]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC-1964]：Linn，J.，“Kerberos版本5 GSS-API机制”，RFC 19641996年6月。
[RFC-2025]: Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC-2025]：Adams，C.“简单公钥GSS-API机制（SPKM）”，RFC 2025，1996年10月。
[RFC-2078]: Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC-2078]：林恩，J，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。
[RFC-2203]: Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC-2203]：Eisler，M.，Chiu，A.和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，1997年9月。
[RFC-2744]: Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC-2744]：Wray，J.，“通用安全服务API第2版：C-绑定”，RFC 2744，2000年1月。
APPENDIX A
附录A
MECHANISM DESIGN CONSTRAINTS
机构设计约束
The following constraints on GSS-API mechanism designs are adopted in response to observed caller protocol requirements, and adherence thereto is anticipated in subsequent descriptions of GSS-API mechanisms to be documented in standards-track Internet specifications.
为了响应观察到的呼叫方协议要求，采用了GSS-API机制设计的以下约束条件，并且在标准跟踪互联网规范中记录的GSS-API机制的后续描述中预计会遵守这些约束条件。
It is strongly recommended that mechanisms offering per-message protection services also offer at least one of the replay detection and sequencing services, as mechanisms offering neither of the latter will fail to satisfy recognized requirements of certain candidate caller protocols.
强烈建议提供每条消息保护服务的机制还提供至少一种重播检测和排序服务，因为提供这两种服务的机制都不能满足某些候选呼叫方协议的公认要求。
APPENDIX B
附录B
COMPATIBILITY WITH GSS-V1
与GSS-V1的兼容性
It is the intent of this document to define an interface and procedures which preserve compatibility between GSS-V1 [RFC-1508] callers and GSS-V2 providers. All calls defined in GSS-V1 are preserved, and it has been a goal that GSS-V1 callers should be able to operate atop GSS-V2 provider implementations. Certain detailed changes, summarized in this section, have been made in order to resolve omissions identified in GSS-V1.
本文档旨在定义一个接口和过程，以保持GSS-V1[RFC-1508]调用者和GSS-V2提供程序之间的兼容性。GSS-V1中定义的所有调用都将被保留，并且GSS-V1调用方应该能够在GSS-V2提供程序实现之上操作一直是一个目标。为了解决GSS-V1中发现的遗漏，本节总结了某些详细变更。
The following GSS-V1 constructs, while supported within GSS-V2, are deprecated:
以下GSS-V1构造虽然在GSS-V2中受支持，但不推荐使用：
Names for per-message processing routines: GSS_Seal() deprecated in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap(); GSS_Verify() deprecated in favor of GSS_VerifyMIC().
每个消息处理例程的名称：GSS_Seal（）不推荐使用，而支持GSS_Wrap（）；GSS_Sign（）已被弃用，取而代之的是GSS_GetMIC（）；不推荐使用GSS_unchal（）以支持GSS_Unwrap（）；GSS_Verify（）已弃用，取而代之的是GSS_VerifyMIC（）。
GSS_Delete_sec_context() facility for context_token usage, allowing mechanisms to signal context deletion, is retained for compatibility with GSS-V1. For current usage, it is recommended that both peers to a context invoke GSS_Delete_sec_context() independently, passing a null output_context_token buffer to indicate that no context_token is required. Implementations of GSS_Delete_sec_context() should delete relevant locally-stored context information.
GSS_Delete_sec_context（）保留了上下文令牌使用功能，允许发送上下文删除信号的机制，以与GSS-V1兼容。对于当前用法，建议上下文的两个对等方独立调用GSS_Delete_sec_context（），传递空输出_context_令牌缓冲区，以指示不需要上下文_令牌。GSS_Delete_sec_context（）的实现应该删除本地存储的相关上下文信息。
This GSS-V2 specification adds the following calls which are not present in GSS-V1:
此GSS-V2规范添加了GSS-V1中不存在的以下调用：
Credential management calls: GSS_Add_cred(), GSS_Inquire_cred_by_mech().
凭证管理调用：GSS\u Add\u cred（）、GSS\u Inquire\u cred\u by\u mech（）。
Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(), GSS_Export_sec_context(), GSS_Import_sec_context().
上下文级调用：GSS_Inquire_Context（）、GSS_Wrap_size_limit（）、GSS_Export_sec_Context（）、GSS_Import_sec_Context（）。
Per-message calls: No new calls. Existing calls have been renamed.
按消息呼叫：无新呼叫。已重命名现有呼叫。
Support calls: GSS_Create_empty_OID_set(), GSS_Add_OID_set_member(), GSS_Test_OID_set_member(), GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(), GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
支持调用：GSS_Create_empty_OID_set（）、GSS_Add_OID_set_member（）、GSS_Test_OID_set_member（）、GSS_Inquire_names_for_mech（）、GSS_Inquire_mechs_for_name（）、GSS_规范化_name（）、GSS_导出_name（）、GSS_复制_name（）。
This GSS-V2 specification introduces three new facilities applicable to security contexts, indicated using the following context state values which are not present in GSS-V1:
本GSS-V2规范介绍了三种适用于安全上下文的新功能，使用GSS-V1中不存在的以下上下文状态值表示：
anon_state, set TRUE to indicate that a context's initiator is anonymous from the viewpoint of the target; Section 1.2.5 of this specification provides a summary description of the GSS-V2 anonymity support facility, support and use of which is optional.
anon_状态，设置为TRUE，表示从目标的角度来看，上下文的发起方是匿名的；本规范第1.2.5节提供了GSS-V2匿名支持设施的概要说明，该设施的支持和使用是可选的。
prot_ready_state, set TRUE to indicate that a context may be used for per-message protection before final completion of context establishment; Section 1.2.7 of this specification provides a summary description of the GSS-V2 facility enabling mechanisms to selectively permit per-message protection during context establishment, support and use of which is optional.
prot_ready_状态，设置为TRUE，表示在最终完成上下文建立之前，上下文可用于每条消息的保护；本规范第1.2.7节提供了GSS-V2设施启用机制的概要说明，该机制可在上下文建立、支持和使用过程中选择性地允许每条消息的保护，这是可选的。
trans_state, set TRUE to indicate that a context is transferable to another process using the GSS-V2 GSS_Export_sec_context() facility.
trans_state，设置为TRUE表示上下文可以使用GSS-V2 GSS_Export_sec_context（）功能转移到另一个进程。
These state values are represented (at the C bindings level) in positions within a bit vector which are unused in GSS-V1, and may be safely ignored by GSS-V1 callers.
这些状态值在GSS-V1中未使用的位向量中的位置表示（在C绑定级别），GSS-V1调用者可以安全地忽略这些位置。
New conf_req_flag and integ_req_flag inputs are defined for GSS_Init_sec_context(), primarily to provide information to negotiating mechanisms. This introduces a compatibility issue with GSS-V1 callers, discussed in section 2.2.1 of this specification.
为GSS_Init_sec_context（）定义了新的conf_req_标志和integ_req_标志输入，主要用于向协商机制提供信息。这引入了与GSS-V1呼叫者的兼容性问题，本规范第2.2.1节对此进行了讨论。
Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API implementors in the following areas: implementation robustness, credential management, behavior in multi-mechanism configurations, naming support, and inclusion of optional sequencing services. The token tagging facility as defined in GSS-V2, Section 3.1, is now described directly in terms of octets to facilitate interoperable implementation without general ASN.1 processing code; the corresponding ASN.1 syntax, included for descriptive purposes, is unchanged from that in GSS-V1. For use in conjunction with added naming support facilities, a new Exported Name Object construct is added. Additional name types are introduced in Section 4.
相对于GSS-V1，GSS-V2在以下方面为GSS-API实现者提供了额外的指导：实现健壮性、凭证管理、多机制配置中的行为、命名支持以及可选序列服务的包含。GSS-V2第3.1节中定义的令牌标记设施现在直接用八位字节来描述，以便于互操作实施，无需通用ASN.1处理代码；相应的ASN.1语法（包括用于描述的语法）与GSS-V1中的语法相同。为了与添加的命名支持工具结合使用，将添加新的导出名称对象构造。第4节介绍了其他名称类型。
This GSS-V2 specification adds the following major_status values which are not defined in GSS-V1:
本GSS-V2规范添加了GSS-V1中未定义的以下主要_状态值：
GSS_S_BAD_QOP unsupported QOP value GSS_S_UNAUTHORIZED operation unauthorized GSS_S_UNAVAILABLE operation unavailable GSS_S_DUPLICATE_ELEMENT duplicate credential element requested GSS_S_NAME_NOT_MN name contains multi-mechanism elements GSS_S_GAP_TOKEN skipped predecessor token(s) detected
GSS\U S\U BAD\U QOP不支持的QOP值GSS\U S\U未经授权的操作未经授权的GSS\U S\U不可用的操作未经授权的GSS\U重复的\U元素重复凭证元素请求的GSS\U名称未\u MN名称包含多机制元素GSS\U差距\u令牌已检测到跳过的前置令牌
Of these added status codes, only two values are defined to be returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by GSS_VerifyMIC() and GSS_Unwrap()).
在这些添加的状态代码中，只有两个值被定义为可由GSS-V1中现有的调用返回：GSS_S_BAD_QOP（可由GSS_GetMIC（）和GSS_Wrap（）返回）和GSS_GAP_TOKEN（可由GSS_VerifyMIC（）和GSS_Unwrap（）返回）。
Additionally, GSS-V2 descriptions of certain calls present in GSS-V1 have been updated to allow return of additional major_status values from the set as defined in GSS-V1: GSS_Inquire_cred() has GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN, GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
此外，GSS-V1中存在的某些调用的GSS-V2描述已更新，以允许从GSS-V1中定义的集合中返回其他主要状态值：GSS\U Inquire\U cred（）是否有GSS\U缺陷\U凭据和GSS\U凭据是否过期定义为可返回，GSS\U Init\U sec\U context（）是否有GSS\U旧\U令牌，GSS\U重复\U令牌，GSS_S_BAD_MECH定义为可返回，GSS_Accept_secu context（）将GSS_BAD_MECH定义为可返回。
APPENDIX C
附录C
CHANGES RELATIVE TO RFC-2078
与RFC-2078相关的变更
This document incorporates a number of changes relative to RFC-2078, made primarily in response to implementation experience, for purposes of alignment with the GSS-V2 C language bindings document, and to add informative clarification. This section summarizes technical changes incorporated.
本文件包含了与RFC-2078相关的一些变更，这些变更主要是根据实施经验做出的，目的是与GSS-V2 C语言绑定文件保持一致，并添加信息性澄清。本节总结了合并的技术变更。
General:
概述：
Clarified usage of object release routines, and incorporated statement that some may be omitted within certain operating environments.
阐明了对象发布例程的用法，并合并了在某些操作环境中可以省略某些例程的声明。
Removed GSS_Release_OID, GSS_OID_to_str(), and GSS_Str_to_OID() routines.
删除了GSS_Release_OID、GSS_OID_to_str（）和GSS_str_to_OID（）例程。
Clarified circumstances under which zero-length tokens may validly exist as inputs and outputs to/from GSS-API calls.
阐明了零长度令牌作为GSS-API调用的输入和输出有效存在的情况。
Added GSS_S_BAD_MIC status code as alias for GSS_S_BAD_SIG.
添加了GSS_S_BAD_话筒状态代码作为GSS_S_BAD_信号的别名。
For GSS_Display_status(), deferred to language bindings the choice of whether to return multiple status values in parallel or via iteration, and added commentary deprecating return of GSS_S_CONTINUE_NEEDED.
对于GSS_Display_status（），延迟到语言绑定，选择是并行返回多个状态值还是通过迭代返回多个状态值，并添加注释，以避免返回GSS_S_CONTINUE_。
Adapted and incorporated clarifying material on optional service support, delegation, and interprocess context transfer from C bindings document.
改编并合并了C绑定文档中关于可选服务支持、委托和进程间上下文传输的澄清材料。
Added and updated references to related documents, and to current status of cited Kerberos mechanism OID.
添加并更新了对相关文档以及引用的Kerberos机制OID的当前状态的引用。
Added general statement about GSS-API calls having no side effects visible at the GSS-API level.
添加了关于GSS-API调用在GSS-API级别没有可见副作用的一般性声明。
Context-related (including per-message protection issues):
与上下文相关（包括每条消息的保护问题）：
Clarified GSS_Delete_sec_context() usage for partially-established contexts.
阐明了GSS_Delete_sec_context（）对部分建立的上下文的用法。
Added clarification on GSS_Export_sec_context() and GSS_Import_sec_context() behavior and context usage following an export-import sequence.
添加了关于GSS_导出_sec_context（）和GSS_导入_sec_context（）行为以及导出导入序列后的上下文用法的说明。
Added informatory conf_req_flag, integ_req_flag inputs to GSS_Init_sec_context(). (Note: this facility introduces a backward incompatibility with GSS-V1 callers, discussed in Section 2.2.1; this implication was recognized and accepted in working group discussion.)
向GSS_Init_sec_context（）添加了信息配置请求标志、整数请求标志输入。（注：该设施引入了与GSS-V1呼叫者的向后不兼容，在第2.2.1节中进行了讨论；这一含义已在工作组讨论中得到承认和接受。）
Stated that GSS_S_FAILURE is to be returned if GSS_Init_sec_context() or GSS_Accept_sec_context() is passed the handle of a context which is already fully established.
声明如果向GSS_Init_sec_context（）或GSS_Accept_sec_context（）传递已完全建立的上下文句柄，则返回GSS_S_FAILURE。
Re GSS_Inquire_sec_context(), stated that src_name and targ_name are not returned until GSS_S_COMPLETE status is reached; removed use of GSS_S_CONTEXT_EXPIRED status code (replacing with EXPIRED lifetime return value); stated requirement to retain inquirable data until context released by caller; added result value indicating whether or not context is fully open.
Re GSS_Inquire_sec_context（），声明在达到GSS_S_完成状态之前不会返回src_name和target_name；删除了GSS_S_上下文_过期状态代码的使用（替换为过期生存期返回值）；在调用方释放上下文之前保留可查询数据的规定要求；添加的结果值，指示上下文是否完全打开。
Added discussion of interoperability conditions for mechanisms permitting optional support of QOPs. Removed reference to structured QOP elements in GSS_Verify_MIC().
增加了对允许可选支持QOP的机制的互操作性条件的讨论。删除了GSS_Verify_MIC（）中对结构化QOP元素的引用。
Added discussion of use of GSS_S_DUPLICATE_TOKEN status to indicate reflected per-message tokens.
增加了关于使用GSS_S_DUPLICATE_令牌状态来指示每消息反射令牌的讨论。
Clarified use of informational sequencing codes from per-message protection calls in conjunction with GSS_S_COMPLETE and GSS_S_FAILURE major_status returns, adjusting status code descriptions accordingly.
阐明了每报文保护呼叫中信息排序代码的使用，以及GSS_S_完成和GSS_S_故障主要_状态返回，并相应地调整状态代码描述。
Added specific statements about impact of GSS_GetMIC() and GSS_Wrap() failures on context state information, and generalized existing statements about impact of processing failures on received per-message tokens.
添加了关于GSS_GetMIC（）和GSS_Wrap（）失败对上下文状态信息的影响的特定语句，以及关于处理失败对接收到的每消息令牌的影响的通用现有语句。
For GSS_Init_sec_context() and GSS_Accept_sec_context(), permitted returned mech_type to be valid before GSS_S_COMPLETE, recognizing that the value may change on successive continuation calls in the negotiated mechanism case.
对于GSS_Init_sec_context（）和GSS_Accept_sec_context（），允许返回的mech_类型在GSS_完成之前有效，认识到在协商机制的情况下，该值可能在连续调用时更改。
Deleted GSS_S_CONTEXT_EXPIRED status from GSS_Import_sec_context().
已从GSS_导入_秒_上下文（）中删除GSS_S_上下文_过期状态。
Added conf_req_flag input to GSS_Wrap_size_limit().
将conf_req_标志输入添加到GSS_Wrap_size_limit（）。
Stated requirement for mechanisms' support of per-message protection services to be usable concurrently in both directions on a context.
对机制支持每消息保护服务的规定要求，该服务在上下文的两个方向上同时可用。
Credential-related:
凭证相关：
For GSS_Acquire_cred() and GSS_Add_cred(), aligned with C bindings statement of likely non-support for INITIATE or BOTH credentials if input name is neither empty nor a name resulting from applying GSS_Inquire_cred() against the default credential. Further, stated that an explicit name returned by GSS_Inquire_context() should also be accepted. Added commentary about potentially time-variant results of default resolution and attendant implications. Aligned with C bindings re behavior when
对于GSS_Acquire_cred（）和GSS_Add_cred（），如果输入名称既不是空的，也不是对默认凭据应用GSS_Inquire_cred（）而产生的名称，则与C bindings语句一致，可能不支持INITIATE或这两种凭据。此外，声明还应接受GSS_Inquire_context（）返回的显式名称。增加了关于默认解决方案的潜在时变结果和相关影响的评论。与C绑定一致，在
GSS_C_NO_NAME provided for desired_name. In GSS_Acquire_cred(), stated that NULL, rather than empty OID set, should be used for desired_mechs in order to request default mechanism set.
GSS_C_NO_NAME为所需的_NAME提供。在GSS_Acquire_cred（）中，声明所需的_机械应使用NULL，而不是空OID集合，以便请求默认机械装置集合。
Added GSS_S_CREDENTIALS_EXPIRED as returnable major_status for GSS_Acquire_cred(), GSS_Add_cred(), also specifying GSS_S_NO_CRED as appropriate return for temporary, user-fixable credential unavailability. GSS_Acquire_cred() and GSS_Add_cred() are also to return GSS_S_NO_CRED if an authorization failure is encountered upon credential acquisition.
为GSS_Acquire_cred（）、GSS_Add_cred（），添加的GSS_S_凭证_已过期，作为可返回的主要凭证状态，还指定了GSS_S_NO_cred作为临时、用户可修复凭证不可用的适当返回。如果在获取凭证时遇到授权失败，则GSS_Acquire_cred（）和GSS_Add_cred（）也将返回GSS_S_NO_cred。
Removed GSS_S_CREDENTIALS_EXPIRED status return from per-message protection, GSS_Context_time(), and GSS_Inquire_context() calls.
已从每消息保护、GSS_上下文_time（）和GSS_Inquire_Context（）调用中删除GSS_凭据_过期状态返回。
For GSS_Add_cred(), aligned with C bindings' description of behavior when addition of elements to the default credential is requested.
对于GSS_Add_cred（），与请求向默认凭证添加元素时C绑定的行为描述一致。
Upgraded recommended default credential resolution algorithm to status of requirement for initiator credentials.
已将推荐的默认凭据解析算法升级为启动器凭据的要求状态。
For GSS_Release_cred(), GSS_Inquire_cred(), and GSS_Inquire_cred_by_mech(), clarified behavior for input GSS_C_NO_CREDENTIAL.
对于GSS_Release_cred（）、GSS_Inquire_cred（）和GSS_Inquire_cred_by_mech（），阐明了输入GSS_C_NO_凭证的行为。
Name-related:
姓名相关：
Aligned GSS_Inquire_mechs_for_name() description with C bindings.
使用C绑定对齐GSS_Inquire_mechs_以获取_name（）说明。
Removed GSS_S_BAD_NAMETYPE status return from GSS_Duplicate_name(), GSS_Display_name(); constrained its applicability for GSS_Compare_name().
已从GSS_Duplicate_name（）、GSS_Display_name（）中删除GSS_BAD_NAMETYPE状态返回；限制其对GSS_Compare_name（）的适用性。
Aligned with C bindings statement re GSS_Import_name() behavior with GSS_C_NO_OID input name type, and stated that GSS-V2 mechanism specifications are to define processing procedures applicable to their mechanisms. Also clarified GSS_C_NO_OID usage with GSS_Display_name().
与具有GSS_C_NO_OID输入名称类型的C bindings语句re GSS_Import_name（）行为一致，并声明GSS-V2机制规范将定义适用于其机制的处理过程。还澄清了GSS_显示名称（）中的GSS_C_NO_OID用法。
Downgraded reference to name canonicalization via DNS lookup to an example.
通过DNS查找将对名称规范化的引用降级为示例。
For GSS_Canonicalize_name(), stated that neither negotiated mechanisms nor the default mechanism are supported input mech_types for this operation, and specified GSS_S_BAD_MECH status to be returned in this case. Clarified that the GSS_Canonicalize_name() operation is non-destructive to its input name.
对于GSS_Canonicalize_name（），声明此操作不支持协商机制或默认机制的输入机械类型，并指定在这种情况下返回GSS_S_BAD_mech状态。阐明GSS_Canonicalize_name（）操作对其输入名称没有破坏性。
Clarified semantics of GSS_C_NT_USER_NAME name type.
阐明了GSS\U C\U NT\U用户名类型的语义。
Added descriptions of additional name types. Also added discussion of GSS_C_NO_NAME and its constrained usage with specific GSS calls.
添加了其他名称类型的说明。还添加了关于GSS_C_NO_名称及其在特定GSS调用中的受限使用的讨论。
Adapted and incorporated C bindings discussion about name comparisons with exported name objects.
改编并合并了关于与导出的名称对象进行名称比较的C绑定讨论。
Added recommendation to mechanism designers for support of host-based service name type, deferring any requirement statement to individual mechanism specifications. Added discussion of host-based service's service name element and proposed approach for IANA registration policy therefor.
向机制设计人员添加了支持基于主机的服务名称类型的建议，将任何需求声明推迟到各个机制规范。增加了对基于主机的服务的服务名称元素的讨论，并提出了IANA注册策略的建议方法。
Clarified byte ordering within exported name object. Stated that GSS_S_BAD_MECH is to be returned if, in the course of attempted import of an exported name object, the name object's enclosed mechanism type is unrecognized or unsupported.
阐明了导出的名称对象中的字节顺序。声明如果在尝试导入导出名称对象的过程中，名称对象的封闭机制类型无法识别或不受支持，则将返回GSS_S_BAD_MECH。
Stated that mechanisms may optionally accept GSS_C_NO_NAME as an input target name to GSS_Init_sec_context(), with comment that such support is unlikely within mechanisms predating GSS-V2, Update 1.
声明机制可以选择性地接受GSS_C_NO_NAME作为GSS_Init_sec_context（）的输入目标名称，并说明在GSS-V2之前的机制中不太可能提供此类支持，更新1。
AUTHOR'S ADDRESS
作者地址
John Linn RSA Laboratories 20 Crosby Drive Bedford, MA 01730 USA
美国马萨诸塞州贝德福德克罗斯比大道20号John Linn RSA Laboratories 01730
Phone: +1 781.687.7817
EMail: jlinn@rsasecurity.com
Phone: +1 781.687.7817
EMail: jlinn@rsasecurity.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。