ISAKMP：Internet Security Association and Key Management Protocol，Internet 安全关联和密钥管理协议
一种协议框架，定义了有效负载的格式、实现密钥交换协议的机制以及SA协商。
使用TCP和UDP的端口500，一般使用UDP。
初识ISAKMP
在互联网环境中进行通信，由于双方都无法直接接触对方，而且互联网本身是一个开放的环境，因而信息的安全性难以得到保障。一般情况下，当我们讨论网络安全的时候，至少要考虑这几个问题：信息加密、身份认证和数据的完整性。对于某些特殊的场景，可能还需要考虑访问控制和信息的不可否认性等问题。
为了实现在互联网环境中进行安全通信，RFC2048定义了名为ISAKMP的安全框架。它结合了认证、密钥管理和安全关联的概念来在互联网上建立起安全的通信。
在这个框架中，安全关联是指两个网络实体间共享的一组安全属性，比如加密算法和模式等。ISAKMP它的主要作用就是协商和管理安全关联，以及密钥。为了实现这一功能，ISAKMP定义了一系列的消息和过程。
但是ISAKMP只是一个框架而已，它并不规定采用什么样的密钥交换算法，也不关注各个加密算法、认证算法和完整性算法的实现。这样做的好处在于，框架本身有很好的可扩展性。如果在将来的某一天，我们发现密钥交换算法存在漏洞或者某个加密算法不安全了，可以直接替换掉，而不破坏框架本身。当然，前提是框架本身必须具有很好的安全性。现在的ISAKMP框架已经可以很好的处理DOS、连接劫持和中间人攻击。
从宏观上来看，ISAKMP主要做了三件事情：
1. SA协商
2. 密钥交换
3. 认证
SA协商的目的是为了在通信双方间协商出一组双方都认可的安全参数。比如两端采用相同的加密算法和完整性算法。
密钥交换的目的是为已经协商好的算法生成必要的密钥信息。
认证的目的是鉴别对方的身份，保证自己不是在跟一个伪造的对象通信。
这样，通过一系列的消息交互，通信的双方既鉴别了对方的身份，也保证了后继通信的安全性。
ISAKMP协议
Interne 安全连接和密钥管理协议（ISAKMP）是 IPsec 体系结构中的一种主要协议，它结合加密安全的概念，密钥管理和安全连接来建立政府，商家和因特网上的私有通信所需要的安全。
因特网安全联盟和密钥管理协议（ISAKMP）定义程序和信息包的格式来建立、协商、修改和删除安全连接（SA）。SA 包括所有如 IP 层服务、传输或应用层服务、流通传输的自我保护的各种各样的网络协议所需要的信息。ISAKMP 定义交换密钥生产的有效载荷和认证数据。这些格式为依靠于密钥产生技术，加密算法和认证机制的传输密钥和认证数据提供了一致的框架。
把函数分离为三部分增加了一个完整的 ISAKMP 执行安全分析的复杂性，因此在具有不同安全要求的系统之间不赞成分离操作，而且还应该将更多 ISAKMP 服务的发展分析变得简单化。
ISAKMP 被用来支持在所有网络堆栈（如 IPSEC、TLS、TLSP、OSPF 等等）的层上的安全协议的 SA 的谈判。ISAKMP 通过集中安全连接的管理减少了在每个安全协议中复制函数的数量。ISAKMP 还能通过一次对整个服务堆栈的协议来减少建立连接的时间。
ISAKMP 中，解释域（DOI）用来组合相关协议，通过使用 ISAKMP 协商安全连接。共享 DOI 的安全协议从公共的命名空间选择安全协议和加密转换方式，并共享密钥交换协议标识。同时它们还共享一个特定 DOI 的有效载荷数据目录解释，包括安全连接和有效载荷认证。
总之，ISAKMP 关于设置 DOI 需要定义如下方面：
特定 DOI 协议标识的命名模式；
位置字段解释；
可应用安全方案设置；
特定 DOISA 属性语法；
特定 DOI 有效负载目录语法；
必要情况下，附加密钥交换类型；
必要情况下，附加通知信息类型。
8 12 16 24 32
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 发起者 !
! Initiator Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 应答 !
! Responder Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 下一个载荷 ! MjVer ! MnVer ! 交换类型 ! 标志 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 消息 ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 长度 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ISAKMP 头格式
Initiator Cookie ― Initiator Cookie：启动 SA 建立、SA 通知或 SA 删除的实体 Cookie。
Responder Cookie ― Responder Cookie：响应 SA 建立、SA 通知或 SA 删除的实体 Cookie。
Next Payload ― 信息中的 Next Payload 字段类型。
Major Version ― 使用的 ISAKMP 协议的主要版本。
Minor Version ― 使用的 ISAKMP 协议的次要版本。
Exchange Type ―
表示所用的交换类型。这表示消息和载荷遵循所用的交换顺序。
交换类型 值
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6 - 31
DOI Specific Use 32 - 239
Private Use 240 - 255
Flags ― 为 ISAKMP 交换设置的各种选项。
Message ID ― 唯一的信息标识符，用来识别第2阶段的协议状态。
Length ― 全部信息（头＋有效载荷）长（八位）。
ISAKMP - 安全关联协商
前面说过，ISAKMP主要有三个过程：SA协商、密钥交换和认证。本篇主要讨论SA协商。
首先要明白一个问题：为什么需要协商？为什么协议不规定使用某种特定的算法，这样实现上可以变得简单很多？
要回答这个问题，我们必须全面的审视网络通信的环境。所有的安全服务都与网络的配置和环境有关。互联网很有意思的一点在于，任何一台互联网设备可随时随地的接入，也可以自由的离开。所以网络环境是不断变化的。同时，网络设备也是多样化的，每个设备可能支持不同的算法。所以需要通过协商建立起一个彼此都支持认可的安全属性集。
如果采用特定的算法，实现上当然可以简化，但是却失去了灵活性。比如，在某些情况下，可能不需要太高强度的加密，而在某些情况下却需要很高强度的加密。但是没有一种算法可以满足所有的需求。更重要的原因在于，一旦这个统一的算法不安全了，整个网络都会受到影响。
所以说，协商是必要。那么第二个问题也就自然而然的出来了，我们需要协商什么？
一般说来，我们需要协商加密算法、认证机制，以及密钥建立算法。安全关联必须也支持面向主机的认证（低层协议），和面向用户的认证（高层协议）。在应用层协议，比如e-mail、remote login和文件传输，以及面向会话的协议，路由协议和链路层协议中，都要求算法和机制的独立性。ISAKMP为这些安全协议、应用、安全需求和网络环境提供了一个一般的安全关联和密钥建立协议。
ISAKMP对于它的认证和keyexchange部分有基本的需求。这些需求能够防卫DOS、重放/反射、中间人和连接劫持攻击。这一点非常重要，因为这些攻击都是针对协议的攻击。提供了算法和机制独立性的完整的SA支持，以及协议攻击保护造就了ISAKMP的优势。
至于协商的过程则比较简单。一方首先发起协商，告知对方自己支持的安全参数。如果接收方也支持，则协商成功。否则，重新协商。
SA的概念：
所谓安全关联，指的是两个或者多个实体之间的一种安全关系。它描述了实体间如何利用安全服务来进行安全通信。这种安全关系可以通过实体间的一组信息来表述，类似于一个合同。这些信息必须是所有实体都同意，而且共享的信息。有时候这些信息单独的被称作一个SA，但这仅仅是已存在的安全关系的物理示例而已。这种关系的存在，为安全协作的实体提供了大家都同意的安全信息。所有的实体都必须遵循SA，从而使安全通信成为可能。访问SA属性的时候，实体们使用一个叫做SPI（Security Parameter Index）的指针或者标识。[SEC-ARCH]提供了IP SA和SPI定义的更多细节。ISAKMP - 密钥交换
密钥交换主要用于密钥的建立。在ISAKMP体系中，无论是数据加密算法还是认证算法，都需要一个双方都知道的密钥。然而，互联网环境是不安全的，如何才能够通过不安全的互联网环境建立起一个安全的密钥呢？
一般有两种方式。第一种叫做密钥传输，第二种叫做密钥生成。
顾名思义，密钥传输就是直接把密钥发给对方。一个典型的例子是，首先在客户端随机生成一个密钥，然后使用服务端的公开密钥进行加密。由于只有服务端知道如何对加密数据解密，所以保证了密钥的安全性。但是，如果服务端的私钥被窃取了，那么通信就变得不安全。
密钥生成与密钥传输有着本质的不同。由于密钥是不在网络上传输的，这样，即便一个攻击者截取了密钥交换信息，也无法取得密钥。密钥生成通常使用Diffie-Hellman算法。首先通信的双方各自独立的生成一个私钥，记为Xi和Xr。然后利用Xi和Xr生成可以公开的密钥信息Yi和Yr。双方交换Yi和Yr，于是发起端拥有Xi和Yr，而接收端拥有Yi和Xr。利用这些信息和DH算法，两端就可以生成相同的密钥。
从计算量上来讲，密钥传输的计算量比密钥生成要少。但是从安全性上来看，无疑密钥生成的安全性更高。所以，现在主流的密钥交换协议，比如IPSec，都是基于DH算法来实现的。
ISAKMP - 认证
认证，指的是通过认证的过程来验证通信对方是否是它所期望的实体，而不是假冒者。
举一个例子，公司派你独自一人去美国出差，糟糕的是你并不认识美国公司的任何一个同事。经过10多个小时的飞行，飞机终于降落在美国土地上。你刚下飞机，赫然看见有人举着牌子，上面写着你的名字。然后你过去打招呼，说我就是Bruce。对方很高兴的说，终于等到你了，咱们走吧。结果，你猜怎么着，对方是黑手党的……
所以说，无论做什么事情，首先要弄明白对方的身份，尤其是跟对方素未谋面的时候。所有的认证协议都使用一个通用的模型：Alice首先发起认证过程，她给Bob或者可信的KDC发送一条消息。接下来，在各个方向上继续交换其他一些消息。当这些消息被发送出去以后，Trudy可能截获、修改或者重放这些消息以便欺骗Alice和Bob，或者纯粹捣乱他们的工作。
然而，当协议完成的时候，Alice确认她是在跟Bob通话，而Bob也确认他是在跟Alice通话。而且，在绝大多数协议中，二者也将建立起一个秘密的会话密钥，以便接下来的会话过程。
想要认证对方，双方应当有一些共享的秘密信息，而且这些信息只被参与通信的双方所了解。如果双方对于彼此一点了解也没有，显然是无法认证对方的。就好比你在美国下飞机了，如果你不知道接机人的身份信息，很容易就会被人欺骗。
基于共享密钥的认证通常使用质询-回应协议。Alice首先选择一个随机数RA，然后发给Bob。Bob使用共享密钥对随机数做一系列变换，然后送回给Alice。Alice在本地对随机数做相同的变化，然后同Bob发来的结果进行比较，如果相同，说明对方是Bob。由于任何第三方不可能获取共享密钥，因而无法生成变换结果来欺骗Alice。
但是，这种认证有一种致命的缺陷。在某种情况下，Trudy可以利用一种被称为反射攻击的技术使得协议失败。继续上面的例子，假如Trudy截获了Alice发给Bob的质询消息。然后重新开启一个会话，声称自己是Bob，并给Alice发送随机数RA，要求Alice证明自己的身份。于是Alice对RA进行变换，把结果发给Trudy。然后Trudy用这个结果来回应Alice最初的质询，于是成功的欺骗了Alice。
由此可见，设计一个正确的认证协议要比表面上复杂的多。下面的4条一般性原则通常会有所帮助：
1. 让发起者首先证明自己是谁，然后轮到应答方。
2. 让发起方和应答方使用不同的密钥做证明。不过，这意味着要有两个共享密钥。
3. 让发起方和应答方从不同的质询集合选择随机数。比如，发起方必须使用偶数，应答方必须使用奇数。
4. 使协议可以抵抗这种牵扯到第二个并行会话的攻击。
以上原则只要有一条违反了，则协议通常会被攻破。
一个可行的认证协议是使用HMAC。在此协议中，通信双方都会生成一个随机数，然后将双方的随机数、双方的表示和共享的秘密密钥一起做HASH运算，得到的结果是一个HMAC。
过程如下：
1. Alice随机选择一个RA，用明文发送给Bob。
2. Bob随机选择一个RB，并连同计算出的HMAC(RA,RB,A,B,Key-AB)一起发回给Alice作为质询。要求Alice用这个随机数证明自己。
3. Alice回应HMAC(RA,RB,Key-AB)。
显然，Trudy无法伪造Bob的应答，因为它不知道Key-AB。
ISAKMP对于它的认证和密钥交换模块有一些基本的安全需求，以防止DOS、重放/反射、中间人攻击和连接劫持攻击。
DOS攻击：
ISAKMP防范DOS攻击的主要方式是cookie。在ISAKMP交换中，最占用资源的部分便是DH交换，因为DH交换需要做大量的幂运算。如果一个攻击者在前两个消息之后，通过伪造的Ip不断的发送Key Exchange消息，便可能让对端陷入大量的幂运算，从而耗尽cpu资源。所以通过cookie将一个实体跟ip/port对绑定，并结合ISAKMP的状态机，可以抵御此类的攻击。
重放/反射和连接劫持攻击：
主要通过ISAKMP的状态机进行防范。
中间人攻击：
中间人攻击包括窃听、插入、删除和修改消息，或者将消息反射回发送方，或者重播一条旧的消息，或者重定向消息。ISAKMP阻挡了这些攻击，使之不能成功。
ISAKMP的各个消息交换之间的关联可以阻挡消息插入。如果在两次交换间插入其他消息会导致交换失败。
ISAKMP的状态机保证了当一条消息被删除时，不会导致安全关联的部分建立。也就是说，如果某一条期待的消息没来时，安全关联不会生效。同时，状态机会清空所有状态，回到空闲状态。
状态机同样阻挡了反射消息，防止它造成破坏。
对于每一个新建立的SA，ISAKMP要求有一个带时间变量信息的新的cookie，这样就可以防止重放旧的消息。
ISAKMP的强认证机制保证了它不会与其他第三方建立SA。
消息可能被重定向到一个不同的目的地址，或者被修改。但是这种变化可以被检测出来，从而防止与伪造的第三方建立起一个SA。
ISAKMP文档定义了异常处理出现的地方，并且推荐向合适的一方通知异常。
DH算法最大的一个缺陷在于，它无法防止中间人攻击。如下图所示：
Alice MITM Bob
(g,g^x)| -------------------------> |
|(g, g^m) ---------------> |
| <------------------------| (g, g^y)
| <----------------(g,g^m)|
Alice想和Bob交换密钥。于是选择(p,g,x)，并发送公开密钥g^x(modp)给Bob。但是中间人MITM拦截了此对话，并把自己伪装成Alice跟Bob通信。MITM向Bob发送自己的公开密钥g^m(mod p)，从而跟Bob建立起了共享密钥g^my(mod p)。同时，它又冒充自己是Bob，跟Alice建立起共享密钥g^xm(mod p)。这样，当Alice向Bob发送消息时，消息首先到达MITM。MITM用g^xm(mod p)来解密，然后用g^my(mod p)来加密，从而成功的欺骗了Alice和Bob。
中间人攻击之所以能够成功的关键在于，通信双方没有对对方进行认证，从而无法确定对方的真实身份。所以，防范中间人攻击就必须进行双向认证。在ISAKMP体系中，通信双方首先交换DH值，最后进行身份认证。一旦有中间人，认证必然失败。
以数字签名认证为例，双方使用公钥签名(DSS或RSA)来验证对等体。公钥通常是通过证书获得的。在第三次和第四次消息交换中，发起方和应答放请求对方提供证书，同时向对方发送临时值(Ni和Nr)以及DH公开值。在第五和第六次消息交换中，相互交换了证书。虽然证书是可选的，但是这已经成为一种标准实现。创建数字签名的方法如下：
SIGi= PrivateKeyi (Hashi)
SIGr= PrivateKeyr (Hashr)
在这里，使用相应的私钥对HASHi和HASHr进行了签名，得到消息摘要SIGi和SIGr。而签名是不可伪造的，所以中间人不可能替换Hashi和Hashr，因为替换之后，它无法产生正确的签名。而Hashi的生成使用了通信双方的共享密钥，所以现在有两个Hashi。一个是Alice和MITM之间的HashiA，一个是MITM和Bob之间的HashiB。
现在，Alice要向Bob证明自己，于是它用自己的私钥对HashiA进行签名。MITM截获到此消息后，如果它不做任何处理，直接把消息交给Bob。Bob用Alice的公钥解密此签名，最后会发现HashiA和HashiB的不一致，从而认证失败。
MITM为了继续欺骗，于是决定修改此消息。它先解密此消息，然后将Alice的证书替换成自己的证书，并用自己的私钥对HashiB进行签名。这样，Bob就不会发现Hashi的不一致。但是，Bob在向CA验证证书的时候发现对方并不是Alice。
如果使用Pre-SharedKey。Hashi和Hashr的生成会用到预共享密钥的信息。如果采用主模式，发起方会在第五个消息首先发送Hashi。而此时，它还没有获取应答方的IDir。因此，只能用ip地址来确定应答方的身份和选择预共享密钥。这种情况下，通常采用Aggressive模式。因为Aggressive模式的第一个消息中，发起方向应答方表明了自己的身份，然后应答方根据发起方的身份选择预共享密钥，并生成Hashr。第三个消息中，应答方用Hashi来证明自己。
如果使用公开密钥加密来进行认证。由于双方都已经获取了对方的公开密钥，并对随机值和ID进行加密，所以可以保证中间人无法伪造随机值和ID。如果中间人存在，由于Alice和Bob持有的DH值不同，因而无法生成相同的HASHI，认证失败
ISAKMP - 解释域(DOI)和初始向量(IV)
Domain of Interpretation – 解释域
DOI定义了负载的格式、交换的类型，以及对安全相关信息的命名约定，比如对安全策略或者加密算法和模式的命名。DOI标识用来说明payload通过哪一个DOI来解释。常用的DOI有两个，0和1。0表示ISAKMP DOI，1标识IPSec DOI。如果一个负载，Notification payload的DOI为0，那么说明这是一个ISAKMP DOI，那么就必须用ISAKMP协议来解析它；如果是1，说明这是一个IPSec DOI，那么就必须用IPSec协议来解析它。对于某些payload，比如Vendor ID Payload和Certificate Payload，是通用的payload，所以它没有DOI域，对所有的协议都采用一致的解释方式。而对于identification payload，它里面就有一个‘DOI specificID data’，如果使用IPSec DOI，参照RFC2407，这个域的格式应该是协议ID + 端口的形式。
再举一个例子：
IKE在为上层应用（AH/ESP）建立起一个安全关联的时候，要进行两次协商。第一次协商建立起一个简单的安全关联，然后用这个安全关联来为AH/ESP协商安全参数。SA协商的时候，里面有一个名为Transform的负载，它包含了若干名为SA Attributes的负载（每个负载代表一种类型的算法，比如HASH/Encryption等）。它的解释就需要DOI的帮助。在IKE Phase1协商时，对于这个负载的解释是根据IANA的‘Internet Key Exchange (IKE) Attributes’文档来解释的。而对于Phase2阶段，这个负载的解释是根据‘IPSec DOI for Isakmp’这个文档来解释的。虽然两个阶段的DOI都一样，都是IPSec DOI，但由于IPSec DOI中明确说明对于这个负载的解释仅限于第二阶段协商，所以对于第一阶段协商的解释必须回到IANA的文档中。
Initialization vector
分组密码的加密有多种模式，其中最简单的是ECB模式。如果明文的长度很长，一般先将明文分成等长大小的块。然后用相同的密钥对每个明文块加密。但是，这样存在一个问题，如果明文块出现了重复，那么加密的结果也是完全相同的。对于很长的消息，这种模型可能就不太安全。
为了克服ECB的这些弱点，研究人员又提出了CBC模型。这种模式的加密算法的输入是先对当前的明文组和上一个密文组做异或，然后将异或的结果用密钥加密。这样，即便两个明文组完全一样，由于跟它们做异或操作的对象不同，加密的结果也不同。那么，第一个明文组跟谁做异或呢？答案就是Initialization vector。IV其实就是一个固定长度的随机数，或者伪随机数。这样，用IV跟第一个明文块做异或使得加密的结果产生一定的随机性，从而有效的防范了攻击者猜测变换法则。
http://blog.csdn.net/jiangwlee/article/category/909949
4499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
