moqingsong
论坛版主
论坛版主
  • 注册日期2002-04-07
  • 最后登录2011-02-03
  • 粉丝0
  • 关注0
  • 积分74分
  • 威望71点
  • 贡献值0点
  • 好评度10点
  • 原创分0分
  • 专家分0分
阅读:1542回复:0

RFC2408:Internet安全联盟和密钥管理协议(ISAKMP)

楼主#
更多 发布于:2002-05-22 16:33
RFC2408:
Internet安全联盟和密钥管理协议
(ISAKMP)
Internet Security Association
and Key Management Protocol (ISAKMP)








摘要:
该文档为Internet团体指定了一个Internet标准协议栈。它描述了利用安全概念来建立安全联盟(SA),以及Internet环境中密钥所需的协议。安全联盟协议协商,建立,修改和删除安全联盟,以及Internet环境所需的属性。Internet环境中,有多种安全机制,对于每一种安全机制都有多个可选项。密钥管理协议必须健壮,以处理Internet团体公钥的产生,以及私人网络私钥的产生。Internet安全联盟和密钥管理协议(ISAKMP)定义了认证一个通信同位体,安全联盟的建立和管理,密钥的产生方法,以及减少威胁(例如:服务否认和重放攻击)的过程。在Internet环境里,对于建立和维护安全联盟(经过IP 安全服务和其它安全协议),这些都是必不可少的。

目录
1  介绍 5
1.1  需要的技术术语 5
1.2  所需的商议 6
1.3  什么能够被协商? 6
1.4  安全联盟和管理 7
1.4.1  安全联盟和注册 7
1.4.2  ISAKMP的需求 7
1.5  认证 8
1.5.1  认证中心 8
1.5.2  实体命名 8
1.5.3  ISAKMP的需求 9
1.6  公钥加密系统 9
1.6.1  密钥交换属性 10
1.6.2  ISAKMP的需要 10
1.7  ISAKMP保护 11
1.7.1  防止障碍(服务否认) 11
1.7.2  拦截连接 11
1.7.3  中途攻击 11
1.8  多播通信 12
2  术语和概念 12
2.1  ISAKMP术语 12
2.2  ISAKMP布置 13
2.3  协商状态 14
2.4  标识安全联盟 15
2.5  其它 17
2.5.1  传输协议 17
2.5.2  保留域 17
2.5.3  反障碍标记的创建 17
3  ISAKMP载荷 18
3.2  ISAKMP头格式 18
3.2  普通载荷头 21
3.3  数据属性 22
3.4  安全联盟载荷 23
3.5  提议载荷 24
3.6  传输载荷 25
3.7  密钥交换载荷 27
3.8  标识载荷 28
3.9  证书载荷 29
3.10  证书请求载荷 31
3.11  哈希载荷 32
3.12  签名载荷 33
3.13  NONCE载荷 33
3.14  通告载荷 34
3.14.1  通告信息类型 36
3.15  删除载荷 38
3.16  厂商ID载荷 40
4.6  证明唯一交换 41
4.7  主动交换 43
4.8  信息交换 44
5  ISAKMP有效载荷处理 44
5.1  普通信息处理 45
5.2  ISAKMP头操作 45
5.3  特殊有效载荷头处理 47
5.4  安全联盟有效载荷处理 48
5.5  提议有效载荷处理 48
5.6  转换有效载荷处理 49
5.7  密钥的交换有效负载的处理 50
5.8  鉴定有效负载的处理 50
5.9  处理的证书有效负载 51
5.10  处理的证书请求有效负载 52
5.11  哈希值有效负载的处理 53
5.12  签名有效负载的处理 53
5.13  目前有效负载的处理 54
5.14  通知有效负载的处理 54
5.15  删除有效负载的处理 56
6  结论 58
A  ISAKMP 安全协会属性 59
A.1  背景 / 基本原理 59
A.2  因特网 IP 安全 DOI 的分配值 59
A.3  支持安全协议 59
A.4  ISAKMP 鉴定类型值 60
A.4.1  ID_IPV4_ADDR 60
A.4.2  ID_IPV4_ADDR_SUBNET 60
A.4.3  ID_IPV6_ADDR 60
A.4.4  ID_IPV6_ADDR_SUBNET 60
B定义新的解释域 60
B.1  状况 61
B.2  安全策略 61
B.3  命名计划 62
B.4  为指定安全服务的句法 62
B.5  有效负载说明 62
B.6  定义新交换类型的 62
安全考虑 62
IANA 考虑 63
解释域 63
支持的安全协议 63
鸣谢 63
参考数目 64
作者地址 66
版权声明 67

