IPSec VPN技術規範原理分析

1. IPSec簡介

        IPSec（IP Security）是IETF制定的三層隧道加密協議，它爲Internet上傳輸的數據提供高質量的、可互操作的、基於密碼學的安全保證。特定的通信方之間在IP層通過加密與數據源認證等方式，提供了以下的安全服務： 

• 數據機密性：IPSec發送方在通過網絡傳輸包前對包進行加密。
• 數據完整性：IPSec接收方對發送方發送來的包進行認證，以確保數據在傳輸過程中沒有被篡改。
• 數據來源認證：IPSec在接收端可以認證發送IPSec報文的發送端是否合法。
• 防重放：IPSec接收方可檢測並拒絕接收過時或重複的報文。

        可以通過IKE（Internet Key Exchange因特網密鑰交換協議）爲IPSec提供自動協商交換密鑰、建立和維護安全聯盟的服務，以簡化IPSec使用和管理。IKE協商並不是必須的，IPSec所使用的策略和算法等也可以手工協商。

2. IPSec的實現

        IPsec協議不是一個單獨的協議，它給出了應用於IP層上網絡數據安全的一整套體系結構，包括網絡認證協議AH（Authentication Header，認證頭）、ESP（Encapsulating Security Payload，封裝安全載荷）、IKE（Internet Key Exchange，因特網密鑰交換）和用於網絡認證及加密的一些算法等。其中，AH協議和ESP協議用於提供安全服務，IKE協議用於密鑰交換。

        IPsec提供了兩種安全機制：認證和加密。認證機制使IP通信的數據接收方能夠確認數據發送方的真實身份以及數據在傳輸過程中是否遭篡改。加密機制通過對數據進行加密運算來保證數據的機密性，以防數據在傳輸過程中被竊聽。

        IPsec協議中的AH協議定義了認證的應用方法，提供數據源認證和完整性保證；ESP協議定義了加密和可選認證的應用方法，提供數據可靠性保證。

•  AH協議（IP協議號爲51）提供數據源認證、數據完整性校驗和防報文重放功能，它能保護通信免受篡改，但不能防止竊聽，適合用於傳輸非機密數據。AH的工作原理是在每一個數據包上添加一個身份驗證報文頭，此報文頭插在標準IP包頭後面，對數據提供完整性保護。可選擇的認證算法有MD5（Message Digest）、SHA-1（Secure Hash Algorithm）等。
• ESP協議（IP協議號爲50）提供加密、數據源認證、數據完整性校驗和防報文重放功能。ESP的工作原理是在每一個數據包的標準IP包頭後面添加一個ESP報文頭，並在數據包後面追加一個ESP尾。與AH協議不同的是，ESP將需要保護的用戶數據進行加密後再封裝到IP包中，以保證數據的機密性。常見的加密算法有DES、3DES、AES等。同時，作爲可選項，用戶可以選擇MD5、SHA-1算法保證報文的完整性和真實性。

        在實際進行IP通信時，可以根據實際安全需求同時使用這兩種協議或選擇使用其中的一種。AH和ESP都可以提供認證服務，不過，AH提供的認證服務要強於ESP。同時使用AH和ESP時，設備支持的AH和ESP聯合使用的方式爲：先對報文進行ESP封裝，再對報文進行AH封裝，封裝之後的報文從內到外依次是原始IP報文、ESP頭、AH頭和外部IP頭。

3. 安全聯盟（Security Association，SA）

        IPSec在兩個端點之間提供安全通信，端點被稱爲IPsec對等體。

        SA是IPsec的基礎，也是IPsec的本質。SA是通信對等體間對某些要素的約定，例如，使用哪種協議（AH、ESP還是兩者結合使用）、協議的封裝模式（傳輸模式和隧道模式）、加密算法（DES、3DES和AES）、特定流中保護數據的共享密鑰以及密鑰的生存週期等。建立SA的方式有手工配置和IKE自動協商兩種。

        SA是單向的，在兩個對等體之間的雙向通信，最少需要兩個SA來分別對兩個方向的數據流進行安全保護。同時，如果兩個對等體希望同時使用AH和ESP來進行安全通信，則每個對等體都會針對每一種協議來構建一個獨立的SA。

        SA由一個三元組來唯一標識，這個三元組包括SPI（Security Parameter Index，安全參數索引）、目的IP地址、安全協議號（AH或ESP）。

        SPI是用於唯一標識SA的一個32比特數值，它在AH和ESP頭中傳輸。在手工配置SA時，需要手工指定SPI的取值。使用IKE協商產生SA時，SPI將隨機生成。

        通過IKE協商建立的SA具有生存週期，手工方式建立的SA永不老化。IKE協商建立的SA的生存週期有兩種定義方式：

• 基於時間的生存週期，定義了一個SA從建立到失效的時間；
• 基於流量的生存週期，定義了一個SA允許處理的最大流量。

        生存週期到達指定的時間或指定的流量，SA就會失效。SA失效前，IKE將爲IPsec協商建立新的SA，這樣，在舊的SA失效前新的SA就已經準備好。在新的SA開始協商而沒有協商好之前，繼續使用舊的SA保護通信。在新的SA協商好之後，則立即採用新的SA保護通信。

4. 封裝模式

        IPSec有如下兩種工作模式：

• 隧道（tunnel）模式：用戶的整個IP數據包被用來計算AH或ESP頭，AH或ESP頭以及ESP加密的用戶數據被封裝在一個新的IP數據包中。通常，隧道模式應用在兩個安全網關之間的通訊。
•  傳輸（transport）模式：只是傳輸層數據被用來計算AH或ESP頭，AH或ESP頭以及ESP加密的用戶數據被放置在原IP包頭後面。通常，傳輸模式應用在兩臺主機之間的通訊，或一臺主機和一個安全網關之間的通訊。

        不同的安全協議在tunnel和transport模式下的數據封裝形式如圖1所示，data爲傳輸層數據。

圖1 安全協議數據封裝格式

5. 加密算法

        IPSec VPN使用國家密碼管理局批准的非對稱密碼算法、對稱密碼算法、密碼雜湊算法和隨機數生成算法。算法及使用方法如下：

• 非對稱密碼算法使用SM2橢圓曲線密碼算法，也可支持2048位及以上的RSA算法，用於實體驗證、數字簽名和數字信封等。
• 對稱密碼算法使用SM1或SM4分組密碼算法，用於密鑰協商數據的加密保護和報文數據的加密保護。算法的工作模式使用CBC模式。
• 密碼雜湊算法使用SM3或SHA-1密碼雜湊算法，用於對稱密鑰生成和完整性校驗。
• 隨機數生成算法生成的隨機數應能通過GM/T 0005規定的檢測。

6. 協商方式

        有如下兩種協商方式建立SA：

