IPSec 中文RFC

IPSec 中文RFC (1)
來源：作者：發佈時間：2008-04-28 閱讀次數114
Network Working Group D. Harkins
Request for Comments: 2409 D. Carrel
Category: Standards Track cisco Systems
November 1998

Internet密鑰交換（IKE）
（The Internet Key Exchange）
本備忘錄的現狀
本文檔指定了一個Internet 團體的Internet標準協議，並請求討論和建議以作改進。請參考當前
版本的“Internet官方協議標準”（STD 1），查看本協議的標準化進程和現狀。本文檔的分發不受限
制。
版權通告
Copyright (C) The Internet Society (1998)。保留所有的權利。

1.摘要 2
2.討論 2
3.術語和定義 3
3.1必要的術語 3
3.2符號 3
3.3完全後繼保密 4
3.4安全聯盟 4
4.簡介 5
5.交換 6
5.1 使用簽名來驗證的IKE第一階段 8
5.2 使用公共密鑰加密的第一階段驗證 8
5.3 使用修改過的公鑰加密模式來進行第一階段的驗證 10
5.4 使用共享密鑰的第一階段協商 11
5.5 第二階段——快速模式 12
5.6 新組模式 14
5.7 ISAKMP信息交換 15
6 Oakley組 15
6.1 第一個Oakley缺省組 15
6.2 第二個Oakley組 16
6.3 第三個Oakley組 16
6.4 第四個Oakley組 16
7. 完整IKE交換的負載爆炸 17
7.1 使用主模式的第一階段 17
7.2 使用快速模式的第二階段 18
8. 完全後繼保密舉例 20
10.安全考慮 21
11.IANA考慮 22
11.1 屬性類 22
11.2 加密算法類 22
11.3 hash算法 22
11.4 組描述和組類型 23
11.5 存活期類型 23
12. 鳴謝 23
13.參考 23
附錄A 25
屬性分配號碼 25
屬性種類 26
種類值 26
附錄B 28
作者地址 30
作者的註釋 30
完全版權聲明 31

1.摘要
ISAKMP ([MSST98])中對驗證和密鑰交換提出了結構框架，但沒有具體定義。ISAKM被設計用
來獨立的進行密鑰交換，即被設計用於支持多種不同的密鑰交換。
Oakley ([Orm96])中描述了一系列被稱爲“模式”的密鑰交換，並詳述了每一種提供的服務（如
密鑰的完全後繼保密（perfect forward secrecy），身份保護，以及驗證）。
SKEME ([SKEME])中描述了一種提供匿名，否認，和快速密鑰更新的通用密鑰交換技術。
本文檔將描述使用部分Oakley，部分SKEME，並結合ISAKMP的一種協議，它使用ISAKMP來得
到已驗證的用於生成密鑰和其它安全聯盟（如AH，ESP）中用於IETE IPsec DOI的材料。
2.討論
本文檔描述了一種混合協議。目的是用於以一種保護的方式來協商安全聯盟併爲它提供經驗證
過的密鑰生成材料。
本文檔中實現的過程可用於協商虛擬專用網（***），也可用於遠程用戶（其IP地址不需要事
先知道）從遠程訪問安全主機或網絡。
支持客戶協商。客戶模式即爲協商雙方不是安全聯盟發起的兩個終點。當使用客戶模式時，端
點處雙方的身份是隱藏的。
本協議並沒有實現整個Oakley協議，只實現了滿足目的所需要的部分子集。它並沒有聲稱與整
個Oakley協議相一致或兼容，也並不依靠Oakley協議。
同樣，本協議沒有實現整個的SKEME協議，只使用了用於驗證的公鑰加密的方法和使用當前時間
（nonce）交換來快速重建密鑰的思路。本協議並不依靠SKEME協議。
3.術語和定義
3.1必要的術語
本文檔中出現的關鍵字“MUST”，“MUST NOT”，“REQUIRED”，“SHOULD”，“SHOULD
NOT”以及“MAY”的解釋在[Bra97]中描述。
3.2符號
下列的符號在整個文檔中都使用。

HDR是ISAKMP的報頭，它的交換類型是模式。當寫成HDR*時，意味着負載加密。

SA是有一個或多個提議的SA協商負載。發起方可能提供多個協商的提議；應答方只能用一個
提議來回答。

<P>_b指明負載<P>數據部分（body）——不包括ISAKMP的通用vpayload負載。

SAi_b是SA負載的數據部分（除去ISAKMP通用報頭）——也就是由發起者所提供的DOI、
情況（situation）、所有的提議（proposal）、以及所有的變換（transform）。

CKY-I和CKY-R分別是ISAKMP報頭中發起者和響應者的cookie。

g^xi和g^xr分別是Diffie-Hellman ([DH])中發起者和響應者的公共值。

g^xy是Diffie-Hellman的共享祕密。

KE是包含了用於Diffie-Hellman交換的公共信息的密鑰交換負載。沒有對KE負載的數據進行
特殊的編碼（如TLV）。

Nx是當前時間（nonce）負載；其中x可以是i和r，分別代表ISAKMP的發起者和響應者。

IDx是x的身份識別負載。x可以是“ii”或“ir”，分別表示第一階段協商中的ISAKMP發起者
和響應者；也可以是“ui”或“ur”，分別表示第二階段的用戶發起者和響應者。用於互聯網DOI的
ID負載格式在[Pip97]中定義。

SIG是數字簽名負載。簽名的數據是特定於某種交換的。

CERT是證書負載。

HASH（以及衍生物，如HASH（2）或HASH_I）是hash負載。hash的內容是特定於驗證方法
的。

prf(key, msg)是key的僞隨機函數——通常是key的hash函數——用於產生表現有僞隨機性的確
定的輸出。prf用於導出密鑰和驗證（即作爲有密鑰的MAC）。（見[KBC96]）

SKEYID是從祕密材料中衍生出的字符串，只有某次交換中的活躍雙方纔知道。

SKEYID_e是ISAKMP SA用來保護消息的機密性的密鑰材料。

