rfc2409.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：sword (sword   [e-mail])
译文发布时间：2001-7-25
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本
文档的翻译及版权信息。



 
Network Working Group                                            D. Harkins
Request for Comments: 2409                                         D. Carrel
Category: Standards Track                                       cisco Systems
                                                           November 1998

Internet密钥交换（IKE）
（The Internet Key Exchange）
本备忘录的现状
	本文档指定了一个Internet 团体的Internet标准协议，并请求讨论和建议以作改进。请参考当前
版本的“Internet官方协议标准”（STD 1），查看本协议的标准化进程和现状。本文档的分发不受限
制。
版权通告
	Copyright (C) The Internet Society (1998)。保留所有的权利。

目录
   
1.摘要	2
2.讨论	2
3.术语和定义	3
3.1必要的术语	3
3.2符号	3
3.3完全后继保密	4
3.4安全联盟	4
4.简介	5
5.交换	6
5.1 使用签名来验证的IKE第一阶段	8
5.2	使用公共密钥加密的第一阶段验证	8
5.3	使用修改过的公钥加密模式来进行第一阶段的验证	10
5.4	使用共享密钥的第一阶段协商	11
5.5	第二阶段——快速模式	12
5.6	新组模式	14
5.7	ISAKMP信息交换	15
6	Oakley组	15
6.1	第一个Oakley缺省组	15
6.2	第二个Oakley组	16
6.3	第三个Oakley组	16
6.4	第四个Oakley组	16
7.	完整IKE交换的负载爆炸	17
7.1	使用主模式的第一阶段	17
7.2	使用快速模式的第二阶段	18
8.	完全后继保密举例	20
10.安全考虑	21
11.IANA考虑	22
11.1	属性类	22
11.2	加密算法类	22
11.3 hash算法	22
11.4	 组描述和组类型	23
11.5	 存活期类型	23
12.	鸣谢	23
13.参考	23
附录A	25
属性分配号码	25
属性种类	26
种类值	26
附录B	28
作者地址	30
作者的注释	30
完全版权声明	31


1.摘要
ISAKMP ([MSST98])中对验证和密钥交换提出了结构框架，但没有具体定义。ISAKM被设计用
来独立的进行密钥交换，即被设计用于支持多种不同的密钥交换。
   Oakley ([Orm96])中描述了一系列被称为“模式”的密钥交换，并详述了每一种提供的服务（如
密钥的完全后继保密（perfect forward secrecy），身份保护，以及验证）。
   SKEME ([SKEME])中描述了一种提供匿名，否认，和快速密钥更新的通用密钥交换技术。
本文档将描述使用部分Oakley，部分SKEME，并结合ISAKMP的一种协议，它使用ISAKMP来得
到已验证的用于生成密钥和其它安全联盟（如AH，ESP）中用于IETE IPsec DOI的材料。
2.讨论
本文档描述了一种混合协议。目的是用于以一种保护的方式来协商安全联盟并为它提供经验证
过的密钥生成材料。
   	本文档中实现的过程可用于协商虚拟专用网（VPN），也可用于远程用户（其IP地址不需要事
先知道）从远程访问安全主机或网络。
	支持客户协商。客户模式即为协商双方不是安全联盟发起的两个终点。当使用客户模式时，端
点处双方的身份是隐藏的。
	本协议并没有实现整个Oakley协议，只实现了满足目的所需要的部分子集。它并没有声称与整
个Oakley协议相一致或兼容，也并不依靠Oakley协议。
同样，本协议没有实现整个的SKEME协议，只使用了用于验证的公钥加密的方法和使用当前时间
（nonce）交换来快速重建密钥的思路。本协议并不依靠SKEME协议。
3.术语和定义
3.1必要的术语
	本文档中出现的关键字“MUST”，“MUST NOT”，“REQUIRED”，“SHOULD”，“SHOULD 
NOT”以及“MAY”的解释在[Bra97]中描述。
3.2符号
下列的符号在整个文档中都使用。

	HDR是ISAKMP的报头，它的交换类型是模式。当写成HDR*时，意味着负载加密。
	
SA是有一个或多个提议的SA协商负载。发起方可能提供多个协商的提议；应答方只能用一个
提议来回答。
	
