ETSI TS 133 320 V9.7.0 (2013-02)

Universal Mobile Telecommunications System (UMTS); LTE; Security of Home Node B (HNB) / Home evolved Node B (HeNB) (3GPP TS 33.320 version 9.7.0 Release 9)

RTS/TSGS-0333320v970

General Information

• Status: Published
• Publication Date: 31-Jan-2013
• Technical Committee: 3GPP SA 3 - Security
• Current Stage: 12 - Completion
• Completion Date: 01-Feb-2013

Standards Content (Sample)

Technical Specification
Universal Mobile Telecommunications System (UMTS);
LTE;
Security of Home Node B (HNB)
/ Home evolved Node B (HeNB)
(3GPP TS 33.320 version 9.7.0 Release 9)

3GPP TS 33.320 version 9.7.0 Release 9 1 ETSI TS 133 320 V9.7.0 (2013-02)

Reference
RTS/TSGS-0333320v970
Keywords
LTE,SECURITY,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2013.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 2 ETSI TS 133 320 V9.7.0 (2013-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 3 ETSI TS 133 320 V9.7.0 (2013-02)
Contents
Intellectual Property Rights . 2
Foreword . 2
Foreword . 5
1 Scope . 6
2 References . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Overview of Security Architecture and Requirements . 8
4.1 System architecture of H(e)NB . 8
4.2 Network Elements . 9
4.2.1 H(e)NB . 9
4.2.2 Security Gateway (SeGW) . 9
4.2.3 H(e)NB Management System (H(e)MS) . 9
4.2.4 UE . 9
4.2.5 H(e)NB Gateway (H(e)NB-GW) and MME . 9
4.2.6 AAA Server and HSS . 10
4.2.7 Void . 10
4.3 Interfaces (Reference Points) . 10
4.3.1 Backhaul Link . 10
4.3.2 H(e)MS Interface . 10
4.3.3 Interface between SeGW and AAA Server, AAA Server and HSS . 10
4.4 Security Requirements and Principles . 10
4.4.1 Operation . 10
4.4.2 Requirements on H(e)NB . 10
4.4.3 Requirements on SeGW . 11
4.4.4 Requirements on H(e)MS . 11
4.4.5 Requirements on Backhaul Link . 12
4.4.6 Requirements on H(e)MS Link . 12
5 Security Features . 13
5.1 Secure Storage and Execution . 13
5.1.1 Hosting Party Module . 13
5.1.2 Trusted Environment (TrE). 13
5.1.2.1 General . 13
5.2 Device Mutual Authentication . 13
5.3 Hosting Party Mutual Authentication . 14
5.4 Other security features . 14
6 Security Procedures in H(e)NB . 15
6.1 Device Integrity Check . 15
6.1.1 Device Integrity Check Procedure . 15
6.1.2 Protection of Trusted Reference Value(s) . 15
6.2 Void . 15
6.3 Measures for Clock Protection . 15
6.3.1 Clock Synchronization Security Mechanisms for H(e)NB . 15
7 Security Procedures between H(e)NB and SeGW . 16
7.1 Device Validation . 16
7.2 Device Authentication . 16
7.2.1 General . 16
7.2.2 SeGW and Device Mutual Authentication Procedure. 16
7.2.3 H(e)NB/IKEv2 Processing Requirements for SeGW Certificates . 18
7.2.4 SeGW/IKEv2 Processing Requirements for H(e)NB Certificates . 18
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 4 ETSI TS 133 320 V9.7.0 (2013-02)
7.2.5 Security Profiles . 18
7.2.5.1 Profile for IKEv2 . 18
7.2.5.2 IKEv2 Certificate Profile . 19
7.2.5.2.1 IKEv2 Entity Certificates . 19
7.2.5.2.2 IKEv2 CA Certificates . 19
7.3 Hosting Party Authentication . 19
7.4 IPsec Tunnel Establishment . 20
7.5 Device Authorization . 20
8 Security Aspects of H(e)NB Management . 21
8.1 Location Verification . 21
8.1.1 General . 21
8.1.2 IP Address provided by H(e)NB . 21
8.1.3 IP Address and/or access line location identifier provided by broadband access provider . 21
8.1.4 Surrounding macro-cell information provided by H(e)NB . 21
8.1.5 GNSS information provided by H(e)NB . 21
8.1.6 Requirements . 22
8.2 Access Control Mechanisms for H(e)NB . 22
8.2.1 Non-CSG Method . 22
8.2.2 CSG Method . 22
8.3 Protection of H(e)MS traffic between H(e)MS and H(e)NB . 22
8.3.1 Connection to H(e)MS accessible on MNO Intranet . 22
8.3.2 Connection to H(e)MS accessible on public Internet . 23
8.3.2.1 General . 23
8.3.2.2 Device Validation . 23
8.3.3 TLS certificate profile . 24
8.3.3.1 TLS entity certificates . 24
8.3.3.2 TLS CA certificates. 24
8.3.4 TR-069 protocol profile . 24
8.4 Protection of SW Download . 25
9 Security Aspects of Emergency Call Handling . 25
10 Security Aspects for Mobility . 27
10.1 Inbound mobility . 27
10.2 Outbound mobility . 27
Annex A (informative): Authentication Call-flows . 28
A.1 Device Authentication Call-flow Example . 28
A.2 Combined Device and HP Authentication Call-flow Example . 29
Annex B (informative): Location Verification Examples . 32
B.1 Example of Location verification based on IP address and line identifier in NASS . 32
B.2 Example process of location verification when the verifying node receive different types of
location information . 32
Annex C: Change history . 34
History . 35

ETSI
3GPP TS 33.320 version 9.7.0 Release 9 5 ETSI TS 133 320 V9.7.0 (2013-02)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 6 ETSI TS 133 320 V9.7.0 (2013-02)
1 Scope
This document specifies the security architecture for the H(e)NB subsystem. This includes security requirements on
Home Node Bs, Home eNode Bs, and other H(e)NB-associated network nodes (e.g. SeGW and H(e)MS), as well as the
procedures and features which are provided to meet those requirements.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM
document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the
present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 32.583: "Telecommunications management; Home Node B (HNB) Operations,
Administration, Maintenance and Provisioning (OAM&P); Procedure flows for Type 1 interface
HNB to HNB Management System (HMS) ".
[3] IETF RFC 4187: "Extensible Authentication Protocol Method for 3rd Generation Authentication
and Key Agreement (EAP-AKA) ".
[4] IETF RFC 4306: "Internet Key Exchange (IKEv2) Protocol".
[5] Void.
[6] IETF RFC 4739: "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2
Protocol', Nov 2006".
[7] 3GPP TS 33.310: "Network Domain Security (NDS); Authentication Framework (AF) ".
[8] 3GPP TS 23.003: "Numbering, addressing and identification".
[9] 3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security".
[10] 3GPP TS 33.234: "3G security; Wireless Local Area Network (WLAN) interworking security".
[11] 3GPP TS 32.593: "Telecommunication management; Procedure flows for Type 1 interface
H(e)NB to H(e)NB Management System (H(e)MS) ".
[12] 3GPP TS 25.467: "UTRAN architecture for 3G Home Node B (HNB); Stage 2".
[13] - [14] Void.
[15] The Broadband Forum TR-069: "CPE WAN Management Protocol v1.1", Issue 1 Amendment 2,
December 2007.
[16] IETF RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".
[17] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
[18] ETSI ES 282 004 (V1.1.1): "Telecommunications and Internet Converged Services and Protocols
for Advanced Networking (TISPAN); NGN functional architecture; Network Attachment Sub-
System (NASS) ", 2006.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 7 ETSI TS 133 320 V9.7.0 (2013-02)
[19] ETSI ES 283 035 (V1.1.1): "Telecommunications and Internet Converged Services and Protocols
for Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e2 interface
based on the DIAMETER protocol", 2006.
[20] 3GPP TS 33.102: "3G security; Security architecture".
[21] 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE): Security architecture".
[22] IETF RFC 2560: "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol –
OCSP"
[23] Open Mobile Alliance OMA-WAP-OCSP V1.0: "Online Certificate Status Protocol Mobile
Profile". URL: http://www.openmobilealliance.org/
[24] IETF RFC 4806: "Online Certificate Status Protocol (OCSP) Extensions to IKEv2".
[25] IETF RFC 4366: "Transport Layer Security (TLS) Extensions".
[26] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
[27] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".[28] 3GPP TS
25.367: "Mobility procedures for Home Node B (HNB); Overall description; Stage 2".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
CSG: A closed subscriber group identifies subscribers of an operator who are permitted to access one or more cells of
the PLMN of but having restricted access ('CSG cells')
Hosting party: The party hosting the H(e)NB and having a contract with the PLMN operator.
Security Gateway: Element at the edge of the core network terminating security association(s) for the backhaul link
between H(e)NB and core network.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
AAA Authentication, Authorization, and Accounting
ACL Access Control List
ACS Auto-Configuration Server
AKA Authentication and Key Agreement
CA Certification Authority
CPE Customer Premises Equipment
CRL Certificate Revocation List
CSG Closed Subscriber Group
DNS Domain Name System
DPD Dead Peer Detection
eNB Evolved Node-B
EAP Extensible Authentication Protocol
ESP Encapsulating Security Payload
E-UTRAN Evolved UTRAN
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 8 ETSI TS 133 320 V9.7.0 (2013-02)
FQDN Fully Qualified Domain Name
GNSS Global Navigation Satellite System
H(e)NB Home NodeB or Home eNodeB
H(e)NB-GW Home (e)NodeB Gateway
H(e)MS Home NodeB Management or Home eNodeB Management System
HeMS Home eNodeB Management System
HeNB Home eNodeB
HMS Home NodeB Management System
HNB Home NodeB
HP Hosting Party
HPM HP Module
HW Hardware
IKE Internet Key Exchange
IMSI International Mobile Subscriber Identity
LTE Long Term Evolution
MME Mobility Management Entity
MSK Master Session Key
NAPT Network Address Port Translation
NAT Network Address Translation
NAT-T NAT-Traversal
OCSP Online Certificate Status Protocol
PKI Public Key Infrastructure
SA Security Association
SeGW Security Gateway
TLS Transport Layer Security
TrE Trusted Environment
UDP User Datagram Protocol
UICC Universal Integrated Circuit Card
URI Uniform Resource Identifier
URL Uniform Resource Locator
USIM Universal Subscriber Identity Module
UMTS Universal Mobile Telecommunications System
UTRAN Universal Terrestrial Radio Access Network
WAP Wireless Application Protocol

