本章要点：
IPSec的而概念、功能、体系结构；安全联盟和安全策略的概念；传输模式和隧道模式的功能和特点；IPSec安全协议的AN机制和功能；IPSec安全协议的ESP机制和功能；密钥管理协议ISAKMP机制和功能；Internet的密钥交换协议IKE机制和功能。

第十章 IPSec

IPSec安全体系结构

IPSec的概念

• IPSec（IP Security）是一种由IETF设计的端到端的确保IP层通信安全的机制
• IPSec不是一个单独的协议，而是一组协议
• IPSec协议的定义文件包括了12个RFC文件和几十个Internet草案，已经成为工业标准的网络安全协议
• IPSec是随着IPv6的制定而产生的，鉴于IPv4的应用仍然很广泛，所以后来在IPSec的制定中也增加了对IPv4的支持
• IPSec在IPv6中是必须支持的，而在IPv4中是可选的
• IP协议在当初设计时并没有过多地考虑安全问题，而只是为了能够使网络方便地进行互联互通，因此IP协议从本质上就是不安全的
• 如果不采取安全措施，IP通信会暴露在多种威胁之下，例如：窃听、篡改、IP欺骗、重放攻击
• IP协议之所以如此不安全，是因为IP协议没有采取任何安全措施，既没有对数据包的内容进行完整性验证，又没有进行加密
• IPSec协议可以为IP网络通信提供透明的安全服务，保护IP通信免遭窃听和篡改，保证数据的完整性和机密性，有效抵御网络攻击，同时保持易用性

IPSec的功能

• 作为一个隧道实现了VPN通信

  • IPSec作为第三层的隧道协议，可以在IP层上创建一个安全的隧道

• 保证数据来源可靠

  • 在IPSec通信之前双方要先用IKE认证对方身份并协商密钥，只有IKE协商成功之后才能通信
  • 由于第三方不可能知道验证和加密的算法以及相关密钥，因此无法冒充发送方，即使冒充，也会被接收方检测出来

• 保证数据完整

  • IPSec通过验证算法功能保证数据从发送方到接收方的传送过程中的任何数据篡改和丢失都可以被检测

• 保证数据机密性

  • IPSec通过加密算法使只有真正的接收方才能获取真正的发送内容，而他人无法获知数据的真正内容

IPSec体系结构

• IPSec包含了3个最重要的协议

  • AH

    • AH为IP数据包提供3种服务：无连接的数据完整性验证、数据源身份认证和防重放攻击

  • ESP

    • ESP除了为IP数据包提供AH已有的3种服务外，还提供另外两种服务：数据包加密、数据流加密

  • IKE

    • IKE协议负责密钥管理，定义了通信实体间进行身份认证、协商加密算法以及生成共享的会话密钥的方法。IKE将密钥协商的结果保留在安全联盟（SA）中，供AH和ESP以后通信时使用

安全联盟和安全联盟数据库

• 安全联盟（SA）

  • SA（SecurityAssociation，安全联盟）是两个IPSec实体（主机、安全网关）之间经过协商建立起来的一种协定

  • 内容包括采用何种IPSec协议（AH还是ESP）、运行模式、验证算法、加密算法、加密密钥、密钥生存期、抗重放窗口、计数器等，从而决定了保护什么、如何保护以及谁来保护

  • SA是单向的，进入（inbound）SA负责处理接收到的数据包，外出（outbound）SA负责处理要发送的数据包

  • 因此每个通信方必须要有两种SA，一个进入SA，一个外出SA，这两个SA构成了一个SA束（SA Bundle）

  • SA的管理包括创建和删除

  • SA管理方式

    • 手工管理

      • SA的内容由管理员手工指定、手工维护
      • 手工维护容易出错，而且手工建立的SA没有生存周期限制，一旦建立了，就不会过期，除非手工删除，因此有安全隐患

    • IKE自动管理

      • SA的自动建立和动态维护是通过IKE进行的
      • 利用IKE创建和删除SA，不需要管理员手工维护，而且SA有生命期
      • 如果安全策略要求建立安全、保密的连接，但又不存在与该连接相应的SA，IPSec的内核会立刻启动IKE来协商SA

  • SA标识

    • 每个SA由三元组<SPI，源/目的IP地址，IPSec协议>唯一标识

      • SPI（Security Parameter Index，安全参数索引）是32位的安全参数索引，标识同一个目的地的SA
      • 源/目的IP地址：表示对方IP地址。对于外出数据包，指目的IP地址；对于进入数据包，指源IP地址
      • IPSec协议：采用AH或ESP

