WO2013109417A2

WO2013109417A2 - Notarized ike-client identity and info via ike configuration payload support

Info

Publication number: WO2013109417A2
Application number: PCT/US2013/020292
Authority: WO
Inventors: Zaifeng Zong; Xiaoyun Zhou; Tricci So; Li Zhu
Original assignee: Zte Corporation; Zte (Usa) Inc.
Priority date: 2012-01-18
Filing date: 2013-01-04
Publication date: 2013-07-25
Also published as: WO2013109417A3

Abstract

Systems and methods for notarizing access point information are disclosed. An access point provides identity information to a gateway, wherein the gateway notarizes the identify information with a notarized signature. The notarized signature for the FAP information is sent to the access point. The access point sends both the identity information and the corresponding notarized signature to a core network associated with the access point. The core network verifies the FAP information by validating the gateway notarized signature prior to acceptance of the identity information.

Description

SPECIFICATION

TITLE

NOTARIZED IKE-CLIENT IDENTITY AND INFO VIA IKE CONFIGURATION PAYLOAD SUPPORT

[0001] IPSec IKEv2, RFC 5996, has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. Today Femtocell deployment requires the mobile operator's Femtocell AP (FAP) to leverage the IPSec IKEv2 to support mutual authentication and data protection between the insecure Femtocell, which typically deployed in customer's premise, and its corresponding mobile core network.

• A known security threat has been identified in Femto architecture for failing to validate the FAP's identity and information provided by FAP at the mobile operator's core network.

• This invention leverages the mutual authentication protocol handshake

operation between the IKE-client (i.e. IKE-initiator) and I KE-server (i.e. IKE- responder) in today IKEv2 standard to enable the I KE-server to notarize the information specified by the IKE-client. The notarized information can then be used by IKE-client to present to any 3^rd party who has trusted relationship with IKE-server to use as the proof of the true identity of the IKE-client and to use to verify for the information presented by IKE-client. In order to enable the IKE-client to specify the required information to be notarized, and to enable the IKE-server to feedback the notarized information to the IKE-client, a simple extension to the IKEv2 Configuration Payload is proposed by this invention to be used as the carriage to transport these two pieces of information between the IKE peers. FIELD OF THE INVENTION

[0002] The present invention relates to a method for extending the IKE mutual authentication capability and the configuration payload mechanism to support the IKE-server (i.e. IKE responder) to notarize the IKE-client (i.e. IKE initiator)'s identity and the specified information provided by IKE-client which can be used to present to 3^rd party who has trust relationship with IKE-server in order to certify the IKE-client's identity and the information that is provided.

BACKGROUND

[0003] Today many network solutions leverage the IPSec IKEv2 to provide the secure transport as well as some form remote configuration support for their network elements over third party infrastructure (e.g. ADSL, Cable etc.).

[0004] The standardized Femtocell architecture from Femto Forum as well as from many mobile standards (e.g. 3GPP, 3GPP2 and WiMAX) are good examples that all have common architecture to leverage the IPSec IKEv2 to interconnect the

Femtocell AP (FAP) with the Security Gateway (SeGW).

[0005] In typical Femtocell deployment, the FAP is mutually authenticated with the Security Gateway (SeGW) (e.g. via IKEv2 with public key signature based

authentication with certificates). Hence, the SeGW knows the real identity of the FAP. However, since there is no interface between the SeGW and Operator's core network elements, the operator's core network will depend on the information provided by the FAP which is transparent to the intermediate SeGW to proceed network operation decisions. A compromised FAP may present false information (e.g. a wrong Closed Subscriber Group Identity (CSG ID) or false access mode for 3GPP defined mobile network architecture) to the mobile operator's core network that could not be able to validate in order to influence the wrong system behavior in the network. [0006] A solution to address the above security gap is to have the SeGW which has the ability to validate the FAP to notarize the FAP information and generate a notarized signature. When the FAP needs to provide FAP information to the operator's core network, the FAP sends the FAP information together with the notarized signature certified by SeGW. The operator's core network can then verify the FAP information by validating the SeGW's notarized signature.

The following presents the generic Femtocell architecture and an example of Femtocell network configuration defined by 3GPP.

[0007] Figure-1 presents an overview of the routing paths for the NS-WLAN Offload and Non-3GPP Access.

[0008] In figure 1 , the H(e)NB is one variant of FAP defined by 3GPP, H(e)NB GW and H(e)MS are equivalent to Femto Gateway and Femto Management as defined in Femto generic architecture, respectively. The AAA server is used to support the authentication between the FAP and SeGW via IKEv2 EAP.

[0009] Since in Femto architecture, the device and server configuration are used and hence IPSec tunnel based on tunnel mode is established over the ISP which is considered as insecure link between FAP and SeGW. This IPSec tunnel is used to protect the transport of mobile operator specific signaling information exchange and its mobile subscriber's traffic.

