rfc2025.txt

很多RFC的中文文档

过算法集第一个算法产生的密钥（或一部分）。如果K-ALG不被接受，则目的方选择
另一种K-ALG算法，并返回该K-ALG算法和与之相关的密钥或密钥一部分（否则，
发送一个删除令牌，表示建立不成功）。如果必须的话（目的方选择2-pass K-ALG如
dhKeyAgreement），发送方将继续发送它的密钥。

	最后，在第一个context建立令牌中，发起方提供一套可能的O-ALG算法（如果
不需要响应，只有一种O-ALG算法）。该O-ALG（一个）算法被目的方接受，形成用
于context子密钥产生算法的OWF。

	在以后的SPKM版本中，其他算法也可能被指定。
3．令牌格式
	本节讨论SPKM协议上可见的特性；它定义了协议交互的基本元素，并且与程序
设计语言无关（见RFC-1509）。
SPKM GSS-API机制通过一个目标标识（OID）表示“SPKM-1”或“SPKM-2”，
即{spkm spkm-1(1)}或 {spkm spkm-2(2)}，其中spkm为{iso(1) identified-organization(3) 
dod(6) internet(1) security(5) mechanisms(5) spkm(1)}。在context建立过程中，SPKM-1
用户使用随机数进行重放（replay）检查，SPKM-2使用时间戳（如果应用需要，两种
机制都使用序列号进行replay和out-of-sequence检查）。
	
	GSS-API应用的双方（为安全context管理和信息保护目的）传递的令牌定义如下。
3．1 Context建立令牌
	本节定义三类令牌：“发起方”令牌，由gss-init-sec-context（）发送，由
gss-accept-sec-context（）接收；“目的方”令牌，由gss_accept_sec_context（）发送，
由gss-init-sec-context（）接收；“错误”令牌，发送和接收内含于gss-init-sec-context（）
和gss_accept_sec_context（）中。

	
	RFC-1508的附录B中，附加了如下的最初的context建立令牌：

   InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
           thisMech           MechType,
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "SPKM-1" or "SPKM-2"
           innerContextToken  ANY DEFINED BY thisMech
   }               -- contents mechanism-specific

		当thisMech是SPKM-1或SPKM-2，innerContextToken定义如下：

      SPKMInnerContextToken ::= CHOICE {
         req    [0] SPKM-REQ,
         rep-ti [1] SPKM-REP-TI,
         rep-it [2] SPKM-REP-IT,
         error  [3] SPKM-ERROR,
         mic    [4] SPKM-MIC,
         wrap   [5] SPKM-WRAP,
         del    [6] SPKM-DEL
      }

	以上定义应该用于所有通过SPKM GSS-API机制产生的令牌，包括SPKM-REP-TI
（目的方对发起方的响应），SPKM-REP-IT（发起方对目的方的响应），SPKM-ERROR，
context-deletion，消息令牌（不是用于context建立的令牌）。SPKMInnerContextToken
的标记值定义了每一个令牌的token-id（用[0-6]表示）。类似信息被包含在令牌的tok-id
子段中。尽管看起来有些冗余，标记值和tok-id代表不同的含义：标记保证
InitialContextToken能被合适的解码；tok-id表示消息令牌的数据该令牌类型一致。 每
个innerContextToken也包含一个context-id字段，第6节将对token-id和context-id的
信息和使用进行详细讨论。
	
Context建立令牌的InnerContextToken字段包含如下信息之一：SPKM-REQ；
SPKM-REP-TI；SPKM-REP-IT；和SPKM-ERROR。此外，所有InnerContextToken都
采用ASN.1 BER编码（其简化版是DER编码，见X509 8.7）。

SPKM的context建立令牌通过X509的第10节定义，并与[9798]一致。在目的方
发起方进行单向认证时，SPKM-1（随机数）采用10.3定义的“双方认证”模式，当发
起方要求双向认证时，SPKM-1采用10.4定义的“三方认证”模式。而在接收放进行
单向认证是，SPKM-2（时间戳）采用10.2定义的“单方认证”模式，在目的方进行双
向认证时，采用10.3定义的“双方认证”模式。
		
	上文意味着当SPKM-2进行单向认证时，不需要进行K-ALG协商（目的方要么接