• 安全联盟数据库（SAD）

  • SAD（Security Association Database，安全联盟数据库）并不是通常意义上的“数据库”，而是将所有的SA以某种数据结构集中存储的一个列表
  • 对于外出的流量，如果需要使用IPSec处理，然而相应的SA不存在，则IPSec将启动IKE来协商出一个SA，并存储到SAD中
  • 对于进入的流量，如果需要进行IPSec处理，IPSec将从IP包中得到三元组，并利用这个三元组在SAD中查找一个SA

安全策略和安全策略数据库

• SP（Security Policy，安全策略）指示对IP数据包提供何种保护，并以何种方式实施保护

• SP主要根据源IP地址、目的IP地址、入数据还是出数据等来标识

• IPSec还定义了用户能以何种粒度来设定自己的安全策略，由“选择符”来控制粒度的大小，不仅可以控制到IP地址，还可以控制到传输层协议或者TCP/UDP端口等

• SPD（Security
  Policy Database，安全策略数据库）是将所有的SP以某种数据结构集中存储的列表

• 当要将IP包发送出去时，或者接收到IP包时，首先要查找SPD来决定如何进行处理

• 可能的处理方式

  • 丢弃

    • 流量不能离开主机或者发送到应用程序，也不能进行转发

  • 不用IPSec

    • 对流量作为普通流量处理，不需要额外的IPSec保护

  • 使用IPSec

    • 对流量应用IPSec保护，此时这条安全策略要指向一个SA
    • 对于外出流量，如果该SA尚不存在，则启动IKE进行协商，把协商的结果连接到该安全策略上

IPSec运行模式

• 传输模式（Transport Mode）

  • 传输模式要保护的内容是IP包的载荷，传输模式为上层协议提供安全保护
  • 通常情况下，传输模式只用于两台主机之间的安全通信
  • 正常情况下，传输层数据包在IP中被添加一个IP头部构成IP包。启用IPSec之后，IPSec会在传输层数据前面增加AH或者ESP或者二者同时增加，构成一个AH数据包或者ESP数据包，然后再添加IP头部组成新的IP包

• 隧道模式（Tunnel Mode）

  • 隧道模式保护的内容是整个原始IP包，隧道模式为IP协议提供安全保护

  • 通常情况下，只要IPSec双方有一方是安全网关或路由器，就必须使用隧道模式

  • 路由器将需要进行IPSec保护的原始IP包看作一个整体，将这个IP包作为要保护的内容，前面添加AH或者ESP头部，然后再添加新的IP头部，组成新的IP包之后再转发出去

  • 数据包的两个IP头

    • 内部头：由路由器背后的主机创建
    • 外部头：由提供IPSec的设备（可能是主机，也可能是路由器）创建

  • 隧道模式下，通信终点由受保护的内部IP头指定，而IPSec终点则由外部IP头指定。如IPSec终点为安全网关，则该网关会还原出内部IP包，再转发到最终目的地

• AH和ESP都支持这两种模式，因此有4种可能的组合：传输模式的AH、隧道模式的AH、传输模式的ESP和隧道模式的ESP。

IPSec安全协议——AN

AH概述

• AH（Authentication Header，验证头部协议）由RFC2402定义，是用于增强IP层安全的一个IPSec协议，该协议可以提供无连接的数据完整性、数据来源验证和抗重放攻击服务
• AH协议对IP层的数据使用密码学中的验证算法，从而使得对IP包的修改可以被检测出来
• 具体地说，这个验证算法是密码学中的MAC（Message Authentication Codes，报文验证码）算法，MAC算法将一段给定的任意长度的报文和一个密钥作为输入，产生一个固定长度的输出报文，称为报文摘要或者指纹
• MAC算法与HASH算法非常相似，区别在于MAC算法需要一个密钥（key），而HASH算法不需要
• 实际上，MAC算法一般是由HASH算法演变而来，也就是将输入报文和密钥结合在一起然后应用HASH算法。这种MAC算法称为HMAC，例如HMAC-MD5、HMAC-SHA1等
• 为了使通信双方能产生相同的报文摘要，通信双方必须采用相同的HMAC算法和密钥
• 对同一段报文使用不同的密钥来产生相同的报文摘要是不可能的。因此，只有采用相同的HMAC算法并共享密钥的通信双方才能产生相同的验证数据

