The PPP Triple-DES Encryption Protocol (3DESE)
The information below is for an old version of the document that is already published as an RFC.
|Document||Type||This is an older version of an Internet-Draft that was ultimately published as an RFC.|
|Last updated||2013-03-02 (Latest revision 1998-04-10)|
|Stream||Internet Engineering Task Force (IETF)|
|IESG||IESG state||RFC 2420 (Proposed Standard)|
|Send notices to||(None)|
Network Working Group H. Kummert Internet-draft Nentec GmbH Expires: January 1998 July 1997 The PPP Triple-DES Encryption Protocol (3DESE) draft-ietf-pppext-3des-encrypt-00.txt Status of this Memo This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the email@example.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Point-to-Point Protocol (PPP)  provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP)  provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the Triple-DES standard (3DES)  for encrypting PPP encapsulated packets. Kummert [Page 1] INTERNET DRAFT PPP Triple-DES Encryption July 1997 Table of contents 1. Introduction .............................................. 2 1.1 Algorithm ................................................. 3 1.2 Keys ...................................................... 3 2. 3DESE Configuration Option for ECP ........................ 4 3. Packet format for 3DESE ................................... 4 4. Encryption ................................................ 5 4.1 Padding ................................................... 6 4.2 Recovery after packet loss ................................ 6 5. Security considerations ................................... 7 6. References ................................................ 7 7. Acknowledgements .......................................... 7 8. Author's address .......................................... 8 9. Expiration date of this draft ............................. 8 1. Introduction The purpose of encrypting packets exchanged between two PPP implemen- tations is to attempt to insure the privacy of communication con- ducted 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 imple- mented 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 . 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 . 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. The padding section reflects the result of the discussion on this topic on the ppp mailing list. In this document, the key words "MUST", "SHOULD", and "recommended" are to be interpreted as described in . Kummert [Page 2] INTERNET DRAFT PPP Triple-DES Encryption July 1997 1.1 Algorithm The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algo- rithm. In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 octet) plaintext block (P1). The keyed DES func- tion is iterated three times, an encryption (E) followed by a decryp- tion (D) followed by an encryption (E), and generates the ciphertext (C1) for the block. Each iteration uses an independent key: k1, k2 and k3. For successive blocks, the previous ciphertext block is XOR'd with the current 8-octet plaintext block (Pi). The keyed DES-EDE3 encryp- tion function generates the ciphertext (Ci) for that block. 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. When all three keys (k1, k2 and k3) are the same, DES-EDE3-CBC is equivalent to DES-CBC. 1.2 Keys The secret DES-EDE3 key shared between the communicating parties is effectively 168-bits long. This key consists of three independent Kummert [Page 3] INTERNET DRAFT PPP Triple-DES Encryption July 1997 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. When configuring keys for 3DESE those with incorrect parity or so- called weak keys  SHOULD be rejected. 2. 3DESE Configuration Option for ECP 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: Figure 1: ECP 3DESE Configuration Option 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 tbd, to indicate the 3DESE protocol. 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. 3. Packet format for 3DESE Description Kummert [Page 4] INTERNET DRAFT PPP Triple-DES Encryption July 1997 The 3DESE packets that contain the encrypted payload have the following fields: Figure 2: 3DESE Encryption Protocol Packet Format 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 nego- tiated. Protocol ID The value of this field is 0x53 or 0x55; the latter indi- cates the use of the Individual Link Encryption Control Protocol and that the ciphertext contains a Multilink frag- ment. Protocol Field Compression MAY be applied to the leading zero if negotiated. Sequence Number These 16-bit numbers are assigned by the encryptor sequen- tially starting with 0 (for the first packet transmitted once ECP has reached the opened state). Ciphertext The generation of this data is described in the next sec- tion. 4. Encryption Once the ECP has reached the Opened state, the sender MUST NOT apply the encryption procedure to LCP packets nor ECP packets. If the async control character map option has been negotiated on the link, the sender applies mapping after the encryption algorithm has been run. Kummert [Page 5] INTERNET DRAFT PPP Triple-DES Encryption July 1997 The encryption algorithm is generally to pad the Protocol and Infor- mation 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. 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. 4.1 Padding 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. 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. 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. When using Multilink and encrypting on individual links it is recom- mended that all non-terminating fragments have a length divisible by 8. So no additional padding is needed on those fragments. 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. Kummert [Page 6] INTERNET DRAFT PPP Triple-DES Encryption July 1997 4.2 Recovery after packet loss 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. 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). 5. Security considerations Security issues are the primary subject of this draft. 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. 6. References  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.  Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider Sys- tems, June 1996.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, Harvard University, March 1997.  Meyer, G., Sklower, K. "The PPP DES Encryption Protocol (DESE)", RFC 1969, Spider Systems, June 1996.  Doraswamy, N., Metzger, P., Simpson, W., "The ESP Triple DES Transform", Work in progress, June 1997  Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. Kummert [Page 7] INTERNET DRAFT PPP Triple-DES Encryption July 1997 7. Acknowledgements Much portions of this document was taken from  and . Bill Simp- son gave useful hints on the initial revision. 8. Author's Address: Holger Kummert Nentec Gesellschaft fuer Netzwerktechnologie 76227 Karlsruhe, Killisfeldstr. 64, Germany Phone: +49 721 9495 0 E-mail: firstname.lastname@example.org 9. Expiration date of this draft January 23, 1998 Kummert [Page 8]