組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：sword (sword   zxl1025@chinese.com)
譯文發布時間：2001-7-25
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本
文檔的翻譯及版權信息。



 
Network Working Group                                            D. Harkins
Request for Comments: 2409                                         D. Carrel
Category: Standards Track                                       cisco Systems
                                                           November 1998

Internet密鑰交換（IKE）
（The Internet Key Exchange）
本備忘錄的現狀
	本文檔指定了一個Internet 團體的Internet標準協議，并請求討論和建議以作改進。請參考當前
版本的“Internet官方協議標準”（STD 1），查看本協議的標準化進程和現狀。本文檔的分發不受限
制。
版權通告
	Copyright (C) The Internet Society (1998)。保留所有的權利。

目錄
   
1.摘要	2
2.討論	2
3.術語和定義	3
3.1必要的術語	3
3.2符號	3
3.3完全后繼保密	4
3.4安全聯盟	4
4.簡介	5
5.交換	6
5.1 使用簽名來驗證的IKE第一階段	8
5.2	使用公共密鑰加密的第一階段驗證	8
5.3	使用修改過的公鑰加密模式來進行第一階段的驗證	10
5.4	使用共享密鑰的第一階段協商	11
5.5	第二階段——快速模式	12
5.6	新組模式	14
5.7	ISAKMP信息交換	15
6	Oakley組	15
6.1	第一個Oakley缺省組	15
6.2	第二個Oakley組	16
6.3	第三個Oakley組	16
6.4	第四個Oakley組	16
7.	完整IKE交換的負載爆炸	17
7.1	使用主模式的第一階段	17
7.2	使用快速模式的第二階段	18
8.	完全后繼保密舉例	20
10.安全考慮	21
11.IANA考慮	22
11.1	屬性類	22
11.2	加密算法類	22
11.3 hash算法	22
11.4	 組描述和組類型	23
11.5	 存活期類型	23
12.	鳴謝	23
13.參考	23
附錄A	25
屬性分配號碼	25
屬性種類	26
種類值	26
附錄B	28
作者地址	30
作者的注釋	30
完全版權聲明	31


1.摘要
ISAKMP ([MSST98])中對驗證和密鑰交換提出了結構框架，但沒有具體定義。ISAKM被設計用
來獨立的進行密鑰交換，即被設計用于支持多種不同的密鑰交換。
   Oakley ([Orm96])中描述了一系列被稱為“模式”的密鑰交換，并詳述了每一種提供的服務（如
密鑰的完全后繼保密（perfect forward secrecy），身份保護，以及驗證）。
   SKEME ([SKEME])中描述了一種提供匿名，否認，和快速密鑰更新的通用密鑰交換技術。
本文檔將描述使用部分Oakley，部分SKEME，并結合ISAKMP的一種協議，它使用ISAKMP來得
到已驗證的用于生成密鑰和其它安全聯盟（如AH，ESP）中用于IETE IPsec DOI的材料。
2.討論
本文檔描述了一種混合協議。目的是用于以一種保護的方式來協商安全聯盟并為它提供經驗證
過的密鑰生成材料。
   	本文檔中實現的過程可用于協商虛擬專用網（VPN），也可用于遠程用戶（其IP地址不需要事
先知道）從遠程訪問安全主機或網絡。
	支持客戶協商。客戶模式即為協商雙方不是安全聯盟發起的兩個終點。當使用客戶模式時，端
點處雙方的身份是隱藏的。
	本協議并沒有實現整個Oakley協議，只實現了滿足目的所需要的部分子集。它并沒有聲稱與整
個Oakley協議相一致或兼容，也并不依靠Oakley協議。
同樣，本協議沒有實現整個的SKEME協議，只使用了用于驗證的公鑰加密的方法和使用當前時間
（nonce）交換來快速重建密鑰的思路。本協議并不依靠SKEME協議。
3.術語和定義
3.1必要的術語
	本文檔中出現的關鍵字“MUST”，“MUST NOT”，“REQUIRED”，“SHOULD”，“SHOULD 