TERMINOLOGY

[0010] FAP

Femtocell Access Point, a FAP is typically designed in home or enterprise environment.

[0011] Femtocell

Femtocell is a low-powered wireless access point that operates in licensed spectrum to connect standard mobile devices to a mobile operator's networking using residential broadband connections.

[0012] Femto GW

Femtocell Gateway, is the concentrate point of multiple FAPs.

[0013] Femto Management

Femto Management is the management system used to manage FAP.

[0014] SeGW

A Security Gateway provides secure termination and aggregation for users and signaling traffic to reach the mobile operator's core network. Examples of functions provided by Security Gateway are IPSec Encryption, DoS Mitigation, Dynamic Session Security and Real-time Bandwidth management to provide security for mobile operators' networks and their users.

[0015] H(e)NB

Home (evolved) Node B, the FAP defined by 3GPP, supports 2nd/3rd generation radio mode or LTE radio mode. It's called HNB when it supports 2^nd/3^rd generation radio mode, and HeNB when it supports LTE radio mode.

[0016] H(e)NB GW

H(e)NB GW is the concentrate point of H(e)NBs, it controls the H(e)NB registration, and handles 3GPP specific signaling.

[0017] H(e)MS

H(e)NB management system, the H(e)MS is used to send configuration parameters to the H(e)NB and to manage the H(e)NB by the mobile operator. [0018] UE

User equipment, it's a mobile terminal defined by 3GPP.

[0019] There is a recent study identifying a security threat in Femtocell architecture for failing to validate the FAP's identity and information provided by FAP at the mobile operator's core network.

[0020] In Femtocell architecture, an IPSec tunnel will be established between the SeGW and the FAP. This IPSec tunnel will be used to protect the transport of the signaling between the FAP and the operator's core network, as well as user packets. The signaling between the FAP and the operator's core network is encapsulated in the inner IP packet of the IPSec tunnel and is transparent to the SeGW.

[0021] After successful mutual authentication between the FAP and the SeGW, the operator's core network does not verify the FAP information sent by the FAP. This introduces a security threat when a FAP is compromised (e.g. impersonation), by injecting false information to the mobile operator's core network over the established IPSec tunnel with SeGW.

[0022] Since FAP is resided at the untrusted domain (i.e. customer premise), whereas SeGW is the trusted gateway entry to the core network domain, and given the mutual authenticated relationship between the SeGW and the FAP, hence, it would be reliable to have the SeGW to certify all the information that is sent by the FAP prior to the core network to process the information.

[0023] Unfortunately, in today generic and even technology specific FAP architecture, SeGW has no standardized interface to the mobile core network entities which perform the UE access control based on the FAP information. One of the main reasons is because SeGW is not specific designed for FAP deployment and hence, there is no justification to define specific interface to the mobile network entities. Never-the-less, it is outside the scope of this document to discuss the motivation behind such architecture decision.

[0024] Besides, given the existing deployment for FAP for mobile operator, it is too late to change the existing architecture which will introduce backward incompatibility for the network configuration. The most desirable solution to resolve the issue is by software upgrade with a backward compatible simple change.

SUMMARY OF THE INVENTION

[0025] A simple solution that is proposed to resolve this issue is to notarize the FAP information by the SeGW once the SeGW verifies the identity of the FAP. The notarized signature for the FAP information will be feedback to the FAP using the secured Configuration Payload (CP) as defined by IKEv2 today. The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the

information.

[0026] This solution requires minimum changes to the existing RFC 5996 - Internet Key Exchange Protocol Version 2 (IKEv2) to provide a standardized solution, and it does not introduce any backward incompatibility issue to the existing RFC, the existing specification, the existing architecture and the existing implementation.

[0027] The details on how to derive the SeGW notarized signature will not be defined by IETF as the IKEv2 CP is just used as a carriage to transport the signature. It is within scope of the mobile operators to work with their SeGW vendors to define their own algorithm of how the signature is computed.

[0028] The existing IKEv2 Configuration Payload (CP) is extended to allow the IKE- initiator to specify the information that is required to be notarized, and to allow the IKE-responder (i.e., SeGW) to insert the notarized signature of the FAP information into the CP to be sent back to the IKE-initiator (i.e., FAP) after the peers are successfully mutually authenticated.

[0029] The major advantages of this proposal are as follows:

- Simple extension to the existing IKEv2 RFC 5996 o only a new code point is required to be defined for the CP to

indicate the carriage of the SeGW's notarized signature of the FAP information.

- Fully compatibility to the existing architecture and procedures o FAP (i.e. IKE-initiator) has signaling path with operator's core

network to pass the FAP information and the signature. o CP is part of the IKEv2 parameters which is generally supported by existing FAP-SeGW IPSec/iKEv2 authentication procedures. o Each CP is designed to be standalone and orthogonal to each other, and hence, no concern for backward incompatibility to the existing IKEv2 procedures that are supported by the FAP.

