CN106169952A - 一种英特网密钥管理协议重协商的认证方法及装置 - Google Patents

Abstract

本申请提供的一种英特网密钥管理协议(IKE)重协商的认证方法及装置，所述方法包括：在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密；将所述加密后的ID发送至所述对端设备；在收到对端设备发送的ID后，通过所述上一次与对端设备IKE协商得到的SA进行解密；判断所述解密后的ID与上一次协商时得到的ID是否一致；在所述解密后的ID与上一次协商时得到的ID一致的情况下，认证通过。应用本申请实施例，可以实现在英特网密钥管理协议重协商过程中不进行EAP认证也可以确保安全。

Description

一种英特网密钥管理协议重协商的认证方法及装置

技术领域

本申请涉及互联网技术领域，尤其涉及一种英特网密钥管理协议(IKE)重协商的认证方法及装置。

背景技术

随着远程访问中心资源需求的增加，相应地推出了远程访问技术。

通常，在进行远程访问过程中，通信的双方需要先进行密钥协商，从而保证通信过程中数据的安全。这一过程称之为密钥管理协议(Internet Key Exchange，IKE),并且协商出来的结果称之为安全联盟(Security Association，SA)。

具体地，所述IKE协商的过程可以分为两次协商阶段：第一次协商阶段和第二次协商阶段。所述第一次协商阶段用于协商双方公共的用于保护第二阶段的第一密钥，即IKESA；所述第二次协商阶段用于协商保护传输的数据的第二密钥，即IPSec SA。也就是说，IKE协商出来的SA包括了两个部分即IKE SA和IPSec SA。为了进一步增加数据的安全，所述IKE提出了一种重协商机制，即对于所述第一次协商阶段和第二次协商阶段得出的密钥都会存在一个生命周期(lifetime)，在所述生命周期到后，当前密钥就会失效，需要双方重新协商新的密钥。如此，即使原有的密钥被破解，也无法解密用新的密钥保护的数据。

现有技术中，在IKE初次协商时，客户端会需要进行扩展认证(ExtendedAuthentication Protocol，EAP认证)，如果所述客户端通过了EAP认证，则后续IKE重协商就无需新进行EAP认证。然而，由于IKE重协商和IKE初次协商无关联，所以无法确保IKE重协商和IKE初次协商的客户端是同一个客户端。如此，就会存在安全的问题。

发明内容

本申请提供的英特网密钥管理协议(IKE)重协商的认证方法及装置，以解决现有技术中IKE重协商时存在的安全问题。

根据本申请实施例提供的一种英特网密钥管理协议(IKE)重协商的认证方法，所述方法包括：

在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密；

将所述加密后的ID发送至所述对端设备；

在收到对端设备发送的ID后，通过所述上一次与对端设备IKE协商得到的SA进行解密；

判断所述解密后的ID与上一次协商时得到的ID是否一致；

在所述解密后的ID与上一次协商时得到的ID一致的情况下，认证通过。

可选的，所述英特网密钥管理协议为IKEv1。

可选的，所述SA为IKE SA。

根据本申请实施例提供的一种英特网密钥管理协议(IKE)重协商的认证装置，所述装置包括：

加密单元，用于在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密；

发送单元，用于将所述加密后的ID发送至所述对端设备；

解密单元，用于在收到对端设备发送的ID后，通过所述上一次与对端设备IKE协商得到的SA进行解密；

判断单元，用于判断所述解密后的ID与上一次协商时得到的ID是否一致；

确定单元，用于在所述解密后的ID与上一次协商时得到的ID一致的情况下，认证通过。

可选的，所述英特网密钥管理协议为IKEv1。

可选的，所述SA为IKE SA。

本申请实施例中，在进行重协商的第一次协商阶段，本端设备可以通过上一次IKE协商得到的SA将所述本端设备的ID进行加密，并向对端设备发送该加密后的ID；由于重协商是两端同时进行的，所以对端设备也会发送一个加密后的ID；所以，本地在收到所述对端设备发送的ID后，可以通过所述上一次IKE协商得到的SA进行解密；解密后再判断ID是否一致，只有ID一致的情况下，才可以认证通过。也就是说只有具有上一次SA的对端设备才能保证重协商的成功，如果重协商的对端设备与上一次协商的对端设备不是同一台设备，那么本次协商的对端设备也就不具有上一次协商的SA，那么即使在盗用ID的情况下也会由于没有上一次的SA无法实现正确加密，而本端设备也就无法解密得到ID。这就将本次协商与上一次协商相关联，从而保证了其它设备在重协商时无法认证通过，这样即使不进行EAP认证也可以确保重协商的安全。避免了现有技术中重协商时不进行EAP认证所出现的安全问题；还可以避免重协商时进行EAP认证造成交互报文增多所导致的效率较低的问题。

