logo资料库

RFC2409密钥交换协议IKE.doc

发布时间：2022-06-10 发布人：admin 分类：说明书 资料大小：0.62M 资料格式：doc 举报 版权申诉
第1页 / 共38页
第2页 / 共38页
第3页 / 共38页
第4页 / 共38页
第5页 / 共38页
第6页 / 共38页
第7页 / 共38页
第8页 / 共38页
资料共38页，剩余部分请下载后查看
    组织：中国互动出版网（http://www.china-pub.com/） RFC 文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：sword (sword 译文发布时间：2001-7-25 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本 文档的翻译及版权信息。 zxl1025@chinese.com) Network D. Harkins Request Working Group for Comments: 2409 cisco Systems November 1998 D. Carrel Category: Standards Track Internet 密钥交换（IKE） （The Internet Key Exchange） 本备忘录的现状 本文档指定了一个 Internet 团体的 Internet 标准协议，并请求讨论和建议以作改进。请参 考当前 版本的“Internet 官方协议标准”（STD 1），查看本协议的标准化进程和现状。本文档的分发不 受限 制。 版权通告 Copyright (C) The Internet Society (1998)。保留所有的权利。 目录 2 2 3 1.摘要 2.讨论 3.术语和定义 3 3.1必要的术语 3.2符号 3 3.3完全后继保密 4 3.4安全联盟 4 4.简介 5.交换 5.1 使用签名来验证的 IKE 第一阶段 8 5.2 使用公共密钥加密的第一阶段验证 8 5.3 使用修改过的公钥加密模式来进行第一阶段的验证 10 5 6
    14 26 15 17 Oakley 组 15 5.4 使用共享密钥的第一阶段协商 11 5.5 第二阶段——快速模式 12 5.6 新组模式 5.7 ISAKMP 信息交换 15 6 6.1 第一个 Oakley 缺省组 6.2 第二个 Oakley 组 16 6.3 第三个 Oakley 组 16 6.4 第四个 Oakley 组 16 7. 完整 IKE 交换的负载爆炸 7.1 使用主模式的第一阶段 17 7.2 使用快速模式的第二阶段 18 8. 完全后继保密举例 10.安全考虑 21 11.IANA 考虑 22 11.1 属性类 22 11.2 加密算法类 22 11.3 hash 算法 22 11.4 11.5 12. 鸣谢 23 13.参考 23 附录 A 25 属性分配号码 25 属性种类 种类值 26 附录 B 28 30 作者地址 作者的注释 30 完全版权声明 31 组描述和组类型 存活期类型 23 20 23 1.摘要 ISAKMP ([MSST98])中对验证和密钥交换提出了结构框架，但没有具体定义。ISAKM 被设计 用来独立的进行密钥交换，即被设计用于支持多种不同的密钥交换。 Oakley ([Orm96])中描述了一系列被称为“模式”的密钥交换，并详述了每一种提供的服务 （如密钥的完全后继保密（perfect forward secrecy），身份保护，以及验证）。 SKEME ([SKEME])中描述了一种提供匿名，否认，和快速密钥更新的通用密钥交换技术。 本文档将描述使用部分 Oakley，部分 SKEME，并结合 ISAKMP 的一种协议，它使用 ISAKMP 来得到已验证的用于生成密钥和其它安全联盟（如 AH，ESP）中用于 IETE IPsec DOI 的材料。 2.讨论 本文档描述了一种混合协议。目的是用于以一种保护的方式来协商安全联盟并为它提供经验 证过的密钥生成材料。 本文档中实现的过程可用于协商虚拟专用网（VPN），也可用于远程用户（其 IP 地址不需
    要事 先知道）从远程访问安全主机或网络。 支持客户协商。客户模式即为协商双方不是安全联盟发起的两个终点。当使用客户模式 时，端 点处双方的身份是隐藏的。 本协议并没有实现整个 Oakley 协议，只实现了满足目的所需要的部分子集。它并没有声 称与整 个 Oakley 协议相一致或兼容，也并不依靠 Oakley 协议。 同样，本协议没有实现整个的 SKEME 协议，只使用了用于验证的公钥加密的方法和使用当前 时间 （nonce）交换来快速重建密钥的思路。本协议并不依靠 SKEME 协议。 3.术语和定义 3.1必要的术语 本文档中出现的关键字“MUST”，“MUST NOT”，“REQUIRED”，“SHOULD”，“SHOULD NOT”以及“MAY”的解释在[Bra97]中描述。 3.2符号 下列的符号在整个文档中都使用。 HDR 是 ISAKMP 的报头，它的交换类型是模式。当写成 HDR*时，意味着负载加密。 SA 是有一个或多个提议的 SA 协商负载。发起方可能提供多个协商的提议；应答方只能用一 个 提议来回答。

    _b 指明负载

    数据部分（body）——不包括 ISAKMP 的通用 vpayload 负载。 SAi_b 是 SA 负载的数据部分（除去 ISAKMP 通用报头）——也就是由发起者所提供的 DOI、 情况（situation）、所有的提议（proposal）、以及所有的变换（transform）。 CKY-I 和 CKY-R 分别是 ISAKMP 报头中发起者和响应者的 cookie。 g^xi 和 g^xr 分别是 Diffie-Hellman ([DH])中发起者和响应者的公共值。 g^xy 是 Diffie-Hellman 的共享秘密。 KE 是包含了用于 Diffie-Hellman 交换的公共信息的密钥交换负载。没有对 KE 负载的数 据进行 特殊的编码（如 TLV）。 Nx 是当前时间（nonce）负载；其中 x 可以是 i 和 r，分别代表 ISAKMP 的发起者和响应者。 IDx 是 x 的身份识别负载。x 可以是“ii”或“ir”，分别表示第一阶段协商中的 ISAKMP 发起 者

    和响应者；也可以是“ui”或“ur”，分别表示第二阶段的用户发起者和响应者。用于互联网 DOI 的 ID 负载格式在[Pip97]中定义。 SIG 是数字签名负载。签名的数据是特定于某种交换的。 CERT 是证书负载。 HASH（以及衍生物，如 HASH（2）或 HASH_I）是 hash 负载。hash 的内容是特定于验 证方法 的。 prf(key, msg)是 key 的伪随机函数——通常是 key 的 hash 函数——用于产生表现有伪随机 性的确 定的输出。prf 用于导出密钥和验证（即作为有密钥的 MAC）。（见[KBC96]） SKEYID 是从秘密材料中衍生出的字符串，只有某次交换中的活跃双方才知道。 SKEYID_e 是 ISAKMP SA 用来保护消息的机密性的密钥材料。 SKEYID_a 是 ISAKMP SA 用来验证消息所使用的密钥材料。 SKEYID_d 是非 ISAKMP 安全联盟用来衍生出密钥所使用的密钥材料。 y 表示“x”是由密钥“y”加密的。 -->表示“发起者到响应者”的通信（请求）。 <--表示“响应者到发起者”的通信（回答）。 | 表示信息的串联——如 X | Y 表示 X 和 Y 是串联的。 [x]表示 x 是可选的。 消息加密（ISAKMP 报头后标注有“*”号）必须紧接在 ISAKMP 报头后。当通信是受保护 的 时候，所有 ISAKMP 报头后的负载必须要加密。从 SKEYID_e 产生加密密钥的方法由各个算 法定义。 3.3完全后继保密 在本文档中使用的完全后继保密（PFS）术语是和一个概念相关的，即限制单密钥只能访 问到 受本单密钥保护的数据。要满足 PFS，对于用来保护数据传输的已经存在的密钥来说，它就
    不能用 于衍生出其它的密钥，如果用来保护数据传输的密钥是从其它密钥材料中衍生出来的，则这 些材料 就不能再用于衍生任何其它密钥。 在本协议中提供了密钥和身份的完全后继保密（5.5和 8 节） 3.4安全联盟 安全联盟（SA）是一组用来保护信息的策略和密钥。在本协议中，ISAKMP SA 是协商双 方为 保护之间的通信而使用的共享的策略和密钥。 4.简介 Oakley 和 SKEME 各自定义了建立经过验证的密钥交换的方法。其中包括负载的构建， 信息负 载的运送，它们被处理的顺序以及被使用的方法。 然而 Oakley 定义了“模式”， ISAKMP 定义了“阶段”。两者之间的关系非常直接，IKE 描 述 了在两个阶段中进行的不同的、称为模式的交换。 第一阶段指两个 ISAKMP 实体建立一个安全、验证过的信道来进行通信。这被称为 ISAKMP 安 全联盟（SA）。“主模式”和“积极模式”都能完成第一阶段的交换。“主模式”和“积极模式”只 能在第一阶段中使用。 第二阶段指协商代表服务的安全联盟，这些服务可以是 IPsec 或任何其它需要密钥材料以 及/或 者协商参数的服务。 “新组模式”并不真正在第一阶段或第二阶段中。它紧接着第一阶段，用于建立可在以后协 商 中使用的新组。“新组模式”只能在第一阶段之后使用。 ISAKMP SA 是双向的，即一旦建立，任何一方都可以发起快速模式交换，信息交换，以 及新组 模式交换。由 ISAKMP 基础文档可知，ISAKMP SA 由发起者的 cookie 后跟响应者的 cookie 来标识 ——在第一阶段的交换中各方的角色决定了哪一个 cookie 是发起者的。由第一阶段的交换所 建立的 cookie 顺序继续用于标识 ISAKMP SA，而不管快速模式、信息、新组交换的方向。换句话来 说，当 ISAKMP SA 的方向改变时，cookie 不能交换位置。 由于使用 ISAKMP 阶段，实现中可以在需要时完成快速的密钥交换。单个第一阶段协商可 以用 于多个第二阶段的协商。而单个第二阶段协商可以请求多个安全联盟。由于这种优化，实现 中每个 SA 可以少于一个传输往返，以及少于一次 DH 求幂运算。第一阶段中的“主模式”提供了身份 保护。 当身份保护不必要时，可以使用“积极模式”以进一步减少传输往返。下面的内容中包括了开发 者 对进行优化的提示。同时必须注意当使用公共密钥加密来验证时，积极模式仍然提供身份保
    护。 本协议本 身并没有定义自 己的 DOI 。在第一 阶段中建立的 ISAKMP SA 可以使用 非 ISAKMP 服 务（如 IETF IPSec DOI [Pip97]）的 DOI 和情形（situation）。在这种情况下，实现中可以限制 使用 ISAKMP SA 来建立具有相同 DOI 的服务 SA。另一种方法是使用 DOI 和情形（situation）为 零值（参 看[MSST98]中对这些域的描述）来建立 ISAKMP SA，在这种情况下，实现中可以自由使用 ISAKMP SA 来为任何已定义的 DOI 建立安全服务。如果使用 DOI 为零来建立第一阶段的 SA，第一阶 段中的 标识负载的语法就在[MSST98]中定义，而不是从任何的 DOI（如[Pip97]，它可能会进一步扩 展标识 的语法和语义）中定义。 IKE 使用下面的属性，并且作为 ISAKMP 安全联盟的一部分来协商。（这些属性只属于 ISAKMP 安全联盟，而不属于 ISAKMP 为所代表的服务进行协商而建立的任何安全联盟）： —加密算法 —hash 算法 —验证方法 —进行 Diffie-Hellman 操作的组的有关信息。 所有这些属性是强制性的且必须被协商的。另外，可以可选的协商一个伪随机函数 （“prf”）。（当 前本文档中还没有定义可协商的伪随机函数。在双方都同意时可以私下使用属性值用于 prf 协 商。） 如果没有协商“prf”， 协商的 HMAC (参看[KBC96])的 hash 算法就作为伪随机函数。其它非强 制性 的属性在附录 A 中定义。选择的 hash 算法必须支持原始模式和 HMAC 模式。 Diffie-Hellman 组必须使用一个已定义的组描述（第6节）来指定，或者定义一个组的全部 属性 （第5.6节）。组属性（如组类型或素数——参看附录 A）不能和以前定义的组（不论是保留的 组描 述，还是由新组模式交换后确定并建立的私下使用的描述）相关联。 IKE 的实现必须支持以下的属性值： —使用弱、半弱密钥检查，且为 CBC 模式的 DES[DES]。（弱、半弱密钥参考[Sch96]，并 在附 录 A 中列出）。密钥根据附录 B 进行衍生。 —MD5[MD5]和 SHA[SHA]。 —通过共享密钥进行验证。 —对缺省的组1进行 MODP（参看下面内容）。
    另外，IKE 的实现必须支持3DES 加密；用 Tiger ([TIGER])作为 hash；数字签名标准， RSA[RSA]， 使用 RSA 公共密钥加密的签名和验证；以及使用组2进行 MODP。IKE 实现可以支持在附录 A 中 定义的其它的加密算法，并且可以支持 ECP 和 EC2N 组。 当实现了 IETF IPsec DOI[Pip97]时，IKE 必须实现以上描述的模式。其它 DOI 也可使用 这里描 述的模式。 5.交换 有两中基本方法可以用来建立经过验证密钥交换：主模式和积极模式。它们都通过短暂 的 Diffie-Hellman 交换来产生经过验证的密钥材料。主模式必须要实现；积极模式最好也实现。 另外， 作为产生新密钥材料和协商非 ISAKMP 安全服务机制的快速模式也必须要实现。另外，作为 定义 Diffie-Hellman 交换私有组机制的新组模式应该要实现。实现中不能在交换正在进行时改变交 换类 型。 交换遵从标准 ISAKMP 负载语法，属性编码，消息的超时和重传，以及信息消息——例 如，当 一个提议未被接时，或者签名验证或解密失败时，一个通知响应就被发送，等等。 在第一阶段交换中，SA 负载必须先于任何其它的负载。除了另外的通知表明在任何消息 的 ISAKMP 负载中没有需要特定顺序的需求。 不论在第一阶段还是第二阶段中，在 KE 负载中传递的 Diffie-Hellman 公共值必须在必要 时用零 填充，且长度必须为协商 Diffie-Hellman 组所需要的长度。 当前时间（nonce）负载的长度必须在8到256个字节之间。 主 模 式 是 ISAKMP 身 份 保 护 交 换 的 实 现 ： 头 两 个 消 息 协 商 策 略 ； 下 两 个 消 息 交 换 Diffie-Hellman 的公共值和必要的辅助数据（例如：当前时间（nonce））；最后的两个消息验证 Diffie-Hellman 交换。 作为初始 ISAKMP 交换的验证方法的协商影响负载的组成，而不是它们的目的。主模式的 XCHG 就 是 ISAKMP 身份保护。 类似的，积极模式是 ISAKMP 积极交换的实现。头两个消息协商策略，交换 Diffie-Hellman
    公 共值以及必要的辅助数据，还有身份。另外，第二个消息还要对响应者进行验证。第三个消 息对发 起者进行验证，并提供参与交换的证据。积极模式的 XCHG 就是 ISAKMP 的积极交换。在 ISAKMP SA 的保护下，如果需要，最后的消息可以不发送，这样允许每一方延迟求幂的运算，直到这 次交换 完成以后再运算。积极模式的图示中显示最后的负载以明文发送，这不是必须的。 IKE 的交换并不是 open ended，而是有固定数目的消息。证书请求负载的回执不能扩展传 输或 期待的消息的数目。 积极模式在安全联盟协商中有一定的局限性。因为在消息构建请求中，Diffie-Hellman 交 换所需 要的组不能被协商。另外，不同的验证方法可能进一步限制属性的协商。例如，利用公共密 钥加密 的验证就不能被协商，同时，当使用修改过的公共密钥加密方法来验证时，密码和 hash 又不 能被协 商。当要利用 IKE 能协商大量属性的能力时，就需要使用主模式了。 快速模式和新组模式在 ISAKMP 中没有与之对应的。它们的 XCHG 的值在附录 A 中定义。 主模式，积极模式，以及快速模式进行安全联盟的协商。安全联盟的建议（offer）采取 下列形 式：转换（transform）负载封装在提议（proposal）负载中，而提议负载又封装在安全联盟（SA） 负 载中。第一阶段交换（主模式和积极模式）中如果多个建议提出，则必须采取下列形式：多 个转换 （transform）负载封装在一个提议（proposal）负载中，然后它们又封装在一个 SA 负载中。 对第一 阶段交换可以换种方式来表述：在单个 SA 负载中，不能有多个提议负载，同时，也不允许有 多个 SA 负载。本文档并不禁止在第二阶段的交换中出现这些形式。 本来发起者发送给响应者的建议（offer）的数量是没有限制的，但出于性能考虑，实现 中可以 选择限制将进行检查的建议（offer）的数量。 在安全联盟的协商中，发起者向响应者提出可能的安全联盟的建议（offer）。响应者不能 修改任 何建议的属性，除了属性的编码（参看附录 A）。如果交换的发起者注意到属性值被修改了， 或者有 属性在建议中被增加或删除了，则这个响应必须废弃。
    分享到：
    赞 收藏

    相关推荐

    资料库

    网络技术

    共收录2367份资料，累计7个分类，关注成员有19位，主要包括：综合布线,网管软件,网络监控,网络设备,其它,系统集成,网络基础

    热门标签

    综合布线 网管软件 网络监控 网络设备 其它 系统集成 网络基础

    最新资料