非IMS终端应用增强型通用鉴权架构的方法

摘要

本发明提供一种非IMS终端通过IMS终端代理应用增强型通用鉴权架构的方法。该方法包括如下步骤：步骤a，非IMS终端发送不带GBA参数的应用请求消息给NAF，以及NAF响应该应用请求消息，指示非IMS终端先和引导服务功能实体执行鉴权处理，非IMS终端向IMS终端代理发送GBA请求消息。步骤b，IMS终端代理在接收到非IMS终端的GBA请求信息后，查询一关系映射表，获取该非IMS终端的设备标识，该关系映射表存储非IMS终端的标识信息与非IMS终端的设备标识的对应关系，该GBA请求信息包括非IMS终端的标识信息以及要访问的NAF的标识。步骤c，IMS终端代理为非IMS终端生成与所述设备标识相关的衍生密钥，步骤d，引导服务功能实体为NAF生成衍生密钥，其与步骤c中生成的衍生密钥相同。

说明书

技术领域

本发明涉及第三代移动通信领域，特别涉及一种扩展通用鉴权架构的方法。

背景技术

3GPP(第三代移动通信系统)中定义了一种通用鉴权框架(GBA)。如图1所示，通用鉴权框架通常由IMS(IP多媒体业务子系统)用户(UE)、引导服务功能实体(BSF)、用户归属网络服务器(HSS)、用户定位功能实体(SLF)和网络业务应用实体(NAF)组成。UE和BSF通过Ub接口连接，BSF和NAF通过Zn接口连接，UE和NAF通过Ua接口连接，SLF和BSF通过Dz接口连接，BSF和HSS通过Zh接口连接。BSF用于与UE进行互验证身份，同时生成BSF与用户的共享密钥Ks；HSS中存储用于描述用户信息的签约文件，同时HSS还兼有产生鉴权信息的功能。SLF用于当存在多个HSS时，协助BSF查找相应的HSS。NAF用于为UE提供网络业务。

当用户UE第一次向NAF发出应用请求时，不知道NAF是否需要GBA过程，就不携带GBA参数。如果NAF要求进行初始的GBA过程，则在发给UE的响应消息中会告诉UE进行GBA过程。

当用户UE需要使用某种业务时，如果用户知道该业务需要到BSF进行互鉴权过程，则直接发送鉴权请求到BSF进行互鉴权。否则，用户会首先和该业务对应的NAF联系，如果该NAF使用GBA通用鉴权框架，并且发现该用户还未到BSF进行互认证过程，NAF则通知该用户到BSF进行互鉴权以验证身份。

参照图2，描述UE和BSF执行互鉴权的流程。

首先，在步骤710中，UE向BSF发送GBA请求消息，该GBA请求消息包括该用户的标识。

接着，进入步骤720中，BSF向HSS获取认证向量，BSF通过与HSS的交互获取该UE的鉴权向量信息，如AUTN、RAND、IK(加密密钥)、CK(完整性密钥)以及XRES等。

接着，进入步骤730，BSF向UE返回挑战响应消息，该消息中包含AUTN、RAND。具体地说，BSF在接收到UE的鉴权向量信息后，将鉴权向量信息中的AUTN和RAND，一并携带在挑战响应消息中，并将该消息返回给UE。其中，AUTN用于验证BSF的身份，RAND用于使UE获取与BSF侧相同的IK和CK。

接着，进入步骤740，UE通过运行AKA算法，检查AUTN的有效性以鉴权网络，得到IK和CK，并生成RES(鉴权响应值)。具体地说，UE在接收到BSF返回的挑战响应消息后，通过对其中AUTN的有效性检查验证对端BSF的身份，根据其中的RAND计算得到与BSF侧相同的IK和CK，并生成RES。

接着，进入步骤750，UE再次向BSF发送GBA请求消息，并在该消息中携带RES。其中，RES用于验证UE的身份。

接着，进入步骤760，BSF检查RES的有效性以鉴权UE。BSF通过判断GBA请求消息中的RES是否与从HSS处获取的XRES一致，从而对UE进行鉴权。

