?? rfc2407.txt
字號:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!完整長度 ( 在字節) ! 保留 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 完整級別
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integ 。連接。長度 ( 按位) ! 保留 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 完整范疇位圖 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖 1 :安全關聯有效負載格式
安全關聯有效負載被定義如下:
o 下一個有效負載 ( 1 字節 )在消息中的下一個有效負載的有效負載類型標識符。如果當前的有效負載是在消息的最后,這域將是零 ( 0 ) 。
o 保留 ( 1 字節 )- 閑置, 必須是零 ( 0 ) 。
o 有效負載長度 ( 2 字節 )- 長度,字節,當前的有效負載,包括通用的頭。
o 解釋的域 ( 4 字節 )- 指定 IPSEC DOI , 它被分配了值一( 1 ) 。
o 狀況 ( 4 字節 )- 位掩碼過去常解釋安全關聯有效負載的剩余部分。關于值的完全表見節 4.2 。
o 標記過的域標識符 ( 4 字節 )- 被分配了數字的 IANA被用來解釋秘密和完整性信息。
o 密文長度 ( 2個字節)- 在字節上,指定秘密級別標識符長度,排除墊位。
o 保留 ( 2 個字節 )-閑置, 必須是零 ( 0 ) 。
o 秘密級別 ( 可變長度 )- 指定要求的強制秘密級別。秘密級別必須填 ( 0 ) 來在下一條 32 位邊界上排列。
o 秘密類別長度 ( 2 個字節 )- 指定長度, 按位,秘密類別 ( 分隔空間 ) 位圖, 排除墊位。
o 保留 ( 2 個字節 )- 閑置, 必須是零 ( 0 ) 。
o 秘密類別位圖 ( 可變長度 )- 一個位圖被用來指明被要求的秘密類別( 分隔空間 )。位圖必須填 ( 0 ),在下一條 32 位邊界上排列。
o 完整長度 ( 2 個字節 )- 指定長度, 按字節,完整級別標識符,排除墊位。
o 保留 ( 2 個字節 )- 閑置, 必須是零 ( 0 ) 。
o 完整級別 ( 可變長度 )- 指定要求的強制完整級別。完整級別必須填 ( 0 ) 在下一條 32 位的邊界上排列。
o 完整類別長度 ( 2 個字節 )- 指定長度, 按位,完整類別 ( 分隔空間 ) 位圖, 排除墊位。
o 保留 ( 2 字節 )- 閑置, 必須是零 ( 0 ) 。
o 完整類別位圖 ( 可變長度 )- 一個位圖被用來指明被要求的完整類別 ( 分隔空間 )。位圖必須填 ( 0 ),在下一條 32 位的邊界上排列。
4.6.1.1 IPSEC 標記了的域標識符
下列表列出標記域標識符域的分配的值,它被包含在關聯有效負載的安全狀況域中。
域 值
------ -----
保留 0
4.6.2 鑒定有效負載內容
鑒定有效負載被用來認明安全關聯的開始者。開始者的身份應該被應答者使用來決定關聯要求的正確主機系統安全策略。例如,一臺主機可能選擇沒有要求從某個集合IP 地址機密認證和完整性,和另一范圍IP 地址地完全機密性認證。鑒定有效負載提供能被應答者用來作出決定的信息。
在階段期I協商期間, ID 端口和協議域必須被設置為零或上到500 的 UDP。如果實現收到任何另外的值,這必須被當作一個錯誤并且安安全關聯裝必須被放棄。這個事件應該是 auditable 。
下列圖表說明鑒定有效負載的內容。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!下一個有效負載! 保留 ! 有效負載長度 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID 類型 !協議 ID ! 端口 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 鑒定數據 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖 2 :鑒定有效負載格式
鑒定有效負載域被定義如下:
o 下一個有效負載 ( 1 字節 )-在消息中關于下一個有效負載的有效負載類型標識符。如果當前的有效負載是消息的最后一個,這域將是零 ( 0 ) 。
o 保留 ( 1 字節 )- 閑置, 必須是零 ( 0 ) 。
o 有效負載長度 ( 2 字節 )- 長度, 按字節,鑒定數據,包括通用頭。
o 鑒定類型 ( 1 字節 )- 描述在鑒定數據域發現的身份信息值。
o 協議 ID ( 1 字節 )- 指定一個聯系的 IP 值協議 ID (例如 UDP/TCP ) 。零值意味著協議 ID 域應該被忽略。
o 端口 ( 2 字節 )- 指定一個聯系的端口值。零值意味著協議 ID 域應該被忽略。
o 鑒定數據 ( 可變長度 )- 值,如由鑒定類型顯示的。
4.6.2.1 鑒定類型值
下列表格列出了鑒定有效負載中為鑒定類型域分配的值。
ID 類型 值
------- -----
保留 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
對于ID 實體是可變長度的類型, ID實體的大小在 ID 有效負載頭中以大小被計算。
當 IKE 交換被證實使用證書時 ( 任何格式 ),任何被用來輸入到本地策略決定的Id必須被包含在交換用來認證的證書中。
4.6.2.2 ID_IPV4_ADDR
ID_IPV4_ADDR 類型指定單個 4 ( 4 ) 字節的 IPv4 地址。
4.6.2.3 ID_FQDN
ID_FQDN 類型指定一個完全合格的域名字符串。一個 ID_FQDN 例子是,“ foo.bar.com ”。字符串不能包含任何終止符。
4.6.2.4 ID_USER_FQDN
這個ID_USER_FQDN 類型指定一個有很高權限的用戶名字符串,ID_USER_FQDN的一個例子是"piper@foo.bar.com".這個字符串不應該包含任何界限。
4.6.2.5 ID_IPV4_ADDR_SUBNET
這個ID_IPV4_ADDR_SUBNET類型詳細說明IPV4地址的排列,它表現為兩個四位的八位位組值。第一個值是IPV4的地址。第二個值是IPV4的網絡面具。特別注意這個網絡面具中的ones(1s)指示的相應的位被固定,而zeros(0s)指示一個通配符位。
4.6.2.6 ID_IPV6_ADDR
這個ID_IPV6_ADDR類型指定一個單一的16位八位位組Ipv6地址。
4.6.2.7 ID_IPV6_ADDR_SUBNET
這個ID_IPV6_ADDR_SUBNET類型詳細說明Ipv6地址的排列,它被描繪為兩個16位的八位位組的值。第一個值是一個Ipv6的地址。第二個值是Ipv6的網絡面具。特別注意網絡面具中的ones(1s)指示地址中的相應位被固定,而zeros(0s)指示一個通配符位。
4.6.2.8 ID_IPV4_ADDR_RANGE
這個ID_IPV4_ADDR_RANGE類型詳細說明一個IPV4地址的排列,它表現為兩個四位的八位位組值。第一個值開始于Ipv4地址,第二值結束于IPV4的地址。在兩個指定地址中的所有地址被認為在這個列表之中。
4.6.2.9 ID_IPV6_ADDR_RANGE
這個ID_IPV6_ADDR_RANGE 類型詳細說明Ipv6地址的排列,它表現為兩個16位的八位位組值。第一個值開始于IPV6地地址,第二個值結束IPV6地址。在兩個指定地址中的所有地址被認為在這個列表之中。
4.6.2.10 ID_DER_ASN1_DN
這個ID_DER_ASN1_DN類型詳細說明二進制的DER,它是以ASN.1 X.500來編碼的,它的證書被交換來建立這個SA.
4.6.2.11 ID_DER_ASN1_GN
這個4.6.2.11 ID_DER_ASN1_GN類型詳細說明二進制的DER,它是以ASN.1 X.500來編碼的,它的證書被交換來建立SA。
4.6.2.12 ID_KEY_ID
這個ID_KEY_ID類型詳細說明不透明的字節流,它可能被用來通過指定必須的的賣主信息來鑒別哪一個共享的密鑰應被用來鑒別侵權的談判模式。
4.6.3 IPSEC通報信息類型
ISAKMP定義兩塊通報信息代碼,一個是錯誤的,另一個是狀態信息。ISAKMP也分配每塊中的一部分在DOL里作為私有用途。這個IPSEC DOI為自己的用途定義下列私有信息。
通報信息 - 錯誤類型 值
----------------------------- -----
保留的 8192
通報信息 - 狀態類型 值
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
通知狀態信息MUST送到ISAKMP SA的保護下:在最后主要交換模式里任何一個作為有效載荷;在主要模式下的分離的信息交換或侵權的模式過程是完成的;或在任何快的模式交換里作為有效載荷。這些信息不應該被送到侵權的模式交換中,因為侵權模式不提供必須的保護來約束通報狀態信息交換。
特別注意:一個通報的有效載荷僅僅在快的模式下被完全保護,在那兒整個有效載荷被包含在HASH(n)分類中。在主要模式立,當通報信息被加密了,它不是普遍的包含在這個HASH(n)分類歷。結果,在主模式密文里,一個積極的攻擊能引起通報信息類型被改動。(這是真的,一般的,對于任何主模式交換里的最后的信息)當這個風險很小時,一個跟改過的通報信息可能引起接收者中斷整個談判,他想到發送者遇到了一個致命的錯誤。
4.6.3.1 RESPONDER-LIFETIME
這個RESPONDER-LIFETIME狀態信息可能被用來協調由接受者選擇的IPSEC SA lifetime。
當它存在時,通報有效載荷應該有下列格式:
。有效載荷長度-發送有效載荷的長度+數據大小(var)
。DOI-發送到IPSEC DOI(1)
。ID協議-從選擇的SA發送到選擇的協議ID
。SPI大小-發送16(兩個eight-octet ISAKMP cookies)或4(一個IPSEC SPI)
。通報信息類型-發動RESPONDER-LIFETIME (Section 4.6.3)
。SPI-發送兩個ISAKMP cookies或者道發送者的IPSEC SPI
。告示數據-包含一個ISAKMP屬性列表,這個列表帶有回答者實際的SA lifetime(s)
執行時注意:通知數據領域包含一個屬性列表,它說明通知數據域有零長度并且通報有效載荷有相連的屬性列表。
4.6.3.2 REPLAY-STATUS
這個REPLAY-STATUS狀態信息可能被用來對接受者的選擇作肯定證實,看他是否實現anti-replay的發現。
當它出現時,這個通知有效載荷應該有下列格式:
o 有效載荷長度 - 設定有效載荷的長度+ 數據的大小( 4 )
o DOI - 設定到 IPSEC DOI ( 1 )
o 協議 ID - 從選擇的 SA 選擇了協議 ID集合
o SPI 大小 - 設定到任何一個 16 ( 16 )( 2 個 8 字節ISAKMP cookies) 或 4 ( 4 )( 一 IPSEC SPI )
o 通知消息類型 - 到 REPLAY-STATUS 的集合
o SPI - 設定到 2 個 ISAKMP cookies或到發送者的入站IPSEC SPI
o 通知數據 - 4 字節值:
0 = 不可重放探測
1 = 啟用重放探測
4.6.3.3 INITIAL-CONTACT
當一個方面希望通知其它方這是這是同遙遠系統建立的第一個 SA 時, INITIAL-CONTACT 狀態消息可以被使用。這條通知消息的接收裝置然后可能選擇刪除任何存在的 Sa ,它在傳送系統時重新啟動,并且假設不再為傳送系統的原有 Sa存取與他們聯系的密鑰材料。當使用時,通知數據域的內容應該為空( 即有效載荷長度應該被設置為被通知有效載荷的固定長度 ) 。
當前,通知有效載荷必須有下列格式:
o 有效載荷長度 - 設定有效載荷的長度 + 數據的大小( 0)
o DOI - 設定到 IPSEC DOI ( 1 )
o 協議 ID - 從選擇的 SA 選擇了協議 ID 集合
o SPI 大小 - 設定到 16 ( 16 )( 2 個 8 字節ISAKMP cookies)
o 通知消息類型 - 到 INITIAL-CONTACT 的集合
o SPI - 設定到 2 個 ISAKMP cookies
o 通知數據 -<不被包括>
4.7 IPSEC 密鑰交換要求
IPSEC DOI 不介紹附加的密鑰交換類型。
5.安全考慮
整個備忘錄屬于因特網密鑰交換協議(IKE), 它以一種安全的并且好鑒定的方式,聯合ISAKMP([ISAKMP])和[OAKLEY]來提供密鑰材料來源。各種各樣的安全協議和文件中轉換鑒別的特別討論能在相關的基礎文件和密碼參考書目中找到。
6.IANA 需要考慮的事項
這個文件包含一些需要IANA來維持的“魔法”數字。這個章節解釋由IANA來使用的標準,用這個標準在每一個這些列表中分配附加數字。在前面章節中沒有明確說明的所有值對IANA來說是保留的。
6.1 IPSEC位置定義
這個位置定義是一個32位bitmask,它描繪IPSEC SA的建議和商談被實現的環境。請求分配新位置應該由一個RFC來完成,這個RFC由關聯位來解釋。
如果這個RFC不在標準軌跡上(也就是說,它是一個報告的或實驗的RFC),它應該在RFC被公開和轉化標識符被指派之前被明確的回復或被IESG認可。
這個上層的兩位在合作系統中被保留用作私有用途。
6.2 IPSEC 安全協議標識符
這個安全協議標識符適合一個8位值,它標識一個正需要討論的安全協議 。請求分配一個新的安全協議標識符應該由一個RFC來實現,它描敘了這個需要的安全協議。[AH]和[ESP]是這個安全協議文件中的例子。
如果這個RFC不在標準軌跡上(也就是說,它是一個報告的或實驗的RFC),它應該在這個RFC被公開和這個轉化被指岀之前明確的評論和由IESG來認可。
這些值249-255在合作系統中被保留作為私有用途。
6.3 IPSEC ISAKMP 轉移標志符
這個IPSEC ISAKMP 轉移標志符是一個8位的值,它標識一個用來流通的密鑰交換協議。
請求分配新的ISAKMP轉移標志符應該由RFC來完成,它描敘這個需要的密鑰交換協議。[IKE]是一個這種文件中的例子。
如果RFC不在標準軌跡上(也就是說,它是一個報告的或實驗的RFC),它應該在RFC被公開和這個轉移標識符被分配之前明確的指出和通過IESG來證實。
在合作系統中保留249-255這些值作為私有用途來使用。
6.4 IPDEC AH 轉移標識符
這個IPSEC AH 轉移標識符是一個8位值,它鑒別一個特定的算法法則來為AH提供完整保護。請求分配一個新的AH 轉移標識符應該由一個RFC來協助完成。這個RFC描繪了怎樣在AH框架中用這個運算法則。
如果這個RFC不是在這個標準軌跡上(也就是說,它是一個報告的或實驗的RFC),它應該在RFC被公開和這個轉移標識符被分配之前被明確的指出和通過IESG來證實。
在合作系統中保留這些值249-255來作為私有用途。
6.5 IPSEC ESP轉移標識符
這個IPSEC ESP轉移標識符是一個8位的值,它鑒別一個特定的運算法則用來為ESP提供一個秘密保護。請求分配一個新的ESP轉移標識符應該由RFC來協作完成。這個RFC描敘了在ESP框架中怎樣用這個算法.
如果這個RFC不在這個標準軌跡上(也就是說,它不是一個報告的或實驗的RFC),它應該在RFC被公開和這個轉移標識符被分配之前被明確的指出和通過IESG來證實。
在合作系統中保留這些值249-255來作為私有用途。
6.6 IPSEC IPCOMP 轉移標識符
這個IPSEC IPCOMP轉移標識符是一個8位的值,在ESP之前它標識一個特定的運算法則用來提供IP層壓縮。請求分配一個新的IPCOMP轉移標識符應該由一個RFC來協作完成,它描敘了在IPCOMP框架([IPCOMP])中怎樣使用運算法則。另外,這個需要的運算法則應該被公開,并且在公共范圍內。
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -