[go: up one dir, main page]

WO2010069202A1 - Procédé de négociation d'authentification et système associé, passerelle de sécurité, noeud local b - Google Patents

Procédé de négociation d'authentification et système associé, passerelle de sécurité, noeud local b Download PDF

Info

Publication number
WO2010069202A1
WO2010069202A1 PCT/CN2009/074561 CN2009074561W WO2010069202A1 WO 2010069202 A1 WO2010069202 A1 WO 2010069202A1 CN 2009074561 W CN2009074561 W CN 2009074561W WO 2010069202 A1 WO2010069202 A1 WO 2010069202A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
ike
identifier
device authentication
auth
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2009/074561
Other languages
English (en)
Chinese (zh)
Inventor
何承东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of WO2010069202A1 publication Critical patent/WO2010069202A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Definitions

  • 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
  • HNB home wireless access point
  • SeGW security gateway
  • the core network element is required.
  • 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;
  • EAP-AKA Extensible Authentication Protocol - Authentication and Key Agreement
  • DH(e)NB optionally supporting the EAP-AKA host authentication mechanism
  • 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.
  • the SeGW can decide which security mechanism to use according to the security policy of the operator.
  • 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.
  • 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.
  • IKE-AUTH request I IKE AUTH response
  • IKE_AUTH response IKE-AUTH request/response message pairs
  • 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
  • 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.
  • 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.
  • 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.
  • 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. .
  • SeGW 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.
  • 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.
  • 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
  • an authentication negotiation method including: receiving an Internet Key Exchange-Security Association-Initialization IKE-SA-INIT request sent by a Home Wireless Access Point H(e)NB;
  • the NB receives, 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.
  • a security gateway 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
  • 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.
  • a home wireless access point 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.
  • an authentication negotiation system 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.
  • the authentication negotiation method and system, the security gateway, and the home wireless access point implement H by determining the IKE-SA-INIT response and the identifier carried in the IKE-AUTH request.
  • 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.
  • FIG. 1 is a schematic structural diagram of a system for home access according to an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a first embodiment of an authentication negotiation method according to the present invention
  • FIG. 3 is a first signaling flowchart of a second embodiment of an authentication negotiation method according to the present invention.
  • FIG. 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
  • FIG. 7 is a third signaling flowchart of a third embodiment of an authentication negotiation method according to the present invention.
  • FIG. 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.
  • FIG. 13 is a schematic structural diagram of an embodiment of a security gateway according to the present invention.
  • FIG. 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
  • FIG. 1 is a schematic structural diagram of a system for home access according to an embodiment of the present invention.
  • a home wireless access point H(e)NB
  • UE licensed user's equipment
  • 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).
  • UMTS Universal Mobile Telecommunications System
  • UTRAN Universal Mobile Telecommunications System
  • UTRAN Universal Mobile Telecommunications System
  • E-UTRAN UMTS Terrestriality
  • Home non-3GPP WAP Home non-3GPP wireless access point
  • non-3 GPP networks eg CDMA/Wimax
  • 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.
  • non-3GPP gateway entity implements functions such as mobility management and session management in the non-3GPP 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • H(e)NB home wireless access point
  • SeGW security gateway network element
  • 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.
  • 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.
  • 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.
  • 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.
  • H(e)NB home wireless access point
  • 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.
  • 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.
  • 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;
  • 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;
  • 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.
  • 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.
  • step 404 performs the SeGW pair H(e).
  • 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.
  • 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.
  • 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;
  • 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.
  • 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.
  • the device authentication of the H(e)NB is performed according to the local security policy of the SeGW.
  • 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.
  • 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.
  • 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
  • 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).
  • CERTREQ certificate request
  • CERT_AUTH message type of certificate authentication
  • 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.
  • 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.
  • 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 ).
  • Step 701 The H(e)NB sends an IKE_SA_INIT request message to the SeGW.
  • 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.
  • 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 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.
  • the IKE-SA-INIT response message carries the second identifier indicating that the SeGW supports or requests the authentication of different devices
  • the IKE-SA-INIT response message carries the representation.
  • 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
  • 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.
  • the SeGW performs certificate-based device authentication on the H(e)NB;
  • the SeGW performs EAP-AKA device authentication on the H(e)NB.
  • 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.
  • 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
  • the second identifier carried in the IKE SA INIT response indicates that the SeGW supports certificate-based device authentication.
  • 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.
  • 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 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;
  • 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 is, the NOTIFY header field of ANOTHER-AUTH-FOLLOWS and the NOTIFY header field of MULTIPLE-AUTH-SUPPORTED are bound together.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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;
  • 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.
  • 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.
  • 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 H(e)NB may support all or only partial authentication methods.
  • the IKE-AUTH request 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.
  • FIG. 9 is a first signaling flowchart of a fourth embodiment of an authentication negotiation method according to the present invention.
  • 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.
  • 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;
  • NAI Network Access Identifier
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • NAI network access identifier
  • 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;
  • the IKE-AUTH response message of the SeGW returning to the H(e)NB is omitted here.
  • 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.
  • 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.
  • 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.
  • 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;
  • 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.
  • 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;
  • NAI Network Access Identity
  • 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.
  • 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.
  • the IKE SA INIT response and the IKE-AUTH request carry different identifiers to implement the authentication negotiation process.
  • 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.
  • 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.
  • the NB performs the first identifier of the device authentication and the host authentication, and performs authentication on the H(e)NB.
  • 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.
  • 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.
  • 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.
  • the authentication negotiation system includes: a security gateway (SeGW) 1 and a home wireless access point (H(e)NB) 2.
  • 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
  • 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 authentication negotiation system 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.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un procédé de négociation d'authentification et le système associé, une passerelle de sécurité, et un nœud local B. Le procédé de négociation d'authentification comprend les étapes qui consistent : à recevoir la demande IKE_SA_INIT envoyée par H(e)NB; à envoyer la réponse KE_SA_INIT à H(e)NB; à recevoir la première demande IKE_AUTH envoyée par H(e)NB; à implémenter l'authentification sur H(e)NB selon que le premier identifiant, qui prend en charge l'authentification de dispositif et l'authentification de parti hôte, est inclus ou non dans la réponse IKE_SA_INIT et la première demande IKE_AUTH. La passerelle de sécurité, le nœud local B et le système de négociation d'authentification sont également prévus. Le mécanisme de négociation d'authentification entre H(e)NB et SeGW peut être implémenté simplement et avec précision et les diverses versions des dispositifs H(e)NB et SeGW peuvent être réduites.