接着，进入步骤770，BSF根据从HSS处获取的IK和CK生成Ks。此外，BSF还为共享密钥Ks定义了一个有效期限，以便Ks进行定期更新。

接着，进入步骤780，BSF将B-TID以及Ks的有效期携带在成功响应消息中发送给UE。具体地说，BSF为标识和UE之间本次鉴权交互事务而分配一个B-TID，使该B-TID与Ks、UE的私有用户标识相关联，以便以后BSF可以根据该B-TID查找出相应的Ks，并且，为Ks定义一个有效期，以便Ks进行定期更新。BSF将该B-TID以及Ks的有效期携带在成功响应消息中。

接着，进入步骤790，UE在接收到该成功响应消息后，得到B-TID和Ks的有效期，并将该B-TID和Ks的有效期保存在UE侧，并生成Ks。该共享密钥Ks是作为根密钥来使用的，用于衍生出与各NAF通信时的加密密钥。

完成了如图2所述的过程后，UE和BSF之间就共享了一个根密钥Ks。并且UE可以利用公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)推导出与想要访问的NAF之间的衍生的共享密钥Ks_NAF，其中NAF_Id可以标识出想要访问的NAF，RAND是一个随机数，IMPI是指UE的私有身份标识，″gba-me″代表字符串，KDF是密钥导出函数的缩写。这样，UE侧就获取了该衍生的共享密钥Ks_NAF。剩下的任务就是NAF如何获取该衍生的共享密钥Ks_NAF。只有NAF和UE都获取了Ks_NAF，才能建立双方通讯的安全通道。

参照图3，描述NAF获取Ks_NAF的流程：

首先，在步骤901中，用户在收到B-TID后，生成一个携带了该B-TID的请求连接消息，并发给NAF。NAF收到用户的连接请求后，生成一个携带了NAF标识和B-TID的认证请求信息，然后在步骤902中向BSF进行查询。

接着，在步骤903中，BSF根据该B-TID查找相应的Ks后，再使用与用户侧相同的算法计算出衍生的共享密钥Ks_NAF，然后在认证响应消息中把Ks_NAF、Ks_NAF的有效期限、BSF与UE之间的相互鉴权的时间、以及其他应用相关信息发给NAF。NAF在步骤904中将这些信息保存在NAF上。

接着，在步骤905中，NAF将应用响应消息发送给UE。

通过如上步骤，NAF确认该用户是经过BSF认证的合法用户，同时NAF和UE也就共享了由Ks衍生的密钥Ks_NAF，从而这两者在后续的通信中可以进行安全通信。

当用户发现Ks即将过期，或NAF要求用户重新到BSF进行鉴权时，用户就会重复图2和图3的处理重新到BSF进行互鉴权，以得到新的共享密钥Ks及衍生密钥Ks_NAF。

如图4所示，描述了NAF发现衍生的共享密钥Ks_NAF已经过期时UE和NAF之间执行的处理。详细的，UE在步骤1001中发送应用请求消息给NAF后，NAF发现衍生的共享密钥Ks_NAF已经过期，则在步骤1002中通知UE需要重新执行和BSF之间的相互鉴权过程。

以上所述UE上包含IP多媒体业务身份标识模块ISIM(IP MultimediaServices Subscriber Identity Module)/通用集成电路卡UICC(UniversalIntegrated Circuit Card)，而且UE上既包含GBA客户端，也包含NAF应用客户端。但是随着通用鉴权框架应用范围越来越广泛，出现一些新的应用场景，例如在传统的没有ISIM/UICC模块因而也就不具备ISIM能力的用户终端上，或者NAF应用客户端与GBA客户端分离的终端(多个外围终端采用同一个ISIM/UICC访问网络业务)上如何应用GBA。为了描述简便，我们统一称之为非IMS终端。

TISPAN(ETSI的NGN网络标准)中定义了一种称为IMS驻留网关IRG(IMS Residential Gateway)的功能实体，用于为那些非IMS终端提供访问IMS业务的安全通道。

