rfc2412.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：马  良  （Blade_Satan  [e-mail]）
译文发布时间：2001-10-11
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                           H. Orman
Request for Comments: 2412                Department of Computer Science
Category: Informational                            University of Arizona
                                                           November 1998
                 
OAKLEY 键决定协议
(RFC2412--The OAKLEY Key Determination Protocol)

本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。
版权声明
 Copyright (C) The Internet Society (1998).  All Rights Reserved.

摘要
       本文档描述了一种名为 OAKLEY的协议，即两个已经验证的部分在安全且加密
密鈅素材问题上取得一致。其基本的机理是Diffie-Hellman密鈅交换算法。

        OAKLEY协议支持完整转发安全性，用户通过定义抽象的群结构来使用
Diffie-Hellman算法，密鈅更新，及通过带外机制分发密鈅集，并且兼容用来管理SA
的ISAKMP协议。
目录
1．简介	3
2. 协议框架.	4
2.1概述.	4
2.2 符号	5
2.2.1 关于消息的描述.	5
2.2 符号指南.	5
2.3 交换密鈅消息概论	7
2.3.1 基本的密鈅交换消息域.	7
2.3.1.1 关于指数的建议	8
2.3.2  映向ISAKMP消息结构的映射.	8
2.4 密鈅交换协议.	9
2.4.1 一个攻击例子.	10
2.4.1.1 空值的域.	12
2.4.1.2 伪随机函数数字签名.	12
2.4.2 隐藏身份的攻击案例.	13
2.4.3 一个不使用Diffie-Hellman算法地私有身份地大胆例子.	15
2.4.3  一个保守的例子.	16
2.4.4  保护密鈅的额外强度.	17
2.5 身份与验证.	17
2.5.1 身份.	17
2.5.2 验证.	18
2.5.3确认验证密鈅.	19
2.5.4 获取身份对象.	19
2.6 加密变换的接口.	20
2.7重发,超时,与错误消息.	20
2.8 私有密鈅的附加安全措施:私有群.	21
2.8.1 定义一个新群.	22
2.8.2 使用一个私有群生成一个密鈅.	23
2.9 快速模式:从旧密鈅中生成新密鈅.	23
2.10 定义并使用预分配密鈅.	24
2.11 分配一个外部密鈅.	24
2.11.1 需要考虑的加密强度.	25
3.指定的生成安全联合.	25
4.ISAKMP的兼容性.	26
4.1 使用已存在的密鈅验证	26
4.2第三方验证.	26
4.3 新群模式.	27
5 安全实现注意事项.	27
6.OAKLEY解析与状态机.	27
7信任有效载荷.	29
附录A群描述符.	29
附录B消息格式.	33
附录C将一个可变精度整数编码.	33
附录D加密强度.	34
附录E著名的群.	34
E1. 著名的群1: 一个 768  比特素数.	35
E2. 著名的群2: 一个1024位素数.	36
E3. 著名的群3: 一个椭圆曲线群定义.	37
E4. 著名的群4: 一个大椭圆曲线群定义.	39
E5. 著名的群5: 一个1536位素数.	41
附录F实现群操作.	42
参考书目:	42

1．简介
         密鈅体制是依靠加密进行数据保护的核心，而且是[RFC2401]中描述的数据包保
护机制的基本组件，例如。一个可升级的安全的用于Internet密鈅分发机制是必要的。
该协议的目标是提供一种机制并且赋予其强大的加密强度。

         Diffie-Hellman密鈅交换算法提供了这样一种机制。它允许两个不同群体就一个共
享值达成一致而不需要加密。这个共享值可以立即用于紧接着的通信的加密。举例来说
    数据传送或是验证。STS协议[STS]提供了向一个安全协议中嵌入该算法的范例，一方
    除了可以确信安全的共享机密，双方还可以确信互相的身份，甚至当一个主动攻击者存
在时。
        因为OAKLEY是一种普通的密鈅交换协议，并且其生成的密鈅被用来加密的数据
