RFC2409密钥交换.docx
《RFC2409密钥交换.docx》由会员分享，可在线阅读，更多相关《RFC2409密钥交换.docx（38页珍藏版）》请在冰豆网上搜索。
RFC2409密钥交换
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
sword（swordzxl1025@）
译文发布时间：
2001-7-25
版权：
本中文文档版权归中国互动出版网所有。
可用于非商业用途转载，但需保留本文档版权信息。
NetworkWorkingGroup
RequestforComments:
2409
Category:
StandardsTrack
D.Harkins
D.Carrel
ciscoSystems
November1998
本备忘录的现状
本文档指定了一个Internet团体的Internet标准协议，并请求讨论和建议以作改进。
请参考当前版本的“Internet官方协议标准”（STD1），查看本协议的标准化进程和现状。
本文档的分发不受限制。
1.摘要
ISAKMP（[MSST98]）中对验证和密钥交换提出了结构框架，但没有具体定义。
ISAKM被设计用来独立的进行密钥交换，即被设计用于支持多种不同的密钥交换。
Oakley（[Orm96]）中描述了一系列被称为“模式”的密钥交换，并详述了每一种提供的服务（如密钥的完全后继保密（perfectforwardsecrecy），身份保护，以及验证）。
SKEME（[SKEME]）中描述了一种提供匿名，否认，和快速密钥更新的通用密钥交换技术。
本文档将描述使用部分Oakley，部分SKEME，并结合ISAKMP的一种协议，它使用ISAKMP来得到已验证的用于生成密钥和其它安全联盟（如AH，ESP）中用于IETEIPsecDOI的材料。
2.讨论
本文档描述了一种混合协议。
目的是用于以一种保护的方式来协商安全联盟并为它提供经验证过的密钥生成材料。
本文档中实现的过程可用于协商虚拟专用网（VPN），也可用于远程用户（其IP地址不需要事先知道）从远程访问安全主机或网络。
支持客户协商。
客户模式即为协商双方不是安全联盟发起的两个终点。
当使用客户模式时，端点处双方的身份是隐藏的。
本协议并没有实现整个Oakley协议，只实现了满足目的所需要的部分子集。
它并没有声称与整个Oakley协议相一致或兼容，也并不依靠Oakley协议。
同样，本协议没有实现整个的SKEME协议，只使用了用于验证的公钥加密的方法和使用当前时间（nonce）交换来快速重建密钥的思路。
本协议并不依靠SKEME协议。
3.术语和定义
3.1必要的术语
本文档中出现的关键字“MUST”，“MUSTNOT”，“REQUIRED”，“SHOULD”，“SHOULDNOT”以及“MAY”的解释在[Bra97]中描述。
3.2符号
下列的符号在整个文档中都使用。
∙HDR是ISAKMP的报头，它的交换类型是模式。
当写成HDR*时，意味着负载加密。
∙SA是有一个或多个提议的SA协商负载。
发起方可能提供多个协商的提议；应答方只能用一个提议来回答。
∙
_b指明负载
数据部分（body）－不包括ISAKMP的通用vpayload负载。
∙SAi_b是SA负载的数据部分（除去ISAKMP通用报头）－也就是由发起者所提供的DOI、情况（situation）、所有的提议（proposal）、以及所有的变换（transform）。
∙CKY-I和CKY-R分别是ISAKMP报头中发起者和响应者的cookie。
∙g^xi和g^xr分别是Diffie-Hellman（[DH]）中发起者和响应者的公共值。
∙g^xy是Diffie-Hellman的共享秘密。
∙KE是包含了用于Diffie-Hellman交换的公共信息的密钥交换负载。
没有对KE负载的数据进行特殊的编码（如TLV）。
∙Nx是当前时间（nonce）负载；其中x可以是i和r，分别代表ISAKMP的发起者和响应者。
∙IDx是x的身份识别负载。
x可以是“ii”或“ir”，分别表示第一阶段协商中的ISAKMP发起者和响应者；也可以是“ui”或“ur”，分别表示第二阶段的用户发起者和响应者。
用于互联网DOI的ID负载格式在[Pip97]中定义。
∙SIG是数字签名负载。
签名的数据是特定于某种交换的。
CERT是证书负载。
∙HASH（以及衍生物，如HASH
（2）或HASH_I）是hash负载。
hash的内容是特定于验证方法的。
∙prf（key,msg）是key的伪随机函数－通常是key的hash函数－用于产生表现有伪随机性的确定的输出。
∙prf用于导出密钥和验证（即作为有密钥的MAC）。
（见[KBC96]）
∙SKEYID是从秘密材料中衍生出的字符串，只有某次交换中的活跃双方才知道。
∙SKEYID_e是ISAKMPSA用来保护消息的机密性的密钥材料。
∙SKEYID_a是ISAKMPSA用来验证消息所使用的密钥材料。
∙SKEYID_d是非ISAKMP安全联盟用来衍生出密钥所使用的密钥材料。
∙y表示“x”是由密钥“y”加密的。
∙-->表示“发起者到响应者”的通信（请求）。
∙<--表示“响应者到发起者”的通信（回答）。
∙|表示信息的串联－如X|Y表示X和Y是串联的。
∙[x]表示x是可选的。
∙消息加密（ISAKMP报头后标注有“*”号）必须紧接在ISAKMP报头后。
当通信是受保护的时候，所有ISAKMP报头后的负载必须要加密。
从SKEYID_e产生加密密钥的方法由各个算法定义。
3.3完全后继保密
在本文档中使用的完全后继保密（PFS）术语是和一个概念相关的，即限制单密钥只能访问到受本单密钥保护的数据。
要满足PFS，对于用来保护数据传输的已经存在的密钥来说，它就不能用于衍生出其它的密钥，如果用来保护数据传输的密钥是从其它密钥材料中衍生出来的，则这些材料就不能再用于衍生任何其它密钥。
在本协议中提供了密钥和身份的完全后继保密（5.5和8节）
3.4安全联盟
安全联盟（SA）是一组用来保护信息的策略和密钥。
在本协议中，ISAKMPSA是协商双方为保护之间的通信而使用的共享的策略和密钥。
4.简介
Oakley和SKEME各自定义了建立经过验证的密钥交换的方法。
其中包括负载的构建，信息负载的运送，它们被处理的顺序以及被使用的方法。
然而Oakley定义了“模式”，ISAKMP定义了“阶段”。
两者之间的关系非常直接，IKE描述了在两个阶段中进行的不同的、称为模式的交换。
第一阶段指两个ISAKMP实体建立一个安全、验证过的信道来进行通信。
这被称为ISAKMP安全联盟（SA）。
“主模式”和“积极模式”都能完成第一阶段的交换。
“主模式”和“积极模式”只能在第一阶段中使用。
第二阶段指协商代表服务的安全联盟，这些服务可以是IPsec或任何其它需要密钥材料以及/或者协商参数的服务。
“新组模式”并不真正在第一阶段或第二阶段中。
它紧接着第一阶段，用于建立可在以后协商中使用的新组。
“新组模式”只能在第一阶段之后使用。
ISAKMPSA是双向的，即一旦建立，任何一方都可以发起快速模式交换，信息交换，以及新组模式交换。
由ISAKMP基础文档可知，ISAKMPSA由发起者的cookie后跟响应者的cookie来标识——在第一阶段的交换中各方的角色决定了哪一个cookie是发起者的。
由第一阶段的交换所建立的cookie顺序继续用于标识ISAKMPSA，而不管快速模式、信息、新组交换的方向。
换句话来说，当ISAKMPSA的方向改变时，cookie不能交换位置。
由于使用ISAKMP阶段，实现中可以在需要时完成快速的密钥交换。
单个第一阶段协商可以用于多个第二阶段的协商。
而单个第二阶段协商可以请求多个安全联盟。
由于这种优化，实现中每个SA可以少于一个传输往返，以及少于一次DH求幂运算。
第一阶段中的“主模式”提供了身份保护。
当身份保护不必要时，可以使用“积极模式”以进一步减少传输往返。
下面的内容中包括了开发者对进行优化的提示。
同时必须注意当使用公共密钥加密来验证时，积极模式仍然提供身份保护。
本协议本身并没有定义自己的DOI。
在第一阶段中建立的ISAKMPSA可以使用非ISAKMP服务（如IETFIPSecDOI[Pip97]）的DOI和情形（situation）。
在这种情况下，实现中可以限制使用ISAKMPSA来建立具有相同DOI的服务SA。
另一种方法是使用DOI和情形（situation）为零值（参看[MSST98]中对这些域的描述）来建立ISAKMPSA，在这种情况下，实现中可以自由使用ISAKMPSA来为任何已定义的DOI建立安全服务。
如果使用DOI为零来建立第一阶段的SA，第一阶段中的标识负载的语法就在[MSST98]中定义，而不是从任何的DOI（如[Pip97]，它可能会进一步扩展标识的语法和语义）中定义。
IKE使用下面的属性，并且作为ISAKMP安全联盟的一部分来协商。
（这些属性只属于ISAKMP安全联盟，而不属于ISAKMP为所代表的服务进行协商而建立的任何安全联盟）：
∙加密算法
∙hash算法
∙验证方法
∙进行Diffie-Hellman操作的组的有关信息。
所有这些属性是强制性的且必须被协商的。
另外，可以可选的协商一个伪随机函数（“prf”）。
（当前本文档中还没有定义可协商的伪随机函数。
在双方都同意时可以私下使用属性值用于prf协商。
）如果没有协商“prf”，协商的HMAC（参看[KBC96]）的hash算法就作为伪随机函数。
其它非强制性的属性在附录A中定义。
选择的hash算法必须支持原始模式和HMAC模式。
Diffie-Hellman组必须使用一个已定义的组描述（第6节）来指定，或者定义一个组的全部属性（第5.6节）。
组属性（如组类型或素数——参看附录A）不能和以前定义的组（不论是保留的组描述，还是由新组模式交换后确定并建立的私下使用的描述）相关联。
IKE的实现必须支持以下的属性值：
∙使用弱、半弱密钥检查，且为CBC模式的DES[DES]。
（弱、半弱密钥参考[Sch96]，并在附录A中列出）。
密钥根据附录B进行衍生。
∙MD5[MD5]和SHA[SHA]。
∙通过共享密钥进行验证。
∙对缺省的组1进行MODP（参看下面内容）。
另外，IKE的实现必须支持3DES加密；用Tiger（[TIGER]）作为hash；数字签名标准，RSA[RSA]，使用RSA公共密钥加密的签名和验证；以及使用组2进行MODP。
IKE实现可以支持在附录A中定义的其它的加密算法，并且可以支持ECP和EC2N组。
当实现了IETFIPsecDOI[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的积极交换。
在ISAKMPSA的保护下，如果需要，最后的消息可以不发送，这样允许每一方延迟求幂的运算，直到这次交换完成以后再运算。
积极模式的图示中显示最后的负载以明文发送，这不是必须的。
IKE的交换并不是openended，而是有固定数目的消息。
证书请求负载的回执不能扩展传输或期待的消息的数目。
积极模式在安全联盟协商中有一定的局限性。
因为在消息构建请求中，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，或协商的HMAChash函数（如果没有协商prf）来对HASH_I和HASH_R签名。
但是，如果签名算法绑定于特定的hash算法（如DSS只定义使用SHA160位的输出），则签名的构建会有不同。
在这种情况下，签名仍然将象上面一样覆盖HASH_I和HASH_R，但使用和签名方法向关联的HMAChash算法。
协商的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）,]PubKey_r,PubKey_r
-->
<--
HDR,KE,PubKey_i,PubKey_i
HDR*,HASH_I
-->
<--
HDR*,HASH_R
积极模式使用加密作为验证的描述如下：
发起者
响应者
HDR,SA,[HASH
（1）,]KE,Pubkey_r,Pubkey_r
-->
HDR,SA,KE,PubKey_i,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）,]Pubkey_r,Ke_i,Ke_i,[<Ke_i]
-->
<--
HDR,PubKey_
升级会员 