另外，IKE的實現必須支持3DES加密；用Tiger ([TIGER])作為hash；數字簽名標準，RSA[RSA]，
使用RSA公共密鑰加密的簽名和驗證；以及使用組2進行MODP。IKE實現可以支持在附錄A中
定義的其它的加密算法，并且可以支持ECP和EC2N組。
   
	當實現了IETF IPsec DOI[Pip97]時，IKE必須實現以上描述的模式。其它DOI也可使用這里描
述的模式。
5.交換
	有兩中基本方法可以用來建立經過驗證密鑰交換：主模式和積極模式。它們都通過短暫的
Diffie-Hellman交換來產生經過驗證的密鑰材料。主模式必須要實現；積極模式最好也實現。另外，
作為產生新密鑰材料和協商非ISAKMP安全服務機制的快速模式也必須要實現。另外，作為定義
Diffie-Hellman交換私有組機制的新組模式應該要實現。實現中不能在交換正在進行時改變交換類
型。
  
	交換遵從標準ISAKMP負載語法，屬性編碼，消息的超時和重傳，以及信息消息——例如，當
一個提議未被接時，或者簽名驗證或解密失敗時，一個通知響應就被發送，等等。
   
	在第一階段交換中，SA負載必須先于任何其它的負載。除了另外的通知表明在任何消息的
ISAKMP負載中沒有需要特定順序的需求。
   
	不論在第一階段還是第二階段中，在KE負載中傳遞的Diffie-Hellman公共值必須在必要時用零
填充，且長度必須為協商Diffie-Hellman組所需要的長度。
   
	當前時間（nonce）負載的長度必須在8到256個字節之間。
   
	主模式是ISAKMP身份保護交換的實現：頭兩個消息協商策略；下兩個消息交換Diffie-Hellman
的公共值和必要的輔助數據（例如：當前時間（nonce））；最后的兩個消息驗證Diffie-Hellman交換。
作為初始ISAKMP交換的驗證方法的協商影響負載的組成，而不是它們的目的。主模式的XCHG就
是ISAKMP身份保護。
   
類似的，積極模式是ISAKMP積極交換的實現。頭兩個消息協商策略，交換Diffie-Hellman公
共值以及必要的輔助數據，還有身份。另外，第二個消息還要對響應者進行驗證。第三個消息對發
起者進行驗證，并提供參與交換的證據。積極模式的XCHG就是ISAKMP的積極交換。在ISAKMP 
SA的保護下，如果需要，最后的消息可以不發送，這樣允許每一方延遲求冪的運算，直到這次交換
完成以后再運算。積極模式的圖示中顯示最后的負載以明文發送，這不是必須的。

  	IKE的交換并不是open ended，而是有固定數目的消息。證書請求負載的回執不能擴展傳輸或
期待的消息的數目。
   
	積極模式在安全聯盟協商中有一定的局限性。因為在消息構建請求中，Diffie-Hellman交換所需
要的組不能被協商。另外，不同的驗證方法可能進一步限制屬性的協商。例如，利用公共密鑰加密
的驗證就不能被協商，同時，當使用修改過的公共密鑰加密方法來驗證時，密碼和hash又不能被協
商。當要利用IKE能協商大量屬性的能力時，就需要使用主模式了。
   
	快速模式和新組模式在ISAKMP中沒有與之對應的。它們的XCHG的值在附錄A中定義。
  
	主模式，積極模式，以及快速模式進行安全聯盟的協商。安全聯盟的建議（offer）采取下列形
式：轉換（transform）負載封裝在提議（proposal）負載中，而提議負載又封裝在安全聯盟（SA）負
載中。第一階段交換（主模式和積極模式）中如果多個建議提出，則必須采取下列形式：多個轉換
（transform）負載封裝在一個提議（proposal）負載中，然后它們又封裝在一個SA負載中。對第一
階段交換可以換種方式來表述：在單個SA負載中，不能有多個提議負載，同時，也不允許有多個
SA負載。本文檔并不禁止在第二階段的交換中出現這些形式。
   
	本來發起者發送給響應者的建議（offer）的數量是沒有限制的，但出于性能考慮，實現中可以
選擇限制將進行檢查的建議（offer）的數量。
   
	在安全聯盟的協商中，發起者向響應者提出可能的安全聯盟的建議（offer）。響應者不能修改任
何建議的屬性，除了屬性的編碼（參看附錄A）。如果交換的發起者注意到屬性值被修改了，或者有
屬性在建議中被增加或刪除了，則這個響應必須廢棄。
   
	主模式或積極模式中都允許四種不同的驗證方法——數字簽名，公共密鑰加密的兩種驗證形式，