SKEYID_a是ISAKMP SA用來驗證消息所使用的密鑰材料。

SKEYID_d是非ISAKMP安全聯盟用來衍生出密鑰所使用的密鑰材料。

<x>y表示“x”是由密鑰“y”加密的。

-->表示“發起者到響應者”的通信（請求）。

<--表示“響應者到發起者”的通信（回答）。

| 表示信息的串聯——如X | Y表示X和Y是串聯的。

[x]表示x是可選的。

消息加密（ISAKMP報頭後標註有“*”號）必須緊接在ISAKMP報頭後。當通信是受保護的
時候，所有ISAKMP報頭後的負載必須要加密。從SKEYID_e產生加密密鑰的方法由各個算法定義。

3.3完全後繼保密

在本文檔中使用的完全後繼保密（PFS）術語是和一個概念相關的，即限制單密鑰只能訪問到
受本單密鑰保護的數據。要滿足PFS，對於用來保護數據傳輸的已經存在的密鑰來說，它就不能用
於衍生出其它的密鑰，如果用來保護數據傳輸的密鑰是從其它密鑰材料中衍生出來的，則這些材料
就不能再用於衍生任何其它密鑰。
在本協議中提供了密鑰和身份的完全後繼保密（5.5和 8 節）
3.4安全聯盟
安全聯盟（SA）是一組用來保護信息的策略和密鑰。在本協議中，ISAKMP SA是協商雙方爲
保護之間的通信而使用的共享的策略和密鑰。
4.簡介
Oakley和SKEME各自定義了建立經過驗證的密鑰交換的方法。其中包括負載的構建，信息負
載的運送，它們被處理的順序以及被使用的方法。
然而Oakley定義了“模式”， ISAKMP定義了“階段”。兩者之間的關係非常直接，IKE描述
了在兩個階段中進行的不同的、稱爲模式的交換。
第一階段指兩個ISAKMP實體建立一個安全、驗證過的信道來進行通信。這被稱爲ISAKMP安
全聯盟（SA）。“主模式”和“積極模式”都能完成第一階段的交換。“主模式”和“積極模式”只
能在第一階段中使用。
第二階段指協商代表服務的安全聯盟，這些服務可以是IPsec或任何其它需要密鑰材料以及/或
者協商參數的服務。
“新組模式”並不真正在第一階段或第二階段中。它緊接着第一階段，用於建立可在以後協商
中使用的新組。“新組模式”只能在第一階段之後使用。
ISAKMP SA是雙向的，即一旦建立，任何一方都可以發起快速模式交換，信息交換，以及新組
模式交換。由ISAKMP基礎文檔可知，ISAKMP SA由發起者的cookie後跟響應者的cookie來標識
——在第一階段的交換中各方的角色決定了哪一個cookie是發起者的。由第一階段的交換所建立的
cookie順序繼續用於標識ISAKMP SA，而不管快速模式、信息、新組交換的方向。換句話來說，當
ISAKMP SA的方向改變時，cookie不能交換位置。
由於使用ISAKMP階段，實現中可以在需要時完成快速的密鑰交換。單個第一階段協商可以用
於多個第二階段的協商。而單個第二階段協商可以請求多個安全聯盟。由於這種優化，實現中每個
SA可以少於一個傳輸往返，以及少於一次DH求冪運算。第一階段中的“主模式”提供了身份保護。
當身份保護不必要時，可以使用“積極模式”以進一步減少傳輸往返。下面的內容中包括了開發者
對進行優化的提示。同時必須注意當使用公共密鑰加密來驗證時，積極模式仍然提供身份保護。
本協議本身並沒有定義自己的DOI。在第一階段中建立的ISAKMP SA可以使用非ISAKMP服
務（如IETF IPSec DOI [Pip97]）的DOI和情形（situation）。在這種情況下，實現中可以限制使用
ISAKMP SA來建立具有相同DOI的服務SA。另一種方法是使用DOI和情形（situation）爲零值（參
看[MSST98]中對這些域的描述）來建立ISAKMP SA，在這種情況下，實現中可以自由使用ISAKMP
SA來爲任何已定義的DOI建立安全服務。如果使用DOI爲零來建立第一階段的SA，第一階段中的
標識負載的語法就在[MSST98]中定義，而不是從任何的DOI（如[Pip97]，它可能會進一步擴展標識
的語法和語義）中定義。

IKE使用下面的屬性，並且作爲ISAKMP安全聯盟的一部分來協商。（這些屬性只屬於ISAKMP
安全聯盟，而不屬於ISAKMP爲所代表的服務進行協商而建立的任何安全聯盟）：
—加密算法
—hash算法
—驗證方法
—進行Diffie-Hellman操作的組的有關信息。

所有這些屬性是強制性的且必須被協商的。另外，可以可選的協商一個僞隨機函數（“prf”）。（當
前本文檔中還沒有定義可協商的僞隨機函數。在雙方都同意時可以私下使用屬性值用於prf協商。）
如果沒有協商“prf”，協商的HMAC (參看[KBC96])的hash算法就作爲僞隨機函數。其它非強制性
的屬性在附錄A中定義。選擇的hash算法必須支持原始模式和HMAC模式。

Diffie-Hellman組必須使用一個已定義的組描述（第6節）來指定，或者定義一個組的全部屬性
（第5.6節）。組屬性（如組類型或素數——參看附錄A）不能和以前定義的組（不論是保留的組描
述，還是由新組模式交換後確定並建立的私下使用的描述）相關聯。

IKE的實現必須支持以下的屬性值：
—使用弱、半弱密鑰檢查，且爲CBC模式的DES[DES]。（弱、半弱密鑰參考[Sch96]，並在附
錄A中列出）。密鑰根據附錄B進行衍生。
—MD5[MD5]和SHA[SHA]。
—通過共享密鑰進行驗證。
—對缺省的組1進行MODP（參看下面內容）。

另外，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)

