OAKLEY 键决定协议
组织：中国互动出版网（）
RFC文档中文翻译计划（compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：马 良 （Blade_Satan flikic@mail.ustc.edu.cn）
译文发布时间：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)分别被用来鉴别发起者与响应者的身份.
E{x}Ki意味着使用发起者的公开密鈅来加密x,加密使用与验证方法组合在一起
算法,一般为RSA算法.
S{x}Ki意味着使用发起者的签名密鈅来对x签名.签名一般使用与验证组合在一
起的算法.一般为RSA算法,或是DSS算法.
prf(a,b)表示对数据b使用伪随机函数a.可以认为a作为一个键或一个值刻划了函
数prf;在后面的情形中它是一类函数的索引.其中每个函数都计算输入的散列或是单向
混合输出.
Prf(0,b)表示对数据b使用单向函数.
类似早先商讨过的表示一个单独算法的符号,例如,MD5,可以有两种用途.一.一个
键入式的MD5变换将用到一个密鈅"a",二.在单向函数中变换将有一个固定的密鈅
值"0".
术语"变换"是指在相应的RFC中定义的函数,其中会提到"变换"是为了IPSEC中的
AH与ESP定义的(请参阅RFC2401.)
2.3 交换密鈅消息概论
密鈅交换处理是一种确保双方公共密鈅信息状态安全的机制.相关的信息是一个密
鈅名,密鈅素材,双方的身份验证,并且有三种用于验证的算法:加密(用来保护双方的身
份),散列(一个用来保护消息及用来验证的消息域的伪随机函数),与验证(用于相互验证
的基本算法).在附录B中包含关于编码及`这些选项的含义.
主交换模式有五种选择: 无状态cookie交换, 优秀的密鈅素材转寄安全性.身份的
保密, 优秀的保密身份转寄的安全性.使用数字签名(不可否认的),双方可以使用上述性
质的任意组合.
处理的大致过程是这样的:首先交换的发起者在它的第一消息中声明它所想发出的
信息,响应者在应答中提供它所想提供的信息.交换过程一直持续下去直到双方的需求都
得到了满足为止.
选择在每个消息中包含多少信息取决于选择了那个选项.例如: 如果不选无状态
cookie交换,不选身份的保密与优秀的保密身份转寄的安全性,选择了数字签名,这样的话
完成交换只需要三个消息.
附加其它性质会增加决定密鈅素材的回合数.
ISAKMP提供了域来指定使用AH与ESP协议的安全联合的参数.这些安全联合有
效载荷类型将由OAKLEY密鈅素材和算法来加密.但本文档不讨论如何这些内容.
2.3.1 基本的密鈅交换消息域.
在一个OAKLEY密鈅交换消息中由12个域.并不是所有的域都与每个消息相关.
如果一个域是不相关的可以置空值或是不出现(非有效载荷).
CKY-I 发起者 cookie.
CKY-R 响应者 cookie.
MSGTYPE 用于密鈅交换, 可以是 ISA_KE&AUTH_REQ 或
ISA_KE&AUTH_REP; 对于每个新群组定义,
将是 ISA_NEW_GROUP_REQ 或 ISA_NEW_GROUP_REP
GRP 用于交换的 Diffie-Hellman群名.
g^x (or g^y) 表示群生成元幂的可变长度整数.
EHAO or EHAS 加密,散列,验证函数分别被选择和提供.
IDP 发起者是否使用g^xy加密随后信息(优秀的身份转寄安全性)
ID(I) 发起者的身份.
ID(R) 响应者的身份.
Ni 由发起者提供的随机数
Nr 由响应者提供的随机数..
Cookies的这种结构导致执行并不是独立的.Phil Karn建议将它作为一个单向函数
对一个周期性更换的种子数值作用的结果,本地和远程的IP地址,本地与远程的UDP端
口.这样的话,cookies可以保持无状态与周期性的更换.但在OAKLEY中要注意,周期性
的更换种子数值也会导致由其生成的KEYID的也会变化,迫使消除与它有关的任何状态
信息.
为了支持预分配密鈅`,我们建议在cookie中为永久密鈅保留一些空间.上述的编
码依赖于本地实现. .
凡是使用了OAKLEYS的加密函数必须时一种可以保证消息数据安全性与完整性的
加密变换.仅仅在加密块链接模式下使用DES算法是不允许的.可选的与必选的加密变
换将包含任何满足这个标准及在RFC240(ESP)中定义的安全性能.
使用了OAKLEY的单向(散列)函数必须是一种可以用来做密鈅散列或是无密鈅的
加密变换.可选的与必选的加密变换将包含任何满足RFC2406(AH)中定义的安全性能.
在实时环境下,其将是一个关于匹配交换中所用的GRP的强度的平均信息量的可
变精度整数.如果没有指出GRP,那么随机数长度最少为90比特,用于随机素材的伪随机
数生成器应该从长度至少90比特的初始化加密数据开始.参阅RFC 1750
2.3.1.1 关于指数的建议
在理想情况下,用于密鈅交换的熵的指数至少要为180比特.这样可以保证在两次
交换中密鈅素材的绝对独立性(注意如果只有一方选择了随机指数的情况).在实际中,
实现者也许希望多个密鈅交换基于单独的一个关于180比特的熵值 ,与单向散列函数
来保证如果一个密鈅泄漏不会危及到其它密鈅.既然这样,将随机数与cookie的基值与
指数的基值分开,并且用180比特的熵来尽可能快的替换基值将是一个有效的方法.
值0到P-1不能用来当作指数值,实现者要注意检查这些值,并且拒绝接受远程另外
一方发送来的值1到P-1.(P是用来定义一个有限群的素数)
2.3.2 映向ISAKMP消息结构的映射.
所有的OAKLEY消息域都对应于ISAKMP消息有效载荷或有效载荷的组件.ISAKMP中
相关的有效载荷域,是SA有效载荷,AUTH有效载荷,授权有效载荷,密鈅交换有效载荷.
当时,建立ISAKMP协议的框架是一项正在进行的工作,精确的将Oakley消息域映射到
ISAKMP有效载荷也是一项正在进行的工作.(从相关文档中可以获知).
在使用OAKLEY时,OAKMP的一些头部数据块与有效载荷域将为常数值.使用中的精
确值将在解决方案文档中附有的解释文档中发布.
以下将指出每个OAKLEY域将出现在那些ISAKMP消息结构中.解决方案对这种映射
有最终解释权.
CKY-I ISAKMP header
CKY-R ISAKMP header
MSGTYPE Message Type in ISAKMP header
GRP SA payload, Proposal section
g^x (or g^y) Key Exchange Payload, encoded as a variable
precision integer
EHAO and EHAS SA payload, Proposal section
IDP A bit in the RESERVED field in the AUTH header
ID(I) AUTH payload, Identity field
ID(R) AUTH payload, Identity field
Ni AUTH payload, Nonce Field
Nr AUTH payload, Nonce Field
S{...}Kx AUTH payload, Data Field
prf{K,...} AUTH payload, Data Field
2.4 密鈅交换协议.
在OAKLEY密鈅交换中,精确的消息及数字交换取决于发起者与响应者使用了那些
选项.根据这些选项,一次密鈅交换可以用三个或更多的消息来完成.
密鈅决定协议的三个组件是.
1. cookie交换(可选,无状态)
2. Diffe-Hellman 半密鈅交换.(可选,但为转寄安全的基本组成部分)
3. 验证(选项:ID的安全性,使用PFS的ID的安全性,不可否认)
发起者可以提供尽可能少的信息,例如一个空交换,而不附带任何附加信息.另一方
面,发起者也可以在开始时就提供响应者用于验证交换要求及快速完成密鈅决定所需
要的所有信息,前提条件时响应者也同意接受这种方法.如果响应者不接受这种方法,
响应者可以只回复最小数量的信息.(最小限度,比如一个cookie)
验证的方法可以是数字签名,公开密鈅,或一个带外对称密鈅.以上三种不同的方
法导致消息的微小变化,这些微小变化在本节的例子里有详细描述.
如果协议没有按照正常方式中断,发起者有责任重发数据.因此在协议的连续通
信过程中,响应者必须避免抛弃应答信息直到得到发起者的认可.
本节的剩余部分是一些例子,用来讲述怎样使用OAKLEY选项.
2.4.1 一个攻击例子.
以下的例子是描述两方之间怎么样使用三个消息来完成一个密鈅交换.身份在这
里不是保密的,生成密鈅素材使用PFS来保护.
通过使用数字签名,双方将产生一个通信校验,这个校验结果是可以被记录的,稍
后还可以提供给第三方.
由群指数所蕴涵的密鈅素材对完成交换不是必需的.如果有必要推迟计算,执行者
可以保存"x"与"g^y"值并且标注密鈅素材为"不可计算的".稍后可以依据以上信息
继续计算.
Initiator Responder
--------- ---------
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ->
ID(I), ID(R), Ni, 0,
S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}Ki
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP,
ID(R), ID(I), Nr, Ni,
S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, ->
ID(I), ID(R), Ni, Nr,
S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki
NB'NIDP"意味着PFS用来隐藏身份的选项是无效的.因此,在使用一个基于g^xy的
密鈅时,身份是是不用加密的.
NB域在本文档中是用逗号分割开的;在真正的协议消息编码过程中是连接在一起
的,该编码过程在ISAKMP/Oakley解决方案中定义及描述.
例子中的交换结果是一个密鈅的 KEYID=CKY-I|CKY-R与 值
sKEYID=prf(NI|NR,g^xy|CKY-I|CKY-R).
这次交换的大致处理过程如下:
发起者
发起者生成一个唯一的cookie,并将它与预期的响应者的IP绑定,并且它将选取
状态信息如下:GRP(群组标识符),一个伪随机选择的指数x,g^x,EHAO表,随机
数,身份.在EHAO表中,首次的验证选择时一个支持数字签名的算法.并且用来验证
身份 随机数,及群的身份.发起者进一步指出该密鈅在无验证的初始化状态中,并
且为可能存在的重发与请求终止设置计时器.
当想响应者收到这个消息.后,他可以选择忽略所有的信息,仅仅将它视为一个对
cookie的请求,创建无状态.如果CKI-I并没有被IP头中的源地址使用,响应者生成一
唯一的cookie,CKY-R.下一步就依赖于响应者的参数选择.最小的请求响应是将第一
个cookie域设置为零,并且CKY-Y填在第二个域.为了举例,我们必须假定响应者具有
攻击性(另一种情况见第六节),并且接受如下设定:
首次验证选择(必须使用数字签名方法来验证初始化消息),
对于发起者与响应者的身份缺乏足够的的转寄安全保护.
在本例中响应者决定接受所有发起者提供的信息.并验证消息中的签名,并将其
与(CKY-I,CKY-R)对及下列状态信息绑定:
消息的网络源地址与目标地址
无验证的密鈅状态.
提供验证的首次算法.
群组身份,本群组中的一个指数值'y',及消息中的g^x值.
随机值Ni与一个伪随机选择值Nr.
为可能的不正常状态设置的计时器.
响应者通过回应消息计算g^y值,并同时使用私有密鈅ID(R)标记身份与随机数.
并将消息发送给发起者.在所有的交换中,每一方将确信不接受1与g^(p-1)做为一个指
数.
本例中,响应者暗中接受的EHAO表验证类中的首次算法,这是因为响应者无法在
没有接收验证签名的算法的情况下确认发起者的数字签名.响应者的EHAS表也会反映
出他接受的信息.
发起者接受到应答信息并且确认CKY-I是一个有效的网络地址与导入信息的联合.
将CKY-R值加入到(CKY-I,网络地址)对的状态中.并且与所有(CKY-I,CKY-R)对的
状态信息绑定.
通过状态信息来确认响应者的数字签名.(如果确认失败,消息被丢弃).
将g^y加入到他的状态信息.
将EHA选择保促到状态信息中.
任意计算(g^y)^x=(g^x)^y(该计算可以延迟到发送应答消息).
发送应答消息,使用公开密鈅ID(I)签名.
标记密鈅身份(CKY-I|CKY-R)作为验证.并且组合应答消息和签名.
当响应者接受发起者的消息,并且同时签名有效,它将标记密鈅为已验证状态.并将
计算g^xy值并且将该值与密鈅身份绑定.
请注意虽然用于身份保护的PFS并未使用,但用于生成密鈅素材的PFS仍然存在,
因为Differ-Hellman的半密鈅g^x与g^y已经交换.
即使响应者只接受部分发起者的信息,发起者仍然认为协议在处理过程中,发起者
将假定没有被响应者接受的域信息也没有被响应者记录.
如果响应者没有接受攻击性的交换,并且为A函数选择其它的一种算法,这时协议
将不再继续使用来自于首次消息的数字签名算法或签名值.
2.4.1.1 空值的域.
如果响应者不接受所有发起者提供的域,它将在响应的消息中对应的域里填入
NULL值.在第六节中有怎么用按从左至右的方式来选择域的指导方针.如果一个域不
被接受则这个域及其后面的所有域必须值NULL值.
响应者将不记录一个域的任何信息,如果这个域不被接受的话.如果ID's与实
时状态也是NULL值话,经不会有一个基于这些NULL值的数字签名.
2.4.1.2 伪随机函数数字签名.
构造这个攻击性的例子是为了暗示虽然公开密鈅技术已应用于签名,然而.当
双方事先约定好计划与一个公用密鈅时,一个伪随机函数时可以使用的.
如果在EHAO表中的第一个提议是一种"存在密鈅"方法时,则该提议中的密鈅
名用于签名的密鈅素材,该签名由与密鈅名绑定的H算法计算生成.
假设EHAO表中的第一个提议为
EXISTING-KEY, 32
并且与密鈅身份32绑定的算法是MD5-HMAC,密鈅素材是一些比特串,称之为sK32
这时在攻击性交换的第一个消息中将显示签名:
S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki,并且签名的计算由函数:
MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x
| g^y | EHAO)
来执行,( MD5-HMAC函数的精确定义请查阅相关的RFC文档)计算结果将出现在验证
有效载荷中.
2.4.2 隐藏身份的攻击案例.
下列的例子指出在双方之间如何不使用数字签名来完成一次密鈅交换.在验证过
程中,公开密鈅加密算法隐藏了身份.群的指数交换并经过验证.但在交换过车中蕴涵的
密鈅素材(g^xy)是不需要的.
这种方案与前面的数字签名方案有一个很重要的不同,那就是在第一个消息中,
响应者的身份以明文:ID(R')给出.然而, 公开密鈅算法隐藏的身份信息是与之不同的
ID(R).这所以这样是因为发起者必须通知响应者使用那对公开/私有密鈅对来解密.,但
同时,身份信息已被公开密鈅算法所隐藏.
发起者也可以选择放弃对响应者身份的保密,但这样做是不合适的.相反,如果在
响应者的节点上有一个很著名的身份,则用于加密那个身份的公开密鈅算法就可以加密
真正的响应者身份.
Initiator Responder
--------- ---------
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ->
ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr'
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP,
E{ID(R), ID(I), Nr}Ki,
prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <-
-> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP,
prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) ->
Kir = prf(0, Ni | Nr)
NB "NIDP" 意味着隐藏身份的PFS选项没有使用.
NB ID(R')值包含在验证有效载荷中.(在附录B中有描述)
交换的处理过程的大致轮廓如下:
发起者:
发起者生成一个唯一的cookie并且将它与预期的响应者的IP地址绑定.并且选择
状态信息: GRP,g^x,EHAO列表.在EHAO列表中的第一个验证选择是一种算法,并且支持
公开密鈅算法.发起者还命名两个身份在连接中使用,并且将它们输入状态信息中.一个
众所周知的响应者身份也被选中.并且用于这个身份的公开密鈅用来加密随机数Ni
与两个连接用的身份,发起者更进一步说明密鈅处于初始化未经验证的状态,并且为可
能的重发与请求终止设置计时器.
当响应者接受这个消息时,它可以选择忽略所有信息,并且仅仅以一个cookie请
求将其抛出,创建无状态.
如果CKY-I还没有被源地址的IP头所使用,则响应者生成一个唯一的cookie,
CKY-R,如同以前,下一步取决于响应者的选择.最小的所需响应是一个将首个cookie
域设为零的消息,并且CKY-R在第二个域.在本例中,我们假设响应者更为大胆接受如下
设置:
群GRP,第一个验证选择(必须为用于加密有效载荷的公开密鈅算法),缺乏可靠
身份信息的转寄安全性,身份ID(I),ID(R)
响应者必须解密身份与随机数.使用R'的私有密鈅.然后,使用R的私有密鈅
来解密随机数.
响应者现在可以绑定cookie对(CKY-I,CKY-R)与下列状态信息.
消息的网络源地址及目标地址.
密鈅的未验证状态.
每一类的第一个算法在EHAO(加密散列验证算法)列表中
群GRP与y和g^y值在群GRP中.
随机数值Ni与伪随机值Nr.
为可能的不正常状态设置的计时器.
响应者这时用ID(I)的公开密鈅加密状态信息,生成prf值,并将其发送给发起者.
发起者收到回复消息并确认CKY-I是网络地址与此消息的一个有效绑定.
将CKY-R值加入(CKY-I,网络地址)的状态信息中,并且将所有状态信息与(CKY-I,
CKY-R)绑定.
解密身份信息与随机数..
检查prf计算(如果失败,则丢弃该消息).
将g^y加入状态信息中.
在状态信息中保存EHA选择.
计算(g^x)^y(=g^xy)(计算可能会被延迟).并且发送应答消息,使用ID(R)的公开
密鈅加密,同时将KEYID(CKY-I|CKY-R)标记为已验证.
当响应者收到这个消息时,密鈅已被标记为已验证状态.如果还没有这样做.它将计
算g^xy并且将它与KEYID绑定.
密鈅素材sKEYID=prf(Ni|Nr,g^xy| CKY-I|CKY-R)
要指出的是,虽然用于身份保护的PFS没有使用,但用于保护密鈅素材的的PFS仍然
存在,因为Diffie-Hellman 半密鈅g^x,g^y已交换.
2.4.3 一个不使用Diffie-Hellman算法地私有身份地大胆例子.
如果任务中生成密鈅不需要优良转寄安全性,则可以避免消耗计算资源.双方可以
交换随机数与密鈅部分来完成验证任务与生成密鈅素材.使用生成密鈅素材来保护的
长期的加密数据的安全性,依赖于每一方使用的私有密鈅.
在这个交换中,GRP为零值,群指数域则用来存放一个随机数值得替换.
在前面的章节中,首选的算法必须是一个公开密鈅加密系统.其响应为一个
cookie与一个非零指数域.响应者无疑议的接受首选算法,较差的关于身份及生成密
鈅素材的转寄安全性.
Initiator Responder
--------- ---------
-> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, ->
ID(R'), E{ID(I), ID(R), sKi}Kr', Ni
<- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP,
E{ID(R), ID(I), sKr}Ki, Nr,
prf(Kir, ID(R) | ID(I) | Nr | Ni | EHAS) <-
-> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP,
prf(Kir, ID(I) | ID(R) | Ni | Nr | EHAS) ->
Kir = prf(0, sKi | sKr)
NB 在随机状态域中的sKi与sKr值.符号的变化意味着强调他们的熵是设置密鈅素
材的临界值.
NB "NIDP' 意味着用于隐藏身份的PFS选项没有使用.
交换的结果是一个KEYID = CKY-I|CKY-R andvalue sKEYID = prf(Kir, CKY-I |
CKY-R)的密鈅.
2.4.3 一个保守的例子.
在本例中,双方都是很保守的态度.它们使用cookie交换来迟滞状态的创建.
并使
用优良的转寄安全来保护身份信息.所以在本例中,使用公开密鈅加密来验证.数字签
名,或预先共享的密鈅也被采用,如同在前面详细描述的那样.这个保守的例子不交换
随机数,prf's等等.但是它在传送的每个消息中交换多少信息呢?
响应者认为发起者重复CKY-R的能力某种程度上说明消息来源于一个实时的处于
网络中的通讯者,并且这个通讯者与发起者的地网络地址绑定.发起者也有类似的假设
当CKY-I反复的发向发起者.
所有的消息必须含有有效的cookies或者至少是一个零cookie.如果两个cookie
都是零,则意味着一个cookie请求.如果只是发起者的cookie为零,则是一个对
cookie请求的响应.
消息中的信息如果违反cookie规则,那么将降将不能用于任何的OAKLEY操作.
发起者与响应者必须就EHA算法的一个集合达成一致.不能发起者使用一个集合,
而响应着使用另一个算法集合.发起者在初始化时必须至少提供一个MD5或是DES算法
没有说明的域将填为空值.
Initiator Responder
--------- ---------
-> 0, 0, OK_KEYX ->
<- 0, CKY-R, OK_KEYX <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO ->
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*,
ID(I), ID(R), E{Ni}Kr, ->
<- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <-
E{Nr, Ni}Ki, ID(R), ID(I),
prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS )
-> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP,
prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS ) ->
Kir = prf(0, Ni | Nr)
*当IDP值有效时,验证有效载荷被所选的加密算法加密,算法使用的是密鈅素材
prf(0,g^xy).(这个变换定义了加密算法将说明怎么样从密鈅素材中选取密鈅比特)
这样的加密附加于任何公开密鈅的,请看附录B.
在第一个消息中,几个域被忽略了,这些域目前都是空值.
首次交换中允许响应者使用无状态cookies,如果响应者按照习惯生成cookies
即允许在没有保存的情况下使他们生效,如同在Photuris中,则是可能的.甚至如果发
起者,包含一个cookie在他的初始化请求中,响应者仍使用无状态cookies,仅仅从他的
应答中忽略CKY-I,并且记录发起者的cookies直到 下一条消息出现.
在交换完成以后,双方都要计算,共享密鈅素材sKEYID,prf(Ni| Nr, g^xy | CKY-I
| CKY-R),prf是一个从EHA列表中散列类中选择的随机函数.
每一方都认为远程对方反复发送Ni或Nr值得能力作为一种证明.与远程方沟通,
并确定远程方的身份.
在分析本次交换中,需要注意虽然IDP选项确信身份是被一个暂时的密鈅g^xy保
护,但要验证它自己不依赖于密鈅g^xy.通过有步骤地验证g^x,g^y值是基本的.从而可
以使验证不形成一个循环过程.第三方可以通过中间人代理的方式介入来使发起者与响
应者使用不同的g^xy值.虽然这样一个攻击,可能对窃听者的身份有所启发,但验证会
失败.
2.4.4 保护密鈅的额外强度.
随机数Ni,Nr用来提供生成任务密鈅保密所需的额外的尺度.这样做使密鈅的安
全性依赖于两个不同问题:在群G中的离散对数问题,与破坏实时加密的方案问题.如果
使用RSA来加密.则第二个问题大约等价于分解RSA的公开密鈅.
为了验证,密鈅类型,确认方法,证明的需求都必须声明.
2.5 身份与验证.
2.5.1 身份.
在OAKLEY交换中,发起者提供发起者与响应者的身份,这个模型首先要求
发起者的身份,然后是响应者的.
如果没有指定任何一个身份,则身份将从IP包头部的源地址与目的地址提取.
如果发起者没有提供一个身份,响应者可以使用本地策略允许的任一个身份应答.
发起者可以通过终止交换来拒绝接受.
响应者也可以使用不同于发起者所建议的身份来应答,发起者可以继续交换来默认
接受或是终止交换来拒绝接受.
2.5.2 验证.
首先对另一方身份的验证是任何密鈅交换体系的核心.Internet通信必须产生一个
可以升级的标准来解决这个问题.OAKLEY必须遵循这个标准.在写本文档的同时,还没
有这样一个标准.虽然有了一些雏形.这个文档试图描述怎么样将已有的一些标准融入
OAKLEY协议中去.没有从中做挑选.
