因特網交換密鑰
The Internet Key Exchange (IKE)
November 1998


















目錄
1. 摘要	5
2. 介紹	5
3. 術語和定義	6
4．IPSEC	6
4.1 IPSEC命名方案	6
4.2  IPSEC 狀況定義	6
4.2.1  SIT_IDENTITY_ONLY	6
4.2.2  SIT_SECRECY	7
4.2.3  SIT_INTEGRITY	7
4.3  IPSEC 安全策略要求	7
4.3.1  密鑰管理問題	8
4.3.2  靜態的密鑰問題	8
4.3.3  主機策略問題	8
4.3.4  證書管理	9
4.4  IPSEC 分配數	9
4.4.1  IPSEC 安全協議標識符	9
4.4.2  IPSEC  ISAKMP 轉變標識符	10
4.4.3  IPSEC AH轉變標識符	11
4.4.4  IPSEC  ESP 轉變標識符	12
4.4.5  IPSEC  IPCOMP 轉變標識符	15
4.5  IPSEC 安全關聯屬性	16
4.5.1 要求的屬性支持	18
4.5.2 分析要求的屬性 ( 一生)	19
4.5.3 屬性協商	19
4.5.4 一生通知	20
4.6  IPSEC 有效負載內容	20
4.6.1 安全關聯有效負載	20
4.6.2 鑒定有效負載內容	23
4.6.3	IPSEC通報信息類型	26
4.7  IPSEC 密鑰交換要求	29
5．安全考慮	29
6．IANA 需要考慮的事項	29
6.1	IPSEC位置定義	30
6.2	IPSEC 安全協議標識符	30
6.3	IPSEC ISAKMP 轉移標志符	30
6.4	IPDEC AH 轉移標識符	31
6.5	IPSEC ESP轉移標識符	31
6.7	IPSEC安全相連屬性	32
6.8	IPSEC 標簽范圍標識符	32
6.9	IPSEC 標識符類型	32
6.10	OPSEC通報信息類型	32
7．改變LOG	33
7.1 從V9中改變	33
7.2 從V8 中改變	33
7.3 從V7 中變化	33
7.4 從V6 中改變	34
7.5 從V5中變化	35
7.6 從V4中的變化	35
7.7 從V3 到V4的變化	36
致謝	36
參考書目	37
全部版權陳述	39

