[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]