1  介绍
此文档描述了因特网安全联盟和密钥管理协议(ISAKMP)。ISAKMP结合加密安全的概念,密钥管理和安全联盟来建立政府,商家和因特网上的私有通信所需要的安全。
因特网安全联盟和密钥管理协议(ISAKMP)定义程序和信息包的格式来建立,协商,修改和删除安全联盟(SA)。SA包括所有如IP层服务,传输或应用层服务或流通传输的自我保护的各种各样的网络协议所需要的信息。ISAKMP定义交换密钥生产的有效载荷和认证数据。这些格式为依靠于密钥产生技术,加密算法和验证机制的传输密钥和认证数据提供了一致的框架。
ISAKMP与密钥交换协议的不同处是把安全联盟管理的详细资料从密钥交换的详细资料中彻底的分离出来。不同的密钥交换协议中的安全道具也是不同的。但一个支持SA属性格式,和谈判,修改与删除SA的共同的框架是需要的。
把函数分离为三部分给一个完整的ISAKMP执行的安全分析增加了复杂性。因此分离在有不同安全要求的系统之间是不被赞成的,而且还应该将更多ISAKMP服务的发展的分析变得简单化。
ISAKMP被用来支持在所有网络堆栈的层上的安全协议的SA的谈判。ISAKMP通过集中安全联盟的管理减少了在每个安全协议中复制函数的数量。ISAKMP还能通过一次对整个服务堆栈的协议来减少建立连接的时间。
剩下的部分,第一节建立安全协议的动机和ISAKMP主要组成部分的概要,也就是安全联盟和管理,认证,公钥密码系统及混合的条款。第二节讲述和ISAKMP相关的术语和概念.第三节不同ISAKMP有效载荷的格式。第四节描述ISAKMP的有效载荷在一种认证方法中是怎样被组织到一起来作为交换类型来建立安全联盟和执行密钥交换。另外,安全联盟的协商,删除和错误通知也将被讨论。第五节描述在ISAKMP交换环境中包括错误句柄和安全行为的有效载荷的处理。附录提供ISAKMP必要的属性值和在ISAKMP中定义一个新的解释域(DOI)的所需要求。
1.1  需要的技术术语
词MUST , MUSTNOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY和OPTIONAL出现在文档时,他们的解释都在[RFC-2119]中描述。
1.2  所需的商议
ISAKMP在[DOW92]中扩充的声明,为了较多的安全认证和密钥交换必须被组合道包括安全联盟的交换中。安全服务需要的通信依靠着个体的网络结构和环境。机构正在建立私有个人网络(VPN)作为企业内部互联网,它将需要需要一套在VPN中通信的安全功能和在VPN之外的通信的许多可能的不同安全功能来支持地理上分开的组织成份,消费者,供应者,分消人,政府和其它。在大组织中的部门也许需要一些安全联盟在网络内来分离协议数据,其它的安全联盟在同样的部门内通信。游动的用户希望“打电话回家”表现出另一个安全需要。这些需要必须由带宽来调节。很少人的组的安全需要也许是要建立“信任网”。 ISAKMP交换提供这些向同等地位的人提出用户为达成协议有关安全的共同的一套支持的证实,而且保护的方法的安全功能性的能力归于多种多样的网络组,也就是一个共同的安全联盟。
1.3  什么能够被协商?
安全联盟必须支持不同安全协议的加密算法,认证机制和密钥生成算法,作为IP的安全。安全联盟还要支持底层协议面向主机的定向证书和高层协议中面向用户的证书。算法和机制的独立在通信定向协议,路由协议,和链路层协议中需要应用于如电子邮件,远程登陆,和文件传输。ISAKMP为安全协议,应用,安全需求和网络环境这个宽广的范围提供了一个共同的安全联盟和密钥生成协议。
ISAKMP不能被限制于任何特定的加密算法,密钥产生技术或安全机制。这种适应性在某些前提下是有好处的。首先,它支持在动态的通信环境下被描述。其次,特定安全机制和算法的独立性为向前移动的路径提供了更好的机制和算法。当改良的安全机制被发展或当前的加密算法受到新的攻击,认证机制和密钥交换被发现时,ISAKMP允许在没有发展出一个新的完整的KMP或到当前的一个路径的情况下,更新算法和机制。
ISAKMP对它的认证和密钥交换部分有基本的要求。这些要求拒绝被否认得服务,重放,窃听和拦截攻击。因为这些类型的攻击,所以被作为目标的协议是很重要的。完整的安全联盟的支持提供独立的机制和算法,及针对议定书威胁的保护措施是ISAKMP的强度支持。
1.4  安全联盟和管理
安全联盟是两个或多个描述实体实怎样利用安全服务来安全通信的实体之间的发关系。这种关系被一套能被认为是两个实体间的契约的信息来描述。这个信息必须被所有的实体承认和共享。有时这个信息被作为SA单独引用,但这只是存在地联系中的一个实例。这种关系和信息的存在,是为安全的相互操的实体提供作所需的一致的安全信息。所有的安全实体必须尽可能的坚持SA的安全通信。当访问SA的属性时,实体用一个指针或标识符访问安全参数索引(SPI)。[SEC-ARCH]提供IP安全联盟(SA)和安全参数索引(SPI)定义的详细内容。
1.4.1  安全联盟和注册
SA所需和被IP安全(AH,ESP)要求的属性在[SEC-ARCH]中被定义。属性为IP安全SA指定了包括但是不被限制的认证机制,加密算法,算法模式,密钥长度和初始化向量(IV)。其它提供的算法和机制的独立的安全协议必须定义SA所需要的属性。把特殊的SA定义从ISAKMP中分开对于能为所有可能的安全协议和应用产生SA束的确信的ISAKMP是十分重要的。
注意:见[IPDOI]中对SA属性的讨论,当定义安全协议或应用时它是可信的。
为了使不同网络实体之间的特殊属性能被容易的识别,这些属性必须被分配标识符,并且这些标识符必须由认证中心注册。IANA为英特网提供这项功能。
1.4.2  ISAKMP的需求
安全联盟的建立必须经过密钥管理协议为IP基本网络的定义。SA被用来支持各种动态网络环境下的安全协议。正如认证和密钥交换必须被链接来提供担保密钥是由认证机关[DOW92]来建立,SA的指定必须被链接到认证和密钥管理协议。
ISAKMP提供协议交换来在跟在一些协议的益处中协商实体的安全联盟体制协商的实体间建立安全联盟(如ESP/AH)。首先,最初的协议交换允许一套基本的安全属性被支持。这套基础为并发的ISAKMP交换提供保护。它还指定将被作为ISAKMP协议的一部分被执行的认证方法和密钥交换。如果一套基础的安全属性已经被放到协商实体之间的话,初始的ISAKMP交换可能被略过,并且安全联盟的建立可能被直接的进行。在这套基础的安全属性被支持,初始的身份认证和必需的密钥产生后,建立的SA能被调用ISAKMP的实体用于并发通信。这套基础的SA属性必须被实现来提供在附录A中定义的互用的ISAKMP。
1.5  认证
在建立安全网络通信时十分重要的一步是在通信的另一端对实体的认证。有很多认证机制能被用到。认证机制实现在两种情况之下――脆弱和强壮。在一个脆弱的网络发送清晰的密钥或未被保护的认证信息,受到网络刺探者读它们的威胁。另外,以低熵发送单行无用的缺乏选择的信号也很危险,会受到刺探信息者的猜测攻击。因为[IAB]中新近的声明,当口令能被用于建立认证时,他们不被认为包含在这个内容内。数字签名,如数字签名标准(DSS)和RSA签名,是基于强大的人证机制下的公钥体制。当应用公钥数字签名时,每个实体都需要一个公钥和一个私钥。证书是数字签名认证体制中的实质部分。证书绑定一个特殊实体的身份和其它可能的安全信息,如特权,清除和象限到它的公钥上。基于数字签名的认证需要一个信任的第三方和证书中心来生成,签名和适当地分发证书。如DSS何RSA这样的数字签名和证书的详细信息可参看[Schneier]。
1.5.1  认证中心
证书需要一个基本组织来产生,确认,撤回,管理和分配它。IPRA[RFC-1422]已经为IETF制定了这个基本组织。IPRA认证PCA。PCA控制CA,CA证明用户和从属的实体。当前有关证书的工作包括DNS安全扩展,将提供DNS内有标识的实体密钥。PKIX工作组正在为X.509证书指定因特网轮廓。它将继续在工业中发展X.500目录服务,它能给用户提供X.509证书。美国邮电部门正在发展一个CA层次。NIST公钥结构工作组已经在这个领域开始工作。DOD MISSI纲要已经开始为美国政府发展一个证书基本组织。作为选择,如果基础组织存在,信任证书的PGP网能被用于提供用户认证和相互信任的用户团体的保密。
1.5.2  实体命名
一个实体的名字是它的身份,并且它证书里的公钥被绑在它里面。CA必须为证书的出版定义名字的符号。作为CA是怎样定义策略名字的例子,可以参看UNINETT PCA策略声明[Berge]。当证书被校验时,名字被校验,并且名字在CA地领域里将有意义。例子是把DNS服务器CAs做成他们服务的域和节点的DNS安全扩展。源档案由公钥提供,数字签名就在这些密钥中。有关密钥的名字是IP地址和域名,它们表明了实体访问DNS的信息。信任网是另外一个例子。当信任网建起时,名字被绑到公钥中。在PGP中,名字通常是实体的电子邮件地址,它来表明只有明白电子邮件的人的意思。另外的信任网可以使用一个完全不同的命名方案。
1.5.3  ISAKMP的需求
必须在ISAKMP交换上提供强大的认证。不能认证另一端实体身份的安全联盟和密钥的生成对话将被怀疑。不经过认证就不能信任实体的身份,它的访问控制是可疑的。当加密(ESP)和完整性(AH)保护被偷听者并发的通信时,没有经过认证的SA合密钥可能是敌对方执行一个拦截攻击生成的,而且可能正在偷取你所有的私人数据。
数字签名算法必须被用到ISAKMP的认证部分。但ISAKMP不要求一个特殊的签名算法或认证中心(CA)。ISAKMP允许一个实体初始化通信时指出支持哪个CA。当选择了一个CA后,协议提供所需的信息来支持实际的认证交换。协议支持不同认证中心,整数类型和证书交换标识的认证设备。
ISAKMP利用基于公钥加密的数字签名来进行身份认证。其它可利用的强壮的认证系统被指定为ISAKMP附选的认证体制。其中一些认证系统依赖一个称为密钥分配中心(KDC)的信任的第三方组织来分配会话密钥。Kerberos是一个例子,这儿信任的第三方组织是Kerberos服务器,它掌管了在这个网络域内所有客户和服务器的密钥。客户拿其密钥的证明给服务器提供认证。
ISAKMP规范没有指定与信任的第三方组织(TTP)或证书目录服务器通信的协议。这些协议在TTP河整数目录服务器中被定义,并且指定了它对外的范围。这些额外服务和协议的使用将在密钥交换这个文档中被描述。
1.6  公钥加密系统
公钥加密系统是用户获得共享密钥的最具灵活性,可升级性和高效性的方法,而且是会话密钥支持的英特网用户相互操作的最多方法。许多有不同属性的密钥产生算法对用户使有利的。密钥交换协议的属性包括密钥产生方法,认证,对称,完全向前保密和向后通行保护。
注意:加密密钥能在一个相当长的时间内保护信息。但这是以假定被用于通信保护的密钥在使用后被破坏的基础上的。
1.6.1  密钥交换属性
密钥产生:为密钥产生使用公共的密钥加密的两个共同的方法是密钥运输和密钥产生。一个密钥传输的例子是RSA算法用来加密一个随机产生的会话公共密钥。加密随机密钥被送到拥有私钥的接收者处。在这一点上两端都有相同的会话密钥,但它是被基于从通信的一端输出而创造的。密钥传输方法的好处是它比下面的方法有更小的计算开销。D-H算法说明了公钥加密体制中密钥的产生。D-H算法由两个用户交换公共信息开始。每个用户用他自己的秘密信息算术的结合其它用户的公共信息来来算出共享密钥值。这个共享值能被用作共享密钥或用来把随机产生的会话密钥的密码化密钥锁上。这种方法基于两个用户的公共和私有信息来产生会话密钥。D-H算法的好处是密钥用于加密信息是基于两个用户和一个到另一个密钥交换的。这些加密算法在[Schneier]中详细描述。在两个密钥生成配置上有许多变化,而这些变化是没必要相互操作的。
密钥交换认证:密钥交换能在协议中或协议完成后被认证。协议中密钥交换的认证是当协议中止之前每个组织提供它有私有回话密钥的证明时被提供的。证明能被在协议交换中加密私有会话密钥中已知的数据提供。在协议之后的认证必须发生在并发的通信中。如果秘密会话密钥没有被所希望的组织建立,协议中的认证被指为未初始化的并发的通信。
对称密钥交换:如果每个组织都能不影响产生的密钥,初始化交叉运行的交换和被交换的信息的话,密钥交换可提供对称。合乎需要,密钥的计算不要求任何一个党知道它们的初始化交换。当需要对称密钥交换时,在整个密钥管理协议中的对称能预防攻击。
完全向前保密:正如[DOW92]中的描述,如果长期密钥资料败露来自先前的通信的交换的钥匙的秘密调解的话,认证密钥交换协议提供完全向前保密。完全向前保密的属性不适用于没有认证的密钥交换。
1.6.2  ISAKMP的需要
一个认证密钥交换必须被ISAKMP支持。用户应该根据他们的必要条件的补充性选择密钥算法。ISAKMP不指定一个特殊的密钥交换。但[IKE]描述了在ISAKMP连接中的Oakley密钥交换的协议。当选择一个包括方法,完全向前保密,计算开销,密钥由第三者保存附带条件委付盖印的契约,和密钥长度的密钥产生算法时,需要应该被评估。基于用户的要求,ISAKMP允许一个实体初始化信息来指出支持那种密钥交换。在选择了一个密钥交换后,协议提供需要的信息来支持实际的密钥产生。
1.7  ISAKMP保护
1.7.1  防止障碍(服务否认)
在众多可利用的安全服务中,对于服务否认得保护常常被视作最难的。一个“cookie”或(TCT)的目的在于不为了决定其确实性花费过度的中央处理器资源而保护计算的资源免受攻击的影响。一个指向加强CPU公钥操作的指针能阻碍一些企图的服务否认。对服务否认得绝对保护是不可能的,但这个防止阻碍标记为让它容易的操作提供了一种技术。防止阻碍标记的使用在[Karn]中由Karn和Simpson来介绍。
在第四节中被说明的交换应被注意,加密机制应被用于废弃的连接机制地连接中。攻击者仍能用伪造IP地址的包注往服务器,并导致状态被创建。这种侵入内存管理的技术应该被协议用到ISAKMP中,不通过初始化,防止阻碍的状态,在[Karn]中被做。
1.7.2  拦截连接
ISAKMP用连接认证,密钥交换和安全联盟交换来防止拦截连接。这种连接防止攻击者在密钥和安全联盟交换期间从允许的认证到完成,然后从模仿的一个实体跳到另一个。
1.7.3  中途攻击
中途攻击包括窃听,插入,删除和窜改信息,返回信息给发送人,回复旧信息和重发信息。ISAKMP的特征能成功的防止这些类型的攻击。ISAKMP交换连接防止协议交换中的信息插入。ISAKMP协议状态机制被定义,因此删除信息不能引起一个局部的SA被建立,状态机制将清理所有的状态,并返回到空闲状态。状态机制还防止信息返回带来的危害。每个新的SA建立的各种不同资料的一个新的cookie的需求防止包括重发旧信息的攻击。ISAKMP强大的认证要求防止用其它故意的组织建立的SA。信息能被发往不同目的地或修改,但这将被删除,并且SA不会被建立。ISAKMP规范定义了已经发生的不正常进程和不正常的组织推荐的通报。
1.8  多播通信
多播通信被希望和单播通信有相同的安全服务,和能引进所需的附加安全服务。多播传输的分配SPIs的发行在[SEC-ARCH]中被介绍。多播安全发行在[RFC-1949]和[BC]中被讨论。ISAKMP将来的扩展将支持多播密钥分配。有关多播安全有关的流出的发行,参考因特网草案[ RFC-2094 ]和[ RFC-2093 ],描述在这个域中Sparta的研究。
2  术语和概念
2.1  ISAKMP术语
安全协议:安全协议由网络堆栈中单独点的实体组成,为网络通信提供安全服务。例如IPSEC ESP和IPSEC AH是两个不同的安全协议。TLS是另外一个例子。安全协议能提供不止一项服务,如可在一个模块中提供完整性和机密性。
保护组:保护组是必须被各种安全协议执行的安全服务的列表。例如,安全组可能包括IP ESP中的DES加密合IP AH中的密钥MD5。组中的所有保护必须被作为一个单独的单元对待。因为安全服务在不同的安全协议里有敏感的交互作用,并且组的影响必须被作为整体分离和校验,所以它是必要的。
安全联盟(SA):安全联盟是安全协议指定的一套完整的定义必须的服务和机制的参数来保护安全协议域中的传输。这些参数包括算法标识符,模式,加密密钥等。SA由它的安全联盟协议指定。
ISAKMP SA:被ISAKMP服务应用的SA来保护它自身的传输。2.3和2.4节提供ISAKMP SA的更多详细资料。
安全参数索引(SPI):安全联盟的标识符,相关的一些安全协议。每个安全协议由它自己的“SPI-space”。一组唯一的识别一个SA。SPI的唯一性是依靠的实现,但是能每个系统每个协议或其他的任意选择被形成了。依靠于DOI地附加信息能必然的标识一个SA。DOI也能决定哪个SPI在通信期间被发出。
解释域:解释域(DOI)定义有效载荷的格式,交换类型和如安全政策或加密算法和模式这样的相应安全信息命名的协定。DOI标识符被用于ISAKMP有效载荷的有效载荷。系统必须同时支持多个DOI。DOI的概念是基于TSIG CIPSO 工作组先前的工作的,但扩展安全实验室的解释包括命名和安全服务的解释。DOI的定义:
* 状态:这套信息将被用于决定所需的安全服务。
* 这套安全政策必须而且能被支持。
* 被提供的安全服务的规范的语法。
* 命名相关安全信息的方案,它包括加密算法,密钥交换算法,安全策略分配和认证中心。
* 不同有效载荷内容的特殊格式。
* 所需的附加交换类型。
IETF IF安全DOI的规则在[IPDOI]中被介绍。用户化DOI的详细规则在分散的文档中被介绍。
状态:状态包含系统认为重要的所有相关安全信息来决定被保护的正在协商的会话密钥所需要的安全服务。状态可以包含地址,安全分类,操作模式等。
提议:提议是减少优先选择顺序的一个系统认为可接受来在被给定的状态下保护传输的保护状态的列表。
有效载荷:ISAKMP定义有效载荷的几种类型,它们被用于传送在被定义DOI格式下的如安全联盟数据或密钥交换数据地信息。有效载荷由一般有效载荷头和ISAKMP中不透明的一个八位串组成。ISAKMP用指定DOI来综合和解释有效载荷。多级有效载荷能在一个单独的ISAKMP信息中被传送。第三节有更多有效载荷类型的详细资料,[IPDOI]中有IETF IF安全DOI有效载荷的格式。
交换类型:交换类型是ISAKMP交换中信息的规范,有效载荷类型被用于提供一套特殊的安全服务,如共享者匿名,密钥资料的完全向前保密,共享者的身份认证等。4.1节定义一套ISAKMP交换类型的默认设置。其它交换类型被加入到所需的支持的附加密钥交换。
2.2  ISAKMP布置
图一是在ISAKMP地网络建筑中的系统环境中的高级布置图。协商安全服务的一个重要部分是把所有的个体SA堆栈看作一个单元。这被作为一个“保护组”。
     +------------+        +--------+                +--------------+
     !     DOI    !        !        !                !      应用    !
     !     定义   ! <----> ! ISAKMP !                !      进程    !
     +------------+    --> !        !                !--------------!
    +--------------+   !   +--------+                ! Appl 协议    !
    !   密钥交换   !   !     ^  ^                    +--------------+
    !     定义     !<--      !  !                           ^
    +--------------+         !  !                           !
                             !  !                           !
            !----------------!  !                           !
            v                   !                           !
        +-------+               v                           v
        !  API  !        +---------------------------------------------+
        +-------+        !                Socket 层                    !
            !            !---------------------------------------------!
            v            !              传输协议 (TCP / UDP)           !
     +----------+        !---------------------------------------------!
     !   安全   ! <----> !                     IP                      !
     !   协议   !        !---------------------------------------------!
     +----------+        !                  链路层协议                 !
                         +---------------------------------------------+
     图1:ISAKMP关系图