•  手工方式（manual）配置比較複雜，創建SA所需的全部信息都必須手工配置，而且不支持一些高級特性（例如定時更新密鑰），但優點是可以不依賴IKE而單獨實現IPsec功能。
• IKE自動協商（isakmp）方式相對比較簡單，只需要配置好IKE協商安全策略的信息，由IKE自動協商來創建和維護SA。

        當與之進行通信的對等體設備數量較少時，或是在小型靜態環境中，手工配置SA是可行的。對於中、大型的動態網絡環境中，推薦使用IKE協商建立SA。

7. 安全隧道

        安全隧道是建立在本端和對端之間可以互通的一個通道，它由一對或多對SA組成。

8. 加密卡

        IPsec在設備上可以通過軟件實現，還可以通過加密卡實現。通過軟件實現，由於複雜的加密/解密、認證算法會佔用大量的CPU資源，從而影響設備整體處理效率；而通過加密卡，複雜的算法處理在硬件上進行，從而提高了設備的處理效率。

        加密卡進行加/解密處理的過程是：設備將需要加/解密處理的數據發給加密卡，加密卡對數據進行處理，然後加密卡將處理後的數據發送回設備，再由設備進行轉發處理。

9. IPSec虛擬隧道接口

        IPSec虛擬隧道接口是一種支持路由的三層邏輯接口，它可以支持動態路由協議，所有路由到IPSec虛擬隧道接口的報文都將進行IPSec保護，同時還可以支持對組播流量的保護。使用IPSec虛擬隧道接口建立IPSec隧道具有以下優點：

• 簡化配置：通過路由來確定對哪些數據流進行IPSec保護。與通過ACL指定數據流範圍的方式相比，這種方式簡化了用戶在部署IPSec安全策略時配置上的複雜性，使得IPSec的配置不會受到網絡規劃的影響，增強了網絡規劃的可擴展性，降低了網絡維護成本。
• 減少開銷：在保護遠程接入用戶流量的組網應用中，在IPSec虛擬隧道接口處進行報文封裝，與IPSec over GRE或者IPSec over L2TP方式的隧道封裝相比，無需額外爲入隧道流量加封裝GRE頭或者L2TP頭，減少了報文封裝的層次，節省了帶寬。
• 業務應用更靈活：IPSec虛擬隧道接口在實施過程中明確地區分出“加密前”和“加密後”兩個階段，用戶可以根據不同的組網需求靈活選擇其它業務（例如NAT、QoS）實施的階段。例如，如果用戶希望對IPSec封裝前的報文應用QoS，則可以在IPSec虛擬隧道接口上應用QoS策略；如果希望對IPSec封裝後的報文應用QoS，則可以在物理接口上應用QoS策略。

10. IPSec虛擬隧道接口工作原理

        IPSec虛擬隧道接口對報文的加封裝/解封裝發生在隧道接口上。用戶流量到達實施IPSec配置的設備後，需要IPSec處理的報文會被轉發到IPSec虛擬隧道接口上進行加封裝/解封裝。

如圖2所示，IPSec虛擬隧道接口對報文進行加封裝的過程如下：

圖2 IPSec虛接口隧道加封裝原理圖

• Router將從入接口接收到的IP明文送到轉發模塊進行處理；
• 轉發模塊依據路由查詢結果，將IP明文發送到IPSec虛擬隧道接口進行加封裝：原始IP報文被封裝在一個新的IP報文中，新IP頭中的源地址和目的地址分別爲隧道接口的源地址和目的地址。
• IPSec虛擬隧道接口完成對IP明文的加封裝處理後，將IP密文送到轉發模塊進行處理；
• 轉發模塊進行第二次路由查詢後，將IP密文通過隧道接口的實際物理接口轉發出去。

如圖3所示，IPsec虛擬隧道接口對報文進行解封裝的過程如下：

• Router將從入接口接收到的IP密文送到轉發模塊進行處理；
• 轉發模塊識別到此IP密文的目的地爲本設備的隧道接口地址且IP協議號爲AH或ESP時，會將IP密文送到相應的IPSec虛擬隧道接口進行解封裝：將IP密文的外層IP頭去掉，對內層IP報文進行解密處理。
• IPSec虛擬隧道接口完成對IP密文的解封裝處理之後，將IP明文重新送回轉發模塊處理；
• 轉發模塊進行第二次路由查詢後，將IP明文從隧道的實際物理接口轉發出去。

        從上面描述的加封裝/解封裝過程可見，IPSec虛擬隧道接口將報文的IPSec處理過程區分爲兩個階段：“加密前”和“加密後”。需要應用到加密前的明文上的業務（例如NAT、QoS），可以應用到隧道接口上；需要應用到加密後的密文上的業務，則可以應用到隧道接口對應的物理接口上。

11. IKE簡介

        在實施IPsec的過程中，可以使用IKE（Internet Key Exchange，因特網密鑰交換）協議來建立SA，該協議建立在由ISAKMP（Internet Security Association and Key Management Protocol，互聯網安全聯盟和密鑰管理協議）定義的框架上。IKE爲IPSec提供了自動協商交換密鑰、建立SA的服務，能夠簡化IPSec的使用和管理，大大簡化IPSec的配置和維護工作。

        IKE不是在網絡上直接傳輸密鑰，而是通過一系列數據的交換，最終計算出雙方共享的密鑰，並且即使第三者截獲了雙方用於計算密鑰的所有交換數據，也不足以計算出真正的密鑰。

11. 1 數據認證

        數據認證有如下兩方面的概念：

• 身份認證：身份認證確認通信雙方的身份。支持兩種認證方法：預共享密鑰（pre-shared-key）認證和基於PKI的數字簽名（rsa-signature）認證。
• 身份保護：身份數據在密鑰產生之後加密傳送，實現了對身份數據的保護。

11.2 DH

        DH（Diffie-Hellman，交換及密鑰分發）算法是一種公共密鑰算法。通信雙方在不傳輸密鑰的情況下通過交換一些數據，計算出共享的密鑰。即使第三者（如黑客）截獲了雙方用於計算密鑰的所有交換數據，由於其複雜度很高，不足以計算出真正的密鑰。所以，DH交換技術可以保證雙方能夠安全地獲得公有信息。

11.3 PFS

        PFS（Perfect Forward Secrecy，完善的前向安全性）特性是一種安全特性，指一個密鑰被破解，並不影響其他密鑰的安全性，因爲這些密鑰間沒有派生關係。對於IPSec，是通過在IKE階段2協商中增加一次密鑰交換來實現的。PFS特性是由DH算法保障的。

