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.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
ポイントツーポイントプロトコル（PPP）は、ポイントツーポイントリンク上でマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
PPP圧縮制御プロトコルはPPPカプセル化されたリンクの上に圧縮プロトコルを交渉して利用する方法を提供します。
This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets.
このドキュメントは、PPPカプセル化パケットの機密性を高めるために、暗号化（MPPE）をポイントするマイクロソフトポイントの使用を記載しています。
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].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" [5]で説明されるように解釈されるべきではありません。
The Microsoft Point to Point Encryption scheme is a means of representing Point to Point Protocol (PPP) packets in an encrypted form.
マイクロソフトポイントは、暗号化方式をポイントするために暗号化された形式でプロトコル（PPP）パケットをポイントツーポイントを表現する手段です。
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.
MPPEは、データの機密性を提供するために、RSA RC4 [3]のアルゴリズムを使用しています。暗号化テーブルを初期化するために使用されるセッションキーの長さを交渉することができます。 MPPEは現在、40ビットおよび128ビットのセッションキーをサポートしています。
MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet.
MPPEセッションキーは頻繁に変更されています。正確な周波数は、交渉したオプションによって異なりますが、すべてのパケットであってもよいです。
MPPE is negotiated within option 18 [4] in the Compression Control Protocol.
MPPEは、圧縮制御プロトコルでのオプション18 [4]の中に交渉されています。
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.
CCP構成オプションは、リンク上のMPPEの使用を交渉します。 （MPPEのネゴシエーションが試行されていない場合、すなわち、）デフォルトでは、暗号化は使用されません。しかし、MPPE交渉を試みて失敗した場合、リンクが終了されるべき。
A summary of the CCP Configuration Option format is shown below. The fields are transmitted from left to right.
CCP設定オプション形式の詳細は、以下の通りです。フィールドは左から右に送信されます。
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.
このフィールドは、最初の4つのオクテットは、最上位オクテットです。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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".
「C」ビット[4] MPPCによって使用され、このメモでさらに議論されていません。 「D」ビットが時代遅れです。一部の古いピアがこのオプションを交渉しようとするかもしれないが、それは受け入れられない（SHOULD NOT）。 「L」ビット（最下位オクテットでの0x20の値に相当）に設定されている場合、これは40ビットのセッションキーの使用を交渉するために、送信者の欲求を示します。 「S」ビット（最下位オクテットで0x40の値に相当）に設定されている場合、これは、128ビットのセッションキーの使用を交渉するために、送信者の欲求を示します。 「M」ビット（最下位オクテットでは0x80の値に相当）に設定されている場合、これは56ビットのセッションキーの使用を交渉するために、送信者の欲求を示します。 「H」ビット（最も重要なオクテットでは0x01の値に相当）に設定されている場合、これは、（セッション鍵は、各パケットの送信後に変更されて、送信者がステートレスモードの使用を交渉することを望むことを示します）以下、セクション10を参照してください。以下の説明では、「S」、「M」及び「L」ビットは総称し、「暗号化オプション」と呼ばれます。
All other bits are reserved and MUST be set to 0.
他のすべてのビットは予約され、0に設定しなければなりません。
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:
[2]で説明されるようにMPPEオプションがネゴシエートされています。具体的には、交渉開始剤は、それがサポートするすべてのオプションを要求する必要があります。レスポンダは、単一の暗号化オプションとNAK（の独立した暗号化オプションに加えて、ステートレスモードは常に交渉される可能性があることに注意）する必要があります。レスポンダは、イニシエータによって要求されたセットの中に複数の暗号化オプションをサポートしている場合は、選択したオプションが提供され、「最強」のオプションであるべきです。次のように非公式に、MPPE暗号化オプションの強度を特徴付けることができます。
STRONGEST 128-bit encryption ('S' bit set) 56-bit encryption ('M' bit set) 40-bit encryption ('L' bit set) WEAKEST
最強の128ビット暗号化（「S」ビット・セット）56ビットの暗号化（「M」ビットセット）40ビットの暗号化（「L」ビット・セット）最も弱いです
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.
イニシエータは、どちらの応答者のNAKと同じオプション（複数可）を含む別の要求を送信したり、接続をドロップ、交渉を中止すべきです。
Before any MPPE packets are transmitted, PPP MUST reach the Network-Layer Protocol phase and the CCP Control Protocol MUST reach the Opened state.
任意のMPPEパケットが送信される前に、PPPはネットワーク層プロトコルフェーズに達しなければならないとCCP制御プロトコルはOpened状態に達しなければなりません。
Exactly one MPPE datagram is encapsulated in the PPP Information field. The PPP Protocol field indicates type 0x00FD for all encrypted datagrams.
正確に一つのMPPEデータグラムはPPPの情報分野でカプセル化されています。 PPPプロトコルフィールドはすべて暗号化されたデータグラムのための0x00FDを入力示しています。
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.
PPPリンクを介して送信されるMPPEデータグラムの最大長は、PPPカプセル化されたパケットの情報フィールドの最大長さと同じです。
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.
0x00FAの範囲0x0021でPPPプロトコル番号を持つパケットだけが暗号化されています。その他のパケットはMPPEプロセッサに通していないと、元のPPPプロトコル番号が送信されます。
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.
パディングはMPPEで使用されていないことをお勧めします。送信者がパディングを使用している場合には、LCPフェーズで自己記述-パディングの設定オプション[10]を交渉し、自己記述のパッドを使用しなければなりません。
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方式は、信頼性の高いリンクを必要としません。代わりに、同期の暗号化テーブルを維持するために、各パケット内の12ビットの一貫性の数に依存しています。ステートレスモードが交渉されていないと、受信したパケットで一貫性のカウントが予想される数と一致しない場合、受信機は、RC4テーブルの再同期を引き起こすCCPリセット-Requestパケットを送らなければなりません。
MPPE expects packets to be delivered in sequence.
MPPEは、パケットが順番に配信されると予想しています。
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.
「PPP信頼できる送信」[6]で説明したようにMPPEは、信頼性の高いリンク上で使用することができるが、これは通常、ちょうどのみ一貫性カウントが必要とされているので、不必要なオーバーヘッドを追加します。
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.
MPPE方式は、データを展開または圧縮されません。 MPPEプロセッサからオクテットへの入力及び出力の数は同じです。
A summary of the MPPE packet format is shown below. The fields are transmitted from left to right.
MPPEパケットフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
PPPプロトコル
The PPP Protocol field is described in the Point-to-Point Protocol Encapsulation [1].
PPPプロトコルフィールドは、ポイントツーポイントプロトコルカプセル化[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.
MPPEが正常にPPP圧縮制御プロトコルによって交渉されている場合、このフィールドの値は0x00FDです。プロトコルフィールド圧縮が交渉されている場合、この値は、圧縮することができます。
Bit A
ビット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.
このビットは、このパケットが生成される前に暗号化テーブルが初期化されたことを示しています。受信機はこのパケットを解読する前に、現在のセッションキーを使用してテーブルを再初期化する必要があります。このビットは、この文書のFLUSHEDビットと呼ばれています。ステートレスオプションが交渉されている場合、このビットは、すべて暗号化されたパケットに設定しなければなりません。 MPPCとMPPEの両方FLUSHEDビットを認識することに注意してください。ステートレスオプションが交渉されている場合ので、それはMPPCとMPPEの両方に適用されます。
Bit B
ビットB
This bit does not have any significance in MPPE.
このビットはMPPE内の任意の意味を持っていません。
Bit C
ビットC
This bit does not have any significance in MPPE.
このビットはMPPE内の任意の意味を持っていません。
Bit D
ビットD
This bit set to 1 indicates that the packet is encrypted. This bit set to 0 means that this packet is not encrypted.
1に設定され、このビットは、パケットが暗号化されていることを示しています。 0に設定され、このビットは、このパケットが暗号化されていないことを意味します。
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.
一貫性カウントは、パケットが適切な順序で送信され、何のパケットが廃棄されていないことをされていることを確実にするために使用されます。これは、送信されたパケットごとに1ずつ増加単調に増加するカウンタです。カウンタが（0x0FFF）4095に達すると、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.
暗号化されたデータは、プロトコル・フィールドで始まります。例えば、IPパケット（IPヘッダに続く0x0021）の場合には、MPPEプロセッサは、第1のプロトコル・フィールドを暗号化し、IPヘッダを暗号化します。
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.
パケットは、ヘッダ圧縮が含まれている場合、ヘッダ圧縮が行われ、同様に圧縮されたヘッダーに適用されなければならない後、MPPEプロセッサが適用されます。パケットが（圧縮されたTCP / IPヘッダの）プロトコルタイプ0x002Dが含まれている場合、例えば、MPPEプロセッサは最初0x002Dを暗号化するであろうし、それは、圧縮されたVAN-ヤコブセンTCP / IPヘッダを暗号化することになります。
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.
MPPEとMPPCの両方が同じリンク上でネゴシエートされる場合、MPPEプロセッサは、受信機によってMPPCプロセッサ前に呼び出されなければならない送信者とMPPEプロセッサによってMPPCプロセッサの後に呼び出されなければなりません。
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.
現在の実装では、最初のセッション鍵は、ピア認証情報から導出されます。しかし、他の導出方法が可能です。例えば、いくつかの認証方法（Kerberosなど[8]およびTLS [9]）認証の副作用としてセッション鍵を生成します。これらのキーは、将来的にはMPPEで使用することができます。このため、初期MPPEセッションキーを導出するために使用される技術は、別の文献に記載されています。
Once an initial session key has been derived, the RC4 context is initialized as follows:
最初のセッション鍵が導出されたら、次のように、RC4コンテキストが初期化されます。
rc4_key(RC4Key, Length_Of_Key, Initial_Session_Key)
rc4_key（RC4Key、Length_Of_Key、Initial_Session_Key）
Once initialized, data is encrypted using the following function and transmitted with the CCP and MPPE headers.
初期化されると、データは次の関数を使用して暗号化し、CCPとMPPEヘッダーで送信されます。
EncryptedData = rc4(RC4Key, Length_Of_Data, Data)
EncryptedData = RC4（RC4Key、Length_Of_Data、データ）
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).
ステートレス暗号化が交渉されている場合は、セッションキーは、コヒーレンシカウント変更するたびに変更します。すなわち、すべてのパケットに。ステートレスモードでは、送信者は、各パケットを暗号化して送信する前にそのキーを変更する必要があり、受信機が受信した後、そのキーを変更する必要がありますが、復号化の前に、各パケットは（以下、「同期」を参照してください）。
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).
ステートフルな暗号化がネゴシエートされている場合は、送信者は、コヒーレンシ・カウントの下位のオクテットが0xFF（「旗」パケット）に等しく、及び受信機が受信した後、そのキーを変更する必要がありますがここですべてのパケットを暗号化して送信する前にそのキーを変更する必要があります復号化の前に、「フラグ」パケット（以下、「同期」を参照）。
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];
無効GetNewKeyFromSHA（unsigned long型SessionKeyLength OUT unsigned char型IN unsigned charのIN * StartKey、unsigned char型IN * SESSIONKEY、* InterimKey）{unsigned charのダイジェスト[20]。
ZeroMemory(Digest, 20);
ZeroMemory（ダイジェスト、20）。
/*
* 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); }
MoveMemory（InterimKey、ダイジェスト、SessionKeyLength）。 }
The RC4 tables are re-initialized using the newly created interim key:
RC4テーブルは、新しく作成された暫定鍵を使用して再初期化されています。
rc4_key(RC4Key, Length_Of_Key, InterimKey)
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)
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.
40ビットのセッションキーのための新たなセッションキーの最も重要な3つのオクテットは、現在、それぞれ0xD1、0x26と0x9Eに設定されています。 、56ビットキーのために、最も重要なオクテットは0xD1に設定されています。
Finally, the RC4 tables are re-initialized using the new session key:
最後に、RC4テーブルには、新しいセッションキーを使用して再初期化されています。
rc4_key(RC4Key, Length_Of_Key, SessionKey)
rc4_key（RC4Key、Length_Of_Key、SESSIONKEY）
Packets may be lost during transfer. The following sections describe synchronization for both the stateless and stateful cases.
パケットは転送中に失われる可能性があります。次のセクションでは、両方のステートレスとステートフル例の同期について説明します。
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.
ステートレス暗号化がネゴシエートされており、受信したパケット（C1）でコヒーレンシカウントが最後のパケットで一貫カウントよりも大きい場合に、以前に、受信機が実行しなければならない（C2）を受信N = C1 - C2で、パケットを解読する前にキー変更そのセッション鍵は、送信者のセッションキーと同期していることを確実にするため。通常、Nの値が1になります。介在するパケットが失われた場合はC1 = 5、C2 = 02次に、N = 3つのキーの変更が必要な場合は、Nは、例えば、1より大きいとすることができます。
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.
ステートレス暗号化が交渉された場合FLUSHEDビットはパケットごとに設定されているので、CCPリセット-Requestパケットの送信は、同期のために必要ありません。
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.
ステートフルな暗号化がネゴシエートされている場合は、送信者は、コヒーレンシ・カウントの下位のオクテットが0xFF（「旗」パケット）に等しく、及び受信機が受信した後、そのキーを変更する必要がありますがここですべてのパケットを暗号化して送信する前にそのキーを変更する必要があります復号化の前に、「フラグ」パケット。しかし、「フラグ」パケットが失われる可能性があります。この問題が発生した場合、受信したパケットにおける一貫性・カウントの下位のオクテットは、以前に受信した最後のパケットよりも少なくなります。この場合、受信機は、（下記参照）CCPリセット要求パケットを送信し、次いで、（送信側がパケットを送信する前に、そのキーを変更しているので）、新たに受信したパケットを復号化する前に、キー変更を実行しなければなりません。 256以上の連続したパケットが失われる可能性があります。受信機は、この状態を検出し、送信側と再同期するために必要な鍵の変更の数を実行する必要があります。
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:
ステートフル暗号化を使用している間、パケットロスが検出された場合、受信機は、パケットをドロップし、データなしCCPリセット要求パケットを送信しなければなりません。パケットがフラッシュビットセットで受信されるまで、CCPリセット要求パケットを送信した後、受信機は静かにすべてのパケットを破棄すべきです。 FLUSHEDビットセットでパケットを受信すると、受信機は、そのパケット内の受信した1つに、そのコヒーレンシ・カウントを設定しなければなりません、そして、現在のセッション鍵を使用して、RC4テーブルを再初期化します。
rc4_key(RC4Key, Length_Of_Key, SessionKey)
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.
送信者がCCPリセット要求パケットを受信すると、同じ方法を用いて、自身のRC4テーブルを再初期化して送信された次のパケット中の追い出されたビットを設定しなければなりません。したがって同期はCCPリセット-Ackパケットなしに達成されます。
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).
そのためRC4テーブルがステートフル同期中に再初期化されている方法で、2つのパケットが同じキーを使用して暗号化される可能性があります。この理由のために、ステートフルモードは非可逆ネットワーク環境（インターネット上の例えば、2つのトンネル層）で使用すべきではありません。
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.
MPPE交渉が完全性保護されていないので、アクティブな攻撃者は、CCP設定オプションパケットのサポートされているビットフィールドを変更することで使用されるキーの強さを変えることができます。この攻撃の影響は、しかし、適切なピア設定によって最小限に抑えることができます。
Peers MUST NOT transmit user data until the MPPE negotiation is complete.
MPPEのネゴシエーションが完了するまで、ピアは、ユーザデータを送信してはなりません。
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.
アクティブサービス拒否攻撃は、系統的MPPEパケットヘッダの「D」ビットの値を反転させて取り付けることができます。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1]シンプソン、W.、エディタ、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[2]ランド、D.、 "PPP圧縮制御プロトコル（CCP）"、RFC 1962、1996年6月。
[3] RC4 is a proprietary encryption algorithm available under license from RSA Data Security Inc. For licensing information, contact:
[3] RC4は情報、接触のライセンスについては、RSAデータセキュリティ社からライセンスの下で利用可能な独自の暗号化アルゴリズムは次のとおりです。
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.
[4]ポール、G.、 "マイクロソフトポイントツーポイント圧縮（MPPC）プロトコル"、RFC 2118、1997年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[6]ランド、D.、 "PPP信頼性の高い伝送"、RFC 1663、1994年7月。
[7] "Secure Hash Standard", Federal Information Processing Standards Publication 180-1, National Institute of Standards and Technology, April 1995.
[7]、連邦情報処理規格180-1公報、米国国立標準技術研究所、1995年4月「ハッシュ標準セキュア」。
[8] Kohl, J. and C. Neuman "The Kerberos Network Authentication System (V5)", RFC 1510, September 1993.
[8]コールズ、J.及びC.ノイマン "ケルベロスネットワーク認証システム（V5）"、RFC 1510、1993年9月。
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[9]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[10] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[10]シンプソン、W.、エディタ、 "PPP LCP拡張機能"、RFC 1570、1994年1月。
Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all of Microsoft Corporation, significantly contributed to the design and development of MPPE.
アンソニー・ベル、リチャード・B.ウォード、テレンスのスパイとトーマス・ディミトリ、Microsoft Corporationの全ては、大幅MPPEの設計と開発に貢献しました。
Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie Cobbs, Mark Deuser, and Jeff Haag, for useful feedback.
有用なフィードバックのためのロバート・フレンド、ジョー・デイヴィス、ジョディ・テリル、アーチーCobbs、マーク・Deuser、そしてジェフ・ハーグへの追加のおかげで、。
Questions about this memo can be directed to:
このメモに関する質問に向けることができます。
Gurdeep Singh Pall Microsoft Corporation One Microsoft Way Redmond, Washington 98052 USA
ガーディープ・シンポールマイクロソフト社1つのマイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 882 8080 Fax: +1 425 936 7329 EMail: gurdeep@microsoft.com
電話：+1 425 882 8080ファックス：+1 425 936 7329 Eメール：gurdeep@microsoft.com
Glen Zorn cisco Systems 500 108th Avenue N.E. Suite 500 Bellevue, Washington 98004 USA
グレンツォルンシスコシステムズ500第108アベニューN.E.スイート500ベルビュー、ワシントン98004 USA
Phone: +1 425 438 8218 Fax: +1 425 438 1848 EMail: gwz@cisco.com
電話：+1 425 438 8218ファックス：+1 425 438 1848 Eメール：gwz@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。