5.1 密鑰交換協議

5.1.1 概述

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

本章節用到的符號如下：

• HDR：一個ISAKMP頭。

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

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

• IDi：發起方的標識載荷。

• IDr：響應方的標識載荷。

• HASHi：發起方的雜湊載荷。

• HASHr：響應方的雜湊載荷。

• HASH_ < n > ：雙方進行協商交互時的中間Hash數據。

• SIGi：發起方的簽名載荷。

• SIGr：響應方的簽名載荷。

• CERT_sig_r：簽名證書載荷。

• CERT_enc_r：加密證書載荷。

• MsgID：消息標識號。

• 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的通用載荷頭和密文串接。 如SM2_Encrypt(Ski, pub_key)表示使用SM2算法，使用公鑰pub_key對Ski_b進行加密，其輸出為Ski的通用載荷頭和密文串接。

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

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

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

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

5.1.2 交換階段及模式

密鑰交換協議包括第一階段和第二階段。

在第一階段交換中，通信雙方建立了一個ISAKMP安全聯盟。該安全聯盟是協商雙方為保護它們之間的通信而使用的共享策略和密鑰。用這個安全聯盟來保護IPSec安全聯盟的協商過程。一個ISAKMP安全聯盟可以用于建立多個IPSec安全聯盟。該階段使用主模式實現通信雙方的身份鑒別和密鑰交換，得到工作密鑰，該工作密鑰用于保護第二階段的協商過程。

在第二階段交換中，通信雙方使用第一階段ISAKMP安全聯盟協商建立IPSec安全聯盟，IPSec安全聯盟是為保護它們之間的數據通信而使用的共享策略和密鑰。該階段使用快速模式實現通信雙方IPSec安全聯盟的協商，確定通信雙方的IPSec安全策略及會話密鑰。

5.1.3 交換

5.1.3.1 概述

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

SA載荷采用的載荷封裝形式為：變換載荷封裝在建議載荷中，建議載荷封裝在SA載荷中。本標準不限制發起方可以發給響應方的提議數量，如果第一階段交換中有多個變換載荷，應將多個變換載荷封裝在一個建議載荷中，然后再將它們封裝在一個SA載荷中。安全關聯的定義參見附錄A，有關變換載荷、建議載荷、SA載荷等的具體定義見5.1.5。

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

5.1.3.2 第一階段——主模式

主模式是一個身份保護的交換，其交換過程由6個消息組成。雙方身份的鑒別采用數字證書的方式。

本階段涉及的消息頭及載荷的具體內容見5.1.5。

主模式的交換過程如下：

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

消息2 響應方發送一個SA載荷以及響應方的簽名證書和加密證書，該載荷表明它所接受的發起方發送的SA提議。SA載荷的具體內容見5.1.5.6。

消息3和消息4 發起方和響應方交換數據，交換的數據內容包括nonce、身份標識（ID）等載荷。Nonce是生成加密密鑰和認證密鑰所必需的參數；ID是發起方或響應方的標識。這些數據使用臨時密鑰Sk進行加密保護，Sk用對方加密證書中的公鑰加密保護，并且，雙方各自對數據進行數字簽名。使用SM2算法進行加解密和數字簽名驗簽的具體要求見GB/T 35276。

發起方交換的數據如下：

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)

SKEYID_a = PRF(SKEYID, SKEYID_d | CKY-I | CKY-R | 1)

SKEYID_e = PRF(SKEYID, SKEYID_a | CKY-I | CKY-R | 2)

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

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

所有SKEYID的長度都由PRF函數的輸出長度決定。如果PRF函數的輸出長度太短，不能作為一個密鑰來使用，則SKEYID_e應進行擴展。例如，HMAC的一個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。報頭中的消息長度應包括填充字節的長度，因為這反映了密文的長度。

為了鑒別交換，發起方產生HASHi，響應方產生HASHr，計算公式如下：

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

HASHr = PRF(SKEYID, CKY-R | CKY-I | SAr_b | IDr_b )