12 密鑰交換協議

        密鑰交換協議定義了協商、建立、修改、刪除安全聯盟的過程和報文格式。協議報文使用UDP協議500端口進行傳輸。

        用到的符號如下：

        HDR： 一個ISAKMP頭。

        HDR*：表示ISAKMP頭後面的載荷是加密的。

        SA：帶有一個或多個建議載荷的安全聯盟載荷。

        IDi：發起方的標識載荷。

        IDr：響應方的標識載荷。

        HASHi：發起方的雜湊載荷。

        HASHr：響應方的雜湊載荷。

        SIGi：發起方的簽名載荷。

        SIGr：響應方的簽名載荷。

        CERT_sig_r：簽名證書載荷。

        CERT_enc_r：加密證書載荷。

        Ni：發起方的 nonce 載荷。

        Nr：響應方的 nonce 載荷。

        <p>_b：載荷<p>的主體，就是沒有ISAKMP通用頭的載荷。

        pub_i：發起方公鑰。

        pub_r：響應方公鑰。

        prv_i：發起方私鑰。

        prv_r：響應方私鑰。

        CKY-I：ISAKMP頭中的發起方 cookie。

        CKY-R：ISAKMP頭中的響應方 cookie。

        x | y：x 與 y 串接。

        [x]：x 爲可選。

        Asymmetric_Encrypt(msg, pub_key)：使用非對稱算法Asymmetric，pub_key作爲密鑰對輸入信息msg_b進行加密，其輸出爲msg的通用載荷頭和密文串接。 如RSA_Encrypt(Ski, pub_key)表示使用RSA算法，使用公鑰pub_key對Ski_b進行加密，其輸出爲Ski的通用載荷頭和密文串接。

        Asymmetric_Sign (msg, priv_key)：使用非對稱算法Asymmetric，priv_key作爲密鑰對msg進行數字簽名。

        Symmetric_Encrypt(msg,key)：使用對稱算法Symmetric，key作爲密鑰對輸入信息msg_b進行加密，其輸出爲msg的通用載荷頭和密文串接。如SM1_Encrypt (Ni, key)表示使用SM1算法，使用key作爲密鑰對Ni_b進行加密，其輸出爲Ni的通用載荷頭和密文串接。

        Hash(msg)：使用密碼雜湊算法對msg進行數據摘要運算。

        PRF(key，msg)：使用密鑰 key 對消息 msg 進行數據摘要運算。

12.1 密鑰交換的載荷格式

12.1.1 消息頭格式

        密鑰交換協議消息由一個定長的消息頭和不定數量的載荷組成。消息頭包含着協議用來保持狀態並處理載荷所必須的信息。

        ISAKMP的頭格式如下所示：

發起方cookie
響應方cookie
下一個載荷	版本號	交換類型	標誌
消息ID
長度

        發起方cookie：這個字段是一個唯一的8字節比特串，由發起方隨機生成。

        響應方cookie：這個字段是一個唯一的8字節比特串，由響應方隨機生成。

        Cookie的生成方法應參照RFC2408 2.5.3要求生成。

        下一個載荷：這個字段爲1個字節，說明消息中的第一個載荷的類型。載荷類型的定義如表1所示：

                                                                                            表1 載荷類型的定義

下一個載荷	值
無 (None)	0
安全聯盟 (Security association)	1
建議 (Proposal)	2
變換 (Transform)	3
密鑰交換 (Key exchange)	4
標識 (Identification)	5
證書 (Certificate)	6
證書請求 (Certificate Request)	7
雜湊 (Hash)	8
簽名 (Signature)	9
Nonce	10
通知 (Norigication)	11
刪除 (Delete)	12
廠商 (Vendor)	13
屬性載荷	14
NAT_D	20
NAT_OA	21
對稱密鑰載荷（SK）	128
保留 (Reserved)	15-127
私有使用 (PrivateUse)	128-255

        版本號：這個字段爲1個字節，其中0-3位表示主版本號，4-7位表示次版本號。本規範規定主版本號爲1，次版本號爲1。

        交換類型：這個字段爲1個字節，說明組成消息的交換的類型。交換類型的定義如下所示：

交換類型	分配的值
無 (None)	0
基本 (Base)	1
身份保護 (Identity protection)	2
僅認證 (Authentication only)	3
信息 (Informational)	5
將來使用 (Future use)	6-31
DOI具體使用	32-239
私有使用 (Private use)	240-255

        本規範規定密鑰交換第一階段使用的交換類型爲身份保護類型即主模式，其值爲2。第二階段交換使用的快速模式所分配的值爲32。

        標誌：這個字段的長度爲1個字節，說明爲密鑰交換協議設置的具體選項。目前使用了這個域的前3個比特，其他比特在傳輸前被置爲0。具體定義如下：

• 加密比特：這是標誌字段中的最低有效比特。當這個比特被置爲1時，該消息頭後面所有的載荷都採用ISAKMP SA中指定的密碼算法加密。當這個比特被置爲0時，載荷不加密。
• 提交比特：這是標誌字段的第2個比特，本規範中其值爲0。
• 僅認證比特：這是標誌字段的第3個比特，本規範中其值爲0。

        消息ID：這個字段的長度爲4字節，第一階段中該字段爲0，在第二階段爲發起方生成的隨機數。它作爲惟一的消息標誌，用於在第二階段的協商中標識協議狀態。

        長度：這個字段的長度爲4字節，以字節爲單位標明包含消息頭和載荷在內的整個消息長度。

12.1.2 通用載荷頭

        每個載荷由通用載荷頭開始。通用載荷頭定義了載荷的邊界，所以就可以聯接不同的載荷。通用載荷頭的定義如圖下所示：

下一個載荷

保留

載荷長度

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

12.1.3 安全聯盟載荷

        安全聯盟載荷用於協商SA，並且指定協商所基於的解釋域DOI。安全聯盟的格式依賴於他使用的DOI，本載荷的類型值爲1。安全聯盟載荷的格式如下所示：

下一個載荷	保留	載荷長度
解釋域（DOI）
情形

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明整個安全聯盟載荷的長度，計算範圍包括SA載荷、所有建議載荷、和所有與被提議的安全聯盟有關的變換載荷。

        解釋域DOI：這個字段長度爲4個字節，其值爲無符號整數，它指定協商所基於的DOI，這個字段的值爲1。

        情形：這個字段長度爲4個字節，表明協商發生時的情形，用來決定需要的安全服務的信息。定義如下：

• SIT_IDENTITY_ONLY：其值爲1。表明SA將由一個相關的標識載荷中的源標識信息來標識。
• SIT_SECRECY：其值爲2。表明SA正在一個需經標記的祕密的環境中協商。
• SIT_INTEGRITY：其值是4。表明SA正在一個須經標記的完整性環境中協商。

        本規範默認採用SIT_IDENTITY_ONLY情形。

12.1.4 建議載荷

        建議載荷用於密鑰交換的發起方告知響應方它優先選擇的安全協議以及希望協商中的SA採用的相關安全機制，本載荷的類型值爲2。建議載荷的格式如下所示：

