Network Working Group R. Housley
Request for Comments: 2773 P. Yee
Updates: 959 SPYRUS
Category: Experimental W. Nace
NSA
February 2000
Encryption using KEA and SKIPJACK
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October 1985) [3] and RFC 2228, "FTP Security Extensions" (October 1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys. SKIPJACK is used to encrypt file data and the FTP command channel.
この文書では、FTPの仕様STD 9、RFC 959、 "ファイル転送プロトコル（FTP）"、（1985年10月）を使用してファイル転送を暗号化する方法を定義して、[3]とRFC 2228、 "FTPセキュリティ拡張機能"（1997年10月）[ 1]。この方法では、相互認証を与え、データ暗号化キーを確立するために、鍵交換アルゴリズム（KEA）を使用します。 SKIPJACKは、ファイルデータとFTPコマンドチャネルを暗号化するために使用されます。
The File Transfer Protocol (FTP) provides no protocol security except for a user authentication password which is transmitted in the clear. In addition, the protocol does not protect the file transfer session beyond the original authentication phase.
ファイル転送プロトコル（FTP）は平文で送信されたユーザ認証パスワードを除いて一切のプロトコルのセキュリティを提供しません。また、プロトコルは、元の認証フェーズを超えてファイル転送セッションを保護しません。
The Internet Engineering Task Force (IETF) Common Authentication Technology (CAT) Working Group has proposed security extensions to FTP. These extensions allow the protocol to use more flexible security schemes, and in particular allows for various levels of protection for the FTP command and data connections. This document describes a profile for the FTP Security Extensions by which these mechanisms may be provisioned using the Key Exchange Algorithm (KEA) in conjunction with the SKIPJACK symmetric encryption algorithm.
IETF（Internet Engineering Task Force）の共通認証技術（CAT）ワーキンググループは、FTPへのセキュリティ拡張を提案しました。これらの拡張機能は、プロトコルが、より柔軟なセキュリティ方式を使用することができ、特に、FTPコマンドおよびデータ接続の保護のさまざまなレベルが可能になります。この文書では、これらのメカニズムはカツオ、対称暗号化アルゴリズムと一緒に鍵交換アルゴリズム（KEA）を使用してプロビジョニングされるかもしれないFTPセキュリティ拡張のためのプロファイルを記述する。
FTP Security Extensions [1] provides:
FTPセキュリティ拡張[1]提供：
* user authentication -- augmenting the normal password mechanism;
*ユーザー認証 - 通常のパスワードメカニズムを増強。
* server authentication -- normally done in conjunction with user authentication;
*サーバ認証 - 通常、ユーザー認証と連動して行われます。
* session parameter negotiation -- in particular, encryption keys and attributes;
*セッションパラメータのネゴシエーション - 特に、暗号化キーと属性;
* command connection protection -- integrity, confidentiality, or both;
*コマンド接続保護 - 完全性、機密性、またはその両方。
* data transfer protection -- same as for command connection protection.
*データ転送保護 - コマンド接続の保護のためのと同じ。
In order to support the above security services, the two FTP entities negotiate a mechanism. This process is open-ended and completes when both entities agree on an acceptable mechanism or when the initiating party (always the client) is unable to suggest an agreeable mechanism. Once the entities agree upon a mechanism, they may commence authentication and/or parameter negotiation.
上記のセキュリティサービスをサポートするために、2つのFTPエンティティがメカニズムを交渉します。このプロセスは、オープンエンドで、両方のエンティティが許容できるメカニズムに同意するか、開始パーティ（常にクライアント）が快いメカニズムを提案することができないときときに完了します。エンティティがメカニズムに同意したら、彼らは、認証および/またはパラメータの交渉を開始することができます。
Authentication and parameter negotiation occur within an unbounded series of exchanges. At the completion of the exchanges, the entities will either be authenticated (unilateral or mutually), and may, additionally, be ready to protect FTP commands and data.
認証とパラメータのネゴシエーションは、取引所の無限のシリーズ内で発生します。交換の完了時に、エンティティは、（一方的または相互）認証され、そして、さらに、FTPコマンドとデータを保護する準備ができてよいです。
Following the exchanges, the entities negotiate the size of the buffers they will use in protecting the commands and data that follow. This process is accomplished in two steps: the client offers a suggested buffer size and the server may either refuse it, counter it, or accept it.
交換後、実体は、彼らが続くコマンドやデータを保護する際に使用するバッファのサイズを交渉します。このプロセスは、2つのステップで達成される：クライアントは、それを拒否し、それに対抗、またはそれを受け入れることのいずれかを示唆したバッファサイズとサーバを提供しています。
At this point, the entities may issue protected commands within the bounds of the parameters negotiated through the security exchanges. Protected commands are issued by applying the protection services required to the normal commands and Base64 encoding the results. The encoded results are sent as the data field within a ENC (integrity and confidentiality) command. Base64 is an encoding for mapping binary data onto a textual character set that is able to pass through most 7-bit systems without loss. The server sends back responses in new result codes which allow the identical protections and Base64 encoding to be applied to the results. Protection of the data transfers can be specified via the PROT command which supports the same protections as those afforded the other FTP commands. PROT commands may be sent on a transfer-by-transfer basis, however, the session parameters may not be changed within a session.
この時点では、エンティティは、セキュリティの交流を通じて交渉されたパラメータの範囲内で保護されたコマンドを発行することができます。保護されたコマンドは、結果をコードする通常のコマンドとはBase64に必要な保護サービスを適用することにより、発行されています。符号化された結果は、ENC（整合性と機密保護）コマンド内のデータフィールドとして送信されます。 BASE64は損失なし最も7ビットシステムを通過することができるテキスト文字セットにバイナリデータをマッピングするための符号化です。サーバは、同一の保護とBase64エンコード結果に適用されることを可能にする新しい結果コードで応答を返送します。データ転送の保護は、他のFTPコマンドを与えたものと同様の保護をサポートしていPROTコマンドで指定することができます。 PROTコマンドは転送によって転送基づいて送信されてもよい、しかし、セッションパラメータは、セッション内で変更されなくてもよいです。
This paper profiles KEA with SKIPJACK to achieve certain security services when used in conjunction with the FTP Security Extensions framework. FTP entities may use KEA to give mutual authentication and establish data encryption keys. We specify a simple token format and set of exchanges to deliver these services. Functions that may be performed by the Fortezza Crypto Card.
本論文では、FTPセキュリティ拡張フレームワークと組み合わせて使用すると、特定のセキュリティサービスを実現するためにSKIPJACKでKEAプロファイル。 FTPエンティティは、相互認証を与え、データ暗号化キーを確立するためにKEAを使用することができます。私たちは、単純なトークン形式を指定し、これらのサービスを提供する交換のセット。フォルテッツァ暗号カードによって行うことができる機能。
The reader should be familiar with the extensions in order to understand the protocol steps that follow. In the context of the FTP Security Extensions, we suggest the usage of KEA with SKIPJACK for authentication, integrity, and confidentiality.
読者が続くプロトコルステップを理解するために、拡張子に精通している必要があります。 FTPセキュリティ拡張のコンテキストでは、我々は、認証、完全性、機密性のためにSKIPJACKとKEAの使用を示唆しています。
A client may mutually authenticate with a server. What follows are the protocol steps necessary to perform KEA authentication under the FTP Security Extensions framework. Where failure modes are encountered, the return codes follow those specified in the Extensions. They are not enumerated in this document as they are invariant among the mechanisms used. The certificates are ASN.1 encoded.
クライアントが相互にサーバとの認証を行ってもよいです。以下は、FTPセキュリティ拡張フレームワークの下でKEA認証を実行するために必要なプロトコルステップです。故障モードが発生した場合は、リターンコードは、拡張機能で指定されたものに従ってください。彼らは使用されるメカニズムの中で不変であると彼らはこの文書で列挙されません。証明書は、ASN.1エンコードされています。
The exchanges detailed below presume a working knowledge of the FTP Security Extensions. The notation for concatenation is " || ". Decryption of encrypted data and certification path validation is implicitly assumed, but is not shown.
以下に詳細交換はFTPセキュリティ拡張の実用的な知識を推定します。連結のための表記は「||」です。暗号化されたデータと認証パス検証の復号化は暗黙のうちに想定されますが、表示されません。
---------------------------------------------------------------------
Client Server
AUTH KEA-SKIPJACK -->
<-- 334 ADAT=Base64( Certb || Rb )
ADAT Base64( Certa || Ra ||
WMEK || IV || Encrypt(
Label-Type || Label-Length ||
Label-List || pad || ICV ) ) -->
<-- 235 ADAT=Base64( IV )
---------------------------------------------------------------------
Figure 1
The server and client certificates contain KEA public keys. The client and server use KEA to generate a shared SKIPJACK symmetric key, called the TEK. The client uses the random number generator to create a second SKIPJACK key, called the MEK. The MEK is wrapped in the TEK for transfer to the server. An initialization vector (IV) associated with the MEK is generated by the client and transferred to the server. A list of security labels that the client wants to use for this FTP session may be transferred to the server encrypted in the MEK. As shown in Figure 2, the security label data is formatted as a one octet type value, a four octet label length, the security label list, padding, followed by an eight octet integrity check value (ICV). Figure 3 lists the label types. If the label type is absent (value of zero length), then the label size must be zero.
サーバーとクライアント証明書はKEA公開鍵が含まれています。クライアントとサーバーの使用KEAが共有カツオ対称鍵を生成し、TEKと呼ばれます。クライアントは、MEKと呼ばれる二SKIPJACKキーを作成するために、乱数ジェネレータを使用しています。 MEKは、サーバーへの転送のためにTEKに包まれています。 MEKに関連した初期化ベクトル（IV）は、クライアントによって生成され、サーバーに転送されます。クライアントは、このFTPセッションのために使用したいセキュリティラベルのリストは、MEKで暗号化されたサーバーに転送することができます。図2に示されるように、セキュリティ・ラベル・データは、8つのオクテット整合性チェック値（ICV）、続いて、1つのオクテットのタイプ値は、4つのオクテットラベル長さ、セキュリティラベルのリスト、パディング、としてフォーマットされます。図3は、ラベルの種類を示しています。ラベルタイプ（長さゼロの値）存在しない場合には、ラベルのサイズがゼロでなければなりません。
In order to ensure that the length of the plain text is a multiple of the cryptographic block size, padding shall be performed as follows. The input to the SKIPJACK CBC encryption process shall be padded to a multiple of 8 octets. Let n be the length in octets of the input. Pad the input by appending 8 - (n mod 8) octets to the end of the message, each having the value 8 - (n mod 8), the number of octets being added. In hexadecimal, he possible pad strings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, 07070707070707, and 0808080808080808. All input is padded with 1 to 8 octets to produce a multiple of 8 octets in length. This pad technique is used whenever SKIPJACK CBC encryption is performed.
次のように、プレーンテキストの長さは、暗号ブロックサイズの倍数であることを保証するために、パディングが行われなければなりません。 SKIPJACK CBC暗号化プロセスへの入力は8つのオクテットの倍数に水増しされなければなりません。 n個の入力のオクテットの長さとします。パッド8を付加することにより、入力 - それぞれが値8を有する、メッセージの最後に（N MOD 8）オクテット - （N MOD 8）は、オクテットの数が追加されます。進数では、彼の可能なパッドの文字列がある：01、0202、030303、04040404、0505050505、060606060606、07070707070707、及び0808080808080808.すべての入力は長さが8つのオクテットの倍数を生成するために1〜8オクテットで埋められます。 SKIPJACK CBC暗号化が行われるたびに、このパッドの技術が使用されています。
An ICV is calculated over the plaintext security label and padding. The ICV algorithm used is the 32-bit one's complement addition of each 32-bit block followed by 32 zero bits. This ICV technique is used in conjunction with SKIPJACK CBC encryption to provide data integrity.
ICVは平文セキュリティラベルとパディングの上に計算されます。使用ICVアルゴリズムは、32ビットのゼロに続く各32ビットブロックの32ビットの1の補数の加算です。このICV技術は、データの整合性を提供するためにSKIPJACK CBC暗号化と組み合わせて使用されます。
---------------------------------------------------------------------
Label Type 1 Octet
Label Length 4 octets
Label List variable length
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 2
---------------------------------------------------------------------
Label Type Label Syntax Reference
0 Absent Not applicable
1 MSP SDN.701[2]
2-255 Reserved for Future Use To Be Determined
---------------------------------------------------------------------
Figure 3
FTP command channel operations are now confidentiality protected. To provide integrity, the command sequence number, padding, and ICV are appended to each command prior to encryption.
FTPコマンドチャネルの動作について機密保護されています。整合性を実現するには、コマンドシーケンス番号、パディング、およびICVは暗号化の前に、各コマンドに追加されます。
Sequence integrity is provided by using a 16-bit sequence number which is incremented for each command. The sequence number is initialized with the least significant 16-bits of Ra. The server response will include the same sequence number as the client command.
配列の完全性は、各コマンドのために増分される16ビットのシーケンス番号を使用して提供されます。シーケンス番号は、Raが最下位16ビットで初期化されます。サーバーの応答は、クライアントのコマンドと同じシーケンス番号が含まれます。
An ICV is calculated over the individual commands (including the carriage return and line feed required to terminate commands), the sequence number, and pad.
ICVは、シーケンス番号、及びパッド（キャリッジリターンとコマンドを終了するために必要な改行を含む）は、個々のコマンドに対して計算されます。
---------------------------------------------------------------------
Client Server
ENC Base64(Encrypt("PBSZ 65535"
|| SEQ || pad || ICV )) -->
<-- 632 Base64(Encrypt("200" ||
SEQ || pad || ICV))
ENC Base64(Encrypt("USER yee"
|| SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("331" ||
SEQ || pad || ICV))
ENC Base64(Encrypt("PASS
fortezza" || SEQ ||
pad || ICV)) -->
<-- 631 Base64(Sign("230"))
---------------------------------------------------------------------
Figure 4
After decryption, both parties verifying the integrity of the PBSZ commands by checking for the expected sequence number and correct ICV. The correct SKIPJACK key calculation, ICV checking, and the validation of the certificates containing the KEA public keys provides mutual identification and authentication.
復号化した後、両当事者は期待シーケンス番号と正しいICVをチェックしてPBSZコマンドの整合性を検証します。正しいSKIPJACKキー計算、ICVチェック、およびKEA公開鍵を含む証明書の検証が相互識別および認証を提供します。
---------------------------------------------------------------------
Client Server
ENC Base64(Encrypt("PROT P" ||
SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("200" || SEQ
|| pad || ICV))
---------------------------------------------------------------------
Figure 5
At this point, files may be sent or received with encryption and integrity services in use. If encryption is used, then the first buffer will contain the token followed by enough encrypted file octets to completely fill the buffer (unless the file is too short to fill the buffer). Subsequent buffers contain only encrypted file octets. All buffers are completely full except the final buffer.
この時点で、ファイルが使用中の暗号化と整合性サービスを送信または受信することができます。暗号化が使用されている場合は、最初のバッファ（ファイルがバッファを満たすには短すぎる場合を除き）完全にバッファを満たすのに十分な暗号化ファイルオクテットに続くトークンが含まれています。以降のバッファは、のみ暗号化されたファイルのオクテットを含んでいます。すべてのバッファは、最終バッファを除いて完全に満ちています。
---------------------------------------------------------------------
Client Server
ENC Base64(Encrypt(
("RETR foo.bar") ||
SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("150" ||
SEQ || pad || ICV))
---------------------------------------------------------------------
Figure 6
The next figure shows the header information and the file data.
次の図は、ヘッダ情報とファイルデータを示します。
---------------------------------------------------------------------
Plaintext Token IV 24 octets
WMEK 12 octets
Hashvalue 20 octets
IV 24 octets
Label Type 1 octets
Label Length 4 octets
Label Label Length octets
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 7
In order to support both on-the-fly encryption and pre-encrypted files, a token is defined for carrying a file encryption key (FEK). To prevent truncation and ensure file integrity, the token also includes a hash computed on the complete file. The token also contains the security label associate with the file. This FEK is wrapped in the session TEK. The token is encrypted in the session TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type, a 4 octet label length, a variable length label value, a one to 8 octet pad, and an 8 octet ICV. The first 24 octets of the token are the plaintext IV used to encrypt the remainder of the token. The token requires its own encryption IV because it is transmitted across the data channel, not the command channel, and ordering between the channels cannot be guaranteed. Storage of precomputed keys and hashes for files in the file system is a local implementation matter; however, it is suggested that if a file is pre-encrypted, then the FEK be wrapped in a local storage key. When the file is needed, the FEK is unwrapped using the local storage key, and then rewrapped in the session TEK. Figure 8 shows the assembled token.
オンザフライの暗号化と暗号化前のファイルの両方をサポートするために、トークンは、ファイル暗号化キー（FEK）を運ぶために定義されています。切り捨てを防ぎ、ファイルの整合性を確保するために、トークンは、完全なファイル上で計算されたハッシュを含んでいます。トークンは、ファイルとセキュリティラベルの仲間が含まれています。このFEKは、セッションTEKに包まれています。トークンはSKIPJACK CBCモードを使用してセッションTEKで暗号化されています。トークンは、FEKラップ12オクテット、20オクテットファイルハッシュ、24オクテットファイルIV、1つのオクテットのラベルの種類、4オクテットラベル長、可変長ラベル値、8オクテットパッドへの1つ、および8オクテットを含んでいますICV。トークンの最初の24個のオクテットはIVがトークンの残りの部分を暗号化するために使用平文です。それは、データチャネルではなく、コマンドチャネルを介して送信されるため、トークンは、独自の暗号化IVを必要とし、チャンネル間の順序は保証できません。ファイルシステム内のファイルの予め計算されたキーとハッシュのストレージはローカルの導入問題です。しかし、ファイルが事前に暗号化されている場合、FEKは、ローカルストレージ・キーに包まれたことが示唆されました。ファイルが必要な場合、FEKは、ローカルストレージ・キーを使用してアンラップして、セッションTEKにリラップされます。図8は、組み立てられたトークンを示しています。
---------------------------------------------------------------------
Plaintext Token IV 24 octets
Wrapped FEK 12 octets
Hashvalue 20 octets
IV 24 octets
Label Type 1 octet
Label Length 4 octets
Label Label Length octets
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 8
In order to clarify the usage of various keys in this protocol, Figure 9 summarizes key types and their usage:
このプロトコルにおける各種キーの使用を明確にするために、図9は、キーの種類とその使用方法を要約したものです。
---------------------------------------------------------------------
Key Type Usage
TEK Encryption of token at the beginning of
each file, also wraps the MEK and the FEK
MEK Encryption of command channel
FEK Encryption of the file itself (may be
done out of scope of FTP)
---------------------------------------------------------------------
Figure 9
This entire memo is about security mechanisms. For KEA to provide the authentication and key management discussed, the implementation must protect the private key from disclosure. For SKIPJACK to provide the confidentiality discussed, the implementation must protect the shared symmetric keys from disclosure.
この全体のメモは、セキュリティ・メカニズムについてです。 KEAは議論認証と鍵管理を提供するために、実装は、開示から秘密鍵を保護しなければなりません。 SKIPJACKが議論機密性を提供するために、実装は、開示から共有対称鍵を保護する必要があります。
We would like to thank Todd Horting for insights gained during implementation of this specification.
我々は、この仕様の実装中に得られた洞察のためのトッドHortingに感謝したいと思います。
[1] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[1]ホロヴィッツ、M.とS.ラント、 "FTPセキュリティ拡張機能"、RFC 2228、1997年10月。
[2] Message Security Protocol 4.0 (MSP), Revision A. Secure Data Network System (SDNS) Specification, SDN.701, February 6, 1997.
[2]メッセージセキュリティプロトコル4.0（MSP）、リビジョンA.は、安全なデータネットワークシステム（SDNS）仕様、SDN.701、1997年2月6日。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[3]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
Russell Housley SPYRUS 381 Elden Street Suite 1120 Herndon, VA 20170 USA
ラッセルHousleyのSPYRUS 381 Eldenストリートスイート1120ハーンドン、VA 20170 USA
Phone: +1 703 707-0696 EMail: housley@spyrus.com
電話：+1 703 707-0696 Eメール：housley@spyrus.com
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara, CA 95054 USA
ピーター・イーSPYRUS 5303ベッツィー・ロスドライブサンタクララ、CA 95054 USA
Phone: +1 408 327-1901 EMail: yee@spyrus.com
電話：+1 408 327-1901 Eメール：yee@spyrus.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。