4 Overview of Security Architecture and Requirements
4.1 System architecture of H(e)NB
Operator’s core
AAA
network Server/HSS
UE H(e)NB insecure link SeGW
H(e)NB-GW
H(e)MS
H(e)MS
Figure 4.1.1: System Architecture of H(e)NB
Description system architecture:
- Air interface between UE and H(e)NB should be backwards compatible air interface in UTRAN or E-UTRAN;
- H(e)NB access operator"s core network via a Security Gateway. The backhaul between H(e)NB and SeGW may
be insecure.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 9 ETSI TS 133 320 V9.7.0 (2013-02)
- Security Gateway represent operator"s core network to perform mutual authentication with H(e)NB.
- AAA server authenticates the hosting party based on the authentication information retrieved from HSS when
hosting party authentication is performed.
- Security tunnel is established between H(e)NB and Security Gateway to protect information transmitted in
backhaul link.
- HNB-GW performs the mandatory access control and HNB performs the optional access control in case non-
CSG capable UEs or non-CSG capable HNBs. SeGW and HNB-GW are logically separate entities within
operator"s network. If the SeGW and the HNB-GW are not integrated, then the interface between the HNB-GW
and the SeGW may be protected using NDS/IP [9].
- HeNB-GW is optional to deploy. If HeNB-GW is deployed, then SeGW may be integrated into HeNB-GW. If
the SeGW and the HeNB-GW are not integrated, then the interface between the HeNB-GW and the SeGW may
be protected using NDS/IP [9].
- HMS [2] and/or HNB-GW [12] performs location verification of HNB.
- HeMS [11] performs location verification of HeNB.
- Secure communication is required to H(e)NB Management System (H(e)MS).
4.2 Network Elements
4.2.1 H(e)NB
The H(e)NB is a network element that connects User Equipment via its radio interface to the operator"s core network.
The backhaul link to the operator"s core network is a broadband connection. A H(e)NB is typically deployed in
customers" premises.
NOTE: The term H(e)NB refers to both Home NodeB (HNB) and Home eNodeB (HeNB), when both are meant
without distinction.
4.2.2 Security Gateway (SeGW)
The SeGW is a network element at the border of the operator"s core network. After successful mutual authentication
between the H(e)NB and the SeGW, the SeGW connects the H(e)NB to the operator"s core network. Any connection
between the H(e)NB and the core network is tunnelled through the SeGW.
4.2.3 H(e)NB Management System (H(e)MS)
The H(e)MS is a management server that configures the H(e)NB according to the operator"s policy. H(e)MS is also
capable of installing software updates on the H(e)NB. The H(e)MS server may be located inside the operator"s core
network (accessible on the MNO Intranet) or outside of it (accessible on the public Internet).
The HMS is specified in TS 32.583 [2].
The HeMS is specified in TS 32.593 [11].
4.2.4 UE
UE is a standard user equipment for UMTS (for HNB) or LTE (for HeNB).
4.2.5 H(e)NB Gateway (H(e)NB-GW) and MME
HNB-GW is specified in TS 25.467 [12] and HeNB-GW is specified in TS 36.300 [27]. The H(e)NB-GW and the
SeGW may be co-located. The HeNB-GW is optional, while the HNB-GW is mandatory. In the absence of a HeNB-
GW, the HeNB is directly connected to the MME via the SeGW.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 10 ETSI TS 133 320 V9.7.0 (2013-02)
4.2.6 AAA Server and HSS
HSS stores the subscription data and authentication information of the H(e)NBs. When hosting party authentication is
required, AAA server authenticates the hosting party based on the authentication information retrieved from HSS.
4.2.7 Void
4.3 Interfaces (Reference Points)
4.3.1 Backhaul Link
The backhaul link used between H(e)NB and SeGW provides a secure tunnel carrying both the user plane data and the
control plane data that are transmitted between the H(e)NB and network elements in the core network.
H(e)MS traffic is also tunnelled through this secure backhaul link, if the H(e)MS is accessible on the MNO Intranet.
The backhaul link may also carry other data between H(e)NB and core network, e.g. time protocol traffic.
4.3.2 H(e)MS Interface
The H(e)MS Interface between the H(e)NB and the H(e)MS server shall provide a secure connection carrying
configuration data., SW updates and additional data, e.g. location information.
4.3.3 Interface between SeGW and AAA Server, AAA Server and HSS
The interface between the SeGW and AAA Server provides a secure connection carrying authentication, authorization,
and related information.
The interface between AAA Server and HSS provides a secure connection for the retrieval of authentication vectors
(e.g. for hosting party authentication) and retrieval of H(e)NB access-related information for HPM.
4.4 Security Requirements and Principles
4.4.1 Operation
The requirements on operation are:
- Only algorithms of adequate cryptographic strength shall be used for authentication and protection of
confidentiality and integrity.
- Modifications of Hosting Party controlled information by the operator shall only be allowed with the permission
of the Hosting Party.
- The extent of Hosting Party controllable information shall be controlled by the operator.
- IMSIs of UEs connected to H(e)NB shall not be revealed to the Hosting Party of the H(e)NB.
4.4.2 Requirements on H(e)NB
The requirements on the H(e)NB are:
- The integrity of the H(e)NB shall be validated before any connection into the core network is established.
- The H(e)NB shall be authenticated by the SeGW based on a globally unique and permanent H(e)NB identity.
- The H(e)NB shall authenticate the SeGW.
- Optionally the hosting party of the H(e)NB may be authenticated.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 11 ETSI TS 133 320 V9.7.0 (2013-02)
- If hosting party authentication is used, the H(e)NB shall shut down its air interface and disconnect from the
operator"s core network on removal of the HPM which was used for authentication towards the MNO.
- The H(e)NB shall authenticate the H(e)MS, if the H(e)MS is accessed on the public Internet.
- The H(e)NB shall be authenticated by the H(e)MS using the same identity as for authentication to the SeGW, if
the H(e)MS is accessed on the public Internet.
- The configuration and the software of the H(e)NB shall only be updated in a secure way, i.e. the integrity of the
configuration data including the licensed radio parameters and the integrity of the software updates must be
verified.
- Sensitive data including cryptographic keys, authentication credentials, user information, user plane data and
control plane data shall not be accessible at the H(e)NB in plaintext to unauthorized access.
- The time base of the H(e)NB shall be synchronized to the core network.
- The location of the H(e)NB shall be reliably transferred to the network.
- The H(e)NB shall be capable of filtering unauthenticated traffic received from the access network. Operator
policy shall control which types of unauthenticated traffic are filtered.
- The H(e)NB shall implement a mechanism to shut down the air interface within a certain time period after the
connection between H(e)NB and the rest of the operator network went out of service. This time period and the
usage of the mechanism shall be configurable by the operator.
- The H(e)NB shall only activate its air interface after successful establishment of the backhaul link (cf. sub-clause
4.4.5 of the present document). The establishment of the backhaul link happens as a result of successful integrity
validation, device mutual authentication between H(e)NB and SeGW, and optional hosting party authentication.
- All security requirements of the eNB secure environment of TS 33.401 [21] clause 5.3 shall apply to the HeNB.
Security measures to establish this secure environment shall be assured by the TrE (subclause 5.1.2) where they
fall under the capability of the TrE.
4.4.3 Requirements on SeGW
The requirements on the SeGW are:
- The SeGW shall be authenticated by the H(e)NB using a SeGW certificate. The SeGW certificate shall be signed
by a CA trusted by the operator.
- The SeGW shall authenticate the H(e)NB based on H(e)NB certificate.
- The SeGW may authenticate the hosting party of the H(e)NB in cooperation with the AAA server using EAP-
AKA [3].
- The SeGW shall allow the H(e)NB access to the core network only after successful completion of all required
authentications.
- Any unauthenticated traffic from the H(e)NB shall be filtered out at the SeGW.
4.4.4 Requirements on H(e)MS
The requirements on the H(e)MS are:
- The H(e)MS shall be authenticated by the H(e)NB if the H(e)MS is accessible on the public Internet and may be
authenticated by H(e)NB if the H(e)MS is accessible on the MNO Intranet using a H(e)MS certificate. The
H(e)MS certificate shall be provided by a MNO trusted CA.
- The H(e)MS shall authenticate the identity of the H(e)NB if the H(e)MS is accessible on the public Internet and
may authenticate the identity of the H(e)NB if the H(e)MS is accessible on the MNO Intranet, using a H(e)NB
certificate. This identity shall be the same as used during backhaul link establishment (cf. sub-clause 4.4.5 of this
document).
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 12 ETSI TS 133 320 V9.7.0 (2013-02)
- The H(e)MS may securely configure the H(e)NB according to the operator"s policy, whether or not to use IPsec
for subsequent connections (cf. clause 4.4.5 of the present document).
- If the H(e)MS is accessible on the MNO Intranet and the mutual authentication between H(e)MS and H(e)NB is
not performed the identity of H(e)NB has to be transferred over the H(e)MS link.
NOTE 1: In case of H(e)MS accessible on the MNO intranet there may be an additional secure end-to-end tunnel
between H(e)NB and H(e)MS carried inside the secure backhaul link.
NOTE 2: Mutual authentication between H(e)MS and H(e)NB may not be necessary if the H(e)NB is connected to
the H(e)MS through the core network and mutual authentication between H(e)NB and SeGW has taken
place.
4.4.5 Requirements on Backhaul Link
The requirements on the backhaul link are:
- The establishment of the secure backhaul link shall be based on IKEv2 [4] comprising the required
authentications as given in subclauses 4.4.2 and 4.4.3 of this document.
- The backhaul link shall provide integrity, confidentiality and replay protection of the transmitted data.
- IPsec use for the backhaul link is mandatory to implement but optional to use based on an operator policy. To
allow for such operator policy, the H(e)NB may be configurable to IPsec or non-IPsec usage option. If this
configuration is supported, the default configuration set in the factory shall be the usage of IPsec. Based on
operator policy, the H(e)MS may securely configure the H(e)NB, whether or not to use IPsec for subsequent
connections. If the operator chooses not to use IPsec, mutual authentication between the H(e)NB device and the
SeGW shall be performed and the interface between the H(e)NB and SeGW shall be secured with a mechanism
that provides layer 2 security for confidentiality and integrity protection of communications. This mechanism
then shall also bind this secure communications to device authentication and optional HPM authentication.
- The security solution for the backhaul link shall be based on IPsec ESP tunnel mode [9]. If the H(e)NB is
configurable not to use IPsec, in addition a suitable layer 2 protection mechanism shall be mandatory to support.
If the H(e)NB is configured not to use IPsec, this layer 2 mechanism shall be used for the backhaul link
protection.
NOTE: For the non-IPsec usage option the details of the authentication mechanism, the layer 2 security
mechanism and the binding are out of scope of the present document.
- Any connection between the H(e)NB and the core network shall be tunnelled through the Backhaul Link.
- The security solution for the backhaul link shall be compatible with common network address and port
translation variations and support firewall traversal.
4.4.6 Requirements on H(e)MS Link
The requirements on the H(e)MS link are:
- The establishment of the secure H(e)MS link shall be based on the authentication principles as given in
subclauses 4.4.2 and 4.4.4 of this document.
- The H(e)MS link shall provide integrity, confidentiality and replay protection of the transmitted data data
between H(e)MS and H(e)NB.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 13 ETSI TS 133 320 V9.7.0 (2013-02)
5 Security Features
5.1 Secure Storage and Execution
5.1.1 Hosting Party Module
The Hosting Party authentication shall be based on a Hosting Party Module. The Hosting Party Module (HPM) is a
physical entity distinct from the H(e)NB physical equipment, dedicated to the identification and authentication of the
Hosting Party towards the MNO. The HPM shall have the following features:
- The HPM shall be a tamper resistant environment and shall contain the credentials used to authenticate the
Hosting Party.
- The HPM shall be bound to the Hosting Party (e.g. by contractual agreement between Hosting Party and MNO)
and supplied by the MNO to the Hosting Party.
- The HPM shall be removable from the H(e)NB and it shall be possible for a Hosting Party to change the
H(e)NB device by inserting the HPM in the new H(e)NB.
The HPM is provided by means of a UICC.
5.1.2 Trusted Environment (TrE)
5.1.2.1 General
The Trusted Environment (TrE) shall be a logical entity which provides a trustworthy environment for the execution of
sensitive functions and the storage of sensitive data.
All data produced through execution of functions within the TrE shall be unknowable to unauthorized external entities.
The TrE shall be built from an irremovable, HW-based root of trust by way of a secure boot process, which shall occur
whenever a H(e)NB is turned on or goes through a hard reset. The root of trust shall be physically bound to the H(e)NB.
The secure boot process shall include checks of the integrity of the TrE performed by the root of trust. Only
successfully verified components shall be loaded or started. The TrE , after having been successfully started, shall
proceed to verify other components of the H(e)NB (e.g. operating system and further programs) that are necessary for
trusted operation of the H(e)NB.
The TrE shall perform sensitive functions (such as storing private keys and providing cryptographic calculations using
those private keys) needed to perform H(e)NB device integrity check (cf. clause 6.1) and device validation as
specifically described in clauses 7.1 and 8.3.2.2.
The TrE shall perform sensitive functions (such as storing private keys and providing cryptographic calculations using
those private keys ) needed for H(e)NB device authentication with the operator network, as specifically described in
clauses 7.2 and 8.3.
5.2 Device Mutual Authentication
The device mutual authentication is mandatory for H(e)NB.
Device mutual authentication shall be performed using certificates. The H(e)NB"s credentials and critical security
functions for device authentication shall be protected inside a TrE.
The device mutual authentication shall be securely bound to device integrity validation. This procedure, when
successful, leads to mutual authentication between the H(e)NB and the SeGW.
The certificate-based device authentication shall have the following parts:
- The H(e)NB shall be provisioned with a device certificate. This device certificate allows the authentication of the
H(e)NB by the SeGW (and thus the operator network). The device certificate shall be provided by a CA trusted
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 14 ETSI TS 133 320 V9.7.0 (2013-02)
by the operator, e.g. the CA of the operator, the manufacturer or the vendor of the H(e)NB, or by another party
trusted by the operator.
- The SeGW shall be configured with a certificate. This certificate allows the authentication of the SeGW by
H(e)NB. The certificate shall be provided by an operator trusted CA.
- A Fully Qualified Domain Name (FQDN) formatted identifier shall be used for certificate based authentication
of the H(e)NB and of the SeGW. For the H(e)NB this FQDN shall be globally unique. If no DNS is available for
resolution of the FQDN of the SeGW, then the IP address of SeGW shall be used as identifier.
- The H(e)NB may check the revocation status of certificates using OCSP.
- The SeGW may check the revocation status of certificates using CRLs or OCSP.
5.3 Hosting Party Mutual Authentication
The hosting party mutual authentication is optionally performed by the operator"s network following successful device
mutual authentication.
An EAP-AKA based method [3] shall be used for hosting party authentication. When Hosting Party Authentication is
used, both device and hosting party authentication must be completed successfully before a secure tunnel to the operator
network can be established.
The authentication of the hosting party is based on credentials contained in a separate Hosting Party Module (HPM) in
H(e)NB, and in the MNO HLR/HSS.
The EAP-AKA based hosting party authentication shall have the following parts:
- An AKA credential shall be stored in HPM enabling to use EAP-AKA. The SeGW is acting as EAP
authenticator and forwards the EAP protocol messages to the AAA server to retrieve an authentication vector
from AuC via HSS/HLR.
- A globally unique identifier in the format of an IMSI shall be used for EAP-AKA based authentication. These
IMSIs shall be marked in HLR/HSS as used for H(e)NBs, e.g. by allocating dedicated ranges or by adding
specific attributes to avoid misuse of these IMSIs for ordinary UEs.
NOTE: The implementation of the related HLR/HSS entry is out of scope of this document.
5.4 Other security features
The communication between time server and H(e)NB shall be provided with adequate protection.
Access control shall be performed in the HNB-GW and optionally in HNB in case of non-CSG capable UEs or non-
CSG capable HNBs.
In case of CSG capable UEs and CSG capable HNBs, the SGSN/MSC/VLR shall perform access control for UE for
accessing HNB, as described in [12].
MME shall perform access control for UEs accessing HeNB.as described in [27]
The HMS and/or HNB-GW shall perform HNB location verification. The HeMS shall perform HeNB location
verification.
NOTE: Location verification is needed to satisfy various security, regulatory and operational requirements of
operators.
ETSI
3GPP TS 33.320 version 9.7.0 Release 9 15 ETSI T
...