NOT”以及“MAY”的解釋在[Bra97]中描述。
3.2符號
下列的符號在整個文檔中都使用。

	HDR是ISAKMP的報頭，它的交換類型是模式。當寫成HDR*時，意味著負載加密。
	
SA是有一個或多個提議的SA協商負載。發起方可能提供多個協商的提議；應答方只能用一個
提議來回答。
	
<P>_b指明負載<P>數據部分（body）——不包括ISAKMP的通用vpayload負載。

	SAi_b是SA負載的數據部分（除去ISAKMP通用報頭）——也就是由發起者所提供的DOI、
情況（situation）、所有的提議（proposal）、以及所有的變換（transform）。

	CKY-I和CKY-R分別是ISAKMP報頭中發起者和響應者的cookie。

	g^xi和g^xr分別是Diffie-Hellman ([DH])中發起者和響應者的公共值。

	g^xy是Diffie-Hellman的共享秘密。

	KE是包含了用于Diffie-Hellman交換的公共信息的密鑰交換負載。沒有對KE負載的數據進行
特殊的編碼（如TLV）。

Nx是當前時間（nonce）負載；其中x可以是i和r，分別代表ISAKMP的發起者和響應者。
	
	IDx是x的身份識別負載。x可以是“ii”或“ir”，分別表示第一階段協商中的ISAKMP發起者
和響應者；也可以是“ui”或“ur”，分別表示第二階段的用戶發起者和響應者。用于互聯網DOI的
ID負載格式在[Pip97]中定義。

	SIG是數字簽名負載。簽名的數據是特定于某種交換的。
	
	CERT是證書負載。

	HASH（以及衍生物，如HASH（2）或HASH_I）是hash負載。hash的內容是特定于驗證方法
的。

	prf(key, msg)是key的偽隨機函數——通常是key的hash函數——用于產生表現有偽隨機性的確
定的輸出。prf用于導出密鑰和驗證（即作為有密鑰的MAC）。（見[KBC96]）

	SKEYID是從秘密材料中衍生出的字符串，只有某次交換中的活躍雙方才知道。

	SKEYID_e是ISAKMP SA用來保護消息的機密性的密鑰材料。

	SKEYID_a是ISAKMP SA用來驗證消息所使用的密鑰材料。

	SKEYID_d是非ISAKMP安全聯盟用來衍生出密鑰所使用的密鑰材料。

	<x>y表示“x”是由密鑰“y”加密的。

-->表示“發起者到響應者”的通信（請求）。

	<--表示“響應者到發起者”的通信（回答）。

	| 表示信息的串聯——如X | Y表示X和Y是串聯的。

	[x]表示x是可選的。

	消息加密（ISAKMP報頭后標注有“*”號）必須緊接在ISAKMP報頭后。當通信是受保護的
時候，所有ISAKMP報頭后的負載必須要加密。從SKEYID_e產生加密密鑰的方法由各個算法定義。

3.3完全后繼保密
  
	在本文檔中使用的完全后繼保密（PFS）術語是和一個概念相關的，即限制單密鑰只能訪問到
受本單密鑰保護的數據。要滿足PFS，對于用來保護數據傳輸的已經存在的密鑰來說，它就不能用
于衍生出其它的密鑰，如果用來保護數據傳輸的密鑰是從其它密鑰材料中衍生出來的，則這些材料
就不能再用于衍生任何其它密鑰。
    在本協議中提供了密鑰和身份的完全后繼保密（5.5和 8 節）
3.4安全聯盟
  	安全聯盟（SA）是一組用來保護信息的策略和密鑰。在本協議中，ISAKMP SA是協商雙方為
保護之間的通信而使用的共享的策略和密鑰。
4.簡介
	Oakley和SKEME各自定義了建立經過驗證的密鑰交換的方法。其中包括負載的構建，信息負
載的運送，它們被處理的順序以及被使用的方法。
    然而Oakley定義了“模式”， ISAKMP定義了“階段”。兩者之間的關系非常直接，IKE描述
了在兩個階段中進行的不同的、稱為模式的交換。
   	第一階段指兩個ISAKMP實體建立一個安全、驗證過的信道來進行通信。這被稱為ISAKMP安
