WO2010069202A1

WO2010069202A1 - Authentication negotiation method and the system thereof, security gateway, home node b

Info

Publication number: WO2010069202A1
Application number: PCT/CN2009/074561
Authority: WO
Inventors: 何承东
Original assignee: 华为技术有限公司
Priority date: 2008-12-15
Filing date: 2009-10-22
Publication date: 2010-06-24
Also published as: CN101754211A

Abstract

This invention provides an authentication negotiation method and the system thereof, a security gateway, and a home Node B. The authentication negotiation method includes the following steps: receiving the IKE_SA_INIT request sent by the H(e)NB; sending the KE_SA_INIT response to the H(e)NB; receiving the first IKE_AUTH request sent by the H(e)NB; implementing the authentication to the H(e)NB based on whether the first identifier, which supports the device authentication and the hosting party authentication, is included in the IKE_SA_INIT response and the first IKE_AUTH request. The security gateway, the home Node B and the authentication negotiation system are also provided. The authentication negotiation mechanism between the H(e)NB and the SeGW can be implemented simply and accurately, and the various versions of the H(e)NB and the SeGW devices may be reduced.

Description

Authentication negotiation method and system, security gateway, home wireless access point This application is submitted to the Chinese Patent Office on December 15, 2008, and the application number is 200810239705.3. The invention name is "certification negotiation method and system, security gateway, home wireless connection." The priority of the Chinese Patent Application, the entire disclosure of which is incorporated herein by reference. Technical field

The present invention relates to the field of mobile communication technologies, and in particular, to an authentication negotiation method and system, a security gateway, and a home wireless access point. Background technique

Currently, 3GPP and non-3GPP standards organizations are studying a new access mode: home access mode, user equipment (UE) through home wireless access point (Home Node B, HNB), licensed language Connect to the carrier's mobile network through a universal IP public access network. Since the security gateway (SeGW) network element of the HNB in the mobile network of the carrier moves through the IP public access network, it is possible to introduce a common network attack in the IP public network. The core network element is required. Here, the SeGW of the HNB authenticates the HNB device. The certification includes device authentication and host authentication (Host Party Module, HPM, host module, usually with HPM for host authentication). Device authentication refers to the authentication of the HNB device itself; host authentication is the host authentication of the device with the HNB.

The latest 3GPP H(e)NB (including HNB and HeNB (Home Evolved Node B)) security specification 33.820 Vl.2.0 (document number S3-081585) defines the following authentication principles: Authentication and Key Agreement (Extensible Authentication Protocol - Authentication and Key Agreement, EAP-AKA) (DH(e)NB, optionally supporting the EAP-AKA host authentication mechanism;

3 The requirements for the SeGW of the H(e)NB are the same as the two requirements 1 and 2 for the H(e)NB. In addition, the SeGW can decide which security mechanism to use according to the security policy of the operator.

4 Which of the above authentication mechanisms is used depends on the network deployment.

The above-mentioned H(e)NB and SeGW mainly negotiate the authentication mechanism according to the Internet Key Exchange V2 (IKE V2) protocol defined in RFC4306. The main idea of the IKE V2 protocol is to first perform the interaction of the IKE-Security Association - INITial request (IKE SA INIT request) I IKE_SA_INIT response (IKE_SA_INIT response) message pair to negotiate encryption. Algorithm, exchange random numbers, and perform Diffie-Hellman exchange; then perform IKE-Authentication request (IKE-AUTH request) I IKE AUTH response (IKE_AUTH response) message The interaction of the pair, in order to authenticate the above IKE-SA-INIT message, exchange identity and certificate, and establish the first child security alliance. There may also be multiple IKE-AUTH request/response message pairs for subsequent processing of subsequent authentication.

The following is a detailed description of the existing negotiation scheme for the authentication mechanism:

Negotiation scheme 1. If SeGW carries the notification (NOTIFY) header field and certificate request (CERTREQ) header field with the message type multi-authentication support ( MULTIPLE AUTH SUPPORT) in the IKE-SA-INIT response message; H(e)NB In the subsequent IKE-AUTH request message, the authentication (AUTH) header field is also carried, the message type is MULTIPLE-AUTH-SUPPORT's NOTIFY header field, and the message type is "Next Next Authentication" (ANOTHER_AUTH_FOLLOWS) The NOTIFY header field, the result of the negotiation is the use of certificate-based device authentication and EAP-AKA host authentication.

Negotiation scheme 2: If SeGW carries the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORT in the IKE-SA-INIT response message, but does not carry the CERTREQ header field; H(e)NB in the subsequent IKE-AUTH request message Did not carry the AUTH header field, but the same The NOTIFY header field with the message type MULTIPLE-AUTH_SUPPORT and the NOTIFY header field with the message type ANOTHER-AUTH-FOLLOWS are carried, and the negotiation result is EAP-AKA device authentication and EAP-AKA host authentication.

Negotiation scheme 3: If SeGW does not carry the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORT in the IKE-SA_INIT response message, but carries the CERTREQ header field; H(e)NB in the subsequent IKE-AUTH request message The AUTH header field is carried, but the NOTIFY header field with the message type MULTIPLE-AUTH-SUPPORT and the NOTIFY header field with the message type ANOTHER-AUTH-FOLLOWS are not carried, and the negotiation result is the device authentication based on the certificate authentication, but There is no EAP-AKA host certification.

Negotiation scheme 4. If the SeGW does not carry the NOTIFY header field and the CERTREQ header field of the message type MULTIPLE-AUTH_SUPPORT in the IKE-SA-INIT response message; H(e)NB does not have any subsequent IKE-AUTH request message. The NOTIFY header field carrying the AUTH header field, the message type is MULTIPLE-AUTH-SUPPORT, and the NOTIFY header field of the message type ANOTHER-AUTH-FOLLOWS, the negotiation result is EAP-AKA device authentication, but there is no EAP-AKA host authentication. .

In addition to the above four negotiation schemes, the exception is an abnormal situation. SeGW needs to be further judged and processed according to the operator's security policy.

In the process of implementing the present invention, the inventors found that the H(e)NB and SeGW used in the prior art authentication mechanism and the negotiation scheme between them have at least the following disadvantages:

On the network deployment, the device vendors need to provide at least the following versions of H(e)NB and SeGW for different authentication requirements of different carriers: Only devices that support certificate-based device authentication, only EAP-AKA device authentication is supported. Devices, devices that support both certificate-based device authentication and EAP-AKA host authentication, devices that support both EAP-AKA device authentication and EAP-AKA host authentication, and possibly also support for certificate-based device authentication, EAP-AKA Device authentication and EAP-AKA host certified device. For operators, due to the large number of devices, H(e)NB and SeGW purchased by operators from different equipment vendors may support different authentication methods. This may lead to various abnormal situations during authentication negotiation, and may not even complete the authentication of H(e)NB. Therefore, it is impossible to truly meet the certification requirements of operators. Summary of the invention

The embodiments of the present invention provide a method and system for authenticating an authentication, a security gateway, and a home wireless access point, so as to reduce the number of H(e)NB and SeGW devices in the prior art, and provide a simpler and more accurate method. Authentication mechanism.

According to an aspect of the embodiments of the present invention, an authentication negotiation method is provided, including: receiving an Internet Key Exchange-Security Association-Initialization IKE-SA-INIT request sent by a Home Wireless Access Point H(e)NB;

Sending an IKE_SA_INIT response to the H(e)NB;

Receiving, by the H(e)NB, a first Internet Key Exchange-Authentication IKE AUTH request; according to whether the IKE-SA_INIT response and the first IKE-AUTH request carry support for the H(e) The NB performs a first identifier of the device authentication and the host authentication, and performs authentication on the H(e)NB.

According to another aspect of the present invention, a security gateway is provided, including: a receiving module, configured to receive an Internet Key Exchange-Security Association-Initialization IKE-SA sent by a Home Wireless Access Point H(e)NB An INIT request, and receiving an Internet Key Exchange-Authentication IKE AUTH request sent by the H(e)NB;

a sending module, configured to send an IKE-SA-INIT response and an IKE AUTH response to the

H(e)NB;

a processing module, configured to perform, according to the IKE-SA-INIT response and the IKE-AUTH request, a first identifier that supports performing device authentication and host authentication on the H(e)NB, and performing the ) NB certification.