- No impact to the existing security mechanisms for the end-to-end system and the existing protocols o the new added code point has no impact to the IKEv2

Configuration Payload to continue the use of the existing IKEv2 security mechanism.

[0030] Figure 2 describes the high-level control flows on how the IKEv2 CP is used to carry the FAP information and SeGW's notarized signature of the FAP information. BRI EF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 : FAP Generic System Architecture with an example of 3GPP H(e)NB Network Configuration

[0032] Figure 2: Example of the IKEv2 Configuration Payload solution to carry the SeGW's Notarized Signature of the FAP information

DETAILED DESCRIPTION OF THE INVENTION

[0033] As described in the section "Summary Of The Invention" above, this invention introduces "two" new code points and the corresponding descriptions to be added to RFC 5996 for the IKEv2 Configuration Payload section, are shown as follows:

Attribute Type Value Multi-Valued Length

CLIENT_NOTARIZED_INFO 16 NO 0 or more

SERVER_NOTARIZED_SIGNATURE 17 NO 0 or more

[0034] C LI E NT_NOTARIZED_l N FO - This info is provided by the initiator which is operated as a client in the IPSEC tunnel mode. The client provides the information that requires the server to notarize in the CFG_REQUEST so that the notarized signature can be validated by the 3^rd party to verify the client's true identity and the information that is provided by the client. More details are described in 3.15.x.

[0035] SERVER NOTARIZED SIGNATURE - This signature is generated only by the responder which is operated as a server in the IPSEC tunnel mode. The responder notarizes the information provided by the initiator received over the CFG_REQUEST If both the initiator and responder are mutually authenticated, the responder generates the notarized signature based on the information provided by the initiator and the signature will be inserted in CFG_REPLY. More details are described in 3.15.y.

[0036] 3.15.x Configuration Payloads for CUENT_NOTARIZEDJNFO

[0037] The Configuration payload is used by the IKE initiator to request its corresponding IKE responder via the CFG_REQUEST to notarize the info that is carried by this payload. The exact content of this CP and the algorithm of the notarize operation to generate the signature is outside the scope of IETF.

[0038] A minimal exchange might look like this:

CP(CFG_REQUEST) = CLIENT JSIOTARIZED_INFO(xx....)

[0039] 3.15.y Configuration Payloads for SERVER_NOTARIZED_SIGNATURE

[0040] The Configuration payload is used by the IKE responder to respond its corresponding IKE initiator via the CFG_REPLY to carry the notarized client's info by this payload. The exact content of this CP and the algorithm of the notarize operation to generate the signature is outside the scope of IETF.

[0041] A minimal exchange might look like this:

CP(CFG_REPLY) = SERVER_NOTARIZED_SIGNATURE(yy...)

References

[1] [RFC 5996] Internet Key Exchange Version 2, C. Kaulman et al

http://www.rfc-editor.org/rfc/rfc5996.txt

[2] [RFC 5389] Session Traversal Utility for NAT, J. Rosenberg et al,

http://www.rfc-editor.org/rfc/rfc5389.txt

[3] S3-1 10307:

http://www.3qpp.org/ftp/tsa sa/WG3 Securitv/TSGS3 63 Chenqdu/Docs/S3- 110307

[4] S3-110545:

http://www.3gpp.org/ftp/tsg sa/WG3 Securitv/TSGS3 63 Chengdu/Docs/S3- 110545

[5] Infosec Pals article - UMA FemtoCell Security Concerns:

http://infosecpals.com/blog/articles/uma-femtocell-securitv-concerns

Claims

1. A method for notarizing internet key exchange (IKE) identity of a client associated with an access point, comprising: providing, by the access point, information associated with the identity of the access point, to a gateway, wherein the gateway notarizes the identify information; and sending, by the access point, both the identify information and the notarizing information to a core network corresponding to a mobile operator associated with the client.

2. The method of claim 1 , further comprising: validating, by the core network, the identity information and the notarizing information.

3. The method of claim 2, wherein the access point comprises a femto access point.

4. A system for notarizing internet key exchange (IKE) identity of a client, comprising: an access point associated with the client, configured to: provide Information associated with the identity of the access point, to a gateway; and send both the identify information and the notarizing information to a core network corresponding to a mobile operator associated with the client.

5. The system of claim 4, wherein the core network validates the identity information and the notarizing information.

6. The system of claim 5, wherein the access point is a femto access point.

7. An apparatus for notarizing internet key exchange (IKE) identity of a client, comprising: means for providing information associated with the identity of an access point associated with the client, to a gateway, wherein the gateway notarizes the identify information; and means for sending both the identify information and the notarizing information to a core network corresponding to a mobile operator associated with the client.

8. The apparatus of claim 7, further comprising: means for validating, by the core network, the identity information and the notarizing information.