對於使用數字簽名的驗證，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負載交換中協商的對稱加密算法的密鑰。
只有負載的數據部分加密（公鑰和對稱密鑰操作中都一樣），通用的負載的報頭保持明文形式。包含
報頭的負載長度用於執行加密操作。

對稱加密密鑰是從解密的當前時間（nonce）中衍生出來的，如下所示。先計算值Ne_i和Ne_r：
Ne_i = prf(Ni_b, CKY-I)
Ne_r = prf(Nr_b, CKY-R)

接着，通過附錄B中描述的方式分別從Ne_i 和Ne_r中得到密鑰Ke_i和Ke_r，並用於爲協商
的加密算法衍生出對稱密鑰。如果協商的prf產生的輸出的長度大於或等於密碼的密鑰長度要求，則
Ke_i和Ke_r分別從Ne_i和Ne_r的最高位衍生。如果Ke_i和Ke_r需要的長度超過了prf的輸出的
長度，則還需要的比特位通過下列方式得到：不斷的將prf輸出的結果作爲prf的輸入，並連接產生
的結果，直到得到需要的長度。例如：如果協商的加密算法需要320比特的密鑰，而prf的輸出只有
128比特時，Ke_i就是K的最高320比特，其中：
K = K1 | K2 | K3 and
K1 = prf(Ne_i, 0)
K2 = prf(Ne_i, K1)
K3 = prf(Ne_i, K2)

爲簡潔起見，只顯示了Ke_i的衍生過程；Ke_r是相同的。在計算K1時值0的長度是單個字節。
注意Ne_i，Ne_r，Ke_i，以及Ke_r都是暫時性的，必須在使用後廢棄。

將請求存放在可選的HASH負載和強制的當前時間（nonce）負載的位置中，就沒有其它的負載
請求了。跟在加密的當前時間（nonce）之後的所有的負載——無論任何順序——都必須使用Ke_i
或Ke_r來加密，具體使用哪一個取決於方向。

如果CBC模式用於對稱加密，則初始向量（IV）如下所設：當前時間（nonce）後的第一個負
載的IV設爲0；後繼的使用臨時對稱加密密鑰——Ke_i來加密的負載的IV是先前的負載經加密過
後的密文塊。加密過後的負載填充到最接近的塊大小。所有的填充字節都是0x00，除了最後一個字
節。最後一個填充字節的內容爲使用的填充字節數，包括它自己。注意，這就表示總是有填充的。
5.4 使用共享密鑰的第一階段協商

通過其它帶外（out-of-band）機制而衍生出來的密鑰也可用於驗證交換。這種密鑰實際的建立
過程已經超出了本文檔的範圍。

當進行共享密鑰驗證時，主模式定義如下：
發起者響應者
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
使用共享密鑰的積極模式描述如下：
發起者響應者
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->

當使用共享密鑰的主模式時，密鑰只能通過雙方的IP地址來進行識別，因爲HASH_I必須在發
起者處理IDir之前計算出來。積極模式允許使用大量的共享祕密的標識符。另外，積極模式還允許
雙方維持多個不同的共享密鑰，並能對一次特定的交換標識出正確的密鑰。
5.5 第二階段——快速模式

快速模式本身並不是一次完整的交換（因爲它和第一階段交換相關聯），但又作爲SA協商過程
（第二階段）的一部分用來衍生密鑰材料和協商非ISAKMP SA的共享策略。快速模式交換的信息
必須由ISAKMP SA來保護——即除了ISAKMP報頭外，所有的負載都要加密。在快速模式中，
HASH負載必須立即跟隨在ISAKMP報頭後，SA負載必須緊跟在HASH負載之後。HASH用於驗
證消息，同時也提供了參與的證據。
在一個特定的ISAKMP SA中，在ISAKMP報頭中的消息ID標識了快速模式正在進行中，而
ISAKMP SA本身由ISAKMP報頭中的cookie來標識。因爲每個快速模式的實例使用唯一的初始向
量（參看附錄B），這就有可能在一個ISAKMP SA中的任一時間內同時有多個快速模式在進行中。

快速模式基本上是一次SA協商和提供重放（replay）保護的當前時間（nonce）交換。當前時間
（nonce）用於產生新的密鑰材料並阻止通過重放***產生虛假的安全聯盟。可選的密鑰交換（KE）
負載可以經交換來實現通過快速模式產生附加的Diffie-Hellman交換以及求冪運算。但是必須支持使
用快速模式的密鑰交換負載成爲可選的。

基本的快速模式（沒有KE負載）更新第一階段的求冪運算所衍生出來的密鑰材料。這並不提
供PFS。使用可選的KE負載，執行額外的求冪運算，從而爲密鑰材料提供了PFS。

在快速模式中SA協商中的身份隱含假定爲ISAKMP雙方的IP地址，且沒有對協議或端口號隱
含施加限制，除非在快速模式中客戶標識符是指定的。如果ISAKMP代表另一方作爲客戶協商代表，
則雙方的身份必須傳遞爲IDci和IDcr。本地策略將決定是否接受身份指定的提議（proposal）。如果
客戶身份沒有被快速模式的響應者所接受（由於策略或其它原因），一個通知消息類型爲
INVALID-ID-INFORMATION (18)的通知負載將發出。

在雙方之間有多個隧道存在的情況下，客戶身份用於標識並指導流量進入對應的隧道，同時也
用於支持不同粒度的唯一和共享SA。

快速模式期間所發出的所有消息邏輯上是相關的並且必須一致。例如，如果KE負載被髮出，
描述Diffie-Hellman組的屬性（參看6.1節和[Pip97]）必須被包括在協商的 SA中的每個提議
（proposal）中的每個轉換（transform）之中。同樣的，如果使用了客戶身份，則它們必須應用到協
商的每個SA中。

快速模式定義如下：
發起者響應者
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->