下一個載荷	保留	載荷長度
建議號	協議ID	SPI長度	變換數
變長的SPI

        下一個載荷：這個字段的長度爲1個字節，如果後面還有建議載荷，其值爲2，否則應爲0。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明整個建議載荷的長度。計算範圍包括包括通用載荷頭、建議載荷、和所有與該建議有關的變換載荷，該長度僅用於標明本建議載荷的長度。

        建議號：這個字段的長度爲1個字節，標明本建議載荷的建議編號。多個建議的建議號相同標明這些建議是“邏輯與”的關係，不同標明這些建議是“邏輯或”的關係。單調遞增的建議號表示對建議的優先選擇順序，建議號越小優先權越高。

        協議ID：這個字段的長度爲1個字節，標明協議標識符。協議標識符的定義如表3所示：

                                                                                 表3 協議標識符的定義

協議標識符	描述	值
RESERVED	未分配	0
PROTO_ISAKMP	ISAKMP的協議標識符	1
PROTO_IPSec_AH	AH的協議標識符	2
PROTO_IPSec_ESP	ESP的協議標識符	3
PROTO_IPCOMP	IP壓縮的協議標識符	4

        SPI長度：這個字段的長度爲1個字節，以字節爲單位標明SPI的長度。在第一階段該長度爲0，在第二階段該長度爲4。

        變換數：這個字段的長度爲1個字節，標明建議的變換載荷個數。

        變長的SPI：在第一階段沒有這個字段，在第二階段這個字段的長度爲4個字節，其內容是該建議的提出者產生的隨機數。

12.1.5 變換載荷

        變換載荷用於密鑰交換的發起方告知響應方爲一個指定的協議提供不同的安全機制，本載荷的類型值爲3。變換載荷的格式如圖下所示：

下一個載荷	保留	載荷長度
變換號	變換ID	保留2
SA屬性

        下一個載荷：這個字段的長度爲1個字節，如果後面還有變換載荷，其值爲3，否則應爲0。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明本變換載荷的長度。計算範圍包括通用載荷頭、變換載荷和所有的SA屬性載荷。

        變換號：這個字段的長度爲1個字節，標明本變換載荷的變換編號。單調遞增的變換號表示對變換的優先選擇順序，變換號越小優先權越高。

        變換ID：這個字段的長度爲1個字節，標明建議協議的變換標識符。在第一階段該字段的值爲1，在第二階段根據不同的協議選用不同的變換ID。AH協議的變換ID的定義如表4所示，ESP協議的變換ID的定義如表5所示：

                                                                             表4 AH協議的變換ID的定義

變換ID	描述	值
RESERVED	未使用	0-1
AH_SHA	使用SHA-1雜湊算法的HMAC	3
AH_SM3	使用帶256比特SM3密碼雜湊算法的HMAC	20

                                                                             表5 ESP協議的變換ID的定義

變換ID	描述	值
RESERVED	未使用	0
ESP_SM4	SM4分組密碼算法	127
ESP_SM1	SM1分組密碼算法	128

        保留2：這個字段的長度爲2個字節，其值爲0。

        SA屬性：該字段的長度是可變的，標明本變換的SA屬性。該字段的具體定義見本12.1.6

12.1.6 SA屬性載荷

        SA屬性載荷只能用於變換載荷之後，並且沒有通用載荷頭，用於表示SA屬性的數據結構，本載荷的類型值爲14。SA屬性載荷的格式如圖下所示：

屬性類型

屬性值

	屬性類型	屬性長度
屬性值

        屬性類型：這個字段的長度爲2個字節，標明屬性類型。該字段的最高有效比特（比特0）如果爲0，屬性值是變長的，並且本載荷有3個字段，分別是屬性類型、屬性長度和屬性值。如果屬性類型最高有效比特爲1，屬性值是定長的並且本載荷僅有2個字段，分別是屬性類型和屬性值。如果屬性類型是變長的,並且屬性值能在兩個字節中表示,那麼變長的屬性可以用定長表示。

        第一階段密鑰協商屬性類型的定義如表6所示：

                                                                表6 第一階段密鑰協商屬性類型的定義

分類	值	長度
加密算法	1	定長
HASH算法	2	定長
認證方式	3	定長
交換羣描述	4	定長
交換羣類型	5	定長
羣素數/不可約多項式	6	變長
羣產生器1	7	變長
羣產生器2	8	變長
羣曲線A	9	變長
羣曲線B	10	變長
SA生存期類型	11	定長
SA生存期 (SA Life Duration)	12	變長
僞隨機函數（PRF）	13	定長
密鑰長度	14	定長
字段大小	15	定長
羣順序	16	變長
塊大小	17	定長
非對稱算法類型	20	定長

        第二階段密鑰協商屬性類型的定義如表7所示：

                                                                       表7 第二階段密鑰協商屬性類型的定義

分類	值	長度
SA生存類型 (SA Life Type)	1	定長
SA生存期 (SA Life Duration)	2	變長
組描述 (Group Description)	3	定長
封裝模式 (Encapsulation Mode)	4	定長
認證算法 (Authentication Algorithm)	5	定長
密鑰長度 (Key Length)	6	定長
密鑰輪數 (Key Rounds)	7	定長
壓縮字典長度 (Compress Dictionary Size)	8	定長
私有壓縮算法 (Compress Private Algorithm)	9	變長

        屬性值：這個字段如果是定長的，其長度爲2個字節。如果是變長的，其長度由屬性長度字段指定。

        屬性長度：當屬性值是變長時，該字段標明屬性值的長度。

        第一階段加密算法屬性值的定義如表8所示：

                                                                           表8 第一階段加密算法屬性值的定義

名稱	描述	值
ENC_ALG_SM1	SM1分組密碼算法	128

        第一階段密碼雜湊算法屬性值的定義如表9所示：

                                                                           表9 第一階段密碼雜湊算法屬性值的定義

名稱	描述	值
HASH_ALG_SHA	SHA-1密碼雜湊算法	2
HASH_ALG_SM3	SM3密碼雜湊算法	20

        第一階段認證方式屬性值的定義如表10所示：

                                                                            表10 第一階段認證方式屬性值的定義

名稱	描述	值
AUTH_METHOD_DE	公鑰數字信封認證方式	10

        SA生存期類型屬性值的定義適用於第一階段和第二階段，如表11所示：

                                                                             表11 SA生存期類型屬性值的定義

名稱	描述	值
SA_LD_TYPE_SEC	秒	1
SA_LD_TYPE_KB	千字節	2

        第一階段公鑰算法類型屬性值的定義如表12所示：

                                                                             表12 第一階段公鑰算法類型屬性值的定義

名稱	描述	值
ASYMMETRIC_RSA	RSA 公鑰密碼算法	1
ASYMMETRIC_SM2	SM2橢圓曲線密碼算法	2

        第二階段封裝模式屬性值的定義如表13所示：

                                                                              表13 第二階段封裝模式屬性值的定義