2.3  协商状态
ISAKMP提供了两个协商状态。第一个,两个实体同意在他们之间如何保护协商传输,建立ISAKMP SA。ISAKMP SA被用于保护所需SA协议的协商。两个实体能协商多个ISAKMP SA。
第二个协商状态被用于建立其它安全协议的安全联盟。第二个协商能被用于建立多个安全联盟。在状态被安全协议用来保护多个信息/数据交换的过程中,安全联盟被ISAKMP建立。
当两个状态方法对最简单的方案有更高的启动价值时,对于大多数案例有理由是有益的。
首先,实体(例如ISAKMP服务器)能穿过几个第二的阶段协商提取第一个阶段的成本。允许多个SA被建立,而不必为每个在同等地位的通信建立重复的SA。
第二,在第一个状态提供安全属性期间,安全服务为第二个状态协商。例如,在第一个状态协商后,ISAKMP SA提供的密码能提供身份保护,还默认得允许简单的第二个状态交换的使用。另一方面,如果这个通道在第一个状态不提供适当的身份保护期间被建立,第二个状态必须协商适当地安全机制。
第三,相当有适当的ISAKMP SA降低ISAKMP管理活动的成本-不用ISAKMP SA给你的“信赖路径”,将必须SA的为每个错误通知或删除穿过完整的重新认证。
每个状态的协商用定义的ISAKMP交换或DOI中定义的密钥交换来完成。
注意,安全服务被每个协商状态不同的应用。例如,不同的组织在每个协商状态期间被认证。在第一个状态,被认证的组织可能是ISAKMP服务器/主机,当第二个状态时,用户或应用级程序被认证。
2.4  标识安全联盟
当ISAKMP在两个系统之间引导安全通道时,它不能假设安全服务存在,必须对自己提供一些安全保护。因此,ISAKMP认为一个ISAKMP安全联盟与其它类型的不同,并且ISAKMP在它们自己的名称空间内处理它自己的ISAKMP SA。ISAKMP用ISAKMP头中的这两个cookie域来标识ISAKMP SA。ISAKMP头中的信息ID和建议有效载荷中的SPI域在SA建立期间被用来为其它安全协议标识SA。这四个域的解释是依靠操作发生的地点的。
下面的表格现出了在SA建立期间几个域的存在和不存在。以下的域对于各种SA建立相关的操作是必须的:ISAKMP头中的cookies,ISAKMP头的信息ID域,和建议有效载荷中的SPI域。列中的‘X’表示这个值是必须被提出。列中的‘NA’表示列中的值不适用于操作。
  #             操作              I-Cookie  R-Cookie  Message ID    SPI
 (1)  开始ISAKMP协商                X         0         0           0
 (2)  回答 ISAKMP SA 协商            X         X         0           0
 (3)  初始化其它 SA 协商             X         X         X           X
 (4)  回答其它SA 协商               X         X         X           X
 (5)  其它 (KE, ID, etc.)            X         X         X/0         NA
 (6)  安全协议 (ESP, AH)             NA        NA        NA          X
