datatracker.ietf.org
Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

Microsoft Point-To-Point Encryption (MPPE) Protocol
RFC 3078

Document type: RFC - Informational (March 2001; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 3078 (Informational)
Responsible AD: (None)
Send notices to: No addresses provided

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

[include full document text]