doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc3078.txt b/doc/rfc/rfc3078.txt
new file mode 100644
index 0000000..5bbcc13
--- /dev/null
+++ b/doc/rfc/rfc3078.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                            G. Pall
+Request for Comments: 3078                         Microsoft Corporation
+Category: Informational                                          G. Zorn
+Updates: 2118                                              cisco Systems
+                                                              March 2001
+
+
+          Microsoft Point-To-Point Encryption (MPPE) Protocol
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+
+   The PPP Compression Control Protocol provides a method to negotiate
+   and utilize compression protocols over PPP encapsulated links.
+
+   This document describes the use of the Microsoft Point to Point
+   Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated
+   packets.
+
+Specification of Requirements
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+   described in [5].
+
+1.  Introduction
+
+   The Microsoft Point to Point Encryption scheme is a means of
+   representing Point to Point Protocol (PPP) packets in an encrypted
+   form.
+
+   MPPE uses the RSA RC4 [3] algorithm to provide data confidentiality.
+   The length of the session key to be used for initializing encryption
+   tables can be negotiated.  MPPE currently supports 40-bit and 128-bit
+   session keys.
+
+
+
+
+Pall & Zorn                  Informational                      [Page 1]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+   MPPE session keys are changed frequently; the exact frequency depends
+   upon the options negotiated, but may be every packet.
+
+   MPPE is negotiated within option 18 [4] in the Compression Control
+   Protocol.
+
+2.  Configuration Option Format
+
+
+   Description
+
+      The CCP Configuration Option negotiates the use of MPPE on the
+      link.  By default (i.e., if the negotiation of MPPE is not
+      attempted), no encryption is used.  If, however, MPPE negotiation
+      is attempted and fails, the link SHOULD be terminated.
+
+   A summary of the CCP Configuration Option format is shown below.  The
+   fields are transmitted from left to right.
+
+       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     |        Supported Bits         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Supported Bits         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      18
+
+   Length
+
+      6
+
+   Supported Bits
+
+      This field is 4 octets, most significant octet first.
+
+         3                   2                   1
+       1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             |H|                               |M|S|L|D|     |C|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Pall & Zorn                  Informational                      [Page 2]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+   The 'C' bit is used by MPPC [4] and is not discussed further in this
+   memo.  The 'D' bit is obsolete; although some older peers may attempt
+   to negotiate this option, it SHOULD NOT be accepted.  If the 'L' bit
+   is set (corresponding to a value of 0x20 in the least significant
+   octet), this indicates the desire of the sender to negotiate the use
+   of 40-bit session keys.  If the 'S' bit is set (corresponding to a
+   value of 0x40 in the least significant octet), this indicates the
+   desire of the sender to negotiate the use of 128-bit session keys.
+   If the 'M' bit is set (corresponding to a value of 0x80 in the least
+   significant octet), this indicates the desire of the sender to
+   negotiate the use of 56-bit session keys.  If the 'H' bit is set
+   (corresponding to a value of 0x01 in the most significant octet),
+   this indicates that the sender wishes to negotiate the use of
+   stateless mode, in which the session key is changed after the
+   transmission of each packet (see section 10, below).  In the
+   following discussion, the 'S', 'M' and 'L' bits are sometimes
+   referred to collectively as "encryption options".
+
+   All other bits are reserved and MUST be set to 0.
+
+2.1.  Option Negotiation
+
+   MPPE options are negotiated as described in [2].  In particular, the
+   negotiation initiator SHOULD request all of the options it supports.
+   The responder SHOULD NAK with a single encryption option (note that
+   stateless mode may always be negotiated, independent of and in
+   addition to an encryption option).  If the responder supports more
+   than one encryption option in the set requested by the initiator, the
+   option selected SHOULD be the "strongest" option offered.
+   Informally, the strength of the MPPE encryption options may be
+   characterized as follows:
+
+      STRONGEST
+         128-bit encryption ('S' bit set)
+         56-bit  encryption ('M' bit set)
+         40-bit  encryption ('L' bit set)
+      WEAKEST
+
+   This characterization takes into account the generally accepted
+   strength of the cipher.
+
+   The initiator SHOULD then either send another request containing the
+   same option(s) as the responder's NAK or cancel the negotiation,
+   dropping the connection.
+
+
+
+
+
+
+
+Pall & Zorn                  Informational                      [Page 3]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+3.  MPPE Packets
+
+   Before any MPPE packets are transmitted, PPP MUST reach the Network-
+   Layer Protocol phase and the CCP Control Protocol MUST reach the
+   Opened state.
+
+   Exactly one MPPE datagram is encapsulated in the PPP Information
+   field.  The PPP Protocol field indicates type 0x00FD for all
+   encrypted datagrams.
+
+   The maximum length of the MPPE datagram transmitted over a PPP link
+   is the same as the maximum length of the Information field of a PPP
+   encapsulated packet.
+
+   Only packets with PPP Protocol numbers in the range 0x0021 to 0x00FA
+   are encrypted.  Other packets are not passed thru the MPPE processor
+   and are sent with their original PPP Protocol numbers.
+
+      Padding
+
+         It is recommended that padding not be used with MPPE.  If the
+         sender uses padding it MUST negotiate the Self-Describing-
+         Padding Configuration option [10] during LCP phase and use
+         self-describing pads.
+
+      Reliability and Sequencing
+
+         The MPPE scheme does not require a reliable link.  Instead, it
+         relies on a 12-bit coherency count in each packet to keep the
+         encryption tables synchronized.  If stateless mode has not been
+         negotiated and the coherency count in the received packet does
+         not match the expected count, the receiver MUST send a CCP
+         Reset-Request packet to cause the resynchronization of the RC4
+         tables.
+
+         MPPE expects packets to be delivered in sequence.
+
+         MPPE MAY be used over a reliable link, as described in "PPP
+         Reliable Transmission" [6], but this typically just adds
+         unnecessary overhead since only the coherency count is
+         required.
+
+      Data Expansion
+
+         The MPPE scheme does not expand or compress data.  The number
+         of octets input to and output from the MPPE processor are the
+         same.
+
+
+
+
+Pall & Zorn                  Informational                      [Page 4]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+3.1.  Packet Format
+
+   A summary of the MPPE packet format is shown below.  The fields are
+   transmitted from left to right.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          PPP Protocol         |A|B|C|D|    Coherency Count    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Encrypted Data...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      PPP Protocol
+
+         The PPP Protocol field is described in the Point-to-Point
+         Protocol Encapsulation [1].
+
+         When MPPE is successfully negotiated by the PPP Compression
+         Control Protocol, the value of this field is 0x00FD.  This
+         value MAY be compressed when Protocol-Field-Compression is
+         negotiated.
+
+      Bit A
+
+         This bit indicates that the encryption tables were initialized
+         before this packet was generated.  The receiver MUST re-
+         initialize its tables with the current session key before
+         decrypting this packet.  This bit is referred to as the FLUSHED
+         bit in this document.  If the stateless option has been
+         negotiated, this bit MUST be set on every encrypted packet.
+         Note that MPPC and MPPE both recognize the FLUSHED bit;
+         therefore, if the stateless option is negotiated, it applies to
+         both MPPC and MPPE.
+
+      Bit B
+
+         This bit does not have any significance in MPPE.
+
+      Bit C
+
+         This bit does not have any significance in MPPE.
+
+      Bit D
+
+         This bit set to 1 indicates that the packet is encrypted.  This
+         bit set to 0 means that this packet is not encrypted.
+
+
+
+
+Pall & Zorn                  Informational                      [Page 5]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+      Coherency Count
+
+         The coherency count is used to assure that the packets are sent
+         in proper order and that no packet has been dropped.  It is a
+         monotonically increasing counter which incremented by 1 for
+         each packet sent.  When the counter reaches 4095 (0x0FFF), it
+         is reset to 0.
+
+      Encrypted Data
+
+         The encrypted data begins with the protocol field.  For
+         example, in case of an IP packet (0x0021 followed by an IP
+         header), the MPPE processor will first encrypt the protocol
+         field and then encrypt the IP header.
+
+         If the packet contains header compression, the MPPE processor
+         is applied AFTER header compression is performed and MUST be
+         applied to the compressed header as well.  For example, if a
+         packet contained the protocol type 0x002D (for a compressed
+         TCP/IP header), the MPPE processor would first encrypt 0x002D
+         and then it would encrypt the compressed Van-Jacobsen TCP/IP
+         header.
+
+      Implementation Note
+
+         If both MPPE and MPPC are negotiated on the same link, the MPPE
+         processor MUST be invoked after the MPPC processor by the
+         sender and the MPPE processor MUST be invoked before the MPPC
+         processor by the receiver.
+
+4.  Initial Session Keys
+
+   In the current implementation, initial session keys are derived from
+   peer credentials; however, other derivation methods are possible.
+   For example, some authentication methods (such as Kerberos [8] and
+   TLS [9]) produce session keys as side effects of authentication;
+   these keys may be used by MPPE in the future.  For this reason, the
+   techniques used to derive initial MPPE session keys are described in
+   separate documents.
+
+5.  Initializing RC4 Using a Session Key
+
+   Once an initial session key has been derived, the RC4 context is
+   initialized as follows:
+
+      rc4_key(RC4Key, Length_Of_Key, Initial_Session_Key)
+
+
+
+
+
+Pall & Zorn                  Informational                      [Page 6]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+6.  Encrypting Data
+
+   Once initialized, data is encrypted using the following function and
+   transmitted with the CCP and MPPE headers.
+
+      EncryptedData = rc4(RC4Key, Length_Of_Data, Data)
+
+7.  Changing Keys
+
+7.1.  Stateless Mode Key Changes
+
+   If stateless encryption has been negotiated, the session key changes
+   every time the coherency count changes; i.e., on every packet.  In
+   stateless mode, the sender MUST change its key before encrypting and
+   transmitting each packet and the receiver MUST change its key after
+   receiving, but before decrypting, each packet (see "Synchronization",
+   below).
+
+7.2.  Stateful Mode Key Changes
+
+   If stateful encryption has been negotiated, the sender MUST change
+   its key before encrypting and transmitting any packet in which the
+   low order octet of the coherency count equals 0xFF (the "flag"
+   packet), and the receiver MUST change its key after receiving, but
+   before decrypting, a "flag" packet (see "Synchronization", below).
+
+7.3.  The MPPE Key Change Algorithm
+
+   The following method is used to change keys:
+
+      /*
+       * SessionKeyLength is 8 for 40-bit keys, 16 for 128-bit keys.
+       *
+       * SessionKey is the same as StartKey in the first call for
+       * a given session.
+       */
+
+      void
+      GetNewKeyFromSHA(
+      IN  unsigned char *StartKey,
+      IN  unsigned char *SessionKey,
+      IN  unsigned long SessionKeyLength
+      OUT unsigned char *InterimKey )
+      {
+         unsigned char  Digest[20];
+
+         ZeroMemory(Digest, 20);
+
+
+
+
+Pall & Zorn                  Informational                      [Page 7]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+         /*
+          * SHAInit(), SHAUpdate() and SHAFinal()
+          * are an implementation of the Secure
+          * Hash Algorithm [7]
+          */
+
+         SHAInit(Context);
+         SHAUpdate(Context, StartKey, SessionKeyLength);
+         SHAUpdate(Context, SHApad1, 40);
+         SHAUpdate(Context, SessionKey, SessionKeyLength);
+         SHAUpdate(Context, SHApad2, 40);
+         SHAFinal(Context, Digest);
+
+         MoveMemory(InterimKey, Digest, SessionKeyLength);
+      }
+
+   The RC4 tables are re-initialized using the newly created interim key:
+
+      rc4_key(RC4Key, Length_Of_Key, InterimKey)
+
+   Finally, the interim key is encrypted using the new tables to produce
+   a new session key:
+
+      SessionKey = rc4(RC4Key, Length_Of_Key, InterimKey)
+
+   For 40-bit session keys the most significant three octets of the new
+   session key are now set to 0xD1, 0x26 and 0x9E respectively; for 56-
+   bit keys, the most significant octet is set to 0xD1.
+
+   Finally, the RC4 tables are re-initialized using the new session key:
+
+      rc4_key(RC4Key, Length_Of_Key, SessionKey)
+
+8.  Synchronization
+
+   Packets may be lost during transfer.  The following sections describe
+   synchronization for both the stateless and stateful cases.
+
+8.1.  Stateless Synchronization
+
+   If stateless encryption has been negotiated and the coherency count
+   in the received packet (C1) is greater than the coherency count in
+   the last packet previously received (C2), the receiver MUST perform N
+   = C1 - C2 key changes before decrypting the packet, in order to
+   ensure that its session key is synchronized with the session key of
+   the sender.  Normally, the value of N will be 1; however, if
+   intervening packets have been lost, N may be greater than 1.  For
+   example, if C1 = 5 and C2 = 02 then N = 3 key changes are required.
+
+
+
+Pall & Zorn                  Informational                      [Page 8]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+   Since the FLUSHED bit is set on every packet if stateless encryption
+   was negotiated, the transmission of CCP Reset-Request packets is not
+   required for synchronization.
+
+8.2.  Stateful Synchronization
+
+   If stateful encryption has been negotiated, the sender MUST change
+   its key before encrypting and transmitting any packet in which the
+   low order octet of the coherency count equals 0xFF (the "flag"
+   packet), and the receiver MUST change its key after receiving, but
+   before decrypting, a "flag" packet.  However, the "flag" packet may
+   be lost.  If this happens, the low order octet of the coherency count
+   in the received packet will be less than that in the last packet
+   previously received.  In this case, the receiver MUST perform a key
+   change before decrypting the newly received packet, (since the sender
+   will have changed its key before transmitting the packet), then send
+   a CCP Reset-Request packet (see below).  It is possible that 256 or
+   more consecutive packets could be lost; the receiver SHOULD detect
+   this condition and perform the number of key changes necessary to
+   resynchronize with the sender.
+
+   If packet loss is detected while using stateful encryption, the
+   receiver MUST drop the packet and send a CCP Reset-Request packet
+   without data.  After transmitting the CCP Reset-Request packet, the
+   receiver SHOULD silently discard all packets until a packet is
+   received with the FLUSHED bit set.  On receiving a packet with the
+   FLUSHED bit set, the receiver MUST set its coherency count to the one
+   received in that packet and re-initialize its RC4 tables using the
+   current session key:
+
+      rc4_key(RC4Key, Length_Of_Key, SessionKey)
+
+   When the sender receives a CCP Reset-Request packet, it MUST re-
+   initialize its own RC4 tables using the same method and set the
+   FLUSHED bit in the next packet sent.  Thus synchronization is
+   achieved without a CCP Reset-Ack packet.
+
+9.  Security Considerations
+
+   Because of the way that the RC4 tables are reinitialized during
+   stateful synchronization, it is possible that two packets may be
+   encrypted using the same key.  For this reason, the stateful mode
+   SHOULD NOT be used in lossy network environments (e.g., layer two
+   tunnels on the Internet).
+
+
+
+
+
+
+
+Pall & Zorn                  Informational                      [Page 9]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+   Since the MPPE negotiation is not integrity protected, an active
+   attacker could alter the strength of the keys used by modifying the
+   Supported Bits field of the CCP Configuration Option packet.  The
+   effects of this attack can be minimized through appropriate peer
+   configuration, however.
+
+   Peers MUST NOT transmit user data until the MPPE negotiation is
+   complete.
+
+   It is possible that an active attacker could modify the coherency
+   count of a packet, causing the peers to lose synchronization.
+
+   An active denial-of-service attack could be mounted by methodically
+   inverting the value of the 'D' bit in the MPPE packet header.
+
+10.  References
+
+   [1]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+        51, RFC 1661, July 1994.
+
+   [2]  Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
+        1962, June 1996.
+
+   [3]  RC4 is a proprietary encryption algorithm available under
+        license from RSA Data Security Inc.  For licensing information,
+        contact:
+
+                  RSA Data Security, Inc.
+                  100 Marine Parkway
+                  Redwood City, CA 94065-1031
+
+   [4]  Pall, G., "Microsoft Point-to-Point Compression (MPPC)
+        Protocol", RFC 2118, March 1997.
+
+   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]  Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
+
+   [7]  "Secure Hash Standard", Federal Information Processing Standards
+        Publication 180-1, National Institute of Standards and
+        Technology, April 1995.
+
+   [8]  Kohl, J. and C. Neuman "The Kerberos Network Authentication
+        System (V5)", RFC 1510, September 1993.
+
+   [9]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+        2246, January 1999.
+
+
+
+Pall & Zorn                  Informational                     [Page 10]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+   [10] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
+        1994.
+
+11.  Acknowledgements
+
+   Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all
+   of Microsoft Corporation, significantly contributed to the design and
+   development of MPPE.
+
+   Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie
+   Cobbs, Mark Deuser, and Jeff Haag, for useful feedback.
+
+12.  Authors' Addresses
+
+   Questions about this memo can be directed to:
+
+   Gurdeep Singh Pall
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, Washington 98052
+   USA
+
+   Phone: +1 425 882 8080
+   Fax:   +1 425 936 7329
+   EMail: gurdeep@microsoft.com
+
+
+   Glen Zorn
+   cisco Systems
+   500 108th Avenue N.E.
+   Suite 500
+   Bellevue, Washington 98004
+   USA
+
+   Phone: +1 425 438 8218
+   Fax:   +1 425 438 1848
+   EMail: gwz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pall & Zorn                  Informational                     [Page 11]
+
+RFC 3078                     MPPE Protocol                    March 2001
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pall & Zorn                  Informational                     [Page 12]
+