在表的第(1)行,初始值包括初始ISAKMP头中的cookie域,使用程序概括见2.5.3和3.1节。
表中的第二行,回答包括ISAKMP头中的初始化和回答cookie域,使用程序概括见2.5.3和3.1节。附加信息能在同等地ISAKMP间交换,依靠ISAKMP交换类型在状态1协商中的使用。一旦状态1交换完成,初始值和回答cookies北包含在同等地ISAKMP并发通信的ISAKMP头中。
在状态1协商期间,初始值和回答cookie决定了ISAKMP SA。因此,建议有效载荷中的SPI域变得多余,并且被设置成0或包含信号发送实体的cookie。
在表的第三行中,初始化连接一个协议的信息ID,它包含在SA 建议中。这个被连接在每个建议中协议信息ID和初始化的SPI被发往回答者。一旦状态2协商完成,SPI将被安全协议使用。
表中的第(4)行,回答包括相同的信息ID和回答SPI来连接接收建议中的每个协议。这个信息被返回给初始者。
表中的第(5)行,初始者和回答者用ISAKMP头中的信息ID域来保持进程协议协商的轨迹。这只适用于状态2交换,并且这个对状态1的交换的值必须是0。这是因为混合的cookie标识了ISAKMP SA。在建议有效载荷中的SPI域不适用是因为建议有效载荷只在SA协商信息交换中使用。
表中的第(6)行,状态2协商完成。安全协议使用SPI来决定哪个安全服务和机制来应用于它们之间的通信。第6行中的SPI值不是建议有效载荷中的SPI域,但SPI域包含在安全协议头中。
在SA的建立中,SPI必须被产生。ISAKMP被用于处理可变得SPI。这用建议有效载荷中的SPI尺寸域在SA建立期间来完成。SPI的处理将在DOI详细资料中介绍。
当安全联盟被初始建立,一方假设初始者的身份和另一个回答者的身份。一旦SA被建立,同等实体的源初始者和回答者能初始化状态2协商。因而,ISAKMP SA在实际中使双向的。
附加的,ISAKMP允许初始者和回答者在协商过程中控制。当ISAKMP被用来允许包括分建议的SA协商时,初始者能通过仅仅按照初始者本地的安全政策做一个比例维持一些控制。一旦初始者发出一个包含不止一个建议的建议,初始者将放弃对回答者的控制。一旦回答者正在控制SA的建立时,它将能使这个策略优先于初始者提供的多选择的环境里的初始者。选择建议最匹配回答本地安全策略和返回这个选择的初始者来完成它。
2.5  其它
2.5.1  传输协议
ISAKMP能被在任何传输协议或IP自身上执行。执行必须包含ISAKMP在端口500上使用UDP的发送和接收性能。UDP端口500被IANA指派给DSAKMP。执行能附加支持在其它传输协议或IP自身的ISAKMP。
2.5.2  保留域
在ISAKMP有效载荷中保留域的存在被用来保护字节队列。在一个数据报被发出时,所有ISAKMP协议中的保留域必须被设置成0。接收者应该检查0值的保留域,如果没有找到其它值,则丢弃这个数据报。
2.5.3  反障碍标记的创建
cookie产生的详细资料是所依靠的执行,但必须满足这些基本的要求:
1. cookie必须依赖于特殊的组织。这防止一个从cookie使用一个真实IP地址和UDP端口的攻击者,并且用Diffie-Hellman所需的随机的IP地址或端口来覆盖受害者。
2. 它不可能为其它任何发出的实体产生cookie,这将被那个实体接收。这个暗示意味着发出的实体必须用cookie的产生和并发确认中的本地秘密信息。不可能从任何特殊的cookie中推导出这个秘密信息。
3. cookei产生函数必须非常快的阻止对CUP资源的故意攻击。
Karn\'s关于创建cookie方法的提议是在IP源地址和目的地址上实现快速哈希(例如,MD5),UDP源端口和目的端口以及一个本地产生的秘密随机数。ISAKMP要求cookie对每个SA机构都是唯一的以便帮助防止重播攻击,因此,数据和时间必须被添加到被哈希的信息中。产生的cookie被放在ISAKMP(在3.1章节中描述)头启动和应答机cookie域中。这些域有8个字节长,因此需要产生的cookie也是8字节长。通知和删除信息(参看3.14,3.15和4.8章节)是单向传输并且在现有ISAKMP SA保护下运行,不需要生成新的cookie。有一种例外情况是在完成SA建立之前,第一阶段交换期间通知信息的传输。3.14 和4.8章节提供了辅助细节。
3  ISAKMP载荷
 ISAKMP载荷提供模块化的组建块来构造ISAKMP消息。ISAKMP中载荷的存在和顺序由在ISAKMP头(见图2)中所定位的交换类型字段来定义。ISAKMP载荷类型将在3.4节的3.15中进行讨论。ISAKMP载荷,消息和交换(见4节)的描述用网络八字节顺序来表示。
