組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：劉梓超（zichao   zi_chao@263.net）
譯文發(fā)布時(shí)間：2001-4-12
版權(quán)：本翻譯文檔可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及組織信息。



Network Working Group                                            G. Pall
Request for Comments: 3078                         Microsoft Corporation
Category: Informational                                          G. Zorn
Updates: 2118                                              cisco Systems
March 2001




RFC3078微軟點(diǎn)到點(diǎn)加密(MPPE)協(xié)議
(RFC3078 Microsoft Point-To-Point Encryption (MPPE) Protocol)

本備忘錄狀態(tài)
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.
版權(quán)聲明
   Copyright (C) The Internet Society (1999).  All Rights Reserved.

摘要
點(diǎn)到點(diǎn)協(xié)議(PPP)提供一種在點(diǎn)到點(diǎn)鏈路上傳送多協(xié)議數(shù)據(jù)報(bào)的標(biāo)準(zhǔn)方法。
PPP壓縮控制協(xié)議提供了一種在PPP封裝鏈路上協(xié)商和運(yùn)用壓縮協(xié)議的方法。
本文件描述的是利用微軟點(diǎn)到點(diǎn)的加密法(MPPE)提高PPP封裝包的保密性。

要求說明書
本文檔中的關(guān)鍵字“或許”,“必須”，“必須不”，“可選的”，“建議”，“應(yīng)該”和“不應(yīng)該”在[5]中解釋。





目錄
1. 介紹	2
2. 配置選項(xiàng)格式	2
2.1. 選項(xiàng)協(xié)商	3
3. MPPE包	3
3.1.包格式	4
4. 初始會(huì)話密鑰	5
5. 使用會(huì)話密鑰初始化RC4	6
6. 加密數(shù)據(jù)	6
7. 改變密鑰	6
7.1.無狀態(tài)方式密鑰的改變	6
7.2.狀態(tài)方式密鑰變化	6
7.3. MPPE密鑰更換算法	6
8. 同步	7
8.1.無狀態(tài)同步	8
8.2.狀態(tài)同步	8
9. 安全性考慮	8
參考	9
鳴謝	9
作者地址	10
版權(quán)聲明	10
致謝	11

1. 介紹
微軟點(diǎn)到點(diǎn)加密方案是一種將點(diǎn)到點(diǎn)協(xié)議(PPP)包用加密形式表示的方法。
MPPE運(yùn)用RSA RC4 [3]算法提供數(shù)據(jù)的保密性。用于初始化密碼表的會(huì)話密鑰的長(zhǎng)度可以協(xié)商。 MPPE目前支持40位和128位的會(huì)話密鑰。
MPPE會(huì)話密鑰是經(jīng)常變化的；變化的頻率取決于任選項(xiàng)的協(xié)商，每個(gè)包都有可能不同。
MPPE在壓縮控制協(xié)議的選項(xiàng)18[4]中協(xié)商。
2. 配置選項(xiàng)格式
描述
CCP配置選項(xiàng)在鏈路上對(duì)MPPE的使用進(jìn)行協(xié)商。 缺省狀態(tài)下(即，如果MPPE的協(xié)商沒有進(jìn)行)，不使用加密法。 如果，MPPE協(xié)商進(jìn)行了并且失敗，那么鏈接應(yīng)該被中斷。
CCP配置選項(xiàng)格式如下所示。字段從左至右進(jìn)行傳輸。

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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      類型     |    長(zhǎng) 度      |            支持的bit數(shù)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           支持的bit數(shù)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

類型
      18
   
長(zhǎng)度
６