1. 摘要
因特網安全關聯和關密鑰的管理協議 ( ISAKMP ) 為因特網安全關聯管理和密鑰建立定義一個框架。這個框架由定義了的交換，有效負載，和在給定解釋域(DOI )以內發生的處理指南組成。這個文件定義因特網 IP 安全 DOI ( IPSEC  DOI ), 它用具體例子說明IP 適合同 ISAKMP 一起使用,當 IP 使用 ISAKMP商定安全關聯。
關于 IPSEC  DOI 的先前版本的變化的列表，請見7 節。
2. 介紹
在 ISAKMP 以內，解釋的域被用來通過使用 ISAKMP 組織有聯系的協議來商議安全關聯。共享一個DOI 的安全協議選擇安全協議和從一個普通的 ，名字空間轉變的密碼并且共享關密鑰的交換協議標識符。他們也共享 DOI 特定的有效負載數據內容的普通解釋, 包括安全關聯和鑒定有效負載。
總的來說, ISAKMP 把下列要求放在一個 DOI 定義上：
o  為 DOI 特定的協議標識符定義命名方案
o  為狀況域定義解釋
o  定義適用的安全策略集合
o  為 DOI 特定的 SA 屬性的定義句法( 階段II ）
o  為 DOI 特定的有效負載內容定義句法
o  定義附加的密鑰交換類型, 如果需要
o  定義附加的通知消息類型, 如果需要
這個文件的剩余部分為使用 IP 安全(IPSEC )協議提供認證, 完整性，或為 IP 包的機密在合作主機系統或防火墻之間送的請求,進行了詳細實例化。
對于全面的 IPSEC 體系結構描述，見 [ARCH ],[AH ], 和 [ESP ] 。
3. 術語和定義
關鍵詞必須, 不能, 要求, 將, 將不, 應該, 應該不, 推薦,可能和可選,當他們再文檔中出現時,被解釋成如[RFC 2119]所描述的。
4．IPSEC
4.1 IPSEC命名方案
在 ISAKMP 以內，所有的 Doi 的必須在“分配的數字” RFC [ STD-2 ]內同 IANA一起被登記。 IANA 為因特網IP 安全DOI ( IPSEC  DOI )分配的數字是一個 ( 1 ) 。在 IPSEC  DOI 以內，所有著名的標識符必須在 IPSEC  DOI 下面與 IANA 一起被登記。除非另外注明, 在這個文件以內的所有表參考為IPSEC  DOI而被分配數字的 IANA 。對于 IPSEC  DOI 聯系到 IANA 注冊表的進一步的信息,見節 6。
所有的多字節二進制代碼值在網絡字節順序被存儲。
4.2  IPSEC 狀況定義
在 ISAKMP 以內，狀況提供能被響應者用來作出一條關于怎么處理到來的安全關聯信息請求策略的決定。對于IPSEC  DOI ，狀況域是一個有下列值的4字節位掩碼。
狀況							值
--------------
SIT_IDENTITY_ONLY			0x01
SIT_SECRECY					0x02
SIT_INTEGRITY				0x04
4.2.1  SIT_IDENTITY_ONLY
SIT_IDENTITY_ONLY類型指定,安全關聯將被在聯系的鑒定有效負載中提供的源身份信息所標記 。對于各種各樣的鑒定的完全描述見節 4.6.2。所有的 IPSEC  DOI 實現必須支持SIT_IDENTITY_ONLY,由在至少一次階段I Oakley 交換中包含鑒定有效負載 ([ IKE ], 節 5 ) ,并且必須放棄任何不包括鑒定的安裝有效負載關聯。
如果一個開始者既不支持 SIT_SECRECY 也不支持 SIT_INTEGRITY ，狀況僅僅由 4 字節狀況位圖組成并且不包括標記的域標識符域 ( 圖 1 , 節 4.6.1 ) 或任何隨后的標簽信息。相反的,如果開始者支持 SIT_SECRECY 或 SIT_INTEGRITY ，標記的域標識符必須在狀況有效負載時被包括。
4.2.2  SIT_SECRECY
SIT_SECRECY類型指定安全關聯在要求標記秘密的環境中正被商議。如果SIT_SECRECY 在狀況位圖中出現，狀況域將被變量長度數據跟隨,他們包括敏感級別和分隔空間位掩碼。關于安全關聯有效負載格式的完全的描述,見節4.6.1。
如果一個開始者不支持 SIT_SECRECY ， SIT_SECRECY狀況位圖不能被設置并且秘密級別或范疇位圖將被包括。
如果一個應答者不支持 SIT_SECRECY ，環境不支持的標志信息有效負載應該被返回并且安全關聯安裝必須被放棄。
4.2.3  SIT_INTEGRITY
SIT_ INTEGRITY類型指定安全關聯在要求標記完整性的環境中正被商議。如果 SIT_ INTEGRITY 在狀況位圖中出現，狀況域將被變量長度數據跟隨,他們包括完整級別和分隔空間位掩碼。如果SIT_SECRECY也用于關聯,完整信息立即遵從變長秘密級別和類別。關于安全關聯有效負載格式的完全的描述,見節 4.6.1 。
如果一個開始者不支持 SIT_ INTEGRITY ， SIT_ INTEGRITY狀況位圖不能被設置并且無完整性級別或范疇位圖將被包括。
如果一個應答者不支持 SIT_ INTEGRITY ，環境不支持的標志信息有效負載應該被返回并且安全關聯安裝必須被放棄。
4.3  IPSEC 安全策略要求
IPSEC  DOI 不在任何實現上強加特定的安全策略要求。主機系統策略問題將在這個文件的范圍以外。
然而, 當設計一個 IPSEC  DOI 主機實現時，在下面的章節涉及的一些問題必須被考慮。這節自然應該被認為僅僅參考。
4.3.1  密鑰管理問題
選擇來實現 ISAKMP 的許多系統將努力為一個聯合的 IKE 密鑰管理新進程提供執行的保護域，這被期望。在保護模式多用戶操作系統上，這個密鑰管理進程將多半作為分開的特權進程存在。
在這個環境中，介紹密鑰材料到 TCP/IP 核的形式化的API 可以是合乎需要的。 IP 安全體系結構不放任何結構要求,或在一個主機 TCP/IP核和它的密鑰管理供應商之間流動。
4.3.2  靜態的密鑰問題
實現靜態密鑰的主機系統, 或由 IPSEC直接使用，或為認證目的 ( 見 [ IKE ] 節 5.4 ) ，當它不在保護的內存域或由TCP/IP 核使用時,應該采取步驟保護靜態的密鑰材料。
例如, 在一臺膝上計算機上，一個人可能選擇在一家配置存儲器存儲靜態的密鑰, 自己, 在一個私人的口令下面加密了。
依靠操作系統和安裝的實用程序軟件, 一旦靜態的密鑰裝載進TCP/IP 核，他們被保護是不可能的，然而他們不能在沒有滿足一些附加形式的認證下而在起始的系統開始輕易重獲
4.3.3  主機策略問題
假設 IPSEC 的轉變在一夜間發生，是不現實的。主機系統必須準備實現靈活的策略表, 策略表描述哪個系統他們需要安全地通話和他們要求通話安全的系統。一些觀點認為代理防火墻地址可以被要求。
一條最小的途徑可能是 IP 地址，網絡掩碼，和安全要求標志或標志的一張靜態表。
一個更靈活的實現可能由一列通配符 DNS 的命名 ( 例如 "*.foo.bar'),一個在里 / 外 位掩碼 ，和一個可選的防火墻地址組成。通配符 DNS 名字將被用來匹配到來或出去的 IP 地址, 里 / 外位掩碼將被用來決定安全是否將被使用,和哪個方向，并且可選的防火墻地址將被用來顯示通道模式是否需要通過中間防火墻與目標系統談話。
4.3.4  證書管理
實現一個基于證書的認證計劃的主機系統將需要一個機制來獲得和管理證書   數據庫。
安全的 DNS 是是一個證書分發機制, 然而安全的 DNS 地區的普遍應用, 在短術語中，有許多值得懷疑的原因。更可能的是，主機將
需要進口他們通過的安全, out-of-band 機制獲得證書的權能, 和出口自己的證書給另外的系統使用。
然而,手工證書管理不能被執行以便防止介紹動態的證書發現機制或協議的權能成為可行的。
4.4  IPSEC 分配數
下列節為 IPSEC  DOI 列出分配的數字：狀況標識符, 協議標識符, 轉變標識符，AH， ESP ，并且 IPCOMP 轉變標識符, 安全協會屬性類型值, 標記的域標識符， ID 有效負載類型值，和通知消息類型值。
4.4.1  IPSEC 安全協議標識符
ISAKMP 建議句法被特定的設計來允許多重的階段 II 安全協議的同時協商在一個單個的協商內適用。作為結果，下面被列出了的協議組形成了能同時被協商的協議集合。它是決定什么協議能被協商在一起的一個主機策略決定。
下列表為IPSEC DOI而在ISAKMP建議有效負載中引用的安全協議標識符列出值的。
協議 ID					值
-----------					-----
保留						0
PROTO_ISAKMP			1
PROTO_IPSEC_AH			2
PROTO_IPSEC_ESP			3
PROTO_IPCOMP			4
4.4.1.1  PROTO_ISAKMP
PROTO_ISAKMP類型指定在階段I的ISAKMP協議期間要求的消息保護。在 IPSEC  DOI 中被使用的特定的保護機制在 [ IKE ]中被描述。在 IPSEC  DOI 以內的所有的實現必須支持PROTO_ISAKMP 。
NB ：  ISAKMP 保留該值一( 1 ), 越過所有的 DOI 定義。
4.4.1.2  PROTO_IPSEC_AH
PROTO_IPSEC_AH 類型指定 IP 包認證。缺省AH轉變提供數據起源認證, 完整保護, 和重放探測。對于出口控制考慮，機密不能被任何 PROTO_IPSEC_AH轉變所提供。
4.4.1.3  PROTO_IPSEC_ESP
PROTO_IPSEC_ESP 類型指定 IP 包機密。如果要求認證，必須作為 ESP 的部分被提供轉變。缺省 ESP 轉變包括數據起源認證,完整保護, 重放探測, 和機密性。
4.4.1.4  PROTO_IPCOMP
如在[ IPCOMP ]里面定義的, PROTO_IPCOMP類型指定 IP 有效負載壓縮。
4.4.2  IPSEC  ISAKMP 轉變標識符
作為一個 ISAKMP 階段I協商的部分, 開始者的密鑰的交換提供的選擇被用來作一些主機系統策略描述。實際的密鑰交換機制選擇被用來做標準的 ISAKMP 建議有效負載。下列表格列出對于IPSEC  DOI 的為建議有效負載定義的ISAKMP 階段I轉變標識符。
轉變					值
---------					-----
保留					0
KEY_IKE				1
在 ISAKMP 和 IPSEC  DOI 框架內除 IKE ( Oakley )以外定義密鑰的建立協議，是可能的。這個文件的先前版本定義了基于一個通用密鑰的分發中心( KDC )的使用的手工密鑰和計劃。這些標識符從當前的文件被移走了。
IPSEC  DOI 還能在以后被擴大到為附加的non-Oakley 密鑰建立協議包括 關于ISAKMP 和 IPSEC的值, 例如 Kerberos [ RFC-1510 ]或組密鑰管理協議( GKMP )[ RFC-2093 ] 。
4.4.2.1  KEY_IKE
KEY_IKE 類型指定混合的 ISAKMP/Oakley  Diffie-Hellman  密鑰的交換 ( IKE ) ,如在 [ IKE ] 文件定義。在 IPSEC  DOI以內的所有的實現必須支持 KEY_IKE 。
4.4.3  IPSEC AH轉變標識符
認證頭協議 ( AH ) 定義一個強制的和若干可選的轉變用于提供認證, 完整性, 和重放探測。下列表列出定義的AH轉變標識符為IPSEC DOI的ISAKMP 建議有效負載。
注意： 認證算法屬性必須被指定認明適當的H保護組。例如, AH_MD5最好能被想作使用 MD5的通用AH轉變。為了AH請求 HMAC 構造, 一個人指定AH_MD5轉變 ID,伴隨著認證算法屬性設置到 HMAC-MD5。這被顯示使用 " Auth (HMAC-MD5 )" 標志在下列節。
轉變 ID					值
-----------					-----
保留						0-1
AH_MD5					2
AH_SHA					3