名稱	描述	值
RESERVED	使用	0
ENC_MODE_TUNNEL	隧道模式	1
ENC_MODE_TRNS	傳輸模式	2
ENC_MODE_UDPTUNNEL_RFC	NAT穿越隧道模式	3
ENC_MODE_UDPTRNS_RFC	NAT穿越傳輸模式	4

        第二階段認證算法屬性值的定義如表14所示：

                                                                               表14 第二階段認證算法屬性值的定義

名稱	描述	值
RESERVED	使用	0
HMAC_SHA	SHA-1密碼雜湊算法的HMAC	2
HMAC_SM3	SM3密碼雜湊算法的HMAC	20

12.1.7 標識載荷

        標識載荷用於通信雙方交換身份信息，該信息用於確認通信雙方的身份，本載荷的類型值爲5。標識載荷的格式如下所示：

下一個載荷	保留	載荷長度
標識類型	協議ID	端口
標識數據

         下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        標識類型：這個字段的長度爲1個字節，標明標識數據字段中的身份信息類型。標識類型的定義如表15所示：

                                                                                        表15 標識類型的定義

ID類型	描　述	值
RESERVED	未使用	0
ID_IPv4_ADDR	一個單獨的4字節IPv4地址	1
ID_FQDN	完全合格的域名字符串	2
ID_USER_FQDN	完全合格的用戶名字符串	3
ID_IPv4_ADDR_SUBNET	帶有4字節子網掩碼的IPv4地址	4
ID_IPv6_ADDR	一個單獨的16字節IPv6地址	5
ID_IPv6_ADDR_SUBNET	一個帶有16字節子網掩碼的IPv6地址	6
ID_IPv4_ADDR_RANGE	一個IPv4的地址範圍	7
ID_IPV6_ADDR_RANGE	一個IPv6的地址範圍	8
ID_DER_ASN1_DN	一個ASN.1X.500的文本編碼	9
ID_DER_ASN1_GN	一個ASN.1X.500的二進制編碼	10
ID_KEY_ID	用於傳遞特定廠商信息的字節流	11

        在第一階段可以使用的標識類型爲：

        ID_IPv4_ADDR

        ID_IPv6_ADDR

        ID_DER_ASN1_DN

        ID_DER_ASN1_GN

        ID_FQDN

        ID_USER_FQDN

        ID_KEY_ID

        在第二階段可以使用的標識類型爲：

        ID_IPv4_ADDR

        ID_IPv6_ADDR

        ID_IPv4_ADDR_SUBNET

        ID_IPv6_ADDR_SUBNET

        ID_IPv4_ADDR_RANGE

        ID_IPV6_ADDR_RANGE

        協議ID：這個字段的長度爲1個字節，標明一個IP協議的上層協議號。值爲0表明忽略這個字段，在第一階段這個值應爲0。在第二階段是用戶配置的安全策略五元組的協議，值爲0表明忽略這個字段。

        端口：這個字段的長度爲2個字節，標明一個上層協議的端口。值爲0表明忽略這個字段，在第一階段這個值應爲0。在第二階段是用戶配置的安全策略五元組的端口，值爲0表明忽略這個字段。

        標識數據：這個字段是變長的，標明與ID類型字段相對應的標識信息。

12.1.8 證書載荷

        證書載荷用於通信雙方交換證書以及證書相關信息，本載荷的類型值爲6。證書載荷的格式如下所示：

下一個載荷	保留	載荷長度
證書編碼	證書數據
證書數據

         下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表5-1-1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        證書編碼：這個字段的長度爲1個字節，標明證書數據字段的證書編碼類型。證書編碼類型定義如表16所示：

                                                                                             表16 證書編碼類型定義

證書類型	值
無 (NONE)	0
PKCS#7封裝的X.509證書	1
PGP證書	2
DNS已簽名密鑰	3
X.509簽名證書	4
X.509加密證書	5
Kerberos令牌	6
CRL（證書吊銷列表）	7
ARL（機構吊銷列表）	8
SPKI證書	9
X.509屬性證書	10
保留	11-255

        在本規範中，只能使用X.509格式的簽名證書和加密證書。

        證書數據：這個字段是變長字段，標明證書。證書的結構及定義參見GM/T 0015。

12.1.9 雜湊載荷

        雜湊載荷的內容是在SA協商過程中選定的密碼雜湊算法生成的數據，本載荷的類型值爲8。雜湊載荷的格式如下所示：

下一個載荷	保留	載荷長度
雜湊數據

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        雜湊數據：這個字段的長度是變長的，其內容爲密碼雜湊算法生成的數據。

12.1.10 簽名載荷

        簽名載荷的內容是在SA協商過程中的數字簽名算法生成的數據，本載荷的類型值爲9。簽名載荷的格式如下所示：

下一個載荷	保留	載荷長度
簽名數據

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        簽名數據：這個字段的長度是變長的，其內容爲簽名算法生成的數據。

12.1.11 Nonce載荷

        Nonce載荷的內容是用於保護交換數據的隨機數據，本載荷的類型值爲10。Nonce載荷的格式如下所示：

下一個載荷	保留	載荷長度
Nonce數據

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        Nonce數據：這個字段的長度是變長的，其內容爲隨機數。

12.1.12 通知載荷

        通知載荷用於傳送通知數據，本載荷的類型值爲11，通知載荷的格式如下所示：

下一個載荷	保留	載荷長度
解釋域（DOI）
協議ID	SPI長度	通知消息類型
安全參數索引（SPI）
通知數據

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        解釋域（DOI）：這個字段的長度爲4個字節，這個字段的值爲1。

        協議ID：這個字段的長度爲1個字節，標明協議標識符。協議標識符的定義如表3所示。

        SPI長度：這個字段的長度爲1個字節，以字節爲單位標明SPI的長度。在第一階段該長度爲0，在第二階段該長度爲4。

        通知消息類型：這個字段的長度爲2個字節，標明通知消息類型。通知消息的錯誤類型如表17所示，通知消息的狀態類型如表18所示：

                                                                                       表17 通知消息的狀態類型

