The PPP ARCFOUR Encryption Protocol
Author(s): William Simpson
The Point-to-Point Protocol (PPP) [RFC1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links....
INTERNET-DRAFT W A Simpson DayDreamer Intended status: Experimental 15 July 2013 The PPP ARCFOUR Encryption Protocol draft-simpson-ppp-arc4-00 Abstract The Point-to-Point Protocol (PPP) [RFC1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [RFC1968] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document described the use of the ARCFOUR algorithm for encrypting PPP encapsulated packets. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Simpson expires January 4, 2012 [Page i] DRAFT PPP ARCFOUR Encryption 15 July 2013 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 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." Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Terminology . . . . . . . . . . . . . . . . . . . 1 2. Packet Format . . . . . . . . . . . . . . . . . . . . . 1 2.1 Sequence Number (SN) . . . . . . . . . . . . . . . 2 2.2 Initialization Vector (IV) . . . . . . . . . . . . 3 2.3 Keys . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 Integrity Check Value . . . . . . . . . . . . . . 4 3. Compressed Header Format . . . . . . . . . . . . . . . . 4 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 4 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 4 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 5 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 5 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 6 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 6 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Simpson expires January 4, 2012 [Page ii] DRAFT PPP ARCFOUR Encryption 15 July 2013 1. Introduction The PPP Encryption Control Protocol (ECP) [RFC1968] provides confidentiality for PPP packets by encrypting the payload data to be protected. This specification describes the PPP ECP use of a variant of ARCFOUR. [KT99] [Schneier96] ARCFOUR is a long studied and widely implemented encryption algorithm. Most network device operating systems already contain an implemention. It is readily implemented in hardward and software, and well suited to high speed links. PPP links are widely used at the time of writing. Modems are commonly available over POTS copper lines at up to 56 Kbps, while OC-48 / STM-16 (2.4 Gbps payload) are used in Internet backbones. PPP has been specified up to OC-192 / STM-64 (9.5 Gbps payload) [RFC2615], and could easily be extended to OC-768 / STM-256 (38.5 Gbps payload). 1.1. Terminology The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC 2119]. byte An 8-bit quantity; also known as "octet" in standardese. 2. Packet Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | Control | 0000 | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Sequence Number + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Ciphertext ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Check Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Frame Check Sequence ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Simpson expires January 4, 2012 [Page 1] DRAFT PPP ARCFOUR Encryption 15 July 2013 All fields are transmitted in network order (most significant byte first). The Address, Control, and Frame Check Sequence (FCS) are defined by [RFC1662] and related documents. The Address and Control fields SHOULD NOT be compressed. The full-sized Protocol header is indicated by the uncompressed Protocol field (leading zero byte). Following negotiation, this full-sized packet is sent as the initial network layer packet and at least once for every 128 following packets. This full-sized packet SHOULD be opportunistically sent with packets that are less than the negotiated Maximum Receive Unit (MRU) to avoid unnecessary fragmentation. When no opportunity has arisen, the ciphertext MAY be the PPP Padding Protocol (0x0001). Therefore, ECP negotiation SHOULD also concurrently negotiate the Padding Protocol. 2.1. Sequence Number (SN) The Sequence Number (SN) is a 64-bit (8 byte) unsigned counter. This field protects against replay attacks, and may also be used for synchronization. Long term replay prevention requires automated configuration. When configured via an automated session key management protocol, the first value sent is 1, unless otherwise negotiated. Manual configuration can only detect replay of consecutive duplicate Seqeunce Numbers, and during short runs of Sequence Numbers within the round trip time for the parties. The limited anti-replay security depends upon the unpredictability of the values. When configured manually, the first value sent SHOULD be a random number. Thereafter, the value is monotonically increased for each packet sent. This field is mandatory and transparent. That is, the field is always present, and the value is not concealed by encryption. Simpson expires January 4, 2012 [Page 2] DRAFT PPP ARCFOUR Encryption 15 July 2013 2.2. Initialization Vector (IV) The Initialization Vector (IV) is 64 bits (8 bytes) in length. The IV conceals initial bytes that repeat in multiple packets. Each IV is intended to be unique over the lifetime of the cipher session- key(s). The IV is never transmitted. Ideally, the IV is based on explicit fields carried in each packet, but generated pseudo-randomly and protected from disclosure [VK83]. This IV requires a secret seed that is 64 bits (8 bytes) in length. 1) The least significant 32 bits of the SN are ones complemented and exclusive ored with the most significant 32 bits of the seed. 2) Then, the entire SN is added modulo 2**64 to the seed with end- around carry. 3) Finally, the number of 1 bits are counted, and the sum is left circular rotated by the bit count. This result is the IV used for a single packet associated with the SN. Design Rationale Inclusion of the bit-wise complement of the SN ensures that incremental bit changes are reflected twice in the IV. Rotational checksum with an undisclosed seed is intended to generate unpredictable values that are difficult to correlate with the SN. End-around carry always results in a non-zero value. Only the all-ones value will result in no rotation. 2.3. Keys This algorithm requires a fairly long key in a multiple of 8-bit bytes. This secret key is used for the Key Setup phase. [KT99] [Schneier96] In this specification, the Key Setup is repeated twice, for a total of three (3) iterations. This mixes the keying material sufficiently. Simpson expires January 4, 2012 [Page 3] DRAFT PPP ARCFOUR Encryption 15 July 2013 When configured via an automated session key management protocol, 2048-bit (256 byte) keys are required. When configured manually, 256-bit (16 byte) keys are the minimum required. 2.4. Integrity Check Value The Integrity Check Value (ICV) that is 32-bits (4 bytes) in length. The ICV is carried immediately following the ciphertext. 3. Compressed Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | Control | ECP | SN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ On most packets, the header SHOULD compress the ECP designator. This compressed header includes only the least significant 8 bits (1 byte) of the Sequence Number (SN). The Address and Control field SHOULD be compressed as negotiated by LCP. Acknowledgments This specification is based upon earlier documents by this author circa 1996 and by Rodney Thayer circa 1997. IANA Considerations This specification requires an addition to the PPP ECP Configuration Option Types. Provisionally, 4 is expected. Simpson expires January 4, 2012 [Page 4] DRAFT PPP ARCFOUR Encryption 15 July 2013 Operational Considerations All implementations MUST support 2048-bit (256 byte) keys. Security Considerations This protocol was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology. Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come. Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis. The security depends on the quality of the random numbers generated by each party. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem (see [RFC4086] for discussion). It should also be noted that no encryption algorithm is permanently safe from brute force attack, because of the increasing speed of modern computers. As with all cryptosystems, those responsible for applications with substantial risk when security is breeched should pay close attention to developments in cryptology, and especially cryptanalysis, and switch to other algorithms should ARCFOUR prove weak. Simpson expires January 4, 2012 [Page 5] DRAFT PPP ARCFOUR Encryption 15 July 2013 Normative References [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD-51, DayDreamer, July 1994. [RFC1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, DayDreamer, July 1994. [RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", July 1994. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. Informative References [KT99] Kaukonen, K. and R. Thayer, "A Stream Cipher Encryption Algorithm 'Arcfour'", https://tools.ietf.org/html/draft- kaukonen-cipher-arcfour-03 July 1999. [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", June 1999. [RFC4086] Eastlake, D. (3rd), Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, June 2005. [Schneier96] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1996. ISBN 0-471-12845-7. Simpson expires January 4, 2012 [Page 6] DRAFT PPP ARCFOUR Encryption 15 July 2013 Author's Address Questions about this document can be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 William.Allen.Simpson@Gmail.com Simpson expires January 4, 2012 [Page 7]