因特網交換密鑰

1.摘要
因特網安全關聯和關密鑰的管理協議(ISAKMP)為因特網安全關聯管理和密鑰建立定義一個框架。這個框架由定義了的交換，有效負載，和在給定解釋域(DOI)以內發生的處理指南組成。這個文件定義因特網IP安全DOI(IPSECDOI),它用具體例子說明IP適合同ISAKMP一起使用,當IP使用ISAKMP商定安全關聯。
關于IPSECDOI的先前版本的變化的列表，請見7節。
2.介紹
在ISAKMP以內，解釋的域被用來通過使用ISAKMP組織有聯系的協議來商議安全關聯。共享一個DOI的安全協議選擇安全協議和從一個普通的，名字空間轉變的密碼并且共享關密鑰的交換協議標識符。他們也共享DOI特定的有效負載數據內容的普通解釋,包括安全關聯和鑒定有效負載。
總的來說,ISAKMP把下列要求放在一個DOI定義上：
o為DOI特定的協議標識符定義命名方案
o為狀況域定義解釋
o定義適用的安全策略集合
o為DOI特定的SA屬性的定義句法(階段II）
o為DOI特定的有效負載內容定義句法
o定義附加的密鑰交換類型,如果需要
o定義附加的通知消息類型,如果需要
這個文件的剩余部分為使用IP安全(IPSEC)協議提供認證,完整性，或為IP包的機密在合作主機系統或防火墻之間送的請求,進行了詳細實例化。
對于全面的IPSEC體系結構描述，見[ARCH],[AH],和[ESP]。
3.術語和定義
關鍵詞必須,不能,要求,將,將不,應該,應該不,推薦,可能和可選,當他們再文檔中出現時,被解釋成如[RFC2119]所描述的。
4．IPSEC
4.1IPSEC命名方案
在ISAKMP以內，所有的Doi的必須在“分配的數字”RFC[STD-2]內同IANA一起被登記。IANA為因特網IP安全DOI(IPSECDOI)分配的數字是一個(1)。在IPSECDOI以內，所有著名的標識符必須在IPSECDOI下面與IANA一起被登記。除非另外注明,在這個文件以內的所有表參考為IPSECDOI而被分配數字的IANA。對于IPSECDOI聯系到IANA注冊表的進一步的信息,見節6。
所有的多字節二進制代碼值在網絡字節順序被存儲。
4.2IPSEC狀況定義
在ISAKMP以內，狀況提供能被響應者用來作出一條關于怎么處理到來的安全關聯信息請求策略的決定。對于IPSECDOI，狀況域是一個有下列值的4字節位掩碼。
狀況 值
--------------
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
4.2.1SIT_IDENTITY_ONLY
SIT_IDENTITY_ONLY類型指定,安全關聯將被在聯系的鑒定有效負載中提供的源身份信息所標記。對于各種各樣的鑒定的完全描述見節4.6.2。所有的IPSECDOI實現必須支持SIT_IDENTITY_ONLY,由在至少一次階段IOakley交換中包含鑒定有效負載([IKE],節5),并且必須放棄任何不包括鑒定的安裝有效負載關聯。
如果一個開始者既不支持SIT_SECRECY也不支持SIT_INTEGRITY，狀況僅僅由4字節狀況位圖組成并且不包括標記的域標識符域(圖1,節4.6.1)或任何隨后的標簽信息。相反的,如果開始者支持SIT_SECRECY或SIT_INTEGRITY，標記的域標識符必須在狀況有效負載時被包括。
4.2.2SIT_SECRECY
SIT_SECRECY類型指定安全關聯在要求標記秘密的環境中正被商議。如果SIT_SECRECY在狀況位圖中出現，狀況域將被變量長度數據跟隨,他們包括敏感級別和分隔空間位掩碼。關于安全關聯有效負載格式的完全的描述,見節4.6.1。
如果一個開始者不支持SIT_SECRECY，SIT_SECRECY狀況位圖不能被設置并且秘密級別或范疇位圖將被包括。
如果一個應答者不支持SIT_SECRECY，環境不支持的標志信息有效負載應該被返回并且安全關聯安裝必須被放棄。
4.2.3SIT_INTEGRITY
SIT_INTEGRITY類型指定安全關聯在要求標記完整性的環境中正被商議。如果SIT_INTEGRITY在狀況位圖中出現，狀況域將被變量長度數據跟隨,他們包括完整級別和分隔空間位掩碼。如果SIT_SECRECY也用于關聯,完整信息立即遵從變長秘密級別和類別。關于安全關聯有效負載格式的完全的描述,見節4.6.1。
如果一個開始者不支持SIT_INTEGRITY，SIT_INTEGRITY狀況位圖不能被設置并且無完整性級別或范疇位圖將被包括。
如果一個應答者不支持SIT_INTEGRITY，環境不支持的標志信息有效負載應該被返回并且安全關聯安裝必須被放棄。
4.3IPSEC安全策略要求
IPSECDOI不在任何實現上強加特定的安全策略要求。主機系統策略問題將在這個文件的范圍以外。
然而,當設計一個IPSECDOI主機實現時，在下面的章節涉及的一些問題必須被考慮。這節自然應該被認為僅僅參考。
4.3.1密鑰管理問題
選擇來實現ISAKMP的許多系統將努力為一個聯合的IKE密鑰管理新進程提供執行的保護域，這被期望。在保護模式多用戶操作系統上，這個密鑰管理進程將多半作為分開的特權進程存在。
在這個環境中，介紹密鑰材料到TCP/IP核的形式化的API可以是合乎需要的。IP安全體系結構不放任何結構要求,或在一個主機TCP/IP核和它的密鑰管理供應商之間流動。
4.3.2靜態的密鑰問題
實現靜態密鑰的主機系統,或由IPSEC直接使用，或為認證目的(見[IKE]節5.4)，當它不在保護的內存域或由TCP/IP核使用時,應該采取步驟保護靜態的密鑰材料。
例如,在一臺膝上計算機上，一個人可能選擇在一家配置存儲器存儲靜態的密鑰,自己,在一個私人的口令下面加密了。
依靠操作系統和安裝的實用程序軟件,一旦靜態的密鑰裝載進TCP/IP核，他們被保護是不可能的，然而他們不能在沒有滿足一些附加形式的認證下而在起始的系統開始輕易重獲
4.3.3主機策略問題
假設IPSEC的轉變在一夜間發生，是不現實的。主機系統必須準備實現靈活的策略表,策略表描述哪個系統他們需要安全地通話和他們要求通話安全的系統。一些觀點認為代理防火墻地址可以被要求。
一條最小的途徑可能是IP地址，網絡掩碼，和安全要求標志或標志的一張靜態表。
一個更靈活的實現可能由一列通配符DNS的命名(例如"*.foo.bar'),一個在里/外位掩碼，和一個可選的防火墻地址組成。通配符DNS名字將被用來匹配到來或出去的IP地址,里/外位掩碼將被用來決定安全是否將被使用,和哪個方向，并且可選的防火墻地址將被用來顯示通道模式是否需要通過中間防火墻與目標系統談話。
4.3.4證書管理
實現一個基于證書的認證計劃的主機系統將需要一個機制來獲得和管理證書數據庫。
安全的DNS是是一個證書分發機制,然而安全的DNS地區的普遍應用,在短術語中，有許多值得懷疑的原因。更可能的是，主機將
需要進口他們通過的安全,out-of-band機制獲得證書的權能,和出口自己的證書給另外的系統使用。
然而,手工證書管理不能被執行以便防止介紹動態的證書發現機制或協議的權能成為可行的。
4.4IPSEC分配數
下列節為IPSECDOI列出分配的數字：狀況標識符,協議標識符,轉變標識符，AH，ESP，并且IPCOMP轉變標識符,安全協會屬性類型值,標記的域標識符，ID有效負載類型值，和通知消息類型值。
4.4.1IPSEC安全協議標識符
ISAKMP建議句法被特定的設計來允許多重的階段II安全協議的同時協商在一個單個的協商內適用。作為結果，下面被列出了的協議組形成了能同時被協商的協議集合。它是決定什么協議能被協商在一起的一個主機策略決定。
下列表為IPSECDOI而在ISAKMP建議有效負載中引用的安全協議標識符列出值的。
協議ID 值
----------- -----
保留 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
4.4.1.1PROTO_ISAKMP
PROTO_ISAKMP類型指定在階段I的ISAKMP協議期間要求的消息保護。在IPSECDOI中被使用的特定的保護機制在[IKE]中被描述。在IPSECDOI以內的所有的實現必須支持PROTO_ISAKMP。
NB：ISAKMP保留該值一(1),越過所有的DOI定義。
4.4.1.2PROTO_IPSEC_AH
PROTO_IPSEC_AH類型指定IP包認證。缺省AH轉變提供數據起源認證,完整保護,和重放探測。對于出口控制考慮，機密不能被任何PROTO_IPSEC_AH轉變所提供。
4.4.1.3PROTO_IPSEC_ESP
PROTO_IPSEC_ESP類型指定IP包機密。如果要求認證，必須作為ESP的部分被提供轉變。缺省ESP轉變包括數據起源認證,完整保護,重放探測,和機密性。
4.4.1.4PROTO_IPCOMP
如在[IPCOMP]里面定義的,PROTO_IPCOMP類型指定IP有效負載壓縮。
4.4.2IPSECISAKMP轉變標識符
作為一個ISAKMP階段I協商的部分,開始者的密鑰的交換提供的選擇被用來作一些主機系統策略描述。實際的密鑰交換機制選擇被用來做標準的ISAKMP建議有效負載。下列表格列出對于IPSECDOI的為建議有效負載定義的ISAKMP階段I轉變標識符。
轉變 值
--------- -----
保留 0
KEY_IKE 1
在ISAKMP和IPSECDOI框架內除IKE(Oakley)以外定義密鑰的建立協議，是可能的。這個文件的先前版本定義了基于一個通用密鑰的分發中心(KDC)的使用的手工密鑰和計劃。這些標識符從當前的文件被移走了。
IPSECDOI還能在以后被擴大到為附加的non-Oakley密鑰建立協議包括關于ISAKMP和IPSEC的值,例如Kerberos[RFC-1510]或組密鑰管理協議(GKMP)[RFC-2093]。
4.4.2.1KEY_IKE
KEY_IKE類型指定混合的ISAKMP/OakleyDiffie-Hellman密鑰的交換(IKE),如在[IKE]文件定義。在IPSECDOI以內的所有的實現必須支持KEY_IKE。
4.4.3IPSECAH轉變標識符
認證頭協議(AH)定義一個強制的和若干可選的轉變用于提供認證,完整性,和重放探測。下列表列出定義的AH轉變標識符為IPSECDOI的ISAKMP建議有效負載。
注意：認證算法屬性必須被指定認明適當的H保護組。例如,AH_MD5最好能被想作使用MD5的通用AH轉變。為了AH請求HMAC構造,一個人指定AH_MD5轉變ID,伴隨著認證算法屬性設置到HMAC-MD5。這被顯示使用"Auth(HMAC-MD5)"標志在下列節。
轉變ID 值
----------- -----
保留 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
注意：所有的mandatory-to-implement算法被列出作為必須實現(例如AH_MD5)在下列節。所有另外的算法是可選的并且可能在任何特別的應用中被實現。
4.4.3.1AH_MD5
AH_MD5類型指定使用MD5的通用AH轉變。實際的保護組被決定與SA聯系表一致。通用的MD5轉變當前未定義。
在IPSECDOI內的所有的實現必須與Auth一起支持AH_MD5(HMAC-MD5)屬性。這組被定義為HMAC-MD5-96轉變,如在[HMACMD5]中描述的。
與Auth一起的AH_MD5類型(KPDK)屬性指定了AH轉變(密鑰/墊/數據/密鑰)描述在RFC-1826。
有任何另外的認證算法的AH_MD5的使用屬性值當前未定義。
4.4.3.2AH_SHA
AH_SHA類型指定使用SHA-1的通用AH轉變。實際的保護組決定為與聯系的SA屬性表一致。通用的SHA轉變當前未定義。
在IPSECDOI以內的所有的實現必須與Auth一起支持AH_SHA(HMAC-SHA)屬性。這組被定義為描述在[HMACSHA]中的HMAC-SHA-1-96轉變。
與任何另外的認證算法屬性值一起使用的AH_SHA當前未定義。
4.4.3.3AH_DES
AH_DES類型指定使用DES的通用AH轉變。實際的保護組決定為與聯系的SA屬性表一致。通用的DES轉變當前未定義。
IPSECDOI定義AH_DES和Auth(DES-MAC)屬性為DES-MAC轉變。實現不需要支持這種模式.
與任何另外的認證算法屬性值一起使用的AH_DES當前未定義。
4.4.4IPSECESP轉變標識符
包含的安全有效負載(ESP)定義一個強制的和用于常提供數據機密可選的許多轉變。下列表格列出定義的對于IPSECDOI為ISAKMP建議有效負載的ESP轉變標識符。
注意：什么時候認證,完整保護,和重放探測被要求,認證算法屬性必須被指定來認明適當的ESP保護組。例如,請求有3DES的HMAC-MD5認證，一個人指定ESP_3DES屬性轉變ID并且設置把認證算法屬性設置為HMAC-MD5。對于附加處理的要求，見節4.5（認證算法）。
轉變ID 值
------------ -----
保留 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
注意：在下列節中所有的mandatory-to-implement算法被列出作為必須實現(例如ESP_DES)。所有另外的算法是可選的并且可能在任何特別的應用中被實現。
4.4.4.1ESP_DES_IV64
ESP_DES_IV64類型指定定義在RFC-1827和使用一個64比特IV中的RFC-1829DES-CBC轉變
4.4.4.2ESP_DES
ESP_DES類型指定使用DES-CBC的一個通用的DES轉變。實際的保護組定義得與SA屬性表一致。一個通用轉變當前未定義。
在IPSECDOI內的所有實現必須與Auth(HMAC-MD5)一起支持ESP_DES屬性。這組被定義為[DES]轉變,由HMACMD5[HMACMD5]提供認證和完整性了。
4.4.4.3ESP_3DES
ESP_3DES類型指定一個通用的triple-DES轉變。實際的保護組定義得與SA屬性表一致。通用轉變當前未定義。
在IPSECDOI內的所有的實現強烈支持ESP_3DES和Auth(HMAC-MD5)屬性。這組被定義為[ESPCBC]轉變,由HMACMD5[HMACMD5]提供認證和完整性。
4.4.4.4ESP_RC5
ESP_RC5類型指定定義在[ESPCBC]RC5的轉變。
4.4.4.5ESP_IDEA
ESP_IDEA類型指定定義在[ESPCBC]的IDEA轉變。
4.4.4.6ESP_CAST
ESP_CAST類型指定定義在[ESPCBC]的CAST轉變。
4.4.4.7ESP_BLOWFISH
ESP_BLOWFISH類型指定定義在[ESPCBC]的BLOWFISH轉變。
4.4.4.8ESP_3IDEA
ESP_3IDEA類型為triple-IDEA保留。
4.4.4.9ESP_DES_IV32
ESP_DES_IV32類型指定定義在RFC-1827和使用一32位的IV的RFC-1829的DES-CBC轉變。
4.4.4.10ESP_RC4
ESP_RC4類型為RC4保留。
4.4.4.11ESP_NULL
ESP_NULL類型沒有指定任何機密被ESP提供。當ESP被用于僅僅要求認證,完整性,和重放探測的通道包時，ESP_NULL被使用。
在IPSECDOI內的所有實現必須支持ESP_NULL。ESPNULL轉變在[ESPNULL]中被定義。為得到關聯ESP_NULL使用的附加要求,見節4.5認證算法屬性描述。
4.4.5IPSECIPCOMP轉變標識符
IP壓縮(IPCOMP)轉變定義了能被協商為IP有效負載壓縮([IPCOMP])所提供的可選壓縮算法。下列表列出已定義的IPCOMP內,為ISAKMP建議有效負載轉變標識符
IPSECDOI
轉變ID 值
------------ -----
保留 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1IPCOMP_OUI
IPCOMP_OUI類型指定專利的壓縮轉變。IPCOMP_OUI類型必須由進一步認明特定供應商算法的屬性伴隨。
4.4.5.2IPCOMP_DEFLATE
IPCOMP_DEFLATE類型指定“zlib”縮小算法的使用如在[降低]中指定。
4.4.5.3IPCOMP_LZS
IPCOMP_LZS類型指定Stac電子學LZS算法的使用如在[LZS]中指定的。
4.5IPSEC安全關聯屬性
下列SA屬性定義被使用在一個IKE協商的相II。屬性類型可以是基本(B)或可變的長度(V)。這些屬性編碼被定義在基層的ISAKMP說明中。
描述為基本的屬性不能被編碼為變量。如果他們的值適合在兩個字節中，可變的長度屬性可以被編碼為基本屬性。屬性上關于IPSECDOI的進一步信息編碼見[IKE]。列出在[IKE]的所有限制也適用于IPSECDOI。
屬性類型
類 值 類型
-------------------------------------------------
SA生命類型 1 B
SA生命持續時間 2 V
組描述 3 B
封裝模式 4 B
認證算法 5 B
密鑰長度 6 B
密鑰Rounds 7 B
壓縮字典大小 8 B
壓縮私人的算法 9 V
類值
SA生命類型
SA持續時間
為了全面安全關聯而指定生命時間。當SA到期時，在關聯下面協商所有的密鑰(AH或ESP)必須重新協商。生命類型值是：
保留 0
第二 1
K字節 2
值3-61439被保留到IANA中。值61440-65535為私有使用。對于一種給定的生命類型，生命持續時間屬性的值定義了部件一生的實際長度--或很多秒，或能被保護的很多Kbytes。
如果未特別指出，缺省值將被假定為28800秒(8小時)。
SA生命持續時間屬性必須總是遵從描述持續時間單位的SA生命類型。
對于一生通知聯系的附加信息見節4.5.4。
組描述
指定在一個PFSQM協商被使用的Oakley組。關于支持值的列表，見附錄一的[IKE]。
封裝模式
保留 0
隧道 1
運輸 2
值3-61439被保留到IANA。值61440-65535為私人使用。
如果未特別指出，缺省值將被假定為未特別指出(主機依賴)。
認證算法
保留 0
HMAC-MD5 1
HMAC-SHA 2
DES-MAC 3
KPDK 4
值5-61439被保留到IANA。值61440-65535為私人使用。
當它必須被指定來正確的認明適用的AH或ESP轉變時,Auth算法沒有缺省值,除了在下列情況中。
當協商的ESP時，Auth算法屬性不能被包括在建議中。
當協商沒有機密的ESP時，Auth算法屬性必須被包括在建議中并且ESP轉變的ID必須是ESP_NULL。
密鑰的長度
保留 0
密鑰長度沒有缺省值,如它必須為使用可變密鑰長度的密碼轉變而被指定。對于固定長度的密碼，密鑰長度屬性不能被傳送。
密鑰的Rounds
保留 0
密鑰的Rounds沒有缺省值,如它必須為使用rounds變化數字密碼的轉變被指定。
壓縮字典大小
保留 0
指定log2為字典大小的最大值。
字典大小沒有缺省值。
壓縮私人算法
指定私人供應商壓縮算法。首先的3(3)字節必須是被分配了的company_id的一個IEEE(OUI)。下一個字節可以是供應商特定的壓縮子類型,跟隨著供應商零或更多字節的數據。
4.5.1要求的屬性支持
保證基本的互操作性,所有的實現必須準備協商下列所有屬性。
SA生命類型
SA持續時間
Auth算法
4.5.2分析要求的屬性(一生)
允許靈活的語義,IPSECDOI要求一個遵守ISAKMP的實現必須正確分析包含相同屬性類多重例子的屬性表，只要不同的屬性入口不與對方沖突。當前,要求處理的唯一屬性是生命類型和持續時間。
為了知道這為什么重要,下列例子顯示一個二進制4入口編碼指定100MB或24小時的SA一生的屬性表。（見節3.3[ISAKMP]為屬性的完全描述編碼格式。）
屬性#1：
0x80010001（AF=1,類型=SA生命類型,值=秒）
屬性#2：
0x00020004(AF=0,類型=SA持續時間,長度=4個字節)0x00015180值=0x15180=86400秒=24小時)
屬性#3：
0x80010002（AF=1,類型=SA生命類型,值=KB）
屬性#4：
0x00020004(AF=0,類型=SA持續時間,長度=4個字節)0x000186A0(值=0x186A0=100000KB=100MB)
如果沖突屬性被檢測到,ATTRIBUTES-NOT-SUPPORTED通知有效負載應該被返回并且安全關聯安裝必須被放棄。
4.5.3屬性協商
如果實現收到一個它不支持的定義了的IPSECDOI屬性(或屬性值),一個ATTRIBUTES-NOT-SUPPORT應該被發送并且安全關聯安裝必須被放棄的，除非屬性值在保留的范圍內。
如果實現在保留范圍收到屬性值，實現可能選擇繼續基于本地的策略。
4.5.4一生通知
當一個開始者提供比應答者基于他們的本地的策略所需的大的SA一生時，應答者有3種選擇：1)協商全部失敗;2)完成協商但是使用比被提供的更短的一生;3)完成協商并且送一份建議通知到顯示應答者真實一生的開始者。應答者實際上做的選擇是實現特定的或基于本地的策略。
在后者情況中保證互操作性,當應答者希望通知開始者時，IPSECDOI僅僅要求下列：如果開始者提供的SA一生與應答者愿意接受的長，應答者應該在包括應答者IPSECSA有效負載的交換包括ISAKMP通知的有效負載。節4.6.3.1為必須被用于這個目的消息類型的RESPONDER-LIFETIME通知定義有效負載布局。
4.6IPSEC有效負載內容
下列節描述其數據表示依賴于適用的DOI的那些ISAKMP有效負載。
4.6.1安全關聯有效負載
下列圖表為IPSECDOI說明安全關聯有效負載的內容。對于狀況位圖的描述見節4.2。
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一個有效負載！保留！有效負載長度！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！解釋的域(IPSEC）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！狀況(位圖）！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！標記的域標識符！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密長度(在字節）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~秘密級別
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密連接。長度(在位中)！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~秘密范疇位圖~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！完整長度(在字節）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~完整級別
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！Integ。連接。長度(按位）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~完整范疇位圖~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖1：安全關聯有效負載格式
安全關聯有效負載被定義如下：
o下一個有效負載(1字節)在消息中的下一個有效負載的有效負載類型標識符。如果當前的有效負載是在消息的最后，這域將是零(0)。
o保留(1字節)-閑置,必須是零(0)。
o有效負載長度(2字節)-長度,字節，當前的有效負載，包括通用的頭。
o解釋的域(4字節)-指定IPSECDOI,它被分配了值一(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.1IPSEC標記了的域標識符
下列表列出標記域標識符域的分配的值,它被包含在關聯有效負載的安全狀況域中。
域 值
------ -----
保留 0
4.6.2鑒定有效負載內容
鑒定有效負載被用來認明安全關聯的開始者。開始者的身份應該被應答者使用來決定關聯要求的正確主機系統安全策略。例如,一臺主機可能選擇沒有要求從某個集合IP地址機密認證和完整性,和另一范圍IP地址地完全機密性認證。鑒定有效負載提供能被應答者用來作出決定的信息。
在階段期I協商期間，ID端口和協議域必須被設置為零或上到500的UDP。如果實現收到任何另外的值，這必須被當作一個錯誤并且安安全關聯裝必須被放棄。這個事件應該是auditable。
下列圖表說明鑒定有效負載的內容。
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一個有效負載！保留！有效負載長度！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！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.2ID_IPV4_ADDR
ID_IPV4_ADDR類型指定單個4(4)字節的IPv4地址。
4.6.2.3ID_FQDN
ID_FQDN類型指定一個完全合格的域名字符串。一個ID_FQDN例子是，“foo.bar.com”。字符串不能包含任何終止符。
4.6.2.4ID_USER_FQDN
這個ID_USER_FQDN類型指定一個有很高權限的用戶名字符串，ID_USER_FQDN的一個例子是"piper@foo.bar.com".這個字符串不應該包含任何界限。
4.6.2.5ID_IPV4_ADDR_SUBNET
這個ID_IPV4_ADDR_SUBNET類型詳細說明IPV4地址的排列，它表現為兩個四位的八位位組值。第一個值是IPV4的地址。第二個值是IPV4的網絡面具。特別注意這個網絡面具中的ones(1s)指示的相應的位被固定，而zeros(0s)指示一個通配符位。
4.6.2.6ID_IPV6_ADDR
這個ID_IPV6_ADDR類型指定一個單一的16位八位位組Ipv6地址。
4.6.2.7ID_IPV6_ADDR_SUBNET
這個ID_IPV6_ADDR_SUBNET類型詳細說明Ipv6地址的排列，它被描繪為兩個16位的八位位組的值。第一個值是一個Ipv6的地址。第二個值是Ipv6的網絡面具。特別注意網絡面具中的ones（1s）指示地址中的相應位被固定，而zeros(0s)指示一個通配符位。
4.6.2.8ID_IPV4_ADDR_RANGE
這個ID_IPV4_ADDR_RANGE類型詳細說明一個IPV4地址的排列，它表現為兩個四位的八位位組值。第一個值開始于Ipv4地址，第二值結束于IPV4的地址。在兩個指定地址中的所有地址被認為在這個列表之中。
4.6.2.9ID_IPV6_ADDR_RANGE
這個ID_IPV6_ADDR_RANGE類型詳細說明Ipv6地址的排列，它表現為兩個16位的八位位組值。第一個值開始于IPV6地地址，第二個值結束IPV6地址。在兩個指定地址中的所有地址被認為在這個列表之中。
4.6.2.10ID_DER_ASN1_DN
這個ID_DER_ASN1_DN類型詳細說明二進制的DER，它是以ASN.1X.500來編碼的，它的證書被交換來建立這個SA.
4.6.2.11ID_DER_ASN1_GN
這個4.6.2.11ID_DER_ASN1_GN類型詳細說明二進制的DER，它是以ASN.1X.500來編碼的，它的證書被交換來建立SA。
4.6.2.12ID_KEY_ID
這個ID_KEY_ID類型詳細說明不透明的字節流，它可能被用來通過指定必須的的賣主信息來鑒別哪一個共享的密鑰應被用來鑒別侵權的談判模式。
4.6.3IPSEC通報信息類型
ISAKMP定義兩塊通報信息代碼，一個是錯誤的，另一個是狀態信息。ISAKMP也分配每塊中的一部分在DOL里作為私有用途。這個IPSECDOI為自己的用途定義下列私有信息。
通報信息-錯誤類型值
----------------------------------
保留的8192

通報信息-狀態類型值
-----------------------------------
RESPONDER-LIFETIME24576
REPLAY-STATUS24577
INITIAL-CONTACT24578

通知狀態信息MUST送到ISAKMPSA的保護下：在最后主要交換模式里任何一個作為有效載荷；在主要模式下的分離的信息交換或侵權的模式過程是完成的；或在任何快的模式交換里作為有效載荷。這些信息不應該被送到侵權的模式交換中，因為侵權模式不提供必須的保護來約束通報狀態信息交換。
特別注意：一個通報的有效載荷僅僅在快的模式下被完全保護，在那兒整個有效載荷被包含在HASH（n）分類中。在主要模式立，當通報信息被加密了，它不是普遍的包含在這個HASH(n)分類歷。結果，在主模式密文里，一個積極的攻擊能引起通報信息類型被改動。（這是真的，一般的，對于任何主模式交換里的最后的信息）當這個風險很小時，一個跟改過的通報信息可能引起接收者中斷整個談判，他想到發送者遇到了一個致命的錯誤。
4.6.3.1RESPONDER-LIFETIME
這個RESPONDER-LIFETIME狀態信息可能被用來協調由接受者選擇的IPSECSAlifetime。
當它存在時，通報有效載荷應該有下列格式：
。有效載荷長度－發送有效載荷的長度＋數據大?。╲ar）
。DOI-發送到IPSECDOI(1)
。ID協議－從選擇的SA發送到選擇的協議ID
。SPI大小-發送16（兩個eight-octetISAKMPcookies)或4（一個IPSECSPI）
。通報信息類型－發動RESPONDER-LIFETIME(Section4.6.3)
。SPI-發送兩個ISAKMPcookies或者道發送者的IPSECSPI
。告示數據－包含一個ISAKMP屬性列表,這個列表帶有回答者實際的SAlifetime(s)
執行時注意：通知數據領域包含一個屬性列表，它說明通知數據域有零長度并且通報有效載荷有相連的屬性列表。
4.6.3.2REPLAY-STATUS
這個REPLAY-STATUS狀態信息可能被用來對接受者的選擇作肯定證實，看他是否實現anti-replay的發現。
當它出現時，這個通知有效載荷應該有下列格式：
o有效載荷長度-設定有效載荷的長度+數據的大小(4）
oDOI-設定到IPSECDOI(1）
o協議ID-從選擇的SA選擇了協議ID集合
oSPI大小-設定到任何一個16(16)(2個8字節ISAKMPcookies)或4(4)(一IPSECSPI)
o通知消息類型-到REPLAY-STATUS的集合
oSPI-設定到2個ISAKMPcookies或到發送者的入站IPSECSPI
o通知數據-4字節值：
0=不可重放探測
1=啟用重放探測
4.6.3.3INITIAL-CONTACT
當一個方面希望通知其它方這是這是同遙遠系統建立的第一個SA時，INITIAL-CONTACT狀態消息可以被使用。這條通知消息的接收裝置然后可能選擇刪除任何存在的Sa，它在傳送系統時重新啟動，并且假設不再為傳送系統的原有Sa存取與他們聯系的密鑰材料。當使用時，通知數據域的內容應該為空(即有效載荷長度應該被設置為被通知有效載荷的固定長度)。

當前，通知有效載荷必須有下列格式：

o有效載荷長度-設定有效載荷的長度+數據的大小(0）
oDOI-設定到IPSECDOI(1）
o協議ID-從選擇的SA選擇了協議ID集合
oSPI大小-設定到16(16)(2個8字節ISAKMPcookies)
o通知消息類型-到INITIAL-CONTACT的集合
oSPI-設定到2個ISAKMPcookies
o通知數據-<不被包括>
4.7IPSEC密鑰交換要求
IPSECDOI不介紹附加的密鑰交換類型。
5．安全考慮
整個備忘錄屬于因特網密鑰交換協議（IKE）,它以一種安全的并且好鑒定的方式，聯合ISAKMP([ISAKMP])和[OAKLEY]來提供密鑰材料來源。各種各樣的安全協議和文件中轉換鑒別的特別討論能在相關的基礎文件和密碼參考書目中找到。
6．IANA需要考慮的事項
這個文件包含一些需要IANA來維持的“魔法”數字。這個章節解釋由IANA來使用的標準，用這個標準在每一個這些列表中分配附加數字。在前面章節中沒有明確說明的所有值對IANA來說是保留的。
6.1IPSEC位置定義
這個位置定義是一個32位bitmask，它描繪IPSECSA的建議和商談被實現的環境。請求分配新位置應該由一個RFC來完成，這個RFC由關聯位來解釋。
如果這個RFC不在標準軌跡上（也就是說，它是一個報告的或實驗的RFC），它應該在RFC被公開和轉化標識符被指派之前被明確的回復或被IESG認可。
這個上層的兩位在合作系統中被保留用作私有用途。
6.2IPSEC安全協議標識符
這個安全協議標識符適合一個8位值，它標識一個正需要討論的安全協議。請求分配一個新的安全協議標識符應該由一個RFC來實現，它描敘了這個需要的安全協議。[AH]和[ESP]是這個安全協議文件中的例子。
如果這個RFC不在標準軌跡上（也就是說，它是一個報告的或實驗的RFC），它應該在這個RFC被公開和這個轉化被指岀之前明確的評論和由IESG來認可。
這些值249-255在合作系統中被保留作為私有用途。
6.3IPSECISAKMP轉移標志符
這個IPSECISAKMP轉移標志符是一個8位的值，它標識一個用來流通的密鑰交換協議。
請求分配新的ISAKMP轉移標志符應該由RFC來完成，它描敘這個需要的密鑰交換協議。[IKE]是一個這種文件中的例子。
如果RFC不在標準軌跡上（也就是說，它是一個報告的或實驗的RFC），它應該在RFC被公開和這個轉移標識符被分配之前明確的指出和通過IESG來證實。
在合作系統中保留249－255這些值作為私有用途來使用。
6.4IPDECAH轉移標識符
這個IPSECAH轉移標識符是一個8位值，它鑒別一個特定的算法法則來為AH提供完整保護。請求分配一個新的AH轉移標識符應該由一個RFC來協助完成。這個RFC描繪了怎樣在AH框架中用這個運算法則。
如果這個RFC不是在這個標準軌跡上（也就是說,它是一個報告的或實驗的RFC），它應該在RFC被公開和這個轉移標識符被分配之前被明確的指出和通過IESG來證實。
在合作系統中保留這些值249－255來作為私有用途。
6.5IPSECESP轉移標識符
這個IPSECESP轉移標識符是一個8位的值，它鑒別一個特定的運算法則用來為ESP提供一個秘密保護。請求分配一個新的ESP轉移標識符應該由RFC來協作完成。這個RFC描敘了在ESP框架中怎樣用這個算法.
如果這個RFC不在這個標準軌跡上（也就是說，它不是一個報告的或實驗的RFC），它應該在RFC被公開和這個轉移標識符被分配之前被明確的指出和通過IESG來證實。
在合作系統中保留這些值249－255來作為私有用途。
6.6IPSECIPCOMP轉移標識符
這個IPSECIPCOMP轉移標識符是一個8位的值，在ESP之前它標識一個特定的運算法則用來提供IP層壓縮。請求分配一個新的IPCOMP轉移標識符應該由一個RFC來協作完成，它描敘了在IPCOMP框架（[IPCOMP]）中怎樣使用運算法則。另外，這個需要的運算法則應該被公開，并且在公共范圍內。
如果這個RFC不在這個標準軌跡上（也就是說，它是一個報告的或實驗的RFC），它應該在RFC被公開和這個轉移標識符被分配之前被明確的指出和通過IESG來證實。
因為RFC已被批準出版，這些值1－47就用來保存作運算法則。在合作系統中這些值48－63被保留作為私有用途。這些值64－255被保留作為將來擴展。
6.7IPSEC安全相連屬性
這個IPSEC安全相連屬性由16位類型和其相連的值組成。OPSECSA屬性用來在ISAKMP之間傳遞各種各樣的值。請求分配一個新的OPSECSA屬性應該由因特網草案來完成。它描敘了屬性代碼（基礎的/可變長度的）和它的合法值。這個文檔中的第4.5章提供了一個這樣描敘的例子。
在合作系統中這些值32001－32767被保留作為私有用途。
6.8IPSEC標簽范圍標識符
IPSEC標簽范圍標識符是一個32位的值，它鑒別一個namespace，在namespace里秘密層，完整層和各種值都存在。請求分配一個新的OPSEC標簽范圍標識符應該得到滿足。不需要合作文件，盡管在適當的時候因特網草案可以得到鼓勵。
在合作系統中這些值0x80000000-0xffffffff被保留作為私有用途。
6.9IPSEC標識符類型
這個IPSEC標識符類型是一個8位的值，它被用來作為一個解釋各種長度有效載荷的判別式。請求分配新的OPSEC鑒定類型應該由RFC來完成，它描敘了在OPSEC里怎樣使用這個鑒定。
如果RFC不是在標準軌跡上（也就是說，它是一個報告的或實驗的RFC），在RFC被公開和這個轉移標識符被分配之前，它應該明確的指出和由IESG來證實。
在合作系統中這些值249－255被保留作為私有用途。
6.10OPSEC通報信息類型
OPSEC通報信息類型是一個16位的值。這個值來自ISAKMP為每個DOL保留的值的變化。有一個錯誤信息的變動（8192－16383）和一個不同的狀態信息的變動（24576－32767）。請求分配新的通報信息類型應該由因特網草案來實現，在IPSEC里它描敘了怎樣用這個鑒定類型。
在合作系統中這些值16001－16383和這些值32001－32767被保留作為私有用途。

7．改變Log
7.1從V9中改變
。為[IPCOMP],[DEFLATE],和[LZS]增加明顯的參考書目。
。因為ISAKMP"SPI"，允許RESPONDER-LIFETIME和REPLAY-STATUS在IPSECSPI中直接指出。
。附加的填料排除秘密和完整地長度正文。
?？梢韵蚯皡⒖嫉?.5章和第4.4.4章。
。更新文件參考書目。

7.2從V8中改變
。更新IPCOMP標識符變化來更好地反映OPCOMP草案。
。更新IANA考慮的每個Jeff/Ted's暗示的正文。
。除去DES-MACID([DESMAC])的參考書目。
。更正通報章節中的bug；ISAKMP通報值是16位的。

7.3從V7中變化
。更正IPCOMP(IP有效載荷壓縮)的名字。
。更正[ESPCBC]的參考書目。
。在圖1中附加不可見的秘密層和完整層。
。移出涉及到PF_KEY和ARCFOUR的ID。
。更新基礎的/各種各樣的正文來排列[IKE].
。更新參考文件并且為[ARCH]增加引子指示。
。更新通知需求；移出一些侵權的參考書目。
。額外的澄清對通報有效載荷的保護。
?；謴蚏ESERVED到ESP轉移ID的位置；移出ESP_NULL.
。額外需要ESP_NULL的支持和[ESPNULL]的參考。
。附加的用AH/ESP來澄清AuthAlg。
。附加的約束來反對用沖突的AH/Auth聯合體。

7.4從V6中改變
下列這些改變是相對于IPSECDOIV6的。
。附加IANA需要考慮的章節
。移出多數IANA數到IANA需要考慮的章節。
。附加禁止發送(V)代碼屬性（B）.
。附加禁止為固定的長度的密碼(例如DES)發送密鑰長度屬性.
。用IKE取代涉及到ISAKMP/Oakley的參考書目。
。從ESP_ARCFOUR到ESP_RC4進行重命名。
。更新安全考慮章節。
。更新文檔參考書目。

7.5從V5中變化
下列變化與IPSECDOIV5有關系：
。在通知正文中改變SPI的大小
。改變REPLAY-ENABLED到REPLAY-STATUS
。從第4.5.4章到第4.6.3.1章中移動RESPONDER-LIFETIME有效載荷的定義
。為第4.6.3.3章附加明確的有效載荷規劃
。附加執行記錄到第4.6.3章中的介紹
。如果MD5成立，改變AH_SHA正文到需要的SHA-1
。更新文檔參考書目

7.6從V4中的變化
下列變化與IPSECDOIV4有關：
。從AH轉移ID到鑒定算法標識符中移動具有兼容性的AHKPDK的鑒定方法
。每一個結構附加REPLAY-ENABLED通知信息類型
。每個列表附加INITIAL-CONTACT通知信息類型
。附加內容來確信保護通報狀態信息
。附加屬性解析章節永久資格
。附加地澄清永久通知是任選的
。移開私有團體描敘列表（現在指向[IKE]）
。用指向RFC-2119的指針來取代這個術語
。更新HMACMD5和SHA-1ID參考書目
。更新章節1（抽象的）
。更新章節4.4（IPSEC分配的數）
。在第一個階段附加ID端口/協議值的約束

7.7從V3到V4的變化
下列變化與IPSECDOIV3有關，這個對IPSEC郵寄優于MUNICHIETF的列表來說是很有用的：
。為空和ARCFOUR附加轉移標識符
。重新命名HMAC運算法則到AUTH運算法則來進行協調DES-MAC和ESP可選的鑒定/完整性
。附加AH和ESPDES-MAC運算法則標識符
。移動DEY_MANUAL和KEY_KDC標識符定義
。附加永久MUST隨從屬性到SA類型和SA屬性定義
。附加永久通知何IPSECDOI信息類型表格
。附加可選的鑒定和機密性約束到MAC運算法則屬性定義
。更正屬性解析例子（習慣的過時的屬性）
。更正多個因特網草案文件參考書目
。對每個ipsec列表討論（18－Mar－97）附加ID_KEY_ID
。為PFSQM([IKE]MUST)移動默認團體描敘

致謝
這個文件部分起源于以下人的工作：DouglasMaughan,MarkSchertler,MarkSchneider,JeffTurner,DanHarkins,和DaveCarrel.MattThomas,RoyPereira,GregCarter,和RanAtkinson在很多種案例和正文中也提出了他們的建議。
參考書目
[AH]Kent,S.,andR.Atkinson,"IPAuthenticationHeader",RFC
2402,November1998.

[ARCH]Kent,S.,andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.

[DEFLATE]Pereira,R.,"IPPayloadCompressionUsingDEFLATE",RFC
2394,August1998.

[ESP]Kent,S.,andR.Atkinson,"IPEncapsulatingSecurity
Payload(ESP)",RFC2406,November1998.

[ESPCBC]Pereira,R.,andR.Adams,"TheESPCBC-ModeCipher
Algorithms",RFC2451,November1998.

[ESPNULL]Glenn,R.,andS.Kent,"TheNULLEncryptionAlgorithmand
ItsUseWithIPsec",RFC2410,November1998.

[DES]Madson,C.,andN.Doraswamy,"TheESPDES-CBCCipher
AlgorithmWithExplicitIV",RFC2405,November1998.

[HMACMD5]Madson,C.,andR.Glenn,"TheUseofHMAC-MD5withinESP
andAH",RFC2403,November1998.

[HMACSHA]Madson,C.,andR.Glenn,"TheUseofHMAC-SHA-1-96within
ESPandAH",RFC2404,November1998.

[IKE]Harkins,D.,andD.Carrel,D.,"TheInternetKeyExchange
(IKE)",RFC2409,November1998.

[IPCOMP]Shacham,A.,Monsour,R.,Pereira,R.,andM.Thomas,"IP
PayloadCompressionProtocol(IPComp)",RFC2393,August
1998.

[ISAKMP]Maughan,D.,Schertler,M.,Schneider,M.,andJ.Turner,
"InternetSecurityAssociationandKeyManagementProtocol
(ISAKMP)",RFC2408,November1998.

[LZS]Friend,R.,andR.Monsour,"IPPayloadCompressionUsing
LZS",RFC2395,August1998.

[OAKLEY]Orman,H.,"TheOAKLEYKeyDeterminationProtocol",RFC
2412,November1998.

[X.501]ISO/IEC9594-2,"InformationTechnology-OpenSystems
Interconnection-TheDirectory:Models",CCITT/ITU
RecommendationX.501,1993.

[X.509]ISO/IEC9594-8,"InformationTechnology-OpenSystems
Interconnection-TheDirectory:Authentication
Framework",CCITT/ITURecommendationX.509,1993.

Author'sAddress

DerrellPiper
NetworkAlchemy
1521.5PacificAve
SantaCruz,California,95060
UnitedStatesofAmerica

Phone:+1408460-3822
EMail:ddp@network-alchemy.com

全部版權陳述
版權（C）因特網社會（1998）。版權所有
這個文章和它的翻譯可能被復制和提供給別人，并且引出一些評論或者解釋它或援助它執行可能被準備，拷貝，出版和分配，不管是整體的還是局部的，沒有任何限制，提供這上面的版權告示和包含所有拷貝和起源工作的章節。但是，這個文章它自己本身不能以任何方式修改，例如通過移走版權告示或因特網團體或別的因特網組織的參考書目，除了發展因特網標準的需要，在這種情況下，定義在因特網標準過程中的版權程序應該要有，或者需要翻譯成不同于英語的別的語言。
這個受限的許可同意以上的聲明是永久的，并且它將不會被因特網團體或它的繼任者或設計者廢除。
包含在這兒的這個文件和通知作為一個基礎來提供。
這個因特網團體和這個因特網工程任務迫使它宣布所有的授權，表達或隱含，包括但是不限制任何授權，在這兒信息的用途不破壞任何權利或任何隱含的購買授權或一個特別的目的。