According to another aspect of the embodiments of the present invention, a home wireless access point is provided, including: a sending module, configured to send an Internet Key Exchange-Security Association-Initialize IKE-SA-INIT Request and Internet Key Exchange - Authentication IKE AUTH request to the security gateway;

a receiving module, configured to receive an IKE-SA-INIT response and an IKE-AUTH response sent by the security gateway;

a processing module, configured to determine, according to whether the IKE-SA-INIT response carries a first identifier that supports performing device authentication and host authentication on the H(e)NB, and whether to carry the IKE AUTH request The first identifier is described.

According to another aspect of an embodiment of the present invention, an authentication negotiation system is provided, including: a home wireless access point H(e)NB for transmitting an Internet Key Exchange-Security Association-initializing an IKE SA INIT request and an Internet secret Key exchange-authentication IKE AUTH request, receiving the returned IKE SA INIT response and IKE-AUTH response; and according to whether the IKE SA INIT response carries the support for performing device authentication and host authentication on the H(e)NB An identifier, determining whether the first identifier is also carried in the IKE-AUTH request;

a security gateway, configured to receive an IKE_SA_INIT request sent by the H(e)NB and an IKE AUTH request; send an IKE_SA_INIT response and an IKE AUTH response to the H(e)NB; The IKE SA INIT response and the IKE-AUTH request carry the first identifier, and perform authentication on the H(e)NB.

According to the foregoing technical solution, the authentication negotiation method and system, the security gateway, and the home wireless access point provided by the embodiments of the present invention implement H by determining the IKE-SA-INIT response and the identifier carried in the IKE-AUTH request. e) A simple and accurate authentication negotiation mechanism between the NB and the SeGW can also reduce the number of H(e)NB and SeGW devices in the prior art. DRAWINGS

1 is a schematic structural diagram of a system for home access according to an embodiment of the present invention;

2 is a schematic flowchart of a first embodiment of an authentication negotiation method according to the present invention;

3 is a first signaling flowchart of a second embodiment of an authentication negotiation method according to the present invention;

4 is a second signaling flowchart of a second embodiment of an authentication negotiation method according to the present invention; FIG. 5 is a first signaling flowchart of a third embodiment of an authentication negotiation method according to the present invention; FIG. 6 is a second signaling flowchart of a third embodiment of an authentication negotiation method according to the present invention;

7 is a third signaling flowchart of a third embodiment of an authentication negotiation method according to the present invention;

8 is a fourth signaling flowchart of a third embodiment of an authentication negotiation method according to the present invention;

FIG. 9 is a first signaling flowchart of a fourth embodiment of an authentication negotiation method according to the present invention;

FIG. 10 is a second signaling flowchart of a fourth embodiment of the authentication negotiation method according to the present invention;

FIG. 11 is a third signaling flowchart of a fourth embodiment of an authentication negotiation method according to the present invention;

FIG. 12 is a fourth signaling flowchart of a fourth embodiment of an authentication negotiation method according to the present invention;

13 is a schematic structural diagram of an embodiment of a security gateway according to the present invention;

14 is a schematic structural diagram of an embodiment of a home wireless access point according to the present invention;

FIG. 15 is a schematic structural diagram of an embodiment of an authentication negotiation system according to the present invention. detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

FIG. 1 is a schematic structural diagram of a system for home access according to an embodiment of the present invention. As shown in FIG. 1, a home wireless access point (H(e)NB) is used, and a licensed user's equipment (UE) is connected to the operator's mobile network through a universal IP public network. The home wireless access point includes an HNB, a home wireless access point operating in the Universal Mobile Telecommunications System (UMTS) UMTS Territorial Radio Access Network (UTRAN) spectrum; the HeNB, operating in an evolved Home wireless access point for UMTS terrestrial radio access network (Evolved-UTRAN, E-UTRAN) spectrum; Home non-3GPP WAP (Home non-3GPP wireless access point), operating on non-3 GPP networks (eg CDMA/Wimax) Home wireless access point for spectrum/network such as WLAN/HRPD). Gateway network element of the home wireless access point, including the HNB network Off (HNB GW), HeNB GW, and Home non-3GPP WAP GW, which perform home wireless access point management and access control, aggregate home wireless access points, route and forward home wireless access points, and mobile networks Functions such as signaling data between network elements; in addition, the above-mentioned gateway network elements (HNB GW, HeNB GW, and Home non-3 GPP WAP GW) also have a security gateway (SeGW) of a home wireless access point. Function, perform safety-related functions such as authentication, force. Secret and so on. The Mobility Management Entity (MME) is responsible for control plane mobility management in the E-UTRAN network, including user context and mobility state management, and assigning user temporary identity. Service Serving GPRS Supporting Node (SGSN) for implementing routing and forwarding, mobility management, session management, and user information storage in General Packet Radio Service (GPRS)/UMTS networks . The non-3GPP gateway entity (non-3GPP GW) implements functions such as mobility management and session management in the non-3GPP network. For a WLAN network, the non-3GPP GW is an Evolved Packet Data Gateway (EPDG); for a Wimax network, the non-3 GPP GW is an Access Service Network Gateway (ASN GW); for a CDMA network The non-3GPP GW is an Access Gateway (AGW); for the HRPD network, the non-3GPP GW is a High Speed Packet Data Serving Gateway (HSGW). The Home Subscriber Server (HSS) is used to store user subscription information. The Authentication, Authorization and Accounting Server (AAA Server) is used to perform access authentication, authorization, and accounting functions for the UE. The Home Management Server (HMS) is responsible for the management functions of the home wireless access point. The HMS can be an independent network element or integrated into the HSS. The HMS can also directly connect to the home wireless access point. The embodiments of the present invention are not limited. In addition, the system architecture of the home access is not meant to be the system architecture of the final home access, and the embodiment of the present invention is also not limited.

Because the walking between the home wireless access point and the SeGW network element corresponding to the home wireless access point is

