?? rfc2407.txt
字號:
AH_DES 4
注意： 所有的 mandatory-to-implement 算法被列出作為必須實現 ( 例如 AH_MD5 ) 在下列節。所有另外的算法是可選的并且可能在任何特別的應用中被實現。
4.4.3.1 AH_MD5
AH_MD5 類型指定使用 MD5的通用AH轉變。實際的保護組被決定與SA聯系表一致。通用的 MD5 轉變當前未定義。
在 IPSEC DOI 內的所有的實現必須與 Auth 一起支持 AH_MD5 ( HMAC-MD5 ) 屬性。這組被定義為 HMAC-MD5-96轉變,如在 [ HMACMD5 ] 中描述的。
與 Auth 一起的 AH_MD5 類型 ( KPDK ) 屬性指定了AH轉變 ( 密鑰 / 墊 / 數據 / 密鑰 ) 描述在 RFC-1826。
有任何另外的認證算法的 AH_MD5 的使用屬性值當前未定義。
4.4.3.2 AH_SHA
AH_SHA 類型指定使用 SHA-1的通用AH轉變。實際的保護組決定為與聯系的 SA屬性表一致。通用的 SHA 轉變當前未定義。
在 IPSEC DOI 以內的所有的實現必須與 Auth 一起支持 AH_SHA ( HMAC-SHA ) 屬性。這組被定義為描述在 [ HMACSHA ]中的 HMAC-SH A-1-96轉變。
與任何另外的認證算法屬性值一起使用的 AH_SHA當前未定義。
4.4.3.3 AH_DES
AH_ DES 類型指定使用DES的通用AH轉變。實際的保護組決定為與聯系的 SA屬性表一致。通用的DES轉變當前未定義。
IPSEC DOI定義AH_DES和Auth(DES-MAC)屬性為DES-MAC轉變。實現不需要支持這種模式.
與任何另外的認證算法屬性值一起使用的 AH_ DES當前未定義。
4.4.4 IPSEC ESP 轉變標識符
包含的安全有效負載 ( ESP ) 定義一個強制的和用于常提供數據機密可選的許多轉變。下列表格列出定義的對于 IPSEC DOI為 ISAKMP 建議有效負載的ESP 轉變標識符。
注意： 什么時候認證, 完整保護, 和重放探測被要求, 認證算法屬性必須被指定來認明適當的 ESP 保護組。例如,請求有3DES 的HMAC-MD5 認證，一個人指定 ESP_3DES屬性轉變 ID并且設置把認證算法屬性設置為HMAC-MD5。對于附加處理的要求，見節4.5 （認證算法 ）。
轉變 ID 值
------------ -----
保留 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
注意：在下列節中所有的 mandatory-to-implement 算法被列出作為必須實現 ( 例如 ESP_DES )。所有另外的算法是可選的并且可能在任何特別的應用中被實現。
4.4.4.1 ESP_DES_IV64
ESP_DES_IV64 類型指定定義在RFC-1827和使用一個 64 比特 IV中的RFC-1829 DES-CBC轉變
4.4.4.2 ESP_DES
ESP_DES 類型指定使用 DES-CBC的一個通用的 DES 轉變。實際的保護組定義得與SA屬性表一致。一個通用轉變當前未定義。
在 IPSEC DOI內的所有實現必須與 Auth ( HMAC-MD5 )一起支持ESP_DES 屬性。這組被定義為 [ DES ] 轉變,由 HMAC MD5 [ HMACMD5 ]提供認證和完整性了。
4.4.4.3 ESP_3DES
ESP_3DES 類型指定一個通用的 triple-DES 轉變。實際的保護組定義得與SA屬性表一致。通用轉變當前未定義。
在 IPSEC DOI 內的所有的實現強烈支持ESP_3DES和 Auth( HMAC-MD5 ) 屬性。這組被定義為 [ ESPCBC ] 轉變, 由 HMAC MD5 [ HMACMD5 ] 提供認證和完整性。
4.4.4.4 ESP_RC5
ESP_RC5 類型指定 定義在[ ESPCBC ]RC5 的轉變。
4.4.4.5 ESP_IDEA
ESP_IDEA 類型指定定義在 [ ESPCBC ]的IDEA轉變。
4.4.4.6 ESP_CAST
ESP_CAST 類型指定定義在 [ ESPCBC ]的CAST轉變。
4.4.4.7 ESP_BLOWFISH
ESP_BLOWFISH 類型指定定義在[ ESPCBC ]的 BLOWFISH 轉變。
4.4.4.8 ESP_3IDEA
ESP_3IDEA 類型為 triple-IDEA 保留。
4.4.4.9 ESP_DES_IV32
ESP_DES_IV32 類型指定定義在 RFC-1827和使用一 32 位的 IV 的RFC-1829 的DES-CBC轉變。
4.4.4.10 ESP_RC4
ESP_RC4 類型為 RC4 保留。
4.4.4.11 ESP_NULL
ESP_NULL類型沒有指定任何機密被 ESP 提供。當 ESP 被用于僅僅要求認證,完整性,和重放探測的通道包時，ESP_NULL被使用。
在 IPSEC DOI 內的所有實現必須支持 ESP_NULL 。ESP NULL轉變在 [ ESPNULL ]中被定義。為得到關聯ESP_NULL 使用的附加要求,見節 4.5 認證算法屬性描述。
4.4.5 IPSEC IPCOMP 轉變標識符
IP 壓縮 ( IPCOMP ) 轉變定義了能被協商為 IP 有效負載壓縮([ IPCOMP ])所提供的可選壓縮算法 。下列表列出已定義的IPCOMP 內,為 ISAKMP 建議有效負載轉變標識符
IPSEC DOI
轉變 ID 值
------------ -----
保留 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1 IPCOMP_OUI
IPCOMP_OUI 類型指定專利的壓縮轉變。IPCOMP_OUI類型必須由進一步認明特定供應商算法的屬性伴隨。
4.4.5.2 IPCOMP_DEFLATE
IPCOMP_DEFLATE 類型指定“ zlib ”縮小算法的使用如在 [ 降低 ]中指定。
4.4.5.3 IPCOMP_LZS
IPCOMP_LZS 類型指定 Stac電子學 LZS 算法的使用如在[ LZS ]中指定的。
4.5 IPSEC 安全關聯屬性
下列 SA 屬性定義被使用在一個 IKE 協商的相 II。屬性類型可以是基本 (B) 或可變的長度 (V) 。這些屬性編碼被定義在基層的 ISAKMP說明中。
描述為基本的屬性不能被編碼為變量。如果他們的值適合在兩個字節中，可變的長度屬性可以被編碼為基本屬性。屬性上關于IPSEC DOI的進一步信息編碼見[ IKE ]。列出在 [ IKE ]的所有限制也適用于 IPSEC DOI。
屬性類型
類 值 類型
-------------------------------------------------
SA 生命類型 1 B
SA 生命持續時間 2 V
組描述 3 B
封裝模式 4 B
認證算法 5 B
密鑰長度 6 B
密鑰 Rounds 7 B
壓縮字典大小 8 B
壓縮私人的算法 9 V
類值
SA 生命類型
SA 持續時間
為了全面安全關聯而指定生命時間。當 SA 到期時，在關聯下面協商所有的密鑰( AH或 ESP ) 必須重新協商。生命類型值是：
保留 0
第二 1
K 字節 2
值 3-61439 被保留到 IANA中 。值 61440-65535 為私有使用。對于一種給定的生命類型，生命持續時間屬性的值定義了部件一生的實際長度--或很多秒，或能被保護的很多 Kbytes 。
如果未特別指出，缺省值將被假定為28800 秒 ( 8小時 ) 。
SA 生命持續時間屬性必須總是遵從描述持續時間單位的SA 生命類型。
對于一生通知聯系的附加信息見節 4.5.4 。
組描述
指定在一個 PFS QM 協商被使用的Oakley 組。關于支持值的列表，見附錄一的 [ IKE ] 。
封裝模式
保留 0
隧道 1
運輸 2
值 3-61439 被保留到 IANA 。值 61440-65535 為私人使用。
如果未特別指出，缺省值將被假定為未特別指出 ( 主機依賴 ) 。
認證算法
保留 0
HMAC-MD5 1
HMAC-SHA 2
DES-MAC 3
KPDK 4
值 5-61439 被保留到 IANA 。值 61440-65535 為私人使用。
當它必須被指定來正確的認明適用的AH或 ESP 轉變時, Auth 算法沒有缺省值, 除了在下列情況中。
當協商的ESP時， Auth 算法屬性不能被包括在建議中。
當協商沒有機密的ESP時， Auth 算法屬性必須被包括在建議中并且ESP轉變的 ID 必須是 ESP_NULL 。
密鑰的長度
保留 0
密鑰長度沒有缺省值, 如它必須為使用可變密鑰長度的密碼轉變而被指定。對于固定長度的密碼，密鑰長度屬性不能被傳送。
密鑰的 Rounds
保留 0
密鑰的 Rounds 沒有缺省值, 如它必須為使用rounds 變化數字密碼的轉變被指定。
壓縮字典大小
保留 0
指定log2為字典大小的最大值。
字典大小沒有缺省值。
壓縮私人算法
指定私人供應商壓縮算法。首先的 3 ( 3 ) 字節必須是被分配了的company_id 的一個 IEEE ( OUI ) 。下一個字節可以是供應商特定的壓縮子類型,跟隨著供應商零或更多字節的數據。
4.5.1 要求的屬性支持
保證基本的互操作性, 所有的實現必須準備協商下列所有屬性。
SA 生命類型
SA 持續時間
Auth 算法
4.5.2 分析要求的屬性 ( 一生)
允許靈活的語義, IPSEC DOI 要求一個遵守 ISAKMP 的實現必須正確分析包含相同屬性類多重例子的屬性表，只要不同的屬性入口不與對方沖突。當前, 要求處理的唯一屬性是生命類型和持續時間。
為了知道這為什么重要, 下列例子顯示一個二進制 4 入口編碼指定 100MB 或 24 小時的 SA 一生的屬性表。（見節 3.3 [ISAKMP ] 為屬性的完全描述編碼格式。）
屬性 #1 ：
0x80010001 （ AF = 1 , 類型 = SA 生命類型, 值 = 秒）
屬性 #2 ：
0x00020004 ( AF = 0 , 類型 = SA 持續時間, 長度 = 4個字節 ) 0x00015180 值 = 0x15180 =86400 秒 = 24 小時)
屬性 #3 ：
0x80010002 （ AF = 1 , 類型 = SA 生命類型, 值 = KB ）
屬性 #4 ：
0x00020004 ( AF = 0 , 類型 = SA 持續時間, 長度 = 4個字節 ) 0x000186A0 ( 值 = 0x186A0 =100000KB = 100MB )
如果沖突屬性被檢測到, ATTRIBUTES-NOT-SUPPORTED 通知有效負載應該被返回并且安全關聯安裝必須被放棄。
4.5.3 屬性協商
如果實現收到一個它不支持的定義了的 IPSEC DOI 屬性 ( 或屬性值 ), 一個 ATTRIBUTES-NOT-SUPPORT 應該被發送并且安全關聯安裝必須被放棄的，除非屬性值在保留的范圍內。
如果實現在保留范圍收到屬性值，實現可能選擇繼續基于本地的策略。
4.5.4 一生通知
當一個開始者提供比應答者基于他們的本地的策略所需的大的 SA一生時，應答者有 3種選擇： 1 )協商全部失敗; 2 ) 完成協商但是使用比被提供的更短的一生; 3 ) 完成協商并且送一份建議通知到顯示應答者真實一生的開始者。應答者實際上做的選擇是實現特定的或基于本地的策略。
在后者情況中保證互操作性, 當應答者希望通知開始者時， IPSEC DOI 僅僅要求下列：如果開始者提供的 SA 一生與應答者愿意接受的長，應答者應該在包括應答者 IPSEC SA 有效負載的交換包括 ISAKMP 通知的有效負載。節 4.6.3.1 為必須被用于這個目的消息類型的RESPONDER-LIFETIME 通知定義有效負載布局。
4.6 IPSEC 有效負載內容
下列節描述其數據表示依賴于適用的 DOI 的那些 ISAKMP 有效負載。
4.6.1 安全關聯有效負載
下列圖表為 IPSEC DOI 說明安全關聯有效負載的內容。對于狀況位圖的描述見節 4.2 。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一個有效負載！ 保留 ！ 有效負載長度 ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！ 解釋的域 ( IPSEC ） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！ 狀況 ( 位圖） ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！ 標記的域標識符 ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密長度 ( 在字節） ！ 保留 ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 秘密級別
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密連接。長度 ( 在位中 ) ！ 保留 ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 秘密范疇位圖 ~
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -