[要約] RFC 2420は、PPP Triple-DES Encryption Protocol（3DESE）に関する規格です。このプロトコルの目的は、PPPセッションを安全に暗号化することです。
Network Working Group H. Kummert
Request for Comments: 2420 Nentec GmbH
Category: Standards Track September 1998
The PPP Triple-DES Encryption Protocol (3DESE)
PPP Triple-DES暗号化プロトコル（3DESE）
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
ポイントツーポイントプロトコル（PPP）[1]は、ポイントツーポイントリンクを介してマルチプロトコルデータグラムを転送する標準的な方法を提供します。
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
PPP暗号化制御プロトコル（ECP）[2]は、PPPカプセル化リンクを介して暗号化プロトコルをネゴシエートして利用する方法を提供します。
This document provides specific details for the use of the Triple-DES standard (3DES) [6] for encrypting PPP encapsulated packets.
このドキュメントでは、PPPカプセル化パケットを暗号化するためのTriple-DES標準（3DES）[6]の使用に関する特定の詳細を提供します。
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
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つの実装を介して行われる通信のプライバシーを保証することです。 DESアルゴリズムをはじめとする、さまざまな暗号化アルゴリズムが存在します。 DES暗号化アルゴリズムはよく研究され、理解され、広く実装されている暗号化アルゴリズムです。 Triple-DESは、このアルゴリズムが暗号化されるデータに3回適用されてから、回線を介して送信されることを意味します。使用されているバリアントは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暗号化制御プロトコル[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」、および「recommended」は、[3]で説明されているように解釈されます。
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では、初期化ベクトル（IV）は、最初の64ビット（8オクテット）平文ブロック（P1）とXORされます。キー付きDES関数は、暗号化（E）、復号化（D）、暗号化（E）の3回繰り返され、ブロックの暗号文（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.
連続するブロックの場合、以前の暗号文ブロックは現在の8オクテットの平文ブロック（Pi）とXORされます。キー付きDES-EDE3暗号化機能は、そのブロックの暗号文（Ci）を生成します。
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
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と同等です。
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]を拒否する必要があります。
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 has the following fields, which are transmitted from left to right:
ECP 3DESE構成オプションは、発行側の実装がリンク上の通信を復号化するためにこの仕様を採用することを提案していることを示しており、この方法でパケットを暗号化するピアへの要求と考えることができます。 ECP 3DESE構成オプションには次のフィールドがあり、左から右に送信されます。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2, to indicate the 3DESE protocol.
2、3DESEプロトコルを示します。
Length
長さ
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バイトの量で、送信側がオープン状態に達した後に送信される最初のパケットを暗号化するためにピア実装で使用されます。リプレイ攻撃を防ぐために、実装は各ECPネゴシエーション中に異なる値を提供する必要があります（SHOULD）。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address and Control
アドレスと制御
These fields MUST be present unless the PPP Address and Control Field Compression option (ACFC) has been negotiated.
これらのフィールドは、PPPアドレスおよび制御フィールド圧縮オプション（ACFC）がネゴシエートされていない限り、存在する必要があります。
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.
このフィールドの値は0x53または0x55です。後者は、個別リンク暗号化制御プロトコルの使用と、暗号文にマルチリンクフラグメントが含まれていることを示します。プロトコルフィールド圧縮は、交渉された場合、先行ゼロに適用される場合があります。
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.
このデータの生成については、次のセクションで説明します。
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パケットにも暗号化手順を適用してはなりません（MUST NOT）。
If the async control character map option has been negotiated on the link, the sender applies mapping after the encryption algorithm has been run.
非同期制御文字マップオプションがリンクでネゴシエートされている場合、送信者は暗号化アルゴリズムが実行された後にマッピングを適用します。
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バイトの倍数にパディングし、セクション1.1で説明されているように3つの56ビットキーk1、k2、k3を使用して3DESを適用します。
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がオープン状態になった後の最初のパケットを暗号化するとき、初期ノンスは使用前に3DESアルゴリズムによって暗号化されます。
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オクテットの倍数ではない長さのプレーンテキストパケットは、暗号化の前にパディングする必要があります。復号化後にこのパディングが削除されない場合、プロトコルヘッダーに明示的な長さフィールドを含まない一部のプロトコルの解釈に悪影響を与える可能性があります。
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バイトの倍数ではないすべてのパケットは、最大パッド値（MPV）が8の自己記述型パディングという明確な手法を使用して暗号化する前にパディングする必要があります。これは、プレーンテキストがオクテットのシーケンスでパディングされることを意味します1、2、3、.. 7は、その長さが8オクテットの倍数であるためです。 SDPの交渉は必要ありません。 LCP自己記述型オプションの交渉は、直交問題を解決するために独立して交渉することができます。
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.
個々のリンクでマルチリンクと暗号化を使用する場合、すべての非終端フラグメントの長さを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.
ピアが暗号文を復号化した後、ピアは自己記述型パディングオクテットを取り除き、元のプレーンテキストを再作成します。ピアは、パディングを形成するオクテットが上記の自己記述型パディング方式と一致しない場合、フレームを破棄する必要があります（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.
復号化後、自己記述型パッドの有無を判断するには、最後のバイトの内容のみを調べる必要があることに注意してください。
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を復号化することは不可能です。ただし、すべてのパケットN + 1以降は通常の方法で復号化できます。前のパケット（この場合はWASが受信したパケットN）の暗号文の最後のブロックが必要です。
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 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.
セキュリティの問題は、このメモの主要な主題です。この提案は、共有された秘密を取得するための外部の不特定の方法に依存しています。それはプライバシーのための新しい技術を提案しませんが、PPP実装間のデータ伝送への3DES暗号の適用のための規約を説明するだけです。共有シークレットの保護と取得の方法論、および3DES暗号の制限は、ここで説明する使用に関連しています。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] シンプソン、W、編集者、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[2] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[2] Meyer、G。、「The PPP Encryption Control Protocol（ECP）」、RFC 1968、1996年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[4] Sklower、K。、およびG. Meyer、「The PPP DES Encryption Protocol、Version 2（DESE-bis）」、RFC 2419、1998年9月。
[5] Doraswamy, N., Metzger, P., Simpson, W., "The ESP Triple DES Transform", Work in Progress, June 1997.
[5] Doraswamy、N.、Metzger、P.、Simpson、W.、 "The ESP Triple DES Transform"、Work in Progress、1997年6月。
[6] Schneier, B., "Applied Cryptography", Second Edition, John Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.
[6] Schneier、B。、「Applied Cryptography」、Second Edition、John Wiley＆Sons、ニューヨーク、ニューヨーク、1995、ISBN 0-471-12845-7。
Many portions of this document were taken from [4] and [5]. Bill Simpson gave useful hints on the initial revision.
このドキュメントの多くの部分は、[4]と[5]から引用されました。ビル・シンプソンは、最初の改訂について有益なヒントを与えました。
Holger Kummert Nentec Gesellschaft fuer Netzwerktechnologie 76227 Karlsruhe, Killisfeldstr. 64, Germany
Holger Kummert Nentec Society for Network Technology 76227 Karlsruhe、Killisfeldstr。 64、ドイツ
Phone: +49 721 9495 0
EMail: kummert@nentec.de
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。