IP public network, which may introduce common network attacks in IP networks, so the core network is needed. Element, where each SeGW network element corresponding to the home wireless access point authenticates the home wireless access point, including device authentication and host authentication. The device authentication in the latest 3GPP H(e)NB security specification 33.820 VI .2.0 includes certificate-based device authentication or EAP-AKA Over IKE V2 device authentication, that is, EAP-AKA device authentication running on the IKE V2 protocol. An authentication mechanism, all operators use one of the authentication mechanisms in the device authentication; host authentication only includes the EAP-AKA authentication method, and some operators may use it, some operators may not use it, and for For host-authenticated mobile networks, host authentication is typically performed after device authentication.

In the technical implementation of the existing negotiation scheme, if the AU-AUTH request message carries the AUTH header field as a decision to support the certificate-based device authentication or the EAP-AKA device authentication basis, then the IKE-AUTH request message is used. Carrying the NOTIFY header field of ANOTHER-AUTH-FOLLOWS must also carry the AUTH header field, ie AUTH and ANOTHER-AUTH-FOLLOWS are always bound together, so the AUTH header field cannot be used as a means of determining device authentication. in accordance with.

If the IKE-SA-INIT response message carries the CERTREQ header field as a judgment to support certificate-based device authentication or a basis for supporting EAP-AKA device authentication, since the CERTREQ header field can also request to carry content other than the certificate, The basis of the CERTREQ header field as a means of determining device authentication is also inappropriate.

If MULTIPLE- AUTH-SUPPPORTED and ANOTHER-AUTH-FOLLOWS are bound in the same IKE-AUTH request message as the basis for judging whether to support both device authentication and host authentication, since according to RFC4739, "Next IKE-AUTH will contain The second identity, and the next authentication, ie the host authentication, is enabled. Therefore, for scenarios that support both EAP-AKA device authentication and EAP-AKA host authentication, the next IKE-AUTH is still used to initiate EAP-AKA device authentication. , not the EAP-AKA host certified, and therefore does not comply with RFC4739. Therefore, when the two are bound to the same IKE-AUTH request message, it is only applicable to scenarios that support both certificate-based device authentication and EAP-AKA host authentication, but not for EAP-AKA device authentication and EAP- AKA host authentication scenario. In addition, for H(e)NB In this case, the MULTIPLE-AUTH-SUPPORTED header field can only be carried in the first IKE-AUTH request message, and ANOTHER-AUTH-FOLLOWS can be carried in any IKE-AUTH request/response message containing the AUTH header field. That is, it is not necessary for the two to be bound in the same IKE-AUTH request message, so as not to affect the flexibility of negotiation.

For the problem existing in the above existing negotiation scheme, the method for authentication negotiation used in the embodiment of the present invention will be described based on the system architecture of the home access shown in FIG.

In the following embodiments of the present invention, in order to solve the problem of a large number of existing device versions, a home wireless access point (hereinafter referred to as H(e)NB) or a security gateway network element (hereinafter referred to as SeGW) manufactured by a device manufacturer is used. Or H(e)NB and SeGW support all authentication methods, so that after the network deployment, the operator decides which authentication method or combination of use between H(e)NB and SeGW is more free. In the following embodiments of the present invention, in order to solve the problems existing in the existing authentication scheme, the following three points are mainly used to improve the existing authentication negotiation scheme: 1 to extend the message of the NOTIFY header field in the IKE V2 protocol. Type to indicate the type of device authentication, SeGW and H(e)NB carry the NOTIFY header field of the extended message type in the IKE SA INIT response message and the IKE-AUTH request message respectively to indicate the supported device authentication mode; The IKE V2 protocol can carry an EAP header field, such as the NOTIFY message type in the EAP protocol, to indicate the type of device authentication. The SeGW and the H(e)NB are carried in the IKE-SA-INIT response message and the IKE-AUTH request message, respectively. The EAP header field indicates the supported device authentication mode; 3 The MULTIPLE-AUTH-SUPPPORTED and ANOTHER-AUTH-FOLLOWS are no longer bound in the same IKE-AUTH request message.

First, all the authentication modes are supported for the H(e)NB. The SeGW may only support the authentication negotiation in the case of partial authentication. In this case, no abnormalities will occur in the authentication negotiation.

FIG. 2 is a schematic flowchart diagram of a first embodiment of an authentication negotiation method according to the present invention. As shown in Figure 2, the following steps are included:

Step 301: Receive an IKE-SA-INIT request sent by a home wireless access point (H(e)NB); Step 302: Send an IKE_SA_INIT response to the H(e)NB.

Step 303: Receive an IKE-AUTH request sent by the H(e)NB.

Step 304: Perform authentication on the H(e)NB according to whether the IKE-SA-INIT response and the IKE-AUTH request carry the first identifier that supports device authentication and host authentication for the H(e)NB.

Steps 301 to 303 are specifically as follows: H(e)NB sends an IKE_SA_INIT request; after receiving the IKE_SA_INIT request sent by H(e)NB, the SeGW returns an IKE_SA_INIT response to H (e) NB; H(e)NB sends an IKE-AUTH request; after receiving the IKE-AUTH request, the SeGW completes the main authentication negotiation process. The steps of the SeGW returning the IKE AUTH response to the H(e)NB, and the subsequent IKE-AUTH request/response messages in the device authentication and host authentication procedures are omitted in the embodiment of the present invention. Step 304 is performed according to the negotiation result of step 302 and step 303, that is, whether the IKE-SA_INIT response and the IKE-AUTH request carry the first identifier that supports device authentication and host authentication for the H(e)NB, and is executed by the SeGW. H(e)NB authentication, including device authentication or device authentication and host authentication.

For certificate-based device authentication and EAP-AKA device authentication, when the SeGW device supports only one of the device authentication modes, some parameters carried in the IKE-SA-INIT response in step 302 can indicate the supported device authentication mode. Therefore, under the premise that only one type of host authentication is supported between H(e)NB and SeGW, it is only necessary to perform device authentication for H(e)NB by judging whether the IKE-SA-INIT response and the IKE AUTH request carry the support. And the first identifier of the host authentication, and the authentication performed by the SeGW on the H(e)NB can be determined. Detailed description will be made below through specific embodiments.

The authentication negotiation method provided by the embodiment of the present invention can implement a simple and accurate authentication negotiation process between the H(e)NB and the SeGW by carrying the identifier indicating the authentication mode in the IKE-SA-INIT response and the IKE AUTH request. The H(e)NB supports all authentication modes. The SeGW can support all authentication modes or devices that support only partial authentication modes. This reduces the failure of authentication negotiation due to device matching problems.

FIG. 3 is a first signaling flowchart of a second embodiment of an authentication negotiation method according to the present invention. Based on the above diagram In the embodiment shown in FIG. 2, it is assumed in the embodiment that there is only one type of device authentication between the H(e)NB and the SeGW, that is, the device authentication of the certificate or the EAP-AKA device authentication, and H ( e) NB supports all authentication modes, that is, H(e)NB supports device authentication mode and host authentication. As shown in Figure 3, the following steps are included:

Step 401: The H(e)NB sends an IKE_S A-INIT request message to the SeGW.

Step 402: The SeGW sends an IKE-SA-INIT response message to the H(e)NB.

