組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：fol （ fol  fol@371.net ）
譯文發布時間：2001-5-23
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須
保留本文檔的翻譯及版權信息。






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算法，以及通