AH头部格式

• AH协议和TCP、UDP协议一样，是被IP协议封装的协议之一

• 一个IP包的载荷是否是AH协议，由IP协议头部中的协议字段判断，正如TCP协议是6，UDP协议是17一样，AH协议是51

• 如果一个IP包封装的是AH协议，在IP包头（包括选项字段）后面紧跟的就是AH协议头部

• 组成

  • 下一个头（Next Header）

    • 最开始的8位，表示紧跟在AH头部的下一个载荷的类型，也就是紧跟在AH头部后面数据的协议
    • 在传输模式下，该字段是处于保护中的传输层协议的值，比如6（TCP）、17（UDP）或者50（ESP）。在隧道模式下，AH所保护的是整个IP包，该值是4，表示IP-in-IP协议

  • 载荷长度（Payload Length）

    • 接下来的8位，其值是以32位（4字节）为单位的整个AH数据（包括头部和变长的认证数据）的长度再减2

  • 保留（reserved）

    • 16位，作为保留用，实现中应全部设置为0

  • SPI(Security Parameter Index，安全参数索引)

    • SPI是一个32位整数，与源/目的IP地址、IPSec协议一起组成的三元组可以为该IP包惟一地确定一个SA
    • [1，255]保留为将来使用，0保留本地的特定实现使用。因此，可用的SPI值为[256，2^32-1]

  • 序列号

    • 序列号是一个32位整数，作为一个单调递增的计数器，为每个AH包赋予一个序号
    • 当通信双方建立SA时，计数器初始化为0。SA是单向的，每发送一个包，外出SA的计数器增1；每接收一个包，进入SA的计数器增1
    • 该字段可以用于抵抗重放攻击

  • 验证信息

    • 可变长部分，包含了验证数据，也就是HMAC算法的结果，称为ICV（Integrity Check Value，完整性校验值）
    • 该字段必须为32位的整数倍，如果ICV不是32位的整数倍，必须进行填充，用于生成ICV的算法由SA指定

AH运行模式

• AH传输模式

  • 被AH验证的区域是整个IP包（可变字段除外），包括IP包头部，因此源IP地址、目的IP地址是不能修改的，否则会被检测出来
  • 然而，如果该包在传送的过程中经过NAT（Network Address Translation，网络地址转换）网关，其源/目的IP地址将被改变，将造成到达目的地址后的完整性验证失败
  • 因此，AH在传输模式下和NAT是冲突的，不能同时使用，或者可以说AH不能穿越NAT

• AH隧道模式

  • 在隧道模式中，AH插入到原始IP头部字段之前，然后在AH之前再增加一个新的IP头部
  • 隧道模式下，AH验证的范围也是整个IP包，因此AH和NAT的冲突在隧道模式下也存在
  • 在隧道模式中，AH可以单独使用，也可以和ESP一起嵌套使用

数据完整性检查

• AH协议验证的范围包括整个IP包

• 验证过程

  • 在发送方，整个IP包和验证密钥被作为输入，经过HMAC算法计算后得到的结果被填充到AH头部的“验证数据”字段中

  • 在接收方，整个IP包和验证算法所用的密钥也被作为输入，经过HMAC算法计算的结果和AH头部的“验证数据”字段进行比较，如果一致，说明该IP包数据没有被篡改，内容是真实可信的

  • 可变字段

    • 在应用HMAC算法时，有一些因素需要考虑。在IP字段中，有一些是可变的，而且在传输过程中被修改也是合理的，这些字段在计算HMAC时被临时用0填充（另外，AH头部的验证数据字段在计算之前也要用0填充，计算之后再填充验证结果）

    • ToS（Type of Service）

      • 8位的服务类型字段指出了延时、吞吐量和可靠性方面的要求。某些路由器会修改该字段以达到特定的QoS服务质量

    • 标志字段

      • 这是指用于表示分片的3位标志——路由器可能会修改这3个标志

    • 分片偏移字段

      • 标志字段后面的13位的偏移字段

    • TTL

      • 生命期，为了防止IP包的无限次路由，每经过一个路由器，该字段减1，当TTL变为0时，被路由器抛弃

    • 头部校验和

      • 中间路由器对IP包头部作了任何修改之后，必须重新计算头部校验和，因此该字段也是可变的

    • 选项字段

  • 不变字段

    • 对于一个IP包，除可变字段外，其余部分是应该不变的，这些部分也正是受到AH协议保护的部分
    • 版本字段
    • 头部长度字段
    • IP总长字段
    • ID字段
    • 协议字段
    • 源IP字段
    • 目的地址字段
    • AH头中除“验证数据”意外的其他字段
    • 数据：指经过AH处理之后，在AH头部后面的数据。传输方式下，指TCP、UDP或ICMP等数据；隧道模式下，指被封装的原IP包

IPSec安全协议——ESP

ESP概述

• 与AH一样，ESP（Encapsulating Security Payload，封装安全载荷）协议也是一种增强IP层安全的IPSec协议，由RFC2406定义
• ESP协议除了可以提供无连接的完整性、数据来源验证和抗重放攻击服务之外，还提供数据包加密和数据流加密服务
• ESP协议提供数据完整性和数据来源验证的原理和AH一样，也是通过验证算法实现
• ESP协议规定了所有IPSec系统必须实现的验证算法：HMAC-MD5、HMAC-SHA1、NULL
• NULL认证算法是指实际不进行认证
• 数据包加密服务通过对单个IP包或IP包载荷应用加密算法实现；数据流加密是通过隧道模式下对整个IP包应用加密算法实现
• ESP的加密采用的是对称密钥加密算法
• 为了保证互操作性，ESP协议规定了所有IPSec系统都必须实现的算法：DES-CBC、NULL
• NULL加密算法是指实际不进行加密
• 之所以有NULL算法，是因为加密和认证都是可选的，但是ESP协议规定加密和认证不能同时为NULL
• 换句话说，如果采用ESP，加密和认证至少必选其一，当然也可以二者都选，但是不能二者都不选

ESP头部格式

• ESP协议和TCP、UDP、AH协议一样，是被IP协议封装的协议之一

• 一个IP包的载荷是否是ESP协议，由IP协议头部中的协议字段判断，ESP协议字段是50

• 如果一个IP包封装的是ESP协议，在IP包头（包括选项字段）后面紧跟的就是ESP协议头部

• 组成

  • SPI

    • SPI是一个32位整数，与源/目的IP地址、IPSec协议一起组成的三元组可以为该IP包惟一地确定一个SA

  • 序列号（Sequence Number）

    • 序列号是一个32位整数，作为一个单调递增的计数器，为每个ESP包赋予一个序号。当通信双方建立SA时，计数器初始化为0
    • SA是单向的，每发送一个包，外出SA的计数器增1；每接收一个包，进入SA的计数器增1。该字段可以用于抵抗重放攻击

  • 载荷数据（Payload Data）

    • 这是变长字段，包含了实际的载荷数据。不管SA是否需要加密，该字段总是必需的
    • 如果采用了加密，该部分就是加密后的密文；如果没有加密，该部分就是明文
    • 如果采用的加密算法需要一个IV（Initial Vector，初始向量），IV也是在本字段中传输的。该加密算法的规范必须能够指明IV的长度以及在本字段中的位置
    • 本字段的长度必须是8位的整数倍

  • 填充（Padding）

    • 填充字段包含了填充位

  • 填充长度（Pad Length）

    • 填充长度字段是一个8位字段，以字节为单位指示了填充字段的长度，其范围为[0，255]

  • 下一个头（Next Header）

    • 8位字段，指明了封装在载荷中的数据类型，例如6表示TCP数据

  • 验证数据（Authentication Data）

    • 变长字段。只有选择了验证服务时才会有该字段，包含了验证的结果

ESP运行模式

• 运行模式决定了ESP插入的位置以及保护的对象