The SeGW determines that the device authentication and the host authentication are performed on the H(e)NB. Therefore, the IKE SA INIT response message carries a first identifier indicating that the SeGW supports or requests device authentication and host authentication for the H(e)NB, for example, the first identifier. The identifier may be a NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED; the step 402 does not carry the second identifier of which device authentication is requested, indicating that both the SeGW and the H(e)NB support only the same device. Authentication mode device; assuming that both SeGW and H(e)NB support only certificate-based device authentication in this embodiment, then step 402 indicates that the SeGW supports certificate-based device authentication and EAP-AKA for H(e)NB Host certification;

Step 403: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the bearer carries

The H(e)NB supports or requests a first identifier for device authentication and host authentication. For example, the first identifier may be a NOTIFY header field whose message type is MULTIPLE-AUTH_SUPPORTED indicates that H(e)NB only supports or requests certificate-based Equipment certification and EAP-AKA host certification;

At this point, H(e)NB and SeGW interact according to the above message, and may also cooperate with the local security policy to negotiate certificate-based device authentication and EAP-AKA host authentication.

Step 404: The SeGW performs a certificate-based device authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

Step 405: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field and the AUTH header field carrying the message type followed by the next authentication (ANOTHER_AUTH_FOLLOWS) indicate that the device authentication has been completed, and the next step EAP-AKA host authentication will then be performed on H(e)NB; It should be noted that step 405 and 403 above may also be combined in the same IKE-AUTH request message, that is, the NOTIFY header field of ANOTHER-AUTH-FOLLOWS and the NOTIFY header field of MULTIPLE-AUTH-SUPPORTED are bound together. An IKE-AUTH request message;

Step 406: The SeGW performs an EAP-AKA host authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

When it is assumed that the specific authentication negotiation process when the SeGW and the H(e)NB support only the EAP-AKA device authentication is the same as the specific authentication negotiation process when the SeGW supports the certificate-based device authentication, only the step 404 performs the SeGW pair H(e). NB's EAP-AKA device authentication process; and it should be noted that step 405 and the above 403 cannot be merged in the same IKE-AUTH request message, that is, the NOTIFY header field and MULTIPLE of ANOTHER-AUTH-FOLLOWS must be combined. – AUTH – The NOTIFY header field of SUPPORTED is carried separately in different IKE-AUTH messages.

FIG. 4 is a second signaling flowchart of a second embodiment of the authentication negotiation method according to the present invention. Based on the embodiment shown in FIG. 2, it is assumed in the embodiment that there is only one type of device authentication between the H(e)NB and the SeGW, that is, the device authentication of the certificate or the EAP-AKA device authentication. The H(e)NB supports all authentication modes, that is, the H(e)NB supports the device authentication mode and the host authentication. The IKE SA INIT response and the IKE-AUTH request do not carry the first indicating support device authentication and host authentication. The identifier, for example, the first identifier may be the MULTIFY_AUTH_SUPPORTED NOTIFY header field. As shown in Figure 4, the following steps are included:

Step 501: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 502: The SeGW sends an IKE-SA-INIT response message to the H(e)NB.

The SeGW determines that the device authentication needs to be performed only for the H(e)NB. Therefore, the IKE-SA-INIT response message does not carry the first identifier indicating that the SeGW supports or requests the device authentication and host authentication for the H(e)NB, for example, An identifier may be a NOTIFY header field of message type MULTIPLE-AUTH-SUPPORTED to indicate that the SeGW only supports Or requesting device authentication for the H(e)NB; the step 502 does not carry the second identifier of which device authentication is requested, indicating that both the SeGW and the H(e)NB support only the same device authentication mode. For example, if the SeGW and the H(e)NB support only the EAP-AKA device authentication in this embodiment, the step 502 indicates that the SeGW performs EAP-AKA device authentication on the H(e)NB; Step 503, H(e) The NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED does not carry the H(e)NB only supports or requests the EAP-AKA device authentication;

At this point, H(e)NB and SeGW interact according to the above message, and may also cooperate with the local security policy to negotiate EAP-AKA device authentication.

Step 504: The SeGW performs an EAP-AKA device authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

The embodiment shown in FIG. 4 is different from the embodiment shown in FIG. 3 in that the embodiment shown in FIG. 4 does not carry a NOTIFY header field whose message type is MULTIPLE-AUTH_SUPPORTED, and the identifier is only executed for H(e)NB. Device authentication without the host authentication process of steps 405 and 406. In addition, the specific authentication negotiation process when the SeGW only supports the certificate-based device authentication is the same as the specific authentication negotiation process in the case where the SeGW only supports the EAP-AKA device authentication in FIG. 4, but only the Step 504 performs the SeGW to the H(e)NB. The certificate-based device authentication process is not described here.

Summarizing the embodiment shown in FIG. 3 and FIG. 4, when the first identifier is not carried in the IKE-SA-INIT response and the IKE-AUTH request, the device authentication of the H(e)NB is performed according to the local security policy of the SeGW. When the first identifier is carried in the IKE-SA-INIT response and the IKE-AUTH request, device authentication and host authentication for the H(e)NB are performed according to the local security policy of the SeGW.

Based on the foregoing H(e)NB supporting all the authentication modes, if the SeGW also supports all the authentication modes, the IKE-SA-INIT response may also perform the authentication negotiation by carrying the second identifier, the second identifier. Used to request to perform certificate-based device authentication or EAP-AKA device authentication for the H(e)NB. The following description will be made by way of specific examples.

FIG. 5 is a first signaling flowchart of a third embodiment of an authentication negotiation method according to the present invention. In this embodiment For example, the SeGW performs certificate-based device authentication only for the H(e)NB. The IKE-SA-INIT response and the IKE-AUTH request do not carry the first identifier, and the second identifier carried in the IKE SA INIT response indicates that the certificate-based device authentication is performed on the H(e)NB, for example, the second identifier. It can be a NOTIFY header field, or a certificate request (CERTREQ) header field with a message type of certificate authentication (CERT_AUTH). As shown in FIG. 5, the following steps are included:

Step 601: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 602: The SeGW sends an IKE_SA_INIT response message to the H(e)NB.

The SeGW judges that only the certificate-based device authentication needs to be performed on the H(e)NB. Therefore, the IKE SA INIT response message does not carry the NOTIFY header field whose message type is MULTIPLE-AUTH_SUPPORTED, but carries the SeGW support or requests the certificate-based The second identifier of the device authentication, for example, the second identifier may be a NOTIFY header field with a message type of CERT_AUTH, or a CERTREQ header field, to indicate that the SeGW only requests or supports certificate-based device authentication for the H(e)NB;

Step 603: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field of the message type MULTIPLE_AUTH_SUPPORTED is not carried. The H(e)NB supports certificate-based device authentication.

At this point, H(e)NB and SeGW interact according to the above message, and may also cooperate with the local security policy to negotiate certificate-based device authentication.

Step 604: The SeGW performs a certificate-based device authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

FIG. 6 is a second signaling flowchart of a third embodiment of an authentication negotiation method according to the present invention. In this embodiment, the EGW-AKA device authentication is performed only on the H(e)NB by the SeGW. The IKE-SA-INIT response and the IKE-AUTH request do not carry the first identifier, and the second identifier carried in the IKE SA INIT response indicates that the EAP-AKA device authentication, such as the second identifier, is supported for the H(e)NB. It can be a NOTIFY header field or an EAP header field whose message type is EAP-AKA authentication ( EAP-AKA-AUTH ). As shown in Figure 6, the following steps are included: Step 701: The H(e)NB sends an IKE_SA_INIT request message to the SeGW. Step 702: The SeGW sends an IKE_SA_INIT response message to the H(e)NB.

