rfc2025.txt

很多RFC的中文文档

		如果int-alg指定sum64-DES-CBC，则conf-alg必须为DES-CBC（如保密性必须被
应用请求或SPKM返回一个错误）。加密和完整性使用DES-CBC子密钥进行单向处理，
具体如下。先计算明码数据块的和（以2**64-1为模）。这个8字节的值被附在
“confounded”数据和1-8个填塞数之后（见KRB5关于DES-CBC的填塞数的定义）。
如上，CBC加密的结果被放在Wrap-body的数据段中。密文的最后一块被放在Wrap-body
的int-cksum字段中。

3．2．2．3 序列号

		序列号在函数gss-wrap（）中计算并处理，具体处理与3.2.1.2和3.2.1.3处理一致。

3．2．2．4 数据加密
		
	具体处理如下，除了（a）conf-alg是空（不加密）；或（b）conf-alg是DES-CBC
且int-alg是md5-DES-CBC（加密处理3.2.2.2）；或（c）int-alg是sum64-DES-CBC（加
密处理见3.2.2.2）。

	“被搀杂的”数通过conf-alg指定的算法进行填塞和加密处理。数据使用IV值为
零的CBC加密。 所使用的密钥是来自context密钥的子密钥，该密钥由2.4节介绍的
子密钥产生算法建立（这确保用于加密的子密钥和用于完整性的子密钥 — 如
DES-MAC而不是sum64-DES-CBC – 是不同的子密钥）
3．2．3 Context删除令牌
	该令牌通过gss_delete_sec_context（）产生，其格式与gss_sign（）/gss_getMIC（）
所产生的令牌格式一致。

	SPMK-DEL令牌定义如下：

   SPKM-DEL ::= SEQUENCE {
           del-header       Del-Header,
           int-cksum        BIT STRING
                                -- 令牌头的Checksum
                                -- 通过int-alg字段指定的算法计算
   }

   Del-Header ::= SEQUENCE {
           tok-id           INTEGER (769),
                                -- 必须包含0301 (hex)
           context-id       Random-Integer,
           int-alg [0]      AlgorithmIdentifier OPTIONAL,
                                -- 完整性算法标识
                                -- （必须是经协商的完整性算法中的一个）
                                -- 字段不存在 = 默认的 id
           snd-seq [1]      SeqNum OPTIONAL
                                -- 序列号字段
   }
	
	snd-seq字段的计算与通过gss_sign() / gss_getMIC()计算一样。int-cksum字段计算
与采用gss_sign() / gss_getMIC()一样，但user-data和checksum字段长度为零。 

	如果接收到一个有效的删除令牌，则目的方应该删除context，
gss-process-context-token（）返回主状态码GSS_S_COMPLETE，和一个辅助状态码
GSS_SPKM_S_SG_CONTEXT_DELETED。如果，删除令牌是无效的，则context将不
被删除，gss-process-context-token（）返回相应的主状态码（如GSS_S_BAD_SIG）和
一个辅助状态码GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD，此时应用可以通
过某些操作去检查context的状态（如发送一个sealed/wrapped的测试消息，并等待一
个sealed/wrapped的响应）。

4．名字类型和对象标识（Name Types and Object Identifiers）
		SPKM没有专门定义名字格式。这部分用于以后的研究。
4．1 可选的名字格式
	这部分讨论的被SPKM GSS-API可选支持的名字格式。注意到，可能存在一些
GSS-API之外的，与特定的操作系统相关的函数来对这些格式进行解释，而支持这些格
式的GSS-API位于这些函数之上。GSS-API对它们的支持主要是为了应用的方便。

4．1．1 用户名格式
		用户名格式对应的对象标识为（OID）为{iso(1) member-body(2) United States(840) 
mit(113554) infosys(1) gssapi(2) generic(1) user_name(1)}。这种类型推荐的符号名为
“GSS_SPKM_NT_USER_NAME”。

		这种名字类型用于描述一个本地系统的已命名的用户。对它的解释与特定的操作系
统相关。其格式被构造为：
		username

4．1．2 机器UID格式
		机器UID格式对应的对象标识为{iso(1) member-body(2) United States(840) 
mit(113554) infosys(1) gssapi(2) generic(1) machine_uid_name(2)}。其推荐的符号名为
“GSS_SPKM_NT_MACHINE_UID_NAME”。
		
		这种类型用于描述与一个本地系统用户相对应的数字用户标识。对它的解释与操作