• ESP传输模式

  • 传输模式保护的是IP包的载荷，例如TCP、UDP、ICMP等，也可以是其他IPSec协议的头部

  • ESP插入到IP头部（含选项字段）之后，任何被IP协议所封装的协议（如传输层协议TCP、UDP、ICMP，或者IPSec协议）之前

    • ESP头部包含SPI和序列号字段
    • ESP尾部包含填充、填充长度和下一个头字段

  • 如果使用了加密，SPI和序号字段不能被加密

  • 如果使用了验证，验证数据也不会被加密，因为如果需要ESP的验证服务，那么接收端会在进行任何后续处理（例如检查重放、解密）之前进行先验

  • 值得注意的是，和AH不同，ESP的验证不会对整个IP包进行验证，IP包头部（含选项字段）不会被验证。因此，ESP不存在像AH那样的和NAT模式冲突的问题

  • 当然，ESP在验证上的这种灵活性也有缺点：除了ESP头部之外，任何IP头部字段都可以修改，只要保证其校验和计算正确，接收端就不能检测出这种修改

  • ESP传输模式的验证服务要比AH传输模式弱一些

  • 如果需要更强的验证服务并且通信双方都是公有IP地址，应该采用AH来验证，或者将AH认证与ESP验证同时使用

• ESP隧道模式

  • 隧道模式保护的是整个IP包，对整个IP包进行加密

  • ESP插入到原IP头部（含选项字段）之前，在ESP之前再插入新的IP头部

  • 两个IP头部

    • 里面的IP头部是原始的IP头部，含有真实的源IP地址、最终的目的IP地址
    • 外面的IP头部可以包含与里面IP头部不同的IP地址，例如，可以是NAT网关的IP地址，这样两个子网中的主机可以利用ESP进行安全通信

  • 与传输模式一样，ESP头部含有SPI和序号字段；ESP尾部含有填充、填充长度和下一个头字段；如果选用了验证，ESP的验证数据字段中包含了验证数据

  • ESP头部和ESP验证数据字段不被加密

  • 隧道模式中，内部IP头部被加密和验证

  • 而外部IP头部既不被加密也不被验证。不被加密是因为路由器需要这些信息来为其寻找路由；不被验证是为了能适用于NAT等情况

  • ESP隧道模式的验证和加密能够提供比ESP传输模式更加强大的安全功能

  • 因为隧道模式下对整个原始IP包进行验证和加密，可以提供数据流加密服务；而ESP在传输模式下不能提供流加密服务，因为源、目的IP地址不被加密

  • 隧道模式下将占用更多的带宽，因为隧道模式要增加一个额外的IP头部

  • 因此，如果带宽利用率是一个关键问题，则传输模式更合适

  • 尽管ESP隧道模式的验证功能不像AH传输模式或隧道模式那么强大，但ESP隧道模式提供的安全功能已经足够了

ISAKMP协议

ISAKMP概述

• ISAKMP（Internet
  Security Association Key Management Protocol，Internet安全联盟密钥管理协议）由RFC2408定义，定义了协商、建立、修改和删除SA的过程和包格式
• ISAKMP只是为SA的属性和协商、修改、删除SA的方法提供了一个通用的框架，并没有定义具体的SA格式
• ISAKMP没有定义任何密钥交换协议的细节，也没有定义任何具体的加密算法、密钥生成技术或者认证机制。这个通用的框架是与密钥交换独立的，可以被不同的密钥交换协议使用
• ISAKMP报文可以利用UDP或者TCP，端口都是500，一般情况下常用UDP协议
• ISAKMP双方交换的内容称为载荷（payload），ISAKMP目前定义了13种载荷
• 载荷按照某种规则“叠放”在一起，然后在最前面添加上ISAKMP头部，这样就组成了一个ISAKMP报文
• ISAKMP报文按照一定的模式进行交换，从而完成SA的协商、修改和删除等功能

ISAKMP包头部格式

• ISAKMP报文的头部是固定长度的，包含了维护状态、处理载荷必要的信息；头部后面的载荷数目不定

• 组成

  • 发起方Cooikes（Initiator Cookie）

    • 发起方的Cookie，长度为64位（8字节）。Cookie可以帮助通信双方确认一个ISAKMP报文是否真的来自对方
    • 在发起方，如果收到的某报文的应答方Cookie字段和以前收到的该字段不同，则丢弃该报文
    • 同样，在应答方，如果收到的某报文的发起方Cookie和以前收到的该字段不同，则丢弃该报文
    • 这种机制可以防止DoS攻击

  • 应答方Cookie（Responder Cookie）

    • 应答方的Cookie，紧跟在发起方Cookie之后，长度为64位（8字节）

  • 下一个载荷（Next Payload）

    • 表示紧跟在ISAKMP头部之后的第一个载荷的类型值。目前定义了13种载荷

  • 主版本（Major Version）

    • 长度为4位，表示ISAKMP协议的主版本号

  • 次版本（Minor Version）

    • 长度为4位，表示ISAKMP协议的次版本号

  • 交换类型（Exchange Type）

    • 长度为8位，表示该报文所属的交换类型。目前定义了5种交换类型

  • 标志（Flags）

    • 长度为8位，目前只有后3位有用，其余保留，用0填充。后3位的含义从最后一位往前依次为

      • 加密位（encryption）。加密位如果是1，表示ISAKMP头部后面的所有载荷都被加密了；如果是0，表示载荷是明文，没有加密
      • 提交位（commit）
      • 纯验证位（Authentication Only）

  • 报文ID（Message ID）

    • 长度32位，包含的是由第二阶段协商的发起方生成的随机值，这个唯一的报文标识可以唯一确定第二阶段的协议状态

  • 报文长度（Message Length）

    • 长度32位，以字节为单位表示了ISAKMP整个报文（头部 + 若干载荷）的总长度