或者共享密鑰。對每種驗證方法要分別計算SKEYID值。
     
	對于數字簽名：SKEYID = prf(Ni_b | Nr_b, g^xy)
	對于公共密鑰加密：SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)
	對于共享密鑰：SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
   
不論是主模式還是積極模式，結果都是產生三組經過驗證的密鑰材料：
      SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
以及達成了用于保護通信的一致的策略。上面的值0，1，2由單個字節的值來代表。用于加密的密
鑰值根據具體的算法（參看附錄B）從SKEYID_e中衍生出來。
  
    為了驗證交換中的雙方，協議的發起者產生HASH_I，響應者產生HASH_R，其中：
    HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
    HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
 
	對于使用數字簽名的驗證，HASH_I和HASH_R是經過簽名并效驗的；對于使用公共密鑰加密
驗證或共享密鑰的驗證，HASH_I和HASH_R直接驗證交換。整個ID負載（包括ID類型，端口，
協議，但通用報頭除外）被hash計算進HASH_I和HASH_R。
   
	正如上面提到的，所協商的驗證方法影響第一階段模式的消息內容和使用，但不影響它們的目
的。當使用公共密鑰來驗證時，第一階段的交換可以使用簽名或使用公鑰加密（如果算法支持）來
完成。下面是使用不同的驗證選項的第一階段交換。
5.1 使用簽名來驗證的IKE第一階段
   
使用簽名，在第二個傳輸往返中交換的輔助信息是當前時間（nonce）；通過對相互可以得到的
hash值進行簽名來對交換進行驗證。使用簽名驗證的主模式描述如下：
        發起者                          響應者
       -----------                        -----------
        HDR, SA                     -->
                                    <--    HDR, SA
        HDR, KE, Ni                 -->
                                    <--    HDR, KE, Nr
        HDR*, IDii, [ CERT, ] SIG_I -->
                                    <--    HDR*, IDir, [ CERT, ] SIG_R
和ISAKMP相關聯的帶簽名的積極模式描述如下：
        發起者                         響應者
       -----------                        -----------
        HDR, SA, KE, Ni, IDii       -->
                                    <--    HDR, SA, KE, Nr, IDir,
                                                [ CERT, ] SIG_R
        HDR, [ CERT, ] SIG_I        -->

   
	兩種模式中，簽名的數據——SIG_I或SIG_R是協商的數字簽名算法分別應用到HASH_I或
HASH_R所產生的結果。
   
	總的來說，就象上面說明的一樣，簽名使用協商的prf，或協商的HMAC hash函數（如果沒有
協商prf）來對HASH_I和HASH_R簽名。但是，如果簽名算法綁定于特定的hash算法（如DSS只
定義使用SHA 160位的輸出），則簽名的構建會有不同。在這種情況下，簽名仍然將象上面一樣覆
蓋HASH_I和HASH_R，但使用和簽名方法向關聯的HMAC hash算法。協商的prf和hash函數將
被用作其它指定的偽隨機函數。
  
	既然使用的hash算法已知，就沒有必要將它的OID也編碼到簽名之中。另外，在PKCS#1的
RSA簽名中使用的OID和本文檔中使用的OID之間沒有關聯。所以，RSA簽名在PKCS#1格式中
必須被作為私有密鑰加密來編碼，而不是作為PKCS#1格式（它包括hash算法的OID）中的簽名。
DSS簽名必須作為r后跟s來編碼。
  
	一或多個證書負載在傳遞中是可選的。
5.2	使用公共密鑰加密的第一階段驗證
  
	使用公共密鑰加密來驗證交換，交換的輔助信息是加密的當前時間（nonce）。每一方重新構建
hash（如果另一方能解密當前時間（nonce））的能力就驗證了交換。
   
	要執行公鑰加密，發起者必須已經擁有響應者的公鑰。當響應者有多個公鑰時，發起者用來加
密輔助信息的證書的hash值也作為第三個消息傳遞。通過這種方式，響應者可以確定使用哪一個對
應的私鑰來解密加密了的負載，同時也保持了身份保護功能。
   
	除了當前時間（nonce）外，雙方的身份（IDii和IDir）也使用對方的公鑰進行加密。如果驗證
方法是公鑰加密，則當前時間（nonce）和身份負載必須使用對方的公鑰加密。只有負載的數據部分
進行了加密，而負載的報頭仍為明文形式。
  
