rfc2025.txt

很多RFC的中文文档

算法和至少一个可抵赖的完整性算法。

	   作出如上约定的原因是为了确保每个SPKM实现者提供一个支持抗抵赖性的数据完
整性服务和不支持抗抵赖性的数据完整性服务。一个不知道基本算法的应用能够通过传
递（QOP完整性 TS=1，IA=MA=0）或（QOP完整性TS=2, IA=MA=0），选择一个或
另一个算法。尽管一个希望匿名的发起方将永不使用抗抵赖性的数字签名算法，完整性
服务必须在context中必须有效，以便目地方在需要时使用。

	   最后，为了和第二节定义个“必须”和“建议”的算法一致，定义了如下QOP值。

	   对于保密性MA字段：

0001 (1) = DES-CBC

	   对于完整性MA字段：

      0001 (1) = md5WithRSA
      0010 (2) = DES-MAC

6．支持的函数
	这部分描绘了SPKM实现必须支持的函数，该函数实际上在所有的GSS-API机制
中都有意义。它使用token-id和context-id的信息，这些信息被包含在SPKM的context
建立令牌，错误令牌，context删除令牌和消息令牌中。这些函数在如下的章节中定义。

6．1  SPKM解析令牌调用
   输入：

   o  input_token OCTET STRING

   输出：

   o  major_status INTEGER,

   o  minor_status INTEGER,

   o  mech_type OBJECT IDENTIFIER,

   o  token_type INTEGER,

   o  context_handle CONTEXT HANDLE,



   返回主状态（major_status）码：

   o  GSS_S_COMPLETE表示输入令牌的所有字段能够被解析。解析结果被分别储存在
mech_type，token_type 和 context_handle中（如果为空，表示该参数未被使用）。

   o  GSS_S_DEFECTIVE_TOKEN表示要么token-id或context-id（如果存在）未被解
析。如果token-type中返回值非空，表示错误在后者（即context-id 译者注）。 

   o  GSS_S_NO_TYPE表示tonken-id解析成功，但不存在与之对应的有效token-type。

	 （注意在RFC-1508中，没有为GSS定义主状态码。除非对起进行定义（如果曾经有
的话），否则SPKM实现将返回GSS_S_DEFECTIVE_TOKEN，并且token-type和
context-handle设为NULL。这意味着不被认识的token-id信息和不能被解析的token-id信
息是被看作一致	的。）

   o  GSS_S_NO_CONTEXT表示context-id能被解析，但不存在与其对应的
context-handle。

   o  GSS_S_FAILURE表示机制类型不能被解析（如令牌被破坏）。

   SPKM_Parse_token() 被用于返回应用机制的类型，令牌类型和与给定的输入令牌相对
应的context句柄。由于GSS-API令牌对于应用调用者是不透明的，这个函数允许应用在
不违背GSS的不透明性的情况下，决定与令牌相关的信息。其中最主要的是令牌类型，
应用可以用来决定调用哪个GSS函数使得令牌被处理。

	如果所有令牌限于RFC-1508的附录B（同时在Kerberos V5 GSS机制[KRB5]和本文中
描述），则对于任意未被破坏的输入令牌，任意一种实现必须返回至少mech-type参数（其
他参数可以为空）。如果如果一个调用SPKM_Parse_token()实现能够识别令牌，它将返回
token-type使得应用能够继续调用正确的GSS函数。最后，如果机制在它的令牌中提供一
个context-id字段，则一个实现能够映射context-id到context-handle，并将其
（context-handle）返回给应用。这对于那些同时打开多个context并且使用相同的机制的
应用而言是很必须的。当一个输入令牌到达时，应用能够使用该函数决定要调用的GSS
函数和该函数使用的context-handle。注意到该函数不通过加密处理去决定令牌的有效性，
它简单的尝试解析令牌的mech-type，token-type和context-id字段。因此它是可以构造的，
如一个任意的数据缓冲可以从一个看上去象一个有效的mech-type的随机数开始，则
SPKM_Parse_token()对该缓冲数据可能返回错误的信息。尽管是可构造的，但这种情况是
不大可能的。

   SPKM_Parse_token() 函数对与SPKM相容的实现而言是必须的，但对于应用而言是可
选的。也就是，如果一个应用只有一个context，并且能够猜想要调用的GSS函数（或它
愿意处理处理错误码），则应用可以不调用SPKM_Parse_token()。此外，如该函数曾经移
植到GSS-API层，则在采用GSS_Parse_token()，或一个新名字或函数规范时，
SPKM_Parse_token()是被否定的。最后注意到，这时，这个函数没有定义辅助状态返回码。
6．2  token_type输出参数
   定义如下令牌类型：

      GSS_INIT_TOKEN   = 1
      GSS_ACCEPT_TOKEN = 2
      GSS_ERROR_TOKEN  = 3
      GSS_SIGN_TOKEN   = GSS_GETMIC_TOKEN = 4
      GSS_SEAL_TOKEN   = GSS_WRAP_TOKEN   = 5
      GSS_DELETE_TOKEN = 6

	所有的SPKM机制必须能够执行从任意令牌的token-id信息（通过
