Internet DRAFT - draft-zong-ipsecme-ikev2-cpext4femto
draft-zong-ipsecme-ikev2-cpext4femto
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]
