ImageVerifierCode 换一换
格式:DOCX , 页数:52 ,大小:43.82KB ,
资源ID:20691894      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/20691894.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(Internet密钥交换IKE.docx)为本站会员(b****2)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

Internet密钥交换IKE.docx

1、Internet密钥交换IKE组织:中国互动出版网(http:/www.china-RFC文档中文翻译计划(http:/www.china-E-mail:ouyangchina-译者:sword (sword zxl1025)译文发布时间:2001-7-25版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。 Network Working Group D. HarkinsRequest for Comments: 2409 D. CarrelCategory: Standards Track cisco Systems November

2、 1998Internet密钥交换(IKE)(The Internet Key Exchange)本备忘录的现状 本文档指定了一个Internet 团体的Internet标准协议,并请求讨论和建议以作改进。请参考当前版本的“Internet官方协议标准”(STD 1),查看本协议的标准化进程和现状。本文档的分发不受限制。版权通告 Copyright (C) The Internet Society (1998)。保留所有的权利。目录 1.摘要 22.讨论 23.术语和定义 33.1必要的术语 33.2符号 33.3完全后继保密 43.4安全联盟 44.简介 55.交换 65.1 使用签名来验证

3、的IKE第一阶段 85.2 使用公共密钥加密的第一阶段验证 85.3 使用修改过的公钥加密模式来进行第一阶段的验证 105.4 使用共享密钥的第一阶段协商 115.5 第二阶段快速模式 125.6 新组模式 145.7 ISAKMP信息交换 156 Oakley组 156.1 第一个Oakley缺省组 156.2 第二个Oakley组 166.3 第三个Oakley组 166.4 第四个Oakley组 167. 完整IKE交换的负载爆炸 177.1 使用主模式的第一阶段 177.2 使用快速模式的第二阶段 188. 完全后继保密举例 2010.安全考虑 2111.IANA考虑 2211.1 属

4、性类 2211.2 加密算法类 2211.3 hash算法 2211.4 组描述和组类型 2311.5 存活期类型 2312. 鸣谢 2313.参考 23附录A 25属性分配号码 25属性种类 26种类值 26附录B 28作者地址 30作者的注释 30完全版权声明 311.摘要ISAKMP (MSST98)中对验证和密钥交换提出了结构框架,但没有具体定义。ISAKM被设计用来独立的进行密钥交换,即被设计用于支持多种不同的密钥交换。 Oakley (Orm96)中描述了一系列被称为“模式”的密钥交换,并详述了每一种提供的服务(如密钥的完全后继保密(perfect forward secrecy)

5、,身份保护,以及验证)。 SKEME (SKEME)中描述了一种提供匿名,否认,和快速密钥更新的通用密钥交换技术。本文档将描述使用部分Oakley,部分SKEME,并结合ISAKMP的一种协议,它使用ISAKMP来得到已验证的用于生成密钥和其它安全联盟(如AH,ESP)中用于IETE IPsec DOI的材料。2.讨论本文档描述了一种混合协议。目的是用于以一种保护的方式来协商安全联盟并为它提供经验证过的密钥生成材料。 本文档中实现的过程可用于协商虚拟专用网(VPN),也可用于远程用户(其IP地址不需要事先知道)从远程访问安全主机或网络。 支持客户协商。客户模式即为协商双方不是安全联盟发起的两个

6、终点。当使用客户模式时,端点处双方的身份是隐藏的。 本协议并没有实现整个Oakley协议,只实现了满足目的所需要的部分子集。它并没有声称与整个Oakley协议相一致或兼容,也并不依靠Oakley协议。同样,本协议没有实现整个的SKEME协议,只使用了用于验证的公钥加密的方法和使用当前时间(nonce)交换来快速重建密钥的思路。本协议并不依靠SKEME协议。3.术语和定义3.1必要的术语 本文档中出现的关键字“MUST”,“MUST NOT”,“REQUIRED”,“SHOULD”,“SHOULD NOT”以及“MAY”的解释在Bra97中描述。3.2符号下列的符号在整个文档中都使用。 HDR是

7、ISAKMP的报头,它的交换类型是模式。当写成HDR*时,意味着负载加密。 SA是有一个或多个提议的SA协商负载。发起方可能提供多个协商的提议;应答方只能用一个提议来回答。 _b指明负载数据部分(body)不包括ISAKMP的通用vpayload负载。 SAi_b是SA负载的数据部分(除去ISAKMP通用报头)也就是由发起者所提供的DOI、情况(situation)、所有的提议(proposal)、以及所有的变换(transform)。 CKY-I和CKY-R分别是ISAKMP报头中发起者和响应者的cookie。 gxi和gxr分别是Diffie-Hellman (DH)中发起者和响应者的公共

8、值。 gxy是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(以及衍生物,如HA

9、SH(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安全联盟用来衍生出密钥所使用的密钥材料。 y表示“x”是由密钥“y”加密的。-表示“发起者到响应者”

10、的通信(请求)。 两种模式中,签名的数据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算法已知,就没有必要将它的

11、OID也编码到签名之中。另外,在PKCS#1的RSA签名中使用的OID和本文档中使用的OID之间没有关联。所以,RSA签名在PKCS#1格式中必须被作为私有密钥加密来编码,而不是作为PKCS#1格式(它包括hash算法的OID)中的签名。DSS签名必须作为r后跟s来编码。 一或多个证书负载在传递中是可选的。5.2 使用公共密钥加密的第一阶段验证 使用公共密钥加密来验证交换,交换的辅助信息是加密的当前时间(nonce)。每一方重新构建hash(如果另一方能解密当前时间(nonce)的能力就验证了交换。 要执行公钥加密,发起者必须已经拥有响应者的公钥。当响应者有多个公钥时,发起者用来加密辅助信息的

12、证书的hash值也作为第三个消息传递。通过这种方式,响应者可以确定使用哪一个对应的私钥来解密加密了的负载,同时也保持了身份保护功能。 除了当前时间(nonce)外,双方的身份(IDii和IDir)也使用对方的公钥进行加密。如果验证方法是公钥加密,则当前时间(nonce)和身份负载必须使用对方的公钥加密。只有负载的数据部分进行了加密,而负载的报头仍为明文形式。 当使用加密作为验证时,主模式定义如下: 发起者 响应者 - - HDR, SA - - HDR, SA HDR, KE, HASH(1), PubKey_r, PubKey_r - HDR, KE, PubKey_i, - PubKey_

13、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加密。这

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1