rfc3078.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页


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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Glen Zorn
   cisco Systems
   500 108th Avenue N.E.
   Suite 500
   Bellevue, Washington 98004
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]














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]