主模式-第一阶段六个包交换细节总结:
(1) 阶段1
这个阶段要协商的SA可以称为ISAKMP SA(在IKE中可以称为IKE SA),该SA是为了保证阶段2的安全通信。
认证方法
1.包封装:
IKE的报文封装:
|前导码|EtherentII|源公IP|目公IP|UDP-500|Palyload|帧尾|
playload:为IKE协商策略的负载内容,对于1~4个包为明文内容,用UDP的500,以后的5~9个包都为加密内容,用UDP的4500
第1个包的Palyload
协商:
1.加密算法:DES、3DES、AES...
2.认证方法:peer-share、RSA
3.认证与完整性算法:MD5、SHA-1
4.group组:1、2、5、7
5.IKE SA的存活时间:默认一天,可手动指定
6.NAT穿越:静态NAT地址转换协商(只有在ESP加密和认证时才会协商)
7.cookie值:源IP地址+目的IP地址+UDP源端口+UDP目的端口+随机数+当前日期+当前时间通过完整性算法算出的HASH值截取前64位
第2个包是由响应端发起的:响应端会把发起×××连接的发起端发来的协商策略进行比照,如果有对应的IKE策略就回应响应端认可的那个IKE策略,同时产生响应端的cookie值
第3,4个包在交流各自通过DH算法算出的公/私钥,私钥保留在本地,公钥发给对方,再通过对方的公钥,自己的公钥和私钥以及其它一些参数,生成被用密钥,加密对称密钥和认证密钥。
密钥推导:
·
·
·
·
SKEYID_e =PRF(SKEYID, SKEYID_a|gir|CKY-i|CKY-r|2)
解释各密钥的作用:
SKEYID_d:一个中间态密钥,不用于实际的数据加密和认证,仅仅用于导出其他密钥。由SKEYID和K(是Pre-sharedkeys,或是证书的公钥)经H计算得出。
SKEYID_a:用于在IKE第二阶段协商中,为信道中传输的数据(协商数据,非用户数据)进行认证时,认证算法所用的认证密钥。由SKEYID
SKEYID_e:用于在IKE第二阶段协商中,为信道中传输的数据进行加密是,加密算法所用的加密密钥。由SKEYID_D
第5、6个包主要是用来进行IKE阶段协商的认证,里面就要认证源ID与认证密钥
以上六个包协商完成了之后,就进入到第二价段的IPSEC SA的协商,即主动模式的协商:
3.重难点分析:
在第一阶段的前两个包里重点在于ISAKMP策略的协商,这是为后面能在一个安全的环境之下协商IPSECSA策略打下基础,因为这些策略直接提供对第二阶段的IPSEC SA策略协商的加密保护;
在3、4个包里,重在点于通过DH算法产生和传递进行第一阶段认证的密钥材料,这些材料会让两端的×××设备产生一对相同的密钥,这个产生的密钥就是第一阶段相互间真实的认证密钥,这点很重要;
在5、6个包里,就用前面产生的认证密钥进行相互认证,当相互认证通过,那么为第二个阶段协商IPSECSA策略的安全通道立即打开,两端的×××服务器会用第一个阶段协商的安全策略对第二阶段协商IPSECSA策略进行安全加密和认证;
同时要注意,从第5个包起,后面的所有包将会加密,只不过不同的是,第5、6个包和第二阶段协商的3个包都是通过第一阶段协商的安全策略进行加密的,而用户通信的数据则是用第二阶段协商的IPSECSA策略进行加密和认证的,至于密钥两者是否一样,就要看在第二阶段是否定义了PFS策略,如果应用了,那第第二阶段的密钥将与第一阶段的不同,否则两者的密钥是一样的。
第二阶段的3个包主要用来协商用于加密用户数据的安全策略(只有认证和加密方法和对应算法),当第二阶段协商完毕之后,第一阶段的策略将暂时不会被使用,直到有新的×××连接建立时或IPSECSA加密密钥超时时,才会用第一阶段的策略重新生成并传递新的加密数据和认证的密钥。
4.注意事项:
在发起IPSEC连接之前,一定要确保两端×××设备的第一阶段与第二阶段的策略,感兴趣流配置正确,并且PEER与KEY也要正确,同时要在连接外网的接口应用安全策略关联,两端×××设备要能相互PING通,这是前提;
对于×××穿越防火墙或过ACL时,则一定要放行UDP 500号端口,如果做了NAT,则有两种情况:
1.如果穿越的是路由,则在放行UDP 500号端口的基础之上,还需要放行UDP的4500号端口;
2.如果穿越的是防火墙,刚在放行UDP 500号端口的基础之上,还需要放行ESP协议
主模式-第二阶段三个包交换细节总结:
这个阶段要协商的SA是密钥交换协议最终要协商的IPSEC SA,当IKE为IPSec协商时可以称为IPSecSA,是保证AH或者ESP的安全通信。阶段2的安全由阶段1的协商结果来保证。阶段1所协商的一个SA可以用于协商多个阶段2的SA。
第1个包协商IP sec SA的策略,建立IP sec的安全关联,
1.在IKE SA协商进行认证的基础上,产生新的Key再次进行双方的认证;
2. 建立IP sec SA的安全关联,协商所用的:
第2个包主要是接收端查看本地有没有一个IPSECSA策略与发起方的一样,如果有,并且认证成功,感兴趣流协商成功,那么接收端会把协商成功的IPSECSA策略发给发起端,同时也会把自己的认证Key发给发启端来进行双向认证
第3个包主要是发起端对接收端发来的第二个包进行确认,当然前提是发起端对接收端的认证成功。
经过以上三个包的交换后,IPSEC的连接就完成了,后继就是对感兴趣流的数进行IPSE上面所协商的策略进行安全处理了。