Network Working Group R. Atkinson
Request for Comments: 1827 Naval Research Laboratory
Category: Standards Track August 1995
IP封裝安全載荷（ESP）
本備忘錄的狀態(tài)
這篇文檔詳述了Internet community中的一個internet標(biāo)準(zhǔn)棧協(xié)議，并且請求對于這個標(biāo)準(zhǔn)棧協(xié)議的討論和建議。標(biāo)準(zhǔn)化的狀態(tài)和協(xié)議的狀態(tài)請參考internet官方協(xié)議標(biāo)準(zhǔn)（std1）. 發(fā)布本備忘錄的發(fā)放不受限制。
摘要
此篇文檔描述了IP封裝安全載荷（ESP）。ESP是為IP數(shù)據(jù)包提供完整性和機(jī)密性的一種機(jī)制。在某些情況下也可用于IP數(shù)據(jù)包的安全認(rèn)證。此機(jī)制可用于IPv4和IPv6。
1 介紹
ESP是為IP數(shù)據(jù)包提供完整性和機(jī)密性的一種機(jī)制。它也能在特定的認(rèn)證算法和算法模型的基礎(chǔ)上提供身份認(rèn)證。ESP不提供流量分析的不可否認(rèn)性和保護(hù)**。IP認(rèn)證頭（AH）使用一定的認(rèn)證算法[Atk95b]可以實(shí)現(xiàn)不可否認(rèn)**。IP認(rèn)證頭可以和ESP結(jié)合起來使用以提供身份認(rèn)證的服務(wù)。用戶如果只想實(shí)現(xiàn)信息完整性和身份認(rèn)證服務(wù)而不想實(shí)現(xiàn)機(jī)密**，則可以選擇IP認(rèn)證頭（AH）協(xié)議來取代ESP。本文假設(shè)讀者已經(jīng)熟悉相關(guān)文檔“IP安全架構(gòu)”，它定義了用于IPv4和IPv6的總的INTERNET層的安全架構(gòu)，并且提供了對于這篇描述文檔的重要背景。[Atk95a]
1． 1綜述
IP封裝安全載荷（ESP）試圖提供信息的機(jī)密性和完整**，方法是將被保護(hù)的數(shù)據(jù)加密并把被加密的數(shù)據(jù)放入IP封裝安全載荷（ESP）的數(shù)據(jù)部分。根據(jù)用戶的安全需求，此機(jī)制可以被用于加密傳輸層段（例如：TCP,UDP,ICMP,IGMP）,也可用來加密一個完整的IP 數(shù)據(jù)包。為了保證完整原始數(shù)據(jù)包的機(jī)密性，封裝被保護(hù)的數(shù)據(jù)是必須的。
在共享系統(tǒng)中使用此規(guī)范會增長IP協(xié)議處理的代價(jià)。使用此規(guī)范也會增長信息通訊的延遲時(shí)間。延遲時(shí)間的增長主要是由包含在一個ESP中的每個IP數(shù)據(jù)包都需要的加密和解密過程引起的。
在隧道模式的ESP中，原始的IP數(shù)據(jù)包被放置于ESP的被加密部分，然后將完整的ESP幀放入一個數(shù)據(jù)包內(nèi)，此數(shù)據(jù)包有一個未加密的IP報(bào)頭。未加密的IP數(shù)據(jù)報(bào)頭中的信息被用來將安全數(shù)據(jù)包從源地址發(fā)送到目的地址。一個未加密的IP路由報(bào)頭可以被包括在IP報(bào)頭和ESP之間。
在傳輸模式的ESP中，ESP頭被插入到IP數(shù)據(jù)包中傳輸層協(xié)議報(bào)頭（例如，TCP,UDP,或者 ICMP）的前面。在此模式下，因?yàn)闆]有加密的IP報(bào)頭或者IP選項(xiàng)所以帶寬被保護(hù)。
在IP中，一個IP認(rèn)證頭可以用來作為一個未加密信息報(bào)的頭部或者在一個傳輸模式的ESP信息報(bào)中位于IP報(bào)頭和ESP報(bào)頭之間，也可以作為一個報(bào)頭位于一個隧道模式的ESP信息報(bào)的加密部分。當(dāng)一個AH同時(shí)出現(xiàn)在純文本的IP報(bào)頭和單個信息包的隧道模式ESP頭之內(nèi)時(shí)，未加密的IPv6認(rèn)證主要被用于向未加密的IP頭的內(nèi)容提供保護(hù)，加密的認(rèn)證頭被用于向加密的IP信息包提供報(bào)頭驗(yàn)證。本文稍后詳述。
IP封裝安全載荷的組織結(jié)構(gòu)與別的IP有效載荷有很大不同。ESP有效載荷的第一個成分是有效載荷的未加密域。第二個部分是加密的數(shù)據(jù)。未加密 ESP報(bào)頭的域通知預(yù)期的接收者怎樣合適的解密和處理加密的數(shù)據(jù)。被加密的數(shù)據(jù)部分包括用于安全協(xié)議的受保護(hù)域以及加密封裝的IP數(shù)據(jù)包。
安全聯(lián)合的概念是ESP的重要的基礎(chǔ)部分。它在相關(guān)文檔“Security Architecture for the Internet Protocol” 被詳細(xì)的描述。執(zhí)行者應(yīng)該在讀此篇文檔之前讀那篇文檔。
1．2 需求的術(shù)語定義
在本文檔中，通常被大寫的單詞用來定義一個特定的要求（REQUIREMENT）的重要程度。這些單詞是：
－MUST（必須）
這個單詞和近意詞"REQUIRED"意謂它們所指的項(xiàng)在規(guī)范中是絕對必須,不可缺少的。
－SHOULD(應(yīng)該)
此單詞和近意詞“RECOMMENDED"修飾的條款，在特定的環(huán)境下，由于某些合理原因存在，是可以忽略的。但是此條款的完整含義必須被理解，在采取不同的方針之前，應(yīng)該特別重視所處的場合。
－MAY（可以）
這個單詞和它的近意詞“OPTIONAL"意謂著它們所指的特定項(xiàng)確實(shí)是可選的。一個產(chǎn)品提供商（vendor）可能為了一個特別的商務(wù)用途的需要或者增強(qiáng)它的產(chǎn)品（例如：別的商家可能忽略此項(xiàng)目）而將此項(xiàng)條目包括進(jìn)來。
2 密鑰管理
密鑰管理是IP安全架構(gòu)的一個重要部分。然而，一個特定的密鑰管理協(xié)議并沒有包括在本篇說明文檔中，這是因?yàn)殚L期以來，在各種公開的著作中，涉及到密鑰管理的算法和協(xié)議存在很多細(xì)微的錯誤。IP盡量分離密鑰管理機(jī)制和安全協(xié)議機(jī)制之間的關(guān)聯(lián)。在密鑰管理機(jī)制和安全協(xié)議機(jī)制之間的唯一聯(lián)系是安全參數(shù)索引（SPI），SPI在后面將更詳盡的描述。這種分離允許幾種不同的密鑰管理機(jī)制被使用。更重要的是，它允許在密鑰管理協(xié)議被更換或者修正的時(shí)候，安全協(xié)議機(jī)制不會受到過度的影響。因此，一個IP的密鑰管理協(xié)議不會在本文檔中詳述。在IP安全架構(gòu)中將會更詳盡的描述密鑰管理并且詳述用于IP的密鑰管理需求。參考文獻(xiàn)[Atk95a]包容了這些密鑰管理需求。
密鑰管理機(jī)制被用于協(xié)商每個安全關(guān)聯(lián)中的參數(shù)。這些參數(shù)不僅包括密鑰本身而且還包括其他的信息（例如：加密算法和加密模型，安全分類的級別，等等），所有的這些都將被通信的雙方所使用。密鑰管理協(xié)議的實(shí)現(xiàn)通常創(chuàng)造和維護(hù)一個邏輯表，此表中包含了每個當(dāng)前安全關(guān)聯(lián)中的參數(shù)。一個ESP的實(shí)現(xiàn)通常需要通過讀安全參數(shù)表來決定如何處理每一個包含ESP的數(shù)據(jù)包（例如：采取哪個算法或模型以及何種密鑰）。
3 封裝安全有效載荷的語法
封裝安全有效載荷（ESP）可能出現(xiàn)在IP頭之后和最后傳輸層協(xié)議之前的任何地方。IANA（Internet Assigned Numbers Authority，負(fù)責(zé)全球Internet的IP地址編號分配的機(jī)構(gòu)）已經(jīng)分配了協(xié)議號50給ESP[STD-2]。ESP 頭前的那個報(bào)頭總是在它的NEXT Header（IPV6）或者協(xié)議（IPV4）域中寫入值50。ESP由一個未加密的報(bào)頭和加密的數(shù)據(jù)部分組成。加密的數(shù)據(jù)既包括被保護(hù)的ESP 頭也包括被保護(hù)的用戶數(shù)據(jù)。而用戶數(shù)據(jù)或者是一個完整的IP 數(shù)據(jù)包，也可能僅僅是一個上層協(xié)議部分（例如： TCP 或者 UDP）。一個安全數(shù)據(jù)包的高層圖表如下所示：
|<-- Unencrypted -->|<---- Encrypted ------>|
+-------------+--------------------+------------+---------------------+
| IP Header | Other IP Headers | ESP Header | encrypted data |
+-------------+--------------------+------------+---------------------+
ESP報(bào)頭的更詳細(xì)的圖表如下所示
+-------------+--------------------+------------+---------------------+
| Security Association Identifier (SPI), 32 bits |
+=============+====================+============+=====================+
| Opaque Transform Data, variable length |
+-------------+--------------------+------------+---------------------+
加密和認(rèn)證算法以及與它們相關(guān)聯(lián)的不透明變換數(shù)據(jù)的精確格式被稱作變換（“transform”）。ESP格式被設(shè)計(jì)成為支持新的變換，從而可以在將來支持新的或者額外的加密算法。變換被自身詳細(xì)說明，而不是在此篇文檔的主體部分被詳述。用于與IP一起使用的強(qiáng)制轉(zhuǎn)換被定義在一個獨(dú)立文檔中 [KMS95]。別的可選變換存在于別的說明文檔中，附加的變換可能在將來定義。
3．1 封裝安全有效載荷的域
SPI 是一個32位的偽隨機(jī)值，它用來確定數(shù)據(jù)包的安全關(guān)聯(lián)。如果不建立安全關(guān)聯(lián)，SPI 域的值就應(yīng)該是0x00000000。一個SPI 類似于別的安全協(xié)議中的SAID。因?yàn)?在此處SPI 的語意和別的安全協(xié)議中的SAID不是完全相同，所以名字不一樣。
SPI的值的集合中，從0x00000001到 0x000000FF 是被保留給 IANA 的，以用于將來的使用。除非在一篇 RFC 中公開的說明一個特定的被保留的 SPI 值已經(jīng)被分配，否則保留的 SPI 值通常不能被分配。
SPI 是唯一的強(qiáng)制的不受約束的變換域。特定的變換可能有別的對于變換來說是獨(dú)有的域。變換在此篇文檔中不會被詳述。
3．2 ESP 的安全標(biāo)記
加密的 IP 數(shù)據(jù)包不必要并且通常也不包含任何明確的安全標(biāo)簽因?yàn)?SPI 指明了敏感級別。這是對當(dāng)前 IPv4 實(shí)施方案的一個改進(jìn)，當(dāng)前的實(shí)施方案通常在分割模式工作站以及別的需要安全標(biāo)簽的系統(tǒng)中使用一個明確的敏感標(biāo)簽[Ken91] [DIA]。在一些情況下，用戶可以選擇在使用 ESP 提供的不明確的標(biāo)簽的同時(shí)添加一個明確的標(biāo)簽（例如： RFC1108 中定義的IPSO 標(biāo)簽，可以在IPv4中被使用）。明確標(biāo)簽的選項(xiàng)能夠被定義與 IPv6 一起使用（例如，使用 IPv6 端到端的選項(xiàng)報(bào)頭或者IPv6 的逐跳路由的可選報(bào)頭）。ESP 的執(zhí)行可以同時(shí)支持非明確的標(biāo)簽和明確的標(biāo)簽，但是不是必須要求支持明確標(biāo)簽。ESP 在要求提供多級安全的系統(tǒng)中實(shí)施的時(shí)候必須支持不明確的標(biāo)簽。
4 封裝安全協(xié)議的處理過程
此節(jié)描述了當(dāng) ESP 在兩個互連的實(shí)體間使用時(shí)實(shí)施的步驟。多播與單播的僅在密鑰管理上不同（細(xì)節(jié)請看看上面的 SPI定義）。ESP 有兩種使用模式。第一種被稱做隧道模式，在ESP內(nèi)封裝一個完整的 IP數(shù)據(jù)包。第二個模式稱為傳輸模式，在ESP內(nèi)封裝一個傳輸層的幀（如UDP,TCP）。術(shù)語傳輸模式一定不能被誤解僅限于TCP 和UDP。例如，一個IMCP 消息在不同環(huán)境下既可以通過傳輸模式發(fā)送也可以通過隧道模式發(fā)送。ESP 的處理過程發(fā)生在發(fā)送時(shí)的 IP 分割之前以及接受時(shí)的IP重新組合之后。此節(jié)描述了兩種模式的協(xié)議處理過程。
4．1 隧道模式下的 ESP
隧道模式下的 ESP報(bào)頭跟隨在所有的端到端的報(bào)頭之后（例如，認(rèn)證頭，如果在明文中呈現(xiàn)的話），在它后面就緊接著一個被隧道化的 IP數(shù)據(jù)包。發(fā)送方將原始的IP數(shù)據(jù)包封裝進(jìn)ESP，至少使用發(fā)送方的用戶ID以及目的地址來定位正確的安全關(guān)聯(lián)，然后運(yùn)用合適的加密變換。如果使用基于主機(jī)的密鑰產(chǎn)生機(jī)制，那么對于一個特定的目的地址來說，一個給定系統(tǒng)上所有的發(fā)送用戶擁有相同的安全關(guān)聯(lián)。如果沒有任何一個密鑰已經(jīng)被建立，那么密鑰管理機(jī)制要為這個連接會話產(chǎn)生一個加密密鑰，此過程要在ESP被使用之前發(fā)生。此后，（加密的）ESP作為最終的有效載荷被封裝入一個未加密的IP數(shù)據(jù)包。如果執(zhí)行嚴(yán)格的紅黑分割，那么可選的載荷和明文IP數(shù)據(jù)報(bào)頭中的地址以及其他的信息可能會和包含在原始數(shù)據(jù)包（現(xiàn)在已經(jīng)被加密和封裝了）中的值有所不同。
接收方剝?nèi)ッ魑腎P報(bào)頭以及明文的可選IP載荷（如果有）并且丟棄它們。接下來，接受方結(jié)合使用目的地址和SPI值來定位這個信息包的正確的會話密鑰，然后使用這個密鑰來解密這個ESP。
如果對于此會話不存在一個合法的安全關(guān)聯(lián)（例如，接受方?jīng)]有密鑰），接受方必須丟棄這個加密的ESP 并且這個錯誤必須被記錄在系統(tǒng)日志或者審核日志當(dāng)中。這個系統(tǒng)日志或?qū)徍巳罩緫?yīng)該包括SPI的值，時(shí)間，明文的發(fā)送地址，明文的目的地址，以及明文的信息流的ID。日志條目也可以包括別的認(rèn)證數(shù)據(jù)。接受方可能不想立即通知發(fā)送方有錯，因?yàn)檫@樣極有可能被拒絕服務(wù)攻擊模式所利用。
如果解密成功，原始的IP數(shù)據(jù)包被從ESP（已被解密）移出。然后，這個原始的數(shù)據(jù)包就按照通常的IP協(xié)議規(guī)范來處理。在要求提供多級安全安全的系統(tǒng)中（例如，一個B1級或分割模式的工作站）,基于接受進(jìn)程的安全級別以及與安全關(guān)聯(lián)相關(guān)的安全級別，附加的合適強(qiáng)制訪問控制必須被實(shí)施。如果這些強(qiáng)制訪問控制失敗了，那么這個信息包應(yīng)該被丟棄，同時(shí)應(yīng)該使用特定的實(shí)施過程將錯誤錄入日志。
4．2 傳輸模式下的ESP
在傳輸模式下，ESP 頭被放置在端到端的頭部之后（例如，認(rèn)證頭），它后面緊接著的是一個傳輸層的頭（例如：UDP ,TCP, ICMP）。
發(fā)送者將原始的傳輸層（例如：UDP,TCP,ICMP）幀封裝入ESP，至少使用發(fā)送的用戶ID和目的地址來定位合適的安全關(guān)聯(lián)，然后運(yùn)用合適的加密變換。如果使用基于主機(jī)的密鑰產(chǎn)生機(jī)制，那么對于一個特定的目的地址來說，一個給定系統(tǒng)上所有的發(fā)送用戶擁有相同的安全關(guān)聯(lián)。如果沒有任何一個密鑰已經(jīng)被建立，那么密鑰管理機(jī)制要為這個連接會話產(chǎn)生一個加密密鑰，此過程要在ESP被使用之前發(fā)生。此后，（加密的）ESP作為最終的有效載荷被封裝入一個未加密的IP數(shù)據(jù)包。
接收方的處理明文IP頭和明文的可選IP 頭（如果有）并且暫時(shí)存儲相關(guān)信息（例如，源地址和目的地址，信息流ID，路由選項(xiàng)頭），接受方結(jié)合使用目的地址和SPI值來定位這個信息包的正確的會話密鑰，然后使用已為此次通信而建立的會話密鑰將ESP 解密。
如果沒有用于此會話的密鑰或者解密的嘗試失敗，接受方必須丟棄這個加密的ESP 并且這個錯誤必須被記錄在系統(tǒng)日志或者審核日志當(dāng)中。如果如此的一個失敗發(fā)生，這個系統(tǒng)日志或?qū)徍巳罩緫?yīng)該包括SPI的值，接受時(shí)間，明文的發(fā)送地址，明文的目的地址，以及明文的信息流的ID。日志條目也可以包括別的關(guān)于失敗的信息包的信息。如果某些原因的存在而導(dǎo)致解密無法正常工作，那么由此而來的數(shù)據(jù)就無法被實(shí)施中的協(xié)議引擎所分析。因此，失敗的機(jī)密通常是可以被檢測到的。
如果解密成功，原來的傳輸層（例如，UDP,TCP,ICMP）幀從ESP （已被解密）中移出。明文IP 頭信息和傳輸層頭被結(jié)合起來判別數(shù)據(jù)一個被送往哪一個應(yīng)用程序。然后數(shù)據(jù)就象按照一般的IP 協(xié)議規(guī)范那樣被送給合適的應(yīng)用程序。在要求提供多級安全安全的系統(tǒng)中（例如，一個B1級或分割模式的工作站）,基于接受進(jìn)程的安全級別以及與安全關(guān)聯(lián)相關(guān)的安全級別，附加的合適強(qiáng)制訪問控制必須被實(shí)施。
4．3 認(rèn)證
一些變換在提供機(jī)密性和信息完整性功能的同時(shí)也提供認(rèn)證功能。當(dāng)這些變換不被使用時(shí)，認(rèn)證報(bào)頭可能與封裝安全載荷一起使用。將認(rèn)證報(bào)頭與ESP結(jié)合使用有兩種不同的方法，依賴這兩種方法數(shù)據(jù)被認(rèn)證。認(rèn)證頭的位置闡明了哪一個數(shù)據(jù)集合正在被認(rèn)證。
在第一種方法中，被接受的數(shù)據(jù)包整個被認(rèn)證，包括它的加密部分和未加密部分。而只有ESP報(bào)頭之后的數(shù)據(jù)是機(jī)密的。在此方法中，，發(fā)送方首先運(yùn)用 ESP 封裝被保護(hù)的數(shù)據(jù)，然后將明文的IP報(bào)頭置于ESP報(bào)頭和加密的數(shù)據(jù)之前。最后，按照通常的方法利用已得出的數(shù)據(jù)包計(jì)算出IP 認(rèn)證報(bào)頭。接收時(shí)，接收者首先使用通常的IP 認(rèn)證頭處理過程對整個數(shù)據(jù)包進(jìn)行身份認(rèn)證。然后，如果身份認(rèn)證成功，那么就使用通常的IP ESP 處理過程來進(jìn)行解密。如果解密成功，那么得到的數(shù)據(jù)就被傳遞給上一層。
如果認(rèn)證過程僅被應(yīng)用于隧道模式ESP保護(hù)下的數(shù)據(jù)，那么此IP 認(rèn)證頭通常會被放置在被保護(hù)的數(shù)據(jù)報(bào)之內(nèi)。然而，如果是使用傳輸模式ESP，IP 認(rèn)證報(bào)頭被放在ESP報(bào)頭的前面并且根據(jù)整個IP 數(shù)據(jù)報(bào)來計(jì)算它。
如果認(rèn)證報(bào)頭被封裝在一個隧道模式的 ESP報(bào)頭之內(nèi)并且兩個報(bào)頭都有與它們相關(guān)聯(lián)的安全分類級別，而這兩個安全分類級別不是相同的，那么一個錯誤就會發(fā)生。這個錯誤應(yīng)該被上面描述的程序過程記錄在系統(tǒng)日志或者審核日志中。一個認(rèn)證報(bào)頭定位在ESP報(bào)頭之外的時(shí)候，如果它們有不同的安全分類級別并不一定是個錯誤。這可能是合理的因?yàn)樵跀?shù)據(jù)被 ESP加密之后，明文的IP 報(bào)頭可能有一個不同的分類級別。
5 一致性要求
符合或與此篇說明文檔相一致的具體實(shí)現(xiàn)必須完全執(zhí)行本篇文章描述的報(bào)頭，必須支持伴隨此報(bào)頭的手工密鑰發(fā)布，必須滿足 “Internet協(xié)議安全架構(gòu)”[Atk95]的所有需求,必須支持DES CBC（在伴隨文檔中被詳述，題目是：The ESP DES-CBC Transform[KMS95]）的使用。實(shí)施者也可以實(shí)現(xiàn)別的ESP變換。實(shí)施者應(yīng)該查詢最近版本的“IAB Official Standards”RFC作為對于本篇文檔狀態(tài)的更深層的指導(dǎo)。
6 安全考慮
此篇文檔討論了一個隨IP 使用的安全機(jī)制。此機(jī)制不是一個萬能的良方，但在創(chuàng)建一個安全的互聯(lián)網(wǎng)的時(shí)候它確實(shí)提供了一個重要而有用的部分。
對于一個使用分組鏈接算法并且缺乏一個健壯的完整性機(jī)制的ESP來說，它的加密變換在受到cut-and-paste攻擊（見Bellovin的描述文章）時(shí)是脆弱的，除非認(rèn)證報(bào)頭總是出現(xiàn)在使用ESP變換的信息包之內(nèi)，否則不應(yīng)該被使用。[Bel95]
使用者需要明白此規(guī)格提供的安全品質(zhì)完全依賴于所采用的加密算法的強(qiáng)度和實(shí)現(xiàn)時(shí)的正確性，以及密鑰管理機(jī)制的安全性和它實(shí)現(xiàn)時(shí)的安全性，還依賴于密鑰自身的強(qiáng)度以及在所有相關(guān)系統(tǒng)中ESP 和IP實(shí)施的正確性。
如果這些假定的條件有一些不滿足，就不會有真正的安全可言。在IP 封裝安全有效載荷中推薦使用高可靠性的的開發(fā)技術(shù)。
如果用戶想在受到流量分析時(shí)保護(hù)數(shù)據(jù)，他可能用到一個恰當(dāng)?shù)逆溄蛹用芊椒?。鏈接加密的描述和?guī)格不在此篇文章的論述范圍之內(nèi)。
即使不使用面向用戶的密鑰，當(dāng)前使用的算法對于所有的選擇明文攻擊方法來說都應(yīng)該是牢固的。對DES的選擇明文攻擊在[BS93]和[Mat94] 中被描述。面向用戶的密鑰的被推薦使用，因?yàn)樗梢耘懦鞣N選擇明文攻擊并且使解密更困難。就像在IP Security Architecture[AtK95a]描述的那樣，在實(shí)現(xiàn)的時(shí)候應(yīng)該使用面向用戶的密鑰。
承謝
此文檔極大的受益于Bill Simpson,Perry Metzger ,Phil Karn做的工作，他們將SIP,SIPP,IPv6 的作者最初定義的方法普遍化。
本文的許多概念源于美國政府的SP3安全協(xié)議規(guī)格，ISO/IEC的NLSP規(guī)格，以及提議中的swIPe安全協(xié)議 [SDNS89,ISO92a,IB93,IBK93,ISO92b]或是受到它們的影響。用于保密的DES的使用在論述SNMPv2的文章中已經(jīng)被嚴(yán)整的建模[GM93]。Steve Deering,Dave Michelcic,Hilarie Orman提供了對此篇備忘錄早期版本的可靠的評論。
參考文獻(xiàn)
[Atk95a] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 1825, NRL, August 1995.
[Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol. 19,
No. 2, March 1989.
[Bel95] Steven M. Bellovin, Presentation at IP Security Working
Group Meeting, Proceedings of the 32nd Internet Engineering
Task Force, March 1995, Internet Engineering Task Force,
Danvers, MA.
[BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the
Data Encryption Standard", Springer-Verlag, New York, NY,
1993.
[CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data:
Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23,
July 1994. pp. 253-280
[CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
and Hijacked Terminal Connections", CA-95:01, January 1995.
Available via anonymous ftp from info.cert.org.
[DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode
Workstation Specification", Technical Report
DDS-2600-6243-87.
[GM93] Galvin J., and K. McCloghrie, "Security Protocols for
version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
Systems, April 1993.
[Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
Specification, Work in Progress, October 1994.
[IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation
of Network-layer Security Under Unix", Proceedings of the USENIX
Security Symposium, Santa Clara, CA, October 1993.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe:
Network-Layer Security for IP", presentation at the Spring
1993 IETF Meeting, Columbus, Ohio.
[ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, Section 13.4.1, page 33, International Standards
Organisation, Geneva, Switzerland, 29 November 1992.
[Ken91] Kent, S., "US DoD Security Options for the Internet
Protocol", RFC 1108, BBN Communications, November 1991.
[KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC
Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer,
August 1995.
[Mat94] Matsui, M., "Linear Cryptanalysis method for DES Cipher",
Proceedings of Eurocrypt '93, Berlin, Springer-Verlag, 1994.
[NIST77] US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication
46, January 1977.
[NIST80] US National Bureau of Standards, "DES Modes of Operation"
Federal Information Processing Standard (FIPS) Publication
81, December 1980.
[NIST81] US National Bureau of Standards, "Guidelines for Implementing
and Using the Data Encryption Standard", Federal Information
Processing Standard (FIPS) Publication 74, April 1981.
[NIST88] US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication
46-1, January 1988.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciences Institute, October 1994.
[Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons,
New York, NY, 1994. ISBN 0-471-59756-2
[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, as published
in NIST Publication NIST-IR-90-4250, February 1990.
作者聲明
本文的觀點(diǎn)和規(guī)格代表作者本人，海軍研究實(shí)驗(yàn)室還沒有對本文的價(jià)值（如果有的話）作出判斷。本文作者以及作者的雇主對于由于正確或者錯誤的實(shí)施使用此規(guī)格而引起的問題不負(fù)任何責(zé)任。
作者地址
Randall Atkinson
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA
Phone: (202) 404-7090
Fax: (202) 404-7942
EMail: http://www.360doc.com/mailto:atkinson@itd.nrl.navy.mil