支持的Bit數(shù)
      該字段有４個(gè)八位字節(jié)，最高八位字節(jié)在前。
         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|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ‘C’bit位被MPPC[4]使用，在本備忘錄不作進(jìn)一步的討論。‘D’bit位被舍棄；雖然一些舊的端子可能會(huì)對(duì)這個(gè)選項(xiàng)進(jìn)行協(xié)商，但這是不應(yīng)該接受的。如果‘L’bit位被設(shè)置(對(duì)應(yīng)于最低位的八位字節(jié)值為0x20)，這表明發(fā)送端要求協(xié)商使用40位會(huì)話密鑰。 如果‘S’bit位被設(shè)置(對(duì)應(yīng)于最低位的八位字節(jié)值為0x40)，這表明發(fā)送端要求協(xié)商使用128位會(huì)話密鑰。如果‘M’bit位被設(shè)置(對(duì)應(yīng)于最低位的八位字節(jié)值為0x80)，這表明發(fā)送端要求協(xié)商使用56位會(huì)話密鑰。如果‘H’bit位被設(shè)置(對(duì)應(yīng)于最高八位字節(jié)的值為0x01)，這表明發(fā)送端希望協(xié)商使用無狀態(tài)方式，在這種方式中會(huì)話密鑰在每個(gè)包傳輸之后變化(參見下面的節(jié)10)。在下面的討論中，‘S’，‘M’和‘L’bit位有時(shí)被共同地作為“加密選項(xiàng)”。

所有其他的位保留并且必須設(shè)置為0。
2.1. 選項(xiàng)協(xié)商
MPPE選項(xiàng)如[2]的描述進(jìn)行協(xié)商。特別地，協(xié)商發(fā)起端應(yīng)該說明它所支持的所有的選項(xiàng)。
應(yīng)答端應(yīng)該用一個(gè)單一的加密選項(xiàng)進(jìn)行否認(rèn)(應(yīng)該注意無狀態(tài)方式也許總是需要協(xié)商，它獨(dú)立并附加于一個(gè)加密選項(xiàng))。如果應(yīng)答端支持超過一種發(fā)起端所要求設(shè)置的加密選項(xiàng)，則它選擇的選項(xiàng)應(yīng)該是所能提供的“最健壯”的選項(xiàng)。
非正式的，MPPE加密選項(xiàng)的強(qiáng)度可以遵循如下表示方法：
      最健壯的
         128位加密(‘S’bit位被設(shè)置)
         56位加密(‘M’bit位被設(shè)置)
         40位加密(‘L’bit位被設(shè)置)
最虛弱的

這個(gè)描述考慮了大家公認(rèn)的密碼強(qiáng)度。
發(fā)起端應(yīng)該發(fā)送另一個(gè)含有與應(yīng)答端的否定同樣選項(xiàng)的請(qǐng)求報(bào)文或者取消協(xié)商，終止連接。
3. MPPE包
在任何MPPE包被發(fā)送前，PPP必須為網(wǎng)絡(luò)層協(xié)議階段并且CCP控制協(xié)議必須為開放狀態(tài)。
一個(gè)MPPE數(shù)據(jù)報(bào)被壓縮在PPP信息域中。PPP協(xié)議字段注明所有加密的數(shù)據(jù)報(bào)類型為0x00FD。
在PPP鏈路上傳送的MPPE數(shù)據(jù)報(bào)最大長(zhǎng)度同一個(gè)PPP壓縮包的信息域的最大長(zhǎng)度一樣。
僅PPP協(xié)議號(hào)在范圍0x0021到0x00FA之間的包被加密。其他的包不通過MPPE處理程序并且同它們的原來的PPP協(xié)議號(hào)一同發(fā)送。

    填料

建議MPPE不使用填充字段。如果發(fā)送端使用填充字段，它必須在鏈路控制階段進(jìn)行自描述填充配置選擇[10]協(xié)商并且使用自描述填充。

    可靠性和順序性

    MPPE方案不需要可靠鏈路。它依靠每個(gè)包所含的一個(gè)12位計(jì)數(shù)值來保持與加密表的同步。如果無狀態(tài)方式?jīng)]有被協(xié)商而且附在所收到包的數(shù)與所期待的數(shù)不符合，則接收端必須發(fā)送一個(gè)CCP重置請(qǐng)求包使RC4表重新同步。
    MPPE需要包被順序發(fā)送。
    MPPE可以被用在一個(gè)可靠鏈路上，如“PPP可靠傳輸”[6]中所述，但是由于僅僅需要附加的計(jì)數(shù)，這樣就增加了不必要的開銷。
    