5.1.3.3 第二階段——快速模式

快速模式交換依賴于第一階段主模式交換，作為IPSec SA協商過程的一部分協商IPSec SA的安全策略并衍生會話密鑰。快速模式交換的信息由ISAKMP SA來保護，即除了ISAKMP頭外所有的載荷都要加密。在快速模式中，一個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標識并規定通信數據流進入對應的隧道。

本階段涉及的消息頭及載荷的具體內容見5.1.5。

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

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

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

HASH_1 = PRF（SKEYID_a，MsgID | Ni_b | SA [ | IDi | IDr]）

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

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

HASH_2 = PRF（SKEYID_a，MsgID | Ni_b |SA | Nr_b [ | IDi | IDr]）

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

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

HASH_3 = PRF（SKEYID_a，0 | MsgID | Ni_b | Nr_b ）

最后，會話密鑰素材定義為：

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

其中，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。

5.1.3.4 ISAKMP信息交換

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

其中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安全關聯在信息交換時還沒有建立，則消息以明文發送，即：

5.1.4 NAT穿越

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

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

注：#標志說明如果NAT存在，這些包將被發送到修改后的端口。

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

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

5.1.5 密鑰交換的載荷格式

5.1.5.1 消息頭格式

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

ISAKMP的頭格式如圖1所示：

圖1 ISAKMP頭格式

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

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

Cookie的生成方法應建議依據RFC2408 2.5.3要求生成。

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

表1 載荷類型的定義

表1 載荷類型的定義（續）

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

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

表2 交換類型的定義

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

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

00001—— 加密比特：這是標志字段中的最低有效比特。當這個比特被置為1時，該消息頭后面所有的載荷都采用ISAKMP SA中指定的密碼算法加密。當這個比特被置為0時，載荷不加密。

00002—— 提交比特：這是標志字段的第2個比特，本標準中其值為0。

00003—— 僅鑒別比特：這是標志字段的第3個比特，本標準中其值為0。

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

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

5.1.5.2 通用載荷頭

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

圖2 通用載荷頭格式

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

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

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

5.1.5.3 SA載荷

SA載荷用于協商安全關聯，并且指定協商所基于的解釋域DOI。載荷的格式依賴于他使用的DOI，本載荷的類型值為1。SA載荷的格式如圖3所示：

圖3 SA載荷格式

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

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

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

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

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

00004—— SIT_IDENTITY_ONLY：其值為1。表明SA將由一個相關的標識載荷中的源標識信息來標識。

00005—— SIT_SECRECY：其值為2。表明SA正在一個需經標記的秘密的環境中協商。

00006—— SIT_INTEGRITY：其值是4。表明SA正在一個須經標記的完整性環境中協商。

本標準默認采用SIT_IDENTITY_ONLY情形。

5.1.5.4 建議載荷

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

圖4 建議載荷格式

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

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

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

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

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

表3 協議標識符的定義

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

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

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

5.1.5.5 變換載荷

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

圖5 變換載荷格式

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

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

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

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

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

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

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

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

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

5.1.5.6 SA屬性載荷

SA屬性載荷只能用于變換載荷之后，并且沒有通用載荷頭，用于表示SA屬性的數據結構，本載荷的類型值為14。SA屬性載荷的格式如圖6所示：

圖6 SA屬性載荷格式

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

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

表6 第一階段密鑰交換屬性類型的定義

表6 第一階段密鑰交換屬性類型的定義（續）

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

表7 第二階段密鑰交換屬性類型的定義

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

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

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

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

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

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

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

表10 第一階段鑒別方式屬性值的定義

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

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

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

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

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

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

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

表14 第二階段鑒別算法屬性值的定義

5.1.5.7 標識載荷

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

圖7 標識載荷格式

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

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

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

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

表15 標識類型的定義

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

• 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類型字段相對應的標識信息。

5.1.5.8 證書載荷

證書載荷用于通信雙方交換證書以及證書相關信息，本載荷的類型值為6。

證書載荷的格式如圖8所示：

