Microsoft Point-To-Point Encryption (MPPE) Protocol
RFC 3078
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
Show full document text