RFC 2419

The PPP DES Encryption Protocol, Version 2 (DESE-bis)

📅 published September 1998, from ietf

RFC 2419 💅 The PPP DES Encryption Protocol, Version 2 (DESE-bis) 🎀

  • Series: Network Working Group 🌸
  • Authors: K. Sklower (University of California, Berkeley) and G. Meyer (Shiva) 👯
  • Category: Standards Track 🦋
  • Date: September 1998 📅
  • Obsoletes: RFC 1969 (this one replaces it, bestie) ✨

Status of This Memo ✨

okay so this document specifies an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions 🗣️ If you want to know where this protocol sits in standardization and its current status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📋 Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (1998). All Rights Reserved. 🫶

Abstract 📝

okay bestie, the Point-to-Point Protocol (PPP) [1] is the standard way to move multi-protocol datagrams over point-to-point links 🚀

The PPP Encryption Control Protocol (ECP) [2] is the part that lets two ends negotiate and use encryption protocols over PPP-encapsulated links 🔐

This document gets into the specifics of using the DES standard [5, 6] to encrypt PPP-encapsulated packets 💖

Acknowledgements 🙏

The authors gave a huge shoutout to Fred Baker of Cisco, Philip Rakity of Flowpoint, and William Simpson of Daydreamer for helping make the document clearer and more correct 💜

Table of Contents 🗂️

   1. Introduction ................................................  2
   1.1. Motivation ................................................  2
   1.2. Conventions ...............................................  2
   2. General Overview ............................................  2
   3. Structure of This Specification .............................  4
   4. DESE Configuration Option for ECP ...........................  4
   5. Packet Format for DESE ......................................  5
   6. Encryption ..................................................  6
   6.1. Padding Considerations ....................................  7
   6.2. Generation of the Ciphertext ..............................  8
   6.3. Retrieval of the Plaintext ................................  8
   6.4. Recovery after Packet Loss ................................  8
   7. MRU Considerations ..........................................  9
   8. Differences from RFC 1969 ...................................  9
   8.1. When to Pad ...............................................  9
   8.2. Assigned Numbers ..........................................  9
   8.3. Minor Editorial Changes ...................................  9
   9. Security Considerations .....................................  9
   10. References ................................................. 10
   11. Authors' Addresses ......................................... 11
   12. Full Copyright Statement ................................... 12

1. Introduction ✨

1.1. Motivation 🎯

the purpose of this memo is twofold, lol 🙈 First, it shows how to spell out the necessary details of a "data" or "bearer" protocol inside the context of the generic PPP Encryption Control Protocol. Second, it gives at least one commonly understood way to do secure data transmission between PPP implementations 🔒

The DES encryption algorithm is well studied, well understood, and widely implemented 💅 The DES cipher was designed to be efficient in hardware, so it can be relatively expensive to implement in software. Still, it's so everywhere that it makes sense as a "model" encryption protocol 🌸

Source code implementing DES in the "Electronic Code Book Mode" can be found in [7]. Heads up though: US export laws forbid including compilation-ready source code in this document 🙃

1.2. Conventions 📏

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8] 👑

2. General Overview 🌈

the whole point of encrypting packets between two PPP implementations is to try to keep their conversation private 🤫 The process depends on an encryption algorithm and a shared secret (usually at least a key) that both sender and receiver have.

Basically, the encryptor takes a PPP packet, including its protocol field, runs the chosen algorithm on it, and puts the resulting cipher text in the information field of another PPP packet. In this specification, it also adds an explicit sequence number 🧁 The decryptor applies the inverse algorithm and treats the resulting plain text as if it had arrived directly on the interface 💫

How the secret gets to both sides is out of scope for this document. Usually that's some kind of manual configuration 🗝️ Implementations might use PPP authentication, or the EndPoint Identifier Option described in PPP Multilink [3], to help pick the shared secret. And if someone can work out the secret by analyzing the communication between the two parties, then no privacy is guaranteed. Yikes 💀

The US Data Encryption Standard (DES) algorithm [5, 6] supports multiple modes, but this specification picks just one to use with the PPP Encryption Control Protocol (ECP): Cipher Block Chaining (CBC) mode 🎀 Besides the US Government publications cited above, CBC mode is also discussed in [7], although no C source code is provided for it per se.

The initialization vector for this mode is worked out from an explicit 64-bit nonce, which gets exchanged in the clear during the negotiation phase 🌷 The 56-bit key that all DES modes need is set up as a shared secret between the implementations.

Why chaining? It's generally thought to take more computing power to figure out a 64-bit DES key by analyzing the encrypted stream when chaining is used, compared to when each block is encrypted separately with no chaining 🧠 Also, identical plaintext sequences produce different ciphers when chaining is in effect, which makes analysis way harder 🙌

Here's the catch, though 👀 If chaining extends beyond packet boundaries, both the sender and receiver have to agree on the order the packets were encrypted in. So this specification adds an explicit 16-bit sequence number to keep the decryption of packets in order 🔢 This mode of operation can even recover from occasional packet loss. More details on that are given below ✨