这些非IMS终端包括但不限于SIP电话、软电话，PC，PDA等。IMS驻留网关功能上相当于一个B2BUA(背靠背用户代理)实体，其具有一“ISIM

ON UICC(通用集成电路卡上的IP多媒体业务身份标识模块)”模块，用来为这些非IMS终端提供访问IMS业务的安全通道，并且该模块上存储了一个私有用户标识(IMPI)和多个公共用户标识(IMPU)。该IRG面向非IMS终端的本地接口可能是网线、数据线、USB、蓝牙、或红外线等接口。我们也可以称这种实体为IMS终端代理。

这种应用场景下，一个IMS用户可能具备多个非IMS终端设备，并且所有这些非IMS终端采用同一个ISIM/UICC模块(位于IMS终端代理上)访问网络业务。另外，NAF应用客户端位于IMS终端代理以外的一个或者几个非IMS终端上，因此与执行GBA的客户端(位于IMS终端代理上)不在同一个设备上。我们称之为增强的GBA框架，如图5所示。在该增强型GBA框架中，具有SIP电话、PC、软电话等非IMS终端，IMS终端代理B2BUA为这些非IMS终端生成衍生密钥Ks_NAF，这些IMS终端利用该生成的衍生密钥Ks_NAF和NAF通信。当多个外围终端设备共享一个UE上的GBA客户端时，如果这些外围终端设备中的某两个或者某几个访问同一个NAF时，还会出现多个外围终端设备采用同一个衍生密钥Ks_NAF与某一个NAF通信的情况，造成安全隐患：如果其中一个被攻破，另外一个也会不攻自破。

如图6所示，描述了现有的针对如图5所示的增强型GBA架构的鉴权方法。

首先，在步骤801中，非IMS终端发送应用请求给NAF。NAF在步骤802中指示非IMS终端采用GBA。

接着，在步骤803中，非IMS终端发送一请求给UE(IMS终端)，请求UE生成密钥，该请求中包含该非IMS终端的设备标识。

接着，通过和图2中的步骤701-709类似的步骤807-808生成基本密钥Ks，且在步骤808中根据该基本密钥Ks和设备标识生成衍生密钥。然后在步骤809中将衍生密钥和B-TID发送给非IMS终端。

接着，在步骤810中，非IMS终端将包括B-TID和设备标识的认证请求发送给NAF。NAF在步骤811中发送一密钥请求给BSF，请求生成衍生密钥，该密钥请求包括设备标识、B-TID和NAF标识。

BSF在步骤812中计算出衍生密钥，并在步骤813中将该衍生密钥返回NAF。

从而，非IMS终端和NAF之间可以通过该衍生密钥执行安全通信。

但是，该方案具有如下缺点：

1.该方案是针对3GPP移动终端的，对于固定终端不适用。

2.网络侧需要能够管理所有这些终端设备，需要为每个终端设备分配唯一的设备标志。由于终端制造商和网络运营商可能并不是一家，并且终端类型多种多样，管理上比较困难。

3.所有的非IMS终端都需要知道自己的设备标志，并主动携带这个设备标志给UE(包含ISIM/UICC模块)和NAF。这样可能存在非IMS终端进行设备标志伪装攻击(类似IP地址伪装攻击)的隐患。

4.该方案没有考虑新旧版本互通的情况。

发明内容

本发明的目的在于提供一种更安全的非IMS终端应用增强型通用鉴权架构的方法。

依照本发明的非IMS终端通过IMS终端代理应用增强型通用鉴权架构的方法如下步骤：步骤a，非IMS终端发送不带GBA参数的应用请求消息给网络业务应用实体，以及网络业务应用实体响应该应用请求消息，指示非IMS终端和引导服务功能实体执行鉴权处理，步骤b，IMS终端代理在接收到非IMS终端的GBA请求信息后，查询一关系映射表，获取该非IMS终端的设备标识，该关系映射表存储非IMS终端的标识信息与非IMS终端的设备标识的对应关系，该GBA请求信息包括非IMS终端的标识信息，步骤c，IMS终端代理为非IMS终端生成与所述设备标识相关的衍生密钥Ks_NAF，步骤d，引导服务功能实体为网络业务应用实体生成衍生密钥Ks_NAF，其与步骤c中生成的衍生密钥Ks_NAF相同。