通知類型	描述	值
INVALID_PAYLOAD_TYPE	無效的載荷類型	1
DOI_NOT_SUPPORTED	不支持的DOI	2
SITUATION_NOT_SUPPORTED	不支持的SITUATION	3
INVALID_COOKIE	無效的COOKIE	4
INVALID_MAJOR_VERSION	無效的主版本	5
INVALID_MINOR_VERSION	無效的微版本	6
INVALID_EXCHANGE_TYPE	無效的交換類型	7
INVALID_FLAGS	無效的標誌	8
INVALID_MESSAGE_ID	無效的消息ID	9
INVALID_PROTOCOL_ID	無效的協議號	10
INVALID_SPI	無效的SPI	11
INVALID_TRANSFORM_ID	無效的變換號	12
ATTRIBUTES_NOT_SUPPORTED	不支持的屬性	13
NO_PROPOSAL_CHOSEN	建議不被接受	14
BAD_PROPOSAL_SYNTAX	錯誤的建議語法	15
PAYLOAD_MALFORMED	錯誤的載荷格式	16
INVALID_KEY_INFORMATION	無效的密鑰信息	17
INVALID_ID_INFORMATION	無效的ID信息	18
INVALID_CERT_ENCODING	無效的證書編碼	19
INVALID_CERTIFICATE	無效的證書	20
CERT_TYPE_UNSUPPORTED	不支持的證書類型	21
INVALID_CERT_AUTHORITY	無效的證書機構	22
INVALID_HASH_INFORMATION	無效的HASH信息	23
AUTHENTICATION_FALIED	失敗的鑑別	24
INVALID_SIGNATURE	無效的簽名	25
ADDRESS_NOTIFICATION	地址通知	26
NOTIFY_SA_LIFETIME	安全聯盟生存週期通知	27
CERTFICATE_UNAVAILABLE	證書不可用	28
UNSUPPORTED_EXCHANGE_TYPE	不支持的交換類型	29
UNEQUAL_PAYLOAD_LENGTHS	錯誤的載荷長度	30
RESERVED	保留	31-8191
PRIVATE	私有	8192-16383

                                                                                             表18 通知消息的狀態類型

通知類型	值
已連接	16384
保留（將來使用）	16385-24575
特定於DOI的編碼	24576-32767
私有（將來使用）	32768-40959
保留（將來使用）	40960-65535

        SPI：在第一階段沒有這個字段。在第二階段這個字段的長度爲4個字節，其內容是接收方建議載荷中的SPI值。

        通知數據：這個字段是變長的，用於傳送通知消息類型對應的通知數據。

12.1.13 刪除載荷

        刪除載荷用於通知對方某個SA已經取消，本載荷的類型值爲12。刪除載荷的格式如下所示：

下一個載荷	保留	載荷長度
解釋域（DOI）
協議ID	SPI長度	SPI數目
安全參數索引（SPI）

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        解釋域（DOI）：這個字段的長度爲4個字節，其值爲1。

        協議ID：這個字段的長度爲1個字節，標明要刪除的SA的協議標識符。協議標識符的定義如表3所示。

        SPI長度：這個字段的長度爲1個字節，以字節爲單位標明SPI的長度。刪除第一階段的SA時該長度爲16，刪除第二階段的SA時該長度爲4。

        SPI數目：這個字段的長度爲2個字節，標明本載荷中包含的SPI數目。

        安全參數索引（SPI）：這個字段是變長的，標明被刪除SA的SPI。這個字段的長度由SPI長度字段和SPI數目字段的值決定。

12.1.14 廠商載荷

        廠商ID載荷用於傳遞廠商自定義的常量，本載荷的類型值爲13。廠商ID載荷的格式如下所示：

下一個載荷	保留	載荷長度
廠商ID（VID）

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        廠商ID（VID）：這個字段是變長的，其內容爲廠商ID串的雜湊值。

12.1.15 NAT_D載荷

        NAT_D載荷用於檢測兩個密鑰交換通信方之間是否存在NAT設備，以及檢測NAT設備的確切位置，本載荷的類型值爲20。NAT_D載荷的格式如下所示：

下一個載荷	保留	載荷長度
載荷內容

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        載荷內容：這個字段是變長的，其內容爲：

                HASH = Hash(CKY-I | CKY-R | IP | Port)

12.1.16 NAT_OA載荷

        NAT_OA載荷用於密鑰協商第二階段中，當使用傳輸模式穿越NAT時需要傳送這個載荷，本載荷的類型值爲21。NAT_OA載荷的載荷格式如下所示：

下一個載荷	保留	載荷長度
ID類型	保留2
NAT_OA數據

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        ID類型：這個字段的長度爲1個字節，其值爲表15中的ID_IPV4_ADDR的值或ID_IPV6_ADDR的值。

        保留2：這個字段的長度爲3個字節，其值爲0。

        NAT_OA數據：這個字段的值是4字節IPv4地址或16字節IPv6地址。

12.1.17 對稱密鑰載荷

        對稱密鑰載荷用於在密鑰交換第一階段時，傳遞數字信封中的對稱密鑰，本載荷的類型值爲128。對稱密鑰載荷的格式如下所示：

下一個載荷	保留	載荷長度
對稱密鑰密文

        下一個載荷：這個字段的長度爲1個字節，標識了本載荷後下一個載荷的類型。如果當前載荷是最後一個，則該字段將被置爲0。載荷類型由表1定義。

        保留：這個字段的長度爲1個字節，其值爲0。

        載荷長度：這個字段的長度爲2個字節，以字節爲單位標明包含通用載荷頭在內的整個載荷長度。

        對稱密鑰密文：這個字段的長度是可變的，其內容爲由公鑰加密的對稱密鑰。

12.2 IKE的交換過程

        IKE使用了兩個階段爲IPSec進行密鑰協商並建立SA：

• 第一階段，通信各方彼此間建立了一個已通過身份認證和安全保護的通道，即建立一個ISAKMP SA。該SA是協商雙方爲保護它們之間的通信而使用的共享策略和密鑰。用這個SA來保護IPSec SA的協商過程。一個ISAKMP SA可以用於建立多個IPSec SA。第一階段有主模式（Main Mode）和野蠻模式（Aggressive Mode）兩種IKE交換方法。
• 第二階段，用在第一階段建立的安全隧道爲IPSec協商安全服務，即爲IPsec協商具體的SA，建立用於最終的IP數據安全傳輸的IPSec SA。IPSec SA是爲保護它們之間的數據通信而使用的共享策略和密鑰。

        交換使用標準ISAKMP載荷語法、屬性編碼、消息的超時和重傳以及通知消息。        

        安全聯盟SA採用的載荷封裝形式爲：變換載荷封裝在建議載荷中，建議載荷封裝在安全聯盟載荷中。本規範不限制發起方可以發給響應方的提議數量，如果第一階段交換中有多個變換載荷，應將多個變換載荷封裝在一個建議載荷中，然後再將它們封裝在一個安全聯盟載荷中。有關變換載荷、建議載荷、安全聯盟載荷等的具體定義見12.1。

        在安全聯盟的協商期間，響應方不能修改發起方發送的任何提議的屬性。否則，交換的發起方應終止協商。

圖4 主模式交換過程

        如圖4所示，第一階段主模式的IKE協商過程中包含三對消息：

• 第一對叫SA交換，是協商確認有關安全策略的過程；
• 第二對消息叫密鑰交換，交換Diffie-Hellman公共值和輔助數據（如：隨機數），密鑰材料在這個階段產生；
• 最後一對消息是ID信息和認證數據交換，進行身份認證和對整個第一階段交換內容的認證。

第一階段-主模式

        主模式是一個身份保護的交換，其交換過程由6個消息組成。雙方身份的認證採用數字證書的方式。本階段涉及的消息頭及載荷的具體內容見12.1。

