rfc2078.txt

RFC规范的翻译稿

上下文发起或者接收的默认的信任状元素。另一方面，需要对特定的信任状结构做出明显的选
定的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     <---------------------