rfc2078.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者： Jessie（zhenm2000  [e-mail]）
译文发布时间：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的双方建立安全上下文的先决条件。调用者可以指定用于