PCT/CN2009/074561 2008-12-15 2009-10-22 Procédé de négociation d'authentification et système associé, passerelle de sécurité, noeud local b Ceased WO2010069202A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810239705.3 2008-12-15
CN200810239705.3A CN101754211A (zh) 2008-12-15 2008-12-15 认证协商方法及系统、安全网关、家庭无线接入点

Publications (1)

Publication Number Publication Date
WO2010069202A1 true WO2010069202A1 (fr) 2010-06-24

Family

ID=42268298

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/074561 Ceased WO2010069202A1 (fr) 2008-12-15 2009-10-22 Procédé de négociation d'authentification et système associé, passerelle de sécurité, noeud local b

Country Status (2)

Country Link
CN (1) CN101754211A (fr)
WO (1) WO2010069202A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011023223A1 (fr) * 2009-08-25 2011-03-03 Nokia Siemens Networks Oy Procédé de réalisation d'une authentification dans un réseau de communication

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2521388A4 (fr) * 2010-08-20 2014-01-15 Zte Corp Procédé d'authentification mutuelle entre des équipements d'accès réseau et équipements d'accès réseau
CN102457837B (zh) * 2010-10-21 2016-01-20 中兴通讯股份有限公司 一种用户签约信息处理方法和系统
CN102833359A (zh) * 2011-06-14 2012-12-19 中兴通讯股份有限公司 隧道信息获取方法、安全网关及演进家庭基站/家庭基站
CN103096398B (zh) 2011-11-08 2016-08-03 华为技术有限公司 一种网络切换的方法和装置
CN106302018B (zh) * 2016-08-18 2019-04-23 北京锦鸿希电信息技术股份有限公司 车地通信方法和增强型移动无线模块emrm
CN107820242A (zh) * 2016-09-14 2018-03-20 中国移动通信有限公司研究院 一种认证机制的协商方法及装置
CN110048988B (zh) * 2018-01-15 2021-03-23 华为技术有限公司 消息的发送方法和装置
CN114830705B (zh) * 2019-12-31 2025-05-06 华为技术有限公司 认证方法、装置及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070268888A1 (en) * 2006-05-18 2007-11-22 Cisco Technology, Inc. System and method employing strategic communications between a network controller and a security gateway
US20080162926A1 (en) * 2006-12-27 2008-07-03 Jay Xiong Authentication protocol
WO2008153456A1 (fr) * 2007-06-11 2008-12-18 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et agencement pour une manipulation de certificat

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070268888A1 (en) * 2006-05-18 2007-11-22 Cisco Technology, Inc. System and method employing strategic communications between a network controller and a security gateway
US20080162926A1 (en) * 2006-12-27 2008-07-03 Jay Xiong Authentication protocol
WO2008153456A1 (fr) * 2007-06-11 2008-12-18 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et agencement pour une manipulation de certificat

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Security ofH(e)NB; (Release 8).", 3GPP TR 33.820 VL .1.0., 9 December 2007 (2007-12-09) *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011023223A1 (fr) * 2009-08-25 2011-03-03 Nokia Siemens Networks Oy Procédé de réalisation d'une authentification dans un réseau de communication

