RFC2420 日本語訳
2420 The PPP Triple-DES Encryption Protocol (3DESE). H. Kummert. September 1998. (Format: TXT=16729 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Kummert Request for Comments: 2420 Nentec GmbH Category: Standards Track September 1998
Kummertがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2420年のNentec GmbHカテゴリ: 標準化過程1998年9月
The PPP Triple-DES Encryption Protocol (3DESE)
ppp三重のDES暗号化プロトコル(3DESE)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
[2]がPPPの上で暗号化プロトコルを交渉して、利用する方法を提供するPPP Encryption Controlプロトコル(ECP)はリンクを要約しました。
This document provides specific details for the use of the Triple-DES standard (3DES) [6] for encrypting PPP encapsulated packets.
このドキュメントはTriple-DESの標準の(3DES)[6]のPPPをコード化する使用のための特定の詳細に要約のパケットを提供します。
Table of Contents
目次
1. Introduction .............................................. 2 1.1 Algorithm ................................................. 2 1.2 Keys ...................................................... 3 2. 3DESE Configuration Option for ECP ........................ 3 3. Packet format for 3DESE ................................... 4 4. Encryption ................................................ 5 4.1 Padding ................................................... 5 4.2 Recovery after packet loss ................................ 6 5. Security Considerations ................................... 6 6. References ................................................ 7 7. Acknowledgements .......................................... 7 8. Author's Address .......................................... 7 9. Full Copyright Statement .................................. 8
1. 序論… 2 1.1アルゴリズム… 2 1.2個のキー… 3 2. ECPのための3DESE設定オプション… 3 3. 3DESEのためのパケット形式… 4 4. 暗号化… 5 4.1 そっと歩きます… 5 パケット損失の後の4.2回復… 6 5. セキュリティ問題… 6 6. 参照… 7 7. 承認… 7 8. 作者のアドレス… 7 9. 完全な著作権宣言文… 8
Kummert Standards Track [Page 1] RFC 2420 PPP Triple-DES Encryption September 1998
暗号化1998年9月の三重のDESのKummert標準化過程[1ページ]RFC2420ppp
1. Introduction
1. 序論
The purpose of encrypting packets exchanged between two PPP implementations is to attempt to insure the privacy of communication conducted via the two implementations. There exists a large variety of encryption algorithms, where one is the DES algorithm. The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm. Triple-DES means that this algorithm is applied three times on the data to be encrypted before it is sent over the line. The variant used is the DES-EDE3-CBC, which is described in more detail in the text. It was also chosen to be applied in the security section of IP [5].
2つのPPP実現の間で交換されたパケットをコード化する目的は2つの実現で行われたコミュニケーションのプライバシーを保障するのを試みることです。 さまざまな暗号化アルゴリズムが存在しています。そこでは、1つがDESアルゴリズムです。 DES暗号化アルゴリズムはよく研究された、理解されている、広く実行された暗号化アルゴリズムです。 三重のDESは、このアルゴリズムが線でそれを送る前にコード化するためにデータで3回適用されることを意味します。 使用される異形はDES-EDE3-CBCです。(そのDES-EDE3-CBCはさらに詳細にテキストで説明されます)。 また、それは、IP[5]のセキュリティ部で適用されるために選ばれました。
This document shows how to send via the Triple-DES algorithm encrypted packets over a point-to-point-link. It lies in the context of the generic PPP Encryption Control Protocol [2].
このドキュメントは、Triple-DESアルゴリズムで二地点間リンクの上にどのようにコード化されたパケットを送るかを示します。 それは一般的なPPP Encryption Controlプロトコル[2]の文脈に横たわっています。
Because of the use of the CBC-mode a sequence number is provided to ensure the right order of transmitted packets. So lost packets can be detected.
CBC-モードの使用のために、伝えられたパケットの正しい注文を確実にするために一連番号を提供します。 そのように失われたパケットは検出できます。
The padding section reflects the result of the discussion on this topic on the ppp mailing list.
詰め物部はこの話題についての議論の結果をpppメーリングリストに反映します。
In this document, the key words "MUST", "SHOULD", and "recommended" are to be interpreted as described in [3].
本書では、キーワード“MUST"、“SHOULD"、および「お勧め」は[3]で説明されるように解釈されることです。
1.1 Algorithm
1.1アルゴリズム
The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algorithm. In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 octet) plaintext block (P1). The keyed DES function is iterated three times, an encryption (E) followed by a decryption (D) followed by an encryption (E), and generates the ciphertext (C1) for the block. Each iteration uses an independent key: k1, k2 and k3.
DES-EDE3-CBCアルゴリズムはDES-CBCアルゴリズムの簡単な異形です。 DES-EDE3-CBCでは、初期設定Vector(IV)はそうです。XORは最初に64ビット(8八重奏)の平文ブロック(P1)でそうするでしょう。 合わせられたDES機能が3回繰り返されて、復号化(D)があとに続いた暗号化(E)は、暗号化(E)で続いて、暗号文(C1)をブロックに発生させます。 各繰り返しは独立しているキーを使用します: k1、k2、およびk3。
For successive blocks, the previous ciphertext block is XOR'd with the current 8-octet plaintext block (Pi). The keyed DES-EDE3 encryption function generates the ciphertext (Ci) for that block.
連続したブロックに関して、前の暗号文ブロックはそうです。XORは現在の8八重奏平文ブロック(パイ)でそうするでしょう。 合わせられたDES-EDE3暗号化機能は暗号文(Ci)をそのブロックに発生させます。
Kummert Standards Track [Page 2] RFC 2420 PPP Triple-DES Encryption September 1998
暗号化1998年9月の三重のDESのKummert標準化過程[2ページ]RFC2420ppp
P1 P2 Pi
| | |
IV--->(X) +------>(X) +-------->(X)
v | v | v
+-----+ | +-----+ | +-----+
k1->| E | | k1->| E | : k1->| E |
+-----+ | +-----+ : +-----+
| | | : |
v | v : v
+-----+ ^ +-----+ ^ +-----+
k2->| D | | k2->| D | | k2->| D |
+-----+ | +-----+ | +-----+
| | | | |
v | v | v
+-----+ | +-----+ | +-----+
k3->| E | | k3->| E | | k3->| E |
+-----+ | +-----+ | +-----+
| | | | |
+---->+ +------>+ +---->
| | |
C1 C2 Ci
P1 P2パイ| | | IV--->(X) +------>(X) +-------->(X) v| v| +に対して-----+ | +-----+ | +-----+ k1>| E| | k1>| E| : k1>| E| +-----+ | +-----+ : +-----+ | | | : | v| v: +に対して-----+ ^ +-----+ ^ +-----+ k2>| D| | k2>| D| | k2>| D| +-----+ | +-----+ | +-----+ | | | | | v| v| +に対して-----+ | +-----+ | +-----+ k3>| E| | k3>| E| | k3>| E| +-----+ | +-----+ | +-----+ | | | | | +---->++------>++---->|、|、| C1 C2 Ci
To decrypt, the order of the functions is reversed: decrypt with k3, encrypt with k2, decrypt with k1, and XOR with the previous cipher- text block.
解読するために機能の注文を逆にします: 解読する、k3でk2によるコード化、k1、およびXORと共に前の暗号テキストブロックで解読します。
When all three keys (k1, k2 and k3) are the same, DES-EDE3-CBC is equivalent to DES-CBC.
すべての3個のキー(k1、k2、およびk3)が同じであるときに、DES-EDE3-CBCはDES-CBCに同等です。
1.2 Keys
1.2 キー
The secret DES-EDE3 key shared between the communicating parties is effectively 168-bits long. This key consists of three independent 56-bit quantities used by the DES algorithm. Each of the three 56- bit subkeys is stored as a 64-bit (8 octet) quantity, with the least significant bit of each octet used as a parity bit.
長い間、事実上、交信パーティーの間で共有された秘密のDES-EDE3キーは168ビットです。 このキーはDESアルゴリズムで使用される3つの独立している56ビットの量から成ります。 それぞれの3個の56の噛み付いているサブキーが64ビット(8八重奏)の量として収納されます、それぞれの八重奏の最下位ビットがパリティビットとして使用されている状態で。
When configuring keys for 3DESE those with incorrect parity or so- called weak keys [6] SHOULD be rejected.
3DESE不正確な同等があるそれらか弱いキー[6]と呼ばれるそうSHOULDのためのキーが拒絶されるのを構成するとき。
2. 3DESE Configuration Option for ECP
2. ECPのための3DESE設定オプション
Description
記述
The ECP 3DESE Configuration Option indicates that the issuing
implementation is offering to employ this specification for
decrypting communications on the link, and may be thought of as
a request for its peer to encrypt packets in this manner. The
ECP 3DESE Configuration Optionは、発行実現がリンクに関するコミュニケーションを解読するためのこの仕様を使うと申し出ていて、同輩がこの様にパケットをコード化するという要求として考えられるかもしれないのを示します。 The
Kummert Standards Track [Page 3] RFC 2420 PPP Triple-DES Encryption September 1998
暗号化1998年9月の三重のDESのKummert標準化過程[3ページ]RFC2420ppp
ECP 3DESE Configuration Option has the following fields, which
are transmitted from left to right:
ECP 3DESE Configuration Optionには、以下の野原がいます:(その野原は、左から右まで伝えられます)。
Figure 1: ECP 3DESE Configuration Option
図1: ECP 3DESE設定オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Initial Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一回だけに頭文字をつけてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2, to indicate the 3DESE protocol.
2 3DESEプロトコルを示すために。
Length
長さ
10
10
Initial Nonce
初期の一回だけ
This field is an 8 byte quantity which is used by the peer
implementation to encrypt the first packet transmitted
after the sender reaches the opened state. To guard
against replay attacks, the implementation SHOULD offer a
different value during each ECP negotiation.
この分野は送付者が開かれた状態に着いた後に伝えられた最初のパケットをコード化するのに同輩実現で使用される8バイトの量です。 反射攻撃に用心するために、実現SHOULDはそれぞれのECP交渉の間、異価を提供します。
3. Packet format for 3DESE
3. 3DESEのためのパケット・フォーマット
Description
記述
The 3DESE packets that contain the encrypted payload have the
following fields:
コード化されたペイロードを含む3DESEパケットは以下の分野を持っています:
Figure 2: 3DESE Encryption Protocol Packet Format
図2: 3DESE暗号化プロトコルパケット・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control | 0000 | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. No. High | Seq. No. Low | Ciphertext ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス| コントロール| 0000 | プロトコルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq。 いいえ 高値| Seq。 いいえ 安値| 暗号文… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address and Control
アドレスとコントロール
These fields MUST be present unless the PPP Address and
Control Field Compression option (ACFC) has been
PPP AddressとControl Field Compressionオプション(ACFC)がなかった場合、これらの分野は存在していなければなりません。
Kummert Standards Track [Page 4] RFC 2420 PPP Triple-DES Encryption September 1998
暗号化1998年9月の三重のDESのKummert標準化過程[4ページ]RFC2420ppp
negotiated.
交渉にされる。
Protocol ID
プロトコルID
The value of this field is 0x53 or 0x55; the latter
indicates the use of the Individual Link Encryption
Control Protocol and that the ciphertext contains a
Multilink fragment. Protocol Field Compression MAY be
applied to the leading zero if negotiated.
この分野の値は、0×53か0×55です。 後者は、Individual Link Encryption Controlプロトコルの使用と、暗号文がMultilink断片を含むのを示します。 交渉されるなら、プロトコルField Compressionは先行ゼロに適用されるかもしれません。
Sequence Number
一連番号
These 16-bit numbers are assigned by the encryptor
sequentially starting with 0 (for the first packet
transmitted once ECP has reached the opened state).
これらの16ビットの数は0(ECPがいったん開かれた状態に達すると伝えられた最初のパケットのための)から連続して、始まる暗号化する人によって割り当てられます。
Ciphertext
暗号文
The generation of this data is described in the next
section.
このデータの世代は次のセクションで説明されます。
4. Encryption
4. 暗号化
Once the ECP has reached the Opened state, the sender MUST NOT apply the encryption procedure to LCP packets nor ECP packets.
一度ECPはOpened状態に達したことがあって、送付者は暗号化手順をLCPパケットに適用してはいけません。または、ECPパケット。
If the async control character map option has been negotiated on the link, the sender applies mapping after the encryption algorithm has been run.
async制御文字地図オプションがリンクに関して交渉されたなら、暗号化アルゴリズムが走った後に送付者はマッピングを適用します。
The encryption algorithm is generally to pad the Protocol and Information fields of a PPP packet to some multiple of 8 bytes, and apply 3DES as described in section 1.1 with the three 56-bit keys k1, k2 and k3.
暗号化アルゴリズムは、一般に、PPPパケットのプロトコルと情報分野を8バイトの何らかの倍数に水増しして、3の56ビットのキーk1でセクション1.1で説明される3DES、k2、およびk3を適用することです。
The encryption procedure is only applied to that portion of the packet excluding the address and control field.
暗号化手順はアドレスと制御フィールドを除いたパケットのその一部に適用されるだけです。
When encrypting the first packet after ECP stepped into opened state the Initial Nonce is encrypted via 3DES-algorithm before its use.
踏み込まれたECPが状態を開いた後に最初のパケットをコード化するとき、Initial Nonceは使用の前の3DES-アルゴリズムでコード化されます。
4.1 Padding
4.1 詰め物
Since the 3DES algorithm operates on blocks of 8 octets, plain text packets which are of length not a multiple of 8 octets must be padded prior to encrypting. If this padding is not removed after decryption this can be injurious to the interpretation of some protocols which do not contain an explicit length field in their protocol headers.
以来、3DESアルゴリズムは8つの八重奏(コード化する8つの八重奏のどんな倍数もそっと歩くはずがない前長さのものであるプレーンテキストパケット)のブロックを作動させます。 この詰め物が復号化の後に取り除かれないなら、これは彼らのプロトコルヘッダーに明白な長さの分野を含まないいくつかのプロトコルの解釈に有害である場合があります。
Kummert Standards Track [Page 5] RFC 2420 PPP Triple-DES Encryption September 1998
暗号化1998年9月の三重のDESのKummert標準化過程[5ページ]RFC2420ppp
Therefore all packets not already a multiple of eight bytes in length MUST be padded prior to encrypting using the unambiguous technique of Self Describing Padding with a Maximum Pad Value (MPV) of 8. This means that the plain text is padded with the sequence of octets 1, 2, 3, .. 7 since its length is a multiple of 8 octets. Negotiation of SDP is not needed. Negotiation of the LCP Self Describing Option may be negotiated independently to solve an orthogonal problem.
8のMaximum Pad Value(MPV)と共にSelf Describing Paddingの明白なテクニックを使用して、コード化の前に既に長さにおける、8バイトの倍数ではなく、したがって、すべてのパケットを水増ししなければなりません。 これは、プレーンテキストでそっと歩くことを意味します。八重奏1、2の系列、3。 長さ以来の7は8つの八重奏の倍数です。 SDPの交渉は必要ではありません。 LCP Self Describing Optionの交渉は、直交した問題を解決するために独自に交渉されるかもしれません。
Plain text which length is already a multiple of 8 octets may require padding with a further 8 octets (1, 2, 3 ... 8). These additional octets MUST only be appended, if the last octet of the plain text had a value of 8 or less.
それの長さが既に8つの八重奏の倍数であるプレーンテキストが、より遠い8つの八重奏でそっと歩くのを必要とするかもしれない、(1 2 3 .8) これらの追加八重奏を追加するだけでよいです、プレーンテキストの最後の八重奏に8以下の値があったなら。
When using Multilink and encrypting on individual links it is recommended that all non-terminating fragments have a length divisible by 8. So no additional padding is needed on those fragments.
個々のリンクの上のMultilinkとコード化を使用するとき、非の終わり断片ですべて、長さが8時までに分割可能になるのは、お勧めです。 それで、どんな追加詰め物もそれらの断片の上に必要ではありません。
After the peer has decrypted the ciphertext, it strips off the Self Describing Padding octets to recreate the original plain text. The peer SHOULD discard the frame if the octets forming the padding do not match the Self Describing Padding scheme just described.
同輩が暗号文を解読した後に、それは、オリジナルのプレーンテキストを休養させるためにSelf Describing Padding八重奏を全部はぎ取ります。 詰め物を形成する八重奏がただ説明されたSelf Describing Padding計画に合っていないなら、同輩SHOULDはフレームを捨てます。
Note that after decrypting, only the content of the last byte needs to be examined to determine the presence or absence of a Self Described Pad.
解読する後に最後のバイトの内容だけが、Self Described Padの存在か不在を決定するために調べられる必要に注意してください。
4.2 Recovery after packet loss
4.2 パケット損失の後の回復
Packet loss is detected when there is a discontinuity in the sequence numbers of consecutive packets. Suppose packet number N - 1 has an unrecoverable error or is otherwise lost, but packets N and N + 1 are received correctly.
連続したパケットの一連番号に不連続があるとき、パケット損失は検出されます。 パケット番号であるなら、N--1を回復不能エラーを持っているか、または別の方法で失いますが、正しくパケットNとN+1を受け取ります。
Since the previously described algorithm requires the last Ci of packet N - 1 to decrypt C1 of packet N, it will be impossible to decrypt packet N. However, all packets N + 1 and following can be decrypted in the usual way, since all that is required is the last block of ciphertext of the previous packet (in this case packet N, which WAS received).
以前に説明されたアルゴリズムがパケットNのC1を解読するためにパケットN--1を最後のCiに要求するので、パケットN.がHoweverであると解読するのが不可能である、不断のとおりすべてのパケットN+1と次の事柄を解読することができます、必要であるすべてが前のパケット(この場合受け取られたパケットN)の暗号文の最後のブロックであるので。
5. Security Considerations
5. セキュリティ問題
This proposal is concerned with providing confidentiality solely. It does not describe any mechanisms for integrity, authentication or nonrepudiation. It does not guarantee that any message received has not been modified in transit through replay, cut-and-paste or active tampering. It does not provide authentication of the source of any
この提案は唯一秘密性を提供するのに関係があります。 それは保全、認証または非拒否のためにどんなメカニズムについても説明しません。 それは、受け取られたどんなメッセージもトランジットで再生、カットアンドペーストまたはアクティブないじることで変更されていないのを保証しません。 それはいずれの源の認証を提供しません。
Kummert Standards Track [Page 6] RFC 2420 PPP Triple-DES Encryption September 1998
暗号化1998年9月の三重のDESのKummert標準化過程[6ページ]RFC2420ppp
packet received, or protect against the sender of any packet denying its authorship.
パケットが受信されたか、または著述業を否定するどんなパケットの送付者からも守ってください。
Security issues are the primary subject of this memo. This proposal relies on exterior and unspecified methods for retrieval of shared secrets. It proposes no new technology for privacy, but merely describes a convention for the application of the 3DES cipher to data transmission between PPP implementations. Any methodology for the protection and retrieval of shared secrets, and any limitations of the 3DES cipher are relevant to the use described here.
安全保障問題はこのメモの第一の対象です。 この提案は共有秘密キーの検索のための外の、そして、不特定の方法を当てにします。 それは、プライバシーのために新技術を全く提案しませんが、3DES暗号の応用のために単にPPP実現の間のデータ伝送にコンベンションについて説明します。 共有秘密キーの保護と検索、および3DES暗号のどんな制限のためのどんな方法論もそうです。ここで説明された使用に関連しています。
6. References
6. 参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[2] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
1968, June 1996.
[2] マイヤー、G.、「ppp暗号化制御プロトコル(ECP)」、RFC1968 1996年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
1998年9月の[4] Sklower、K.とG.マイヤー、「ppp DES暗号化プロトコル、バージョン2(2回DESE)」RFC2419。
[5] Doraswamy, N., Metzger, P., Simpson, W., "The ESP Triple DES
Transform", Work in Progress, June 1997.
[5] Doraswamy(N.、メッツガー、P.、シンプソン、「超能力の三重のDESは変える」W.)は進歩、1997年6月に働いています。
[6] Schneier, B., "Applied Cryptography", Second Edition, John Wiley
& Sons, New York, NY, 1995, ISBN 0-471-12845-7.
[6]シュナイアー、B.、「適用された暗号」、第2版、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1995、ISBN0-471-12845-7。
7. Acknowledgements
7. 承認
Many portions of this document were taken from [4] and [5]. Bill Simpson gave useful hints on the initial revision.
[4]と[5]からこのドキュメントの多くの一部を取りました。 ビル・シンプソンは初期の改正のときに役に立つヒントを与えました。
8. Author's Address
8. 作者のアドレス
Holger Kummert Nentec Gesellschaft fuer Netzwerktechnologie 76227 Karlsruhe, Killisfeldstr. 64, Germany
オルガーKummert Nentec Gesellschaft fuer Netzwerktechnologie76227カールスルーエ、Killisfeldstr。 64 ドイツ
Phone: +49 721 9495 0 EMail: kummert@nentec.de
以下に電話をしてください。 +49 721 9495 0 メール: kummert@nentec.de
Kummert Standards Track [Page 7] RFC 2420 PPP Triple-DES Encryption September 1998
暗号化1998年9月の三重のDESのKummert標準化過程[7ページ]RFC2420ppp
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Kummert Standards Track [Page 8]
Kummert標準化過程[8ページ]
一覧
スポンサーリンク
