简单公共密钥GSS-API机制(SPKM)

1、Network Working Group C. AdamsRequest for Comments: 2025 Bell-Northern ResearchCategory: Standards Track October 1996简单公共密钥GSS-API机制（SPKM）(rfc2025 The Simple Public-Key GSS-API Mechanism (SPKM)Status of this Memo This document specifies an Internet standards track protocol for the Internet community

2、, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.摘要本规范定义了基于简单公共密钥机制（SPKM）通信的双方采用的协议，处理过程。该机

3、制支持公共安全事务应用程序接口（GSS-API， 见RFC 1508和1509）背景尽管Kerberos的第五版GSS-API在很多情况下广泛使用，但是有些基于GSS-API的应用采用的是公共密钥体系，而不是对称密钥体系。本文所提出的机制满足这一需求，并具有如下特性：1）SPMK允许在不使用安全时间戳的情况下完成单方或双方的认证。这使那些不能存取安全时间戳的环境能够进行安全认证。2）SPKM使用算法标识去定义通信双方所使用的各种算法。这在运行环境，未来扩展以及算法选择上保持了最大限度的灵活性3）SPKM在gss_sign()和gss_seal()中，即GSSv2中的gss_getMIC() g

4、ss_wrap()，实现真正的基于非对称算法的数字签名，而不是基于对称算法（如DES）的MAC的完整性检验。在某些情况下真正的数字签名所支持的抗抵赖性是很重要的。4）在实现时，SPKM的数据格式和程序设计与Kerberos的是类似的。这使得在那些已经运行Kerberos的环境更容易实现SPKM。综上所述，SPKM更加的灵活和广泛，同时没有增加额外的复杂度密钥管理SPKM的密钥管理尽可能地与X.509和PEM（见RFC 1422）兼容，因为他们代表一大批团体的要求，而且在标准上已经相当成熟。致谢本文中的许多材料是基于Kerberos第五版的GSS-API机制（KRB5），并且尽可能与之兼容。本文

5、在很多方面归功于下述人的工作：Bell-Northern Research的Warwick Ford 和Paul Van Oorschot进行了许多富有成效的讨论，Kelvin Desplanque进行一些整理，OpenVision Technologies的John Linn给予了有帮助的建议，OSS的Bancroft Scott给予关于ASN.1的帮助。1概述公共安全事务应用程序接口（GSS-API）的目的在RFC-1508的摘要中是如下描述的：公共安全事务应用程序接口（GSS-API）以一种统一的模式为使用者提供安全事务，由于它支持最基本的机制和技术，所以保证不同的应用环境下的可移植性。

6、该规范定义了GSS-API事务和基本元素，并独立于基本的机制和程序设计语言环境，并借助于其它相关的文档规范实现。他们包括如下定义：-定义与特定语言环境相关的参数-定义令牌格式，协议和为实现基于特别的安全机制的GSS-API事务所采用的处理过程SPKM是后一类文档的一种实例，因此定义为“GSS-API机制”。该机制为基于公共密钥体系的在线分布式应用环境提供认证，密钥建立，数据完整性验证，数据可靠性保障服务。因为它遵从RFC-1508规定的接口，所以SPKM能作为一种掺杂（drop-in）替换，被那些使用基于GSS-API调用的安全事务的应用所采用（如那些采用Kerberos的GSS-API的进行

7、安全处理的应用）。公共密钥体系支持用于信息交换中抗抵赖的数字签名，并具有其它的优点，如大量用户的条件下扩展性（scalability）应用程序可通过GSS-API操作范例（具体见RFC-1508）使用SPKM的令牌：GSS-API中定义的操作范例如下。一个典型的GSS-API调用者本身是一个通信协议（或使用通信协议的应用程序），GSS-API调用是为了在授权，完整性，或可信赖性方面保护其通信安全。一个GSS-API调用者接收本地GSS-API模块产生的的令牌，并将其传递给远端系统；对端传递接收到的令牌至本地GSS-API模块进行进一步处理。本文定义两类GSS-API机制，SPKM-1和SPKM

8、-2，它们主要区别在于SPKM-2在建立上下文环境（context）时要求安全时间戳，而SPKM-1不需要。既然有些环境下安全时间戳并不是必须的，这种区分保证了应用的更大的灵活性。2算法SPKM支持多种算法。这部分将对它们分别进行描述，介绍其用法并对每种算法给出专门的例子。为了保证不同SPKM至少在最低层次上的互操作性，有一种完整性算法是必须支持的；其余算法是可选的（有些GSS兼容的处理不要求支持信息的保密性）。对保密性算法的强制性会限制机制实现的出口，因此本文中定义某些算法是推荐的（即不考虑出口限制，在SPKM中采用这些算法会增加互操作性）。21 完整性算法(I-ALG)目的：主要用于确保一

9、个合法用户产生的数据在任何时刻都不被改变。使用该算法，可以保证数据的真实性，并且支持抗抵赖性例子： md5WithRSAEncryption OBJECT IDENTIFIER := iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 - imported from PKCS1 该算法（必须的）通过用RSA算法去加密源数据的MD5哈希值，来保证数据的完整性和真实性，并支持抗抵赖性。这在本质上同OIW（the Open Systems Environment Implementors' Workshop）所定义

10、的md5WithRSA 1 3 14 3 2 3是完全一致的。既然这是目前唯一必须要求的完整性算法，出于互操作的考虑，规定在建立连接中，所有需要签名的令牌，都使用md5WithRSA算法进行签名，而不是MAC（将）。在以后版本中，如果有其它更好的算法时，这个规定可以进行改变。 DES-MAC OBJECT IDENTIFIER := iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 10 - carries length in bits of the MAC as - an INTEGER parameter, c

11、onstrained to - multiples of eight from 16 to 64这个算法（推荐）通过计算数据的DES MAC去保证完整性（见FIPS-113） md5-DES-CBC OBJECT IDENTIFIER := iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) md5-DES-CBC(1) 这个算法通过用DES CBC算法去加密源数据的“搀杂”的MD5哈希值，去保证数据的完整性（见）。当源数据不是非常短时，这种处理在速度上具有很大的优势。注意到没有搀杂的情况下