The SeGW judges that only the EAP-AKA device authentication needs to be performed on the H(e)NB. Therefore, the NOTIFY header field with the message type MULTIPLE-AUTH_SUPPORTED is not carried in the IKE-SA-INIT response message, but carries the SeGW support EAP- The second identifier of the AKA device authentication, for example, the second identifier may be a NOTIFY header field or an EAP header field with a message type of EAP-AKA-AUTH, to indicate that the SeGW only requests or supports device authentication for the H(e)NB;

Step 703: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field of the message type MULTIPLE_AUTH_SUPPORTED is not carried, and the H(e)NB supports the EAP-AKA device authentication.

Step 704: The SeGW performs an EAP-AKA device authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

In the embodiment shown in FIG. 5 and FIG. 6 , the IKE-SA-INIT response message carries the second identifier indicating that the SeGW supports or requests the authentication of different devices, and the IKE-SA-INIT response message carries the representation. When the SeGW supports or requests the second identifier of the certificate-based device authentication, that is, the SeGW performs certificate-based device authentication on the H(e)NB; when the IKE-SA-INIT response message carries the indication that the SeGW supports or requests the EAP-AKA device authentication The second identity, that is, SeGW performs EAP-AKA device authentication for H(e)NB.

In addition, when the IKE-SA-INIT response message carries the second identifier indicating that the SeGW supports or requests the certificate-based device authentication, that is, the SeGW performs certificate-based device authentication on the H(e)NB; When the SA-INIT response message does not carry the second identifier, the SeGW performs EAP-AKA device authentication on the H(e)NB. Or when the IKE-SA-INIT response message carries the second identifier indicating that the SeGW supports or requests the EAP-AKA device authentication, that is, The SeGW performs EAP-AKA device authentication on the H(e)NB; and when the IKE-SA-INIT response message does not carry the second identifier, the SeGW performs certificate-based device authentication on the H(e)NB.

FIG. 7 is a third signaling flowchart of a third embodiment of the authentication negotiation method according to the present invention. In this embodiment, the SeGW performs only certificate-based device authentication and EAP-AKA host authentication for the H(e)NB as an example. The IKE-SA-INIT response and the IKE-AUTH request carry the first identifier, and the second identifier carried in the IKE SA INIT response indicates that the SeGW supports certificate-based device authentication. For example, the second identifier may be a message type CERT-AUTH. The NOTIFY header field or the CERTREQ header field. As shown in Figure 7, the following steps are included:

Step 801: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 802: The SeGW sends an IKE_SA_INIT response message to the H(e)NB.

The SeGW determines that the certificate-based device authentication and the EAP-AKA host authentication need to be performed on the H(e)NB. Therefore, the IKE-SA-INIT response message carries the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED, and carries the SeGW. Supporting or requesting a second identifier of the certificate-based device authentication, for example, the second identifier may be a NOTIFY header field or a CERTREQ header field with a message type of CERT_AUTH, to indicate that the SeGW only requests or supports the H(e)NB based on Certificate device certification and EAP-AKA host certification;

Step 803: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field carrying the message type MULTIPLE-AUTH_SUPPORTED indicates that the H(e)NB supports certificate-based device authentication and EAP-AKA host authentication.

Step 804: The SeGW performs a certificate-based device authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

Step 805: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field and the AUTH header field carrying the message type ANOTHER_AUTH_FOLLOWS indicate that the device authentication has been completed, and the next step is to proceed to H(e). NB performs EAP-AKA host authentication; It should be noted that step 805 and 803 above can also be combined in the same IKE-AUTH request message, that is, the NOTIFY header field of ANOTHER-AUTH-FOLLOWS and the NOTIFY header field of MULTIPLE-AUTH-SUPPORTED are bound together. An IKE-AUTH request message;

Step 806: The SeGW performs an EAP-AKA host authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

FIG. 8 is a fourth signaling flowchart of a third embodiment of the authentication negotiation method according to the present invention. In this embodiment, the SeGW only performs EAP-AKA device authentication and EAP-AKA host authentication for the H(e)NB as an example. The IKE-SA-INIT response and the IKE-AUTH request carry the first identifier, and the second identifier carried in the IKE SA INIT response indicates that the EAP-AKA device authentication is performed on the H(e)NB, for example, the second identifier may be It is a NOTIFY header field or an EAP header field whose message type is EAP-AKA-AUTH. As shown in Figure 8, the following steps are included:

Step 901: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 902: The SeGW sends an IKE_SA_INIT response message to the H(e)NB.

The SeGW determines that the EAP-AKA device authentication and the EAP-AKA host authentication need to be performed on the H(e)NB. Therefore, the IKE-SA-INIT response message carries the NOTIFY header field with the message type MULTIPLE-AUTH-SUPPORTED, and carries the SeGW. A second identifier supporting the EAP-AKA device authentication, for example, the second identifier may be a NOTIFY header field or an EAP header field of the EAP-AKA-AUTH message type, to indicate that the SeGW only requests or supports the device for the H(e)NB. Certification and host certification;

Step 903: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field carrying the message type MULTIPLE-AUTH_SUPPORTED indicates that the H(e)NB supports EAP-AKA device authentication and EAP-AKA host authentication.

At this point, H(e)NB and SeGW interact according to the above message, and may also cooperate with the local security policy to negotiate EAP-AKA device authentication and EAP-AKA host authentication.

Step 904: The SeGW performs an EAP-AKA device authentication process on the H(e)NB. For the sake of clarity, The IKE-AUTH response message that SeGW returns to H(e)NB is omitted here;

Step 905: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field and the AUTH header field carrying the message type ANOTHER_AUTH_FOLLOWS indicate that the device authentication has been completed, and the next step is to proceed to H(e). NB performs EAP-AKA host authentication;

It should be noted that step 905 here and 903 above cannot be combined in the same article.

IKE—AUTH request message, that is, the NOTIFY header field of ANOTHER_AUTH_FOLLOWS and the NOTIFY header field of MULTIPLE_AUTH_SUPPORTED must be separated in different IKE-AUTH messages;

Step 906: The SeGW performs an EAP-AKA host authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

With the embodiment shown in FIG. 5 and FIG. 6 above, in the embodiment shown in FIG. 7 and FIG. 8, the IKE-SA-INIT response message may also carry the device authentication indicating that the SeGW supports or requests the certificate-based device. The second identifier, that is, the SeGW performs certificate-based device authentication on the H(e)NB; and when the IKE SA INIT response message does not carry the second identifier, the SeGW performs EAP-AKA device authentication on the H(e)NB. Alternatively, when the IKE-SA-INIT response message carries the second identifier indicating that the SeGW supports or requests the EAP-AKA device authentication, that is, the SeGW performs EAP-AKA device authentication on the H(e)NB; and when the IKE-SA – When the second identifier is not carried in the INIT response message, the SeGW performs certificate-based device authentication on the H(e)NB.

The H(e)NB can support the H(e)NB and the SeGW by using the identifier in the foregoing embodiment, whether the HGW supports all the authentication modes or only the partial authentication mode. Between the authentication and the negotiation, the authentication of the H(e)NB is achieved without an abnormal situation.

