RFC2773 日本語訳
2773 Encryption using KEA and SKIPJACK. R. Housley, P. Yee, W. Nace. February 2000. (Format: TXT=20008 bytes) (Updates RFC0959) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 2773 P. Yee
Updates: 959 SPYRUS
Category: Experimental W. Nace
NSA
February 2000
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2773のP.イーアップデート: 959SPYRUSカテゴリ: 実験的なW.Nace NSA2000年2月
Encryption using KEA and SKIPJACK
ケアとトビウオの類を使用する暗号化
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
このドキュメントは2228年の(1985年10月)のSTD9、RFC959、「ファイル転送プロトコル(FTP)」、[3]、およびRFCのときにFTP仕様を使用することでファイル転送を暗号化するメソッドを定義します、「FTPセキュリティ拡大」(1997年10月)[1]。 このメソッドは、互いの認証を与えて、データ暗号化キーを証明するのに、Key Exchange Algorithm(KEA)を使用するでしょう。 SKIPJACKは、ファイルデータとFTP指揮系統を暗号化するのに使用されます。
1.0 Introduction
1.0 序論
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.
File Transferプロトコル(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)の一般的なAuthentication Technology(CAT)作業部会はセキュリティ拡大をFTPに提案しました。 これらの拡大は、よりフレキシブルなセキュリティがFTPコマンドとデータ接続のための様々なレベルの保護のために計画して、特に許す使用にプロトコルを許容します。 このドキュメントはSKIPJACKの左右対称の暗号化アルゴリズムに関連してKey Exchange Algorithm(KEA)を使用することでこれらのメカニズムが食糧を供給されるかもしれないFTP Security Extensionsのためのプロフィールについて説明します。
Housley, et al. Experimental [Page 1] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[1ページ]RFC2773暗号化
FTP Security Extensions [1] provides:
FTP Security Extensions[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
ここに、実体はセキュリティ交換を通して交渉されたパラメタの領域の中で保護されたコマンドを発行するかもしれません。 通常のコマンドに必要である保護サービスと結果をコード化するBase64を適用することによって、保護されたコマンドを発行します。 ENC(保全と秘密性)の中のデータ分野が命令するようにコード化された結果を送ります。 Base64は、損失なしでほとんどの7ビットのシステムを通り抜けることができる原文の文字集合にバイナリ・データを写像するためのコード化です。 サーバは同じ保護とBase64コード化が結果に適用されるのを許容する新しい結果コードにおける応答を返送します。 保護、データ転送缶では、指定されていて、PROTを通してどのサポートを命令してくださいか。
Housley, et al. Experimental [Page 2] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[2ページ]RFC2773暗号化
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.
それらと同じ保護は他のFTPコマンドを提供しました。 転送ごとのベースでPROTコマンドを送るかもしれなくて、しかしながら、セッション以内にセッションパラメタを変えないかもしれません。
2.0 Key Exchange Algorithm (KEA) Profile
2.0 主要な交換アルゴリズム(ケア)プロフィール
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 Security Extensionsフレームワークに関連して使用されると、この紙は、あるセキュリティー・サービスを達成するためにSKIPJACKと共にKEAの輪郭を描きます。 FTP実体は、互いの認証を与えて、データ暗号化キーを証明するのにKEAを使用するかもしれません。 私たちは、これらのサービスを提供するために簡単なトークン形式と1セットの交換を指定します。 Fortezza Crypto Cardによって実行されるかもしれない機能。
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 Security Extensionsの文脈では、私たちは認証、保全、および秘密性のために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 Security Extensionsフレームワークの下で互いにaサーバどんな尾行が実行するのに必要なプロトコルステップであるかでKEA認証を認証するかもしれません。 故障モードが遭遇するところに、復帰コードはExtensionsで指定されたものに続きます。 それらは、本書では使用されるメカニズムの中で不変であるので、数え上げられません。 証明書はコード化された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 Security Extensionsの実用的な知識を推定します。 「連結のための記法はそうです」|| ". 暗号化されたデータと証明経路合法化の復号化は、それとなく想定されますが、示されません。
--------------------------------------------------------------------- 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
AUTH KEA-SKIPJACK--><--334ADAT=Base64(Certb| | Rb)ADAT Base64、(Certa| | Ra| | WMEK| | IV| | (ラベルタイプ| | ラベル長さ| | ラベルリスト| | パッド| | ICV)を暗号化してください--、><--、235ADAT=Base64(IV)--------------------------------------------------------------------- 図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
サーバとクライアント証明書はKEA公開鍵を含んでいます。 TEKは、クライアントとサーバが共有されたSKIPJACKが対称鍵であると生成するのにKEAを使用すると呼びました。 MEKは、クライアントが2番目のSKIPJACKキーを作成するのに乱数発生器を使用すると呼びました。 MEKは中に包装されます。
Housley, et al. Experimental [Page 3] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[3ページ]RFC2773暗号化
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.
. 初期化ベクトル(IV)がMEKに関連づけたサーバへの転送のためのTEKをクライアントは生成して、サーバに移します。クライアントがこのFTPセッションに使用したがっている機密保護ラベルのリストをMEKで暗号化されたサーバに移すかもしれません。 図2に示されるように、1つの八重奏タイプが評価するようにセキュリティラベルデータはフォーマットされます、4八重奏ラベルの長さ、8八重奏保全チェック価値(ICV)をラベル・リスト(詰め物)が続けたセキュリティ。 図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モッズ風の8)八重奏--(nモッズ風の8)を追加することによって、入力を水増ししてください、加えられる八重奏の数。 16進で彼、可能なパッドストリングは以下の通りです。 01、0202、030303、04040404、0505050505、060606060606、07070707070707、および0808080808080808。 すべての入力が1〜8つの八重奏で水増しされて、長さにおける、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
--------------------------------------------------------------------- Type1Octet Label Length4八重奏Label List可変長Padの1〜8八重奏をICV8八重奏とラベルしてください。--------------------------------------------------------------------- 図2
---------------------------------------------------------------------
Label Type Label Syntax Reference
0 Absent Not applicable
1 MSP SDN.701[2]
2-255 Reserved for Future Use To Be Determined
--------------------------------------------------------------------- Future Use未定のためのラベルType Label Syntax Reference0のAbsent Notの適切な1MSP SDN.701[2]2-255のReserved
---------------------------------------------------------------------
Figure 3
--------------------------------------------------------------------- 図3
Housley, et al. Experimental [Page 4] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[4ページ]RFC2773暗号化
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
暗号化..パッド..暗号化..パッド..暗号化..ユーザ..イー..パッド..暗号化..パッド..暗号化..パス..パッド..サイン--------------------------------------------------------------------- 図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.
復号化、予想された一連番号がないかどうかチェックすることによってPBSZコマンドの保全について確かめる双方、および正しいICVの後に。 KEA公開鍵を含む証明書の正しいSKIPJACK主要な計算、ICVの照合、および合法化は互いの識別と認証を提供します。
---------------------------------------------------------------------
Client Server
--------------------------------------------------------------------- クライアントサーバ
ENC Base64(Encrypt("PROT P" ||
SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("200" || SEQ
|| pad || ICV))
---------------------------------------------------------------------
Figure 5
ENC Base64(暗号化します("PROT P"| | SEQ| | パッド| | ICV))--><--632Base64(暗号化します(「200」| | SEQ| | パッド| | ICV))--------------------------------------------------------------------- 図5
Housley, et al. Experimental [Page 5] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[5ページ]RFC2773暗号化
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
ENC Base64(暗号化します(("RETR foo.bar")| | SEQ| | パッド| | ICV))--><--632Base64(暗号化します(「150」| | SEQ| | パッド| | ICV))--------------------------------------------------------------------- 図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
--------------------------------------------------------------------- 平文Token IV24八重奏WMEK12八重奏Hashvalue20八重奏IV24八重奏Label Type1八重奏Label Length4八重奏Label Label Length八重奏Padの1〜8八重奏ICV、8つの八重奏--------------------------------------------------------------------- 図7
2.1 Pre-encrypted File Support
2.1 あらかじめ暗号化されたファイルサポート
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
ハエの暗号化とあらかじめ暗号化されたファイルの両方をサポートして、トークンは、ファイル暗号化キー(FEK)を運ぶために定義されます。 また、トランケーションを防いで、ファイル保全を確実にするために、トークンは完全なファイルの上で計算されたハッシュを含んでいます。 また、トークンはファイルの機密保護ラベル関連を含んでいます。 このFEKはセッションTEKのときに包装されます。 トークンは、セッションTEKのときにSKIPJACK CBCモードを使用することで暗号化されます。 トークンは12八重奏の包装されたFEK、20八重奏ファイルハッシュ、24八重奏ファイルIV、1つの八重奏ラベル形式、4八重奏ラベルの長さ、可変長ラベル価値、1〜8八重奏パッド、および8八重奏ICVを含んでいます。 トークンの最初の24の八重奏がトークンの残りを暗号化するのに使用される平文IVです。 トークンは、指揮系統ではなく、データ・チャンネルの向こう側に伝えられて、間に注文するので、それ自身の暗号化IVを必要とします。
Housley, et al. Experimental [Page 6] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[6ページ]RFC2773暗号化
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.
チャンネルを保証できません。 ファイルシステムのファイルのための前計算されたキーとハッシュのストレージはローカルの実装問題です。 しかしながら、包装されたコネがローカルの主記憶キイであったならファイルがaであるならあらかじめ暗号化されていて、その時がFEKであると示唆されます。 ファイルが必要であると、FEKはローカルの主記憶キイを使用することで開けられて、セッションTEKのときに再包装されます。 エイト環は組み立てられたトークンを示しています。
---------------------------------------------------------------------
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
--------------------------------------------------------------------- 平文Token IV24八重奏Wrapped FEK12八重奏Hashvalue20八重奏IV24八重奏Label Type1八重奏Label Length4八重奏Label Label Length八重奏Padの1〜8八重奏ICV、8つの八重奏--------------------------------------------------------------------- エイト環
3.0 Table of Key Terminology
3.0 主要な用語のテーブル
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)
--------------------------------------------------------------------- それぞれの始めのトークンの主要なType Usage TEK Encryptionはファイル自体の指揮系統FEK EncryptionのMEKとFEK MEK Encryptionをファイルして、また、包装します。(FTPの範囲からするかもしれません)
---------------------------------------------------------------------
Figure 9
--------------------------------------------------------------------- 図9
4.0 Security Considerations
4.0 セキュリティ問題
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が議論した秘密性を提供するように、実装は公開から共有された対称鍵を保護しなければなりません。
5.0 Acknowledgements
5.0 承認
We would like to thank Todd Horting for insights gained during implementation of this specification.
洞察のためのHortingがこの仕様の実装の間、獲得したのをトッドに感謝申し上げます。
Housley, et al. Experimental [Page 7] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[7ページ]RFC2773暗号化
6.0 References
6.0の参照箇所
[1] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228,
October 1997.
[1] ホロビッツとM.とS.ラント、「FTPセキュリティ拡大」、RFC2228、1997年10月。
[2] Message Security Protocol 4.0 (MSP), Revision A. Secure Data
Network System (SDNS) Specification, SDN.701, February 6, 1997.
[2] メッセージセキュリティは1997年2月6日に4.0(MSP)、改正のA.の安全なデータ網システム(SDNS)仕様、SDN.701について議定書の中で述べます。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985.
[3] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
7.0 Authors' Addresses
7.0 作者のアドレス
Russell Housley SPYRUS 381 Elden Street Suite 1120 Herndon, VA 20170 USA
ラッセルHousley SPYRUS381エルデン・通りスイート1120ヴァージニア20170ハーンドン(米国)
Phone: +1 703 707-0696 EMail: housley@spyrus.com
以下に電話をしてください。 +1 703 707-0696 メールしてください: housley@spyrus.com
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara, CA 95054 USA
ピーターイーSPYRUS5303ベッツィ・ロス・Driveカリフォルニア95054サンタクララ(米国)
Phone: +1 408 327-1901 EMail: yee@spyrus.com
以下に電話をしてください。 +1 408 327-1901 メールしてください: yee@spyrus.com
Housley, et al. Experimental [Page 8] RFC 2773 Encryption using KEA and SKIPJACK February 2000
Housley、他 ケアとトビウオの類2000年2月を使用する実験的な[8ページ]RFC2773暗号化
8.0 Full Copyright Statement
8.0 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Housley, et al. Experimental [Page 9]
Housley、他 実験的[9ページ]
一覧
スポンサーリンク