附图说明

图1是本申请提供的非NAT穿越的应用场景示意图；

图2是本申请提供的NAT穿越的应用场景示意图；

图3是本申请一实施例提供的一种英特网密钥管理协议(IKE)重协商的认证方法的流程图；

图4是本申请一实施例提供的英特网密钥管理协议中ID负载格式的示意图；

图5是本申请一实施例提供的一种英特网密钥管理协议(IKE)重协商的认证装置所在设备的一种硬件结构图；

图6是本申请一实施例提供的一种英特网密钥管理协议(IKE)重协商的认证装置的模块图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请实施例中所述的本端和对端是一种相互对应的称呼。例如，在客户端侧，可以认为客户端为本端，而VPN网关设备则为对端。类似的，在VPN网关设备侧，可以认为VPN网关设备为本端，而客户端则为对端。

在相关技术中，远程访问技术例如VPN(Virtual Private Network虚拟专用网)，可以利用共用网络架设专用网络，即可以实现远程客户端访问中心资源服务器。例如位于北京的总公司和位于上海的分公司之间，一般中心资源服务器是位于总公司内的，如果分公司想要访问总公司的中心资源服务器，就可以使用VPN。

一般，广泛使用的为IPSec VPN网络。所述IPSec(Internet Protocol Security，Internet协议安全性)是一种开放标准的框架结构，通过使用加密的安全服务以确保在Internet协议(IP)网络上进行保密而安全的通信。所述IPSec协议并不是一个单独的协议，它给出了应用于IP层上网络数据安全的一整套体型结构，包括了网络认证协议(Authentication Header，AH)、封装安全载荷协议(Encapsulating Security Payload，ESP)、密钥管理协议(Internet Key Exchange，IKE)和用于网络认证及加密的一些算法等。所述IPSec规定了如何在对等层之间选择安全协议、确定安全算法和密钥交換，向上提供了访问控制、数据源认证、数据加密等网络安全服务。

在部署所述IPSec VPN时，网管人员通常可以设置允许多个客户端连接到VPN网关设备，在实现时，一般需要为每一个客户端配置不同的VPN策略和预设密码，从而用以区别不同的用户。然而，在客户端上数量较多时，进行配置的工作量就会很大，费时费力，效率也较低，管理也会不方便。所以，现如今主流的IPSec VPN网关设备优化了配置，只需配置一条VPN策略，就可以允许大量客户端同时接入。如此，只要对接入的客户端分法一个同一个VPN策略即可，但是这样由于所有客户端具有的VPN策略相同，对每个客户端无法单独区分，相应地降低了网络的安全性(例如在出现网络攻击时，无法确定攻击者具体是哪一台客户端)。为了解决一条VPN策略所造成的网络安全问题，所以提出了一种融合在IPSec VPN里的EAP认证机制。该EAP认证，用于要求客户端在接入VPN网关设备时需要提供身份认证信息，VPN网关设备可以集中管理客户端合法的身份认证信息。

为了确保通信过程中数据的安全，通信的双方(即客户端和VPN网关设备)需要先进行密钥协商。这一过程称之为密钥管理协议(Internet Key Exchange，IKE),并且协商出来的结果称之为安全联盟(Security Association，SA)。

具体地，所述IKE协商的过程可以分为两次协商阶段：第一次协商阶段和第二次协商阶段。其中，所述第一次协商阶段用于协商双方公共的用于保护第二次协商阶段的第一密钥，即IKE SA。所述第二次协商阶段用于协商保护传输的数据的第二密钥，即IPSec SA。

需要说明的是，在IKE的第一次协商阶段，双方还会交换自身的ID，并且验证对端的合法性也是协商成功的条件之一。

为了进一步增加数据的安全，所述IKE提出了一种重协商机制，即对于所述SA(包括IKE SA和IPSec SA)会存在一个生命周期(lifetime)，在所述生命周期到后，当前SA就会失效，需要双方重新协商新的SA。如此，即使原有的SA被破解，也无法解密用新的SA保护的数据。

值得一提的是，生命周期(lifetime)可以具有两个维度，包括时间(time)和数据量(volume limit)。一般的，IKE SA的生命周期的time默认为86400秒，即1天，并且没有volume limit；IPSec SA的生命周期的t ime默认为3600秒，即1小时，并且volume limit默认为4608000K字节(bytes)，即4608G字节。

通常，生命周期的时间先过期，在要过期的120秒之前，会自动进行重协商，从而得到新的SA。