The following is a description of how all authentication methods are supported by the SeGW. The H(e)NB may support all or only partial authentication methods. In this case, in addition to the IKE-SA-INIT response carrying the second identity requesting the certificate-based device authentication or EAP-AKA device authentication for the H(e)NB, the IKE-AUTH request also carries the request pair. The H(e)NB performs a certificate-based device authentication or a third identity of the EAP-AKA device authentication. However, there may still be an abnormal situation in the authentication negotiation based on this case.

FIG. 9 is a first signaling flowchart of a fourth embodiment of an authentication negotiation method according to the present invention. In this embodiment, the certificate-based device authentication is performed on the H(e)NB by the SeGW as an example. The IKE-SA-INIT response and the IKE-AUTH request do not carry the first identifier, and the second identifier carried in the IKE SA INIT response and the third identifier carried in the IKE-AUTH request indicate the request or support for H ( e) NB performs certificate-based device authentication. As shown in Figure 9, the following steps are included:

Step 1001: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 1002: The SeGW sends an IKE_SA_INIT response message to the H(e)NB.

SeGW judges that only certificate-based device authentication is required for H(e)NB, so

The IKE SA INIT response message does not carry the NOTIFY header field with the message type MULTIPLE-AUTH_SUPPORTED, but carries the second identifier indicating that the SeGW supports or requests the certificate-based device authentication. For example, the second identifier may be the message type CERT_AUTH. a NOTIFY header field, or a CERTREQ header field, to indicate that the SeGW only requests or supports certificate-based device authentication for the H(e)NB;

Step 1003: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED is not carried, but the bearer indicates that the H(e)NB supports the certificate-based device authentication. The third identifier, for example, the third identifier may be a NOTIFY header field of message type CERT_AUTH, or an AUTH header field, or a Network Access Identifier (NAI) indicating certificate-based device authentication, to indicate H (e) NB also supports certificate-based device authentication;

Step 1004: The SeGW performs a certificate-based device authentication process on the H(e)NB. For the sake of clarity, the SeGW returns the H(e)NB IKE-AUTH response message.

In addition, when the first identifier is carried in the IKE-SA-INIT response and the IKE-AUTH request, The second identifier carried in the IKE SA INIT response and the third identifier carried in the IKE-AUTH request indicate that the request to perform certificate-based device authentication for the H(e)NB may be performed according to the local security policy of the SeGW. e) NB's certificate-based device authentication and EAP-AKA host authentication. The signaling flow in which the H(e)NB and the SeGW perform message interaction to negotiate the authentication mode and the certificate-based device authentication is the same as the embodiment shown in FIG. 9 above, the signaling procedure of the EAP-AKA host authentication and the above-mentioned host authentication The signaling process in the embodiment is the same, and details are not described herein again.

FIG. 10 is a second signaling flowchart of a fourth embodiment of an authentication negotiation method according to the present invention. In this embodiment, the EAP-AKA device authentication is performed by the SeGW on the H(e)NB as an example. The IKE-SA-INIT response and the IKE-AUTH request do not carry the first identifier, and the second identifier carried in the IKE SA INIT response and the third identifier carried in the IKE-AUTH request indicate the request or support for H ( e) NB performs EAP-AKA device authentication. As shown in Figure 10, the following steps are included:

Step 1101: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 1102: The SeGW sends an IKE_SA_INIT response message to the H(e)NB.

According to the local security policy, the SeGW determines that only the E(AP) device needs to perform EAP-AKA device authentication. Therefore, the IKE-SA-INIT response message does not carry the NOTIFY header field with the message type MULTIPLE-AUTH-SUPPORTED, but carries the representation. The SeGW supports or requests the second identifier of the EAP-AKA device authentication. For example, the second identifier may be a NOTIFY header field with a message type of EAP-AKA-AUTH, or an EAP header field, to indicate that the SeGW only requests or supports the H (e). NB performs EAP-AKA device authentication;

Step 1103: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED is not carried, but the bearer indicates that the H(e)NB supports the EAP-AKA device authentication. The third identifier, for example, the third identifier may be a NOTIFY header field of message type EAP-AKA_AUTH, or a network access identifier (NAI) indicating EAP-AKA device authentication, to indicate that H(e)NB also supports EAP. - AKA device authentication; At this point, H(e)NB and SeGW interact according to the above message, and may also cooperate with the local security policy to negotiate EAP-AKA device authentication; Step 1104: The SeGW performs an EAP-AKA device authentication process on the H(e)NB. For the sake of clarity, the IKE-AUTH response message of the SeGW returning to the H(e)NB is omitted here.

In addition, when the first identifier is carried in the IKE-SA-INIT response and the IKE-AUTH request, if the second identifier carried in the IKE SA INIT response and the third identifier carried in the IKE-AUTH request indicate the request to the H (e) If the NB performs EAP-AKA device authentication, the EAP-AKA device authentication and EAP-AKA host authentication for the H(e)NB may be performed according to the local security policy of the SeGW. The signaling process in which the H(e)NB and the SeGW perform message interaction to negotiate the authentication mode and the EAP-AKA device authentication is the same as the embodiment shown in FIG. 10, the signaling procedure of the EAP-AKA host authentication and the above-mentioned host authentication. The signaling process in the embodiment is the same, and details are not described herein again.

FIG. 11 is a third signaling flowchart of a fourth embodiment of the authentication negotiation method according to the present invention. when

When the IKE SA INIT response and the IKE-AUTH request do not carry the first identifier, if the second identifier and the third identifier respectively request different device authentication for the home wireless access point, the network security policy according to the SeGW is rejected. The H(e)NB performs device authentication, or performs device authentication for the H(e)NB according to the device authentication performed by the third identification request. As shown in FIG. 11, the method includes the following steps: Step 1201: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 1202: The SeGW sends an IKE_SA_INIT response message to the H(e)NB.

According to the local security policy, the SeGW determines that only the device authentication needs to be performed on the H(e)NB. Therefore, the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED is not carried in the IKE_SA_INIT response message, indicating that the SeGW only requests Or device authentication for the H(e)NB is supported. The device authentication supported by the SeGW includes the certificate-based device authentication and the EAP-AKA device authentication. Therefore, the step 1202 carries the device that indicates the SeGW request or supports the certificate-based device authentication. The second identifier, for example, the second identifier may be a NOTIFY header field with a message type of CERT_AUTH, or a CERTREQ header field, to indicate that the SeGW supports certificate-based device authentication at this time;

Step 1203: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED is not carried, but The band indicates that the H(e)NB only supports the third identity based on the EAP-AKA device authentication. For example, the third identifier may be a NOTIFY header field with a message type of EAP-AKA-AUTH, or a network access indicating EAP-AKA device authentication. Identification (NAI), indicating that H(e)NB supports EAP-AKA device authentication;

Since the H(e)NB may only support EAP-AKA device authentication, the IKE-AUTH request message sent in step 1203 indicates that the H(e)NB only supports EAP-AKA device authentication, but the SeGW selects the request in step 1202. Or the certificate-based device authentication is supported, so an abnormal situation occurs. Step 1204: The SeGW performs further processing according to the local security policy. Specifically, the SeGW may refuse to perform device authentication on the H(e)NB according to the local security policy. And end this process; Because SeGW supports all authentication methods, SeGW can also perform EAP-AKA device authentication for H(e)NB according to the local security policy.

