Network Working Group Z. Zong Internet-Draft ZTE Corporation Intended status: Standards Track January 18, 2012 Expires: July 21, 2012 IKEv2 Configuration Payload Extension for Notarizing Femtocell in Mobile Core Network draft-zong-ipsecme-ikev2-cpext4femto-00.txt Abstract IPSec IKEv2, RFC 5996 [RFC5996], 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 exists in Femto architecture for failing to validate the FAP's identity and information provided by FAP at the mobile operator's core network. This document reviews this security threat and proposes a simple extension of the IKEv2 to resolve the issue. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Zong Expires July 21, 2012 [Page 1] Internet-Draft cpext4femto January 2012 This Internet-Draft will expire on July 21, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zong Expires July 21, 2012 [Page 2] Internet-Draft cpext4femto January 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4. Proposed Solution - Extension to IKEv2 Configuration Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Details of proposed changes to RFC 5996 for IKEv2 CP . . . 10 4.1.1. Configuration Payloads for CLIENT_NOTARIZED_INFO . . . 10 4.1.2. Configuration Payloads for SERVER_NOTARIZED_SIGNATURE . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Zong Expires July 21, 2012 [Page 3] Internet-Draft cpext4femto January 2012 1. Introduction 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.). 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). 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. 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. Zong Expires July 21, 2012 [Page 4] Internet-Draft cpext4femto January 2012 Mobile Operator's Core Network C-------------------C | | | G-------------G | "Generic Femto Architecture" | |Femto-Gateway| | | G-------------G | I----------I | | | Internet | S----S M----------M | +------+ +------+ | Service | | | | Femto- | | |Mobile| | FAP |<==| Provider |===>|SeGW| |Management| | +------+ +------+ | (ISP) | | | M----------M | I----------I S----S | | A----------A | | | AAA | | | | Server | | | A----------A | C-------------------C Mobile Operator's Core Network /------------------\ "Example of Femto Network in 3GPP" | +---------+ | | |H(e)NB GW| | +----+ +--------+ Insecure link +----+ +---------+ | | UE | | H(e)NB |<==============>|SeGW| +----------+ | +----+ +--------+ +----+ |AAA Server| | | +----------+ | | +------+ | | |H(e)MS| | | +------+ | \------------------/ Figure 1: FAP Generic System Architecture with an example of 3GPP H(e)NB 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. 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. Zong Expires July 21, 2012 [Page 5] Internet-Draft cpext4femto January 2012 2. Terminology 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. FAP Femtocell Access Point, a FAP is typically designed in home or enterprise environment. Femto GW Femtocell Gateway, is the concentrate point of multiple FAPs. Femto Management Femto Management is the management system used to manage FAP. 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. H(e)NB Home (evolved) Node B, the FAP defined by 3GPP, supports 2nd or 3rd generation radio mode or LTE radio mode. It's called HNB when it supports 2nd or 3rd generation radio mode, and HeNB when it supports LTE radio mode. 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. 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. Zong Expires July 21, 2012 [Page 6] Internet-Draft cpext4femto January 2012 UE User equipment, it's a mobile terminal defined by 3GPP. 3. Problem Statement 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. 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. 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. 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. 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. 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. Zong Expires July 21, 2012 [Page 7] Internet-Draft cpext4femto January 2012 4. Proposed Solution - Extension to IKEv2 Configuration Payload 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. This solution requires minimum changes to the existing RFC 5996 [RFC5996] - 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. 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. 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. The major advantages of this proposal are as follows: o Simple extension to the existing IKEv2 RFC 5996 [RFC5996] * 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 o No impact to the existing security mechanisms for the end-to-end system and the existing protocols * FAP (i.e. IKE-initiator) has signaling path with operator's core network to pass the FAP information and the signature. * CP is part of the IKEv2 parameters which is generally supported by existing FAP-SeGW IPSec/IKEv2 authentication procedures. Zong Expires July 21, 2012 [Page 8] Internet-Draft cpext4femto January 2012 * 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. o Fully compatibility to the existing architecture and procedures * the new added code point has no impact to the IKEv2 Configuration Payload to continue the use of the existing IKEv2 security mechanism. The following 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. +-------+ +----------+ | IKE- | | IKE- | |Client | | Server | +-------+ +----------+ IKE-Initiator IKE-Responder (e.g FAP) (e.g SeGW) IKEv2 Message 1 ---------------------------> (HDR, SAi1, Kei, Ni) <--------------------------- IKEv2 Message 2 (HDR, SAr1, KEr, Nr, [CERTREQ]) IKEv2 Message 3 ---------------------------> (HDR, SK{IDi, [CERT], [CERTREQ][IDr]CP(CFG_REQUEST), SAi2, TSi, TSr}) : :..> CFG_REQUEST: Include Client notarized info => CLIENT_NOTARIZED_Info <--------------------------- IKEv2 Message 4 (HDR, SK{IDr, [CERT], Auth, CP(CFG_REPLY), SAr2, TSi, TSr}) : CFG_REPLY: If successful authentication <..: SERVER_NOTARIZED_SIGNATURE <= Figure 2: Example of the IKEv2 Configuration Payload solution to carry the SeGW Notarized Signature of the FAP information. The details of the proposed changes are described in the following section. Zong Expires July 21, 2012 [Page 9] Internet-Draft cpext4femto January 2012 4.1. Details of proposed changes to RFC 5996 for IKEv2 CP Two new code points for configuration attributes defined in section 3.15.1 of RFC 5996 [RFC5996] are defined as shown in the following table: +----------------------------+-------+--------------+-----------+ | Attribute Type | Value | Multi-Valued | Length | +----------------------------+-------+--------------+-----------+ | CLIENT_NOTARIZED_INFO | 16 | No | 0 or more | | SERVER_NOTARIZED_SIGNATURE | 17 | No | 0 or more | +----------------------------+-------+--------------+-----------+ CLIENT_NOTARIZED_INFO - 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 3rd party to verify the client's true identity and the information that is provided by the client. More details are described in 4.1.1. 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 4.1.2. 4.1.1. Configuration Payloads for CLIENT_NOTARIZED_INFO 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. A minimal exchange might look like this: CP(CFG_REQUEST) = CLIENT_NOTARIZED_INFO(xx....) 4.1.2. Configuration Payloads for SERVER_NOTARIZED_SIGNATURE 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. Zong Expires July 21, 2012 [Page 10] Internet-Draft cpext4femto January 2012 A minimal exchange might look like this: CP(CFG_REPLY) = SERVER_NOTARIZED_SIGNATURE(yy...) 5. IANA Considerations A new code point for IKEv2 Configuration Payload that indicates the new contents containing the SeGW notarized signature for the FAP information are required to be registered with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations The proposed solution is to add a new code point to the already defined IKEv2 Configuration Payload with no change to the existing IKEv2 security mechanism that has been used to protect the CP. 7. Conclusion This document explains the issues for the lack of the support in the mobile operator's core network to validate the FAP's identity and its corresponding FAP information. This document discusses the requirements and presents the justification of the proposed solution to resolve the issue as described above. The proposed solution requires only simple extension to the IKEv2 Configuration Payload as defined in RFC 5996 [RFC5996] to carry the SeGW's notarized signature of the FAP information inserted by the SeGW (i.e. IKE-responder) and to be feedback to the FAP (i.e. IKE-initiator). The proposed solution is fully backward compatible to the existing RFC, FAP system architecture, signaling procedures and existing SeGW's implementation. 8. Acknowledgements TBD. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Zong Expires July 21, 2012 [Page 11] Internet-Draft cpext4femto January 2012 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Author's Address Zaifeng Zong ZTE Corporation No 50, Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 P.R.China Email: zong.zaifeng@zte.com.cn Zong Expires July 21, 2012 [Page 12]