rfc2025.txt

很多RFC的中文文档

   REP-TI-TOKEN ::= SEQUENCE {
           rep-ti-contents Rep-ti-contents,
           algId           AlgorithmIdentifier,
           rep-ti-integ    Integrity  -- "token" 是Rep-ti-contents
   }

   Rep-ti-contents ::= SEQUENCE {
           tok-id           INTEGER (512),   -- 必须包含 0200 (hex)
           context-id       Random-Integer,  -- 见6.3
           pvno [0]         BIT STRING OPTIONAL, -- 协议版本号
           timestamp        UTCTime OPTIONAL, -- 对SPKM-2必须的
           randTarg         Random-Integer,
           src-name [1]     Name OPTIONAL,
             -- 在REQ-TOKEN中必须被包含
           targ-name        Name,
           randSrc          Random-Integer,
           rep-data         Context-Data,
           validity [2]     Validity  OPTIONAL,
             -- 密钥的validity间
-- （存在如果目的只能支持比REQ-TOKEN所提出的时间间隔更短的context）
           key-estb-id      AlgorithmIdentifier OPTIONAL,
             -- 用于当目的方改变密钥建立算法
             -- （必须是发起方key-estb-set的一个成员）
           key-estb-str      BIT STRING OPTIONAL
             -- 包含 （1）发起方key-estb-req的响应 （如果发起方采用2-pass K-ALG）   
             -- （2）与key-estb-id中所支持的K-ALG相一致的key-estb-req
             -- （3）与发起方key-estb-id所支持的第一个K-ALG相一致的key-estb-req，
             -- 如果发起方的key-estb-req（可选的）不被使用（在这种情况下目的方的
key-estb-str必须存在）。
             -- 被建立的密钥必须满足2.4规定的密钥长度限制。
           }

协议的版本（pvno）参数是一个BIT STRING，它使用足够的位去定义发起方提出
而被目的方支持的协议版本（每位表示一个协议版本）；也就是说，目的方设置确切的
pvno的某一位。如果目的方不支持所有的版本，则返回一个删除令牌表示连接不被建
立。如果发起方的pvno只有一位，而且目的方恰巧支持，则该版本被使用，但
REP-TOKEN的参数被忽略。最后，如果发起方和目的方有一个或多个相同的版本，但
是REQ-TOKEN并不被目的方支持，则REP-TOKEN必须设置一个合适的pvno位（用
于后续令牌的哑元值字段）。发送方必须响应一个带有合适版本的新的REQ-TOKEN（本
质上是建立一个新的连接）

3．1．3 Context建立令牌 – 发起方（第二个令牌）
	相关的SPKM-REP-IT语法如下：

   SPKM-REP-IT ::= SEQUENCE {
           responseToken    REP-IT-TOKEN,
           algId            AlgorithmIdentifier,
           rep-it-integ     Integrity  -- "token" 是 REP-IT-TOKEN
   }

   REP-IT-TOKEN ::= SEQUENCE {
           tok-id           INTEGER (768), -- 必须包含0300 (hex)
           context-id       Random-Integer,
           randSrc          Random-Integer,
           randTarg         Random-Integer,
           targ-name        Name,  -- targ-name在REP-TI中指定
           src-name         Name OPTIONAL,
             -- 在REQ-TOKEN中必须包含
           key-estb-rep     BIT STRING OPTIONAL
                 -- 包含目的方key-estb-str的响应
                 -- （如果目的选择2-pass K-ALG）
           }
3．1．4 错误令牌
	SPKM-ERROR令牌如下：

   SPKM-ERROR ::= SEQUENCE {
           error-token      ERROR-TOKEN,
           algId            AlgorithmIdentifier,
           integrity        Integrity  -- "token"是ERROR-TOKEN
   }

   ERROR-TOKRN ::=   SEQUENCE {
           tok-id           INTEGER (1024), -- 必须包含0400 (hex)
           context-id       Random-Integer
           }

	SPKM-ERROR令牌仅用于context建立过程。如果接收SPKM-REQ或
SPKM-REP-TI令牌错误，则接收函数（gss-init-sec-context（）或gss-accept-sec-context
（））将产生一个SPKM-ERROR令牌发送给对端（如果对端处于等待请求响应的状态），
并返回GSS_S_CONTINUE_NEEDED。另一方面，如果对端不需要等待请求响应（如
对端已经完成context建立），则该函数返回适当的主状态码（如GSS_S_BAD_SIG），
并伴随着辅助状态为GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT，并删除所有与
context相关的信息。输出的令牌将不是SPKM-ERROR令牌，而是SPKM-DEL令牌，
该令牌被对端的gss-process-context-token（）所使用。
	
	如果gss-init-sec-context（）接收一个错误的令牌（无论是否为有效的令牌），它将