FIG. 12 is a fourth signaling flowchart of a fourth embodiment of an authentication negotiation method according to the present invention. The difference compared with Fig. 11 is that the information of the second identifier and the third identifier are opposite, as shown in Fig. 12, including the following steps:

Step 1301: The H(e)NB sends an IKE_SA_INIT request message to the SeGW.

Step 1302: The SeGW sends an IKE-SA_INIT response message to the H(e)NB.

According to the local security policy, the SeGW determines that only the device authentication needs to be performed on the H(e)NB. Therefore, the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED is not carried in the IKE_SA_INIT response message, indicating that the SeGW only requests Or device authentication for the H(e)NB is supported. The device authentication supported by the SeGW includes the certificate-based device authentication and the EAP-AKA device authentication. Therefore, the step 1302 carries the first representation of the SeGW request or the EAP-AKA device authentication. The second identifier, for example, the second identifier may be a NOTIFY header field with a message type of EAP-AKA-AUTH, or an EAP header field, to indicate that the SeGW supports EAP-AKA device authentication at this time;

Step 1303: The H(e)NB sends an IKE-AUTH request message to the SeGW, where the NOTIFY header field of the message type MULTIPLE-AUTH_SUPPORTED is not carried, but the bearer indicates that the H(e)NB only supports the certificate-based device. The third identifier of the authentication, for example, the third identifier can For a NOTIFY header field of message type CERT_AUTH, or an AUTH header field, or a Network Access Identity (NAI) indicating certificate-based device authentication, indicating that H(e)NB supports certificate-based device authentication;

Since the H(e)NB may only support certificate-based device authentication, the IKE-AUTH request message sent in step 1303 indicates that the H(e)NB only supports certificate-based device authentication, but the SeGW selects the request in step 1302. Or the EAP-AKA device authentication is supported, and an abnormal situation occurs. Step 1304: The SeGW performs further processing according to the local security policy. Specifically, the SeGW may refuse to perform device authentication on the H(e)NB according to the policy, and This process is terminated; since the SeGW supports all authentication methods, the SeGW can also perform certificate-based device authentication for the H(e)NB according to the policy.

In addition, when the first identifier is carried in the IKE-SA-INIT response and the IKE-AUTH request, if the contents of the second identifier and the third identifier are inconsistent and belong to the situation shown in FIG. 11 or FIG. 12, the SeGW is based on The local security policy, which refuses to perform device authentication and host authentication for the H(e)NB, or performs device authentication of this type (based on certificate or EAP-AKA) for the H(e)NB according to the type of device authentication performed by the third identity request. And EAP-AKA host certification. The signaling flow in which the H(e)NB and the SeGW perform message exchange to negotiate the authentication mode and the certificate-based device authentication are the same as the embodiment shown in FIG. 11 or FIG. 12, and the signaling flow of the EAP-AKA host authentication and the foregoing The signaling process in the host authentication embodiment is the same and will not be described here. The IKE SA INIT response and the IKE-AUTH request carry different identifiers to implement the authentication negotiation process. However, since the SeGW supports all authentication methods, and the H(e)NB may only support some or all authentication methods, the authentication negotiation The process may have the device authentication mode set by SeGW. H(e)NB does not support. In this case, the SeGW can theoretically adjust and continue the following authentication process, so the authentication negotiation can still be implemented under any circumstances.

FIG. 13 is a schematic structural diagram of an embodiment of a security gateway according to the present invention. As shown in FIG. 13, the security gateway includes: a receiving module 11, a sending module 12, and a processing module 13. The receiving module 11 is used for receiving Receiving an Internet Key Exchange-Security Alliance-Initialization (IKE SA INIT) request sent by the Home Wireless Access Point (H(e)NB), and receiving an Internet Key Exchange-Authentication (IKE AUTH) sent by the H(e)NB The requesting module 12 is configured to send an IKE-SA-INIT response and an IKE AUTH response to the H(e)NB; the processing module is configured to carry a support pair H in the IKE-SA-INIT response and the IKE AUTH request. e) The NB performs the first identifier of the device authentication and the host authentication, and performs authentication on the H(e)NB.

The specific method for the authentication of the H(e)NB by using the security gateway is described in the above-mentioned authentication negotiation method embodiment, and details are not described herein again.

The security gateway provided by the present invention completes the process of authentication negotiation through message interaction with the H(e)NB, and authenticates the H(e)NB, providing a simple and accurate authentication mechanism.

FIG. 14 is a schematic structural diagram of an embodiment of a home wireless access point according to the present invention. As shown in FIG. 14, the home wireless access point includes: a sending module 21, a receiving module 22, and a processing module 23. The sending module 21 is configured to send an IKE-SA_INIT request and an IKE-AUTH request to the security gateway (SeGW); the receiving module 22 is configured to receive the IKE-SA-INIT response and the IKE-AUTH response sent by the SeGW; And determining whether to carry the first identifier in the IKE-AUTH request according to whether the IKE-SA-INIT response carries a first identifier that supports device authentication and host authentication for the H(e)NB.

The home wireless access point and the SeGW are used to implement the information exchange, so that the authentication of the H(e)NB can be implemented. For the specific method, refer to the foregoing authentication negotiation method embodiment, and details are not described herein.

FIG. 15 is a schematic structural diagram of an embodiment of an authentication negotiation system according to the present invention. As shown in FIG. 15, the authentication negotiation system includes: a security gateway (SeGW) 1 and a home wireless access point (H(e)NB) 2. Where H(e)NB2 is used to send the IKE_SA_INIT request and the IKE_AUTH request, receive the returned IKE SA INIT response and the IKE_AUTH response; and according to whether the IKE-SA-INIT response carries the support pair H ( e) NB2 performs the first identifier of the device authentication and the host authentication, and determines whether the first identifier is also carried in the IKE-AUTH request; the SeGW1 is configured to receive the IKE SA INIT request sent by the H(e)NB2 and the IKE_AUTH request; Send IKE—SA—INIT response and IKE AUTH responds to H(e)NB2; and performs H(e)NB2 according to whether the IKE SA INIT response and the IKE-AUTH request carry the first identifier supporting device authentication and host authentication for H(e)NB2 Certification.

The SeGW1 includes: a receiving module 11, a sending module 12, and a processing module 13. H(e)NB2 includes: a transmitting module 21, a receiving module 22, and a processing module 23.

The specific method for implementing the authentication of the H(e)NB by the SeGW in the authentication negotiation system is described in the foregoing embodiment of the authentication negotiation method, and details are not described herein.

The authentication negotiation system provided by the present invention completes the authentication negotiation process by using the message exchange between the SeGW and the H(e)NB, and authenticates the H(e)NB, thereby providing a simple and accurate authentication mechanism.

A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by a computer program to instruct related hardware, and the program can be stored in a computer-accessible storage medium. When executed, the flow of an embodiment of the methods as described above may be included. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

It should be noted that the above embodiments are only for explaining the technical solutions of the present invention, and are not intended to be limiting; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those skilled in the art that: The technical solutions described in the foregoing embodiments are modified, or some of the technical features are equivalently replaced. The modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