數(shù)據(jù)擴(kuò)展

    MPPE方案不擴(kuò)展或壓縮數(shù)據(jù)。從MPPE處理程序輸入和輸出的八位字節(jié)數(shù)是相同的。

3.1.包格式

   MPPE包格式如下所示。字段從左至右進(jìn)行傳輸。

       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 協(xié)議             |A|B|C|D|        附加計(jì)數(shù)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       加密的數(shù)據(jù)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    ppp協(xié)議

    PPP協(xié)議字段在點(diǎn)到點(diǎn)協(xié)議封裝[1]中描述。
    當(dāng)MPPE由PPP壓縮控制協(xié)議成功協(xié)商后，該字段的值為0x00FD。當(dāng)協(xié)議-字段-壓縮協(xié)商后，這個(gè)值可以被壓縮。

    位A

    該位表明加密表在包產(chǎn)生之前初始化。在解密包之前，接收端必須用當(dāng)前的會(huì)話密鑰再初始化它的表。在本文檔中，該位被稱為FLUSHED位。如果無狀態(tài)選項(xiàng)已經(jīng)被協(xié)商，該位必須在每個(gè)加密包中設(shè)置。要注意MPPC和MPPE都識(shí)別FLUSHED位；因此，如果無狀態(tài)選項(xiàng)被協(xié)商，那么它同時(shí)適合與MPPC和MPPE。

    位B

    在MPPE中，該位沒有任何意義。

    位C

    在MPPE中，該位沒有任何意義。

    位D

    該位被設(shè)為1表明包被加密。該位被設(shè)為0表明這個(gè)包沒有被加密。

    附加計(jì)數(shù)

    附加計(jì)數(shù)被用來保證包按正確次序發(fā)送，而且沒有包被丟棄。它是一個(gè)單項(xiàng)增加的計(jì)數(shù)器，每發(fā)送一個(gè)包就增加1。當(dāng)計(jì)數(shù)值到達(dá)4095(0x0FFF)時(shí)，被重置為0。

    加密的數(shù)據(jù)

    加密數(shù)據(jù)從協(xié)議字段開始。例如，一個(gè)IP信息包(0x0021后面是一個(gè)IP報(bào)頭)，MPPE處理程序便會(huì)首先加密協(xié)議字段然后加密IP報(bào)頭。
    如果包包含頭壓縮，MPPE處理程序在頭壓縮完成之后被應(yīng)用并且也必須被用于壓縮的頭部。例如，如果一個(gè)包包含協(xié)議類型0x002D(一個(gè)壓縮的TCP/IP頭)，MPPE處理程序便會(huì)首先加密0x002D然后加密壓縮的Van-Jacobsen TCP/IP頭。

    實(shí)現(xiàn)注意事項(xiàng)

    如果MPPE和MPPC在相同的鏈路進(jìn)行協(xié)商，MPPE處理程序必須在MPPC處理程序之后由發(fā)送端激活，MPPE處理程序必須在MPPC處理程序以前由接收端激活。

4. 初始會(huì)話密鑰

就當(dāng)前的實(shí)現(xiàn)而言，初始會(huì)話密鑰源自對(duì)等端的信任書；然而，其他的方法也是可能的。   例如，一些認(rèn)證方法(如Kerberos[8]和TLS[9])作為認(rèn)證的附加效果產(chǎn)生會(huì)話密鑰；這些密鑰在將來可能會(huì)被MPPE使用。為此，用來生成初始MPPE會(huì)話密鑰的方法用分開的文檔描述。