3. Structure of This Specification 🧩

The PPP Encryption Control Protocol (ECP) gives you a framework for negotiating encryption parameters, like choosing the algorithm 🛠️ It specifies the assigned numbers to be used as PPP protocol numbers for the "data packets" carried as the associated "data protocol", and it describes the state machine 🤖

So a spec that plugs into that matrix only needs to describe any extra configuration options required for a particular algorithm, plus how to encrypt and decrypt the information once the Opened state has been reached 💖

4. DESE Configuration Option for ECP 🎀

Description 💬

The ECP DESE Configuration Option says the issuing implementation is offering to use this specification to decrypt communications on the link. You can think of it as a request for its peer to encrypt packets this way too 🔁

The ECP DESE Configuration Option has the following fields, transmitted from left to right:

Figure 1: ECP DESE 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 = 3    |    Length     |         Initial Nonce ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🏷️

Type = 3 means DESE-bis 🦋 The former value 1, which pointed at the previous DESE spec, is deprecated. In other words, systems implementing this specification MUST NOT offer the former value 1 in a configure-request, and MUST configure-reject the former value on receipt of a configure-request containing it 🚫

Length 📏

10

Initial Nonce 🎲

This field is an 8 byte quantity. The peer implementation uses it 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 🛡️ An example might be to use the number of seconds since Jan 1st, 1970 (GMT/UT) in the upper 32 bits, and the current number of nanoseconds relative to the last second mark in the lower 32 bits ⏱️

Its formulaic role is described in the Encryption section below ✨

5. Packet Format for DESE 📦

Description 💌

The DESE packets themselves have the following fields:

Figure 2: DES 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 negotiated 🤝

Protocol ID 🆔

The value of this field is 0x53 or 0x55. The latter means the ciphertext includes headers for the Multilink Protocol, and it requires that the Individual Link Encryption Control Protocol has reached the opened state 🔗 The leading zero MAY be absent if the PPP Protocol Field Compression option (PFC) has been negotiated ✂️

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 🎯

Ciphertext 🔒

The generation of this data is described in the next section 🫶

6. Encryption ✨

okay bestie, once ECP hits the Opened state 🔓, the sender MUST NOT encrypt LCP packets or ECP packets. they stay plain 🫶

if the async control character map option was negotiated on the link 🗺️, the sender does the mapping after the encryption algorithm has run. order matters, periodt 💅

the vibe of the algorithm: pad the Protocol and Information fields of a PPP packet out to a multiple of 8 bytes, then run DES in Chaining Block Cipher mode with a 56-bit key K 🔐

ngl there are a LOT of details about what counts as the Protocol and Information fields 🥹. it depends on whether Multilink is in play, whether ACFC and PFC were negotiated, and which kind of padding got picked. so many variables, no cap 😭

no matter whether ACFC was negotiated, the sender only encrypts the part of the packet that isn't the address and control field 🎀

if Multilink is negotiated and you're treating encryption as happening on each link separately 🔗, then encryption goes over the (possibly extended) protocol and information fields inside the Multilink Protocol packet 🧚

if Multilink is negotiated and you're treating encryption as happening on the bundle 📦, then the multilink procedure gets applied to the resulting DESE packets. the bundle version is giving main character energy ✨

6.1. Padding Considerations

okay so DES works on blocks of 8 octets 🧩. that means plain text packets whose length isn't a multiple of 8 octets have to get padded. and that padding can mess with protocols that don't carry an explicit length field in their headers 😬. not iconic behavior at all

there's no standard list of which protocols are vulnerable to padding-induced corruption 📜, so people could get confused about which ones should be protected from it. so this spec says the unambiguous technique below MUST be applied to ALL plain text packets 🙌. no picking and choosing, bestie

the padding method is based on the LCP Self-Describing-Padding (SDP) option (defined in RFC 1570 [4]) 🍓. it's different in two ways 👀: first, the maximum pad value is fixed at 8, and second, the method applies to ALL packets, not just "specifically identified protocols" 💅

plain text that isn't a multiple of 8 octets long MUST be padded before encryption, using enough octets from the sequence 1, 2, 3 ... 7 to make it a multiple of 8 octets 🧁

plain text that's already a multiple of 8 octets may still need an extra 8 octets (1, 2, 3 ... 8) 😳. those extra octets MUST be appended before encryption if the last octet of the plain text has a value of 1 through 8, inclusive. yes it's a little bit of a plot twist 🌀

after the peer decrypts the cipher text, it strips off the Self-Describing-Padding octets to get the original plain text back 🪄

after decrypting, you only need to look at the last octet to figure out how many pad bytes to remove. but the peer SHOULD discard the frame if all the octets forming the padding don't match the scheme we just described. that's a red flag, bestie 🚩

the padding operation above happens independently of whether the LCP Self-Describing-Padding (SDP) option was negotiated 🙅‍♀️. if SDP was negotiated, it gets applied to the whole packet after it's been ciphered and after the Encryption Protocol Identifiers have been prepended 🧇

6.2. Generation of the Ciphertext

