Network Working Group                                         G. S. Pall
Internet-Draft                                                   G. Zorn
Category: Informational                            Microsoft Corporation
<draft-ietf-pppext-mppe-00.txt>                               March 1998

          Microsoft Point-To-Point Encryption (MPPE) Protocol


1.  Status of this Memo

This  document  is an Internet-Draft.  Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and  its
working groups.  Note that other groups may also distribute working doc-
uments as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum  of  six  months
and  may  be  updated,  replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference  material
or to cite them other than as ``work in progress''.

To  learn  the  current  status  of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in  the  Internet-Drafts  Shadow
Directories  on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

This memo provides information for the Internet  community.   This  memo
does  not specify an Internet standard of any kind.  The distribution of
this memo is unlimited.  It is filed as  <draft-ietf-pppext-mppe-00.txt>
and  expires September 13, 1998.  Please send comments to the PPP Exten-
sions Working Group mailing list (ietf-ppp@merit.edu) or to the  authors
(gurdeep@microsoft.com and glennz@microsoft.com).


2.  Abstract

The  Point-to-Point  Protocol  (PPP)  [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.

The PPP Compression Control Protocol [2] provides a method to  negotiate
and utilize compression protocols over PPP encapsulated links.

This  document describes the use of the Microsoft Point to Point Encryp-
tion protocol (also referred to as MPPE in this document) for encrypting
PPP encapsulated packets.







Pall & Zorn                                                     [Page 1]


INTERNET-DRAFT                    MPPE                        March 1998


3.  Introduction

The  Microsoft Point to Point Encryption scheme is a means of represent-
ing 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.

The  MPPE algorithm changes the session keys frequently; either on every
packet or after transmitting 256 packets,  depending  upon  the  options
negotiated.

MPPE  is negotiated within option 18 [4] in the Compression Control Pro-
tocol.


4.  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].


5.  Configuration Option Format

Description

   The CCP Configuration Option negotiates the use of MPPE on the  link.
   By  default, 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




Pall & Zorn                                                     [Page 2]


INTERNET-DRAFT                    MPPE                        March 1998


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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                           |N|H|S|L|         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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  nego-
   tiate  the use of 40-bit session keys.  If the 'S' bit is set (corre-
   sponding 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 'N' bit is set (corresponding  to  a  value  of
   0x01  in the second least significant octet), this indicates that the
   sender wants to negotiate the use of 40-bit session keys derived from
   the  NT  password  hash.   This  option  has  not been implemented by
   Microsoft at this time, but may be in the future.  If the 'H' bit  is
   set  (corresponding  to  a  value  of  0x80  in the least significant
   octet), this indicates that the sender wishes to negotiate the use of
   "history-less"  mode,  in  which the session key is changed after the
   transmission of each packet (see section 7.6, below).  In the follow-
   ing  discussion,  the 'N', 'S' and 'L' bits are sometimes referred to
   collectively as "encryption options".

   All other bits are reserved and MUST be set to 0.


5.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  the
"historyless"  option  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)
      40-bit  encryption ('N' bit set)



Pall & Zorn                                                     [Page 3]


INTERNET-DRAFT                    MPPE                        March 1998


      40-bit  encryption ('L' bit set)
   WEAKEST

This characterization takes into account the generally accepted strength
of the cipher/key length comination and key derivation method.

The  initiator  SHOULD  then  either send another request containing the
same option(s) as the responder's NAK or cancel the  negotiation,  drop-
ping the connection.


6.  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  data-
grams.

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  encap-
sulated 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  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 "history-less"  mode  has  not
      been  negotiated  and  the  receiver recognizes that the coherency
      count received in the packet  does  not  match  the  count  it  is
      expecting,  it  MUST send a CCP Reset-Request packet to resynchro-
      nize the tables.

      MPPE expects the packets to be delivered in sequence.




Pall & Zorn                                                     [Page 4]


INTERNET-DRAFT                    MPPE                        March 1998


      MPPE MAY be used over a reliable link, as described in "PPP  Reli-
      able  Transmision"  [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.


6.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  com-
   pressed 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
   "history-less"  option  has  been negotiated, this bit MUST be set on
   every packet.  Note that MPPC and MPPE  both  recognize  the  FLUSHED
   bit; therefore, if the "historyless" option is negotiated, it applies
   to both MPPC and MPPE.

Bit B

   This bit does not have any significance in MPPE.

Bit C



Pall & Zorn                                                     [Page 5]


INTERNET-DRAFT                    MPPE                        March 1998


   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.

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  monotoni-
   cally 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 pro-
   cessor 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  pro-
   cessor MUST be invoked after the MPPC processor by the sender and the
   MPPE processor MUST be invoked  before  the  MPPC  processor  by  the
   receiver.