重新产生SPKM-REQ作为输出令牌，并返回主状态码GSS_S_CONTINUE_NEEDED。
（注意如果gss-accept-sec-context（）在希望接收SPKM-REP-IT令牌时，接收到
SPKM-REQ令牌，它将忽略SPKM-REQ，并返回一个零长度的输出令牌，和一个主状
态码GSS_S_CONTINUE_NEEDED。）

	类似的，如果gss-accept-sec-context（）接收到一个错误令牌（无论是否有效令牌），
它将重新产生SPKM-REP-TI作为起输出令牌，并返回主状态码
GSS_S_CONTINUE_NEEDED。

	md5WithRsa是目前指定的对context建立令牌进行签名的算法。通过适当的使用
SPKM-ERROR令牌可以解决位长系数的差异。Context发起方使用其所支持的最强的
RSA（如1024位）对REQ-TOKEN进行签名。如果目的方不能验证，它将传送一个
SPKM-ERROR令牌，该令牌用其所支持的最大长度的RSA（如512位）进行签名。

	由于签名算法的长度等于签名模块的长度，因此在交换完成后，双方都知道对端所
支持的RSA长度。接下来将继续进行交换（使用连续稍短的算法），直到达成一致或因
无法达成一致而导致context建立失败。
3．2 消息（Per-message）和Context删除令牌   
	本节定义了三类令牌：“MIC”令牌，通过gss-getMIC（）产生，通过gss-verigyMIC
（）处理；“Wrap”令牌，通过gss-wrap（）产生，通过gss-unwrap（）处理；删除令
牌，通过gss-init-sec-context（），gss-accept-sec-context（）或gss-delete-sec-context（）
产生，通过gss-process-context-token（）处理。
3．2．1 消息令牌（Per-message ）-Sign/MIC
使用gss-sign（）/gss-getMIC（）调用产生一个令牌，它与被保护的数据分开， 该
令牌用于验证所接收的数据的完整性。令牌和数据可以被应用分别发送，目的方应用负
责将令牌和数据进行关联。
SPKM-MIC令牌的格式如下：


   SPKM-MIC ::= SEQUENCE {
           mic-header       Mic-Header,
           int-cksum        BIT STRING
                                -- 头和数据的校验和（ckecksum），
                                -- 通过int-alg子段指定的算法计算
   }

   Mic-Header ::= SEQUENCE {
           tok-id           INTEGER (257),
                                -- 必须包含 0101 (hex)
           context-id       Random-Integer,
           int-alg [0]      AlgorithmIdentifier OPTIONAL,
                                -- 完整性算法标识
                                -- （必须是context中所协商的完整性算法中的一个）
                                -- 字段不存在 = 默认的id
           snd-seq [1]      SeqNum OPTIONAL  --序列号
   }

   SeqNum ::= SEQUENCE {
           num      INTEGER, -- 序列号自身
           dir-ind  BOOLEAN  -- 方向标识
   }


3.2.1.1. 校验和（Checksum）

	Checksum计算过程（对所有的算法都一样---注意对于SPKM，术语“checksum”
包含数字签名，也包含哈希和MAC）：Checksum计算整个数据段，该数据段逻辑上通
过明文的令牌头（mic-header）的字节决定。最后结果将整个明文头和计算的数据绑定
在一起，以最小化数据被恶意修改的可能性。

	例如，如果int-alg算法指定为md5WithRSA，那么checksum通过计算明文（通过
令牌头事先设置）的MD5[RFC-1321]哈希值，再对16个字节的MD5结果进行RSA签
名[PKCS1]实现。签名通过来自信任状的RSA私钥计算，其结果（它的长度隐含在私
钥的“modulus”参数中）被储存在int-cksum字段中

	如果int-alg指定为基于对称密钥的哈希算法（如DES-MAC或md5-DES-CBC），
则密钥是来自于context密钥的子密钥（见2. 4）。同样，其结果（它的长度由int-alg决
定）被储存在int-cksum字段中。

3．2．1．2 序列号
	
	假定在传输层以下的协议（无论是什么协议栈）提供保证通信足够的可靠性（不存