系统相关的。代表这种类型名字的gss_buffer_desc必须包含一个本地很重要的
（locally-significant）uid_t字段，该字段表示主机字节序。The gss_import_name()操作
将uid解释为一个基于用户命名格式的username。
4．1．3 串UID格式
		串UID格式对应的对象标识为{iso(1) member-body(2) United States(840) mit(113554) 
infosys(1) gssapi(2) generic(1) string_uid_name(3)}。其推荐的符号名为
“GSS_SPKM_NT_STRING_UID_NAME”。
	
		这种类型用于描述代表一个本地系统用户的数字标识的数字串。对它的解释与操作
系统相关的。该类型类似机器UID格式，除了buffer包含一个串用来表示uid-t。
5．参数定义
	这部分定义定义SPKM GSS-API所使用的参数。它定义了为支持可移植性的所需
的基本接口。
5．1 辅助状态码
	这部分建议了minor_status通常的符号名，该符号是SPKM GSS-API的返回值。该
定义能够增强所规定的SPKM机制的不同的实现方间的可移植性（在任何情况下，
gss_display_status()能够使调用者将minor_status标识转换为文本表示）。每个机制的实
现都必须通过文件或其它方法，将这些符号名转换为具体的值，该值被一个特别的
GSS-API实现用来表示minor-status。应该承认，这个对应列表可以随着时间增长，对
于特定的GSS-API实现，所需的额外的minor_status码的定义也将增加。
5．1．1 Non-SPKM-specific状态码（Minor Status Code MSB, bit 31, SET）
5．1．1．1 GSS-Related状态码（Minor Status Code bit 30 SET）

   GSS_S_G_VALIDATE_FAILED
       /* "有效的错误" */
   GSS_S_G_BUFFER_ALLOC
       /* "不能分配gss_buffer_t数据" */
   GSS_S_G_BAD_MSG_CTX
       /* "消息context无效" */
   GSS_S_G_WRONG_SIZE
       /* "缓冲区大小错误" */
   GSS_S_G_BAD_USAGE
       /* "信任状使用类型不清楚" */
   GSS_S_G_UNAVAIL_QOP
/* "指定无效的保护品质（QOP）" */

5．1．1．2 Implementation-Related状态码（Minor Status Code bit 30 OFF）

   GSS_S_G_MEMORY_ALLOC
       /* "不能执行内存分配请求" */
5．1．2 SPKM-specific-codes状态码（Minor Status Code MSB, bit 31, OFF）
   GSS_SPKM_S_SG_CONTEXT_ESTABLISHED
       /* "context已经建立" */
   GSS_SPKM_S_SG_BAD_INT_ALG_TYPE
       /* "令牌中有不知道的完整性算法类型" */
   GSS_SPKM_S_SG_BAD_CONF_ALG_TYPE
       /* "令牌中有不知道的保密性算法类型" */
   GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE
       /* "令牌中有不知道的密钥建立算法类型" */
   GSS_SPKM_S_SG_CTX_INCOMPLETE
       /* "尝试使用不完全安全的context" */
   GSS_SPKM_S_SG_BAD_INT_ALG_SET
       /* "所提供的算法集中没有公共的完整性算法" */
   GSS_SPKM_S_SG_BAD_CONF_ALG_SET
       /* "所提供的算法集中没有公共的保密性算法" */
   GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET
       /* "所提供的算法集中没有公共的密钥建立算法" */
   GSS_SPKM_S_SG_NO_PVNO_IN_COMMON
       /* "没有公共的协议版本" */
   GSS_SPKM_S_SG_INVALID_TOKEN_DATA
       /* "数据格式不完全：不能被编码成令牌" */
   GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT
       /* "接收到的令牌格式不完全：不能被解码" */
   GSS_SPKM_S_SG_CONTEXT_DELETED
       /* "将对端请求的Context删除" */
   GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD
       /* "收到无效的删除令牌 – context没有删除" */
   GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT
      /* "不可恢复的令牌建立错误。Context删除" */
5．2 保护品质（Quality of Protection Value）
	保护品质（QOP）参数在SPKM GSS-API中作为gss_sign()和gss_seal() 
（gss_getMIC() 和gss_wrap()）的输入，在可选的算法集中去选择保密性和完整性算法。
一旦这套算法集在发起方和目的方达成一致，QOP参数只是简单在这套算法集中选择。

	具体的说，SPKM-REQ令牌发送一个发起方所支持的表示完整性的算法标识序列
和表示保密性的算法标识序列。目的方通过SPKM-REP-TI令牌返回该算法序列的子集
（与发送的顺序一致）。因此，发起方和目的方彼此知道自己支持的算法，和双方共同
支持的算法（后者表示在context有效阶段所支持的算法）。综上所述，QOP参数具有
这些的信息的含义。例如，一个应用可以请求数字3的完整性算法。如果该算法在context
建立过程中被支持，则它被使用，否则返回GSS_S_FAILURE，和一个适当的辅助状态
码。
		
	如果SPKM-REP-TI令牌没被使用（SPKM-2中的单向认证），则“一致”的算法标