SPKMInnerContextToken标记值或tok-id字段）到上述类型的映射。应用必须能够基于
token-type决定调用哪个GSS函数（例如，如果令牌是GSS_INIT_TOKEN，则应用将
调用gss_accept_sec_context()，如果令牌是GSS_WRAP_TOKEN，则应用调用
gss_unwrap()）。
6．3  context_handle输出参数
	   SPKM必须维持一个context-id和context-handle间的映射，因此将一个单独的令牌
与其对应的context想关联。很明显，context-handle值可以是本地决定的，事实上，它
可以与包含本地系统中包含敏感数据的内存相关，使得将context-id与一个计算出的
context-handle设为完全相等，是不通用的。相反将context-handle与一个计算出的
context-id设为完全相等也是不通用的，因为context-handle必须在应用第一次调用
gss_init_sec_context()或gss_accept_sec_context()时被返回，而context-id（对两端的所有
context）的唯一性可以要求发送方和目的方同时计算。因此，context-handle和context-id
必须被分别计算，且机制实现必须能够在最近的context建立完成后建立二者间的映射。

	   在令牌建立过程中，Context-id计算处理如下。每个SPKM实现必须产生一个新的
随机数，即一个不大可能已经被使用的。注意到对该随机数，没有加密处理（如，它不
需要不可预见，只是简单要求是一个新的数）。发起方通过PSKM-REQ令牌的context-id
字段将它的随机数到目的方，。如果没有进一步的context建立令牌（如SPKM-2的单向
认证），则这个值被接受为context-id（如果不被目的方接受，必须产生错误令牌）。否
则，目的方产生它的随机数，并将它加到发起方的随机数后面。这个被连接的值被当作
context-id，在SPKM-REP-TI中使用，并在该context的所有的后续令牌中有效。

	   双方共同产生context-id确保每边的值都是新的，因此预先排除了context间的重放
（replay）攻击（一个来自于旧的context的令牌被恶意插入一个新的context中，无论
是相同的对端还是不同的对端）。在SPKM-2单向认证中SPKM-REQ的key-src-bind字
段必须存在用于简单辅助目的方相信该令牌是新的（以及它请求的context密钥）。
7．安全考虑
	安全问题的讨论贯穿在整个备忘录中。

8．参考文献

   [Davi89]:    D. W. Davies and W. L. Price, "Security for Computer
   Networks", Second Edition, John Wiley and Sons, New York, 1989.

   [FIPS-113]:  National Bureau of Standards, Federal Information
   Processing Standard 113, "Computer Data Authentication", May 1985.

   [GSSv2]:     Linn, J., "Generic Security Service Application Program
   Interface Version 2", Work in Progress.

   [Juen84]:    R. R. Jueneman, C. H. Meyer and S. M. Matyas, Message
   Authentication with Manipulation Detection Codes, in Proceedings of
   the 1983 IEEE Symposium on Security and Privacy, IEEE Computer
   Society Press, 1984, pp.33-54.

   [KRB5]:      Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
   RFC 1964, June 1996.

   [PKCS1]:     RSA Encryption Standard, Version 1.5, RSA Data Security,
   Inc., Nov. 1993.

   [PKCS3]:     Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA
   Data Security, Inc., Nov. 1993.

   [RFC-1321]:  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321.

   [RFC-1422]:  Kent, S., "Privacy Enhancement for Internet Electronic
   Mail:  Part II: Certificate-Based Key Management", RFC 1422.

   [RFC-1423]:  Balenson, D., "Privacy Enhancement for Internet
   Elecronic Mail: Part III: Algorithms, Modes, and Identifiers",
   RFC 1423.

   [RFC-1508]:  Linn, J., "Generic Security Service Application Program
   Interface", RFC 1508.

   [RFC-1509]:  Wray, J., "Generic Security Service Application Program
   Interface: C-bindings", RFC 1509.

   [RFC-1510]:  Kohl J., and C. Neuman, "The Kerberos Network
   Authentication Service (V5)", RFC 1510.

   [9798]:      ISO/IEC 9798-3, "Information technology - Security
   Techniques - Entity authentication mechanisms - Part 3:  Entitiy
   authentication using a public key algorithm", ISO/IEC, 1993.

   [X.501]:     ISO/IEC 9594-2, "Information Technology - Open Systems
   Interconnection - The Directory:  Models", CCITT/ITU Recommendation
   X.501, 1993.

   [X.509]:     ISO/IEC 9594-8, "Information Technology - Open Systems
   Interconnection - The Directory:  Authentication Framework",
   CCITT/ITU Recommendation X.509, 1993.

   [X9.44]:     ANSI, "Public Key Cryptography Using Reversible
    Algorithms for the Financial Services Industry:  Transport of
   Symmetric Algorithm Keys Using RSA", X9.44-1993.

9．作者地址

   Carlisle Adams
   Bell-Northern Research
   P.O.Box 3511, Station C
   Ottawa, Ontario, CANADA  K1Y 4H7

   Phone: [phone]
   EMail: [e-mail]


































Appendix A:  ASN.1 Module Definition

SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1)
               security(5) mechanisms(5) spkm(1) spkmGssTokens(10)}


DEFINITIONS IMPLICIT TAGS ::=
BEGIN


-- EXPORTS ALL --


IMPORTS

   Name
      FROM