其中：
HASH（1）是從ISAKMP報頭中的消息id（M-ID）開始，連接跟在hash後的整個消息的prf
結果,其中包括所有的負載頭，但不包括爲加密而加入的填充。HASH（2）和HASH（1）一樣，除
了發起者的不包含負載頭的當前時間（nonce）——Ni被增加在M-ID後，完整的消息之前。HASH
（2）中添加當前時間是爲了增加參與證據。用於參與的HASH（3）是用單個字節代表的值0，後
跟串聯着的消息id和除去負載頭的兩個當前時間（nonce）——先是發起者的，後跟響應者的nonce
的prf結果。換句話說，以上的交換的hash是：

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
除了HASH，SA，和可選的ID負載以外，快速模式沒有對負載順序的限制。當消息中的負載
順序不同於示例時，或當有可選的負載，如通知負載被鏈入到了消息中時，HASH（1）和HASH（2）
可以和上面的示例不同。

如果不需要PFS，並且沒有KE負載交換，則新的密鑰材料定義爲：
KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b)。
如果需要PFS且有KE負載交換，則新密鑰材料定義爲：
KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
其中快速模式中的g(qm)^xy是臨時Diffie-Hellman交換的共享祕密。
在任一種情況下，“協議”和“SPI”是從包含協商的轉換（transform）負載的ISAKMP提議負
載中得到的。

單個SA協商導致兩個安全聯盟—— 一個入，一個出。每個SA（一個由發起者選擇，另一個
有響應者選擇）的不同的SPI保證了每個方向有不同的密鑰。SA的目的地選擇的SPI用於衍生SA
的KEYMAT。

當需要的密鑰材料的長度大於prf所提供的長度時，KEYMAT就不斷的通過將prf的結果回填
給自己，並將結果串聯起來，直到滿足需要的長度。即：
KEYMAT = K1 | K2 | K3 | ...
其中
K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
等等。

這個密鑰材料（不論是否滿足PFS，和是直接衍生出，還是串聯而成）必須在協商的SA中使
用。而由服務來定義怎樣從密鑰材料中衍生密鑰。

在快速模式中使用臨時Diffie-Hellman交換的情況下，指數（g（qm）^xy）從當前狀態中不可
恢復的刪除掉，並且SKEYID_e和SKEYID_a（從第一階段協商中衍生）繼續用於保護和驗證ISAKMP
SA，同時SKEYID_d繼續用於衍生密鑰。

使用快速模式，多個SA和密鑰可以使用一個交換來協商，如下所示：
發起者響應者
----------- -----------
HDR*, HASH(1), SA0, SA1, Ni,
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA0, SA1, Nr,
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
密鑰材料和在單個SA的情況中一樣的衍生出來。在這種情況下（兩個SA負載的協商），結果
將是四個安全聯盟——每個方向兩個。
5.6 新組模式

新組模式不能在ISAKMP SA建立之前使用。新組的描述只能跟在第一階段協商之後。（雖然它r
也不是第二階段的交換）。
發起者響應者
----------- -----------
HDR*, HASH(1), SA -->
<-- HDR*, HASH(2), SA

其中HASH（1）是prf的輸出，它使用SKEYID_a作爲密鑰，從ISAKMP報頭中的消息ID開
始，串接整個SA的提議（包括頭和數據部分）作爲數據；HASH（2）也是prf的輸出，它使用SKEYID_a
作爲密鑰，同時從ISAKMP報頭中的消息ID開始，串接應答作爲數據。換種方式表達，上面交換
的hash爲：
HASH(1) = prf(SKEYID_a, M-ID | SA)
HASH(2) = prf(SKEYID_a, M-ID | SA)

提議將指定組的特性（參看附錄A，“屬性分配編號”）。私有組的組描述必須大於或等於2^15。
如果組不能被接受，響應者必須使用消息類型設爲ATTRIBUTES-NOT-SUPPORTED (13)的通知負載
來應答。

ISAKMP的實現可以要求私有組在建立的它的SA中設置超時。

組可以在主模式的SA提議中直接協商。對於MODP組來說，要達到這目的，必須將下列值作
爲SA的屬性來傳遞（參看附錄A）：類型、素數和產生器；對於EC2N組來說，需要類型、不可約
分多項式、組產生器1、組產生器2、組曲線A、組曲線B和組順序。另一方面，使用新組模式，組
的種類（nature）可以隱藏，同時在第一階段的協商中只有組標識符以明文方式傳遞。
5.7 ISAKMP信息交換

本協議在可能時保護ISAKMP信息交換。當使用本協議時，一旦ISAKMP安全聯盟已經建立（同
時SKEYID_e 和 SKEYID_a也已產生），則ISAKMP信息交換就如下所示：
發起者響應者
----------- -----------
HDR*, HASH(1), N/D -->

其中N/D要麼是ISAKMP通知（notify）負載，要麼是ISAKMP刪除（delete）負載，同時HASH
（1）是prf的輸出，它使用SKEYID_a作爲密鑰，而本交換唯一的M-ID和串接的整個信息負載（通
知負載或者刪除負載）作爲數據。換種方式表達，上面交換的hash爲：
HASH(1) = prf(SKEYID_a, M-ID | N/D)

和提到過的一樣，ISAKMP報頭中的消息ID——也用在prf的計算中——是這個交換中唯一的，
不能和產生這次信息交換的第二階段交換中的另一個消息ID相同。使用SKEYID_e來加密這個消息
時，初始向量的導出在附錄B中描述。

如果ISAKMP安全聯盟在信息交換時還沒有建立，則交換就以明文發送，同時沒有HASH負載。
6 Oakley組

使用IKE，進行Diffie-Hellman交換的組是協商而得的。下面定義了四個組，從1到4。這些組
起源於Oakley協議，因此被稱爲“Oakley組”。組的屬性類在附錄A中定義。所有大於等於2^15
的值都作爲私有組的標識符。對於缺省Oakley組強度的討論，請參考下面的安全考慮一節。

這些組都是由Richard Schroeppel在Arizona大學中創造出來的。它們的屬性在[Orm96]中描述。
6.1 第一個Oakley缺省組