Also Published As

Publication number Publication date
CN101754211A (zh) 2010-06-23

Similar Documents

Publication Publication Date Title
US11463874B2 (en) User profile, policy, and PMIP key distribution in a wireless communication network
CN101682630B (zh) 用于在无线通信网络中提供pmip密钥分层结构的方法和装置
WO2019017837A1 (fr) Procédé de gestion de sécurité de réseau et appareil
WO2010069202A1 (fr) Procédé de négociation d'authentification et système associé, passerelle de sécurité, noeud local b
US20110078442A1 (en) Method, device, system and server for network authentication
WO2008131689A1 (fr) Procédé et système de fourniture d'un service de communication d'urgence et dispositifs correspondants
WO2013063783A1 (fr) Procédé et dispositif de gestion de canal de sécurité de données
CN107466465B (zh) 使用互联网密钥交换消息来配置活动性检查
WO2006002601A1 (fr) Procede pour l'etablissement de la connexion de session par les utilisateurs de reseau local sans fil
CN106105134A (zh) 改进的端到端数据保护
TW200830901A (en) Handoff method of mobile device utilizing dynamic tunnel
WO2009135385A1 (fr) Procédé, système et dispositif pour obtenir un type de confiance d'un système d'accès non-3gpp
WO2010094244A1 (fr) Procédé, dispositif et système pour réaliser une authentification d'accès
TW201507526A (zh) 受信任無線區域網路（ｗｌａｎ）存取場景
WO2011127774A1 (fr) Procédé et appareil pour contrôler un mode d'accès d'un terminal utilisateur à internet
JP2008537644A (ja) 無線ネットワークにおけるモバイルユニットの高速ローミングの方法およびシステム
WO2010015134A1 (fr) Procédé de transmission d'options de configuration du protocole, système et équipement utilisateur s'y rapportant
US8611859B2 (en) System and method for providing secure network access in fixed mobile converged telecommunications networks
JP4687788B2 (ja) 無線アクセスシステムおよび無線アクセス方法
WO2012083873A1 (fr) Procédé, appareil et système de génération de clé
US9137661B2 (en) Authentication method and apparatus for user equipment and LIPA network entities
WO2011143977A1 (fr) Procédé et système d'établissement de clés améliorées lorsqu'un terminal rentre dans un réseau d'accès radio terrestre universel (utran) amélioré
CN113784351B (zh) 切片服务验证方法、实体及设备
WO2013037273A1 (fr) Procédé et système de traitement de capacité d'équipements d'utilisateurs
WO2013044759A1 (fr) Procédé, système et dispositif pour la mise en œuvre d'un contrôle de dérivation de service transparente

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09832884

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09832884

Country of ref document: EP

Kind code of ref document: A1