12、，这种完整性机制的加密强度相当于明文下使用DES的强度。 sum64-DES-CBC OBJECT IDENTIFIER := iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) sum64-DES-CBC(2) 这个算法通过用DES CBC加密由所有输入源数据源数据块（利用增加模2*64 - 1所计算的总和）和搀杂数据块组成的数据，来保证数据的完整性。因此在这个算法中，为保证安全，加密是必须的。关于完整性算法的安全性的更多解释，可以参考Juen84, Davi89。22 保密性算法 (C-

13、ALG)目的：该对称算法通过gss_seal()和gss_wrap()调用进行加密数据例子： DES-CBC OBJECT IDENTIFIER := iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 - carries IV (OCTET STRING) as a parameter; - this (optional) parameter is unused in - SPKM due to the use of confounding这个算法是推荐的。23 密钥建立算法 (K-ALG):目的：这个算法在发

14、起方和目的方之间，通过建立过程中的上下文（context），产生一个共同的对称密钥。密钥所使用的的C-ALG和I-ALGS（如DES-MAC）算法来自于context密钥。正如3.1将讨论的，密钥建立通过X.509的交互认证模式实现，因此最终产生的共享对称密钥是可信赖的。例子： RSAEncryption OBJECT IDENTIFIER := iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 - imported from PKCS1 and RFC-1423 在这个算法中（必须的），context密钥由发起方

15、产生，通过目的方的RSA公钥加密，并送至目的方。目的方不必要对发起方的要建立的密钥进行响应。 id-rsa-key-transport OBJECT IDENTIFIER := iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 22 - imported from X9.44 这与RSAEncryption类似，但发送方的认证信息一起通过目的方的RSA公钥加密。 dhKeyAgreement OBJECT IDENTIFIER := iso(1) member-body(2) US(840) rsadsi(1135

16、49) pkcs(1) pkcs-3(3) 1 在这个算法中，contxt密钥被连接双方使用Diffie-Hellman密钥建立算法共同产生。目的方必须响应发起方的密钥建立请求（因此K-ALG不能被用于SPKM-2中的单向认证）24 子密钥产生算法(O-ALG)的单向函数目的：在通过K-ALG算法建立context密钥后，发起方和目的方必须能够衍生一套C-ALG和I-ALG算法的子密钥集。由于所支持的C-ALG算法列表是有限连续的，因此第一个算法（默认的）定义为0，下一个为，依次类推。同样，对所支持的I-ALGS算法列表的编号也是一致的。假定，context密钥是一个长度为M的任意二进制串，则