當使用加密作為驗證時，主模式定義如下：
        發起者                       響應者
       -----------                      -----------
        HDR, SA                   -->
                                  <--    HDR, SA
        HDR, KE, [ HASH(1), ]
          <IDii_b>PubKey_r,
            <Ni_b>PubKey_r        -->
                                         HDR, KE, <IDir_b>PubKey_i,
                                  <--            <Nr_b>PubKey_i
        HDR*, HASH_I              -->
                                  <--    HDR*, HASH_R
積極模式使用加密作為驗證的描述如下：
        發起者                       響應者
       -----------                      -----------
        HDR, SA, [ HASH(1),] KE,
          <IDii_b>Pubkey_r,
           <Ni_b>Pubkey_r         -->
                                         HDR, SA, KE, <IDir_b>PubKey_i,
                                  <--         <Nr_b>PubKey_i, HASH_R
        HDR, HASH_I               -->

   
其中HASH（1）是發起者用于加密當前時間（nonce）和身份的證書的hash（使用協商的hash
函數）。
  
	RSA加密必須被編碼進PKCS#1格式中。當只有ID和當前時間（nonce）負載的數據部分要加
密時，加密的數據前必須有一個有效的ISAKMP通用報頭。負載的長度是整個加密負載加上報頭的
長度。PKCS#1編碼可以不用解密而確定明文負載的實際長度。
   
	使用加密來驗證提供了可信的可拒絕交換。沒有證據（使用數字簽名）表明通信曾經發生過，
因為每一方都可以完全重新構建交換的兩方。另外，秘密的產生也增加了安全，因為襲擊者不僅不
得不破解Diffie-Hellman交換，還要破解RSA加密。這種交換由[SKEME]提出。
   
	注意，與其它的驗證方法不一樣，公鑰加密驗證允許積極模式有身份保護。
5.3	使用修改過的公鑰加密模式來進行第一階段的驗證
   
	使用公鑰加密來進行驗證比簽名驗證（參看5.2節）有更大的優點。不幸的是，這需要4個公
鑰操作為代價——兩個公鑰加密和兩個私鑰解密。而修改過的驗證模式保持了使用公鑰加密來驗證
的優點，但只需要一半的公鑰操作。
   
	在這種模式中，當前時間（nonce）仍然使用雙方的公鑰進行加密，但雙方的身份（以及證書）
使用協商的對稱加密算法（從SA負載中獲得）來加密，其密鑰是從當前時間（nonce）中衍生而來。
這種解決方案增加最少的復雜性和狀態，而在每一方節省了兩個公鑰操作。另外，密鑰交換（KE）
負載也使用同一個衍生的密鑰進行加密。這為對Diffie-Hellman交換進行密碼分析而提供了額外的保
護。
   
	使用公鑰加密的驗證方法（5.2節 ），如果響應者有多個證書包含可用的公鑰（例如，如果證書
不只是用于簽名，也不受證書限制或算法限制），可以發送HASH負載來標識證書。如果HASH負
載被發送，他必須是第二個消息交換的第一個負載，同時必須后跟加密的當前時間（nonce）。如果
HASH負載沒有發送，第二個消息交換的第一個負載必須是加密的當前時間（nonce）。另外，發起
者可以可選的發送證書負載，以提供一個公鑰給響應者進行響應時使用。
   
當使用修改過的加密模式來驗證時，主模式定義如下：
        發起者                       響應者
       -----------                      -----------
        HDR, SA                   -->
                                  <--    HDR, SA
        HDR, [ HASH(1), ]
          <Ni_b>Pubkey_r,
          <KE_b>Ke_i,
          <IDii_b>Ke_i,
          [<<Cert-I_b>Ke_i]       -->
                                         HDR, <Nr_b>PubKey_i,
                                              <KE_b>Ke_r,
                                  <--         <IDir_b>Ke_r,
        HDR*, HASH_I              -->
                                  <--    HDR*, HASH_R

  積極模式使用修改的加密方法來驗證的描述如下：
        發起者                       響應者
       -----------                      -----------
        HDR, SA, [ HASH(1),]
          <Ni_b>Pubkey_r,
          <KE_b>Ke_i, <IDii_b>Ke_i
          [, <Cert-I_b>Ke_i ]     -->
                                         HDR, SA, <Nr_b>PubKey_i,
                                              <KE_b>Ke_r, <IDir_b>Ke_r,
                                  <--         HASH_R
        HDR, HASH_I               -->
	其中HASH（1）和5.2節相同。Ke_i和Ke_r是在SA負載交換中協商的對稱加密算法的密鑰。
只有負載的數據部分加密（公鑰和對稱密鑰操作中都一樣），通用的負載的報頭保持明文形式。包含