Network Working Group H. Kummert
Request for Comments: 2420 Nentec GmbH
Category: Standards Track September 1998
Network Working Group H. Kummert
Request for Comments: 2420 Nentec GmbH
Category: Standards Track September 1998
The PPP Triple-DES Encryption Protocol (3DESE)
PPP三重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.
版权所有（C）互联网协会（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.
本文件提供了使用三重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. 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].
加密两个PPP实现之间交换的数据包的目的是试图确保通过这两个实现进行的通信的隐私。有很多种加密算法，其中一种是DES算法。DES加密算法是一种经过充分研究、理解和广泛实施的加密算法。三重DES意味着在通过线路发送数据之前，该算法对要加密的数据应用三次。所使用的变体是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].
本文档介绍如何通过三重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].
在本文件中，关键词“必须”、“应该”和“建议”的解释如[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）异或。密钥DES函数迭代三次，先加密（E），然后解密（D），再加密（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.
对于连续的块，前一个密文块与当前的8八位字节明文块（Pi）异或。密钥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
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解密，用前面的密文块进行异或。
When all three keys (k1, k2 and k3) are the same, DES-EDE3-CBC is equivalent to DES-CBC.
当所有三个键（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算法使用的三个独立的56位量组成。三个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配置选项指示发出实现提供使用该规范来解密链路上的通信，并且可以被认为是请求其对等方以这种方式加密数据包。这个
ECP 3DESE Configuration Option has the following fields, which are transmitted from left to right:
ECP 3DESE配置选项具有以下字段，这些字段从左向右传输：
Figure 1: ECP 3DESE Configuration Option
图1:ECP3DESE配置选项
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 | Length | Initial Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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字节的数量，对等实现使用它来加密发送方达到打开状态后传输的第一个数据包。为了防止重播攻击，实现应该在每次ECP协商期间提供不同的值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
除非已启用PPP地址和控制字段压缩选项（ACFC），否则这些字段必须存在
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.
该字段的值为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达到打开状态，发送方不得对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.
如果已在链接上协商异步控制字符映射选项，则发送方将在运行加密算法后应用映射。
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、k2和k3应用第1.1节中所述的3DE。
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进入打开状态后对第一个数据包进行加密时，初始Nonce在使用前通过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.
因此，在使用最大Pad值（MPV）为8的自描述填充的明确技术进行加密之前，必须填充长度不是8字节倍数的所有数据包。这意味着纯文本中填充了八位字节1、2、3、。。因为它的长度是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.
对等方解密密文后，它会去掉自描述的填充八位字节以重新创建原始纯文本。如果构成填充的八位字节与刚才描述的自描述填充方案不匹配，则对等方应丢弃该帧。
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-1的最后一个Ci来解密数据包N的C1，因此不可能解密数据包N。然而，所有数据包N+1及其后的数据包都可以用通常的方式进行解密，因为所需的只是前一数据包（在本例中，数据包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.
安全问题是本备忘录的主要主题。该方案依赖外部和未指定的方法来检索共享机密。它没有提出新的隐私技术，只是描述了一种将3DES密码应用于PPP实现之间的数据传输的约定。保护和检索共享机密的任何方法以及3DES密码的任何限制都与此处描述的使用有关。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[2] Meyer，G.，“PPP加密控制协议（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] K.Sklower和G.Meyer，“PPP DES加密协议，第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] 多拉斯瓦米，N.，梅茨格，P.，辛普森，W.，“ESP三重DES变换”，正在进行的工作，1997年6月。
[6] Schneier, B., "Applied Cryptography", Second Edition, John Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.
[6] 施奈尔，B.，“应用密码学”，第二版，约翰·威利父子出版社，纽约，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 Gesellschaft fuer Netzwerktechnology 76227 Karlsruhe，Killisfeldstr。64，德国
Phone: +49 721 9495 0
EMail: kummert@nentec.de
Phone: +49 721 9495 0
EMail: kummert@nentec.de
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。