在数据包的恶意的丢失，顺序颠倒，数据包被正确处理）。因此，在SPKM中使用序列
号只用于安全，而不是通信的可靠（即，避免SPKM令牌恶意的丢失，重发，循序重
排）。-- 因此它被推荐用于context建立中的顺序和重发检测。注意到序列号用于消息
令牌中不使用时间戳的情况下。发起方的初始序列号放在SPKM-REQ的Context-Data
字段，目的方的初始序列号放在SPKM-REP-TI的Context-Data字段；如果任一方没有
设置该值，则默认为00。

	序列号字段：序列号字段通过发送方的四字节序列号和一个布尔型的方向标识
（FALSE- 发送方是context初始方，TRUE – 发送方是context的目的方）。在构造一
个gss-sign/getMIC（）或gss-seal/wrap（）令牌后，发送方的序列号增加一。

 3．2．1．3 序列号处理过程
	
	令牌的接收者通过比较收到的序列号值和期望的序列号值，收到的方向标识值和期
望的方向标识值，来验证序列号字段。如果序列号值大于期望值，则期望的序列号值被
调整，并返回GSS_S_GAP_TOKEN。如果序列号值小于期望值，则期望值不被调整，
并根据情况返回GSS_S_DUPLICATE_TOKEN,，GSS_S_UNSEQ_TOKEN,，或
GSS_S_OLD_TOKEN令牌。如果方向标识值错误，则期望的序列号值不被调整，返回
GSS_S_UNSEQ_TOKEN令牌

	既然序列号值只是输入中用于完整性checksum的的一部分，所以序列号值不需要
加密，并且将不同消息中的checksum和序列号值衔接的作法能够被检测出来。方向标
识可以检测被目的方恶意转发回来的令牌。

3．2．2 消息令牌（Per-message）–  Seal/Wrap
	
	使用gss-seal（）/gss-warp（）能够产生一个封装了用户数据（可以被加密）的令牌。
这个令牌通过gss-seal（）/gss-warp（）产生，包含一个完整性的数据头，紧跟着数据体，
数据体可以是纯明文（conf-alg = NULL），或加密的数据（使用合适的子密钥，见2.4关
于context的C-ALG协商部分）

	SPKM-WRAP令牌有如下格式：

   SPKM-WRAP ::= SEQUENCE {
           wrap-header       Wrap-Header,
           wrap-body         Wrap-Body
   }

   Wrap-Header ::= SEQUENCE {
           tok-id           INTEGER (513),
                                -- 必须包含 0201 (hex)
           context-id       Random-Integer,
           int-alg [0]      AlgorithmIdentifier OPTIONAL,
                                -- 完整性算法标识(必须是context中经协商的完整性
算法中的一个)
                               -- 字段不存在 = 默认的id
           conf-alg [1]     Conf-Alg OPTIONAL,
                                -- 保密性算法标识
                                -- (必须为空或者一个协商的保密性算法)
                                -- 字段不存在 = 默认的id
                                -- NULL = none (没有申请保密性算法)           
snd-seq [2]      SeqNum OPTIONAL
                                -- 序列号
   }



   Wrap-Body ::= SEQUENCE {
           int-cksum        BIT STRING,
                                -- 头和数据的Checksum ,
                                -- 通过int-alg字段指定的算法计算
           data             BIT STRING
                                -- 被加密的或纯明文数据
   }

   Conf-Alg ::= CHOICE {
           algId [0]        AlgorithmIdentifier,
           null [1]         NULL
   }


3．2．2．1 搀杂（Confounding）

	正如[KRB5]所述，在IV值为零时，一个8字节随机搀杂数被产生作为加密密钥的
一部分。该数据被放在“confounded”数据段中。

3．2．2．2 检验和（checksum）

	checksum计算过程（对所有的算法一致）：Checksum计算明码数据段，该数据段
逻辑上通过明文的令牌头（wrap-header）字节数决定。通过gss-sign（）/gss-getMIC（）
处理，结果将整个明文头和数据绑定在一起，以最小化数据被恶意修改的可能性。

		关于md5WithRSA和DES-MAC的例子见3.2.1.1。
	
	如果int-alg定义为md5-DES-CBC，conf-alg定义为除DES-CBC外的算法，则
checksum计算通过3.2.1.1，并将结果保存在int-cksum中。如果conf-alg定义为
DES-CBC，则加密和完整性检测将按照如下处理。计算密码数据的MD5[见RFC-1321]
哈希值。这16个字节附在“confounded”字段后面和1-8个字节的填塞数后面（填塞
数定义见KRB5）。将这个结果用DES-CBC子密钥（见2.4）进行CBC加密，并将结果
放在Wrap-Body的数据段中。密文最后两块（如经过加密的MD5哈希值）作为完整性
checksum也被放在Wrap-Body的int-cksum字段中。