rfc3078.txt

很多RFC的中文文档

5. 使用会话密钥初始化RC4

    一旦初始会话密钥话生成，RC4环境将进行如下初始化∶
  rc4_key ( RC4Key, Length_Of_Key, Initial_Session_Key)
6. 加密数据

初始化后，数据使用下列函数加密并且随CCP和MPPE头发送。
    EncryptedData = rc4 ( RC4Key, Length_Of_Data, Data)
7. 改变密钥
7.1.无状态方式密钥的改变
    如果无状态加密已经被协商，会话密钥随着附加计数的变化而变化；即，每个包都进行变化。在无状态方式下，发送端必须在加密和发送每个包以前变化它的密钥，接收端必须在收到每个包之后，在解密以前变化它的密钥(参见下面的“同步”)。

7.2.状态方式密钥变化
如果状态加密已经协商，发送端必须在加密和发送任何低八位字节的附加计数等于0xFF的包(“标记”包)以前变化它的密钥，接收端必须在收到一个“标记”包之后，在解密以前变化它的密钥(参见下面的“同步”)。

7.3. MPPE密钥更换算法
    下列方法被用来变化密钥∶

/ * 
* 40位密钥的SessionKeyLength为8，128位密钥为16。
* 
*在第一次要求进行会话时的StartKey与SessionKey相同。
* /
      
void
      GetNewKeyFromSHA(
      IN  unsigned char *StartKey,
      IN  unsigned char *SessionKey,
      IN  unsigned long SessionKeyLength
      OUT unsigned char *InterimKey )
      {
         unsigned char  Digest[20];

         ZeroMemory(Digest, 20);

/*
*SHAInit(), SHAUpdate()和SHAFinal() 
*是安全的散列算法[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);
      }

RC4表使用新创的临时的密钥再初始化∶
    rc4_key(RC4Key, Length_Of_Key, InterimKey)

最后，临时密钥使用新表加密产生一个新的会话密钥。
    SessionKey = rc4( RC4Key, Length_Of_Key, InterimKey)

40位会话密钥的最高位的3个八位字节的新的会话密钥分别被设为0xD1, 0x26和0x9E；56位密钥的最高的八位字节被设为0xD1。
最后，RC4表使用新的话路密钥再初始化∶
    rc4_key ( RC4Key, Length_Of_Key, SessionKey)
8. 同步

包可能在传输期间丢失。 以下节描述了无状态和状态方式下的同步情况。
8.1.无状态同步

如果无状态加密法已经协商并且在收到的包中的附加计数值(C1)大于上次收到的包中的附加计数(C2)，为了保证接收端的会话密钥与发送端的会话密钥同步，必须在解密包以前执行N=C1- C2密钥变化操作。正常地，N值应为1；然而，如果介于其间的包已经丢失，N值可能大于1。例如，如果C1=5而C2=2，那么N=3，就需要对密钥进行更改。
如果无状态加密被协商，FLUSHED位在每个包中被设置，那么CCP重置-请求包的传输在同步方式下就不需要了。
8.2.状态同步
如果状态加密已经被协商，发送端必须在加密和发送任何低八位字节的附加计数等于0xFF的包(“标记”包)之前变化它的密钥，接收端必须在收到一个“标记”包之后，在解密以前变化它的密钥。然而，“标记”包可能丢失。 如果发生这种情况，在收到包的低八位字节的附加计数值小于在此前最后收到的包。在这种情况下，接收端在解密重新收到的包以前必须执行密钥变换(因为发送端将已经在发送包以前变化了它的密钥)，然后发送一个CCP重置-请求包(见下文)。有可能256个或以上的连续的包丢失；接收端应该发现这个情况并且执行以与发送端再同步所需要的相应数的密钥更换。
如果在使用状态加密时包丢失，那么接收端必须丢弃包并且发送一个没有数据的CCP重置-请求包。在发送CCP重置-请求包之后,接收端应该静静地丢弃收到的全部的包直到一个具有FLUSHED位的包被收到。接收有FLUSHED位的包时，接收端必须设置它的附加计数值为接到的包的值以便使包和再初始化它的RC4表使用当前的会话密钥：
    rc4_key( RC4Key, Length_Of_Key, SessionKey)

当发送端接收到一个CCP重置-请求包时，它必须使用相同的方法再初始化自己的RC4表，并且在下一个发送的包中设置FLUSHED位。 这样就在没有CCP重置-确认包的情况下完成了同步。
9. 安全性考虑
因为采用RC4表在状态同步期间重新初始化的方法，有可能两个包使用相同的密钥加密。因此,状态方式不应该被用于有损耗的网络环境(例如,在Internet上的两个管道层)。
由于MPPE协商不是被完全保护的,一个活动的攻击者可以通过变更CCP配置选择包支持的位数字段来改变使用的密钥的强度。然而，攻击的影响可以通过适当的对等配置减到最低程度。
在MPPE协商完成前对等端不能传送用户数据。
有可能一个活动的攻击者变更包的附加计数值，导致对端之间不同步。
一个活动的denial-of-service攻击可以通过对MPPE包头中的‘D’位的值的转化来进行测定。
参考
   [1]  Simpson, W., Editor, "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

   [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]  "Secure Hash Standard", Federal Information Processing Standards
        Publication 180-1, National Institute of Standards and
        Technology, April 1995.

   [8]  Kohl, J. and C. Neuman "The Kerberos Network Authentication
        System (V5)", RFC 1510, September 1993.

   [9]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

   [10] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
        1994.
鸣谢
感谢Anthony Bell, Richard B. Ward, Terence Spies和Thomas Dimitri，以及全部微软公司员工对MPPE的设计和发展所作的重要地贡献。
还要感谢Robert Friend, Joe Davies, Jody Terrill, Archie Cobbs, Mark Deuser,和Jeff Haag所提出的有益的意见。
作者地址
   对本备忘录提出的疑问可以写信到：

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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

   Glen Zorn
   cisco Systems
   500 108th Avenue N.E.
   Suite 500
   Bellevue, Washington 98004
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
版权声明
   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   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.

致谢
   Funding for the RFC Editor function is currently provided by the Internet Society.
RFC3078 Microsoft Point-To-Point Encryption (MPPE) Protocol  RFC3078微软点到点加密(MPPE)协议




1
RFC文档中文翻译计划