rfc2078.txt

很多RFC的中文文档

一个新的布尔状态，叫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 – NULL说明当默认的信任行为被要求释放时，信任元素被
使用
输出：
major_status INTEGER
minor_status INTEGER
返回major_status编码
GSS_S_COMPLETE表示被输入cred_handle引用的信任被调用者释放——为了后续者访问的目
的。其他被认证的处理过程共享的访问信用效率是一个本地问题。
GSS_S_NO_CRED表示没有任何释放动作被执行，可能是因为输入的cred_handle无效或者因为
调用者缺乏认证来访问引用的信任。
GSS_S_FAILURE表示释放操作由于GSS-API级未说明的原因失败
为调用者提供一钟方法以明确的要求释放信任，当他们的使用不在需要时。注意系统说明的信
用管理功能也可能存在，例如为保证进程间共享的信用被正确的删除——当相关进程都结束时，
尽管没有没有明显的释放请求被这些进程发出。假设这种情况：多个调用者没有被排除获得对
同一个信任具有访问的权限，调用GSS_Release_cred不能被假定删除一个特定的信任集——基
于系统基础上
2.1.3:GSS_Inquire_cred调用
输入：
cred_handle CREDENTIAL HANDLE – NULL说明信任元素——当默认的信任行为被要求——被
使用的查询
输出：
major_status INTEGER
minor_status INTEGER
cred_name INTERNAL NAME
lifetime_rec INTEGER 按秒记，或者保留值INDEFINITE
cred_usage INTEGER, 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, 2=ACCEPT-ONLY
mech_set SET OF OBJECT IDENTIFIER
返回的major_status编码：
GSS_S_COMPLETE表示被输入参数cred_handle引用的信用是有效的，并且输出cred_name，
lifetime_rec，cred_usage值代表，分别的，信任相关的宿主名称，保持的生命时间，适当的
使用模块，和支持的机制类型。
GSS_NO_CRED表示没有任何关于引用信用的信息能被返回，或者是因为输入的cred_handle无
效，或者因为调用者缺少访问引用信任的认证。
GSS_S_DEFECTIVE_CREDENTIAL表示引用的信用无效
GSS_S_CREDENTIAL_EXPIRED表示引用的信用已经过期
GSS_S_FAILURE表示因为GSS-API没有说明的原因的操作失败
GSS_Inquire_cred调用被定义主要用来这些调用者的使用——要求使用默认的信任行为而不是
通过使用GSS_Acquire_cred调用显示的获得信用。他可以使调用者判断信任结构的关联宿主名
字，保留的有效期，安全上下文开始的可用性或者可接受和支持的机制。
对一个多机制的信用，返回的“lifetime”说明符表示最短的生命期——在信任中的所有的机
制元素（为了上下文开始或者接收的目的）
GSS_Inquire_cred应该为"cred_usage"表示INITIATE-AND-ACCEPT——如果有以下两个条
件：
（1）在信任中存在一个元素——允许上下文开始使用一些机制
（2）在信任中存在一个元素——允许上下文接收一些机制（允许的，但不是必须的，限定一些
机制和（1）相同）
如果满足条件（1），但不满足（2），GSS_Inquire_cred 应该标识cred_usage为INITIATE-ONLY。
如果满足条件（2），但不满足（1），GSS_Inquire_cred 应该标识cred_usage为ACCEPT-ONLY。
调用者要求能很好的消除二意性——在可用的联合间（生命期，使用模式，机制应该调用的
GSS_Inquire_cred_by_mech例程——传给那个例程一个mech OID——GSS_Inquire_cred返回）
2.1.4:GSS_Add_cred 调用
输入：
input_cred_handle CREDENTIAL HANDLE – 掌握信任结构——由GSS_Acquire_cred或者
GSS_Add_cred调用创建，或者NULL加入元素到集合中——调用者应用——当默认的信任行为