rfc2409.txt

很多RFC的中文文档

   
	另外，IKE的实现必须支持3DES加密；用Tiger ([TIGER])作为hash；数字签名标准，RSA[RSA]，
使用RSA公共密钥加密的签名和验证；以及使用组2进行MODP。IKE实现可以支持在附录A中
定义的其它的加密算法，并且可以支持ECP和EC2N组。
   
	当实现了IETF IPsec DOI[Pip97]时，IKE必须实现以上描述的模式。其它DOI也可使用这里描
述的模式。
5.交换
	有两中基本方法可以用来建立经过验证密钥交换：主模式和积极模式。它们都通过短暂的
Diffie-Hellman交换来产生经过验证的密钥材料。主模式必须要实现；积极模式最好也实现。另外，
作为产生新密钥材料和协商非ISAKMP安全服务机制的快速模式也必须要实现。另外，作为定义
Diffie-Hellman交换私有组机制的新组模式应该要实现。实现中不能在交换正在进行时改变交换类
型。
  
	交换遵从标准ISAKMP负载语法，属性编码，消息的超时和重传，以及信息消息——例如，当
一个提议未被接时，或者签名验证或解密失败时，一个通知响应就被发送，等等。
   
	在第一阶段交换中，SA负载必须先于任何其它的负载。除了另外的通知表明在任何消息的
ISAKMP负载中没有需要特定顺序的需求。
   
	不论在第一阶段还是第二阶段中，在KE负载中传递的Diffie-Hellman公共值必须在必要时用零
填充，且长度必须为协商Diffie-Hellman组所需要的长度。
   
	当前时间（nonce）负载的长度必须在8到256个字节之间。
   
	主模式是ISAKMP身份保护交换的实现：头两个消息协商策略；下两个消息交换Diffie-Hellman
的公共值和必要的辅助数据（例如：当前时间（nonce））；最后的两个消息验证Diffie-Hellman交换。
作为初始ISAKMP交换的验证方法的协商影响负载的组成，而不是它们的目的。主模式的XCHG就
是ISAKMP身份保护。
   
类似的，积极模式是ISAKMP积极交换的实现。头两个消息协商策略，交换Diffie-Hellman公
共值以及必要的辅助数据，还有身份。另外，第二个消息还要对响应者进行验证。第三个消息对发
起者进行验证，并提供参与交换的证据。积极模式的XCHG就是ISAKMP的积极交换。在ISAKMP 
SA的保护下，如果需要，最后的消息可以不发送，这样允许每一方延迟求幂的运算，直到这次交换
完成以后再运算。积极模式的图示中显示最后的负载以明文发送，这不是必须的。

  	IKE的交换并不是open ended，而是有固定数目的消息。证书请求负载的回执不能扩展传输或
期待的消息的数目。
   
	积极模式在安全联盟协商中有一定的局限性。因为在消息构建请求中，Diffie-Hellman交换所需
要的组不能被协商。另外，不同的验证方法可能进一步限制属性的协商。例如，利用公共密钥加密
的验证就不能被协商，同时，当使用修改过的公共密钥加密方法来验证时，密码和hash又不能被协
商。当要利用IKE能协商大量属性的能力时，就需要使用主模式了。
   
	快速模式和新组模式在ISAKMP中没有与之对应的。它们的XCHG的值在附录A中定义。
  
	主模式，积极模式，以及快速模式进行安全联盟的协商。安全联盟的建议（offer）采取下列形
式：转换（transform）负载封装在提议（proposal）负载中，而提议负载又封装在安全联盟（SA）负
载中。第一阶段交换（主模式和积极模式）中如果多个建议提出，则必须采取下列形式：多个转换
（transform）负载封装在一个提议（proposal）负载中，然后它们又封装在一个SA负载中。对第一
阶段交换可以换种方式来表述：在单个SA负载中，不能有多个提议负载，同时，也不允许有多个
SA负载。本文档并不禁止在第二阶段的交换中出现这些形式。
   
	本来发起者发送给响应者的建议（offer）的数量是没有限制的，但出于性能考虑，实现中可以
选择限制将进行检查的建议（offer）的数量。
   
	在安全联盟的协商中，发起者向响应者提出可能的安全联盟的建议（offer）。响应者不能修改任
何建议的属性，除了属性的编码（参看附录A）。如果交换的发起者注意到属性值被修改了，或者有
属性在建议中被增加或删除了，则这个响应必须废弃。
   
	主模式或积极模式中都允许四种不同的验证方法——数字签名，公共密钥加密的两种验证形式，