全聯盟（SA）。“主模式”和“積極模式”都能完成第一階段的交換。“主模式”和“積極模式”只
能在第一階段中使用。
   	第二階段指協商代表服務的安全聯盟，這些服務可以是IPsec或任何其它需要密鑰材料以及/或
者協商參數的服務。
	“新組模式”并不真正在第一階段或第二階段中。它緊接著第一階段，用于建立可在以后協商
中使用的新組。“新組模式”只能在第一階段之后使用。
   	ISAKMP SA是雙向的，即一旦建立，任何一方都可以發起快速模式交換，信息交換，以及新組
模式交換。由ISAKMP基礎文檔可知，ISAKMP SA由發起者的cookie后跟響應者的cookie來標識
——在第一階段的交換中各方的角色決定了哪一個cookie是發起者的。由第一階段的交換所建立的
cookie順序繼續用于標識ISAKMP SA，而不管快速模式、信息、新組交換的方向。換句話來說，當
ISAKMP SA的方向改變時，cookie不能交換位置。
   由于使用ISAKMP階段，實現中可以在需要時完成快速的密鑰交換。單個第一階段協商可以用
于多個第二階段的協商。而單個第二階段協商可以請求多個安全聯盟。由于這種優化，實現中每個
SA可以少于一個傳輸往返，以及少于一次DH求冪運算。第一階段中的“主模式”提供了身份保護。
當身份保護不必要時，可以使用“積極模式”以進一步減少傳輸往返。下面的內容中包括了開發者
對進行優化的提示。同時必須注意當使用公共密鑰加密來驗證時，積極模式仍然提供身份保護。
	本協議本身并沒有定義自己的DOI。在第一階段中建立的ISAKMP SA可以使用非ISAKMP服
務（如IETF IPSec DOI [Pip97]）的DOI和情形（situation）。在這種情況下，實現中可以限制使用
ISAKMP SA來建立具有相同DOI的服務SA。另一種方法是使用DOI和情形（situation）為零值（參
看[MSST98]中對這些域的描述）來建立ISAKMP SA，在這種情況下，實現中可以自由使用ISAKMP 
SA來為任何已定義的DOI建立安全服務。如果使用DOI為零來建立第一階段的SA，第一階段中的
標識負載的語法就在[MSST98]中定義，而不是從任何的DOI（如[Pip97]，它可能會進一步擴展標識
的語法和語義）中定義。
  
	IKE使用下面的屬性，并且作為ISAKMP安全聯盟的一部分來協商。（這些屬性只屬于ISAKMP
安全聯盟，而不屬于ISAKMP為所代表的服務進行協商而建立的任何安全聯盟）：
	—加密算法
	—hash算法
	—驗證方法
	—進行Diffie-Hellman操作的組的有關信息。
   
	所有這些屬性是強制性的且必須被協商的。另外，可以可選的協商一個偽隨機函數（“prf”）。（當
前本文檔中還沒有定義可協商的偽隨機函數。在雙方都同意時可以私下使用屬性值用于prf協商。）
如果沒有協商“prf”， 協商的HMAC (參看[KBC96])的hash算法就作為偽隨機函數。其它非強制性
的屬性在附錄A中定義。選擇的hash算法必須支持原始模式和HMAC模式。
  
	Diffie-Hellman組必須使用一個已定義的組描述（第6節）來指定，或者定義一個組的全部屬性
（第5.6節）。組屬性（如組類型或素數——參看附錄A）不能和以前定義的組（不論是保留的組描
述，還是由新組模式交換后確定并建立的私下使用的描述）相關聯。
   
	IKE的實現必須支持以下的屬性值：
	—使用弱、半弱密鑰檢查，且為CBC模式的DES[DES]。（弱、半弱密鑰參考[Sch96]，并在附
錄A中列出）。密鑰根據附錄B進行衍生。
	—MD5[MD5]和SHA[SHA]。
	—通過共享密鑰進行驗證。
	—對缺省的組1進行MODP（參看下面內容）。