依照本发明，由于与衍生密钥Ks_NAF的生成相关的设备标识是由网络侧实体生成的，因此非IMS终端不需要主动将其设备标识发送给B2BUA，从而防止了非IMS终端进行设备标志伪装攻击的隐患。此外，不同的非IMS终端访问同一个NAF时，衍生的共享密钥Ks_NAF是不一样的，这样即使一个Ks_NAF泄密，也不会影响其他的Ks_NAF，从而保证了安全性。此外，设备标识是由B2BUA连同衍生共享密钥Ks_NAF一起传给非IMS终端，这样保证了非IMS终端上不容易进行伪标识攻击。

附图说明

图1为GBA架构的框架图。

图2为GBA架构中UE和BSF相互鉴权的流程图。

图3为GBA架构中NAF获取Ks_NAF的流程图。

图4为GBA架构中密钥过期时UE和NAF执行的处理的流程图。

图5为增强型GBA架构的框架图。

图6为现有的增强型GBA架构的鉴权方法的流程图。

图7为依照本发明的UA和NAF之间的初始引导过程的流程图。

图8为依照本发明的UA和BSF之间的引导交互过程的流程图。

图9为依照本发明的多个UA和BSF之间的引导交互过程的一实施方式的流程图。

图10为依照本发明的多个UA和BSF之间的引导交互过程的另一实施方式的流程图。

图11为UA和NAF之间建立安全联盟的流程图。

图12为密钥过期时UA和NAF执行的处理的流程图。

具体实施方式

本发明提出了一个或者多个非IMS终端通过IMS终端代理B2BUA实体应用增强通用鉴权架构(GBA)的一种解决方法。该B2BUA实体包括NGN的IRG(IMS驻留网关)实体，或3GPP/3GPP2中具有类似功能的实体。该非IMS终端可以是移动网络或者固定网络中的非IMS终端。在下面的描述中，利用UA来统一表示各种非IMS终端。此外，在本发明中，假设这些UA和B2BUA之间的接口是安全的。而且，B2BUA不能主动发起GBA过程，必须由UA来触发。依照本发明，不同的非IMS终端访问同一个NAF时，即使其中一个非IMS终端的密钥泄密，也不会影响到其他的非IMS终端的安全性。

在本发明中，首先设置一关系映射表，该关系映射表包括UA的用户名(或者终端地址/终端端口号)和唯一标识该UA的设备标识之间的映射关系。该关系映射表可以预先配置在B2BUA上，也可以配置在HSS上。当该关系映射表配置在HSS上时，B2BUA通过在从BSF下载鉴权向量的同时将该关系映射表下载，或者通过其他方式获取。

当UA第一次向NAF发出应用请求(或者通过B2BUA)时，如果不知道是否使用GBA参数和NAF通讯或者和NAF之间的共享密钥已经过期，就不携带任何GBA参数。NAF发现UA发来的应用请求中没有携带GBA参数，就会指示UA(或者通过B2BUA指示UA)进行GBA过程。接着，UA请求B2BUA和BSF之间进行GBA过程，BSF生成根密钥Ks和引导事务标识B-TID并返回给B2BUA。然后，B2BUA通过查询上述映射表，找出对应的设备标识，并通过扩展公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id，设备标识)生成Ks_NAF，其中NAF_Id为要访问的NAF的ID，RAND是一个随机数，IMPI是指UA的私有身份标识，″gba-me″代表字符串，KDF是密钥导出函数的缩写。B2BUA将Ks_NAF、B-TID、设备标识、密钥有效期一起发给UA。然后UA(或者通过B2BUA)在发给NAF的请求消息中携带B-TID和获取的设备标识。NAF在发给BSF的请求消息中也携带获取的设备标识。BSF通过相同的公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id，设备标识)生成Ks_NAF，并将其发给NAF。这样，NAF和UA就通过B2BUA共同获取了一个公共密钥Ks_NAF。而且，对于不同的UA，只要使用的用户名不一样，相应的Ks_NAF也就不一样，这样即使一个Ks_NAF泄密，也不会影响到其他Ks_NAF。从而保证了安全性。

下面，参照附图，详细描述依照本发明UA(非IMS终端)应用增强型GBA的方法。

如图7所示，描述了UA和NAF之间的初始引导过程的两种方式。

方式1包括图中所示的步骤101-102。当UA1第一次发送应用请求消息到NAF时，如果不知道NAF是否支持GBA，则在步骤101中将一应用请求消息发送给NAF，且该应用请求消息不携带任何GBA参数。接着，在步骤102中，NAF发送应用响应消息给UA1，指示UA1需要首先和BSF进行GBA过程。

方式2包括图中的步骤101a、101b、102a和102b。该方式2与方式1基本相同，不同之处仅在于所述应用请求消息和应用相应消息皆通过B2BUA转发。

当按照图7所描述的任一方式执行了初始引导过程之后，执行如图8所示的UA和BSF之间的引导交互过程。该引导交互过程包括如下步骤：

首先，在步骤201中，UA1发送GBA请求到B2BUA，该GBA请求中携带有该UA1的用户名和NAF的标识ID。

接着，在步骤202中，B2BUA根据GBA请求携带的用户名，在存储在B2BUA上的关系映射表中找出与该UA1对应的设备标识。当然，该关系映射表也可以配置在HSS上，当B2BUA和BSF相互鉴权时，BSF查询HSS获取鉴权向量(即步骤204)的同时获取该关系映射表，然后将该关系映射表连同B-TID，密钥有效期一起发给B2BUA(即步骤209)。在这种情况下，该步骤202位于步骤209和步骤211之间。

接着，在步骤203-210中，执行B2BUA和BSF之间的互相鉴权过程。通过这些步骤，BSF生成了事务标识B-TID，连同密钥有效期一同发给B2BUA，并且B2BUA和BSF都生成根密钥Ks。此外，在BSF中保存一张表(B-TID，IMPI，Ks，密钥有效期，引导开始时间)，从而当BSF收到NAF的请求后可以根据此B-TID查到根密钥Ks。

具体的，在步骤203中，B2BUA向BSF发送GBA请求消息，该GBA请求消息包括UA1的私有用户标识。

接着，在步骤204中，BSF向HSS获取认证向量，BSF通过与HSS的交互获取该B2BUA的鉴权向量信息，如AUTN、RAND、IK、CK以及XRES等。

接着，在步骤205中，BSF向B2BUA返回挑战响应消息，该消息中包含AUTN、RAND。具体地说，BSF在接收到B2BUA的鉴权向量信息后，将鉴权向量信息中的AUTN和RAND，一并携带在挑战响应消息中，并将该消息返回给B2BUA。其中，AUTN用于验证BSF的身份，RAND用于使B2BUA获取与BSF侧相同的IK和CK。

接着，在步骤206中，B2BUA通过运行AKA算法，检查AUTN的有效性以鉴权网络，得到IK和CK，并生成RES。具体地说，B2BUA在接收到BSF返回的挑战响应消息后，通过对其中AUTN的有效性检查验证对端BSF的身份，根据其中的RAND计算得到与BSF侧相同的IK和CK，并生成RES。

接着，在步骤207中，B2BUA再次向BSF发送GBA请求消息，并在该消息中携带RES。其中，RES用于验证B2BUA的身份。

接着，在步骤208中，BSF检查RES的有效性以鉴权B2BUA。BSF通过判断GBA请求消息中的RES是否与从HSS处获取的XRES一致，从而对B2BUA进行鉴权。而且，BSF根据从HSS处获取的IK和CK生成Ks。

接着，在步骤209中，BSF将B-TID以及Ks的有效期携带在成功响应消息中发送给B2BUA。具体地说，BSF为标识和B2BUA之间本次鉴权交互事务而分配一个B-TID，使该B-TID与Ks、B2BUA的私有用户标识相关联，以便以后BSF可以根据该B-TID查找出相应的Ks，并且，为Ks定义一个有效期，以便Ks进行定期更新。BSF将该B-TID以及Ks的有效期携带在成功响应消息中。