或者共享密钥。对每种验证方法要分别计算SKEYID值。
     
	对于数字签名：SKEYID = prf(Ni_b | Nr_b, g^xy)
	对于公共密钥加密：SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)
	对于共享密钥：SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
   
不论是主模式还是积极模式，结果都是产生三组经过验证的密钥材料：
      SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
以及达成了用于保护通信的一致的策略。上面的值0，1，2由单个字节的值来代表。用于加密的密
钥值根据具体的算法（参看附录B）从SKEYID_e中衍生出来。
  
    为了验证交换中的双方，协议的发起者产生HASH_I，响应者产生HASH_R，其中：
    HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
    HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
 
	对于使用数字签名的验证，HASH_I和HASH_R是经过签名并效验的；对于使用公共密钥加密
验证或共享密钥的验证，HASH_I和HASH_R直接验证交换。整个ID负载（包括ID类型，端口，
协议，但通用报头除外）被hash计算进HASH_I和HASH_R。
   
	正如上面提到的，所协商的验证方法影响第一阶段模式的消息内容和使用，但不影响它们的目
的。当使用公共密钥来验证时，第一阶段的交换可以使用签名或使用公钥加密（如果算法支持）来
完成。下面是使用不同的验证选项的第一阶段交换。
5.1 使用签名来验证的IKE第一阶段
   
使用签名，在第二个传输往返中交换的辅助信息是当前时间（nonce）；通过对相互可以得到的
hash值进行签名来对交换进行验证。使用签名验证的主模式描述如下：
        发起者                          响应者
       -----------                        -----------
        HDR, SA                     -->
                                    <--    HDR, SA
        HDR, KE, Ni                 -->
                                    <--    HDR, KE, Nr
        HDR*, IDii, [ CERT, ] SIG_I -->
                                    <--    HDR*, IDir, [ CERT, ] SIG_R
和ISAKMP相关联的带签名的积极模式描述如下：
        发起者                         响应者
       -----------                        -----------
        HDR, SA, KE, Ni, IDii       -->
                                    <--    HDR, SA, KE, Nr, IDir,
                                                [ CERT, ] SIG_R
        HDR, [ CERT, ] SIG_I        -->

   
	两种模式中，签名的数据——SIG_I或SIG_R是协商的数字签名算法分别应用到HASH_I或
HASH_R所产生的结果。
   
	总的来说，就象上面说明的一样，签名使用协商的prf，或协商的HMAC hash函数（如果没有
协商prf）来对HASH_I和HASH_R签名。但是，如果签名算法绑定于特定的hash算法（如DSS只
定义使用SHA 160位的输出），则签名的构建会有不同。在这种情况下，签名仍然将象上面一样覆
盖HASH_I和HASH_R，但使用和签名方法向关联的HMAC hash算法。协商的prf和hash函数将
被用作其它指定的伪随机函数。
  
	既然使用的hash算法已知，就没有必要将它的OID也编码到签名之中。另外，在PKCS#1的
RSA签名中使用的OID和本文档中使用的OID之间没有关联。所以，RSA签名在PKCS#1格式中
必须被作为私有密钥加密来编码，而不是作为PKCS#1格式（它包括hash算法的OID）中的签名。
DSS签名必须作为r后跟s来编码。
  
	一或多个证书负载在传递中是可选的。
5.2	使用公共密钥加密的第一阶段验证
  
	使用公共密钥加密来验证交换，交换的辅助信息是加密的当前时间（nonce）。每一方重新构建
hash（如果另一方能解密当前时间（nonce））的能力就验证了交换。
   
	要执行公钥加密，发起者必须已经拥有响应者的公钥。当响应者有多个公钥时，发起者用来加
密辅助信息的证书的hash值也作为第三个消息传递。通过这种方式，响应者可以确定使用哪一个对
应的私钥来解密加密了的负载，同时也保持了身份保护功能。
   
	除了当前时间（nonce）外，双方的身份（IDii和IDir）也使用对方的公钥进行加密。如果验证
方法是公钥加密，则当前时间（nonce）和身份负载必须使用对方的公钥加密。只有负载的数据部分
进行了加密，而负载的报头仍为明文形式。
  
