使用KEA和SKIPJACK加密

本備忘錄的狀態
本備忘錄詳細描述了Inte.netcommunity的實驗性協議，但不說明任何一種類型的Internet標準。它需要進一步進行討論和建議以得到改進。發布本備忘錄不受限制。
版權聲明
Copyright(C)TheInternetSociety(2000).保留所有權利。
概要
本文檔詳細描述了一個傳輸文件在使用FTP規范標準9、RFC959、“文件傳輸協議（FTP）”(1985年10月)[3]、和RFC2228“FTP安全擴展”（1997年10月）[1]時加密的方法。該方法將使用密鑰交換算法（KEA）提供相互鑒定并建立數據密鑰。SKIPJACK用來加密文件數據和FTP通道指令。
1.0介紹
文件傳輸協議（FTP），除了傳輸鑒定用戶身份的口令之外沒有提供安全協議。另外，該協議也不能保護遠程文件傳輸的鑒定狀態。
FTP的安全擴展問題已經提交到互聯網工程任務組(IETF)和通用鑒別技術工作組（CAT）。這些擴展允許該協議使用更多的柔性安全方案，并特別允許為FTP指令和數據連接提供多種級別的保護。該文檔描述了FTP安全擴展一個的輪廓，這些規則可能提供使用密鑰交換算法（KEA）和SKIPJACK協同的均衡加密算法。
FTP安全擴展[1]規則：
*用戶鑒定——加強一般密碼機制；
*服務器鑒定——正常地連接用戶鑒定；
*交換參數流通——特別的加密關鍵字和特征碼；
*指令連接保護——完整地，機密地，或包含以上兩點；
*數據傳輸保護——和指令連接保護類似
為了支持上述安全服務，兩個FTP實體需用一種機制溝通。這個過程是開放的和完整的，當兩個實體都接受同一機制或初始的一方（通常為客戶端）不能確定一個合適的機制時。一旦同意使用一個機制，它們會開始鑒定并進行參數傳遞。
交換和參數的傳遞發生在一個極大的交換組中。當交換完成，實體的任何一方（單方或雙方）會進行鑒定，然后，又準備去保護FTP指令和數據。
在交換完成之后，實體會緊接著對傳遞的緩沖區大小進行保護。這個過程用兩步完成：客戶端提出一個緩沖區尺寸，服務器端會從拒絕、修改、同意三者中選一。
至此，實體會在參數傳遞的綁定包里發出保護指令，并始終貫穿安全交換的全過程。保護指令被申請保護服務所需的一般指令和把結果譯成編碼的Base64指令發出。譯碼的結果被一個ENC（完整的和機密的）指令以數據流形式發送出去。Base64是一個把文本字符映射成二進制數據的譯碼指令，它能通過大多數的7位（bit）系統而不丟失。服務器的響應在新的結果碼中傳回，并且同樣也允許使用保護和Base64譯碼指令以應用于回應的結果。數據傳輸的保護被規定使用PROT指令，該指令支持同樣提供給其他FTP指令的保護。PROT指令能在有傳輸功能的系統中送出，不過，交換參數在交換過程中不能改變。
2.0密鑰交換算法（KEA）輪廓
本節描述KEA和SKIPJACKY在和FTP安全擴展框架聯合使用時如何完成可靠的安全服務。FTP實體將使用KEA來相互鑒定，并建立數據密鑰。我們詳細地說明一個簡單的標記格式和一組交換以陳述這些服務。相關功能會通過FortezzaCryptoCard來演示。
為了理解下面的協議，讀者要熟悉這些擴展。在FTP安全擴展的文章中，我們建議使用KEA和SKIPJACK來進行鑒定、保證完整性和機密性。
客戶端會與服務器相互鑒定。以下是在FTP安全擴展框架下實現KEA鑒定的協議必需的步驟。在遭遇失效狀態的地方，返回碼跟隨在擴展功能指定的列表中。但在本文檔中沒有列舉，因為它們在機制使用中是固定不變的。證書為ASN.1編碼。
以下假定一個FTP安全擴展的應用實例進行交換的詳細描述。聯接符號用“||”表示。加密的譯碼數據和鑒定路徑的確認是默認假定的，但沒有明示。
---------------------------------------------------------------------
客戶端服務器端
AUTHKEA-SKIPJACK-->
<--334ADAT=Base64(Certb||Rb)
ADATBase64(Certa||Ra||
WMEK||IV||Encrypt(
Label-Type||Label-Length||
Label-List||pad||ICV))-->
<--235ADAT=Base64(IV)
---------------------------------------------------------------------
圖1
服務器端和客戶端的證明書包含KEA公共密鑰?？蛻舳撕头掌鞫耸褂肒EA產生一個共享的SKIPJACK均衡密鑰，稱為TEK?？蛻舳耸褂秒S機數創建一個二次SKIPJACK密鑰，稱為MEK。為了傳輸到服務器，MEK被封裝在TEK中。當客戶端向服務器端傳輸時，一個初始化向量在MEK被創建時一同生成，一個客戶端要使用FTP任務的安全列表將被使用MEK加密后傳輸到服務器。如圖2所示，安全列表數據的格式是一個8位（1字節）的數值，一個4字節的列表長度，安全列表清單，補充，跟在一個8字節的完整校驗值（ICV）之后。圖3列出了列表的類型。如果列表的類型是缺省的（長度為0），則列表長度必須為0。
為了保證純文本的長度是密文塊大小的數倍，在完成后需要做如下補充：對SKIPJACKCBC密碼化處理的輸入將作8字節倍數的補充。設n是輸入的字節長度。補充的輸入附加8-(nmod8)字節到信息的末尾，每個信息均需附加8-(nmod8)個字節。在十六進制中，可能補充的字串是：01,0202,030303,04040404,0505050505,060606060606,07070707070707,and0808080808080808.所有的1至8字節補充輸入都是為了讓長度是8的倍數。只要使用SKIPJACKCBC加密技術，都要進行這樣的補充。
ICV是在對無格式文本安全列表和補充的計算得到的。ICV的算法是32位的自身反碼加法，每個32位塊跟隨32個0位。ICV算法在使用SKIPJACKCBC加密法時使用，以提供數據的完整性。
---------------------------------------------------------------------
列表類型1字節
列表長度4字節
列表清單可變長度
補充1到8字節
ICV8字節
---------------------------------------------------------------------
圖2
---------------------------------------------------------------------
列表類型列表語法參考
0缺省不適用
1MSPSDN.701[2]
2-255保留保留
--------------------------------------------------------------------
圖3
FTP指令通道操作現在是做為機密來保護的。為了提供完整性，指令序號、補充信息、和ICV都添加在每一個指令的前面以實現加密。
序列的完整性是通過為每個指令增加16位的序列數字來實現的。序列號初始化時是最低有效16位Ra。服務器的響應也會象客戶端那樣含有同樣的序列號。
IVC是通過單獨的指令（包括必要的回車和換行符以結束指令）、序列號、和補充信息計算出來的。
---------------------------------------------------------------------
客戶端服務器端
ENCBase64(Encrypt("PBSZ65535"
||SEQ||pad||ICV))-->
<--632Base64(Encrypt("200"||
SEQ||pad||ICV))
ENCBase64(Encrypt("USERyee"
||SEQ||pad||ICV))-->
<--632Base64(Encrypt("331"||
SEQ||pad||ICV))
ENCBase64(Encrypt("PASS
fortezza"||SEQ||
pad||ICV))-->
<--631Base64(Sign("230"))
---------------------------------------------------------------------
圖4
譯碼之后，兩個實體用PBSZ指令檢查預知的序列號和正確的ICV來校驗完整性。正確的SKIPJACK計算，ICV校驗，和包含KEA公用密鑰的證書，一起提供相互的辨認和鑒定。
---------------------------------------------------------------------
客戶端服務器端
ENCBase64(Encrypt("PROTP"||
SEQ||pad||ICV))-->
<--632Base64(Encrypt("200"||SEQ
||pad||ICV))
---------------------------------------------------------------------
圖5
至此，在使用中，文件將會以加密和完整性服務來發送和接收。如果應用加密技術，第一個緩沖區將包含標記，跟隨足夠多的譯文字節以完全充滿緩沖區（除非文件太短以至無法充滿緩沖區）。后面的緩沖區將僅包含譯文字節。除最后一個緩沖區外所有的緩沖區都會被完全充滿。
---------------------------------------------------------------------
客戶端服務器端
ENCBase64(Encrypt(
("RETRfoo.bar")||
SEQ||pad||ICV))-->
<--632Base64(Encrypt("150"||
SEQ||pad||ICV))
----------------------------------------------------------------------
圖6
下圖顯示頭信息和文件數據：
---------------------------------------------------------------------
PlaintextTokenIV
24字節
WMEK
12字節
Hashvalue
20字節
IV
24字節
LabelType
1字節
LabelLength
4字節
Label
LabelLength字節
Pad
1to8字節
ICV
8字節
---------------------------------------------------------------------
圖7
2.1加密前的文件支持
為了支持加密和加密前的文件，為傳輸一個文件的密鑰（FEK）定義一個標記。為防止殘損和保證文件完整，標記也包含了一個在完成的文件里計算出的無用信號。標記也和文件聯合在一起包含了安全列表。FEK封裝在TEK中。標記使用SKIPJACKCBC模式加密在TEK中。標記包含一個12字節的已封裝FEK，一個20字節的文件無用信息，一個24字節的文件IV，一個1字節的列表類型，一個4字節的列表長度，一個可變長度的列表數據，一個1至8字節的補充，和一個8字節的ICV。標記開始的24個字節是無格式的IV，一般用于標記的剩余內容的加密。標記需要它自己的加密IV，因為它通過數據通道傳輸，而不是指令通道，并且次序介于二個通道之間，但不能有保證。文件系統的文件計算前的密鑰和無用信息的存儲是一個本地執行問題。然而，如果一個文件在加密前被暗示，那么FEK會被在本地存儲的密鑰里封裝起來。當文件需要，FEK被用本地存儲密鑰解封，然后再在TEK中封裝。圖8顯示了裝配標記。
---------------------------------------------------------------------
PlaintextTokenIV
24字節
WrappedFEK
12字節
Hashvalue
20字節
IV
24字節
LabelType
1字節
LabelLength
4字節
Label
LabelLength字節
Pad
1to8字節
ICV
8字節
---------------------------------------------------------------------
3.0關鍵字術語表
為了清晰地闡明在協議中使用各種不同關鍵字，圖9概括了關鍵字的類型和它們的用途：
---------------------------------------------------------------------
關鍵字使用
TEK每個文件開始部分的加密標記，也封裝在MEK和FEK中
MEK指令加密通道
FEK文件自我加密(可能超出FTP范圍)
---------------------------------------------------------------------
圖9
4.0安全考慮
整個備忘錄是關于安全機制的。KEA提供了鑒定和可供討論的密鑰管理，當解密私人密鑰時，執行必須得到保護。SKIPJACK提供了可供討論的機密性，當解密公共均衡密鑰時執行必須得到保護。
5.0感謝
我們對在制訂這個規范是作出貢獻的ToddHorting表示感謝。
6.0參考書目
[1]Horowitz,M.andS.Lunt,“FTP安全擴展”，RFC2228，1997年10月。
[2]消息傳輸安全協議4.0（MSP），修訂版A。安全數據網絡系統（SDNS）SDN.701,1997年2月6日。
[3]Postel,J.andJ.Reynolds,“FTP傳輸協議”，STD9,RFC959,1985年10月。
7.0作者地址
RussellHousley
SPYRUS
381EldenStreet
Suite1120
Herndon,VA20170
USA
Phone:+1703707-0696
EMail:housley@spyrus.com

PeterYee
SPYRUS
5303BetsyRossDrive
SantaClara,CA95054
USA
Phone:+1408327-1901
EMail:yee@spyrus.com
8.0完整的版權聲明
Copyright(C)TheInternetSociety(2000)。版權所有。
本文檔及其譯文可以拷貝和提供給他人，且其衍生物，如評論、解釋或幫助實施的作品可以全部或部分地定制、拷貝、出版和發布，對此我們不加任何限制，前提是上述版權聲明，及本段內容包含在所有的拷貝和派生作品中。然而，本文檔本身不允許以任何方式修改，例如刪除Internet社團或其他Internet組織的版權聲明或參考，除非是為了開發Internet標準的需要。即便在這種情況下，也需要添加Internet標準中定義的版權聲明，或者根據需要把他翻譯成英語以外的其他語言。
上述準許的有限許可是永久性的，無論是Internet社團以及其繼承者或代理者都將不會廢止這些許可。
本文檔及其中包含的信息基于“ASIS”提供，而且INTERNET社團和IETF拒絕所有授權、表達或影射，包括但不限于任何這里使用的消息的授權將不會違背任何版權或者隱含的商業性授權或對特定的合理目的。
致謝
目前，RFC編者活動的基金由Internet社團提供。