Oaklay的實現必須支持有下列素數和產生器的MODP組。這個組分配的id號爲1。
素數爲: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
它的16進制值爲：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
產生器爲：2
6.2 第二個Oakley組
IKE的實現必須支持有下列素數和產生器的MODP組。這個組分配的id號爲2。
素數爲2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }。
它的16進制值爲：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
產生器爲2（十進制）。
6.3 第三個Oakley組

IKE的實現應該支持有下列特徵的EC2N組：組被分配的id號爲3。曲線是基於伽羅瓦域
GF[2^155]，域大小爲155。域的不可約多項式爲：
u^155 + u^62 + 1
橢圓曲線的方程爲：
y^2 + xy = x^3 + ax^2 + b
域大小：155
組素數/不可約多項式：0x0800000000000000000000004000000000000001
組產生器1：0x7b
組曲線A：0x0
組曲線B：0x07338f
當使用這個組時，KE負載中的數據就是解答（x，y）中的值x，曲線上點的選擇是通過隨機選
擇祕密Ka並計算Ka*P而來，其中*代表組相加並加倍的不斷重複的操作，P是x座標等於產生器1
的值，y座標爲由所定義的方程計算出的值所確定的曲線上的一點。曲線的方程式由組類型和係數A
和B隱含確定。對於y座標有兩個可能的值；任何一個都可成功的使用（雙方不需要對選擇達成共
識）。
6.4 第四個Oakley組
IKE的實現應該支持有下列特徵的EC2N組：組被分配的id號爲4；曲線是基於伽羅瓦域
GF[2^185]，域大小爲185。域的不可約多項式爲：
u^185 + u^69 + 1
橢圓曲線的方程爲：
y^2 + xy = x^3 + ax^2 + b
域大小：185
組素數/不可約多項式：0x020000000000000000000000000000200000000000000001
組產生器1：0x18
組曲線A：0x0
組曲線B：0x1ee9
當使用這個組時，KE負載中的數據和使用Oakley組3時一樣。

使用新組模式也可定義其它組。這些組是由Richard Schroeppel在Arizona大學中創建出來的。
這些素數的特性在[Orm96]中定義。
7. 完整IKE交換的負載爆炸
這一節說明IKE協議的使用目的：
—在ISAKMP進程間（第一階段）建立一個安全並經過驗證的信道；同時
—爲IPsec SA（第二階段）產生密鑰材料，並協商。
7.1 使用主模式的第一階段

下列圖表說明在雙方的第一個傳輸往返的交換中的負載交換。發起者可以提出多個提議；響應
者只能用一個來回答。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_SA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ prefered SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ alternate SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

響應者選擇一個轉換的（transform）提議（ISAKMP SA的屬性）來應答。