17、必须满足：L<=M<=U（下限L是所有被支持的C-ALG和I-ALG中最长密钥的位长度，上限U是满足K-ALG参数要求的最大位长度）。例如，如果DES和two-key-triple-DES是协商的保密性算法，DES-MAC是协商的完整性算法（数字签名并不使用context密钥），则context密钥必须至少112位长。如果512位RSAEncryption是用于K-ALG的算法，那么发起方产生的context密钥最大位长度为424（PKCS-1所允许的RSA加密数据的最大长度）-目标在能够RSA解密过程中，去掉“填塞”数据，从而判断密钥的长度。另一方面，如果dhKeyAgreeme

18、nt是密钥建立算法，那么context密钥是Diffie-Hellman方法计算的结果，即其长度为Diffie-Hellman的模p减8。K位子密钥的产生算法规定如下： rightmost_k_bits (OWF(context_key | x | n | s | context_key) 其中-如果子密钥是保密性算法，"x"是ASCII字符"C" (0x43)；如果子密钥完整性算法，“x”是ASCII字符“I”（0x49）； -"n" 是所支持的算法列表中算法代表的数字值（ASCII字符“0”（0x30），ASCII字符“1”（0x

19、31），等等）-"s"是处理的“标识”（stage）-一直是ASCII字符“0”（0x30），除非“k”大于OWF的输出，在这种情况下，OWF通过不断增加“标识”的值进行重复计算（每次OWF输出被串接到上次输出的后面），直到“k”位数据被产生 - "|"是连接操作; 且 - "OWF" 是任意单向函数 例子： MD5 OBJECT IDENTIFIER := iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 这个算法是必须的 SHA OBJECT IDE

20、NTIFIER := iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 18 由于现存的哈希算法并不满足OWF的所有特性，这就是为什么允许在建立过程中协商O-ALG OWF，这使得OWF能够更容易改进。例如，在某些环境下，OWF可能是一个用context-key作为密钥加密输入的加密算法25 协商在SPKM的context建立中，发起方向对方提供一套可能的保密性算法和一套可能的完整性算法（包括数字签名算法）。目的方所选择的保密性算法将在context有效期内用于C-ALG，而完整性算法用于I-ALG（目的方通过以相

21、同的顺序返回所支持列表的子集进行响应）。注意，C-ALG和I-ALG可以用于任何使用context的消息，同时保密性算法和完整性算法列表的第一项可以作为该context默认的算法。 context的保密性算法和完整性算法定义了gss-getMIC（）和gss-wrap（）的保护质量参数（QOP）-具体见5.2。如果对方没有响应（SPKM-2的单向认证），则发起方产生的算法将是context所使用的算法（如果该算法不被接受，将返回一个删除令牌表示请求没有建立）。 此外在第一个context建立令牌中，发起方发送一套可能的K-ALG算法，以及通过算法集第一个算法产生的密钥（或一部分）。如果K-AL

22、G不被接受，则目的方选择另一种K-ALG算法，并返回该K-ALG算法和与之相关的密钥或密钥一部分（否则，发送一个删除令牌，表示建立不成功）。如果必须的话（目的方选择2-pass K-ALG如dhKeyAgreement），发送方将继续发送它的密钥。最后，在第一个context建立令牌中，发起方提供一套可能的O-ALG算法（如果不需要响应，只有一种O-ALG算法）。该O-ALG（一个）算法被目的方接受，形成用于context子密钥产生算法的OWF。在以后的SPKM版本中，其他算法也可能被指定。3令牌格式本节讨论SPKM协议上可见的特性；它定义了协议交互的基本元素，并且与程序设计语言无关（见RFC

23、-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应用的双方（为安全conte

24、xt管理和信息保护目的）传递的令牌定义如下。31 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 := APPLICAT

25、ION 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

26、-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表示）。类似信息被包

27、含在令牌的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编码（其简化版是D

28、ER编码，见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的单向认证可以进行协

29、商，但目的方只能选择由发起方提供的单路（one-pass）的K-ALG（或者拒绝请求）。作为选择，发起方能够请求目的方产生并传输context密钥。对SPKM-1的双向认证，目的方能够选择任一one-或two-pass的K-ALG算法，并能够应发送方的请求产生并发送context密钥。通常SPKM-1或SPKM-2都采用双向认证。因此，尽管两种机制都支持单向认证，但在实际应用中并不普遍。311 Context建立令牌 发起方令牌（第一个令牌）为了完成context建立，发起方和目的方必须能够存取其它实体的公钥证书。在某种条件下，发起方可以采用先取得所有的证书，然后将相关的证书包含在在第一个令牌

30、中发到目的方。在另外的条件下，发送方可以要求目的方在其响应中包含证书数据，或者两边各自得到其所需的证书数据。但在任一条件下，建立SPKM的双方必须有能力根据一个所支持的名字得到对应证书。但具体实现机制不属于规范的范畴。相关的SPKM-REQ语法定义如下（附录A给出了其它文档的入口） SPKM-REQ := SEQUENCE requestToken REQ-TOKEN, certif-data 0 CertificationData OPTIONAL, auth-data 1 AuthorizationData OPTIONAL - 关于auth-data的讨论见 RFC-1510 Certi

31、ficationData := 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, -用户的

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

33、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算法的情况下，“Integri

34、ty”表示使用指定算法进行MACing的结果。具体将“token”的DER编码结果进行MACing处理。（因此对于该MAC而言，algId必须是一个完整性算法。）可以想象，在典型应用，REQ-TOKEN，REP-TI-TOKEN，REP-IT-TOKEN的完整性字段通常使用真正的数字签名，并且提供带重放（replay）检查的单向和双向认证。不过，在某些条件下，仍使用MAC选项。如发起方希望匿名访问时（第一第三次令牌是MAC，第二次令牌是签名的）。另一个例子在先前已经建立认证的情况下，带缓冲的context进行在一段时间后重新建立（这里交换令牌是MACed）。使用MAC主要好处在于在认证不是必须

35、的情况下（如匿名），或认证已经以某种模式建立的情况下（在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, -必须支持除

36、非发起方是“匿名的” 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 - 用于绑定对称

37、密钥的源名 - 在SPKM-2双向认证时，这个字段必须存在 - 如果被使用的K-ALG 不提供这个绑定-（但对于所有其他的情况是可选的） - 这个8进制串保持申请必须的哈希处理MD5的结果如下： - MD5(src | context_key), - 其中“src”是src-name的DER编码 - "context-key"是对称密钥（如在key-estb-req中被传递的未保护的版本） - "|"是连接操作 ?协议的版本（pvno）参数是一个BIT STRING，它使用足够的位去定义发起方支持的协议版本（每位表示一个协议版本）。?本文中协议是版本0。

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

39、不需要不可预知的，只是需要是一个新的数） 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-s

40、tate (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 Alg

41、orithmIdentifier - 用于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实现（用于认

42、证发起方）。而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-R

43、EP-TI中返回证书的数据。对于SPKM-2的单向认证，该位被双方忽略。312 Context建立令牌 目的方 SPKM-REP-TI := SEQUENCE responseToken REP-TI-TOKEN, certif-data CertificationData OPTIONAL - 如果在SPKM-REQ中 target-certif-data-required选项被设为TRUE，必须存在 REP-TI-TOKEN := SEQUENCE rep-ti-contents Rep-ti-contents, algId AlgorithmIdentifier, rep-ti-inte

44、g 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中必须被包含 ta

45、rg-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的响应 （如果发起

46、方采用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的某一位。如果目的方不支持所有的版本，则

47、返回一个删除令牌表示连接不被建立。如果发起方的pvno只有一位，而且目的方恰巧支持，则该版本被使用，但REP-TOKEN的参数被忽略。最后，如果发起方和目的方有一个或多个相同的版本，但是REQ-TOKEN并不被目的方支持，则REP-TOKEN必须设置一个合适的pvno位（用于后续令牌的哑元值字段）。发送方必须响应一个带有合适版本的新的REQ-TOKEN（本质上是建立一个新的连接）313 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-na