当使用加密作为验证时，主模式定义如下：
        发起者                       响应者
       -----------                      -----------
        HDR, SA                   -->
                                  <--    HDR, SA
        HDR, KE, [ HASH(1), ]
          <IDii_b>PubKey_r,
            <Ni_b>PubKey_r        -->
                                         HDR, KE, <IDir_b>PubKey_i,
                                  <--            <Nr_b>PubKey_i
        HDR*, HASH_I              -->
                                  <--    HDR*, HASH_R
积极模式使用加密作为验证的描述如下：
        发起者                       响应者
       -----------                      -----------
        HDR, SA, [ HASH(1),] KE,
          <IDii_b>Pubkey_r,
           <Ni_b>Pubkey_r         -->
                                         HDR, SA, KE, <IDir_b>PubKey_i,
                                  <--         <Nr_b>PubKey_i, HASH_R
        HDR, HASH_I               -->

   
其中HASH（1）是发起者用于加密当前时间（nonce）和身份的证书的hash（使用协商的hash
函数）。
  
	RSA加密必须被编码进PKCS#1格式中。当只有ID和当前时间（nonce）负载的数据部分要加
密时，加密的数据前必须有一个有效的ISAKMP通用报头。负载的长度是整个加密负载加上报头的
长度。PKCS#1编码可以不用解密而确定明文负载的实际长度。
   
	使用加密来验证提供了可信的可拒绝交换。没有证据（使用数字签名）表明通信曾经发生过，
因为每一方都可以完全重新构建交换的两方。另外，秘密的产生也增加了安全，因为袭击者不仅不
得不破解Diffie-Hellman交换，还要破解RSA加密。这种交换由[SKEME]提出。
   
	注意，与其它的验证方法不一样，公钥加密验证允许积极模式有身份保护。
5.3	使用修改过的公钥加密模式来进行第一阶段的验证
   
	使用公钥加密来进行验证比签名验证（参看5.2节）有更大的优点。不幸的是，这需要4个公
钥操作为代价——两个公钥加密和两个私钥解密。而修改过的验证模式保持了使用公钥加密来验证
的优点，但只需要一半的公钥操作。
   
	在这种模式中，当前时间（nonce）仍然使用双方的公钥进行加密，但双方的身份（以及证书）
使用协商的对称加密算法（从SA负载中获得）来加密，其密钥是从当前时间（nonce）中衍生而来。
这种解决方案增加最少的复杂性和状态，而在每一方节省了两个公钥操作。另外，密钥交换（KE）
负载也使用同一个衍生的密钥进行加密。这为对Diffie-Hellman交换进行密码分析而提供了额外的保
护。
   
	使用公钥加密的验证方法（5.2节 ），如果响应者有多个证书包含可用的公钥（例如，如果证书
不只是用于签名，也不受证书限制或算法限制），可以发送HASH负载来标识证书。如果HASH负
载被发送，他必须是第二个消息交换的第一个负载，同时必须后跟加密的当前时间（nonce）。如果
HASH负载没有发送，第二个消息交换的第一个负载必须是加密的当前时间（nonce）。另外，发起
者可以可选的发送证书负载，以提供一个公钥给响应者进行响应时使用。
   
当使用修改过的加密模式来验证时，主模式定义如下：
        发起者                       响应者
       -----------                      -----------
        HDR, SA                   -->
                                  <--    HDR, SA
        HDR, [ HASH(1), ]
          <Ni_b>Pubkey_r,
          <KE_b>Ke_i,
          <IDii_b>Ke_i,
          [<<Cert-I_b>Ke_i]       -->
                                         HDR, <Nr_b>PubKey_i,
                                              <KE_b>Ke_r,
                                  <--         <IDir_b>Ke_r,
        HDR*, HASH_I              -->
                                  <--    HDR*, HASH_R

  积极模式使用修改的加密方法来验证的描述如下：
        发起者                       响应者
       -----------                      -----------
        HDR, SA, [ HASH(1),]
          <Ni_b>Pubkey_r,
          <KE_b>Ke_i, <IDii_b>Ke_i
          [, <Cert-I_b>Ke_i ]     -->
                                         HDR, SA, <Nr_b>PubKey_i,
                                              <KE_b>Ke_r, <IDir_b>Ke_r,
                                  <--         HASH_R
        HDR, HASH_I               -->
	其中HASH（1）和5.2节相同。Ke_i和Ke_r是在SA负载交换中协商的对称加密算法的密钥。
只有负载的数据部分加密（公钥和对称密钥操作中都一样），通用的负载的报头保持明文形式。包含