【正文】 。 （ proposal） 建議載荷包含的是 在 SA協(xié)商過(guò)程中用到的信息 。該載荷提供了一個(gè)框架，利用這個(gè)框架發(fā)起方向接收方發(fā)送自己的建議，例如期望的 IPSec協(xié)議和其他安全機(jī)制。 ZISAKMP載荷 2022/8/27 網(wǎng)絡(luò)安全 李章兵 84 （ transform） 變換載荷包括 變換編號(hào) （ Transform Number）和變換 ID（ Transform ID）；前者表示本載荷在建議載荷中的編號(hào) ,后者確定變換 ID取值。 （ Key Exchange） 密鑰交換載荷 用于傳輸密鑰交換數(shù)據(jù) ，這個(gè)載荷不局限于任何密鑰交換協(xié)議。除了通用載荷頭部外，該載荷 只包含一個(gè)變長(zhǎng)的密鑰交換數(shù)據(jù)字段 ，該字段的組成格式及如何解釋由具體的密鑰交換協(xié)議具體定義，因此該載荷 適用于任何通常用的密鑰交換協(xié)議 。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 85 （ identification） 通信雙方 利用身份載荷互相交換身份信息 。在 SA協(xié)商的時(shí)候，發(fā)起方要通過(guò)該載荷告訴對(duì)方自己的身份，而響應(yīng)方利用發(fā)起方的身份來(lái)決定應(yīng)該采用何種安全策略。 （ certificate） 證書載荷允許通信雙方交換各自的證書，或者與證書相關(guān)的其他內(nèi)容。 （ Certificate Request） 通信雙方可以利用證書請(qǐng)求載荷來(lái)請(qǐng)求對(duì)方發(fā)送證書。一方在收到該請(qǐng)求后，如果支持證書，就必須利用證書載荷來(lái)發(fā)送對(duì)方所請(qǐng)求的證書。如果有多個(gè)證書，請(qǐng)求方就必須發(fā)送多次證書請(qǐng)求載荷，接收方發(fā)送多次證書載荷。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 86 （ Hash）載荷 該載荷包含的是 Hash驗(yàn)證函數(shù)產(chǎn)生的數(shù)據(jù) ，該函數(shù)是 SA協(xié)商過(guò)程中 雙方協(xié)商出來(lái)的 Hash函數(shù)。 Hash數(shù)據(jù)一般 用于驗(yàn)證 包含在ISAKMP報(bào)文中的其余部分?jǐn)?shù)據(jù)的 完整性 ，或者對(duì)協(xié)商實(shí)體進(jìn)行鑒別。 （ signature） 簽名載荷包含 由數(shù)字簽名函數(shù)所產(chǎn)生的數(shù)據(jù) ，該函數(shù)是 SA協(xié)商過(guò)程中 雙方協(xié)商出來(lái) 的。此載荷用來(lái)認(rèn)證 ISAKMP報(bào)文的 完整性 ，還可 用作不可否認(rèn)服務(wù) 。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 87 Nonce載荷包含在交換期間 用于保證存活和防止重放攻擊的隨機(jī)數(shù) 。如果 Nonce用于特殊的密鑰交換協(xié)議， Nonce載荷的使用將由該密鑰交換機(jī)制來(lái)指定。 Nonce可作為密鑰交換載荷的交換數(shù)據(jù)的一部分 ，或 作為一個(gè)獨(dú)立的載荷發(fā)送 。具體如何發(fā)送，由密鑰交換來(lái)定義，而不是 ISAKMP。 （ notification） 通知載荷用于告知對(duì)方一些信息，例如錯(cuò)誤狀態(tài)。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 88 （ delete） 通信一方利用刪除載荷告訴對(duì)方自己已經(jīng)從 SAD中刪除給定 IPSec協(xié)議（ IAKMP、 AH或者 ESP）的 SA。注意：刪除載荷并不是命令對(duì)方刪除 SA，而是 建議對(duì)方刪除 SA。如果對(duì)方選擇忽略該刪除載荷，則對(duì)方以后再使用該 SA所發(fā)送的報(bào)文將失敗。另外，對(duì)于該刪除報(bào)文 不需要對(duì)方應(yīng)答 ，也就是說(shuō)對(duì)方不需要返回刪除是否成功的報(bào)文。 （ Vendor ID） 廠商 ID載荷用于傳輸廠商定義的常數(shù)。這個(gè)機(jī)制允許廠商在 維持向后兼容性的同時(shí)，試驗(yàn)新的特性 。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 89 ISAKMP的 協(xié)商過(guò)程分為兩個(gè)階段 ：階段 1和階段 2。兩個(gè)階段所協(xié)商的對(duì)象不同，但協(xié)商過(guò)程的交換方式（見 ）是由ISAKMP定義的或者由密鑰交換協(xié)議（例如IKE）定義的。 （ 1） 階段 1 這個(gè)階段要 協(xié)商的 SA可以稱為 ISAKMP SA（在 IKE中可以稱為 IKE SA），該 SA是為了保證階段 2的安全通信。 ISAKMP協(xié)商階段 2022/8/27 網(wǎng)絡(luò)安全 李章兵 90 （ 2） 階段 2 這個(gè)階段要協(xié)商的 SA是密鑰交換協(xié)議最終要協(xié)商的 SA，當(dāng) IKE為 IPSec協(xié)商時(shí)可以稱為IPSec SA，是保證 AH或者 ESP的安全通信。階段 2的安全由階段 1的協(xié)商結(jié)果來(lái)保證。 階段 1所協(xié)商的一個(gè) SA可以用于協(xié)商多個(gè)階段 2的 SA。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 91 ISAKMP定義了 5種交換類型 。交換類型定義的是在通信雙方所傳送的載荷的類型和順序，比如一方先發(fā)送什么載荷，另一方應(yīng)如何應(yīng)答等。這些交換模式的區(qū)別在于對(duì)傳輸信息的保護(hù)程度不同，并且傳輸?shù)妮d荷多少也不同。 交換類型 2022/8/27 網(wǎng)絡(luò)安全 李章兵 92 5種交換類型分別是 : （ 1） 基本 交換 （ Base Exchange） 。 （ 2）身份保護(hù)交換 （ Identity Protection Exchange）。 （ 3）純認(rèn)證交換 （ Authentication Only Exchange）。 （ 4）積極交換 (Aggressive Exchange)。 （ 5）信息交換 （ Informational Exchange）。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 93 IKE是一種混合型協(xié)議 ，由 RFC2409定義，包含了 3個(gè)不同協(xié)議的有關(guān)部分： ISAKMP、Oakley和 SKEME。 IKE和 ISAKMP的不同之處在于： IKE真正定義了一個(gè)密鑰交換的過(guò)程，而 ISAKMP只是定義了一個(gè)通用的可以被任何密鑰交換協(xié)議使用的框架。 IKE為 IPSec通信雙方 提供密鑰材料 ，這個(gè)材料 用于生成加密密鑰和驗(yàn)證密鑰 。另外， IKE也為 IPSec協(xié)議 AH和 ESP協(xié)商 SA。 IKE協(xié)議 IKE概述 2022/8/27 網(wǎng)絡(luò)安全 李章兵 94 IKE中有 4種身份認(rèn)證方式： （ 1） 基于數(shù)字簽名（ Digital Signature），利用數(shù)字證書來(lái)表示身份 ，利用數(shù)字簽名算法計(jì)算出一個(gè)簽名來(lái)驗(yàn)證身份。 （ 2） 基于公開密鑰（ Public Key Encryption），利用對(duì)方的公開密鑰加密身份 ，通過(guò)檢查對(duì)方發(fā)來(lái)的該 HASH值作認(rèn)證。 （ 3） 基于 修正的公開密鑰 （ Revised Public Key Encryption），對(duì)上述方式進(jìn)行修正。 （ 4） 基于 預(yù)共享字符串 （ Pre Shared Key），雙方事先通過(guò)某種方式商定好一個(gè)雙方共享的字符串。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 95 IKE目前定義了 4種模式： 主模式、積極模式、快速模式和新組模式。 前面 3個(gè)用于協(xié)商 SA，最后一個(gè)用于協(xié)商 Diffie Hellman算法所用的組。 主模式和積極模式用于第一階段 ； 快速模式用于第二階段；新組模式用于在第一個(gè)階段后協(xié)商新的組。 IKE交換模式 2022/8/27 網(wǎng)絡(luò)安全 李章兵 96 IPSec是用于保護(hù) IP層通信安全的機(jī)制，由若干RFC文件和 Inter草案進(jìn)行定義，而不是一個(gè)單獨(dú)的協(xié)議。 安全策略用于定義對(duì)數(shù)據(jù)包的處理方式，存儲(chǔ)在安全策略數(shù)據(jù)庫(kù)中； IPSec雙方 利用安全聯(lián)盟中的參數(shù)對(duì)需要進(jìn)行 IPSec處理的包進(jìn)行 IPSec處理 ，安全聯(lián)盟存儲(chǔ)在安全聯(lián)盟數(shù)據(jù)庫(kù)中。 傳輸模式和隧道模式的區(qū)別在于保護(hù)的對(duì)象不同，傳輸模式要保護(hù)的內(nèi)容是 IP包的載荷 ，而 隧道模式要保護(hù)的是整個(gè) IP包。 本章小結(jié) 2022/8/27 網(wǎng)絡(luò)安全 李章兵 97 對(duì) IP包進(jìn)行的 IPSec處理有兩種 ： AH和 ESP。 AH提供無(wú)連接的數(shù)據(jù)完整性、數(shù)據(jù)來(lái)源驗(yàn)證和抗重放攻擊服務(wù)；而 ESP除了提供 AH的這些功能外，還可以提供對(duì)數(shù)據(jù)包加密和數(shù)據(jù)流量加密。雖然 AH和ESP都提供驗(yàn)證服務(wù)，但 AH的驗(yàn)證范圍要比 ESP更大，包含了源和目的 IP地址 ，因此造成了 AH協(xié)議和NAT的沖突 ，而 ESP則不存在這種問(wèn)題。 IKE協(xié)議由 3種協(xié)議混合而來(lái)： ISAKMP、 Oakley和 SKEME。 ISAKMP協(xié)議為 IKE提供了密鑰交換和協(xié)商的框架； Oakley提供了組的概念； SKEME定義了驗(yàn)證密鑰交換的一種類型。 IKE協(xié)議的密鑰交換采用 Diffie Hellman算法； IKE協(xié)議有 4種模式：主模式、積極模式、快速模式和新組模式。 2022/8/27 網(wǎng)絡(luò)安全 李章兵 98 101 IPSec協(xié)議和（） VPN隧道協(xié)議處于同一層。 A. PPTP B. L2TP C. GRE D. 以上皆是 102 AH協(xié)議中必須實(shí)現(xiàn)的驗(yàn)證算法是（）。 A. HMACMD5和 HMACSHA1 B. NULL C. HMACRIPEMD160 D. 以上皆是 103 ESP協(xié)議中不是必須實(shí)現(xiàn)的驗(yàn)證算法的是（）。 A. HMACMD5 B. HMACSHA1 C. NULL D. HMACRIPEMD160 習(xí)題 2022/8/27 網(wǎng)絡(luò)安全 李章兵 99 104 ESP協(xié)議中必須實(shí)現(xiàn)的加密算法是（）。 A. 僅 DESCBC B. 僅 NULL C. DESCBC和 NULL D. 3DESCBC 105（）協(xié)議必須提供驗(yàn)證服務(wù)。 A. AH B. ESP C. GRE D. 以上皆是 106 IKE協(xié)商的第一階段可以采用（）。 A. 主模式、快速模式 B. 快速模式、積極模式 C. 主模式、積極模式 D. 新組模式 107 IKE協(xié)議由（）協(xié)議混合而成。 A. ISAKMP、 Oakley、 SKEME B. AH、 ESP C. L2TP、 GRE D. 以上皆不是 2022/8/27 網(wǎng)絡(luò)安全 李章兵 100 108 下列協(xié)議中，（）協(xié)議的數(shù)據(jù)可以受到IPSec的保護(hù)。 、 UDP、 IP B. ARP C. RARP D. 以上皆可以 109 為什么 AH協(xié)議和 NAT沖突？ 1010 簡(jiǎn)述 IKE協(xié)議的幾種模式，以及每一種模式的作用和特點(diǎn)。