ISAKMP载荷头部

• 不论何种载荷，都有一个相同格式的载荷头部

• 组成

  • 下一个载荷（Next Payload）

    • 8位字段，表示紧跟在本载荷后面的下一个载荷的类型
    • 通过该字段，不同的载荷可以像链条一样链接起来，每个载荷的类型都在前一个载荷中指明，第一个载荷的类型在ISAKMP头部中指明，最后一个载荷的Next
      Payload类型为0，从而指明这是最后一个载荷

  • 保留（reserved）

    • 保留用，8位字段，全0

  • 载荷长度（Payload Length）

    • 以字节为单位表示的载荷长度（包括载荷头部），16位字段，该字段定义了每个载荷的边界

ISAKMP载荷

• SA载荷
• 建议载荷（proposal）
• 交换载荷（transform）
• 密钥交换载荷（Key Exchange）
• 身份载荷（identification）
• 证书载荷（certificate）
• 证书请求载荷（Certificate Request）
• 哈希（Hash）载荷
• 签名载荷（signature）
• Nonce载荷
• 通知载荷（notification）
• 删除载荷（delete）
• 厂商ID载荷（Vendor ID）

ISAKMP协商阶段

• ISAKMP的协商过程分为两个阶段：阶段1和阶段2

• 两个阶段所协商的对象不同，但协商过程的交换方式是由ISAKMP定义的或者由密钥交换协议（例如IKE）定义的

• 阶段1

  • 这个阶段要协商的SA可以称为ISAKMP SA（在IKE中可以称为IKE SA），该SA是为了保证阶段2的安全通信

• 阶段2

  • 这个阶段要协商的SA是密钥交换协议最终要协商的SA，当IKE为IPSec协商时可以称为IPSec SA，是保证AH或者ESP的安全通信
  • 阶段2的安全由阶段1的协商结果来保证。阶段1所协商的一个SA可以用于协商多个阶段2的SA

交换类型

• 交换类型定义的是在通信双方所传送的载荷的类型和顺序，比如一方先发送什么载荷，另一方应如何应答等

• 这些交换模式的区别在于对传输信息的保护程度不同，并且传输的载荷多少也不同

• 类型

  • 基本交换
  • 身份保护交换
  • 纯认证交换
  • 积极交换
  • 信息交换

IKE协议

概述

• IKE是一种混合型协议，由RFC2409定义，包含了3个不同协议的有关部分：ISAKMP、Oakley和SKEME
• IKE和ISAKMP的不同之处在于：IKE真正定义了一个密钥交换的过程，而ISAKMP只是定义了一个通用的可以被任何密钥交换协议使用的框架
• IKE为IPSec通信双方提供密钥材料，这个材料用于生成加密密钥和验证密钥。另外，IKE也为IPSec协议AH和ESP协商SAa

身份认证方式

• 基于数字签名，利用数字证书来表示身份，利用数字签名算法计算出一个签名来验证身份
• 基于公开密钥，利用对方的公开密钥加密身份，通过检查对方发来的该HASH值作认证
• 基于修正的公开密钥，对上述方式进行修正
• 基于预共享字符串，双方事先通过某种方式商定好一个双方共享的字符串

交换模式

• 主模式
• 积极模式
• 快速模式
• 新组模式
• 前面3个用于协商SA，最后一个用于协商Diffie-Hellman算法所用的组
• 主模式和积极模式用于第一阶段；快速模式用于第二阶段；新组模式用于在第一个阶段后协商新的组