接着，在步骤210中，B2BUA在接收到该成功响应消息后，得到B-TID和Ks的有效期，并将该B-TID和Ks的有效期保存在B2BUA侧，并生成Ks。

在执行了B2BUA和BSF之间的互相鉴权过程之后，在步骤211中，B2BUA根据公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id，设备标识)推导出Ks_NAF，并保存Ks_NAF与私有用户标识IMPI之间的关系。

接着，在步骤212中，B2BUA将Ks_NAF、B-TID、设备标识、密钥有效期发给UA1。

当存在多个UA需与BSF之间执行引导交互时，可以通过如图9或8所示的流程来执行该引导交互。

如图9所示，首先，第一个UA1通过步骤201-212执行GBA过程。之后，当其他的UA也需要和BSF交互时，其首先在步骤301中将GBA请求发送至B2BUA，该GBA请求中携带有该UA2的用户名。接着在步骤302中，B2BUA根据GBA请求中携带的用户名，在关系映射表中找出该UA2对应的设备标识。根据B2BUA的本地安全策略，在Ks有效期内，可以跳过步骤203-210。BSF对于所有的UA都保存相同的B-TID、Ks等数据。因此，直接执行步骤311，B2BUA根据公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id，设备标识)推导出Ks_NAF，并保存Ks_NAF与私有用户标识IMPI之间的关系。然后在步骤312中，B2BUA将Ks_NAF、B-TID、设备标识、密钥有效期发给UA2。在该过程中，步骤301、302、311、312和如图2所示的步骤201、202、211、212相似。

如图10所示，描述了多个UA与BSF之间执行引导交互的另一实施方式。

该实施方式基本上与如图10所示的实施方式相同，其不同之处在于：当第一个UA1完成了GBA过程后，其他的UA也需要和BSF交互时，根据B2BUA的本地安全策略，在Ks有效期内，需要重新执行上述步骤203-210。为了让BSF区分是同一个UA和BSF的重新交互，还是不同的UA和BSF的交互，需要在上述步骤203中携带设备标识参数。BSF对于每一个UA都保存相应的B-TID_UA、IMPI、KS_UA等数据(如图所示)。因此，以后这些UA将使用不同的B-TID(Ks)和Ks_NAF来访问NAF。

当通过图8，7或8所描述的流程完成了UA与BSF之间的引导交互过程之后，接着执行如图11所描述的过程，实现UA和NAF之间的SA(安全联盟)建立。如图11所示，其包括如下步骤。

首先，在步骤501中，UA发送应用请求消息给NAF，该应用请求中携带有B-TID，设备标识参数。该步骤501也可以由图中的步骤501a-501b代替，在这些步骤中，UA通过B2BUA将应用请求消息发给NAF，这里B2BUA起到转发的作用，该应用请求消息也包括B-TID和设备标识参数。

接着，在步骤502中，NAF发送认证请求消息给BSF，该认证请求消息携带有设备标识、B-TID，NAF主机名(即NAF的标识ID)。

接着，在步骤503中，BSF根据和用户侧相同的公式推导出Ks_NAF，并在步骤504中将推导出的Ks_NAF连同其他参数一起发送给NAF。具体的，BSF根据B-TID查找存储在BSF中的表，获得Ks和IMPI，根据获得的参数和在步骤502中发送来的参数，生成Ks_NAF。

接着，在步骤504中，BSF将Ks_NAF、应用相关用户属性数据、GBA开始时间、密钥有效期发送给NAF。在步骤505中，NAF保存Ks_NAF等参数以及B-TID、设备标识的关系。

在步骤506中，NAF发送应用响应消息给UA。相应的，该步骤也可以由图中的步骤506a-506b代替，即NAF也可能通过B2BUA将应用响应消息发给UA。

通过上面图8，7，或8的过程，B2BUA为UA生成了衍生密钥Ks_NAF，且通过图11所示的处理，BSF为NAF生成了相同的衍生密钥Ks_NAF。从而，UA和NAF之间建立了安全联盟。