受发起方的K-ALG和context密钥，要么拒绝）。SPKM-2双向认证或SPKM-1的单向
认证可以进行协商，但目的方只能选择由发起方提供的单路（one-pass）的K-ALG（或
者拒绝请求）。作为选择，发起方能够请求目的方产生并传输context密钥。对SPKM-1
的双向认证，目的方能够选择任一one-或two-pass的K-ALG算法，并能够应发送方的
请求产生并发送context密钥。

	通常SPKM-1或SPKM-2都采用双向认证。因此，尽管两种机制都支持单向认证，
但在实际应用中并不普遍。
3．1．1 Context建立令牌 – 发起方令牌（第一个令牌）
	为了完成context建立，发起方和目的方必须能够存取其它实体的公钥证书。在某
种条件下，发起方可以采用先取得所有的证书，然后将相关的证书包含在在第一个令牌
中发到目的方。在另外的条件下，发送方可以要求目的方在其响应中包含证书数据，或
者两边各自得到其所需的证书数据。
	但在任一条件下，建立SPKM的双方必须有能力根据一个所支持的名字得到对应
证书。但具体实现机制不属于规范的范畴。

	相关的SPKM-REQ语法定义如下（附录A给出了其它文档的入口）

   SPKM-REQ ::= SEQUENCE {
           requestToken      REQ-TOKEN,
           certif-data [0]   CertificationData OPTIONAL,
           auth-data [1]     AuthorizationData OPTIONAL
              -- 关于auth-data的讨论见 [RFC-1510] 
   }

   CertificationData ::= SEQUENCE {
           certificationPath [0]          CertificationPath OPTIONAL,
           certificateRevocationList [1]  CertificateList OPTIONAL
   }  -- 必须至少有一个存在


   CertificationPath ::= SEQUENCE {
           userKeyId [0]         OCTET STRING OPTIONAL,
              -- 用户的公钥标识
           userCertif [1]        Certificate OPTIONAL,
              -- 包含用户公钥的证书
           verifKeyId [2]        OCTET STRING OPTIONAL,
              --用户的公开验证密钥标识
           userVerifCertif [3]   Certificate OPTIONAL,
              -- 包含用户公开验证密钥的证书
           theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
   }          -- 从目的到源的证书路径
		
	通过将验证字段分开使得不同的密钥对（基于不同的算法）用于不同功能，加密/解密，
签名/验证。当[0]或[1]存在，而[2]和[3]不存在的情况下，用同一对密钥对进行加密/解密，
签名/验证（但在实际应用中并不推荐使用）。如有[2]或[3]的情况下，另外不同的密钥对
进行加密/解密，签名/验证，因此[0]或[1]必须存在。如[4]存在，意味着[0]，[1]，[2]，[3]
必须有一个存在。

      REQ-TOKEN ::= SEQUENCE {
              req-contents     Req-contents,
              algId            AlgorithmIdentifier,
              req-integrity    Integrity  -- "token" is Req-contents
      }

      Integrity ::= BIT STRING
?	在algId 指定一个签名算法的情况下，"Integrity" 表示使用指定算法的签名结
果。具体将“token”的DER编码进行哈希变换后（算法也在algid中定义）的
BER编码值，进行加密处理。
?	在algid指定一个MACing算法的情况下，“Integrity”表示使用指定算法进行
MACing的结果。具体将“token”的DER编码结果进行MACing处理。（因此
对于该MAC而言，algId必须是一个完整性算法。）

可以想象，在典型应用，REQ-TOKEN，REP-TI-TOKEN，REP-IT-TOKEN的完整性字段
通常使用真正的数字签名，并且提供带重放（replay）检查的单向和双向认证。不过，在某
些条件下，仍使用MAC选项。如发起方希望匿名访问时（第一第三次令牌是MAC，第二
次令牌是签名的）。另一个例子在先前已经建立认证的情况下，带缓冲的context进行在一段
时间后重新建立（这里交换令牌是MACed）。