在客户端初次接入VPN网关设备时，需要IKE初次协商和扩展认证(ExtendedAuthentication Protocol，EAP认证)。具体地，进行EAP认证时，IKE的第一次协商阶段正常进行，在完成第一次协商阶段后，VPN网关设备可以强制中断第二次协商阶段并发起EAP认证，如果客户端通过EAP认证，则所述VPN网关设备允许进行第二次协商阶段；反之，如果客户端没通过EAP认证，则所述VPN网关设备不允许进行第二次协商阶段。

在所述客户端通过EAP认证后，后续IKE重协商就无需新进行EAP认证。然而，由于IKE重协商和IKE初次协商无关联，所以VPN网关设备无法确保IKE重协商和IKE初次协商的客户端是同一个客户端。也就是说IKE重协商后，存在客户端被冒用的风险，而从导致安全的问题。

如图1所示的非NAT(Network Address Translation，网络地址转换)穿越的应用场景示意图中，用户A(IP为172.3.3.1)通过IKE协商及EAP认证后就可以经VPN网关设备访问服务器。如果用户B(IP为192.3.3.2)盗用用户A的IP和ID，那么用户B就可以以用户A的身份向VPN网关设备发起协商，进而以用户A的身份访问服务器了。如此，就会出现了安全问题。

如图2所示的NAT穿越的应用场景示意图中，用户A(IP为1.1.1.1)通过IKE协商及EAP认证后就可以经VPN网关设备访问服务器。如果用户B(IP为1.1.1.2)盗用用户A的IP和ID，那么用户B就可以以用户A的身份向VPN网关设备发起协商，进而以用户A的身份访问服务器了。如此，就会出现了安全问题。

在另一种方式中，VPN网关设备在每次重协商时，都会要求客户端进行EAP认证，如此来确保每次重协商时的客户端都是同一客户端。这种方式虽然避免了出现安全问题，但是由于需要每次进行EAP认证，所以交换报文就会大量增加，导致重协商效率较低。

为了解决上述问题，请参见图3，为本申请一实施例提供的的一种英特网密钥管理协议(IKE)重协商的认证方法的流程图。本实施例即可以应用在客户端，也可以应用在VPN网关设备。所述方法包括以下步骤：

步骤110：在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密。

本实施例中，如前所述，协商得到的SA具有一个生命周期(lifetime)，由于在所述生命周期到后，当前SA就会失效，所以需要双方重新协商新的SA。生命周期在要过期的120秒之前，会自动进行重协商，从而得到新的SA。所以，可以看出在当前SA过期失效之前，客户端和VPN网关设备之间会进行重协商，而在所述重协商过程中，当前SA还没有过期失效。

本实施例中，就是利用了所述当前SA，而当前SA相对于本次IKE重协商来说，就是上一次IKE协商时得到的SA。

本实施例中，在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密。

例如，在IKE重协商的第一次协商阶段，客户端通过上一次与VPN网关设备IKE协商得到的SA将所述客户端的ID进行加密；VPN网关设备通过上一次与客户端IKE协商得到的SA将所述VPN网关设备的ID进行加密。

本申请实施例中所述的英特网密钥管理协议为IKEv1。

本申请实施例中的SA为IKE SA。

步骤120：将所述加密后的ID发送至所述对端设备。

本实施例中，本端设备可以将所述加密后的ID发送至所述对端设备。

如图4所示，为本申请提供的英特网密钥管理协议中ID负载格式的示意图。其中，所述Next Payload表示下一个有效载荷；所述RESERVED表示是否保留；所述PayloadLength表示有效载荷的长度；所述ID Type表示ID类型；所述DOI Specific ID Data表示指定ID的数据；所述Identification Data表示识别数据。

步骤130：在收到对端设备发送的ID后，通过所述上一次与对端设备IKE协商得到的SA进行解密。

本实施例中，由于两端设备都会向对端发送加密的ID，所以本端设备相应地也会收到对端设备发送的ID，并且该ID也是加密的。

本端设备在收到对端设备发送的ID后，可以通过所述上一次与对端设备IKE协商得到的SA进行解密。

步骤140：判断所述解密后的ID与上一次协商时得到的ID是否一致。

本实施例中，由于每一次协商都会交换ID，所以可以判断本次重协商所解密的ID与上一次协商得到的ID是否一致。

步骤150：在所述解密后的ID与上一次协商时得到的ID一致的情况下，认证通过。