Claim

A method for authentication negotiation, which is characterized by comprising:

Receiving Home Wireless Access Point H(e)NB Sending Internet Key Exchange - Security Alliance - Initialization

IKE-SA—INIT request;

Sending an IKE_SA_INIT response to the H(e)NB;

The authentication negotiation method according to claim 1, wherein the first identifier is a notification header field whose message type is multi-authentication support.

The authentication negotiation method according to claim 2, wherein the performing the Η (»ΝΒ according to whether the IKE SA INIT response and the first IKE-AUTH request carry the first identifier The certification includes:

When the first identifier is not carried in the IKE_SA_INIT response and the first IKE-AUTH request, device authentication is performed on the H(e)NB.

The authentication negotiation method according to claim 3, wherein the IKE SA INIT response carries a second identifier, and is used to request to perform certificate-based device authentication or scalability on the H(e)NB. Authentication Protocol - Authentication and Key Agreement EAP-AKA Device Certification.

The authentication negotiation method according to claim 4, wherein the supporting the performing device authentication on the H(e)NB specifically includes:

Supporting performing certificate-based device authentication on the H(e)NB if the IKE-SA-INIT response carries a second identifier requesting to perform certificate-based device authentication on the H(e)NB; or The IKE-SA-INIT response carries a second identifier that performs EAP-AKA device authentication on the H(e)NB, and supports performing EAP-AKA device authentication on the H(e)NB.

The authentication negotiation method according to claim 4, wherein the first The IKE AUTH request carries a third identifier for requesting to perform certificate-based device authentication or EAP-AKA device authentication for the H(e)NB.

The authentication negotiation method according to claim 6, wherein the supporting the performing device authentication on the H(e)NB specifically includes:

If the second identifier and the third identifier are both identifiers for performing certificate-based device authentication on the H(e)NB, performing certificate-based device authentication on the H(e)NB; or If the second identifier and the third identifier are both identifiers for performing EAP-AKA device authentication on the H(e)NB, performing EAP-AKA device authentication on the H(e)NB; or If the second identifier and the third identifier respectively are identifiers for performing different device authentication on the H(e)NB, performing device authentication on the H(e)NB, or according to the foregoing three

When the IKE-SA_ΙΝΙΤ response and the first IKE-AUTH request carry the first identifier, device authentication and host authentication are performed on the H(e)NB.

The authentication negotiation method according to claim 8, wherein the IKE SA INIT response further carries a second identifier, configured to request to perform certificate-based device authentication or EAP on the H(e)NB. - AKA equipment certification.

The authentication negotiation method according to claim 9, wherein the supporting the device authentication and the host authentication specifically includes:

Supporting performing certificate-based device authentication and host authentication on the H(e)NB if the IKE-SA_ΙΝΙΤ response carries a second identifier requesting to perform certificate-based device authentication on the H(e)NB Or

Performing an EAP-AKA device on the H(e)NB by carrying the request in the IKE-SA-INIT response

The authentication negotiation method according to claim 9, wherein the first IKE AUTH request further carries a third identifier, configured to request to perform certificate-based device authentication on the H(e)NB or EAP-AKA equipment certification.

The authentication negotiation method according to claim 11, wherein the supporting performing device authentication and host authentication on the H(e)NB specifically includes:

Supporting certificate-based device authentication and hosting of the H(e)NB if the second identifier and the third identifier are both identifiers for performing certificate-based device authentication on the H(e)NB Certification or

If the second identifier and the third identifier are both identifiers for performing EAP-AKA device authentication on the H(e)NB, performing EAP-AKA device authentication and hosting on the H(e)NB Certification; or

If the second identifier and the third identifier respectively are identifiers for performing different device authentication on the H(e)NB, performing device authentication and host authentication on the H(e)NB, or according to The device authentication performed by the third identifier request performs device authentication and host authentication for the H(e)NB.

The authentication negotiation method according to claim 8, 10 or 12, wherein the performing the device authentication and the host authentication on the H(e)NB specifically includes:

Performing device authentication and host authentication for the H(e)NB if the first IKE-AUTH request further carries a fourth identifier indicating that host authentication is to be performed on the H(e)NB; or

After performing device authentication on the H(e)NB, receiving the second IKE_AUTH sent by the H(e)NB carrying a fourth identifier indicating that host authentication will be performed on the H(e)NB The request then performs host authentication for the H(e)NB.

The authentication negotiation method according to claim 13, wherein the fourth identifier comprises: the message type is a notification header field and an authentication header field followed by another authentication.

15. The authentication negotiation method according to any one of claims 4, 5, 6, 7, 9, 10, 11 or 12, characterized in that The requesting to perform the certificate-based device authentication on the H(e)NB includes: a notification header field whose message type is certificate authentication, or a certificate request header field; or

The second identifier for performing EAP-AKA device authentication on the H(e)NB includes: a notification header field whose message type is EAP-AKA authentication, or an EAP header field.

The authentication negotiation method according to claim 6, 7, 11 or 12, wherein the requesting the third identifier of performing certificate-based device authentication on the H(e)NB comprises: the message type is a certificate The authenticated notification header field, or the authentication header field, or the network access identifier indicating the certificate-based device authentication; or

The third identifier for performing EAP-AKA device authentication on the H(e)NB includes: a notification header field whose message type is EAP-AKA authentication, or a network access identifier indicating EAP-AKA device authentication.

The authentication negotiation method according to claim 3, 5, 7, 8, 10 or 12, wherein the performing the authentication of the H(e)NB specifically includes: according to a local security policy of the security gateway , performing authentication on the H(e)NB.

18. A security gateway, comprising:

a receiving module, configured to receive an Internet Key Exchange-Security Association-initialize IKE-SA-INIT request sent by the home wireless access point H(e)NB, and receive an Internet key exchange sent by the H(e)NB- Authenticate IKE AUTH request;

a sending module, configured to send an IKE_SA_INIT response and an IKE AUTH response to the H(e)NB;

19. A home wireless access point, comprising:

a sending module, configured to send an Internet Key Exchange-Security Association-Initialize IKE-SA-INIT request and an Internet Key Exchange-Authentication IKE AUTH request to the security gateway; a receiving module, configured to receive an IKE-SA-INIT response sent by the security gateway, and an IKE-AUTH response;

a processing module, configured to determine, according to whether the IKE_SA_INIT response carries a first identifier that supports performing device authentication and host authentication on the H(e)NB, and whether to carry in the IKE-AUTH request The first identifier.

20. An authentication negotiation system, comprising:

Home wireless access point H(e)NB for transmitting Internet Key Exchange-Security Association-Initializing IKE SA INIT Request and Internet Key Exchange-Authentication IKE-AUTH Request, Receiving Returned IKE SA INIT Response and IKE-AUTH And determining, according to whether the IKE SA INIT response carries a first identifier that supports performing device authentication and host authentication on the H(e)NB, and determining whether to carry the first in the IKE-AUTH request Identification

a security gateway, configured to receive an IKE-SA-INIT request sent by the H(e)NB and an IKE-AUTH request; send an IKE-SA-INIT response and an IKE-AUTH response to the H(e)NB; Whether the IKE SA INIT response and the IKE-AUTH request carry the first identifier, perform authentication on the H(e)NB.