消息序列	發起方i	方向	響應方R
1	HDR, SA	---->
2		<----	HDR, SA,CERT_sig_r,CERT_enc_r
3	HDR, XCHi, SIGi	---->
4		<----	HDR, XCHr, SIGr
5	HDR*, HASHi	---->
6		<----	HDR*, HASHr

        消息1  發起方向響應方發送一個封裝有建議載荷的安全聯盟載荷，而建議載荷中又封裝有變換載荷。

        消息2  響應方發送一個安全聯盟載荷以及響應方的簽名證書和加密證書，該載荷表明它所接受的發起方發送的SA提議。

        消息3和4  發起方和響應方交換數據，交換的數據內容包括nonce、身份標識（ID）等載荷。Nonce是生成加密密鑰和認證密鑰所必需的參數；ID是發起方或響應方的標識。這些數據使用臨時密鑰Sk進行加密保護，Sk用對方加密證書中的公鑰加密保護，最後，雙方各自對數據進行數字簽名後再加密。當使用SM2算法進行加密和數字簽名時，見GM/T 0009；當使用RSA算法進行加密和數字簽名時，見PKCS#1。

        發起方交換的數據如下：

        XCHi = Asymmetric_Encrypt(Ski, pub_r) | Symmetric_Encrypt(Ni,Ski) |  Symmetric_Encrypt(IDi,Ski)|CERT_sig_i|CERT_enc_i

        SIGi_b = Asymmetric_Sign(Ski_b | Ni_b | IDi_b | CERT_enc_i_b, priv_i)

        響應方交換的數據如下：

        XCHr = Asymmetric_Encrypt(Skr, pub_i) | Symmetric_Encrypt(Nr,Skr) | Symmetric_Encrypt(IDr,Skr)

        SIGr_b = Asymmetric_Sign(Skr_b | Nr_b | IDr_b|CERT_enc_r_b, priv_r)

        上述過程中使用的非對稱密碼算法、對稱密碼算法和密碼雜湊算法均由消息1和消息2確定。臨時密鑰Sk由發起方和響應方各自隨機生成，其長度應符合對稱密碼算法對密鑰長度的要求。

        對稱密碼運算使用CBC模式，第一個載荷的IV值爲0；後續的IV使用前面載荷的最後一組密文。

        加密前的交換數據應進行填充，使其長度等於對稱密碼算法分組長度的整數倍。所有的填充字節的值除最後一個字節外都是0，最後一個填充字節的值爲不包括它自己的填充字節數。

        Idi和Idr的類型應使用ID_DER_ASN1_DN。

        如果對方證書已經在撤銷列表中，系統應發送INVALID_CERTIFICATE通知消息。

        消息3和消息4交互完成後，參與通信的雙方生成基本密鑰參數SKEYID，以生成後續密鑰SKEYID_d、SKEYID_a、SKEYID_e，計算方法分別如下：

        SKEYID = PRF(Hash(Ni_b | Nr_b), CKY-I | CKY-R)

        SKEYID_d = PRF(SKEYID, CKY-I | CKY-R | 0)   作爲階段2生成KEY的材料

        SKEYID_a = PRF(SKEYID, SKEYID_d | CKY-I | CKY-R | 1)  用來ISAKMP包完整性用的key

        SKEYID_e = PRF(SKEYID, SKEYID_a | CKY-I | CKY-R | 2) 用來加密ISAKMP包的key

        上述計算公式中的值0，1，2是單個字節的數值。

        SKEYID_e 是ISAKMP SA用來保護其消息機密性所使用的工作密鑰。SKEYID_a 是ISAKMP SA用來驗證其消息完整性以及數據源身份所使用的工作密鑰。SKEYID_d 用於會話密鑰的產生。

        所有SKEYID的長度都由PRF函數的輸出長度決定。如果PRF函數的輸出長度太短，不能作爲一個密鑰來使用，則SKEYID_e應進行擴展。例如，HMAC hash的一個PRF可產生128比特的輸出，但密碼算法要求用到大於128比特的密鑰的時候，SKEYID_e就需要利用反饋及連接方法加以擴展，直到滿足對密鑰長度的要求爲止。反饋及連接方法如下：

        K = K1 | K2 | K3…

        K1 = PRF(SKEYID_e, 0)

        K2 = PRF(SKEYID_e, K1)

        K3 = PRF(SKEYID_e, K2)

        …

        最後從K的起始位置開始取密碼算法的密鑰所需要的位數。

        消息5和6發起方和響應方認證前面的交換過程。這兩個消息中傳遞的信息使用對稱密碼算法加密。對稱密碼算法由消息1和消息2確定，密鑰使用SKEYID_e。對稱密碼運算使用CBC模式，初始化向量IV是消息3中的Ski和消息4中的Skr串連起來經過hash運算得到的，即：

        IV= Hash(Ski_b | Skr_b)

Hash算法由消息1和消息2確定。

        加密前的消息應進行填充，使其長度等於對稱密碼算法分組長度的整數倍。所有的填充字節的值都是0。報頭中的消息長度應包括填充字節的長度，因爲這反映了密文的長度。

        爲了認證交換，發起方產生HASH_I，響應方產生HASH_R，計算公式如下：

        HASH_I = PRF(SKEYID, CKY-I | CKY-R | SAi_b | IDi_b )

        HASH_R = PRF(SKEYID, CKY-R | CKY-I | SAi_b | IDr_b )

 

        野蠻模式交換與主模式交換的主要差別在於，野蠻模式不提供身份保護，只交換3條消息。在對身份保護要求不高的場合，使用交換報文較少的野蠻模式可以提高協商的速度；在對身份保護要求較高的場合，則應該使用主模式。

 

第二階段-快速模式

        快速模式交換依賴於第一階段主模式交換，作爲IPSec SA協商過程的一部分協商IPSec SA的安全策略並衍生會話密鑰。快速模式交換的信息由ISAKMP SA來保護，即除了ISAKMP頭外所有的載荷都要加密（使用SKEYID_e密鑰加密）。在快速模式中，一個HASH載荷應緊跟在ISAKMP頭之後，這個HASH用於消息的完整性校驗以及數據源身份驗證。

        在第二階段，載荷的加密使用對稱密碼算法的CBC工作模式，第1個消息的IV是第一階段的最後一組密文和第二階段的MsgID進行hash運算所得到的，即：

        IV= Hash(第一階段的最後一組密文 | MsgID)