通过本申请实施例中，在进行重协商的第一次协商阶段，本端设备可以通过上一次IKE协商得到的SA将所述本端设备的ID进行加密，并向对端设备发送该加密后的ID；由于重协商是两端同时进行的，所以对端设备也会发送一个加密后的ID；所以，本地在收到所述对端设备发送的ID后，可以通过所述上一次IKE协商得到的SA进行解密；解密后再判断ID是否一致，只有ID一致的情况下，才可以认证通过。也就是说只有具有上一次SA的对端设备才能保证重协商的成功，如果重协商的对端设备与上一次协商的对端设备不是同一台设备，那么本次协商的对端设备也就不具有上一次协商的SA，那么即使在盗用ID的情况下也会由于没有上一次的SA无法实现正确加密，而本端设备也就无法解密得到ID。这就将本次协商与上一次协商相关联，从而保证了其它设备在重协商时无法认证通过，这样即使不进行EAP认证也可以确保重协商的安全。避免了现有技术中重协商时不进行EAP认证所出现的安全问题；还可以避免重协商时进行EAP认证造成交互报文增多所导致的效率较低的问题。

与前述英特网密钥管理协议(IKE)重协商的认证方法实施例相对应，本申请还提供了英特网密钥管理协议(IKE)重协商的认证装置的实施例。

本申请英特网密钥管理协议(IKE)重协商的认证装置的实施例可以分别应用在客户端设备、VPN网关设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请英特网密钥管理协议(IKE)重协商的认证装置所在设备的一种硬件结构图，除了图5所示的处理器、网络接口、内存以及非易失性存储器之外，实施例中装置所在的设备通常根据该英特网密钥管理协议(IKE)重协商的认证的实际功能，还可以包括其他硬件。

请参见图6，为本申请一实施例提供的一种英特网密钥管理协议(IKE)重协商的认证装置的模块图，所述装置可以包括：加密单元210、发送单元220、解密单元230、判断单元240及确定单元250。

其中，所述加密单元210，用于在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密；

所述发送单元220，用于将所述加密后的ID发送至所述对端设备；

所述解密单元230，用于在收到对端设备发送的ID后，通过所述上一次与对端设备IKE协商得到的SA进行解密；

所述判断单元240，用于判断所述解密后的ID与上一次协商时得到的ID是否一致；

所述确定单元250，用于在所述解密后的ID与上一次协商时得到的ID一致的情况下，认证通过。

在一个可选的实现方式中：

所述英特网密钥管理协议为IKEv1。

在一个可选的实现方式中：

所述SA为IKE SA。

综上所述，通过本申请实施例中，在进行重协商的第一次协商阶段，本端设备可以通过上一次IKE协商得到的SA将所述本端设备的ID进行加密，并向对端设备发送该加密后的ID；由于重协商是两端同时进行的，所以对端设备也会发送一个加密后的ID；所以，本地在收到所述对端设备发送的ID后，可以通过所述上一次IKE协商得到的SA进行解密；解密后再判断ID是否一致，只有ID一致的情况下，才可以认证通过。也就是说只有具有上一次SA的对端设备才能保证重协商的成功，如果重协商的对端设备与上一次协商的对端设备不是同一台设备，那么本次协商的对端设备也就不具有上一次协商的SA，那么即使在盗用ID的情况下也会由于没有上一次的SA无法实现正确加密，而本端设备也就无法解密得到ID。这就将本次协商与上一次协商相关联，从而保证了其它设备在重协商时无法认证通过，这样即使不进行EAP认证也可以确保重协商的安全。避免了现有技术中重协商时不进行EAP认证所出现的安全问题；还可以避免重协商时进行EAP认证造成交互报文增多所导致的效率较低的问题。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (6)

1.一种英特网密钥管理协议(IKE)重协商的认证方法，其特征在于，所述方法包括：

在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密；

将所述加密后的ID发送至所述对端设备；

在收到对端设备发送的ID后，通过所述上一次与对端设备IKE协商得到的SA进行解密；

判断所述解密后的ID与上一次协商时得到的ID是否一致；

在所述解密后的ID与上一次协商时得到的ID一致的情况下，认证通过。

2.根据权利要求1所述的方法，其特征在于，所述英特网密钥管理协议为IKEv1。

3.根据权利要求1所述的方法，其特征在于，所述SA为IKE SA。

4.一种英特网密钥管理协议(IKE)重协商的认证装置，其特征在于，所述装置包括：

加密单元，用于在IKE重协商的第一次协商阶段，本端设备通过上一次与对端设备IKE协商得到的SA将所述本地设备的ID进行加密；

发送单元，用于将所述加密后的ID发送至所述对端设备；

解密单元，用于在收到对端设备发送的ID后，通过所述上一次与对端设备IKE协商得到的SA进行解密；

判断单元，用于判断所述解密后的ID与上一次协商时得到的ID是否一致；

确定单元，用于在所述解密后的ID与上一次协商时得到的ID一致的情况下，认证通过。

5.根据权利要求4所述的装置，其特征在于，所述英特网密钥管理协议为IKEv1。

6.根据权利要求4所述的装置，其特征在于，所述SA为IKE SA。