使用MAC主要好处在于在认证不是必须的情况下（如匿名），或认证已经以某种模式建
立的情况下（在context重新建立时，对一个新的令牌产生MAC），减少处理量。

   Req-contents ::= SEQUENCE {
           tok-id           INTEGER (256),    -- 必须包含 0100(hex)
           context-id       Random-Integer,   -- 见 6.3
           pvno             BIT STRING,       -- 协议版本号
           timestamp        UTCTime OPTIONAL, -- 对SPKM-2是必须的
           randSrc          Random-Integer,
           targ-name        Name,
           src-name [0]     Name OPTIONAL,
              --必须支持除非发起方是“匿名的”
           req-data         Context-Data,
           validity [1]     Validity OPTIONAL,
              -- 密钥的有效期（可以被用在安全context的生命期计算）
           key-estb-set     Key-Estb-Algs,
              -- 指定一套密钥建立算法
           key-estb-req      BIT STRING OPTIONAL,
              -- 与集合中第一个K-ALG的相对应的密钥建立参数
              -- (在如果发起方不能或无意产生和安全传送密钥到目的方的情况下不被使
用
            -- 被建立的密钥必须满足2.4规定的密钥长度限制
           key-src-bind      OCTET STRING OPTIONAL
              -- 用于绑定对称密钥的源名
              -- 在SPKM-2双向认证时，这个字段必须存在
              -- 如果被使用的K-ALG 不提供这个绑定
--（但对于所有其他的情况是可选的）
              -- 这个8进制串保持申请必须的哈希处理MD5的结果如下：              
              -- MD5(src || context_key),
              -- 其中“src”是src-name的DER编码
              -- "context-key"是对称密钥（如在key-estb-req中被传递的未保护的版本）
              -- "||"是连接操作
           }


?	协议的版本（pvno）参数是一个BIT STRING，它使用足够的位去定义发起方
支持的协议版本（每位表示一个协议版本）。
?	本文中协议是版本0。因此如果这个版本被支持的话，设置pvno的位0值。类
似的，如果版本1（未来的定义）被支持，位1被设置，如此类推。
?	对于SPKM-2的单向认证，在context的建立过程中，无响应令牌，因此没有
协议的协商。在这种情况下，发起者必须设置位0。而REQ-TOKEN的版本必
须设置pvno的最高位
?	“validity”参数是发起方唯一表示context生命期的字段。既然不能保证发起
方和目的方同时性，有效期的时间间隔可以当作确定的（不是确切的时间）。

   Random-Integer ::= BIT STRING

?	每个SPKM建立时，要求产生一个新的随机数；即，不大可能被先前操作使用
的值。该随机数不需要加密（它不需要不可预知的，只是需要是一个新的数）

   Context-Data ::= SEQUENCE {
           channelId       ChannelId OPTIONAL, -- channel绑定
           seq-number      INTEGER OPTIONAL,   -- 序列号
           options         Options,
           conf-alg        Conf-Algs,          -- 保密性算法
           intg-alg        Intg-Algs,          -- 完整性算法
           owf-alg         OWF-Algs            -- 为子密钥产生
   }

   ChannelId ::= OCTET STRING

   Options ::= BIT STRING {
           delegation-state (0),
           mutual-state (1),
           replay-det-state (2), -- 用于context的重放检测
           sequence-state (3),   -- 用于顺序检测
           conf-avail (4),
           integ-avail (5),
           target-certif-data-required (6)
                                 -- 用于请求目的certif. 数据
   }


   Conf-Algs ::= CHOICE {
           algs [0]        SEQUENCE OF AlgorithmIdentifier,
           null [1]        NULL
            -- 当conf.无效时使用
   } – 用于C-ALG (见5.2节关于QOP的讨论)

   Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
       -- 用于I-ALG (见5.2节关于QOP的讨论)

   OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
       -- 在SPKM-2单向认证中，REQ-TOKEN只包含一个算法
       -- 否则至少包含一个算法
       -- 在REP-TOKEN中一直只包含一个算法

   Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
       -- 允许K-ALG协商

如果在应用调用gss-init-sec-context（）时，没有设置双向请求位，则context建立将采
用单向认证模式。SPKM-2只能通过SPKM-REQ实现（用于认证发起方）。而SPKM-1同时
使用SPKM-REQ和SPKM-REP-TI（用于认证目的方）实现。

	应用要求同时认证双方时，必须请求双向认证，在SPKM-REQ选项中设置“mutual-state”
项。目的方通过SPKM-REP-TI进行响应。如果是SPKM-2，相互认证过程（基于时间戳）
已经完成。如果是SPKM-1，发起方接收到响应后，再发送SPKM-REP-IT进行响应，相互
认证过程（基于随机数）才完成。

	Context-Data的Options字段的其它位在RFC-1508中解释，除了
target-certif-data-required，发起者将其设置为TRUE用于请求目的方在SPKM-REP-TI中返
回证书的数据。对于SPKM-2的单向认证，该位被双方忽略。

3．1．2 Context建立令牌 – 目的方
   SPKM-REP-TI ::= SEQUENCE {
           responseToken    REP-TI-TOKEN,
           certif-data      CertificationData OPTIONAL
             -- 如果在SPKM-REQ中 target-certif-data-required选项被设为TRUE，必须
存在
   }