专利名称：认证协商方法及系统、安全网关、家庭无线接入点的制作方法
技术领域：
本发明涉及移动通信技术领域，特别涉及一种认证协商方法及系统、安全网关、家
庭无线接入点。
背景技术：
目前3GPP和non-3GPP标准组织正在研究一种新的接入模式家庭接入模式，用户 设备(User Equipment, UE)通过家庭无线接入点(Home Node B， HNB)，使用许可的频谱，通 过通用的IP公共接入网络连接到运营商的移动网络。由于从HNB的设备到运营商的移动 网络中的HNB的安全网关(SecurityGateway， SeGW)网元之间经过的是IP公共接入网络， 这样就可能弓I入IP公共网络中常见的网络攻击，因此需要核心网元，这里是HNB的SeGW对 HNB的设备进行认证。其中该认证包括设备认证和宿主认证(Host PartyModule，HPM，宿主 模块，通常用HPM表示宿主认证)。设备认证是指对HNB的设备本身的认证；宿主认证则是 对与运营商签约的，该HNB的设备的宿主的认证。 最新的3GPP H(e)NB(包括HNB禾PHeNB(Home Evolved Node B))安全规范33. 820 VI. 2. 0(文档号S3-081585)定义了如下的认证原则 ①H(e)NB必须支持设备认证机制中的证书认证或者可扩展的认证协议_认证与 密钥协商(Extensible Authentication Protocol-Authentication and KeyAgreement， EAP-AKA)认证中的一种； ②H (e) NB，可选地支持EAP-AKA宿主认证机制； ③对H(e)NB的SeGW的要求和上述对H(e)NB的两条要求①和②一样，另外SeGW 还可以根据运营商的安全策略，决定采用哪种安全机制；
④具体采用上述哪一种认证机制还取决于网络部署。 上述H (e) NB和SeGW之间主要是根据RFC4306定义的Internet密钥交换版 本2(Internet Key Exchange V2， IKE V2)协议进行认证机制的协商的。该IKE V2协 议的主要思想是，首先进行Internet密钥交换-安全联盟_初始化请求(IKE-Security Association-INITial request, IKE_SA_INIT request)/IKE_SA_INIT响应(IKE_SA_ INIT response)消息对的交互，以便协商加密算法，交换随机数，并进行蒂夫_赫尔曼 (Diffie-Hellman)交换；然后进行Internet密钥交换_认证请求(IKE_Authentication request, IKE_AUTH request)/IKE_AUTH响应(IKE_AUTH response)消息对的交互，以便认 证上述IKE_SA_INIT消息，交换身份标识和证书，建立第一个子安全联盟。此后还可能有多 个IKE-AUTH请求/响应消息对的交互，以进行后续认证的相关处理。
下面具体说明现有的认证机制的协商方案 协商方案一、如果SeGW在IKE_SA_INIT响应消息中同时携带了消息类型为多认证 支持(MULTIPLE_AUTH_SUPP0RT)的通知(NOTIFY)头域和证书请求(CERTREQ)头域；H(e)NB 在随后的IKE—AUTH请求消息中同时携带了认证(AUTH)头域，消息类型为MULTIPLE_AUTH_ SUPPORT的NOTIFY头域，以及消息类型为"接着是下一个认证"(AN0THEILAUTILF0LL0WS)的
5NOTIFY头域，则协商结果是采用基于证书认证的设备认证以及EAP-AKA宿主认证。
协商方案二、如果SeGW在IKE_SA_INIT响应消息中携带了消息类型为MULTIPLE— AUTH_SUPPORT的NOTIFY头域，但没有携带CERTREQ头域；H(e)NB在随后的IKE_AUTH请求 消息中没有携带AUTH头域，但同时携带了消息类型为MULTIPLE_AUTH_SUPPORT的NOTIFY 头域以及消息类型为ANOTHER_AUTH_FOLLOWS的NOTIFY头域，则协商结果是采用EAP-AKA 设备认证以及EAP-AKA宿主认证。 协商方案三、如果SeGW在IKE_SA_INIT响应消息中没有携带消息类型为 MULTIPLE_AUTH_SUPPORT的NOTIFY头域，但携带了 CERTREQ头域；H(e)NB在随后的IKE_ AUTH请求消息中携带了 AUTH头域，但没有携带消息类型为MULTIPLE_AUTH_SUPPORT的 NOTIFY头域和消息类型为ANOTHER_AUTH_FOLLOWS的NOTIFY头域，则协商结果是采用基于 证书认证的设备认证，但没有EAP-AKA宿主认证。 协商方案四、如果SeGW在IKE_SA_INIT响应消息中没有携带消息类型为 MULTIPLE_AUTH_SUPPORT的NOTIFY头域和CERTREQ头域；H(e)NB在随后的IKE_AUTH请求 消息中也没有携带AUTH头域、消息类型为MULTIPLE_AUTH_SUPPORT的NOTIFY头域、消息类 型为ANOTHER_AUTH_FOLLOWS的NOTIFY头域，则协商结果是采用EAP-AKA设备认证，但没有 EAP-AKA宿主认证。 除了上述四种协商方案外的其他情况属于异常情况，需要SeGW根据运营商的安 全策略进行进一步的判断和处理。 发明人在实现本发明的过程中，发现现有技术中的认证机制采用的H(e)NB和 SeGW以及它们之间的协商方案至少存在以下缺点 在网络部署上，针对不同的运营商的不同的认证需求，设备商至少需要提供如下 不同版本的H(e)NB和SeGW :仅支持基于证书的设备认证的设备、仅支持EAP-AKA设备认证 的设备、同时支持基于证书的设备认证和EAP-AKA宿主认证的设备、同时支持EAP-AKA设备 认证和EAP-AKA宿主认证的设备、以及还可能提供同时支持基于证书的设备认证、EAP-AKA 设备认证和EAP-AKA宿主认证的设备。而对于运营商来说，由于设备版本繁多，运营商从不 同的设备商处购买的H(e)NB和SeGW可能支持不同的认证方式，导致认证协商时可能进入 各种异常情况，甚至不能完成对H(e)NB的认证。从而不能真正满足运营商的认证需求。
发明内容
本发明实施例在于提供一种认证协商方法及系统、安全网关、家庭无线接入点，以 减少现有技术中的版本繁多的H(e)NB和SeGW设备，并提供一种更加简单、准确的认证机 制。 根据本发明实施例的一方面，提供了一种认证协商方法，包括 接收家庭无线接入点H (e) NB发送的因特网密钥交换_安全联盟_初始化IKE_SA_
INIT i青求; 发送IKE_SA_INIT响应至所述H (e) NB ; 接收所述H(e)NB发送的第一因特网密钥交换_认证IKE_AUTH请求； 根据所述IKE_SA_INIT响应和第一 IKE_AUTH请求中是否携带有支持对所述H(e)
NB执行设备认证和宿主认证的第一标识，执行对所述H(e)NB的认证。
根据本发明实施例的另一方面，提供了一种安全网关，包括 接收模块，用于接收家庭无线接入点H(e)NB发送的因特网密钥交换_安全联 盟_初始化IKE_SA_INIT请求，以及接收所述H(e)NB发送的因特网密钥交换_认证IKE_ AUTH请求； 发送模块，用于发送IKE_SA_INIT响应以及IKE_AUTH响应至所述H(e)NB ; 处理模块，用于根据所述IKE_SA_INIT响应和IKE—AUTH请求中是否携带有支持对
所述H(e) NB执行设备认证和宿主认证的第一标识，执行对所述H(e) NB的认证。 根据本发明实施例的另一方面，提供了一种家庭无线接入点，包括 发送模块，用于发送因特网密钥交换_安全联盟_初始化IKE_SA_INIT请求以及
因特网密钥交换_认证IKE_AUTH请求至安全网关； 接收模块，用于接收所述安全网关发送的IKE_SA_INIT响应以及IKE_AUTH响应；
处理模块，用于根据所述IKE_SA_INIT响应中是否携带有支持对所述H(e)NB执行 设备认证和宿主认证的第一标识，决定是否在所述IKE_AUTH请求中也携带所述第一标识。
根据本发明实施例的另一方面，提供了一种认证协商系统，包括
家庭无线接入点H(e)NB，用于发送因特网密钥交换-安全联盟_初始化IKE_SA_ INIT请求以及因特网密钥交换-认证IKE—AUTH请求，接收返回的IKE_SA_INIT响应以及 IKE_AUTH响应；并根据所述IKE_SA_INIT响应中是否携带有支持对所述H(e)NB执行设备 认证和宿主认证的第一标识，决定是否在所述IKE—AUTH请求中也携带所述第一标识；
安全网关，用于接收所述H(e)NB发送的IKE_SA_INIT请求以及IKE—AUTH请求；发 送IKE_SA_INIT响应以及IKE_AUTH响应至所述H(e)NB ;并根据所述IKE_SA_INIT响应和 IKE_AUTH请求中是否携带有所述第一标识，执行对所述H(e) NB的认证。
由以上技术方案可知，本发明实施例提供的认证协商方法及系统、安全网关、家庭 无线接入点，通过对IKE_SA_INIT响应和IKE—AUTH请求中携带的标识的判断，实现H(e)NB 和SeGW之间的简单准确的认证协商机制，还可以减少现有技术中的版本繁多的H(e) NB和 SeGW设备。
1为本发明实施例家庭接入的系统架构示意图； 2为本发明认证协商方法第一实施例的流程示意图； 3为本发明认证协商方法第二实施例的第一信令流程图 4为本发明认证协商方法第二实施例的第二信令流程图 5为本发明认证协商方法第三实施例的第一信令流程图 6为本发明认证协商方法第三实施例的第二信令流程图 7为本发明认证协商方法第三实施例的第三信令流程图 8为本发明认证协商方法第三实施例的第四信令流程图 9为本发明认证协商方法第四实施例的第一信令流程图 10为本发明认证协商方法第四实施例的第二信令流程图 11为本发明认证协商方法第四实施例的第三信令流程图 12为本发明认证协商方法第四实施例的第四信令流程图
图13为本发明安全网关实施例的结构示意图；
图14为本发明家庭无线接入点实施例的结构示意图；
图15为本发明认证协商系统实施例的结构示意图。
具体实施例方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于 本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他 实施例，都属于本发明保护的范围。 图1为本发明实施例家庭接入的系统架构示意图。如图l所示，包括家庭无 线接入点(H(e)NB)，使用许可的频谱，通过通用的IP公共网络将用户设备(UE)连接到 运营商的移动网络。家庭无线接入点包括HNB，运行在通用移动通信系统(Universal Mobile Telecommunications System, UMTS)陆地无线接入网(UMTS Territorial Radio Access Network, UTRAN)频谱的家庭无线接入点；HeNB，运行在演进的UMTS陆地无线 接入网(Evolved-UTRAN， E-UTRAN)频谱的家庭无线接入点；Home non_3GPP WAP (Home 丽-3GPPwireless access point)，运行在丽-3GPP网络(如CDMA/Wimax/WLAN/HRPD等 网络)频谱的家庭无线接入点。家庭无线接入点的网关网元，包括HNB网关(HNB GW)、HeNB GW以及Home non-3GPP WAP GW，其执行家庭无线接入点的管理和接入控制，汇集家庭无线 接入点，路由和转发家庭无线接入点和移动网络中的网元之间的信令的数据等功能；另外 上述的网关网元(HNB GW、HeNB GW禾PHome non-3GPP WAP GW)还具有家庭无线接入点的安 全网关(Security Gateway, SeGW)的功能，执行与安全相关的功能，例如认证、加密等。移 动性管理实体(Mobility Management Entity,匪E)，负责E-UTRAN网络中的控制面移动性 管理，包括用户上下文和移动状态管理，分配用户临时身份标识等。服务通用分组无线业务 支持节点(ServingGPRS Supporting Node, SGSN)，用于实现通用分组无线业务(General PacketRadio Service, GPRS)/UMTS网络中路由转发、移动性管理、会话管理以及用户信息 存储等功能。非3GPP网关实体(non-3GPP GW)实现非3GPP网络中的移动性管理、会话 管理等功能。对于WLAN网络，non-3GPP GW为演进分组数据网关(Evolved Packet Data Gateway, EPDG);对于Wimax网络，non_3GPP GW为接入业务网络网关(Access Service Network Gateway, ASN GW);对于CDMA网络，non-3GPP GW为接入网关(Access Gateway, AGW);对于HRPD网络，non-3GPP GW为高速分组数据服务网关(HRPDServing Gateway, HSGW)。归属用户服务器(Home Subscriber Server,HSS)用于存储用户签约信息。认证、授 丰又与计费月艮务器(Authentication,Authorization and Accounting Server,AAA Server) 用于对UE执行接入认证、授权和计费功能。家庭接入管理服务器(Home Management Server, HMS)，负责家庭无线接入点的管理功能，其中HMS可以是一个独立的网元，也可以 集成到HSS中；HMS还可以直接和家庭无线接入点相连，本发明实施例不作限制。另外，该 家庭接入的系统架构并不意味着是最终的家庭接入的系统架构，本发明实施例同样不作限 制。 由于从家庭无线接入点到家庭无线接入点对应的SeGW网元之间走的是IP公共 网络，这样就可能引入IP网络中的常见的网络攻击，因此需要核心网元，这里是家庭无线
8接入点对应的各个SeGW网元对家庭无线接入点进行认证，包括设备认证和宿主认证。目 前最新的3GPP H(e)NB安全规范33. 820V1. 2. 0中的设备认证包括基于证书的设备认证或 EAP-AKA Over IKE V2设备认证，即运行在IKE V2协议之上的EAP-AKA设备认证两种认证机 制，所有运营商都会采用设备认证中的其中一种认证机制；而宿主认证则只包含EAP-AKA 认证方式，并且有些运营商可能采用，有些运营商可能不采用，并且对于采用宿主认证的移 动网络，宿主认证一般在设备认证之后进行。 在现有协商方案的技术实现上，若将IKE_AUTH请求消息中是否携带AUTH头域 作为判定是支持基于证书的设备认证，还是支持EAP-AKA设备认证的依据，那么由于IKE— AUTH请求消息中携带有ANOTHER_AUTH_FOLLOWS的NOTIFY头域的同时其必然也携带AUTH 头域，即AUTH和ANOTHER_AUTH_FOLLOWS总是绑定在一起的，因此AUTH头域不能作为判定 设备认证的方式的依据。 若将IKE_SA_INIT响应消息中是否携带CERTREQ头域作为判断是支持基于证书的 设备认证，还是支持EAP-AKA设备认证的依据，那么由于CERTREQ头域也可以请求携带证书 以外的内容，因此CERTREQ头域作为判定设备认证的方式的依据也是不合适的。
若将MULTIPLE_AUTH_SUPPPORTED禾P ANOTHER_AUTH_FOLLOWS绑定在同 一 个 IKE—AUTH请求消息中作为判断是否同时支持设备认证和宿主认证的判定依据，由于根据 RFC4739，"下一条IKE_AUTH将包含第2个身份标识，并启动下一个认证，即宿主认证"，因 此对于同时支持EAP-AKA设备认证和EAP-AKA宿主认证的场景，下一条IKE_AUTH还是用于 启动EAP-AKA设备认证的，而不是EAP-AKA宿主认证的，因此不符合RFC4739的规定。所以 将两者绑定在同一个IKE—AUTH请求消息中时，只适用于同时支持基于证书的设备认证和 EAP-AKA宿主认证的场景，而不能适用于同时支持EAP-AKA设备认证和EAP-AKA宿主认证的 场景。另外，对于H(e)NB而言，MULTIPLE_AUTH_SUPPORTED头域只可以携带在第一个IKE_ AUTH请求消息中，而ANOTHER_AUTH_FOLLOWS是可以携带在任何一个含有AUTH头域的IKE_ AUTH请求/响应消息中的，即两者没有必要绑定在同一个IKE_AUTH请求消息中，以免影响 协商的灵活性。 针对上述现有协商方案上存在的问题，下面将基于图1所示的家庭接入的系统架 构说明本发明实施例所采用的认证协商的方法。 在本发明下述的实施例中，为了解决现有设备版本繁多的问题，设备商制造的家 庭无线接入点(以下用H(e)NB表示)或安全网关网元(以下用SeGW表示)或H(e)NB和 SeGW要支持所有的认证方式，以便运营商在进行网络部署后，决定在H(e)NB和SeGW之间 使用哪种认证方式或其组合的自由度更高。在本发明下述的实施例中，为了解决现有的认 证方案中存在的问题，主要采用以下三点对现有认证协商方案进行了改进①扩展IKE V2 协议中的NOTIFY头域的消息类型以指示设备认证的类型，SeGW和H(e)NB分别在IKE_SA_ INIT响应消息和IKE_AUTH请求消息中携带扩展了消息类型的NOTIFY头域以指示所支持 的设备认证方式；②直接利用IKE V2协议中可以携带EAP头域，例如EAP协议中的NOTIFY 消息类型，来指示设备认证的类型，SeGW和H(e)NB分别在IKE_SA_INIT响应消息和IKE_ AUTH请求消息中携带EAP头域指示所支持的设备认证方式；③不再将MULTIPLE_AUTH_ SUPPPORTED和ANOTHER_AUTH_FOLLOWS绑定在同一个IKE_AUTH请求消息中。
首先对H( )NB支持所有的认证方式，SeGW可能只支持部分认证方式的情况下如何进行认证协商进行详细说明。在此种情况下，认证协商中不会有异常情况出现。 图2为本发明认证协商方法第一实施例的流程示意图。如图2所示，包括如下步
骤 步骤301、接收家庭无线接入点(H(e)NB)发送的IKE_SA_INIT请求；
步骤302、发送IKE_SA_INIT响应至H(e)NB ;
步骤303、接收H(e)NB发送的IKE_AUTH请求； 步骤304、根据IKE_SA_INIT响应和IKE—AUTH请求中是否携带有支持对H(e)NB执 行设备认证和宿主认证的第一标识，执行对H(e) NB的认证。 其中，步骤301 步骤303具体为H(e)NB发送IKE_SA_INIT请求；SeGW接收到 H(e)NB发送的IKE_SA_INIT请求后，返回IKE_SA_INIT响应至H(e)NB ;H(e)NB发送IKE_ AUTH请求；SeGW接收到该IKE_AUTH请求后即完成了主要的认证协商过程。本发明实施例 中省略了 SeGW返回IKE_AUTH响应至H(e)NB的步骤，以及随后的在设备认证和宿主认证过 程中的IKE_AUTH请求/响应消息。步骤304为根据步骤302和步骤303的协商结果，即 IKE_SA_INIT响应和IKE_AUTH请求中是否携带支持对H(e)NB执行设备认证和宿主认证的 第一标识，由SeGW执行对H(e)NB的认证，包括设备认证或设备认证和宿主认证。
对于基于证书的设备认证和EAP-AKA设备认证，当SeGW设备仅支持其中一种设备 认证的方式，由于步骤302中的IKE_SA_INIT响应携带的某些参数可以说明其支持的设备 认证方式，因此在H(e)NB和SeGW之间仅支持一种宿主认证的方式的前提下，只要通过判断 IKE_SA_INIT响应和IKE—AUTH请求中是否携带支持对H(e)NB执行设备认证和宿主认证的 第一标识，即可确定SeGW对H(e)NB所执行的认证。下面将通过具体实施例进行详细说明。
本发明实施例提供的认证协商方法，通过在IKE_SA_INIT响应和IKE—AUTH请求中 携带表示认证方式的标识，可以实现H(e)NB和SeGW之间的简单、准确的认证协商过程，并 且H(e)NB支持所有的认证方式，SeGW可以为支持所有认证方式或者仅支持部分认证方式 的设备，会降低由于设备匹配问题出现认证协商失败的情况。 图3为本发明认证协商方法第二实施例的第一信令流程图。基于上述图2所示的
实施例，本实施例中假设H(e)NB和SeGW之间的设备认证方式只有一种，即要么是基于证书
的设备认证，要么是EAP-AKA设备认证，且H(e)NB支持所有的认证方式，即H(e)NB支持设
备认证方式和宿主认证；如图3所示，包括如下步骤 步骤401 、 H (e) NB向SeGW发送IKE_SA_INIT请求消息； 步骤402、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; SeGW判断需要对H(e)NB执行设备认证和宿主认证，因此在IKE_SA_INIT响应消息 中携带表示SeGW支持或者请求对H(e)NB进行设备认证和宿主认证的第一标识，例如第一 标识可以为消息类型为MULTIPLE—AUTH—SUPPORTED的NOTIFY头域；该步骤402中并没有携 带请求哪种设备认证的第二标识，说明此时SeGW和H(e)NB均为仅支持同一种设备认证方 式的设备；假定该实施例中SeGW和H(e)NB均仅支持基于证书的设备认证，那么该步骤402 表示该SeGW支持对H(e)NB进行基于证书的设备认证和EAP-AKA宿主认证；
步骤403、 H(e)NB向SeGW发送IKE_AUTH请求消息，其中携带表示H(e)NB支持或 者请求进行设备认证和宿主认证的第一标识，例如第一标识可以为消息类型为MULTIPLE— AUTH_SUPPORTED的NOTIFY头域表示H (e) NB仅支持或者请求基于证书的设备认证和EAP-AKA宿主认证； 至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需 要进行基于证书的设备认证和EAP-AKA宿主认证； 步骤404、SeGW对H(e)NB执行基于证书的设备认证过程，为清晰起见，此处省略了 SeGW返回H(e)NB的IKE_AUTH响应消息； 步骤405、H(e)NB向SeGW发送IKE_AUTH请求消息，其中携带消息类型为接着是下 一个认证(ANOTHER_AUTH_FOLLOWS)的NOTIFY头域和AUTH头域表示设备认证已经完成，下 一步将接着对H(e)NB执行EAP-AKA宿主认证； 需要说明的是，此处的步骤405和上面的403也可以合并在同一条IKE—AUTH请求 消息，即将ANOTHER_AUTH_FOLLOWS的NOTIFY头域和MULTIPLE_AUTH_SUPPORTED的NOTIFY 头域绑定在同一条IKE—AUTH请求消息中； 步骤406、 SeGW对H(e)NB执行EAP-AKA宿主认证过程，为清晰起见，此处省略了 SeGW返回H(e)NB的IKE_AUTH响应消息。 当假定SeGW和H (e) NB仅支持EAP-AKA设备认证时的具体认证协商过程与SeGW支 持基于证书的设备认证时的具体认证协商过程相同，只是步骤404执行的为SeGW对H(e)NB 的EAP-AKA设备认证过程；并且需要说明的是，此时的步骤405和上面的403不可以合并在 同一条IKE_AUTH请求消息，即必须将ANOTHER_AUTH_FOLLOWS的NOTIFY头域和MULTIPLE— AUTH_SUPPORTED的NOTIFY头域分开在不同的IKE_AUTH消息中携带。 图4为本发明认证协商方法第二实施例的第二信令流程图。基于上述图2所示的 实施例，本实施例中假设H(e)NB和SeGW之间的设备认证方式只有一种，即要么是基于证书 的设备认证，要么是EAP-AKA设备认证，且H(e)NB支持所有的认证方式，即H(e)NB支持设 备认证方式和宿主认证；其中IKE_SA_INIT响应和IKE—AUTH请求中均不携带表示支持设备 认证和宿主认证的第一标识，例如第一标识可以为MULTIPLE_AUTH_SUPPORTED的NOTIFY头 域。如图4所示，包括如下步骤 步骤501、 H(e)NB向SeGW发送IKE_SA_INIT请求消息；
步骤502、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; SeGW判断仅需要对H(e)NB执行设备认证，因此在IKE_SA_INIT响应消息中没有 携带表示SeGW支持或者请求对H(e)NB进行设备认证和宿主认证的第一标识，例如第一标 识可以为消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，以表示该SeGW仅支持或 者请求对H(e)NB进行设备认证；该步骤502中并没有携带请求哪种设备认证的第二标识， 说明此时的SeGW和H(e)NB均为仅支持同一种设备认证方式的设备；例如假定该实施例中 SeGW和H(e)NB均仅支持EAP-AKA设备认证，那么该步骤502表示该SeGW对H(e)NB进行 EAP-AKA设备认证； 步骤503、H(e)NB向SeGW发送IKE_AUTH请求消息，其中相应地也不携带消息类型 为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域表示H(e)NB仅支持或者请求EAP-AKA设备认 证； 至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需 要进行EAP-AKA设备认证； 步骤504、 SeGW对H(e)NB执行EAP-AKA设备认证过程，为清晰起见，此处省略了
11SeGW返回H(e)NB的IKE_AUTH响应消息。 图4所示实施例与图3所示实施例的不同之处在于图4所示实施例中不携带消息 类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，则标识仅对H (e) NB执行设备认证，而没 有步骤405和步骤406的宿主认证过程。另外，SeGW仅支持基于证书的设备认证时的具体 认证协商过程与上述图4中SeGW仅支持EAP-AKA设备认证时的具体认证协商过程相同，只 是步骤504执行的为SeGW对H(e)NB的基于证书的设备认证过程，在此不再赘述。
总结图3和图4所示的实施例可知，当IKE_SA_INIT响应和IKE_AUTH请求中没有 携带第一标识时，根据SeGW的本地安全策略，执行对H(e)NB的设备认证；当IKE_SA_INIT 响应和IKE—AUTH请求中携带第一标识时，根据SeGW的本地安全策略，执行对H(e)NB的设 备认证和宿主认证。 基于上述H(e)NB支持所有的认证方式的基础上，若SeGW也支持所有的认证方式， 则在IKE_SA_INIT响应中还可以通过携带第二标识来进行认证协商，该第二标识用于请求 对H(e)NB执行基于证书的设备认证或EAP-AKA设备认证。下面将通过具体的实施例进行 说明。 图5为本发明认证协商方法第三实施例的第一信令流程图。本实施例中以SeGW
仅对H(e)NB执行基于证书的设备认证为例。此时IKE_SA_INIT响应和IKE—AUTH请求中没
有携带第一标识，并且IKE_SA_INIT响应中携带的第二标识表示支持对H(e) NB执行基于证
书的设备认证，例如第二标识可以为消息类型为证书认证(CERT_AUTH)的NOTIFY头域、或
证书请求(CERTREQ)头域。如图5所示，包括如下步骤 步骤601 、 H (e) NB向SeGW发送IKE_SA_INIT请求消息； 步骤602、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; SeGW判断仅需要对H(e)NB执行基于证书的设备认证，因此在IKE_SA_INIT响应消 息中没有携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带表示SeGW支 持或者请求基于证书的设备认证的第二标识，例如第二标识可以为消息类型为CERT_AUTH 的NOTIFY头域、或CERTREQ头域，以表示该SeGW仅请求或者支持对H(e)NB进行基于证书 的设备认证； 步骤603、H(e)NB向SeGW发送IKE_AUTH请求消息，其中相应地也不携带消息类型 为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域表示H(e)NB支持基于证书的设备认证；
至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需 要进行基于证书的设备认证； 步骤604、SeGW对H(e)NB执行基于证书的设备认证过程，为清晰起见，此处省略了 SeGW返回H(e)NB的IKE_AUTH响应消息。 图6为本发明认证协商方法第三实施例的第二信令流程图。本实施例中以SeGW 仅对H(e) NB执行EAP-AKA设备认证为例。此时IKE_SA_INIT响应和IKE_AUTH请求中没有 携带第一标识，并且IKE_SA_INIT响应中携带的第二标识表示支持对H(e)NB执行EAP-AKA 设备认证，例如第二标识可以为消息类型为EAP-AKA认证(EAP-AKA_AUTH)的NOTIFY头域 或EAP头域。如图6所示，包括如下步骤 步骤701、 H(e)NB向SeGW发送IKE_SA_INIT请求消息；
步骤702、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ;
SeGW判断仅需要对H(e) NB执行EAP-AKA设备认证，因此在IKE_SA_INIT响应消息中没有携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带有表示SeGW支持EAP-AKA设备认证的第二标识，例如第二标识可以为消息类型为EAP-AKA_AUTH的NOTIFY头域或EAP头域，以表示该SeGW仅请求或者支持对H(e)NB进行设备认证；
步骤703、H(e)NB向SeGW发送IKE_AUTH请求消息，其中相应地也不携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域表示H(e)NB支持EAP-AKA设备认证；
至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需要进行EAP-AKA设备认证； 步骤704、 SeGW对H(e)NB执行EAP-AKA设备认证过程，为清晰起见，此处省略了SeGW返回H(e)NB的IKE_AUTH响应消息。 上述图5和图6所示的实施例中，以IKE_SA_INIT响应消息中携带表示SeGW支持或者请求不同设备认证的第二标识为例，说明当IKE—SAJNIT响应消息中携带表示SeGW支持或者请求基于证书的设备认证的第二标识时，即SeGW对H(e)NB执行基于证书的设备认证；当IKE_SA_INIT响应消息中携带表示SeGW支持或者请求EAP-AKA设备认证的第二标识时，即SeGW对H (e) NB执行EAP-AKA设备认证。 另外，也可以是当IKE_SA_INIT响应消息中携带表示SeGW支持或者请求基于证书的设备认证的第二标识时，即SeGW对H(e)NB执行基于证书的设备认证；而当IKE_SA_INIT响应消息中没有携带第二标识时，即SeGW对H(e)NB执行EAP-AKA设备认证。或者也可以是当IKE_SA_INIT响应消息中携带表示SeGW支持或者请求EAP-AKA设备认证的第二标识时，即SeGW对H(e)NB执行EAP-AKA设备认证；而当IKE_SA_INIT响应消息中没有携带第二标识时，即SeGW对H(e)NB执行基于证书的设备认证。 图7为本发明认证协商方法第三实施例的第三信令流程图。本实施例中以SeGW仅对H(e)NB执行基于证书的设备认证和EAP-AKA宿主认证为例。此时IKE_SA_INIT响应和IKE—AUTH请求中携带第一标识，并且IKE_SA_INIT响应中携带的第二标识表示SeGW支持基于证书设备认证，例如第二标识可以为消息类型为CERT_AUTH的NOTIFY头域或CERTREQ头域。如图7所示，包括如下步骤 步骤801、 H(e)NB向SeGW发送IKE_SA_INIT请求消息；
步骤802、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; SeGW判断需要对H(e)NB执行基于证书的设备认证和EAP-AKA宿主认证，因此在IKE_SA_INIT响应消息中携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，还携带表示SeGW支持或者请求基于证书的设备认证的第二标识，例如第二标识可以为消息类型为CERT_AUTH的NOTIFY头域或CERTREQ头域，以表示该SeGW仅请求或者支持对H(e)NB进行基于证书的设备认证和EAP-AKA宿主认证； 步骤803 、 H (e) NB向SeGW发送IKE_AUTH请求消息，其中携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域表示H (e) NB支持基于证书的设备认证和EAP-AKA宿主认证； 至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需要进行基于证书的设备认证和EAP-AKA宿主认证； 步骤804、SeGW对H(e)NB执行基于证书的设备认证过程，为清晰起见，此处省略了SeGW返回H(e)NB的IKE_AUTH响应消息； 步骤805、H(e)NB向SeGW发送IKE—AUTH请求消息，其中携带消息类型为ANOTHER—AUTH_FOLLOWS的NOTIFY头域和AUTH头域表示设备认证已经完成，下一步将接着对H(e) NB执行EAP-AKA宿主认证； 需要说明的是，此处的步骤805和上面的803也可以合并在同一条IKE—AUTH请求消息，即将ANOTHER_AUTH_FOLLOWS的NOTIFY头域和MULTIPLE_AUTH_SUPPORTED的NOTIFY头域绑定在同一条IKE—AUTH请求消息中； 步骤806、 SeGW对H(e)NB执行EAP-AKA宿主认证过程，为清晰起见，此处省略了SeGW返回H(e)NB的IKE_AUTH响应消息。 图8为本发明认证协商方法第三实施例的第四信令流程图。本实施例中以SeGW仅对H(e)NB执行EAP-AKA设备认证和EAP-AKA宿主认证为例。此时IKE_SA_INIT响应和IKE—AUTH请求中携带第一标识，并且IKE_SA_INIT响应中携带的第二标识表示支持对H(e)NB执行EAP-AKA设备认证，例如第二标识可以为消息类型为EAP_AKA_AUTH的NOTIFY头域或EAP头域。如图8所示，包括如下步骤 步骤901、 H(e)NB向SeGW发送IKE_SA_INIT请求消息；
步骤902、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; SeGW判断需要对H(e) NB执行EAP-AKA设备认证和EAP-AKA宿主认证，因此在IKE_SA_INIT响应消息中携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，还携带表示SeGW支持EAP-AKA设备认证的第二标识，例如第二标识可以为消息类型为EAP_AKA_AUTH的NOTIFY头域或EAP头域，以表示该SeGW仅请求或者支持对H(e) NB进行设备认证和宿主认证； 步骤903 、 H (e) NB向SeGW发送IKE_AUTH请求消息，其中携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域表示H(e)NB支持EAP-AKA设备认证和EAP-AKA宿主认证； 至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需要进行EAP-AKA设备认证和EAP-AKA宿主认证； 步骤904、 SeGW对H(e)NB执行EAP-AKA设备认证过程，为清晰起见，此处省略了SeGW返回H(e)NB的IKE_AUTH响应消息； 步骤905、H(e)NB向SeGW发送IKE—AUTH请求消息，其中携带消息类型为ANOTHER—AUTH_FOLLOWS的NOTIFY头域和AUTH头域表示设备认证已经完成，下一步将接着对H(e) NB执行EAP-AKA宿主认证； 需要说明的是，此处的步骤905和上面的903不可以合并在同一条IKE_AUTH请求消息，即必须将ANOTHER_AUTH_FOLLOWS的NOTIFY头域和MULTIPLE_AUTH_SUPPORTED的NOTIFY头域分开在不同的IKE—AUTH消息中携带； 步骤906、 SeGW对H(e)NB执行EAP-AKA宿主认证过程，为清晰起见，此处省略了SeGW返回H(e)NB的IKE_AUTH响应消息。 同上述图5和图6所示的实施例，该图7和图8所示的实施例中，也可以是当IKE_SA_INIT响应消息中携带表示SeGW支持或者请求基于证书的设备认证的第二标识时，即SeGW对H(e)NB执行基于证书的设备认证；而当IKE_SA_INIT响应消息中没有携带第二标识时，即SeGW对H(e)NB执行EAP-AKA设备认证。或者也可以是当IKE_SA_INIT响应消息中携带表示SeGW支持或者请求EAP-AKA设备认证的第二标识时，即SeGW对H(e)NB执行EAP-AKA设备认证；而当IKE_SA_INIT响应消息中没有携带第二标识时，即SeGW对H(e)NB执行基于证书的设备认证。 通过上述实施例可以实现H(e)NB支持所有认证方式的条件下，无论SeGW支持所有认证方式或者仅支持部分认证方式，均可以采用上述实施例中的标识完成H(e) NB和SeGW之间的认证协商，从而实现对H(e)NB的认证，而不会出现异常情况。
下面对SeGW支持所有的认证方式，H(e)NB可能支持所有或者只支持部分认证方式的情况下如何进行认证协商进行详细说明。在此种情况下，除了 IKE_SA_INIT响应中携带请求对H(e)NB执行基于证书的设备认证或EAP-AKA设备认证的第二标识外，IKE_AUTH请求中也要携带请求对H(e)NB执行基于证书的设备认证或EAP-AKA设备认证的第三标识。而基于这种情况下的认证协商中可能还是存在异常情况。 图9为本发明认证协商方法第四实施例的第一信令流程图。本实施例中以SeGW对H(e)NB执行基于证书的设备认证为例。此时IKE_SA_INIT响应和IKE_AUTH请求中没有携带第一标识，并且IKE_SA_INIT响应中携带的第二标识和IKE—AUTH请求中携带的第三标识均表示请求或者支持对H(e)NB执行基于证书的设备认证。如图9所示，包括如下步骤
步骤1001、 H(e)NB向SeGW发送IKE_SA_INIT请求消息；
步骤1002、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; SeGW判断仅需要对H(e)NB执行基于证书的设备认证，因此在IKE_SA_INIT响应消息中没有携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带表示SeGW支持或者请求基于证书的设备认证的第二标识，例如第二标识可以为消息类型为CERT_AUTH的NOTIFY头域、或CERTREQ头域，以表示该SeGW仅请求或者支持对H(e)NB进行基于证书的设备认证； 步骤1003、 H(e)NB向SeGW发送IKE_AUTH请求消息，其中相应地也不携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带表示H(e)NB支持基于证书的设备认证的第三标识，例如第三标识可以为消息类型为CERT_AUTH的NOT I FY头域、或AUTH头域、或指示基于证书的设备认证的网络接入标识(Network Access Identifier,NAI)，以表示H(e)NB同样支持基于证书的设备认证； 至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需要进行基于证书的设备认证； 步骤1004、 SeGW对H(e)NB执行基于证书的设备认证过程，为清晰起见，此处省略了 SeGW返回H(e)NB的IKE_AUTH响应消息。 另外，当IKE_SA_INIT响应和IKE_AUTH请求中携带第一标识时，若IKE_SA_INIT响应中携带的第二标识和IKE_AUTH请求中携带的第三标识均表示请求对H(e)NB执行基于证书的设备认证，则可以根据SeGW的本地安全策略，执行对H(e)NB的基于证书的设备认证和EAP-AKA宿主认证。其中H(e)NB和SeGW进行消息交互以协商认证方式以及基于证书的设备认证的信令流程同上述图9所示的实施例，EAP-AKA宿主认证的信令流程与上述带有宿主认证实施例中的信令流程相同，在此不再赘述。 图10为本发明认证协商方法第四实施例的第二信令流程图。本实施例中以SeGW对H(e) NB执行EAP-AKA设备认证为例。此时IKE_SA_INIT响应和IKE_AUTH请求中没有携带第一标识，并且IKE_SA_INIT响应中携带的第二标识和IKE—AUTH请求中携带的第三标识均表示请求或者支持对H(e)NB执行EAP-AKA设备认证。如图IO所示，包括如下步骤
步骤1101、 H(e)NB向SeGW发送IKE_SA_INIT请求消息；
步骤1102、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; 根据本地安全策略，SeGW判断仅需要对H(e)NB执行EAP-AKA设备认证，因此在IKE_SA_INIT响应消息中没有携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带表示SeGW支持或者请求EAP-AKA设备认证的第二标识，例如第二标识可以为消息类型为EAP-AKA_AUTH的NOTIFY头域、或EAP头域，以表示该SeGW仅请求或者支持对H(e)NB进行EAP-AKA设备认证； 步骤1103、 H(e)NB向SeGW发送IKE_AUTH请求消息，其中相应地也不携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带表示H(e)NB支持EAP-AKA设备认证的第三标识，例如第三标识可以为消息类型为EAP-AKA_AUTH的NOTIFY头域、或指示EAP-AKA设备认证的网络接入标识(NAI)，以表示H(e)NB同样支持EAP-AKA设备认证；
至此，H(e)NB和SeGW根据上述消息交互，还可能结合本地的安全策略，协商好需要进行EAP-AKA设备认证； 步骤1104、 SeGW对H(e)NB执行EAP-AKA设备认证过程，为清晰起见，此处省略了SeGW返回H(e)NB的IKE_AUTH响应消息。 另外，当IKE_SA_INIT响应和IKE_AUTH请求中携带第一标识时，若IKE_SA_INIT响应中携带的第二标识和IKE—AUTH请求中携带的第三标识均表示请求对H(e)NB执行EAP-AKA设备认证，则可以根据SeGW的本地安全策略，执行对H (e) NB的EAP-AKA设备认证和EAP-AKA宿主认证。其中H(e) NB和SeGW进行消息交互以协商认证方式以及EAP-AKA设备认证的信令流程同上述图10所示的实施例，EAP-AKA宿主认证的信令流程与上述带有宿主认证实施例中的信令流程相同，在此不再赘述。 图11为本发明认证协商方法第四实施例的第三信令流程图。当IKE_SA_INIT响应和IKE—AUTH请求中没有携带第一标识时，若第二标识和第三标识分别请求对家庭无线接入点执行不同的设备认证，则要根据SeGW的本地安全策略，拒绝对H(e)NB执行设备认证，或者按照第三标识请求执行的设备认证执行对H(e)NB的设备认证。如图11所示，包括如下步骤 步骤1201、 H(e)NB向SeGW发送IKE_SA_INIT请求消息；
步骤1202、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; 根据本地安全策略，SeGW判断仅需要对H(e)NB执行设备认证，因此在IKE_SA_INIT响应消息中没有携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，以表示该SeGW仅请求或者支持对H(e)NB进行设备认证；其中SeGW支持的设备认证又包括基于证书的设备认证和EAP-AKA设备认证，因此该步骤1202中携带表示SeGW请求或者支持基于证书的设备认证的第二标识，例如第二标识可以为消息类型为CERT_AUTH的NOTIFY头域、或CERTREQ头域，以说明此时的SeGW支持基于证书的设备认证； 步骤1203、 H(e)NB向SeGW发送IKE_AUTH请求消息，其中相应地也不携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带表示H(e)NB仅支持基于EAP-AKA设备认证的第三标识，例如第三标识可以为消息类型为EAP-AKA_AUTH的NOTIFY头域、或指示EAP-AKA设备认证的网络接入标识(NAI)，表示H(e)NB支持EAP-AKA设备认证；
由于H(e)NB可能仅支持EAP-AKA设备认证，因此在步骤1203中发送的IKE_AUTH请求消息中表明H(e)NB仅支持EAP-AKA设备认证，但步骤1202中SeGW选择为请求或者支持基于证书的设备认证，因此出现异常情况； 步骤1204、 SeGW根据本地安全策略作进一步的处理，具体地，SeGW可以根据本地安全策略在此异常情况下拒绝对H (e) NB进行设备认证，并结束本流程；由于SeGW支持所有的认证方式，因此SeGW也可以根据本地安全策略允许执行对H (e) NB的EAP-AKA设备认证。
图12为本发明认证协商方法第四实施例的第四信令流程图。与图11相比的区别在于，第二标识和第三标识所带的信息相反，如图12所示，包括如下步骤
步骤1301、 H(e)NB向SeGW发送IKE—SA—INIT i青求消息;
步骤1302、 SeGW发送IKE_SA_INIT响应消息给H(e)NB ; 根据本地安全策略，SeGW判断仅需要对H(e)NB执行设备认证，因此在IKE_SA_INIT响应消息中没有携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，以表示该SeGW仅请求或者支持对H(e)NB进行设备认证；其中SeGW支持的设备认证又包括基于证书的设备认证和EAP-AKA设备认证，因此该步骤1302中携带表示SeGW请求或者支持EAP-AKA设备认证的第二标识，例如第二标识可以为消息类型为EAP-AKA_AUTH的NOTIFY头域、或EAP头域，以说明此时的SeGW支持EAP-AKA设备认证； 步骤1303、 H(e)NB向SeGW发送IKE_AUTH请求消息，其中相应地也不携带消息类型为MULTIPLE_AUTH_SUPPORTED的NOTIFY头域，但携带表示H(e)NB仅支持基于证书的设备认证的第三标识，例如第三标识可以为消息类型为CERT_AUTH的NOTIFY头域、或AUTH头域、或指示基于证书的设备认证的网络接入标识(NAI)，表示H(e)NB支持基于证书的设备认证； 由于H(e)NB可能仅支持基于证书的设备认证，因此在步骤1303中发送的IKE_AUTH请求消息中表明H(e)NB仅支持基于证书的设备认证，但步骤1302中SeGW选择为请求或者支持EAP-AKA设备认证，因此出现异常情况； 步骤1304、 SeGW根据本地安全策略作进一步的处理，具体地，SeGW可以根据策略在此异常情况下拒绝对H (e) NB进行设备认证，并结束本流程；由于SeGW支持所有的认证方式，因此SeGW也可以根据策略允许执行对H(e)NB的基于证书的设备认证。
另外，当IKE_SA_INIT响应和IKE_AUTH请求中携带第一标识时，若第二标识和第三标识的内容不一致，属于图11或图12所示的情况时，则SeGW根据本地安全策略，拒绝对H(e)NB执行设备认证和宿主认证，或者按照第三标识请求执行的设备认证类型执行对H(e)NB的该类型的设备认证(基于证书或者EAP-AKA)和EAP-AKA宿主认证。其中H(e)NB和SeGW进行消息交互以协商认证方式以及基于证书的设备认证的信令流程同上述图11或图12所示的实施例，EAP-AKA宿主认证的信令流程与上述带有宿主认证实施例中的信令流程相同，在此不再赘述。 本发明上述认证协商方法的四个实施例提供的多个信令流程，通过在IKE_SA_INIT响应和IKE—AUTH请求中携带不同的标识，可以实现认证协商过程；但是由于SeGW支持所有的认证方式，而H(e)NB可能仅支持部分或者所有认证方式，因此该认证协商的过程
17可能会存在SeGW设定的设备认证方式H(e)NB并不支持，此时理论上SeGW也是可以调整并继续下面的认证过程的，所以在任何情况下的认证协商仍然可以实现。
图13为本发明安全网关实施例的结构示意图。如图13所示，该安全网关包括接收模块ll，发送模块12和处理模块13。其中接收模块11用于接收家庭无线接入点(H(e)NB)发送的因特网密钥交换-安全联盟-初始化(IKE_SA_INIT)请求，以及接收H(e)NB发送的因特网密钥交换_认证(IKE_AUTH)请求；发送模块12用于发送IKE_SA_INIT响应以及IKE_AUTH响应至H(e)NB ;处理模块用于根据IKE_SA_INIT响应和IKE_AUTH请求中是否携带有支持对H(e)NB执行设备认证和宿主认证的第一标识，执行对H(e)NB的认证。
采用该安全网关实现对H(e)NB的认证的具体方法详见上述认证协商方法实施例，在此不再赘述。 本发明提供的安全网关通过与H(e)NB之间的消息交互完成认证协商的过程，并对H (e) NB进行认证，提供了一种简单准确的认证机制。 图14为本发明家庭无线接入点实施例的结构示意图。如图14所示，该家庭无线接入点包括发送模块21、接收模块22和处理模块23。其中发送模块21用于发送IKE—SA—INIT请求以及IKE_AUTH请求至安全网关(SeGW);接收模块22用于接收SeGW发送的IKE_SA_INIT响应以及IKE_AUTH响应；处理模块23用于根据IKE_SA_INIT响应中是否携带有支持对H(e)NB执行设备认证和宿主认证的第一标识，决定是否在IKE_AUTH请求中也携带第一标识。 采用该家庭无线接入点与SeGW实现信息的交互，从而可以实现对H(e)NB的认证，其具体方法详见上述认证协商方法实施例，在此不再赘述。 图15为本发明认证协商系统实施例的结构示意图。如图15所示，该认证协商系统包括安全网关(SeGW) 1和家庭无线接入点(H(e)NB)2。其中H(e)NB2用于发送IKE_SA_INIT请求以及IKE—AUTH请求，接收返回的IKE_SA_INIT响应以及IKE_AUTH响应；并根据IKE_SA_INIT响应中是否携带有支持对H(e)NB2执行设备认证和宿主认证的第一标识，决定是否在IKE—AUTH请求中也携带第一标识；SeGWl，用于接收H(e)NB2发送的IKE_SA_INIT请求以及IKE—AUTH请求；发送IKE_SA_INIT响应以及IKE_AUTH响应至H(e)NB2 ;并根据IKE—SAJNIT响应和IKE—AUTH请求中是否携带有支持对H(e)NB2执行设备认证和宿主认证的第一标识，执行对H(e) NB2的认证。 其中，SeGWl包括接收模块ll，发送模块12和处理模块13。 H(e)NB2包括发送模块21、接收模块22和处理模块23。 采用该认证协商系统实现SeGW对H(e) NB的认证的具体方法详见上述认证协商方法实施例，在此不再赘述。 本发明提供的认证协商系统通过SeGW与H(e)NB之间的消息交互完成认证协商的过程，并对H(e)NB进行认证，提供了一种简单准确的认证机制。 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可获取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory， ROM)或随机存储记忆体(Random AccessMemory,廳)等。
最后应说明的是以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
19
权利要求
一种认证协商方法，其特征在于，包括接收家庭无线接入点H(e)NB发送的因特网密钥交换-安全联盟-初始化IKE_SA_INIT请求；发送IKE_SA_INIT响应至所述H(e)NB；接收所述H(e)NB发送的第一因特网密钥交换-认证IKE_AUTH请求；根据所述IKE_SA_INIT响应和第一IKE_AUTH请求中是否携带有支持对所述H(e)NB执行设备认证和宿主认证的第一标识，执行对所述H(e)NB的认证。
2. 根据权利要求1所述的认证协商方法，其特征在于，所述第一标识为消息类型为多 认证支持的通知头域。
3. 根据权利要求2所述的认证协商方法，其特征在于，所述根据所述IKE_SA_INIT响应 和第一 IKE—AUTH请求中是否携带所述第一标识，执行对所述H(e)NB的认证具体包括当所述IKE_SA_INIT响应和第一 IKE—AUTH请求中没有携带所述第一标识时，支持对所 述H(e)NB执行设备认证。
4. 根据权利要求3所述的认证协商方法，其特征在于，所述IKE_SA_INIT响应中携带有 第二标识，用于请求对所述H (e) NB执行基于证书的设备认证或可扩展的认证协议_认证与 密钥协商EAP-AKA设备认证。
5. 根据权利要求4所述的认证协商方法，其特征在于，所述支持对所述H(e)NB执行设 备认证具体包括若所述IKE_SA_INIT响应中携带请求对所述H(e)NB执行基于证书的设备认证的第二 标识，则支持对所述H(e)NB执行基于证书的设备认证；或者若所述IKE_SA_INIT响应中携带请求对所述H(e)NB执行EAP-AKA设备认证的第二标 识，则支持对所述H (e) NB执行EAP-AKA设备认证。
6. 根据权利要求4所述的认证协商方法，其特征在于，所述第一 IKE—AUTH请求中携带 有第三标识，用于请求对所述H(e)NB执行基于证书的设备认证或EAP-AKA设备认证。
7. 根据权利要求6所述的认证协商方法，其特征在于，所述支持对所述H(e)NB执行设 备认证具体包括若所述第二标识和所述第三标识均为请求对所述H(e)NB执行基于证书的设备认证的 标识，则支持对所述H(e)NB执行基于证书的设备认证；或者若所述第二标识和所述第三标识均为请求对所述H(e)NB执行EAP-AKA设备认证的标 识，则支持对所述H(e)NB执行EAP-AKA设备认证；或者若所述第二标识和所述第三标识分别为请求对所述H(e)NB执行不同的设备认证的标 识，则拒绝对所述H(e)NB执行设备认证，或者按照所述第三标识请求执行的设备认证支持 对所述H(e)NB执行设备认证。
8. 根据权利要求2所述的认证协商方法，其特征在于，所述根据所述IKE_SA_INIT响应 和第一 IKE—AUTH请求中是否携带所述第一标识，执行对所述H(e)NB的认证具体包括当所述IKE_SA_INIT响应和第一 IKE—AUTH请求中携带有所述第一标识时，支持对所述 H (e) NB执行设备认证和宿主认证。
9. 根据权利要求8所述的认证协商方法，其特征在于，所述IKE—SAJNIT响应中还携带 有第二标识，用于请求对所述H(e)NB执行基于证书的设备认证或EAP-AKA设备认证。
10. 根据权利要求9所述的认证协商方法，其特征在于，所述支持对所述H(e)NB执行设 备认证和宿主认证具体包括若所述IKE_SA_INIT响应中携带请求对所述H(e)NB执行基于证书的设备认证的第二 标识，则支持对所述H(e)NB执行基于证书的设备认证和宿主认证；或者所述IKE_SA_INIT响应中携带请求对所述H(e)NB执行EAP-AKA设备认证的第二标识， 则支持对所述H(e)NB执行EAP-AKA设备认证和宿主认证。
11. 根据权利要求9所述的认证协商方法，其特征在于，所述第一IKE—AUTH请求中还携 带有第三标识，用于请求对所述H(e)NB执行基于证书的设备认证或EAP-AKA设备认证。
12. 根据权利要求11所述的认证协商方法，其特征在于，所述支持对所述H(e)NB执行 设备认证和宿主认证具体包括若所述第二标识和所述第三标识均为请求对所述H(e)NB执行基于证书的设备认证的 标识，则支持对所述H(e)NB执行基于证书的设备认证和宿主认证；或者若所述第二标识和所述第三标识均为请求对所述H(e)NB执行EAP-AKA设备认证的标 识，则支持对所述H(e)NB执行EAP-AKA设备认证和宿主认证；或者若所述第二标识和所述第三标识分别为请求对所述H(e)NB执行不同的设备认证的标 识，则拒绝对所述H(e) NB执行设备认证和宿主认证，或者按照所述第三标识请求执行的设 备认证支持对所述H (e) NB执行设备认证和宿主认证。
13. 根据权利要求8、 10或12所述的认证协商方法，其特征在于，所述支持对所述H(e) NB执行设备认证和宿主认证具体包括若所述第一 IKE—AUTH请求中还携带有表示将对所述H(e)NB执行宿主认证的第四标 识，则执行对所述H(e)NB的设备认证和宿主认证；或者执行对所述H(e)NB的设备认证后，接收到所述H(e)NB发送的携带有表示将对所述 H(e) NB执行宿主认证的第四标识的第二 IKE—AUTH请求，则执行对所述H(e) NB的宿主认证。
14. 根据权利要求13所述的认证协商方法，其特征在于，所述第四标识包括消息类型 为接着是另一种认证的通知头域和认证头域。
15. 根据权利要求4、5、6、7、9、10、11或12任一所述的认证协商方法，其特征在于， 请求对所述H(e)NB执行基于证书的设备认证的所述第二标识包括消息类型为证书认证的通知头域、或证书请求头域；或者请求对所述H(e)NB执行EAP-AKA设备认证的所述第二标识包括消息类型为EAP-AKA 认证的通知头域、或EAP头域。
16. 根据权利要求6、7、11或12所述的认证协商方法，其特征在于，请求对所述H(e)NB执行基于证书的设备认证的所述第三标识包括消息类型为证书 认证的通知头域、或认证头域、或指示基于证书的设备认证的网络接入标识；或者请求对所述H(e)NB执行EAP-AKA设备认证的所述第三标识包括消息类型为EAP-AKA 认证的通知头域、或指示EAP-AKA设备认证的网络接入标识。
17. 根据权利要求3、5、7、8、10或12所述的认证协商方法，其特征在于，所述执行对所 述H(e)NB的认证具体包括根据安全网关的本地安全策略，执行对所述H(e)NB的认证。
18. —种安全网关，其特征在于，包括接收模块，用于接收家庭无线接入点H(e)NB发送的因特网密钥交换_安全联盟_初始化IKE_SA_INIT请求，以及接收所述H(e)NB发送的因特网密钥交换_认证IKE—AUTH请求； 发送模块，用于发送IKE_SA_INIT响应以及IKE_AUTH响应至所述H(e)NB ; 处理模块，用于根据所述IKE_SA_INIT响应和IKE—AUTH请求中是否携带有支持对所述H(e) NB执行设备认证和宿主认证的第一标识，执行对所述H(e) NB的认证。
19. 一种家庭无线接入点，其特征在于，包括发送模块，用于发送因特网密钥交换_安全联盟_初始化IKE_SA_INIT请求以及因特网密钥交换_认证IKE_AUTH请求至安全网关；接收模块，用于接收所述安全网关发送的IKE_SA_INIT响应以及IKE_AUTH响应； 处理模块，用于根据所述IKE_SA_INIT响应中是否携带有支持对所述H(e)NB执行设备认证和宿主认证的第一标识，决定是否在所述IKE_AUTH请求中也携带所述第一标识。
20. —种认证协商系统，其特征在于，包括家庭无线接入点H(e)NB，用于发送因特网密钥交换-安全联盟-初始化IKE_SA_INIT 请求以及因特网密钥交换_认证IKE—AUTH请求，接收返回的IKE_SA_INIT响应以及IKE_ AUTH响应；并根据所述IKE_SA_INIT响应中是否携带有支持对所述H(e)NB执行设备认证 和宿主认证的第一标识，决定是否在所述IKE—AUTH请求中也携带所述第一标识；安全网关，用于接收所述H(e)NB发送的IKE—SAJNIT请求以及IKE_AUTH请求；发送 IKE_SA_INIT响应以及IKE—AUTH响应至所述H(e)NB ;并根据所述IKE_SA_INIT响应和IKE_ AUTH请求中是否携带有所述第一标识，执行对所述H(e)NB的认证。
全文摘要
本发明实施例涉及一种认证协商方法及系统、安全网关、家庭无线接入点。本发明实施例的认证协商方法包括接收H(e)NB发送的IKE_SA_INIT请求；发送IKE_SA_INIT响应至H(e)NB；接收H(e)NB发送的第一IKE_AUTH请求；根据IKE_SA_INIT响应和第一IKE_AUTH请求中是否携带有支持对H(e)NB执行设备认证和宿主认证的第一标识，执行对H(e)NB的认证。本发明实施例还提供了一种安全网关、家庭无线接入点以及认证协商系统。本发明实施例实现H(e)NB和SeGW之间的简单准确的认证协商机制，还可以减少现有技术中的版本繁多的H(e)NB和SeGW设备。
文档编号H04L29/06GK101754211SQ20081023970
公开日2010年6月23日 申请日期2008年12月15日 优先权日2008年12月15日
发明者何承东 申请人:华为技术有限公司