rfc2025.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：fol （ fol  [e-mail] ）
译文发布时间：2001-5-23
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。






Network Working Group                                           C. Adams
Request for Comments: 2025                        Bell-Northern Research
Category: 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, 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）通信的双方采用的协议，处理过程。该
机制支持公共安全事务应用程序接口（GSS-API， 见RFC 1508和1509）
背景
	尽管Kerberos的第五版GSS-API在很多情况下广泛使用，但是有些基于GSS-API的应
用采用的是公共密钥体系，而不是对称密钥体系。本文所提出的机制满足这一需求，并具有
如下特性：
1）	SPMK允许在不使用安全时间戳的情况下完成单方或双方的认证。这使那些不能存
取安全时间戳的环境能够进行安全认证。
2）	SPKM使用算法标识去定义通信双方所使用的各种算法。这在运行环境，未来扩展
以及算法选择上保持了最大限度的灵活性
3）	SPKM在gss_sign()和gss_seal()中，即GSSv2中的gss_getMIC() gss_wrap()，实现
真正的基于非对称算法的数字签名，而不是基于对称算法（如DES）的MAC的完
整性检验。在某些情况下真正的数字签名所支持的抗抵赖性是很重要的。
4）	在实现时，SPKM的数据格式和程序设计与Kerberos的是类似的。这使得在那些已
经运行Kerberos的环境更容易实现SPKM。

综上所述，SPKM更加的灵活和广泛，同时没有增加额外的复杂度

密钥管理
	SPKM的密钥管理尽可能地与X.509和PEM（见RFC 1422）兼容，因为他们代表一大
批团体的要求，而且在标准上已经相当成熟。
致谢
	本文中的许多材料是基于Kerberos第五版的GSS-API机制（KRB5），并且尽可能与之
兼容。本文在很多方面归功于下述人的工作：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）以一种统一的模式为使用者提供安全
事务，由于它支持最基本的机制和技术，所以保证不同的应用环境下的可移植性。该
规范定义了GSS-API事务和基本元素，并独立于基本的机制和程序设计语言环境，
并借助于其它相关的文档规范实现。他们包括如下定义：
		-定义与特定语言环境相关的参数
		-定义令牌格式，协议和为实现基于特别的安全机制的GSS-API事务所采用的
处理过程

SPKM是后一类文档的一种实例，因此定义为“GSS-API机制”。该机制为基于公共密
钥体系的在线分布式应用环境提供认证，密钥建立，数据完整性验证，数据可靠性保障服务。
因为它遵从RFC-1508规定的接口，所以SPKM能作为一种掺杂（drop-in）替换，被那些使
用基于GSS-API调用的安全事务的应用所采用（如那些采用Kerberos的GSS-API的进行安
全处理的应用）。公共密钥体系支持用于信息交换中抗抵赖的数字签名，并具有其它的优点，
如大量用户的条件下扩展性（scalability）

应用程序可通过GSS-API操作范例（具体见RFC-1508）使用SPKM的令牌：

	GSS-API中定义的操作范例如下。一个典型的GSS-API调用者本身是一个通
信协议（或使用通信协议的应用程序），GSS-API调用是为了在授权，完整性，或
可信赖性方面保护其通信安全。一个GSS-API调用者接收本地GSS-API模块产生
的的令牌，并将其传递给远端系统；对端传递接收到的令牌至本地GSS-API模块
进行进一步处理。

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

	例子：

         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）所定义的md5WithRSA {1 3 14 3 2 3}是完全一致的。
	既然这是目前唯一必须要求的完整性算法，出于互操作的考虑，规定在建立连接中，
所有需要签名的令牌，都使用md5WithRSA算法进行签名，而不是MAC（将3.3.1）。
在以后版本中，如果有其它更好的算法时，这个规定可以进行改变。
		
         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, constrained 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哈希值，去保证
数据的完整性（见3.2.2.1）。当源数据不是非常短时，这种处理在速度上具有很大的优
势。注意到没有搀杂的情况下，这种完整性机制的加密强度相当于明文下使用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]。
2．2 保密性算法 (C-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
		
		这个算法是推荐的。
2．3 密钥建立算法 (K-ALG):
目的：
	这个算法在发起方和目的方之间，通过建立过程中的上下文（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密钥由发起方产生，通过目的方的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(113549) pkcs(1)
           pkcs-3(3) 1
        }
		
	在这个算法中，contxt密钥被连接双方使用Diffie-Hellman密钥建立算法共同产生。
目的方必须响应发起方的密钥建立请求（因此K-ALG不能被用于SPKM-2中的单向认
证）

2．4 子密钥产生算法(O-ALG)的单向函数
目的：
在通过K-ALG算法建立context密钥后，发起方和目的方必须能够衍生一套C-ALG
和I-ALG算法的子密钥集。由于所支持的C-ALG算法列表是有限连续的，因此第一个
算法（默认的）定义为0，下一个为，依次类推。同样，对所支持的I-ALGS算法列表
的编号也是一致的。假定，context密钥是一个长度为M的任意二进制串，则必须满足：
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解密过程
中，去掉“填塞”数据，从而判断密钥的长度。另一方面，如果dhKeyAgreement是密
钥建立算法，那么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”（0x31），等等）
-	"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 IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 18
         }
		
	由于现存的哈希算法并不满足OWF的所有特性，这就是为什么允许在建立过程中
协商O-ALG OWF，这使得OWF能够更容易改进。例如，在某些环境下，OWF可能是
一个用context-key作为密钥加密输入的加密算法

2．5 协商
	在SPKM的context建立中，发起方向对方提供一套可能的保密性算法和一套可能
的完整性算法（包括数字签名算法）。目的方所选择的保密性算法将在context有效期内
用于C-ALG，而完整性算法用于I-ALG（目的方通过以相同的顺序返回所支持列表的
子集进行响应）。注意，C-ALG和I-ALG可以用于任何使用context的消息，同时保密
性算法和完整性算法列表的第一项可以作为该context默认的算法。

	 context的保密性算法和完整性算法定义了gss-getMIC（）和gss-wrap（）的保护
质量参数（QOP）--具体见5.2。如果对方没有响应（SPKM-2的单向认证），则发起方
产生的算法将是context所使用的算法（如果该算法不被接受，将返回一个删除令牌表
示请求没有建立）。 

	此外在第一个context建立令牌中，发起方发送一套可能的K-ALG算法，以及通