识集简单的使用发起方的算法集（如果该算法集不被接受，目的方必须返回一个错误令
牌，表示context未被建立）。注意到，出于交互的考虑，发起方不需要提供其所支持的
所有算法；相反，它只提供必须的或推荐的SPKM算法，使得它们可能被目的方支持。

		QOP参数是一个32位的无符号整数（一个OM uint32），各位定义如下：

 保密性                           完整性
 31 (MSB)                         16 15                         (LSB) 0
------------------------------------|-----------------------------------
|  TS (5)  | U(3) | IA (4) | MA (4) |  TS (5)  | U(3) | IA (4) | MA(4) |
------------------------------------|-----------------------------------

   其中
		TS是一个五位的类型标识（定义用于保护令牌的算法类型 – 具体说明如下）；
	
		U是一个三位未定义的字段（用于扩充）

		IA是一个四位的字段，列举了具体执行的算法；

		MA是一个4位字段，列举所有定义的算法。

	    QOP参数的解释如下（注意对于保密性和完整性参数的处理过程是相同的）。首先
检查MA字段。如果非零，则用于保护令牌的算法就是该数值对应的算法。
	
	    如果MA为零，则检查IA字段。如果该字段为非零，则用于保护算法的令牌就是
与那个整数值相应的具体执行的算法（如果这个算法在令牌建立中有效）。注意到这个
字段的使用会影响可移植性，因为在一个实现中一个特别的值表示一个算法，而在另一
个实现中可能表示完全不同的另一个算法。

	    最后，如果MA和IA同为零，则检查TS。如果TS为零，表示使用默认的算法，
即发起方提供的算法列表的第一个算法（保密性和完整性依赖QOP的哪一部分被检
查），该算法必须被context建立的双方支持。如果TS非零，表示一个特定的算法限定
符，并采用支持该限定符的第一个算法。

	    以下是部分TS值（算法限定符）；其它值将在以后增加。

	    关于保密性算法TS字段：
 
         00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG
         00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM
         00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK

	   关于完整性算法TS字段：

         00001 (1) = SPKM_INT_ALG_NON_REP_SUPPORT
         00010 (2) = SPKM_INT_ALG_REPUDIABLE

	
	   很明显，限定符象高强度，中等强度，弱强度的定义是有争议的，而且可能随着时
间改变，但对于目前这版的规范，我们定义这些术语如下。如果一个保密性算法的有效
密钥长度小于40位，称为“弱强度”；如果在40至80位之间，成为“中等强度”，如
果大于80位，成为“高强度”。（注意，“有效密钥长度”描述了采用公共的密码攻击去
破解一个密码所需的计算量）。

	   对每个保密性算法和完整性算法而言，一个五位的TS字段允许最多31个限定符
（“0”保留为默认的值）。本文定义了三个用于保密性算法，两个用于完整性算法，其
余的用于未来的扩充。对描述符提出了如“快速”，“中速”，“慢速”等建议，但这些术
语很难量化（与平台和处理器相关），所以不在最初的规范之内。其主要意图是说明TS
术语应该是尽可能量化的，独立与环境的限定符。
 
	   上述定义的QOP结构的用法的含义如下：
	
	   -TS值在GSS-API层上定义，因此在不同的实现间是可移植。对算法不清楚的应用
模块也能选择保护“品质”去保护其消息令牌。

	   -MA值在机制的层上定义，因此在一个机制的不同实现间是可移植的。例如Kerberos 
V5 GSS机制的所有实现必须支持

         GSS_KRB5_INTEG_C_QOP_MD5     (value: 1)
         GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
         GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3)。

	（注意到Kerberos相关的QOP值并不与上文定义的QOP结构冲突）

	   -IA值定义在实现层上（例如在用户文档中），因此通常不可移植。一个知道自己执
行模式和对端执行模式的应用可以自由使用这些值，因为它们在context中和双方间都
是有效的。

	   令牌的目的方必须返回调用者一个包含所有相关域字段集的QOP参数。例如，如果
triple-DES被定义为算法8，则triple-DES-protected令牌的目的方必须将其传递给应用
（QOP保密性TS=1，IA=0，MA=8）。在这种情况下，应用可以随意读取其所理解的
QOP各部分（TS or IA/MA）。

	   为了帮助实现和互操作性，作了如下约定。发送方发送的完整性算法ID集必须至
少包含一个计算数字签名的算法，该算法支持抗抵赖性，必须至少包含任意一个其它类
（可抵赖的）的完整性算法。目的方返回的算法子集也必须包含至少一个抗抵赖的签名