後續的IV是前一個消息的最後一組密文。消息的填充和第一階段中的填充方式一樣。

        在ISAKMP頭中的MsgID唯一標識了一個正在進行中的快速模式，而該ISAKMP SA本身又由ISAKMP頭中的cookies來標識。因爲快速模式的每個實例使用一個唯一的IV，這就有可能基於一個ISAKMP SA的多個快速模式在任一時間內同時進行。

        在快速模式協商中，身份標識ID缺省定義爲ISAKMP雙方的IP地址，並且沒有強制規定允許的協議或端口號。如果協商雙方需要指定ID，則雙方的身份應作爲IDi和IDr被依次傳遞。響應方的本地安全策略將決定是否接受對方的身份標識ID。如果發起方的身份標識ID由於安全策略或其它原因沒有被響應方所接受，則響應方應該發送一個通知消息類型爲INVALID_ID_INFORMATION (18)的通知載荷。

        在通信雙方之間有多條隧道同時存在的情況下，身份標識ID爲對應的IPSec SA標識並規定通信數據流進入對應的隧道。

        快速模式的交換過程如下：

消息序列	發起方	方向	響應方
1	HDR*, HASH(1), SA, Ni [, IDci, IDcr ]	---->
2		<----	HDR*, HASH(2), SA, Nr                                          [, IDci, IDcr ]
3	HDR*, HASH(3)	---->

        消息1  發起方向響應方發送一個雜湊載荷、一個安全聯盟載荷（其中封裝了一個或多個建議載荷，而每個建議載荷中又封裝一個或多個變換載荷）、一個nonce載荷和標識載荷。

        雜湊載荷中消息摘要的計算方法如下：

        HASH（1）= PRF（SKEYID_a，MsgID | SA | Ni [ | IDi | IDr]）

 

        消息2  響應方向發起方發送一個雜湊載荷、一個安全聯盟載荷、一個nonce載荷和標識載荷。

        雜湊載荷中消息摘要的計算方法如下：

        HASH（2）= PRF（SKEYID_a，MsgID | Ni_b |SA | Nr [ | IDi | IDr]）

 

        消息3  發起方向響應方發送一個雜湊載荷，用於對前面的交換進行認證。

       雜湊載荷中消息摘要的計算方法如下：

       HASH（3）= PRF（SKEYID_a，0 | MsgID | Ni_b | Nr_b ）

 

        最後，會話密鑰素材定義爲：

        KEYMAT = PRF(SKEYID_d, protocol | SPI | Ni_b | Nr_b)

        KEYMAT_e = PRF(KEYMAT, protocol | SPI | Ni_b | Nr_b | 0)               用於加密的會話密鑰

        KEYMAT_a = PRF(KEYMAT, KEYMAT_e | protocol | SPI | Ni_b | Nr_b | 1)         用於完整性校驗的會話密鑰

        其中，protocol和SPI從協商得到的ISAKMP建議載荷中選取。

        用於加密的會話密鑰和用於完整性校驗的會話密鑰按照算法要求的長度從KEYMAT中依次選取。先選取用於加密的會話密鑰，後選取用於完整性校驗的會話密鑰。

        當PRF函數的輸出長度小於KEYMAT需要的密鑰素材長度時，需要利用反饋及連接方法加以擴展，直到滿足對密鑰長度的要求爲止。即：

        KEYMAT = K1 | K2 | K3 | ...

        其中：

        K1 = PRF(SKEYID_d, protocol | SPI | Ni_b | Nr_b)

        K2 = PRF(SKEYID_d, K1 | protocol | SPI | Ni_b | Nr_b)

        K3 = PRF(SKEYID_d, K2 | protocol | SPI | Ni_b | Nr_b)

        …

        單個SA協商產生兩個安全聯盟—— 一個入，一個出。每個SA（一個由發起方選擇，另一個由響應方選擇）的不同的SPI保證了每個方向都有一個不同的KEYMAT。由SA的目的地選擇的SPI，被用於衍生該SA的KEYMAT。

 

ISAKMP信息交換

        如果ISAKMP安全聯盟已經建立，則ISAKMP信息交換過程如下所示：

發起方	方向	響應方
HDR*, HASH(1), N/D	---->

        其中N/D是一個ISAKMP通知載荷，或是一個ISAKMP刪除載荷。HASH(1)的計算方法爲：

        HASH(1) = PRF(SKEYID_a, MsgID | N/D)

        其中，MsgID不能與同一個ISAKMP SA保護的其他第二階段交換的MsgID相同。

        這個消息的加密使用對稱密碼算法的CBC工作模式，其密鑰使用SKEYID_e，初始化向量IV是第一階段的最後一組密文和MsgID進行hash運算所得到的，即：

        IV= Hash(第一階段的最後一組密文 | MsgID)

        消息的填充和第一階段中的填充方式一樣。

 

        如果ISAKMP安全關聯在信息交換時還沒有建立，則消息以明文發送，即：

發起方	方向	響應方
HDR, N	---->

 

 

 

12.3 NAT穿越

        IPSec穿越NAT特性讓IPSec數據流能夠穿越網絡中的NAT設備。NAT穿越由3個部分組成：首先判斷通信的雙方是否支持NAT穿越，其次檢測雙方之間的路徑上是否存在NAT，最後決定如何使用UDP封裝來處理NAT穿越。

        實現NAT穿越的NAT_D載荷分別添加在第一階段交換過程中消息3和消息4的載荷之後，這些載荷是獨立的，不參與交換過程的所有密碼運算。支持NAT穿越的第一階段交換過程如下：

消息序列	發起方	方向	響應方
1	HDR,SA, VID	---->
2		<----	HDR, SA, VID
3	HDR, XCHi, SIGi, NAT_D, NAT_D	---->
4		<----	HDR, XCHr, SIGr,NAT_D, NAT_D
5	HDR*#，HASHi	---->
6		<----	HDR*#，HASHr

                                                                  #標誌說明如果NAT存在，這些包將被髮送到修改後的端口。

        如果需要，NAT_OA載荷分別添加在第二階段交換過程中消息1和消息2的載荷之後，同第二階段的消息載荷一起參與密碼運算。

        實現 NAT穿越的處理過程和消息格式按RFC3947的規定執行。

13. IEK在IPSec中的作用

• 因爲有了IKE，IPSec很多參數（如：密鑰）都可以自動建立，降低了手工配置的複雜度。
• IKE協議中的DH交換過程，每次的計算和產生的結果都是不相關的。每次SA的建立都運行DH交換過程，保證了每個SA所使用的密鑰互不相關。
•  IPSec使用AH或ESP報文頭中的序列號實現防重放。此序列號是一個32比特的值，此數溢出後，爲實現防重放，SA需要重新建立，這個過程需要IKE協議的配合。
• 對安全通信的各方身份的認證和管理，將影響到IPSec的部署。IPSec的大規模使用，必須有CA（Certificate Authority，認證中心）或其他集中管理身份數據的機構的參與。
• IKE提供端與端之間動態認證。

14. IPSec與IKE的關係

圖5 IPSec與 IKE的關係圖

       從圖5中我們可以看出IKE和IPSec的關係：

• IKE是UDP之上的一個應用層協議，是IPSec的信令協議；
• IKE爲IPSec協商建立SA，並把建立的參數及生成的密鑰交給IPSec；
• IPSec使用IKE建立的SA對IP報文加密或認證處理。