RFC 2078

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者： Jessie（zhenm2000  jessie0630@263.net）
译文发布时间：2001-6-14
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保
留本文档的翻译及版权信息。


Network Working Group                                           J. Linn
Request for Comments: 2078                      OpenVision Technologies
Category: Standards Track                                  January 1997
Obsoletes: 1508

   

通用安全服务应用接口（GSS-API） V2
(RFC2078 Generic Security Service Application Program Interface, Version 2)

备忘录状态
   这个备忘录为因特网社区提供信息。它没有详细说明任何一种网络标准。这个备忘录的发布
没有限制。
 
摘要
在rfc1508中定义的通用安全服务应用接口（GSS-API）以一种通用的方式为调用者提供安
全服务，它支持多种底层机制和技术，允许应用程序在源代码级移植到不同环境中。这个规范
定义了不依赖于底层机制和编程语言环境的GSS-API服务和原语。还需要被其他人完成的相关
的规范是：
    1、绑定特定语言的参数定义文档。
    2、在具体安全机制上实现GSS-API服务的Token格式、协议和处理过程的定义文档。
这个规范修订RFC-1508，根据实现经验和提出的要求做了更详细、增强的改进。希望本规
范或者起后续版本，在标准化的道路上，成为后续发展GSS-API规范的一个基础。
目录
1:GSS-API的特征和概念
1.1:GSS-API的构造
1.1.1:信任状
1.1.1.1:信任状构造和概念
1.1.1.2:信任状管理
1.1.1.3:默认的信任状解析
1.1.2:令牌
1.1.3:安全上下文
1.1.4:机制类型
1.1.5:命名
1.1.6:通道绑定
1.2:GSS-API的特点和发布
1.2.1:状态报告
1.2.2:Per-Message安全服务可用性
1.2.3: Per-Message重发检测和顺序性
1.2.4:保护的级别
1.2.5:匿名支持
1.2.6:初始化
1.2.7:上下文建立期间Per-Message的保护
1.2.8:实现的健壮性
2:接口描述
2.1:信用状管理调用
2.1.1:GSS_Acquire_cred 调用
2.1.2:GSS_Release_cred 调用
2.1.3:GSS_Inquire_cred 调用
2.1.4:GSS_Add_cred 调用
2.1.5:GSS_Inquire_cred_by_mech 调用
2.2:上下文级调用
2.2.1:GSS_Init_sec_context 调用
2.2.2:GSS_Accept_sec_context 调用
2.2.3:GSS_Delete_sec_context 调用
2.2.4:GSS_Process_context_token 调用
2.2.5:GSS_Context_time 调用
2.2.6:GSS_Inqiure_context 调用
2.2.7:GSS_Wrap_size_limit 调用
2.2.8:GSS_Export_sec_context 调用
2.2.9:GSS_Import_sec_context 调用
2.3:Per-Message调用
2.3.1:GSS_GetMIC 调用
2.3.2:GSS_VerifyMIC 调用
2.3.3:GSS_Wrap 调用
2.3.4:GSS_UnWrap 调用
2.4:支持调用
2.4.1:GSS_Display_status 调用
2.4.2:GSS_Indicate_mechs 调用
2.4.3:GSS_Compare_name 调用
2.4.4:GSS_Display_name 调用
2.4.5:GSS_Import_name 调用
2.4.6:GSS_Release_name 调用
2.4.7:GSS_Release_buffer 调用
2.4.8:GSS_Release_OID_set 调用
2.4.9:GSS_Create_empty_OID_set 调用
2.4.10:GSS_Add_OID_set_member 调用
2.4.11:GSS_Test_OID_set_member 调用
2.4.12:GSS_Release_OID 调用
2.4.13:GSS_OID_to_str 调用
2.4.14:GSS_Str_to_OID 调用
2.4.15:GSS_Inquire_names_for_mech 调用
2.4.16:GSS_Inquire_mechs_for_name 调用
2.4.17:GSS_Canonicalize_name 调用
2.4.18:GSS_Duplicate_name 调用
3:GSS-API V2使用的数据结构定义
3.1:机制独立的Token格式
3.2:机制独立的输出名字对象(Exported Name Object)格式
4:名字类型定义
4.1:主机名字服务形式
4.2:用户名字形式
4.3:机器UID形式
4.4:字符串UID形式
5:特定机制的例子说明
5.1:Kerberos V5,单独TGT
5.2:Kerberos V5,双重TGT
5.3:X.509认证框架
6:安全考虑
7:有关内容
附录A:机制设计约束
附录B:和GSS-V1的兼容性
1:GSS-API的特征和概念
GSS-API在下列模式中使用。一个典型的GSS-API调用者是通讯协议本身，调用GSS-API，
用可信性、完整性和机密性的安全服务来保护他的通讯。调用者接受一个本地GSS-API实现提
供的一个令牌，并且把令牌传送给远程系统的对应方；对方接收令牌并把其传送给他的GSS-API
本地实现处理。通过GSS-API这种方式实现的可用的安全服务在基于公钥和私钥的底层加密技
术的多种机制上可实现的。
GSS-API把双方安全上下文初始化操作从使用上下文的pre_message数据源认证操作和保
护传送消息的完整性操作中分离开来。（初始化操作――GSS_Init_sec_context()和
GSS_Accept_sec_context()调用；数据源认证操作和保护传送消息的完整性操作――
GSS_GetMIC()和GSS_VerifyMIC()调用）（这个安全服务定义，和其他在这篇文档中使用的定义，
对应于ISO74982-2-1988（E）提供的标准，安全体系结构）。当建立安全上下文时，GSS-API允
许上下文发起者可选的使用它的信任状，这意味着上下文的接收者可以根据发起者的行为来初
始化安全上下文。Pre_message的GSS_Wrap()和GSS_Unwrap()调用提供了数据源的认证，数据
完整性的服务（同GSS_GetMIC()和GSS_VerifyMIC()提供的），也提供加密服务的选择――作为
在调用时的选项。其他调用为GSS-API使用者提供支持功能。
以下段落提供一个例子说明使用GSS-API涉及的数据流程――被客户端和服务器通过一种
机制独立的方式使用，来建立安全上下文和传输被保护的数据。这个例子假设已经获得信用状。
这个例子假设底层认证技术能够使用一个Token中载有的元素认定客户（向服务器），同时使用
一个返回的Token向客户端认证服务器（互相认证）；这个假设对当前的CAT文档的机制成立，
但对于其他的加密技术和相关协议不一定为成立。
客户调用GSS_Init_sec_context()和用targ_name表示的服务器建立一个安全上下文，并
且设置mutual_req_flag，因而在上下文建立过程中完成互相认证。GSS_Init_sec_context()
返回一个output_token传递给服务器，并且指示GSS_S_CONTINUE_NEEDED状态以等待互相认证
的顺序完成。如果mutual_req_flag没有被设置，初始化调用GSS_Init_sec_context()将返回
GSS_S_COMPLETE状态。客户发送output_token给服务器端。
服务器传递接收到的Token作为GSS_Accept_sec_context()的输入参数input_token。
GSS_Accept_sec_context()显示GSS_S_COMPLETE状态，根据src_name认证客户的标识，并且
生成将要传递给客户的output_token。服务端传递output_token给客户。
客户把接收到的Token传递给GSS_Init_sec_context()作为后续调用的input_token参数,
它处理Token中的数据以完成从客户发起的互相认证。这次调用GSS_Init_sec_context()返回
GSS_S_COMPLETE状态，表示成功的互相认证和上下文建立的完成。
客户端产生数据消息并且把它传递个GSS_Wrap()，GSS_Wrap()完成数据源的认证，数据完
整性，（可选的）消息的加密处理，封装结果为output_message，标识GSS_S_COMPLETE状态。
客户端发送output_message给服务器端。
服务器端传递接收到的消息给GSS_Unwrap().GSS_Unwrap()解封装，如果消息加密了就解
密，并且验证数据源的可信性和数据完整性的检查。GSS_Unwrap()通过返回GSS_S_COMPLETE状
态表示成功确认，同时返回结果output_message。
为了说明这个例子，我们假设服务端表示“out-of-band”的意思为：当在一个被保护的消
息从客户端传送到服务端后，这个上下文将不被使用了。在这个前提下，服务端调用
GSS_Delete_sec_context以更新上下文级的信息。可选的，服务端的应用可以提供一个token
缓存给GSS_Delee_sec_context()，以接收一个context_token，传递给客户端，请求客户端将
上下文级信息删除。
如果接收到一个服务器传送来的context_token，客户端传递context_token给
GSS_Peocess_context_token（）――它在客户端系统上删除上下文级消息后返回
GSS_S_COMPLETE状态。
GSS-API的设计假定和强调以下几个基本目标：
机制独立：GSS-API定义了一个接口来使用密码技术实现强壮的认证和其他安全服务―
―在独立于特定的底层机制的通用层上。例如，GSS-API提供的服务可以被密钥技术实现（例
如，Kerberos）或者公钥技术实现（例如 X.509）。
协议环境独立：GSS-API独立于使用它的通讯协议组，允许在多种协议环境中使用。在
适当的环境中，一个中介的实现"veneer"――它是面向一个特定的通讯协议（例如，RPC）的，
可以被提出――在调用那个协议和GSS-API的应用程序中间，因此GSS-API功能的起用和协议
通讯的起用是同步的。
协议联合的独立：GSS-API安全上下文构造是独立于通讯协议相关的构造的。这个特点
允许单独的GSS-API实现可以被多种协议模块使用，以利于调用这些模块的应用程序。GSS-API
服务也可以被应用程序直接调用，完全独立于协议关联。
适应多种实现：GSS-API客户不是被限制存在于实现GSS-API的系统定义的TCB（Trusted 
Computing Base）范围内；安全服务被以一种既适应intra-TCB调用，又适用extra-TCB调用
的方式说明。
1.1:GSS-API构造
这节描述组成GSS-API的基本元素。
1.1.1:信任状
1.1.1.1:信任状构造和概念
信任状提供了允许使用GSS-API的双方建立安全上下文的先决条件。调用者可以指定用于
上下文发起或者接收的默认的信任状元素。另一方面，需要对特定的信任状结构做出明显的选
定的GSS-API调用者，可以通过GSS-API提供的信任状句柄（cred_handles）对信任状引用。
在任何一种情况，调用者的信任状引用都是间接的，被GSS-API的实现维护，并且不要求调用
着访问选定的信任状元素。
一个单独的信任状结构可以用于开始一个输出的上下文，接收输入的上下文。当信任状为
使用而被获得时，需要在这些模式的操作的调用者可以指定这种情况：允许底层机制优化他们
的处理过程和存储要求。一个特定机制定义的信任状元素可以包含多个加密密钥，例如，使用
不同算法用于完成认证和消息加密的密钥。
一个GSS-API信任状结构可以包含多个信任元素，每个都包含特定底层机制的识别信息
（mech_type）,但一个给定信任状结构中的元素集都代表同一个实体。一个信任状结构的内容
将根据特定的GSS-API实现所支持的mech_type集而不同。每个信任状元素表示被它的机制需
求以建立上下文（在特定主体上）的数据，和用于上下文发起、上下文接收时使用的独立的信
任状引用。给定信任状中的多个信任状元素重叠机制、使用模式和有效期的组合是不允许的。
一般的，一个单独的mech_type用于在特定的发起者和特定的目标间建立所有的安全上下
文。支持代表多个mech_type的信任状元素集的主要目的是允许一个系统的发起者（支持多种
类型）向目标发起上下文，目标只提供支持发起者系统支持集合的一个子集。
1.1.1.2:信任状管理
一个底层系统特定的机制和位于GSS-API底层的OS功能的责任是保证获得和使用信任状―
―关联它的特定实体在系统中被制约于适当处理过程。这个责任应该被实现者认真对待，作为
一个实体使用主体信任状的能力等同于这个实体成功声明主体身份的能力。
一旦GSS-API的信任状集建立起来，信任集到系统中其他处理或者类似结构的传递性是一
个本地问题，没有被GSS-API定义。例如，一个本地策略是信任状被作为一个给定帐户login
的结果被接收，或者代表那个帐户的使用权利，以被在那个帐户下运行的其他进程访问或者传
递。
信任状的建立进程（特别是用户完成的行为而不是服务器过程时）可能要求访问密码或者
其他被本地保护的东西，并且暴露尽可能少的时间。结果，通过本地方式，在用户login时执
行预备信任状的建立过程被是合适的，它的结果被缓存以用于以后引用。这个预备信任状为后
来的使用将被保留（以系统说明方式），或者：
当调用GSS-API的GSS_Acquire_cred()时被访问，返回一个显示的信任状引用句柄。
构成将被安装的默认的信任状元素，并且在处理中要求一个默认的信任状时被使用。
1.1.1.3:默认的信任状解析
gss_init_sec_context()和gss_accept_sec_context例程允许值GSS_C_NO_CREDENTIAL被
说明作为其信任状参数。这个特定的信任状句柄表示应用程序需要的作为默认主题。当特定的
GSS-API实现与判定默认适当机制的行为无关时，推荐使用以下例程的默认行为，以利于移植
性：
GSS_Init_sec_context:
(i)如果只有一个单独的主体能发起安全上下文――是他的应用程序授权使用的行为，则这
个主体被使用，否则
(ii)如果平台维护一个默认的网络标识，并且如果应用程序被授权具有为了发起安全上下
文标识的行为，则对应那个标识的主体被使用，否则
(iii) 如果平台维护一个默认的本地标识，并且提供把本地标识转换为网络标识的手段，
并且如果应用程序被授权具有为了发起安全上下文标识的应像网络标识到本地默认标识的行
为，则对应那个标识的主体被使用，否则
(iv)一个用户配置的默认标识将被使用。
GSS_Accept_sec_context:
(i)如果只有一个单独的经过认证的主体标识具有接收安全上下文的能力，则这个主体将被
使用，否则
(ii)如果机制能够通过检查上下文建立的Token判定目标主体的标识，并且如果接收应用
程序被授权作为接收安全上下文的主体，则主题标识被使用，否则
(iii) 如果机制支持任何主体接收上下文，并且没有互相认证，任何应用程序被授能接收
安全上下文的主体都可以被使用，否则
(iv)一个用户配置的默认标识将被使用。
以上规则的目的是在任何可能的情况下允许发起者和接收者使用默认的行为建立安全上下
文。应用程序使用默认行为比使用GSS_Acquire_cred来取得一个特定标识更容易跨机制和平台
的移植。
1.1.2:令牌
令牌是传递在GSS-API调用者间的数据元素，并且分为两类。上下文令牌被交换以用来在
双方间建立和管理安全上下文。Per_message 令牌和特定的上下文关联并且被交换以提供对对
应数据安全服务（数据源的认证、完整性、可选择的机密性）。
第一个上下文级标识（从GSS_Init_sec_context()获得）是被要求在开始的部分必须表示
出一个个全局可解释的机制标识符，例如，一个安全机制的对象标识符（OID）。令牌的其余部
分和其他令牌的整个内容一样，说明一个使用的特定底层机制以支持GSS-API。这篇文章的第
三部分为GSS-API支持机制的设计者提供第一个上下文级令牌的头部描述，随后跟随机制说明
消息。
令牌内容从GSS-API调用者来看是不透明的。他们在最终系统的GSS-API实现中产生，提
供给调用着传递给远程系统对应的GSS-API调用者，并且被远端的GSS-API实现者处理。令牌
被GSS-API调用输出（并且被传递给对方的GSS-API调用），调用返回的状态标识说明调用是否
成功完成。令牌传递可以以in-band的方式发生，集成到被GSS-API调用者使用的传送其他数
据的同一个流中，或者以out-of-badn方式跨越逻辑分离的通道。
不同的GSS-API 令牌用于不同的目的（例如，上下文发起、上下文接收、在一个已建立的
上下文上保护消息数据等），并且GSS-API的调用有责任区分接收到的令牌类型,使用对应的安
全上下文关联他们，传递他们给适当的GSS-API处理例程。根据调用者的协议环境，这些区分
可以有以下几种方式完成。以下例子说明区分令牌类型的手段：
――基于语句信息的隐式标志（例如，一个新联合中的所有令牌将被认为上下文建立令牌
直到上下文建立完成，在此之后，所有的令牌将被认为是使用那个上下文处理的数据对象）
――在调用协议层显示的标识
――这些方法的混合物
一般的，在令牌中封装的数据包括内部的机制标志信息，使机制层处理模块能够区分令牌
在机制中不同的用途。这种内部的机制层标志推荐给机制的设计者，并且使机制可以判断一个
调用者是否传递一个特定的令牌给一个不适当的GSS-API例程处理。
基于特定底层加密技术和协议的基本元素，支持这些的基本元素的GSS-API的开发并不意
味着使用这种GSS-API机制的GSS-API调用者能够和使用同样技术和协议的的对方在GSS-API
范围之外进行互操作，或者和一个基于同样底层技术的实现不同机制的对方进行互操作。
GSS-API 令牌的格式定义是和特定的机制联合的，并且集成这些令牌到调用者协议的技术，不
能和基于相同技术的非GSS-API调用令牌互操作。
1.1.3:安全上下文
安全上下文在双方间被建立，联合使用每方本地建立的信任状或者是通过代表接收的信任
状。多个上下文在一对双方间可同时存在，使用相同或者不同的信任状集。当信任过期时，使
用不同信任状的多个上下文共存有利于延续。基于相同信任状的多个上下文间的区分是通过区
分在安全情形中不同的信息流来服务于程序。
GSS-API是独立与底层协议和地址结构的，通过它的调用者来传输GSS-API所提供的数据
元素。作为这些因素的结果，调用者的责任是分析通讯消息，从调用者提供的数据元素中分离
出GSS-API相关的数据元素。GSS-API是独立于面向连接或者非连接的底层通讯服务的。
在安全上下文和相关通讯协议联合间没有任何相互关系被规定（可选的通道绑定功能，在
文档中的1.1.6节中讨论，代表这个规则的一个故意例外，在GSS-API支持的机制中支持额外
的保护特性）。这种分离特性允许GSS-API可以被使用在一个广范围的通讯环境中。并且简化了
单个调用的调用顺序。在多种场合（依赖于底层安全协议，和机制相关，并且和缓存信息的可
用性相关），用于上下文设置的语句信息可以和原始签名的用户数据同时发送，而不用提取额外
的信息交换。
1.1.4:机制类型
为了成功的与目标方建立安全上下文，对发起方和目标方都支持底层机制类型（mech_type）
进行标识是必须的。机制的定义不仅包含使用特定的加密技术（或者混合的或者可选择的加密
技术），并且也定义数据元素（机制将要使用的以支持安全服务）交换的语法和语义。
建议调用者发起上下文时说明默认的mech_type_value，允许系统特定的功能或者被
GSS-API实现者调用的功能来选择适当的mech_type，但调用者可以在需要时直接使用特定的
mech_type。
在不同的环境中，与对方建立安全上下文时标识共享mech_type的方法将改变。例子包括
（但不限于）：
使用固定的mech_type，在环境中的配置文件定义
基于目标说明的语义规范，通过检查目标名字
在名字服务或其他数据库中查找目标名字以标识被目标支持的mech_types
显示的在GSS-API调用者间握手以便于安全上下文的设置
当在GSS-API双方间传送时，mech_type说明符（在3节，表示为对象标识符OIDs）服务
限定于限定相关标识的解释。（对象标识符的结构和编码定义在ISO/ICE8824，ASN.1规范和
ISO/ICE8825为ASN.1的BER说明）使用分层次的结构OIDs以排除关于mech_type说明符的不
准确的解释。例如，代表DASS mech_type的OID，是1.3.12.2.1011.7.5，是Kerberos V5机
制的，更进一步先进级是1.2.840.113554.1.2.2。
1.1.5:命名
GSS-API避免指定名字结构，把用以发起或者接收安全上下文而跨接口传递的名字看作完
整（透明）的对象。这个方法支持了GSS-API在多种底层安全机制之上实现的目标，不同的机
制处理和认证具有不同的形式的名字。在任意的名字环境集合中提供通用的名字转换功能服务
超出了GSS-API的范围；在一个特定最终系统上，支持名字形式之间转换的本地功能和可用性
是被希望的。
通过不同的GSS-API参数使用不同的名字类别。
――内部形式（在此文档中表示为INTERNAL NAME），对调用者是透明的，由每个具体的
GSS-API实现定义。支持的多重名字空间类型的GSS-API实现必须维护内部标签以明确解释给
定的名字。机制名（MN）是一个特殊的INTERNAL NAME实例，保证包含的元素只对应一个机制。
在此规范中，保证发出MN或者要求MN作为输入的函数调用被说明。
――连续的串（"flat"）形式(在此文档中标识为OCTET STRING)；被OID标签伴随以标
识所对应的名字空间。根据标签的值，flat名字可以是被显示的或不是可显示的串，以用于直
接被接收或者显示给最终用户。Flat名字的标标签允许GSS-API调用者和底层GSS-API机制区
分名字类型以判定是否有能力处理相关的名字类型，避免因为错误解释一个类型名字为另一个
名字类型而导致的别名问题。
――GSS-API输出名字对象（Export Name Object），一个flat名字的特殊实例，被特定
的OID值标识，载有有适于二进制比较的规范形式的名字。
除了提供以类型标识名字的方式外，这个规范为特定的应用程序调用还定义了一些基本元
素以支持命名环境的独立性。为了使调用者不需要自己解释名字的内部语法或者语义，为他们
提供了一些基本的服务，定义的调用函数包括：用于名字比较的GSS_Compare_name()，用于显
示名字可读串的GSS_Display_name()，用于转换输入的GSS_Import_name()，用于内部名字释
放的GSS_Release_name()和内部名字复制的GSS_Duplicate_name()。（期望这些提出的
GSS-API调用函数在多个最终系统上被实现，实现基于这些最终系统内现存在的维护系统特定
类型名字的基本功能；                          也包括希望GSS-API提供给GSS-API调用
者可移植的方式以完成特定的操作，在认证的名字上支持授权和审核要求。）
GSS_Import_name()实现可以支持给定名字空间多个可打印句法（例如，多种可选择的X.509 
DN名字的表示），允许调用者机动的选择一种表示形式。GSS_Display_name()实现输出一个选
定的、适应他们操作环境的可打印句法；选择是一个本地问题。对于希望具有跨越多个可选择
的打印语法可移植性的调用者，应该避免基于可打印名字形式的名字比较实现，而应该使用
GSS_Compare_name()调用来判定一个内部格式的名字是否和另外一个匹配。
GSS_Canonicalize_name()和GSS_Export_name()可以使调用者获得和处理一个Exported 
Name Object，规范和转化依据于一个特定的GSS_API机制的处理过程。Exported Name Object
也可以作为GSS_Import_name()的输入，产生一个等价的MNs。设计的这些功能是为了高效的存
储和比较名字（例如，在访问控制列表中使用）。
以下图表说明了名字相关的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()