第二個交換由下列負載組成：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_KE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ D-H Public Value (g^xi from initiator g^xr from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ni (from initiator) or Nr (from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

共享密鑰SKEYID_e和SKEYID_a現用於保護和驗證所有後繼的通信。注意SKEYID_e和
SKEYID_a都未經過驗證。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_ID and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SIG ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data of the ISAKMP negotiator ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ signature verified by the public key of the ID above ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

如5.1節所描述的一樣，密鑰交換是用簽名的hash來驗證的。一旦簽名使用作爲ISAKMP SA
協商的一部分的驗證算法來校驗且通過了，則共享密鑰、SKEYID_e和SKEYID_a可以被認爲經過
驗證了。（爲簡潔起見，證書負載沒有被交換）。

7.2 使用快速模式的第二階段

下列負載在進行ISAKMP SA協商的快速模式的第一個傳輸往返中交換。在這假設的交換中，
ISAKMP協商者作爲其它需要驗證的部分的代表。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SA ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ keyed hash of message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! AH_SHA | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! AH_MD5 | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of source for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of destination for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中hash的內容如上面5.5節的描述。響應者使用只包含一個轉換的相似消息來應答——選擇
的AH轉換（transform）。依賴於接受，發起者通過協商的安全聯盟和密鑰材料可以提供密鑰引擎。
作爲對重放***的檢查，響應者等待直到收到下一個消息。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ hash data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中hash的內容在上面的5.5節中描述。
8. 完全後繼保密舉例

本協議能提供對密鑰和身份的PFS。不但ISAKMP協商雙方的身份可以由PFS保護，如果可用
的話，連雙方爲誰進行協商的身份都可以保護。

要爲密鑰和全部的身份提供完全後繼保密，雙方要執行下列操作：

o 一次主模式交換來保護ISAKMP雙方的身份。
這就建立了一個ISAKMP SA。
o一次快速模式交換來協商其它安全協議保護。
這就在這個協議的兩端建立了一個SA。
o刪除ISAKMP SA和與它相關的狀態。

因爲在非ISAKMP SA中使用的密鑰是從單個臨時Diffie-Hellman交換中衍生出的，PFS是保留
的。

如只是爲非ISAKMP安全聯盟的密鑰提供完全後繼保密，則在ISAKMP SA已經在兩端存在的
情況下，就沒有必要進行第一階段的交換了。所有需要的只是一個包含可選的KE交換的快速模式
和一次額外的Diffie-Hellman交換。在這一步上，如同5.5節所描述的一樣，從快速模式衍生出來的
狀態必須從ISAKMP SA中刪除。
9.實現提示

使用單個ISAKMP第一階段協商使得後繼的第二階段協商非常的快。只要第一階段的狀態保留
在緩存中，並且不需要PFS，第二階段就可以進行而不用進行求冪運算。在單個第一階段協商後，
可以有多少個第二階段協商，這取決於本地策略。其決定依賴於使用的算法的強度和雙方系統的信
賴等級。

實現中可能希望在執行快速模式時，能夠協商一系列的SA。通過這樣，可以加快“重新生成密
鑰”的速度。快速模式定義一系列SA的KEYMAT是怎樣確定的。當一方覺得需要改變SA時，只
需要簡單的使用聲明過的一系列SA中的下一個。一系列SA可以通過在一次快速模式中協商多個
SA（同樣的屬性，不同的SPI）來建立。

一個很有用的優化方法是在雙方需要安全聯盟之前就建立它，這樣當需要時就已經有了。這樣
確保在最初的數據發送前沒有因密鑰管理而產生的延遲。這種優化很容易實現，通過在每次請求安
全聯盟時設置多個安全聯盟並將還沒有被使用的緩存起來。

同樣，如果ISAKMP的實現知道很快就需要SA時（例如，替換一個很快就到期的SA），就可
以在需要它之前建立一個新的SA。

基本的ISAKMP規範描述了協議的一方可以通知另一方一些活動的條件——刪除安全聯盟或對
一些錯誤的響應，如簽名校驗失敗或負載解密失敗。強烈建議這些信息交換在任何情況下都不要響
應。否則會引致“通知之戰”——對一個消息的理解失敗則發出通知給對方，而對方又不能理解，
又發出自己的通知，但這仍然是不可理解的。
10.安全考慮

本文檔討論的是一種混合協議，將部分的Oakley以及部分的SKEME和ISAKMP相合並，用來
以一種安全和經過驗證的方式協商安全聯盟，併爲之衍生密鑰材料。

機密性由使用協商的加密算法來保證。驗證由使用協商的方法來保證：數字簽名算法；支持加
密的公鑰算法；或共享密鑰。交換的機密性和驗證相當於作爲ISAKMP安全聯盟的一部分來協商的
屬性。

使用快速模式來不停的重新生成密鑰會消耗Diffie-Hellman共享祕密的信息量。實現者應該注意
到這個事實並在相同冪期間限制快速模式的交換。

本協議是可以實現密鑰材料和身份的完全後繼保密（PFS）的，通過指定Diffie-Hellman組，並
在KE負載中傳遞公共值，ISAKMP雙方可以建立密鑰的PFS——而身份應該由ISAKMP SA的
SKEYID_e來保護，因此不需要由PFS來保護。如果密鑰和身份的PFS都需要，則ISAKMP雙方必
須對每個ISAKMP SA只建立一個非ISAKMP 安全聯盟（例如：IPsec安全聯盟）。密鑰和身份的PFS
通過在建立單個非ISAKMP SA基礎上刪除ISAKMP SA（可選的發出DELETE消息）來完成。這種
方式中，第一階段協商唯一的和單個第二階段協商相綁定，同時在第一階段協商中建立的ISAKMP
SA 就不再使用了。
從使用已定義的任何組的Diffie-Hellman交換中衍生出的密鑰的強度依靠於組本身的強度、使用
的指數的大小、以及使用的隨機數產生器提供的信息量。根據這些輸入很難確定任何定義組的密鑰
強度。缺省的Diffie-Hellman組（第一組）和一個強隨機數產生器以及不少於160比特的指數一起使
用時，足夠用於DES了。第二組到第四組提供更強的安全性。實現中在建立策略和協商安全參數時
應該考慮到這些保守的估計。

注意，這些限制是對Diffie-Hellman組自身的。IKE中沒有限制使用更強的組，也不會減弱從更
強組中得到的強度。事實上，IKE的可擴展的框架支持定義更多的組；使用橢圓曲線組會大大的增
加使用更小的數字時的強度。

在已定義的組沒有提供足夠強度的情況下，可以使用新組模式來交換能提供必要強度的
Diffie-Hellman組。具體的實現有責任檢查提供的組的基本性質並且能獨立的達到估計的強度。

總是假設交換中的Diffie-Hellman指數在使用過後就從內存中刪除了。更爲具體的，這些指數不
能從長期存在的祕密，如僞隨機數產生器中的種子（seed）中衍生。

IKE交換維持不斷改變的初始向量（IV），即最後的消息的最後的密文塊就是下一個消息的IV。
爲阻止重播（或有着有效cookie的僞造消息）引起同步IKE產生交換，實現中不能立即更新IV，除
非解密的消息通過了基本的完整性檢查並且被用於實際改變IKE狀態機——也就是說，這不是一個
重播消息。

雖然主模式的最後一個傳輸往返（以及積極模式可選的最後一個消息）是加密的，但嚴格的說，
它們並沒有驗證。一個密文形式的主動置換***會導致負載損壞。如果這樣的***破壞了強制性的
負載，它將會由於驗證失敗而被發現，但如果它破壞了任何可選的負載（例如鏈接到主模式交換中
最後一個消息前的通知負載），它就不會被發覺。

11.IANA考慮

本文檔包含許多由IANA維護的“幻數”。這一節解釋由IANA使用來在每一個列表中分配另外
的數字的標準。
11.1 屬性類

本協議中協商的屬性由它們的種類來識別。分配一個新種類的請求必須伴隨一個描述這些屬性
的使用的標準跟蹤RFC。
11.2 加密算法類

在本文檔中使用的加密算法種類的值定義了一個使用的加密算法。分配一個新加密算法值的請
求必須伴隨對一個標準跟蹤或信息RFC的參考，或對描述這個算法的已出版的密碼學書籍的參考。
11.3 hash算法

在本文檔中使用的hash算法中類的值定義了一個使用的hash算法。分配一個新hash算法值的
請求必須伴隨對一個標準跟蹤或信息RFC的參考，或對描述這個算法的已出版的密碼學書籍的參考。
由於在IKE中，密鑰衍生和密鑰擴展使用hash算法的HMAC形式，分配一個新hash算法值的請求
必須考慮到hash算法自身的密碼的特性——例如它的抗衝突性。
11.4 組描述和組類型

組描述種類的值標識在Diffie-Hellman交換中使用的組。組類型類的值定義組的類型。分配一個
新組的請求必須伴隨對一個描述這個組的標準跟蹤或信息RFC的參考。分配一個新組類型的請求必
須伴隨對一個標準跟蹤或信息RFC的參考，或對描述這個新類型的已出版的密碼學書籍或數學書籍
的參考。

11.5 存活期類型

存活期類型種類的值定義了ISAKMP安全聯盟中使用的存活期類型。分配新存活期類型的請求
必須伴隨一個對這個類型的單位和它的到期值的詳細的描述。
12. 鳴謝

本文檔是和Hugo Krawczyk，Douglas Maughan，Hilarie Orman， Mark Schertler， Mark Schneider，
以及Jeff Turner通過仔細榷商而得的。它依靠於由他們編寫的協議。如果沒有他們的興趣和貢獻，
本文檔是不可能寫成的。

特別對Rob Adams，Cheryl Madson，Derrell Piper，Harry Varnis，和Elfed Weaver一直的技術支
持，鼓勵以及各種完整性檢查表示感謝。

我們也要感謝許多IPSec工作組的成員，他們在過去的許多年裏一直對本協議的發展做着貢獻。

13.參考
[CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
May 1997.

[BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr.
Dobb's Journal, v. 19, n. 4, April 1994.

[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption", American National Standards
Institute, 1983.

[DH] Diffie, W., and Hellman M., "New Directions in
Cryptography", IEEE Transactions on Information Theory, V.
IT-22, n. 6, June 1977.

[DSS] NIST, "Digital Signature Standard", FIPS 186, National
Institute of Standards and Technology, U.S. Department of
Commerce, May, 1994.

[IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992

[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.

[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security.

[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992.

[MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.

[Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.

[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard",
November 1993.

[Pip98] Piper, D., "The Internet IP Security Domain Of
Interpretation for ISAKMP", RFC 2407, November 1998.

[RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's
Journal, v. 20, n. 1, January 1995.

[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems",
Communications of the ACM, v. 21, n. 2, February 1978.

[Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms,
and Source Code in C", 2nd edition.

[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue
of Standards and Technology, U.S. Department of Commerce,
May 1994.

[TIGER] Anderson, R., and Biham, E., "Fast Software Encryption",
Springer LNCS v. 1039, 1996.

附錄A

下面是是DES的弱和半弱密鑰的列表。這些密鑰從[Sch96]中得來。所有的密鑰以16進制列出。
DES 弱密鑰：
0101 0101 0101 0101
1F1F 1F1F E0E0 E0E0
E0E0 E0E0 1F1F 1F1F
FEFE FEFE FEFE FEFE

DES 半弱密鑰：
01FE 01FE 01FE 01FE
1FE0 1FE0 0EF1 0EF1
01E0 01E0 01F1 01F1
1FFE 1FFE 0EFE 0EFE
011F 011F 010E 010E
E0FE E0FE F1FE F1FE

FE01 FE01 FE01 FE01
E01F E01F F10E F10E
E001 E001 F101 F101
FE1F FE1F FE0E FE0E
1F01 1F01 0E01 0E01
FEE0 FEE0 FEF1 FEF1

屬性分配號碼

第一階段的屬性協商使用下列定義。第二階段的屬性定義在可應用的DOI規範中（例如，IPsec
屬性定義在IPsec DOI中），除了在快速模式中包含一個臨時Diffie-Hellman交換時的組描述。屬性
類型可以是基本（B）或是變長（V）。這些屬性的編碼在基本ISAKMP規範中定義爲類型/值（基本）
和類型/長度/值（變長）。

被描述爲基本的屬性不能作爲變長來編碼。而如果變長屬性的值在能裝在兩個字節的情況下，
可以作爲基本屬性來編碼。在這種情況下，本協議的發起者提供的變長（或基本）屬性可能作爲基
本（或變長）返回給發起者。

屬性種類

種類值類型
-----------------------------------------------------------------------------------------
加密算法 1 B
Hash算法 2 B
驗證方法 3 B
組描述 4 B
組類型 5 B
組素數/不可約多項式 6 V
組產生器1 7 V
組產生器2 8 V
組曲線A 9 V
組曲線B 10 V
存活期類型 11 B
存活期長度 12 V
PRF 13 B
密鑰長度 14 B
域大小 15 B
組順序 16 V

值17-16383保留給IANA。值16384-32767用於相互同意的雙方私下使用。

種類值

- 加密算法定義在
DES-CBC 1 RFC 2405
IDEA-CBC 2
Blowfish-CBC 3
RC5-R16-B64-CBC 4
3DES-CBC 5
CAST-CBC 6

值7-65000保留給IANA。值 65001-65535在相互同意的雙方之間私下使用。
- Hash算法定義在
MD5 1 RFC 1321
SHA 2 FIPS 180-1
Tiger 3 參看[TIGER]

值4-65000保留給IANA。值65001-65535在相互同意的雙方之間私下使用。
-驗證方法
共享密鑰 1
DSS簽名 2
RSA 簽名 3
使用RSA加密 4
修改過的RSA加密 5

值6-65000保留給IANA。值65001-65535在相互同意的雙方之間私下使用。
- 組描述
缺省768比特 MODP 組（6.1節） 1

另一個1024比特 MODP組（6.2節） 2

使用GP[2^155]的EC2N組（6.3節） 3

使用GP[2^185]的EC2N組（6.4節） 4

值5-32767保留給IANA。值32768-65535在相互同意的雙方之間私下使用。
- 組類型
MODP （模求冪組） 1
ECP (基於GF[P]的橢圓曲線組) 2
EC2N (基於GF[2^N]的橢圓曲線組) 3

值4-65000保留給IANA。值65001-65535在相互同意的雙方之間私下使用。
- 存活期類型
秒 1
千字節 2

值3-65000保留給IANA。值65001-65535在相互同意的雙方之間私下使用。對於給定的“存活
期類型”，“存活期長度”屬性的值定義SA存活期的實際長度——或者爲秒數，或者爲保護的千字
節數。
- PRF
當前沒有定義的僞隨機函數。

值6-65000保留給IANA。值65001-65535在相互同意的雙方之間私下使用。
- 密鑰長度

當使用有可變長度密鑰的加密算法時，這個屬性以比特爲單位指定了密鑰的長度。（必須使用網
絡字節序）。當指定的加密算法使用固定長度密鑰時，這個屬性不能使用。
- 域大小
以比特爲單位的Diffie-Hellman組的域大小。
- 組順序
橢圓曲線組的組順序。注意這個屬性的長度依賴於域大小。
定義的額外交換-- XCHG值
快速模式 32
新組模式 33

附錄B

附錄描述了只在進行ISAKMP消息加密時使用的加密細節。當服務（例如IPSEC轉換
（transform））利用ISAKMP來產生密鑰材料時，所有加密算法的特定細節（例如密鑰和IV的產生，
填充，等等）必須由這個服務來定義。ISAKMP不支持產生的密鑰可適用於任何加密算法。ISAKMP
產生請求數量的密鑰材料，而服務必須產生適合的密鑰。細節，例如弱密鑰檢查，是服務的責任。

由於本文檔採用的PRF回饋機制，使用協商的PRF可能會要求PRF的輸出被擴充。例如，如
果（ficticious）DOORAK-MAC要求24字節的密鑰，但只產生了8字節的輸出，則輸出在被用作密
鑰前，必須通過將它作爲自己的另一個實的密鑰來擴充到3倍的大小。PRF的輸出擴充是通過將
PRF的結果回饋給自己以產生連續的塊。不斷地將這些塊串聯起來，直到達到了需要的長度。例如，
對於用DOORAK-MAC作爲協商的PRF的共享密鑰驗證：
BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b)
BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b)
BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b)
以及
SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24

同樣來衍生SKEYID_d:

後繼的PRF的衍生作同樣的處理。

用於保護ISAKMP SA的加密密鑰用算法特定的方式從SKEYID_e中衍生。當SKEYID_e用來
提供算法需要的所有必要的密鑰材料時出現不夠長的情況，就通過回饋僞隨機函數的結果給自己，
並將結果串聯起來，最後從高位開始取需要的比特數的方法來衍生密鑰。

例如，如果（ficticious）算法AKULA要求320比特的密鑰（且沒有弱密鑰檢查），同時用於產
生SKEYID_e的prf只產生了120比特的材料，則AKULA的密鑰將是Ka的頭320比特，其中：
Ka = K1 | K2 | K3
且
K1 = prf(SKEYID_e, 0)
K2 = prf(SKEYID_e, K1)
K3 = prf(SKEYID_e, K2)

其中prf是協商的prf或是協商的HMAC版本的hash函數（如果沒有協商prf），同時0由一個
字節來代表。每個prf提供總的360比特中的120比特的材料。AKULA將使用360比特串中的頭320
比特。

在第一階段，對於CBC模式加密算法的初始向量材料（IV材料）是從hash值中衍生出來的，
而這個hash值是使用協商的hash算法對串聯起來的發起者的公共Diffie-Hellman值和響應者的公共
Diffie-Hellman值進行hash運算所得的。這隻對頭一個消息使用。每個消息應該用包含0x00的字節
來填充到最接近的塊大小。報頭中的消息長度必須包括填充字符的長度，因爲這反映了密文的長度。
後繼的消息必須使用前一個消息的最後一個CBC加密塊來作爲自己的初始向量。

在第二階段，快速模式的第一個消息中的CBC模式加密的初始向量材料是從hash值中衍生的，
這個hash值是使用協商的hash算法對串聯的第一階段的最後一個CBC輸出塊和第二階段的消息ID
進行hash運算所得的。快速模式交換中的後繼消息的IV是前一個消息的CBC輸出塊。後繼消息的
填充和IV處理和第一階段中的處理一樣。

在ISAKMP SA已經被驗證後，所有的消息交換都使用SKEYID_e進行加密。這些交換的初始
向量的衍生方式和快速模式中一模一樣——即從串聯的第一階段最後的CBC輸出塊和ISAKMP信
息交換報頭中的消息ID（不是引起信息交換的消息中的消息ID）的hash值中衍生出來。

注意，第一階段的最後一個CBC輸出塊，即第一階段的最後一個消息的加密/解密的結果必須
保持在ISAKMP SA狀態中，以允許每個快速模式產生唯一的IV。每個第一階段後期（快速模式和
信息交換）獨立的產生IV以阻止兩個不同的交換同時發生時從同步中獲得IV。

在所有的情況下，有一個雙向密碼/IV上下文。使每個快速模式和信息交換維持一個唯一的上下
文可以阻止從同步中獲得IV。

DES-CBC的密鑰是從SKEYID_e的頭8個非弱和非半弱（參看附錄A）字節中衍生出來的。IV
是上面衍生出的IV材料中的頭8個字節。

IDEA-CBC的密鑰是從SKEYID_e的頭16個字節中衍生出來的。IV是上面衍生出的IV材料中
的頭8個字節。

Blowfish-CBC的密鑰要麼是協商的密鑰大小，要麼是從上述的僞隨機函數回饋方法中衍生的密
鑰的頭56個字節（如果沒有協商密鑰的大小）。IV是從上面衍生的IV材料的頭8個字節。

RC5-R16-B64-CBC的密鑰大小或者是協商的大小，或者是在必要時由前述的僞隨機函數回饋法
衍生的密鑰的頭16個字節（如果沒有協商密鑰的大小）。IV是從上面衍生的IV材料的頭8個字節。
循環的數目必須是16且塊大小必須爲64。

3DES-CBC的密鑰是由前述的僞隨機函數回饋法衍生的密鑰的頭24個字節。3DES-CBC分別使
用3DES-CBC密鑰的頭、中間和最後的8個字節來進行加密—解密—加密操作。IV是從上面衍生的
IV材料的頭8個字節。

CAST-CBC的密鑰大小是協商的大小，或者是在必要時由前述的僞隨機函數回饋法衍生的密鑰
的頭16個字節。IV是從上面衍生的IV材料的頭8個字節。

除了DES-CBC外，支持其它的算法是完全可選的。一些可選的算法可能要服從知識產權的聲明。

【簡寫Mybatis-02】註冊機的實現以及SqlSession處理

手繪二維碼

.NET藉助虛擬網卡實現一個簡單異地組網工具

Cisco ××× 詳細配置

linux 安裝的體會

linux　fedora 11 硬盤安裝方法

一切即將剛開始

IPSec 中文RFC

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結