doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc2419.txt b/doc/rfc/rfc2419.txt
new file mode 100644
index 0000000..cb77cd5
--- /dev/null
+++ b/doc/rfc/rfc2419.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                         K. Sklower
+Request for Comments: 2419            University of California, Berkeley
+Obsoletes: 1969                                                 G. Meyer
+Category: Standards Track                                          Shiva
+                                                          September 1998
+
+
+         The PPP DES Encryption Protocol, Version 2 (DESE-bis)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+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, Philip
+   Rakity of Flowpoint, and William Simpson of Daydreamer for helpful
+   improvements to the clarity and correctness 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 .............................  4
+   4. DESE Configuration Option for ECP ...........................  4
+   5. Packet Format for DESE ......................................  5
+
+
+
+Sklower & Meyer             Standards Track                     [Page 1]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+   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 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 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 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
+
+
+
+Sklower & Meyer             Standards Track                     [Page 2]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+   secret (usually involving at least a key) between the sender and
+   receiver.
+
+   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 Protocol (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.  Certainly,
+   identical sequences of plaintext will produce different ciphers when
+   chaining mode is in effect, thus complicating analysis.
+
+   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.
+
+
+
+
+
+
+Sklower & Meyer             Standards Track                     [Page 3]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+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
+   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 = 3    |    Length     |         Initial Nonce ...
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Type
+
+             Type = 3, to indicate the DESE-bis protocol.  The former
+             value 1 indicating the previous DESE specification is
+             deprecated, i.e.  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
+
+
+
+
+
+
+Sklower & Meyer             Standards Track                     [Page 4]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+        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
+             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.
+
+
+
+
+
+Sklower & Meyer             Standards Track                     [Page 5]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+        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
+
+   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.
+
+
+
+
+
+
+
+
+
+Sklower & Meyer             Standards Track                     [Page 6]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+6.1.  Padding Considerations
+
+   Since the DES algorithm operates on blocks of 8 octets, plain text
+   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.
+
+   Since there is no standard directory of protocols which are
+   susceptible to corruption through padding, this can lead to confusion
+   over which protocols should be protected against padding-induced
+   corruption.  Consequently, this specification requires that the
+   unambiguous technique described below MUST be applied to ALL plain
+   text packets.
+
+   The method of padding is based on that described for the LCP Self-
+   Describing-Padding (SDP) option (as defined in RFC 1570 [4]), but
+   differs in two respects: first, maximum-pad value is fixed to be 8,
+   and second, the method is to be applied to ALL packets, not just
+   "specifically identified protocols".
+
+   Plain text which is not a multiple of 8 octets long MUST be padded
+   prior to encrypting the plain text with sufficient octets in the
+   sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of
+   8 octets.
+
+   Plain text which is already a multiple of 8 octets may require
+   padding with a further 8 octets (1, 2, 3 ... 8).  These additional
+   octets MUST be appended prior to encrypting the plain text if the
+   last octet of the plain text has a value of 1 through 8, inclusive.
+
+   After the peer has decrypted the cipher text, it strips off the
+   Self-Describing-Padding octets, to recreate the original plain text.
+
+   Note that after decrypting, only the content of the last octet need
+   be examined to determine how many pad bytes should be removed.
+   However, the peer SHOULD discard the frame if all the octets forming
+   the padding do not match the scheme just described.
+
+   The padding operation described above is performed independently of
+   whether or not the LCP Self-Describing-Padding (SDP) option has been
+   negotiated.  If it has, SDP would be applied to the packet as a whole
+   after it had been ciphered and after the Encryption Protocol
+   Identifiers had been prepended.
+
+
+
+
+
+
+
+Sklower & Meyer             Standards Track                     [Page 7]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+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.
+
+   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).
+
+
+
+
+Sklower & Meyer             Standards Track                     [Page 8]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+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.
+
+8.  Differences from RFC 1969
+
+8.1.  When to Pad
+
+   In RFC 1969, the method of Self-Describing Padding was not applied to
+   all packets transmitted using DESE.  Following the method of the SDP
+   option itself, only "specifically identified protocols", were to be
+   padded.  Protocols with an explicit length identifier were exempt.
+   (Examples included non-VJ-compressed IP, XNS, CLNP).
+
+   In this speficiation, the method is applied to ALL packets.
+
+   Secondly, this specification is clarified as being completely
+   independent of the Self-Describing-Padding option for PPP, and fixes
+   the maximum number of padding octets as 8.
+
+8.2.  Assigned Numbers
+
+   Since this specification could theoretically cause misinterpretation
+   of a packet transmitted according to the previous specification, a
+   new type field number has been assigned for the DESE-bis protocol
+
+8.3.  Minor Editorial Changes
+
+   This specification has been designated a standards track document.
+   Some other language has been changed for greater clarity.
+
+9.  Security Considerations
+
+   This proposal is concerned with providing confidentiality solely.  It
+   does not describe any mechanisms for integrity, authentication or
+   nonrepudiation.  It does not guarantee that any message received has
+   not been modified in transit through replay, cut-and-paste or active
+
+
+
+
+Sklower & Meyer             Standards Track                     [Page 9]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+   tampering.  It does not provide authentication of the source of any
+   packet received, or protect against the sender of any packet denying
+   its authorship.
+
+   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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+Sklower & Meyer             Standards Track                    [Page 10]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower & Meyer             Standards Track                    [Page 11]
+
+RFC 2419                 PPP DES Encryption v2            September 1998
+
+
+12.  Full Copyright Statement
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower & Meyer             Standards Track                    [Page 12]
+