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 [RFC2119].
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.
[RFC2119] 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]