alright, the math moment 🤓🫧. E[k] is the basic DES cipher using a 56-bit key k on 64-bit blocks, and D[k] is the matching decryption 🔁. the padded plaintext from the last section becomes a sequence of 64-bit blocks P[i] (where i goes from 1 to n) 🧱. the circumflex character (^) means bit-wise exclusive-or on 64-bit blocks ✖️

when you encrypt the first packet sent in the opened state, C[0] is E[k] applied to the Initial Nonce from the peer's ECP DESE option 🌱. otherwise, C[0] is the final block of the previously sent packet 🔗

the ciphertext for the packet comes out of this iterative process, for i running from 1 to n:

C[i] = E[k](P[i] ^ C[i-1])

6.3. Retrieval of the Plaintext

decrypting the first packet received in the opened state 📬: C[0] is E[k] applied to the Initial Nonce sent in the ECP DESE option 🌸. that first packet has sequence number zero. for every packet after that, C[0] is the final block of the previous packet in sequence space 🧵

then decryption is just this, for i running from 1 to n:

P[i] = C[i-1] ^ D[k](C[i]),

6.4. Recovery after Packet Loss

packet loss gets detected when the sequence numbers of consecutive packets don't line up 🕵️‍♀️. say packet number N - 1 has an unrecoverable error or gets lost, but packets N and N + 1 arrive fine 📦📦

here's the tea ☕: packet N needs C[0] to be C[last] from packet N - 1. since that's missing, packet N can't be decoded 😭. BUT packet N + 1 and everything after it can still be decoded the usual way, because all you need is the last block of ciphertext from the previous packet (here, packet N, which WAS received) 🥰. the chain heals itself, iconic

7. MRU Considerations

padding can happen, and there's an extra protocol field in play, so implementations should take the growth of packets into account 📈. example time 🎀: say PFC was negotiated and the MRU used to be exactly a multiple of 8. a full-sized data packet plus a one-byte protocol field would need an extra 7 bytes of padding 😵. and the sequence number adds 2 more bytes. so the information field in the DESE protocol ends up 10 bytes bigger than the original packet's 📏

PPP options are independent of each other by convention, so negotiating DESE doesn't automatically bump up the MRU value by itself 🙅‍♀️. you gotta handle that separately, bestie 💖

8. Differences from RFC 1969

8.1. When to Pad

in RFC 1969, Self-Describing Padding wasn't applied to all packets sent using DESE 🙈. following the SDP option's own method, only "specifically identified protocols" got padded, and protocols with an explicit length identifier were exempt. (examples were non-VJ-compressed IP, XNS, and CLNP) 🧚

in this specification, the method applies to ALL packets 🌈

also, this spec is clarified as completely independent of the Self-Describing-Padding option for PPP, and the maximum number of padding octets is fixed at 8 🔒

8.2. Assigned Numbers

since this specification could theoretically make a packet sent under the previous specification get misread 😬, a new type field number has been assigned for the DESE-bis protocol 🏷️

8.3. Minor Editorial Changes

this spec has been designated a standards track document 🛤️. some other language was also tweaked for clarity ✨

9. Security Considerations

okay this section is SERIOUS, bestie 🚨🔐 read it carefully

this proposal is only concerned with providing confidentiality 🤐. it doesn't describe any mechanisms for integrity, authentication, or nonrepudiation 🙅‍♀️. it doesn't guarantee that a message received hasn't been modified in transit through replay, cut-and-paste, or active tampering 😱. it doesn't authenticate the source of any packet received, and it doesn't stop the sender of a packet from denying they wrote it 💀

this proposal relies on exterior and unspecified methods for authenticating and retrieving shared secrets 🗝️. it doesn't propose any new privacy technology. it just describes a convention for applying the DES cipher to data transmission between PPP implementations 📡

any methodology for protecting and retrieving shared secrets, and any limitations of the DES cipher, are relevant to the use described here ⚠️. so keep those in mind, lovely 🫶

reminder: confidentiality is the ONLY thing this gives you. no integrity, no authentication, no nonrepudiation. don't mix that up 🙈

10. References

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 📚

[2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996. 🔐

[3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 🔗

[4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994. 🍓

[5] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977). 🧮

[6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980). 🧵

[7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and source code in C", John Wiley & Sons, Inc. 1994. There is an errata associated with the book, and people can get a copy by sending e-mail to schneier@counterpane.com. 📖

[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🫧

11. Authors' Addresses

Keith Sklower
Computer Science Department
339 Soda Hall, Mail Stop 1776
University of California
Berkeley, CA 94720-1776

Phone:  (510) 642-9587
EMail:  sklower@CS.Berkeley.EDU


Gerry M. Meyer
Cisco Systems Ltd.
Bothwell House, Pochard Way,
Strathclyde Business Park,
Bellshill, ML4 3HB
Scotland, UK

Phone: (UK) (pending)
Fax:   (UK) (pending)
Email: gemeyer@cisco.com

Copyright (C) The Internet Society (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. 🌍

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. 🫶

📦 where this page comes from