的保密时间可能很长，20年或更长，所以协议中的算法能保证在保密期间密鈅的安全
性是很重要的，基于调研当代数学发展后的最乐观的预期性能。因此该协议有两种方式
来增加掌握了大量密鈅交换记录的攻击者（被动攻击者）攻击的困难，这些方式对于生
成用来加密的密鈅是很有用的。

        OAKLEY协议与STS协议是相关的，具有类似的鉴别Diffie-Hellman指数，并用
指数来决定一个共享密鈅，并且都达到了很好的转寄共享密鈅的安全性，但是它与STS
    协议有以下几点不同，

        首先是增加了弱地址确认机制。（“cookies",Phil Karn 在Photuris 密鈅交换协议
中所描述的）用来避免拒绝服务攻击。

        其次的扩充是允许两方共同为协议选取合适的支持算法：加密方法，密鈅产生方
法，验证方法。

第三点，验证并不依赖用于加密所用的Diffie-Hellman指数；相反，验证是通过
        将指数与各方的身份绑定来实现的。

协议不需要两方计算验证前的共享指数。

协议通过使用附加的算法加密增加了起源密鈅的安全性。用于加密的起源密鈅不仅
取决于Diffie-Hellman算法，还和用来安全验证通信双方的加密方法有关。

综上所述，协议清晰的定义了通信双方怎样才能选取数学结构（群的表示和操作）
来执Diffie-Hellman算法；用户可以使用标准的群组或是通过自己定义。用户定义
群组结构更进一步的保证了加密数据的长期数据的安全性。

OAKLEY有几种发布密鈅的方法。除了经典的Diffie-Hellman交换机制外，本协议
    可以基于一个已存在的密鈅产生一个新密鈅并且通过加密来发送一个表面上产生过的
密鈅.

        协议允许两方使用全部或部分纠错和优良的转寄安全特性.它也可用于基于对称加
密或非加密算法的验证功能.包含这样良好的适应性是为了让各方能便利选用用适合它
们自身安全和性能需求的特性.

        本文档从Karn,Simpson关于 Photuris work的工作进展汲取灵感(包括与作者的讨
论),特别要提及的Schertler eral 的关于ISAKMP的文档,以及ISAKMP协议的文档.还受
到了Paul van Oorschot ,Hugo krawcyzk 的论文的启迪.
 
2. 协议框架.
2.1概述.
        OAKLEY协议是用来为通信双方建立一个共享密鈅,通过分配一个标识符和联合经
过验证的身份信息.密鈅的名字可以被用来产生RFC2402,RFC2406协议中的安全联盟.
或是完成其它网络安全目标.

        每个密鈅被用于验证,加密,单向函数的算法组合起来.这些是OAKLEY的辅助算法
    它们在后来定义的由其它协议产生的安全联盟的出现既不必要也不禁止.

        关于怎样对于数据应用一个算法的细节的描述被称为变换.本文档中不包含变换的
定义,其定义可以在分散的RFC文档中找到.

    纠错记号,或者是"cookies",为双方提供一种较弱的源地址验证.cookie交换可以在在它执
行协议中复杂的运算(大整数求幂)之前完成.

        声明OAKLEY使用cookies的两个目的 :纠错和命名密鈅,是很重要的.参与协议的
双方每方都要拿出一个cookies来用于初始化密鈅;这样的cookies对成为密鈅的标识符
    (KEYID),一个可重复使用的密鈅素材.因为具有这样的双重角色,我们将用符号("COOKI 
E-I,COOKIE-R")来命名cookies串与标记"KEYID".可相互替换.

        OAKLEY是作为ISAKMP协议的一个组件来设计的,运行在UDP协议上,使用一个
众所周知的端口,(请查阅RFC中关于端口分配的部分,STDO2-RFC-1700).在技术上唯一
对协议环境的要求是底层协议栈必须能够提供每个消息的远程发送者的因特网地址.因
而,在理论上, OAKLEY可以直接应用于IP协议或是UDP协议之上,如果合适的话,则协
议以及端口分配都是可用的.

        运行OAKLEY的计算机必须提供一个随机数生成器,就像在[RANDOM]中描述的,
因为在该协议的描述中需要随机数资源.任何时候提及"当前"都意味着当前值是由随机
数生成器生成的,同样提及"伪随机"意味着相关的值是由伪随机生成器生成..

2.2 符号
      本节描述文档中用于消息顺序与目录的符号.
2.2.1 关于消息的描述.
        下面的协议交换是用一种简短的符号写成的,这种符号用清晰的方式来传达交换的
本质.下面简要介绍一下这种符号,关于格式及分配值的细节请参看附录.

        本文档中为了简洁的表示消息交换,使用了一种简短的符号来描述每个消息的源地
址,目的地址,以及相关的域.

        箭头("->")表示这消息是否从创始者发向响应者,反之则用("<-").

        消息中的域被命名并用逗号分隔开.该协议遵循惯例,即最先的几个域组成所有消息
的一个固定的头格式

        例如,假设一个包含固定格式消息的交换,四个固定域中两个是"cookies",第三个域
是消息的类型名,第四个域是用高精度的整数来表示的一个数的幂:

  Initiator                                       Responder
             ->    Cookie-I, 0, OK_KEYX, g^x                    ->
             <-    Cookie-R, Cookie-I, OK_KEYX, g^y             <-

        第一行符号表示了两个消息的次序.发起者在开始时发送一个带有四个域的消息给
响应者;其中第一个域包含未定义值"Cookies-I",第二个域包含数字零,第三个域代表
消息的类型为OK_KEYX,第四个域值为抽象群元素g的x次幂.

        第二行是响应者发向发起者的应答消息,第一个域值为"Cookie-R",第二个域
为"Cookie-I"值的一份拷贝,第三个域为的消息类型为OK_KEYX,第四个域为g的y次幂

        消息类型值OK_KEYX为大写代表它是一个唯一的常量.(常量在附录中有定义)

        可变精度的零长度整数在协议中是无效值.

        有时协议会指出一个完整的有效载荷是无效值(通常由密鈅来交换有效载荷).为了
简化分列,有效载荷仍会出现在消息中.

2.2 符号指南.
        Cookie-I与Cookies-R(或是CKY-I与CKY-R)是64位伪随机数.生成伪随机数的方
法必须保证在一个特定时期中代表每个远程IP地址的生成的伪随机数必须唯一.比如
说在小时内.

   KEYID是由发起者及响应者的cookies和说明域所组成的串.是密鈅素材名.

sKEYID用来指示由KEYID命名的密鈅素材,它从不被传送,但它将参与双方的各种
运算.

OK_KEYX与OK_NEWGRP 是截然不同的消息类型.

IDP位标志着在加密分界线后的数据被加密而 NIDP位则意味着没有加密.

        g^x与g^y是群元素编码后产生的结果,在关于群的描述中g是一个特殊的群元素
(参见附录A)且g^x意味着将g作x次幂.就如同在定义中所描述的,这种类型的编码将
产生一个可变精度的整数或是一对可变精度的整数.注意:我们将用g^xy作为g^(xy)的简
写.关于大整数的计算,各种不同的群定义以及基本的数学运算的参考资料请查阅附录F.
        
        EHA0是加密/散列/验证的一个选择列表.每一个选项包含一对值:一个类名及一个
算法名.

        EHAS是分别从EHA0列表中的加密/散列/验证三类中各选一个选项组成的三元集.

        GRP是群及其相关参数名(为32位值),参数包括:整数的大小,数学运算,生成元.现在
已有一些预定义的GRP(768位的….155位与210位的椭圆曲线,参阅附录E),在后续的协
议版本中还可以共享其它的群定义.区分概念GRP与群描述符是重要的,former是后者的
一个名字.
        
         竖线标志是用来表示位字符串的串连.域将被使用编码后的形式串联起来,就如同
出现在它们的有效载荷中的形式.

     Ni与Nr被发起者与响应者分别选取.
    
     ID(I) 和ID(R)分别被用来鉴别发起者与响应者的身份.