[要約] RFC 3078は、Microsoft Point-To-Point Encryption（MPPE）プロトコルに関する仕様です。このRFCの目的は、MPPEプロトコルのセキュリティ要件と機能を定義し、ポイントツーポイントの通信を暗号化するための方法を提供することです。
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
マイクロソフトポイントツーポイント暗号化（MPPE）プロトコル
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、Microsoft Point to Point Encryption（MPPE）を使用して、PPPにカプセル化されたパケットの機密性を高めることについて説明します。
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]で説明されているように解釈されるべきではありません。
The Microsoft Point to Point Encryption scheme is a means of representing Point to Point Protocol (PPP) packets in an encrypted form.
Microsoft Point to Point暗号化スキームは、暗号化されたフォームでPoint to Pointプロトコル（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
18
Length
長さ
6
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」ビットはMPPC [4]で使用されており、このメモではこれ以上説明されていません。「D」ビットは時代遅れです。一部の年上のピアはこのオプションを交渉しようとするかもしれませんが、受け入れられるべきではありません。「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する必要があります（ステートレスモードは常にネゴシエートされ、暗号化オプションとは無関係で、それに加えて交渉することができることに注意してください）。Responderがイニシエーターが要求したセットで複数の暗号化オプションをサポートしている場合、選択されたオプションは提供される「最も強力な」オプションである必要があります。非公式には、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制御プロトコルはオープン状態に到達する必要があります。
Exactly one MPPE datagram is encapsulated in the PPP Information field. The PPP Protocol field indicates type 0x00FD for all encrypted datagrams.
正確に1つの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.
範囲0x0021〜0x00FAの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リセットリケストパケットを送信する必要があります。
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.
MPPEは、「PPP信頼できる送信」[6]で説明されているように、信頼できるリンクで使用できますが、これは通常、コヒーレンシーカウントのみが必要なため、不必要なオーバーヘッドを追加するだけです。
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.
このビットは、このパケットが生成される前に暗号化テーブルが初期化されたことを示しています。受信者は、このパケットを復号化する前に、現在のセッションキーでテーブルを再発行する必要があります。このビットは、このドキュメントのフラッシュビットと呼ばれます。ステートレスオプションがネゴシエートされている場合、このビットはすべての暗号化されたパケットで設定する必要があります。MPPCとMPPEはどちらもフラッシュビットを認識していることに注意してください。したがって、ステートレスオプションがネゴシエートされた場合、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個ずつ増加する単調に増加するカウンターです。カウンターが4095（0x0fff）に到達すると、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パケット（0x0021の後にIPヘッダーが続く）の場合、MPPEプロセッサは最初にプロトコルフィールドを暗号化し、次に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プロセッサが適用され、圧縮ヘッダーにも適用する必要があります。たとえば、パケットにプロトコルタイプ0x002D（圧縮TCP/IPヘッダーの場合）が含まれている場合、MPPEプロセッサは最初に0x002Dを暗号化し、次に圧縮されたVan-Jacobsen 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、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];
void getNewKeyFromsha（unsigned char *startkey、unsigned char *sessionkey、unsigned long sessionkeylength out unsigned char *interimkey）{unsigned char Digest [20];
ZeroMemory(Digest, 20);
ゼロメモリー（ダイジェスト、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、Digest、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になります。ただし、介在パケットが失われている場合、nは1より大きくなる場合があります。たとえば、c1 = 5およびc2 = 02の場合、n = 3の重要な変更が必要です。
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.
Statelessの暗号化が交渉された場合、フラッシュビットはすべてのパケットに設定されるため、同期にはCCPリセットリケストパケットの送信は必要ありません。
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:
Stateful暗号化の使用中にパケットの損失が検出された場合、受信機はパケットをドロップし、データなしでCCPリセットリケストパケットを送信する必要があります。CCP Reset-Requestパケットを送信した後、レシーバーは、フラッシュビットセットでパケットが受信されるまで、すべてのパケットを静かに破棄する必要があります。フラッシュビットセットを備えたパケットを受信すると、レシーバーはそのパケットで受信したものにコヒーレンシーカウントを設定し、現在のセッションキーを使用して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リセットパケットなしで達成されます。
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] Rand、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 Data Security Inc.からライセンス情報のライセンス情報のために利用可能な独自の暗号化アルゴリズムです。お問い合わせください。
RSA Data Security, Inc. 100 Marine Parkway Redwood City, CA 94065-1031
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] Pall、G。、「Microsoft Point-to-Point圧縮（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[6] Rand、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] 「Secure Hash Standard」、Federal Information Standards Publication 180-1、国立標準技術研究所、1995年4月。
[8] Kohl, J. and C. Neuman "The Kerberos Network Authentication System (V5)", RFC 1510, September 1993.
[8] Kohl、J。およびC. Neuman「Kerberos Network認証システム（V5）」、RFC 1510、1993年9月。
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[9] Dierks、T。およびC. Allen、「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.
Anthony Bell、Richard B. Ward、Terence Spies、Thomas Dimitri、Microsoft Corporationは、MPPEの設計と開発に大きく貢献しました。
Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie Cobbs, Mark Deuser, and Jeff Haag, for useful feedback.
ロバート・フレンド、ジョー・デイビス、ジョディ・テリル、アーチー・コブス、マーク・デューザー、ジェフ・ハーグに感謝します。
Questions about this memo can be directed to:
このメモに関する質問は、次のように向けることができます。
Gurdeep Singh Pall Microsoft Corporation One Microsoft Way Redmond, Washington 98052 USA
Gurdeep Singh Pall Microsoft Corporation One Microsoft Way Redmond、Washington 98052 USA
Phone: +1 425 882 8080
Fax: +1 425 936 7329
EMail: gurdeep@microsoft.com
Glen Zorn cisco Systems 500 108th Avenue N.E. Suite 500 Bellevue, Washington 98004 USA
Glen Zorn Cisco Systems 500 108th Avenue N.E.Suite 500 Bellevue、Washington 98004 USA
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。