<P>_b指明负载<P>数据部分（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是ISAKMP SA用来保护消息的机密性的密钥材料。

	SKEYID_a是ISAKMP SA用来验证消息所使用的密钥材料。

	SKEYID_d是非ISAKMP安全联盟用来衍生出密钥所使用的密钥材料。

	<x>y表示“x”是由密钥“y”加密的。

-->表示“发起者到响应者”的通信（请求）。

	<--表示“响应者到发起者”的通信（回答）。

	| 表示信息的串联——如X | Y表示X和Y是串联的。

	[x]表示x是可选的。

	消息加密（ISAKMP报头后标注有“*”号）必须紧接在ISAKMP报头后。当通信是受保护的
时候，所有ISAKMP报头后的负载必须要加密。从SKEYID_e产生加密密钥的方法由各个算法定义。

3.3完全后继保密
  
	在本文档中使用的完全后继保密（PFS）术语是和一个概念相关的，即限制单密钥只能访问到
受本单密钥保护的数据。要满足PFS，对于用来保护数据传输的已经存在的密钥来说，它就不能用
于衍生出其它的密钥，如果用来保护数据传输的密钥是从其它密钥材料中衍生出来的，则这些材料
就不能再用于衍生任何其它密钥。
    在本协议中提供了密钥和身份的完全后继保密（5.5和 8 节）
3.4安全联盟
  	安全联盟（SA）是一组用来保护信息的策略和密钥。在本协议中，ISAKMP SA是协商双方为
保护之间的通信而使用的共享的策略和密钥。
4.简介
	Oakley和SKEME各自定义了建立经过验证的密钥交换的方法。其中包括负载的构建，信息负
载的运送，它们被处理的顺序以及被使用的方法。
    然而Oakley定义了“模式”， ISAKMP定义了“阶段”。两者之间的关系非常直接，IKE描述
了在两个阶段中进行的不同的、称为模式的交换。
   	第一阶段指两个ISAKMP实体建立一个安全、验证过的信道来进行通信。这被称为ISAKMP安
全联盟（SA）。“主模式”和“积极模式”都能完成第一阶段的交换。“主模式”和“积极模式”只
能在第一阶段中使用。
   	第二阶段指协商代表服务的安全联盟，这些服务可以是IPsec或任何其它需要密钥材料以及/或
者协商参数的服务。
	“新组模式”并不真正在第一阶段或第二阶段中。它紧接着第一阶段，用于建立可在以后协商
中使用的新组。“新组模式”只能在第一阶段之后使用。
   	ISAKMP SA是双向的，即一旦建立，任何一方都可以发起快速模式交换，信息交换，以及新组
模式交换。由ISAKMP基础文档可知，ISAKMP SA由发起者的cookie后跟响应者的cookie来标识
——在第一阶段的交换中各方的角色决定了哪一个cookie是发起者的。由第一阶段的交换所建立的
cookie顺序继续用于标识ISAKMP SA，而不管快速模式、信息、新组交换的方向。换句话来说，当
ISAKMP SA的方向改变时，cookie不能交换位置。
   由于使用ISAKMP阶段，实现中可以在需要时完成快速的密钥交换。单个第一阶段协商可以用
于多个第二阶段的协商。而单个第二阶段协商可以请求多个安全联盟。由于这种优化，实现中每个
SA可以少于一个传输往返，以及少于一次DH求幂运算。第一阶段中的“主模式”提供了身份保护。
当身份保护不必要时，可以使用“积极模式”以进一步减少传输往返。下面的内容中包括了开发者
对进行优化的提示。同时必须注意当使用公共密钥加密来验证时，积极模式仍然提供身份保护。
	本协议本身并没有定义自己的DOI。在第一阶段中建立的ISAKMP SA可以使用非ISAKMP服
务（如IETF IPSec DOI [Pip97]）的DOI和情形（situation）。在这种情况下，实现中可以限制使用
ISAKMP SA来建立具有相同DOI的服务SA。另一种方法是使用DOI和情形（situation）为零值（参
看[MSST98]中对这些域的描述）来建立ISAKMP SA，在这种情况下，实现中可以自由使用ISAKMP 
SA来为任何已定义的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（参看下面内容）。