当通过上面描述的过程建立了UA和NAF之间的安全联盟之后，UA和NAF之间执行安全的通信，但是如果NAF认为衍生的共享密钥Ks_NAF已经过期，则可以通过如图12所示的步骤602中指示指示UA需要重新执行和BSF之间的相互鉴权过程。当然，该指示也可以通过按照步骤602a和602b由B2BUA进行转发。

下面，分析根据上述的方法来实现新旧版本的互通的情况。考虑到BSF由运营商管理，因此可以认为BSF可以通过是否有设备标识参数来区分新、旧版本的情况。

对于UE(或B2BUA)或者NAF，则可能新、旧版本都有。因此只需要考虑新版本的UE(支持设备标识参数)和旧版本的NAF(不支持设备标识参数)、旧版本的UE(不支持设备标识参数)和新版本的NAF(支持设备标识参数)这两种互通情况。

<新版本的UE和旧版本的NAF之间的互通>

新版本的UE和旧版本的NAF之间的互通有如下两种情况：

情况1：如图8、图9所示，假设新版本的UE和旧版本的BSF之间进行GBA过程时，不携带设备标识参数。完成GBA过程后，UE会使用带设备标识的密钥推导公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id，设备标识)生成Ks_NAF；UE向NAF发送的应用请求消息中也携带设备标识参数；但是NAF不识别，因此NAF向BSF发送的认证请求消息中不携带设备标识参数；从而会导致BSF使用不同的密钥推导公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)生成Ks_NAF。从而导致互通不可行。

情况2：如图6所示，假设新版本的UE和旧版本的BSF之间进行GBA过程时，在步骤203中携带设备标识参数。完成GBA过程后，UE会使用带设备标识的密钥推导公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id，设备标识)生成Ks_NAF，同时BSF也应将B-TID和设备标识的关系记录下来；UE向NAF发送的应用请求消息中也携带设备标识参数；但是NAF不识别，因此NAF向BSF发送的认证请求消息中不携带设备标识参数；BSF根据B-TID可以知道UE是新版本的，从而可以查出对应的设备标识，然后BSF使用相同的密钥推导公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id，设备标识)生成Ks_NAF。因此互通是可行的。

因此，从新旧版本互通的角度考虑，新版本的UE和BSF之间进行GBA过程时，必须携带设备标识参数。

<旧版本的UE和新版本的NAF的互通分析>

旧版本的UE和BSF之间进行GBA过程时，不会携带设备标识参数。完成GBA过程后，UE会使用不带设备标识的密钥推导公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)生成Ks_NAF；UE向NAF发送的应用请求消息中也不带设备标识参数；NAF向BSF发送的认证请求消息中也不带设备标识参数，从而BSF也使用相同的密钥推导公式Ks_NAF＝KDF(Ks，″gba-me″，RAND，IMPI，NAF_Id)生成Ks_NAF。因此互通是可行的。

本发明不仅适用于固定网络中的非IMS终端，也同样适用于移动网络中的非IMS终端，该非IMS终端代理实体可以是所述B2BUA(IRG)实体，也可以是3GPP/3GPP2中具备类似功能的实体。

依照本发明，不同的非IMS终端访问同一个NAF时，衍生的共享密钥Ks_NAF是不一样的，这样即使一个Ks_NAF泄密，也不会影响其他的Ks_NAF，从而保证了安全性。此外，设备标识是由B2BUA连同衍生共享密钥Ks_NAF一起传给非IMS终端，这样保证了非IMS终端上不容易进行伪标识攻击。此外，不同的非IMS终端访问同一个NAF时，不仅Ks_NAF不同，B-TID也可以不一样，进一步保证了安全性。而且，本发明是在现有的GBA架构上进行的扩展，从而保证了后向兼容性。

虽然本发明已以较多的方式进行了表达，但并不是用以限定本发明，任何熟悉该技术的人员，在不脱离本发明的精神和范围内，可以做各种改动和润饰，因此本发明的保护范围当视专利申请范围所界定者为准。