rfc2412.txt

很多RFC的中文文档

被接受则这个域及其后面的所有域必须值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协议中去.没有从中做挑选.

   下列方法可能出现在OAKLEY协议的实现中.

a.	预先共享密鈅.
当双方已经安排好了一个可靠的方法来分配密鈅用于验证他们互相的身份,他
们可以用来验证.在大的系统中这样做显然会使问题放大,但是它是一个可以接
受的限于某种情景下的临时方案.对于预共享密鈅的支持是需要的.

使用预共享密鈅的散列列以及验证算法必须作为状态信息的一部分随密鈅分
配.

预共享密鈅有一个KEYID,密鈅素材sKEYID,KEYID用于预共享密鈅验证选项实