rfc2078.txt

很多RFC的中文文档

    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中定义以保
护和缓存数据信息，以用于这种场合——调用方已经拥有处理过程需要的会话密钥。特别的，