|
|
|
10-5 ISAKMP協定
10-5-1 ISAKMP 協定簡介 『網際網路安全關聯金鑰管理協定』（Internet Security Association Key Management Protocol, ISAKMP）是美國 NSA（National Security Agency）所制定的標準規範，並詳列於 RFC 2408。ISAKMP 是 IPSec 協定（VPN 裝置）中相當重要的協定，主要功能是建立、修改與刪除『安全關聯』（Security Association, SA）。其中包含協議雙方的加密金鑰、認證金鑰、以及各種演算法，也就是說，IPSec 協定所欲採用的安全措施皆是利用 ISAKMP 協定建立而成。為了因應 Internet 網路的成長，以及不同應用環境需求，雖然 ISAKMP 只提供一個安全性的基礎架構，有關較詳細的金鑰交換協定，則由另一個協定標準來規劃（IKE 協定，RFC 2409）。 ISAKMP 必須利用 UDP 協定傳輸，且由 IANA 指定在第 500 埠口（500/udp），此外，在 ISAKMP 協定上所承載訊息的編碼，全部規範於 RFC 2407，稱之為『IPSec 解譯領域』（IP Security Domain of Interpretation, IPSec DOI），所以各廠商在實作 IPSec 裝置時，必須依照 IPSec DOI 上的編碼格式。 配合前一章的敘述，我們可以瞭解建構 VPN 網路需包含 IP Sec AH、IPSec ESP、ISAKMP、IKE 與 IPSec DOI 等五個主要通訊協定，的確讓人眼花撩亂。讀者可以先參考圖 10-16 的說明，或許對瞭解這些協定之間的關係，比較容易進入狀況。說明如下： ² 倘若工作站 A 欲透過安全連線與工作站 B 通訊，兩工作站同屬一個 VPN 網路之內，但地理位置不相同，通訊連線必須經由公眾網路連接。 ² 工作站 A 將封包傳送給該區域網路的安全閘門（SA_A），SG_A 判斷必須建立 IPSec 安全連線後，接著查詢本身是否有描述相關安全機制的 SA，如果有則發出 IPSec 封包（ESP 或 AH 協定）；如果沒有或SA 過期的話，則啟動 ISAKMP 協定。 ² SG_A 啟動 ISAKMP 協定與 SG_B 建立連線（500/udp），雙方協議建立 SA。其中包含協議安全套件（加密與認證系統）、安全協定（AH 或 ESP）、加密金鑰與認證金鑰等等。其實，ISAKMP 協定只提供基本架構，至於如何協議安全機制是由另一個 IKE 協定來完成。 ² IKE 協定並無法獨立運作，也沒有專屬通訊的傳輸埠口，而是被嵌入於 ISAKMP 協定上，因此IKE 協定是在 ISAKMP 的基本架構上實現，主要的功能是協議相關的安全措施。 ² 建立 SA 時，必須先確認對方的身份。在安全套件裡可以指明欲利用數位憑證（PKI 或 Kerberos 系統）或帳戶/密碼（Kerberos 系統）方式，所以ISAKMP 協定還必須實作認證機制。 ² 當雙方利用 ISAKMP 協定通訊時，各種協議事項都是利用 IPSec ODI 規範來編碼，只要各家廠商製造安全閘門時，都是利用 IPSec ODI 編碼各種訊息（或安全參數），則他們之間通訊就不會發生不一致的現象
圖 10-16 IPSec 相關安全協定 簡而言之，ISAKMP 主要提供 SA 訊息的管理，也就是如何將 SA 記錄登錄於『安全關聯資料庫』（SA Database, SAD）內，其中包含刪除、更新或增加 SA 記錄，並協議欲採用的安全套件。對於初學者而言，ISAKMP 與 IKE 協定很容易搞混，不易分辨兩者之間運作程序的關聯性。作者建議在研習 ISAKMP 協定時，先假設所有協議事項都是由 ISAKMP 協定所完成，暫時不要去考慮 IKE協定；等到研習 IKE 協定時，再去考慮如何將它嵌入 ISAKMP 協定即可。 10-5-2 ISAKMP 協定功能 接下來，介紹幾點 ISAKMP 協定特性，這對我們了解 ISAKMP 協定非常有幫助。 （A）協議事項 ISAKMP 協議 SA 所需的：安全協定（AH 或 ESP）、操作模式（傳輸或通道）、SA 壽命、認證金鑰、加密金鑰、以及各種編碼演算法，協議後的訊息將登錄於 SAD 資料庫內，作為 IPSec 通訊時引用的 SA 安全參數。ISAKMP並不規範鑰匙交換的運作程序，僅提出一個基本架構，此架構允許各種金鑰交換協定嵌入，譬如 IKE 協定。 （B）建立與管理 SA 若一個 SA 描述兩個或兩個以上的實體之間的安全政策，這個關係是由一組訊息來表示兩個實體之間的連接，且這些訊息必須允許實體之間的所有連線所共享。由此可見，建立 SA 完全著重於訊息的安全機制，並非僅是兩個實際連接的硬體介面。所以建立一個安全關聯是表示一個序列的安全參數，可以用一個『安全參數索引』（Security Parameter Index, SPI）來代表。當安全閘門（或安全主機）欲發出安全連線時，再搜尋適合的安全關聯來引用。 當 SA 不存在時（或過時失效），安全閘門（或安全主機）則需啟動 ISAKMP 協定來建立新的 SA。在 ISAKMP 協商過程中或許會啟動到其他通訊協定，如IKE 協定，因此可能需要多個協定共同來完成。為了實現多個協定的運作，ISAKMP 協定制定一個『起始協定交換』（Initial Protocol Exchange, IPE）的運作程序（或稱為第一階段協商，Phase 1 Negotiation）。當雙方開始協議時，發起者發送 IPE 訊息給對方，其中包含一些較常用的安全套件，如果對方同意接受的話，則緊接著啟動其他協定（如 IKE）來協議該套件的安全參數；即使對方不同意，仍必須回答可以接受的安全套件。至於其他安全協定（如 IKE）可被嵌入 ISAKMP 協定之中。 （C）認證機制 為了確認建立 SA 的對方身份，ISAKMP 必須實作身份認證機制。隨著 VPN 網路的應用範圍，使用者身份認證方式也有所不同，基本上存在下列兩種方式，而且 ISAKMP 必須同時提供這兩種認證機制： ² 憑證授權（Certificate Authorities, CA）：使用者或組織單位由認證中心（CA Center）發給予『數位憑證』（Digital Certificate），通訊雙方就利用此憑證彼此認證對方身份。採用數位憑證需涉及認證公開金鑰問題，這方面請參考第九章的 PKI 系統。 ² 金鑰分配中心（Key Distribution Center, KDC）：KDC 發給一個秘密金鑰或數位憑證給使用者（或組織單位），通訊雙方就利用它來認證彼此身份，如 Kerberos 系統。KDC 系統較適合於企業內網路運作，也是目前許多 VPN 網路皆採用的機制。 （D）隱密性機制 為了達到建立 SA 的隱密性，ISAKMP 協定除了提供公鑰認證機制之外，還需利用公鑰系統來交換鑰匙材料，並建立通訊所需的會議金鑰（Session Key）；在通訊當中，雙方係利用秘密金鑰系統（使用會議金鑰）達到隱密性的功能。然而 ISAKMP 協定沒有定義金鑰交換協定與會議金鑰所產生的機制，這方面可透過其它協定來完成（如 IKE 協定）。 10-5-3 ISAKMP 協定堆疊 (A) 協定堆疊 圖 10-17 為 ISAKMP 協定在 Internet 網路上的協定堆疊，其中只是希望在不影響原來應用程式的架構下，將原來不可靠的 IP 協定轉換成可靠的 IPSec，換句話說，將 IP 協定轉換成 IPSec 協定的同時，對原來 TCP 或 UDP 層次並不影響，所以原來架設在 TCP/UDP 上的應用程式，無需任何的修改也能利用 IPSec 協定來提高其安全性。其做法是先利用 ISAKMP 協定來協商（或建立 SA），再決定何種應用程式需將 IP 協定轉換成 IPSec 協定。然而 ISAKMP 協商連線與其它應用程式一樣，都是透過 Socket 端點連線來建立，至於 ISAKMP 通訊若需要保護，可能會建立 ISAKMP SA 的安全機制，也可能透過 IPSec 協定來傳送，這完全依照雙方協商的『保護套件』（Protection Suite）而定。
圖 10-17 IPSec 相關安全協定 (B) ISAKMP 封包標頭 ISAKMP 封包是利用 UDP協定來傳送，並且 IANA 將 ISAKMP 固定於埠口 500（500/udp）。圖 10-18 為 IP 的 ISAKMP 封包包裝，它除了一個封包標頭外，還包含若干筆 ISAKMP 承載（ISAKMP Payload），其中每一筆 ISAKMP 承載都由承載標頭（Payload Header）記錄所承載的訊息型態與承載資料（Payload Data）所組成。
圖 10-18 IP 的 ISAKMP 封包包裝
圖 10-19 ISAKMP 封包標頭格式 圖 10-19 為 ISAKMP 封包標頭的格式，各欄位功能如下： ² 發起者 Cookie（Initiator Cookie）：此欄位為 64 位元長度，是一個序號計數。表示建立 SA、通知 SA、或是刪除 SA 的發起者，以序號表示是為了防止重複攻擊及阻斷攻擊（容後說明）。 ² 回應者 Cookie（Responder Cookie）：此欄位為 64 位元長度，用來表示針對哪一個發起者 Cookie 所做的回應，存放的值就是所欲回應發起者 Cookie 的值。 ² 下一個承載（Next Payload）：此欄位為 8 位元長度，用來表示緊接著在標頭後面的第一個承載的型態。表 16-1 是 ISAKMP 目前所指定的承載型態，與其相對應的數值。 表 10-1 ISAKMP 承載封包的類型
² 主要版本（Master Version）：此欄位為 4位元長度，表示該 ISAKMP 封包的版本。在 ISAKMP 規範中規定，ISAKMP 裝置並不接受比自己版本較高的封包。 ² 次要版本（Minor Version）：此欄位為 4位元長度，表示該 ISAKMP 封包的次要版本。 ² 交換種類（Exchange Type）：此欄位為 8位元長度，表示此封包訊息的交換型態。表 10-2 為ISAKMP 協定所定義的交換型態： 表 10-2 交換類別
² 旗標（Flag）：此欄位為 8位元長度，目前只用到 3 個位元，其他位元都先設定為 0。旗標位元表示封包的狀態，說明如下： 1. 編碼位元（Encryption bit, E）：此位元被設定時，表示標頭之後的承載都已被 ISAKMP 所指定的加密演算法編碼，否則表示承載資料都是明文。 2. 承諾位元（Commit bit, C）：此位元是使用於單一鑰匙交換同步，以確保在 SA 建立完成之前不會收到任何加密的資料。此位元設定為 1 乃表示雙方已協議出秘密金鑰，若其中一方設定為 1 時，就必須等到另一方同樣設定為 1，方可認定雙方都已確定秘密金鑰，始可傳送已加密的訊息。 3. 僅供認證位元（Authentication Only Bit, A）：此位元設定為 1 時，表示此封包僅採用 SA 所指定的認證演算法進行完整性檢查，但不採用加密方法來保護訊息。 ² 訊息標示（Message ID）：此欄位為 4 個位元長度，包含由發起者在第二階段協議中所產生的隨機數字。如果有兩個以上的 SA 建立連線傳送訊息（如碰撞現象），此訊息標示可以顯示出之間的不同，而被用來識別第二階段連線的唯一表示值。 ² 長度（length）：此為 4 個位元長度的欄位，記錄整個封包的長度，其中包含封包標頭與承載資料，以位元組為計算單位。 『cookie』是一個 ISAKMP SA 通訊連線的標示，其功能和 IPSec 協定（AH 或 ESP）封包標頭上的序號（Sequence Number）欄位非常相似，除了當作連線識別之外，還必須具有防止反重播攻擊與阻斷攻擊。為了預防攻擊者猜測出，某一個 ISAKMP SA 連線是屬於那一個安全閘門所建立的，cookie 大多是利用雜湊演算法，計算出產生者（發起者或回應者）所欲協調安全機制的 IP 位址與傳輸埠口，並加入日期與時間戳記。 |
翻轉工作室：粘添壽
網路規劃與管理技術：
翻轉電子書系列：
|