1.1.6:通道绑定
GSS-API允许调用者提供通道绑定（chan_binding）信息的概念。在上下文建立期间，通
过使用通道绑定加强质量，用以提供双方间的实体鉴别――通过限制范围（在范围中攻击者截
取的上下文建立令牌能被拒绝）。特别的，他们可以使GSS-API调用者把一些底层通讯通道（保
护的机制使用此通讯通道）的相关特性（例如，地址，加密密钥的传输表现形式）绑定给安全
上下文建立，也可以绑定应用程序相关的数据。
发起安全上下文的调用者必须判定合适的通道绑定的值以提供给GSS_Init_sec_context()
调用作为输入，并且相同的值必须被上下文目标提供给GSS_Accept_sec_context()――为了使
双方的GSS-API机制来验证接收到的令牌是否正确处理了通道相关特性。使用或者不使用
GSS-API通道绑定功能由调用者选择。GSS-API可以在一个通道绑定表示为NULL的环境中工作。
鼓励实现者在他们的机制中使用调用者提供的通道绑定数据，但不是必须要求。调用者不能假
设底层机制为通道绑定消息提供机密保护。
当非空的通道绑定被调用者提供时，通过解析绑定的内容可以增强安全（不是通过简单重
现这些在令牌内的绑定值或者通过对他们计算来检查完整性），并且依靠在定义的格式中的特定
数据来表现。到最后，机制实现者间同意定义通道绑定参数内容的通用解释，包括上下文发起
者和接收者的地址说明符（内容依赖于通讯协议环境）。（这些约定被写进GSS-API机制说明和
GSS-API C语言绑定说明中。）为了GSS-API调用者可以在多个机制间移植并且对每一个机制提
供的安全功能完全的使用，强烈推荐GSS-API调用者提供和这些约定以及和他们所操作的网络
环境一致的通道绑定。
1.2:GSS-API的特点和发布
这节描述了关于GSS-API的操作，GSS-API提供的安全服务和设计文档的注释。
1.2.1:状态报告
每个GSS-API调用提供两个状态以返回值，主状态值提供一个机制独立的调用状态标识（例
如：GSS_S_COMPLETE，GSS_S_FAILURE，GSS_S_CONTINUE_NEEDED），足够使一个调用者以普通方
式驱动一个普通的控制流程。表1以表格方式总结了定义的major_status返回码。
表1 GSS-API主要的状态编码
致命的错误编码
GSS_S_BAD_BINDINGS                                 通道绑定错位
GSS_S_BAD_MECH                                     不支持要求的机制
GSS_S_BAD_NAME                                     提供的名字无效
GSS_S_BAD_NAMETYPE                                 提供了不支持的名字类型
GSS_S_BAD_STATUS                                   无效的输入状态选择
GSS_S_BAD_SIG                                      令牌含有无效的完整性检查
GSS_S_CONTEXT_EXPIRED                              指定的安全上下文过期
GSS_S_CREDENTIALS_EXPIRED                          信任状过期
GSS_S_DEFECTIVE_CREDENTIALS                        有缺陷的信任状
GSS_S_DEFECTIVE_TOKEN                              有缺陷的Token
GSS_S_FAILURE                                      GSS-API层未说明的错误
GSS_S_NO_CONTEXT                                   没有指定有效的安全上下文
GSS_S_NO_CRED                                      没有提供有效的信任状
GSS_S_BAD_QOP                                      不支持的QOP值
GSS_S_UNAUTHORIZED                                 操作未授权
GSS_S_UNAVAILABLE                                  操作无效
GSS_S_DUPLICATE_ELEMENT                            要求的信任元素重复
GSS_S_NAME_NOT_MN                                  名字包含多机制元素

消息状态编码
GSS_S_COMPLETE                                     正常结束
GSS_S_CONTINUE_NEEDED                              需要继续调用例程
GSS_S_DUPLICATE_TOKEN                              重复的Pre-message Token
GSS_S_OLD_TOKEN                                    过期的Pre-message Token
GSS_S_UNSEQ_TOKEN                                  滞后的Pre-message Token
GSS_S_GAP_TOKEN                                    超前的Pre-message Token

Minor_status提供更详细的状态信息――包含底层安全机制特定的状态编码信息。
Minor_status的值在这篇文档中没有说明。
GSS_Init_sec_context()和GSS_Accept_sec_context()调用提供GSS_S_CONTINUE_NEEDED 
major_status 返回和可选的消息输出，所以在应用程序中，机制使用的不同数量的消息不需要
以单独的编码路径反映。另外，这种情况也提供给顺序的调用GSS_Init_sec_context()和
GSS_Accept_sec_context()。在GSS-API的上下文初始化调用中，同样的机制被使用用来包装
多方认定。
对于那些为了建立安全上下文而需要和第三方服务器进行互操作的的mech_types，GSS-API
上下文建立调用可以阻碍与第三方交互挂起的完成。
另一方面，没有任何GSS-API调用挂起于和对方的GSS-API实体的连续互操作。所以，本
地的GSS-API的状态返回不能反映发生在远程对应系统上的不可预知的或是同步的例外，反映
这种状态信息是GSS-API之外的GSS-API调用者的责任。
1.2.2:Pre-Message安全服务可用性
当一个安全上下文建立后，两个标志被返回以标识在上下文上可用的Pre-Message保护安
全服务集：
integ_avail标志标识Pre-Message的完整性和数据源认证服务是可用的
conf_avail标志标识Pre-Message的机密服务是可用的，并且如果integ_avail不返回
TRUE，它也将不能返回TRUE。
GSS-API调用者希望预消息安全服务能够在上下文建立时检查这些标志的值，并且必须知
道integ_avail返回FALSE值意味着调用GSS_GetMIC()或者GSS_Wrap()（基于相关的上下文）
时对用户数据消息没有任何加密保护。
GSS-API的预消息完整性和数据源的认定服务对接收的调用者提供了一种保证――在安全
上下文上对方对消息应用了保护，对应于上下文在初始化时命名的实体。GSS-API预消息机密
服务对调用发送者提供了保证――消息内容被保护从可访问者那里，而不是上下文命名的对方。
GSS-API预消息保护服务，作为名字应用的类别，是面向于协议数据单元尺寸操作的。他
们对单元数据的加密操作，在标识中传递加密控制信息，并且在GSS_Wrap中，包装数据单元。
这些简单的功能不是面向高效率的流范例协议的数据保护（例如telnet），如果加密必须应用
八进制到八进制基础上。
1.2.3:预消息重发的检测和序列
某些底层的mech_type在支持的上下文基础上提供对消息的重发检测和消息的顺序发送的
支持。这些可选择的保护特性与上下文建立操作本身的重发检测和顺序特性是不同的。是否存
在在上下文级的重发或者顺序特性是底层机制类型功能下的一个完整的功能，并且不是可以被
调用者选用或者忽略的
调用者初始化上下文提供的标志（replay_det_req_flag和sequence_req_flag）定义是否在上
下文建立时使用预消息的重发检测和顺序特性，。发起方系统的GSS-API实现能决定作为机制类
型的功能是否支持这些特性，而不需要和对方协商。当启动这些功能时，这些特性向接收者提
供一个标志--做为GSS-API处理输入信息的结果，标识这些信息是否被检测到有重复或是顺序
不对。检测这些事件不能防止可疑信息发给接收者；对于可疑信息的正确的处理过程是一个调
用者的策略。
应用于接收消息的重复检测和顺序服务的语义，作为可见的跨接口由GSS-API提供给它的
客户端，内容如下：
当replay_det_state是TRUE时，可能的major_status返回（为了正确的形式和正确的消
息签名）为以下内容：
1.GSS_S_COMPLETE标识窗口（时间和空间顺序）内消息允许重复事件被检测，并且当前消
息不是那个窗口以前处理的消息的回应。
2	.GSS_S_DUPLICATE_TOKEN表示接收到消息上的加密校验值是正确的，但此消息被认为是以
前处理过消息的一个重复。
3.GSS_S_OLD_TOKEN表示接收到消息上的加密校验值是正确的，但那条消息用于检测重发
已经过期了。
当sequence_state是TRUE时，格式和签名正确的消息的major_state可能的返回值如下：
1.GSS_S_COMPLETE标识窗口（时间和空间顺序）内消息允许重复事件被检测，并且当前消
息不是那个窗口以前处理的消息的回应。并且没有以前处理过的消息丢失（相对于最后接到的
消息――已经在上下文上用正确的加密检测值处理过）。
2.GSS_S_DUPLICATE_TOKEN标识在已经接收到的消息上的完整性值检测是正确的。但这条
消息被认为是以前处理消息的一个重复。
3. GSS_S_OLD_TOKEN表示接收到消息上的完整性校验值是正确的，但那条消息用于检测重
发已经过期了。
4.GSS_S_UNSEQ_TOKEN标识在已接收消息上的加密校验值是正确的，但是对于在上下文上
已经处理过的消息来说，他在顺序流上提前的。[注意：机制可以被建立以提供严格的顺序服务
形式，传送一条特定的信息只有在所有的以前处理过的消息以正确的顺序传递之后。这种支持
类型和GSS-API的情形（接收者接收所有消息，不管是否按顺序，提供他们给GSS-API函数确
认――只在每次时，不包括GSS-API内的缓存中的消息）是矛盾的。GSS-API工具提供的支持
功能，帮助客户端完成严格的消息流完整性检测――由通讯协议提供的，和顺序联合，以一种
高效率的方式，但是GSS-API本身不提供在此级别上的流完整性检测服务。
5.GSS_S_GAP_TOKEN标识在已接收消息上的加密校验值是正确的，但是相对于最后接收到
的并且在上下文上有一个正确的加密检测值的消息来说，一个或者多个以前顺序的消息没有被
成功处理。
作为消息流完整性特点（特别是顺序）可以和特定的应用程序通讯范例接口，并且支持可
能的资源特性，强烈推荐mech_type支持这些特性――当上下文建立时，允许他们对于发起者
请求有选择的激活。上下文的发起者和接收者提供相应的指示器（replay_det_state和
sequence_state）,表示这些特性在一个特定的上下文上是否激活。
一个mech_type支持的预消息重发检测例子可以（当replay_det_state是TRUE时）实现
以下特性：底层机制可以通过GSS_GetMIC和GSS_Wrap来插入时间戳到输出的数据元素中，并
且维护（在一个时限窗口内）一个缓存（被发起者-接收者对限制）标志接收到的数据被
GSS_VerifyMIC和GSS_Unwrap处理过。当这些特性激活时，例外状态返回
（GSS_S_DUPLICATE_TOKEN和GSS_S_OLD_TOKEN）将被提供――当GSS_VerifyMIC和GSS_Unwrap
和消息一起出现时，用来检测重复的以前消息或者验证最近接收到的消息在缓存中是否过期。
1.2.4:保护质量
一些mech_types提供给他们的用户以很好的控制方式用来对pre-message进行保护。允许
调用者为特定消息的保护请求可选的动态安全保护。一个预消息保护质量参数（类似于服务质
量，或者QOS）在当前机制支持的不同的QOP中选择。在多QOP的mech_type的上下文建立时，
上下文级的数据提供多保护质量的前提数据。
普遍认为调用者中的多数不希望去直接的说明机制特定的QOP控制，而要求选择一个默认
的QOP。QOP值的定义、选择和非默认的值是机制相关的，并且不同的机制没有相同的QOP值序。
非默认QOP值的使用的意义要求调用者熟悉机制的QOP定义，和非可移植的结构。GSS_S_BAD_QOP
的major_state值被定义以标识一个给定的QOP值不被安全上下文支持，大多数是因为值不被
底层机制识别。
1.2.5:匿名支持
在有些环境中，一个应用程序希望认定对方并且/或者通过使用GSS-API的Pre-Message服
务来保护通讯，但却不暴露自己的标识。例如，考虑一个应用，他提供读访问一个科研数据库，
并且允许任意的请求者查询。这种服务的客户希望认证服务端，但是因为私人原因不希望把自
己的标识透漏给服务端。
在普通的GSS-API使用中，上下文发起者的标识作为上下文建立过程的一部分对于上下文
的接收者有效的。为了提供匿名支持，一个功能（输入anon_req_foag给
GSS_Init_sec_context()）被提供，通过他，上下文发起者可以要求他们的标识不提供给上下
文接收者。机制没有被要求有这个需求，但是调用者将被通知（通过从GSS_Init_sec_context()
返回的anon_state标识）这个要求是否可用。在匿名中，作为匿名原则不需要实现认证意味着
为了建立安全上下文的信任状不是必须的。
以下的对象标识符(OID)被提供表示匿名名字的方法，并且可以被用于比较，以用于检测在
机制独立的情况下，一个名字是否代表一个匿名用户：
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes), 
3(gss_anonymous_name)}
对应于这个定义的推荐的符号名是GSS_C_NT_ANONYMOUS
anon_state和mutual_state的四种可能的组合如下：
anon_state == FALSE, mutual_state == FALSE:发起者证明给目标
anon_state == FALSE, mutual_state == TRUE: 发起者证明给目标，目标证明给发起者
anon_state == TRUE, mutual_state == FALSE:发起者作为匿者证明给目标
anon_state == TRUE, mutual_state == TRUE: 发起者作为匿者证明给目标，目标证明给发起
者
1.2.6:初始化
GSS-API没有定义任何初始化调用（例如，在接口中，调用必须优先于其他调用）。这种情
况意味着，GSS-API实现必须能够自己自初始化。
1.2.7:上下文建立期间的预消息保护
当安全上下文的建立是在GSS_S_CONTINUE_NEEDED状态时，一个工具在GSS-V2中定义以保
护和缓存数据信息，以用于这种场合――调用方已经拥有处理过程需要的会话密钥。特别的，
一个新的布尔状态，叫prot_ready_state，被加入到GSS_Init_sec_context、
GSS_Accept_sec_context、GSS_Inquire_context返回的信息集中，
对于上下文建立调用，这个状态布尔值是有效的和可解释的，当相关的major_status是
GSS_S_CONTINUE_NEEDED或者是GSS_S_COMPLETE。GSS-API的调用者（发起者和接收者）可以
设想预消息保护（由GSS_Wrap，GSS_Unwrap，GSS_GetMIC，GSS_VerifyMIC）是可用的并且对
以下情况是准备好的：port_ready_state==TRUE或者major_status==GSS_S_COMPLETE，尽管在
GSS_S_COMPLETE返回前互相认证不能被保证。
这篇文档完全的、向后兼容的――对于GSS-API V1调用者，他们不需要知道port_ready_state
的存在，将从GSS_S_COMPLETE中获得需要的行为，但他们在GSS_S_COMPLETE返回前不能使用
预消息保护。
在完成上下文建立前，GSS_V2机制返回TRUE的port_ready_state不是必须要求的（事实上，
有些机制不能发展使用消息保护密钥，特别是上下文接收者，在上下文建立完成之前）。它是被
希望的，而不是必须的：在完成上下文建立基础之上，GSS-API V2机制将返回值为TRUE的
port_ready_state，如果他们支持预消息保护（事实上，GSS-V2应用程序不应该假设值为TRUE
的port_ready_state总是和GSS_S_COMPLETE的major_state一起返回，因为GSS-V2实现可能
继续支持GSS-V1机制代码，而GSS-V1永远不返回TRUE port_ready_state）
当port_ready_state返回TRUE时，机制将设置这些上下文服务标识标志（deleg_state，
mutual_state，replay_det_state，sequence_state，anon_state，trans_state，conf_avail，
integ_avail）代表工具的确定性，在那时，在上下文建立时变得可用。在port_ready_state
先于GSS_S_COMPLETE返回的情况下，在GSS_S_COMPLETE返回时，额外的功能被确认和随后表
示是可能的。
1.2.8:实现的强壮性
这节推荐一些GSS-API有利于健壮实现方面的行为。
在一个GSS-API安全上下文中，如果一个Token为了处理而被表示，并且对那个上下文，
此标识被检测为无效的，为了处理以后的有效的标识，上下文状态不能被中断。
在GSS-API实现中，一些本地条件被排除（例如，不可用的存储器），临时的或是永久的，
在GSS-API安全上下文标识的成功处理上，通常产生GSS_S_FAILURE 的major_status返回，
伴随着本地的 minor_status。在此条件下，为了强壮的操作，以下建议：
调用错误时应该释放任何他占用的资源，因此调用者可以再次调用，而不用担心失去更多
的资源。
在一个已建立的安全上下文上的一个单独调用的失败不应排除相同安全上下文的后续调
用。
在任何可能的时候，对于GSS_Delete_sec_context调用将成功处理，即使其他调用不能成
功执行，因此，上下文相关的资源可以被释放。
2:接口描述
这节描述GSS-API的服务接口，把提供的调用分为4组。信任状管理调用涉及主体获得和
释放信任状。上下文级调用涉及管理主体间的安全上下文。Per-message调用涉及在已建立的
安全上下文上保护单独的信息。支持调用为GSS-API的调用者提供一些辅助性的功能。表2以
表格的形式分类和总结了调用。
表 2:GSS-API调用
信任管理
GSS_Acquire_cred                                获得信用状以使用
GSS_Release_cred                                使用后释放信用状
GSS_Inquire_cred                                显示信用状的信息
GSS_Add_cred                                    增加性的构造信用状
GSS_Inquire_cred_by_mech                        显示指定机制的信用状信息
上下文级调用
GSS_Init_sec_context                            初始化输出安全上下文
GSS_Accept_sec_context                          接收输入的安全上下文
GSS_Delete_sec_context                          当上下文不需要时，删除上下文
GSS_Process_context_token                       处理接到的上下文令牌
上下文的控制Token
GSS_Context_time                                标识留在上下文上的有效时间
GSS_Inquire_context                             显示上下文的信息
GSS_Wrap_size_limit                             检查GSS_Wrap标识尺寸限制
GSS_Export_sec_context                          传递上下文到其他处理过程
GSS_Import_sec_context                          导入传递来的上下文
PER-MESSAGE调用
GSS_GetMIC                               应用完整性检查，作为从消息中分离的Token被
接收
GSS_VerifyMIC                            检查随同消息的Token的完整性
GSS_Wrap                                 签名，可选的加密，、封装
GSS_Unwrap                               拆封装，需要的解密，完整性检查
支持调用
GSS_Display_status                       转换状态编码到可打印的形式
GSS_Indicate_mechs                       显示本地系统支持的mech_type
GSS_Compare_name                         比较两个名字
GSS_Display_name                         转换名字到可打印的形式
GSS_Import_name                          转换可打印的名字到规格化的名字
GSS_Release_name                         释放存储的规格化形式的名字
GSS_Release_buffer                       释放可打印名字的存储0
GSS_Release_OID                          释放OID对象的存储
GSS_Release_OID_set                      释放OID集对象存储
GSS_Create_empty_OID_set                 创建空的OID集
GSS_Add_OID_set_member                   加成员到OID集中
GSS_Text_OID_set_member                  测试OID是否是OID集中的成员
GSS_OID_to_str                           显示OID为字符串
GSS_str_to_OID                           从字符串中构造OID
GSS_Inquire_names_for_mech               显示机制支持的名字类型
GSS_Inquire_mechs_for_name               显示支持名字类型的机制
GSS_Canonicalize_name                    转换名字到指定机制形式
GSS_Export_name                          输出指定机制名字
GSS_Duplicate_name                       复制名字对象
2.1:信任状管理调用
这些GSS-API调用提供信任状管理的相关功能。在和其网络实体（目录或者认证服务器）
交换信息时是否挂起的这些特点部分依赖于操作系统说明（在GSS-API范围之外的），所以在这
个文档中没有说明。
在GSS-API中定义的GSS_Acquire_cred()调用支持应用程序的可移植性，一个特殊的是面
向于支持服务器应用程序的可移植性。一般认为（对于一般的系统和机制）为了服务端的处理
进程，用于用户交互的信任状可以从不同的信任状中被管理；在那种环境中，GSS-API的实现
者有责任区分这些情况，并且这些区分过程是本地问题。GSS_Release_cred()调用为调用者提
供了一种手段标识GSS-API不用再要求使用信任状。GSS_Inquire_cred()调用允许调用者判定
信任状结构的信息。GSS_Add_cred()调用允许调用者加入元素到一个已存在的信用状结构中，
允许多机制信任状的重复构造。GSS_Inquire_cred_by_mech调用允许调用者获得特定机制描述
信任的信息状。
2.1.1:GSS_Acquire_cred
输入：
desired_name INTERNAL NAME, -NULL 需要本地确认的默认值
lifetime_req INTEGER, 按秒记；0要求默认
desired_mechs SET OF OBJECT IDENTIFIER, 空集合需要系统默认选择
cred_usage INTEGER 0代表INITIATE-AND-ACCEPT， 1代表INITIATE-ONLY， 2代表ACCEPT-ONLY
输出；
major_status INTEGER
minor_status INTEGER
output_cred_handle CREDENTIAL HANDLE
actual_mechs SET OF OBJECT IDENTIFIER
lifetime_rec INTEGER 按秒记，或者是保留值INDEFINITE
返回major_status编码：
GSS_S_COMPLETE表示要求的信任被成功的建立，在lifetime_rec表示的期间中，和在
cred_usage中要求的使用相适应。适用于在actual_mechs中表示mech_types集，这些信任可
以被以后的使用引用――通过output_cred_handle中的值。
GSS_S_BAD_MECH表示当前GSS-API实现不支持的mech_type被要求，导致信任建立操作失败。
GSS_S_BAD_NAMETYPE表示提供的desired_name是不可解释的，或者是一种不被底层GSS-API
机制支持的类型，所以没有信任可以被建立――陪伴desired_name
GSS_BAD_NAME表示提供的desired_name和术语（内部组成类型说明信息）不一致，所以没有
信任可以被建立――陪伴desired_name
GSS_S_FAILURE表示信任建立过程失败――因为GSS-API级未说明的原因，包括缺乏建立和使
用信任的认证，和相关的在输入参数desired_name中的标识名字。
2.1.2:GSS_Release_cred_call
输入：
cred_handle CREDENTIAL HANDLE