doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1969.txt b/doc/rfc/rfc1969.txt
new file mode 100644
index 0000000..0e3e01b
--- /dev/null
+++ b/doc/rfc/rfc1969.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         K. Sklower
+Request for Comments: 1969            University of California, Berkeley
+Category: Informational                                         G. Meyer
+                                                          Spider Systems
+                                                               June 1996
+
+
+                 The PPP DES Encryption Protocol (DESE)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+
+   The PPP Encryption Control Protocol (ECP) [2] provides a method to
+   negotiate and utilize encryption protocols over PPP encapsulated
+   links.
+
+   This document provides specific details for the use of the DES
+   standard [5, 6] for encrypting PPP encapsulated packets.
+
+Acknowledgements
+
+   The authors extend hearty thanks to Fred Baker of Cisco for helpful
+   improvements to the clarity of the document.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   1.1. Motivation ................................................    2
+   1.2. Conventions ...............................................    2
+   2. General Overview ............................................    2
+   3. Structure of This Specification .............................    3
+   4. DESE Configuration Option for ECP ...........................    4
+   5. Packet Format for DESE ......................................    5
+   6. Encryption ..................................................    6
+   6.1. Padding Considerations ....................................    6
+   6.2. Generation of the Ciphertext ..............................    7
+   6.3. Retrieval of the Plaintext ................................    8
+   6.4. Recovery after Packet Loss ................................    8
+   7. MRU Considerations ..........................................    8
+   8. Security Considerations .....................................    9
+
+
+
+Sklower & Meyer              Informational                      [Page 1]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+   9. References ..................................................    9
+   10. Authors' Addresses .........................................   10
+   11. Expiration Date of this Draft ..............................   10
+
+1.  Introduction
+
+1.1.  Motivation
+
+   The purpose of this memo is two-fold: to show how one specifies the
+   necessary details of a "data" or "bearer" protocol given the context
+   of the generic PPP Encryption Control Protocol, and also to provide
+   at least one commonly-understood means of secure data transmission
+   between PPP implementations.
+
+   The DES encryption algorithm is a well studied, understood and widely
+   implemented encryption algorithm.  The DES cipher was designed for
+   efficient implementation in hardware, and consequently may be
+   relatively expensive to implement in software.  However, its
+   pervasiveness makes it seem like a reasonable choice for a "model"
+   encryption protocol.
+
+   Source code implementing DES in the "Electronic Code Book Mode" can
+   be found in [7].  US export laws forbid the inclusion of
+   compilation-ready source code in this document.
+
+1.2.  Conventions
+
+   The following language conventions are used in the items of
+   specification in this document:
+
+   o    MUST, SHALL or MANDATORY -- the item is an absolute requirement
+        of the specification.
+
+   o    SHOULD or RECOMMENDED -- the item should generally be followed
+        for all but exceptional circumstances.
+
+   o    MAY or OPTIONAL -- the item is truly optional and may be
+        followed or ignored according to the needs of the implementor.
+
+2.  General Overview
+
+   The purpose of encrypting packets exchanged between two PPP
+   implementations is to attempt to insure the privacy of communication
+   conducted via the two implementations.  The encryption process
+   depends on the specification of an encryption algorithm and a shared
+   secret (usually involving at least a key) between the sender and
+   receiver.
+
+
+
+
+Sklower & Meyer              Informational                      [Page 2]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+   Generally, the encryptor will take a PPP packet including the
+   protocol field, apply the chosen encryption algorithm, place the
+   resulting cipher text (and in this specification, an explicit
+   sequence number) in the information field of another PPP packet.  The
+   decryptor will apply the inverse algorithm and interpret the
+   resulting plain text as if it were a PPP packet which had arrived
+   directly on the interface.
+
+   The means by which the secret becomes known to both communicating
+   elements is beyond the scope of this document; usually some form of
+   manual configuration is involved.  Implementations might make use of
+   PPP authentication, or the EndPoint Identifier Option described in
+   PPP Multilink [3], as factors in selecting the shared secret.  If the
+   secret can be deduced by analysis of the communication between the
+   two parties, then no privacy is guaranteed.
+
+   While the US Data Encryption Standard (DES) algorithm [5, 6] provides
+   multiple modes of use, this specification selects the use of only one
+   mode in conjunction with the PPP Encryption Control Protol (ECP): the
+   Cipher Block Chaining (CBC) mode.  In addition to the US Government
+   publications cited above, the 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 deduced from an explicit
+   64-bit nonce, which is exchanged in the clear during the negotiation
+   phase.  The 56-bit key required by all DES modes is established as a
+   shared secret between the implementations.
+
+   One reason for choosing the chaining mode is that it is generally
+   thought to require more computation resources to deduce a 64 bit key
+   used for DES encryption by analysis of the encrypted communication
+   stream when chaining mode is used, compared with the situation where
+   each block is encrypted separately with no chaining.  Further, if
+   chaining is not used, even if the key is never deduced, the
+   communication may be subject to replay attacks.
+
+   However, if chaining is to extend beyond packet boundaries, both the
+   sender and receiver must agree on the order the packets were
+   encrypted.  Thus, this specification provides for an explicit 16 bit
+   sequence number to sequence decryption of the packets.  This mode of
+   operation even allows recovery from occasional packet loss; details
+   are also given below.
+
+3.  Structure of This Specification
+
+   The PPP Encryption Control Protocol (ECP), provides a framework for
+   negotiating parameters associated with encryption, such as choosing
+   the algorithm.  It specifies the assigned numbers to be used as PPP
+
+
+
+Sklower & Meyer              Informational                      [Page 3]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+   protocol numbers for the "data packets" to be carried as the
+   associated "data protocol", and describes the state machine.
+
+   Thus, a specification for use in that matrix need only describe any
+   additional configuration options required to specify a particular
+   algorithm, and the process by which one encrypts/decrypts the
+   information once the Opened state has been achieved.
+
+4.  DESE Configuration Option for ECP
+
+   Description
+
+        The ECP DESE 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 DESE Configuration Option has the following fields,
+        which are 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      |    Length     |         Initial Nonce ...
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Type
+
+             1, to indicate the DESE 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.  An
+
+
+
+Sklower & Meyer              Informational                      [Page 4]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+             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
+             indicates that ciphertext includes headers for the
+             Multilink Protocol, and 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.
+
+
+
+
+Sklower & Meyer              Informational                      [Page 5]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+        Ciphertext
+
+             The generation of this data is described in the next
+             section.
+
+6.  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.
+
+   The encryption algorithm is generally to pad the Protocol and
+   Information fields of a PPP packet to some multiple of 8 bytes, and
+   apply DES in Chaining Block Cipher mode with a 56-bit key K.
+
+   There are a lot of details concerning what constitutes the Protocol
+   and Information fields, in the presence or non-presence of Multilink,
+   and whether the ACFC and PFC options have been negotiated, and the
+   sort of padding chosen.
+
+   Regardless of whether ACFC has been negotiated on the link, the
+   sender applies the encryption procedure to only that portion of the
+   packet excluding the address and control field.
+
+   If the Multilink Protocol has been negotiated and encryption is to be
+   construed as being applied to each link separately, then the
+   encryption procedure is to be applied to the (possibly extended)
+   protocol and information fields of the packet in the Multilink
+   Protocol.
+
+   If the Multilink Protocol has been negotiated and encryption is to be
+   construed as being applied to the bundle, then the multilink
+   procedure is to be applied to the resulting DESE packets.
+
+6.1.  Padding Considerations
+
+   Since the DES algorithm operates on blocks of 8 octets, packets which
+   are of length not a multiple of 8 octets must be padded.  This can be
+   injurious to the interpretation of some protocols which do not
+   contain an explicit length field in their protocol headers.
+   (Additional padding of the ciphered packet for the purposes of
+   transmission by HDLC hardware which requires an even number of bytes
+   should not be necessary since the information field will now be of
+   length a multiple of 8, and whether or not the packet is of even
+   length can be forced by use or absence of a leading zero in the
+
+
+
+Sklower & Meyer              Informational                      [Page 6]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+   protocol field).
+
+   For protocols which do have an explicit length field, such as IP,
+   IPX, XNS, and CLNP, then padding may be accomplished by adding random
+   trailing garbage.  Even when performing the Multilink protocol, if it
+   is only being applied to packets with explicit length fields, and if
+   care is taken so that all non-terminating fragments (i.e., those not
+   bearing the (E)nd bit) are of lengths divisible by 8; then no ill
+   effects will happen if garbage padding is applied only to terminating
+   fragments.
+
+   For certain cases, such as the PPP bridging protocol when the
+   trailing CRC is forwarded or when any bridging is being applied to
+   protocols not having explicit length fields, adding garbage changes
+   the interpretation of the packet.  The self-describing padding option
+   [4] permits unambiguous removal of padded bytes; although it should
+   only be used when absolutely necessary as it may inadvertently
+   require adding as many as 8 octets to packets that could otherwise be
+   left unaltered.
+
+      Consider a packet, which by unlucky circumstance is already a
+      multiple of 8 octets, but terminates in the sequence 0x1, 0x2.
+      Self-describing padding would otherwise remove the trailing two
+      bytes.  For purposes of coexistence with archaic HDLC chips where
+      it is necessary to transmit packets of even length, one would
+      normally only have to add an additional two octets (0x1, 0x2),
+      which could then be removed.  However, since the packet was
+      initially a multiple of 8 bytes, an additional 8 bytes would need
+      to be added.
+
+6.2.  Generation of the Ciphertext
+
+   In this discussion, E[k] will denote the basic DES cipher determined
+   by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the
+   corresponding decryption mechanism.  The padded plaintext described
+   in the previous section then becomes a sequence of 64 bit blocks P[i]
+   (where i ranges from 1 to n).  The circumflex character (^)
+   represents the bit-wise exclusive-or operation applied to 64-bit
+   blocks.
+
+   When encrypting the first packet to be transmitted in the opened
+   state let C[0] be the result of applying E[k] to the Initial Nonce
+   received in the peer's ECP DESE option; otherwise let C[0] be the
+   final block of the previously transmitted packet.
+
+
+
+
+
+
+
+Sklower & Meyer              Informational                      [Page 7]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+   The ciphertext for the packet is generated by the iterative process
+
+                        C[i] = E[k](P[i] ^ C[i-1])
+
+   for i running between 1 and n.
+
+6.3.  Retrieval of the Plaintext
+
+   When decrypting the first packet received in the opened state, let
+   C[0] be the result of applying E[k] to the Initial Nonce transmitted
+   in the ECP DESE option.  The first packet will have sequence number
+   zero.  For subsequent packets, let C[0] be the final block of the
+   previous packet in sequence space.  Decryption is then accomplished
+   by
+
+                        P[i] = C[i-1] ^ D[k](C[i]),
+
+   for i running between 1 and n.
+
+6.4.  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 algorithm in the previous section requires C[0] for packet
+   N to be C[last] for packet N - 1, it will be impossible to decode
+   packet N.  However, all packets N + 1 and following can be decoded 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).
+
+7.  MRU Considerations
+
+   Because padding can occur, and because there is an additional
+   protocol field in effect, implementations should take into account
+   the growth of the packets.  As an example, if PFC had been
+   negotiated, and if the MRU before had been exactly a multiple of 8,
+   then the plaintext resulting combining a full sized data packets with
+   a one byte protocol field would require an additional 7 bytes of
+   padding, and the sequence number would be an additional 2 bytes so
+   that the information field in the DESE protocol is now 10 bytes
+   larger than that in the original packet.  Because the convention is
+   that PPP options are independent of each other, negotiation of DESE
+   does not, by itself, automatically increase the MRU value.
+
+
+
+
+
+Sklower & Meyer              Informational                      [Page 8]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+8.  Security Considerations
+
+   Security issues are the primary subject of this memo.  This proposal
+   relies on exterior and unspecified methods for authentication and
+   retrieval of shared secrets.
+
+   It proposes no new technology for privacy, but merely describes a
+   convention for the application of the DES cipher to data transmission
+   between PPP implementation.
+
+   Any methodology for the protection and retrieval of shared secrets,
+   and any limitations of the DES cipher are relevant to the use
+   described here.
+
+9.  References
+
+   [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
+       RFC 1661, Daydreamer, July 1994.
+
+   [2] Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider
+       Systems, June 1996.
+
+   [3] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The PPP
+       Multilink Protocol (MP)", RFC 1717, UC Berkeley, November 1994.
+
+   [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,
+       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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower & Meyer              Informational                      [Page 9]
+
+RFC 1969                  PPP DES Encryption                   June 1996
+
+
+10.  Authors' Addresses
+
+   Keith Sklower
+   Computer Science Department
+   384 Soda Hall, Mail Stop 1776
+   University of California
+   Berkeley, CA 94720-1776
+
+   Phone:  (510) 642-9587
+   EMail:  sklower@CS.Berkeley.EDU
+
+
+   Gerry M. Meyer
+   Spider Systems
+   Stanwell Street
+   Edinburgh EH6 5NG
+   Scotland, UK
+
+   Phone: (UK) 131 554 9424
+   Fax:   (UK) 131 554 0649
+   EMail: gerry@spider.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower & Meyer              Informational                     [Page 10]
+