圖8 證書載荷格式

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

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

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

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

表16 證書編碼類型定義

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

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

5.1.5.9 雜湊載荷

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

圖9 雜湊載荷格式

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

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

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

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

5.1.5.10 簽名載荷

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

圖10 簽名載荷格式

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

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

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

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

5.1.5.11 Nonce載荷

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

圖11 Nonce載荷格式

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

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

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

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

5.1.5.12 通知載荷

通知載荷用于傳送通知數據，本載荷的類型值為11，通知載荷的格式如圖12所示：

圖12 通知載荷格式

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

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

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

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

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

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

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

表17 通知消息的狀態類型

表18 通知消息的狀態類型

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

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

5.1.5.13 刪除載荷

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

圖13 刪除載荷格式

下一個載荷：這個字段的長度為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數目字段的值決定。

5.1.5.14 廠商ID載荷

廠商ID載荷用于傳遞廠商自定義的常量，本載荷的類型值為13。廠商ID載荷的格式如圖14所示：

圖14 廠商ID載荷格式

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

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

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

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

5.1.5.15 NAT_D載荷

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

圖15 NAT_D載荷格式

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

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

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

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

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

5.1.5.16 NAT_OA載荷

NAT_OA載荷用于密鑰交換第二階段中，當使用傳輸模式穿越NAT時需要傳送這個載荷，本載荷的類型值為21。NAT_OA載荷的載荷格式如圖16所示：

圖16 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地址。

5.1.5.17 對稱密鑰載荷

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

圖17 對稱密鑰載荷格式

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

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

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

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

5.1.6 密鑰交換的數據包格式

5.1.6.1 概述

密鑰交換消息是基于UDP傳輸的，使用UDP 500端口或者4500端口。在UDP 500 端口上發送的密鑰交換消息直接跟在UDP 報頭后面。在UDP 4500 端口上發送的密鑰交換消息，需要在UDP頭與密鑰交換消息之間插入4個全0的字節。

每一條密鑰交換消息以消息頭HDR 作為開始標志。每個HDR后可以有一個或者多個載荷。如果有多個載荷，則用每一個載荷內的“下一個載荷”字段進行標識，如果“下一個載荷”字段為0，說明消息結束。

在本節的所有圖中，“下一載荷”用“NP”來表示。

5.1.6.2 主模式消息1的數據包格式

主模式消息1的數據包的格式如圖18所示，其中SA載荷中應當支持SM4-SM3變換載荷。

圖18 主模式消息1的數據包格式

圖18 主模式消息1的數據包格式（續）

5.1.6.3 主模式消息2的數據包格式

主模式消息2的數據包的格式如圖19所示。

下圖中NP代表下一載荷。

圖19 主模式消息2的數據包格式

5.1.6.4 主模式消息3的數據包格式

使用證書鑒別的主模式消息3數據包的格式如圖20所示：

圖20 主模式消息2的數據包格式

5.1.6.5 主模式消息4的數據包格式

主模式消息4數據包的格式如圖21所示：

圖21 主模式消息4的數據包格式

圖21 主模式消息4的數據包格式（續）

5.1.6.6 主模式消息5的數據包的格式

主模式消息5的數據包的格式如圖22所示：

圖22 主模式消息5的數據包格式

5.1.6.7 主模式消息6的數據的包格式

主模式消息6的數據包的格式如圖23所示：

圖23 主模式消息6的數據包格式

5.1.6.8 快速模式消息1的數據包格式

快速模式消息1的數據包的格式如圖24所示，其中SA載荷中有一個ESP協議建議，建議中有兩種變換。

圖24 快速模式消息1的數據包格式

5.1.6.9 快速模式消息2的數據包格式

快速模式消息2的數據包的格式如圖25所示，其中選擇了其中一種變換。

圖25 快速模式消息2的數據包格式

5.1.6.10 快速模式消息3的數據包格式

快速模式消息3的數據包的格式如圖26所示：

圖26 快速模式消息3的數據包格式