3.2  ISAKMP头格式
 一个ISAKMP消息有固定的头格式,见图2,后面紧跟一个变化的载荷号。固定头简化了分析,如果考虑协议所带来的好处,分析软件将变得简单,并且更容易实现。固定头包括协议所需的信息,来维持状态,处理载荷,并可能防止服务否认或重放攻击。ISAKMP头字段定义如下:
* 发起者cookie(8字节)--实体的cookie对应于一个SA建立请求,或SA通告,或SA删除。
* 应答cookie(八字节)--实体的cookie用来应答一个SA建立请求,和SA通告,或SA删除。
                         1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            发起者                             !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            应答                             !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   下一个载荷  ! MjVer ! MnVer !    交换类型   !     标志      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            消息  ID                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                             长度                              !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图2:ISAKMP 头格式
* 主版本(4 bit)-表示使用的ISAKMP协议的主版本。实现是基于此ISAKMP的Internet草案时,主版本号必须定为1。实现是基于以前ISAKMP的Internet草案时,主版本号必须定为0。实现永远也不能接受一个主版本号大于它自己的数据包。
* 微版本(4字节)--表示使用的ISAKMP协议的文版本。实现是基于此ISAKMP的Internet草案时,微版本号必须定为0。实现是基于以前ISAKMP的Internet草案时,微版本号必须定为1。给定同样的主版本号,实现永远不能接受一个微版本号大于它自己的数据包。
* 类型互换(1个八字节)--表示所用的交换类型。这表示消息和载荷遵循所用的交换顺序。
                        交换类型                值
                         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
* 标志(1个八字节)--表示特定的选项,用于设定ISAKMP交换。以下在标志字段中指定的标志,从最低有效位开始,如:在标志字段中加密位是0,提交位是1,鉴别位是2。其他剩余位必须在传输前设为0。
按第一贴的“给分”键,给分。
游客

返回顶部