神马文学网ipsec密钥交换
来源：百度文库 编辑：神马文学网 时间：2024/07/06 21:10:20
IPsec SA creation steps [zz]
2008-07-30 17:53
转载于 "阿太 Never 的专栏"
IPsec SA creation steps
There are two steps on the IPsec SA creation, phase 1 is to creat IKE-SA, and phase 2 is to creat IPSEC-SA, the phase2 will be protected by phase 1. phase 1 creat a security tunnel to protect phase2.
step 1: creat IKE-SA, there are two modes on this step, the major is main mode, which including six messages;
1,&2, to negotiate the security policy, 1,initiator send all type policys supported to remote, and if remote search one of them which it support too, it will respone to initiator;
including Authentication method: psk or md5; hash- algorithm : md5 or sha; encryption algorithm :des or 3des ; sa life time (duration) x seconds;
3&4 , to exchange the DH and key, and creat key;
5&6, those two messages had been protected by key_id, to authentication each other;
step2 : craet IPSEC-SA;
1, negotiate the IPSEC-protocol:esp or ah; ipsec-mode:tunnel or transport; hash-algorithm: md5 or sha;
2, ack and ack too .
第一阶段
有主模式和积极模式2种
注意!!!只有remote vpn和Easy vpn是积极模式的,其他都是用主模式来协商的
让IKE对等体彼此验证对方并确定会话密钥,这个阶段永DH进行密钥交换,创建完IKE SA后,所有后续的协商都将通过加密合完整性检查来保护
phase 1帮助在对等体之间创建了一条安全通道,使后面的phase 2过程协商受到安全保护
第二阶段
快速模式
协商IPSEC SA使用的安全参数,创建IPSEC SA,使用AH或ESP来加密IP数据流
详细过程主模式协商
IKE phase 1在IPSEC对等体间交换6条消息,这些消息的具体格式取决于使用的对等体认证方法
一,使用预共享密钥进行验证的主模式(6条)
协商过程使用ISAKMP消息格式来传递(UDP 500)
第一阶段
准备工作
在前2条消息发送以前,发送者和接受者必须先计算出各自的cookie(可以防重放和DOS攻击),这些cookie用于标识每个单独的协商交换消息
cookie ---RFC建议将源目IP,源目端口,本地生成的随机数,日期和时间进行散列操作.cookie成为留在IKE协商中交换信息的唯一标识,实际上 cookie是用来防止DOS攻击的，它把和其他设备建立IPSEC所需要的连接信息不是以缓存的形式保存在路由器里，而是把这些信息HASH成个 cookie值
1&2消息
消息1---发送方向对等体发送一条包含一组或多组策略提议,在策略提议中包括5元组(加密算法,散列算法,DH,认证方法,IKE SA寿命)
1．策略协商，在这一步中，就四个强制性参数值进行协商：
1）加密算法：选择DES或3DES
2）hash算法：选择MD5或SHA
3）认证方法：选择证书认证、预置共享密钥认证或Kerberos v5认证
4）Diffie-Hellman组的选择
消息2---接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应
注意!!!发起者会将它的所有策略发送给接受者,接受者则在自己的策略中寻找与之匹配的策略(对比顺序从优先级号小的到大的)（默认策略实际就是个模版没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）
在1&2消息中报错可能出现的原因
1，peer路由不通
2，crypto iskmp key没有设置
3，一阶段的策略不匹配
3&4消息
这2条消息,用于交换DH的公开信息和随机数
两个对等体根据DH的公开信息都算出了双方相等的密植后,两个nonce连通预共享密钥生成第一个skeyID
随后便根据SKEY__ID来推算出其他几个skeyID
skeyID_d---用来协商出后续IPSEC SA加密使用的密钥的
skeyID_a---为后续的IKE消息协商以及IPSEC SA协商进行完整性检查(HMAC中的密钥)
skeyID_e---为后续的IKE消息协商以及IPSEC SA协商进行加密
5&6消息
这2条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的
为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时由于ID还没到,彼此先用HASH来彼此验证对方)
HASH
2008-07-30 17:53
转载于 "阿太 Never 的专栏"
IPsec SA creation steps
There are two steps on the IPsec SA creation, phase 1 is to creat IKE-SA, and phase 2 is to creat IPSEC-SA, the phase2 will be protected by phase 1. phase 1 creat a security tunnel to protect phase2.
step 1: creat IKE-SA, there are two modes on this step, the major is main mode, which including six messages;
1,&2, to negotiate the security policy, 1,initiator send all type policys supported to remote, and if remote search one of them which it support too, it will respone to initiator;
including Authentication method: psk or md5; hash- algorithm : md5 or sha; encryption algorithm :des or 3des ; sa life time (duration) x seconds;
3&4 , to exchange the DH and key, and creat key;
5&6, those two messages had been protected by key_id, to authentication each other;
step2 : craet IPSEC-SA;
1, negotiate the IPSEC-protocol:esp or ah; ipsec-mode:tunnel or transport; hash-algorithm: md5 or sha;
2, ack and ack too .
第一阶段
有主模式和积极模式2种
注意!!!只有remote vpn和Easy vpn是积极模式的,其他都是用主模式来协商的
让IKE对等体彼此验证对方并确定会话密钥,这个阶段永DH进行密钥交换,创建完IKE SA后,所有后续的协商都将通过加密合完整性检查来保护
phase 1帮助在对等体之间创建了一条安全通道,使后面的phase 2过程协商受到安全保护
第二阶段
快速模式
协商IPSEC SA使用的安全参数,创建IPSEC SA,使用AH或ESP来加密IP数据流
详细过程主模式协商
IKE phase 1在IPSEC对等体间交换6条消息,这些消息的具体格式取决于使用的对等体认证方法
一,使用预共享密钥进行验证的主模式(6条)
协商过程使用ISAKMP消息格式来传递(UDP 500)
第一阶段
准备工作
在前2条消息发送以前,发送者和接受者必须先计算出各自的cookie(可以防重放和DOS攻击),这些cookie用于标识每个单独的协商交换消息
cookie ---RFC建议将源目IP,源目端口,本地生成的随机数,日期和时间进行散列操作.cookie成为留在IKE协商中交换信息的唯一标识,实际上 cookie是用来防止DOS攻击的，它把和其他设备建立IPSEC所需要的连接信息不是以缓存的形式保存在路由器里，而是把这些信息HASH成个 cookie值
1&2消息
消息1---发送方向对等体发送一条包含一组或多组策略提议,在策略提议中包括5元组(加密算法,散列算法,DH,认证方法,IKE SA寿命)
1．策略协商，在这一步中，就四个强制性参数值进行协商：
1）加密算法：选择DES或3DES
2）hash算法：选择MD5或SHA
3）认证方法：选择证书认证、预置共享密钥认证或Kerberos v5认证
4）Diffie-Hellman组的选择
消息2---接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应
注意!!!发起者会将它的所有策略发送给接受者,接受者则在自己的策略中寻找与之匹配的策略(对比顺序从优先级号小的到大的)（默认策略实际就是个模版没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）
在1&2消息中报错可能出现的原因
1，peer路由不通
2，crypto iskmp key没有设置
3，一阶段的策略不匹配
3&4消息
这2条消息,用于交换DH的公开信息和随机数
两个对等体根据DH的公开信息都算出了双方相等的密植后,两个nonce连通预共享密钥生成第一个skeyID
随后便根据SKEY__ID来推算出其他几个skeyID
skeyID_d---用来协商出后续IPSEC SA加密使用的密钥的
skeyID_a---为后续的IKE消息协商以及IPSEC SA协商进行完整性检查(HMAC中的密钥)
skeyID_e---为后续的IKE消息协商以及IPSEC SA协商进行加密
5&6消息
这2条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的
为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时由于ID还没到,彼此先用HASH来彼此验证对方)
HASH