7.  Session Keys

In  the  current implementation, session keys are derived from user cre-
dentials; however, other derivation methods are possible.  For  example,
some  authentication  methods (such as Kerberos and TLS) produce session
keys as side effects of authentication and these keys  may  be  used  by
MPPE  in  the  future.   The techniques used to derive session keys from
user credentials are described in the following sections.







Pall & Zorn                                                     [Page 6]


INTERNET-DRAFT                    MPPE                        March 1998


7.1.  Generating 40-bit Session Keys

MPPE uses a derivative of the user's credentials as the  40-bit  session
key used for initializing encryption tables.

The first step is to obfuscate the user's password using the LmPassword-
Hash() function (described in [7]).  The first 8 octets of  the  result,
say  H,  are used as the basis for the session key generated in the fol-
lowing way:

   /*
   * H is the basis for the session key
   * H' is a copy of H and is the generative session key
   * 8 is the length (in octets) of the key to be generated.
   *
   */
   Get_Key(H, H', 8)

   /*
   * The result of Get_Key() stored in H' is then salted as follows:
   *
   */
   H'[0] = 0xD1 ;
   H'[1] = 0x26 ;
   H'[2] = 0x9E ;


7.2.  Generating 128-bit Session Keys

MPPE uses a derivative of the user's credentials as the 128-bit  session
key used for initializing encryption tables.

The  first  step  is  to obfuscate the user's password using NtPassword-
Hash() function as described in [7].  The first 16 octets of the  result
are then hashed again using the same MD4 algorithm.  The first 16 octets
of the second hash, say H, are used as the basis  for  the  session  key
generated in the following way:

   /*
   * Challenge as described in [7] is sent by the PPP peer during
   * authentication and is 8 octets long.
   * H is the basis for the session key. On return, H contains the
   * start key to be used.
   */
   Get_Start_Key(Challenge, H)

   /*
   * H' is a copy of H and is the generative session key.



Pall & Zorn                                                     [Page 7]


INTERNET-DRAFT                    MPPE                        March 1998


   * Length (in octets) of the key to generate is 16.
   *
   */
   Get_Key(H, H', 16)


7.3.  Key Derivation Functions

The following procedures are used to derive the session key.

/*
 * Pads used in key derivation
 */

SHApad1[40] =
   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

SHApad2[40] =
   {0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2,
    0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2,
    0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2,
    0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2, 0xF2};

/*
 * SHAInit(), SHAUpdate() and SHAFinal() functions are an
 * implementation of Secure Hash Algorithm (SHA-1) [10]. These are
 * available in public domain or can be licensed from
 * RSA Data Security, Inc.
 *
 * 1) H is 8 octets long for 40 bit session keys.
 * 2) H is 16 octets long for 128 bit session keys.
 * 3) H' is same as H when this routine is called for the first time
 *    for the session.
 * 4) The generated key is returned in H'. This is the "current" key.
 */

Get_Key(H, H', Length_Of_Desired_Key) {
   SHAInit(Context)
   SHAUpdate(Context, H, Length_Of_Desired_Key)
   SHAUpdate(Context, SHAPad1, 40)
   SHAUpdate(Context, H', Length_Of_Desired_Key)
   SHAUpdate(Context, SHAPad2, 40)
   SHAFinal(Context, Digest)
   memcpy(H', Digest, Length_Of_Desired_Key)
}



Pall & Zorn                                                     [Page 8]


INTERNET-DRAFT                    MPPE                        March 1998


Get_Start_Key(Challenge, H) {
   SHAInit(Context)
   SHAUpdate(Context, H, 16)
   SHAUpdate(Context, H+Challenge, 24)
   SHAFinal(Context, Digest)
   memcpy(H, Digest, 16)
}


7.4.  Initializing RC4 Using a Session Key

Once H' is derived, the RC4 context is initialized as follows:
   /*
   * rc4_key() library can be licensed from RSA Data Security, Inc.
   */
   rc4_key(RC4Key, Length_Of_Key, H')


7.5.  Encrypting Data

Once  initialized,  data  is  encrypted using the following function and
transmitted with the CCP and MPPE headers.

   /*
   * rc4() can be licensed from RSA Data Security, Inc.
   */
   EncryptedData = rc4(RC4Key, Length_Of_Data, Data)


7.6.  Changing Keys

If the "history-less"  option  has  been  negotiated,  the  session  key
changes  every  time the coherency count changes; i.e., on every packet.
Otherwise, the sender MUST change its key before encrypting  and  trans-
mitting  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 "Synchro-
nization", below).

The following method is used to change keys:

   /*
    * H is the original key.
    * H' is current key.
    * Length_Of_Key: 8 for 40 bit keys and 16 for 128 bit session keys.
    *
    * On return H' is changed to the new key.
   */



Pall & Zorn                                                     [Page 9]


INTERNET-DRAFT                    MPPE                        March 1998


   Get_Key(H, H', Length_Of_Key)

Tables are re-initialized using the RC4 function:

   /*
    * rc4() can be licensed from RSA Data Security, Inc.
   */
   rc4_key(RC4Key, Length_Of_Key, H')

H' is encrypted using the new tables to produce a new H':

   /*
    * rc4() can be licensed from RSA Data Security, Inc.
   */
   H' = rc4(RC4Key, Length_Of_Key, H')

For 40-bit session keys the first three octets of H' are  set  to  0xD1,
0x26 and 0x9E respectively.

Finally, tables are re-initialized using the RC4 function:

   /*
    * rc4() can be licensed from RSA Data Security, Inc.
   */
   rc4_key(RC4Key, Length_Of_Key, H')


7.7.  Synchronization

Packets may be lost during transfer.

As  noted  above,  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 per-
form 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 is responsi-
ble for detecting this  condition  and  performing  the  number  of  key
changes necessary to resynchronize with the sender.

If  the  "history-less" option has not been negotiated and the coherency
count maintained by the receiver does  not  match  the  coherency  count
received  in  the  encrypted  packet,  the receiver drops the packet and



Pall & Zorn                                                    [Page 10]


INTERNET-DRAFT                    MPPE                        March 1998


sends a CCP Reset-Request packet without data.  On receiving this packet
the sender re-initializes the RC4 tables using an RC4 function:

   /*
    * H' is the current session key
    * rc4() can be licensed from RSA Data Security, Inc.
   */
   rc4_key(RC4Key, Length_Of_Key, H')

The  next  packet sent by the sender will have the FLUSHED bit set.  The
receiver on receiving a  packet  with  its  FLUSHED  bit  MUST  set  its
coherency  count  to  the one received in that packet and re-initializes
its own  tables  using  the  same  function.   Thus  synchronization  is
achieved  without  a CCP Reset-Ack packet.  Since the FLUSHED bit is set
on every packet if the "history-less" option  was  negotiated,  synchro-
nization is achieved without the transmission of CCP Reset-Request pack-
ets.


8.  Security Considerations

Because of the way that the RC4 tables are  reinitialized  when  packets
are  lost,  it  is  possible that two packets may be encrypted using the
same key.  For this reason, the "historyless" mode SHOULD always be used
in lossy network environments (e.g., layer two tunnels on the Internet).

Because of the way in which 40-bit keys are derived, the initial  40-bit
session key will be identical in all sessions established under the same
user credentials.  For this reason, and because RC4 with  a  40-bit  key
length  is  believed  to  be  a relatively weak cipher, peers SHOULD NOT
negotiate the 'L' bit if it can be avoided.


9.  References

[1]  Simpson, W., "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





Pall & Zorn                                                    [Page 11]


INTERNET-DRAFT                    MPPE                        March 1998


[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]  Cobb, S. and Zorn, G., "Microsoft PPP CHAP Extensions", draft-ietf-
     pppext-mschap-00.txt (work in progress), March 1998.

[8]  "Data Encryption Standard (DES)",  Federal  Information  Processing
     Standard  Publication  46-2,  National  Institute  of Standards and
     Technology, December 1993

[9]  "DES Modes of Operation", Federal Information Processing  Standards
     Publication  81,  National  Institute  of Standards and Technology,
     December 1980

[10] "Secure Hash Standard", Federal  Information  Processing  Standards
     Publication  180-1, National Institute of Standards and Technology,
     April 1995


10.  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  (rfriend@hifn.com),  Joe  Davies
(josephd@microsoft.com), Tony Bell (tonybe@microsoft.com), and Jeff Haag
(jeff_haag@3com.com) for useful feedback.


11.  Chair's Address

The PPP Extensions Working Group can be contacted via the current chair:

   Karl Fox
   Ascend Communications
   3518 Riverside Drive
   Suite 101
   Columbus, OH 43221

   Phone: +1 614 326 6841
   Email: karl@ascend.com




Pall & Zorn                                                    [Page 12]


INTERNET-DRAFT                    MPPE                        March 1998


12.  Authors' Addresses

Questions about this memo ican also be directed to:

   Gurdeep Singh Pall
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone: +1 425 882 8080
   FAX:   +1 425 936 7329
   EMail: gurdeep@microsoft.com


   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone: +1 425 703 1559
   FAX:   +1 425 936 7329
   EMail: glennz@microsoft.com


13.  Expiration Date

This  memo  is  filed  as <draft-ietf-pppext-mppe-00.txt> and expires on
September 13, 1998.























Pall & Zorn                                                    [Page 13]