LTE Security Guide

Alcatel-Lucent

End-To-End

E2E LTE Solutions

LTE Security Guide

MARCH 2010

V0.1

E N D - T O - E N D L T E S O L U T I O N S

Security LTE Guide

Alcatel-Lucent Proprietary 2010 All Rights Reserved 2

CONTENTS

1. INTRODUCTION ................................................................................................ 3

1.1 PURPOSE ...................................................................................................... 3 1.2 REFERENCED DOCUMENTS ...................................................................................... 3

2. LTE SECURITY OVERVIEW .................................................................................... 4

3. STANDARDS ..................................................................................................... 5

4. LTE SECURITY ANALYSIS ..................................................................................... 6

4.1 LTE SOLUTION X.805 ANALYSIS ............................................................................... 6 4.1.1 Security requirements for CRITICAL risks mitigation ......................................... 6 4.1.2 Security requirements for CRITICAL risks mitigation ......................................... 7

4.2 LTE SOLUTION SECURITY ENABLERS ............................................................................ 9 4.3 MAPPING OF MITIGATION REQUIREMENTS TO THE SECURITY ENABLERS ...........................................10

5. SECURITY ENABLERS ........................................................................................ 13

5.1 SECURED HOSTING PLATFORM .................................................................................13 5.1.1 Universal Threat Management ..................................................................13 5.1.2 Alcatel-Lucent Solution ..........................................................................16

5.2 SECURED PRESENTATION ......................................................................................17 5.2.1 Layer 1 - Security between the UE and the eNB .............................................17 5.2.2 Layer 2 - Security between the eNB and EPC for S1 and eNB and eNB for X2 ............23

5.3 SECURED PEERING ............................................................................................29 5.3.1 Diameter exchanges (S6a & S9 interfaces) ....................................................29 5.3.2 Home-routed traffic (S8 interface) ............................................................29 5.3.3 Alcatel-Lucent Solution ..........................................................................30

5.4 SECURITY MEDIATION .........................................................................................32 5.4.1 OAM&P Security Principles ......................................................................32 5.4.2 OAM&P Interface Security .......................................................................34 5.4.3 System and Configuration Security .............................................................41 5.4.4 Security Logs and Alarms ........................................................................43

5.5 SECURITY ASSURANCE .........................................................................................45 5.5.1 Alcatel-Lucent Solution ..........................................................................46

6. SECURITY ARCHITECTURE ................................................................................. 47

6.1 ARCHITECTURE GUIDELINE ....................................................................................47 6.2 NE AND EMS MAPPING........................................................................................47

7. LTE E2E SECURITY FEATURES LIST ....................................................................... 50

Security LTE Guide


1. INTRODUCTION

1.1 Purpose

This document provides a guide to the associated standards and associated security

capabilities in the E2E LTE Solution. The goal is to provide the reader with

information on why the security enabler is needed, mappings of the security

enabler to Alcatel-Lucent products, and reference to documents/features that

implement the enabler.

The security guide is meant to be high level, and can be used for RFx responses and

well as providing a view of what is supported. References are provided if more

information is required.

1.2 Referenced documents

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

Security LTE Guide


2. LTE SECURITY OVERVIEW

LTE is gaining momentum to be the key standard for deploying NGN wireless

telecommunications services that provides end-users with unrivalled mobile

broadband access. 3GPP has specified flat IP-based network architecture with the

aim to efficiently support massive usage of IP services. As a consequence, the

network architecture is much simpler compared with existing architectures like

3G. Inter-working between CDMA and LTE-SAE has also been standardized to enable

evolution to LTE.

Being all-IP, the EPC is susceptible to all kind of security attacks just like any

traditional IP network; the LTE reliance on IP-based network and open standards

greatly changes the threat profile of telecommunication services delivery. EPC

gear needs to support a large number of IPSec terminations for securing data and

control plane communications. In addition, the EPC needs to be protected from

Distributed Denial of Service (DDoS) attacks and thus comprehensive Intrusion

Prevention and Detection Systems (IPS/IDS) need to be deployed.

Operators are aware of these challenges and expect assurance from their suppliers

that their investments will be protected. Security capabilities need to be based on

well defined methodologies. It also needs to be flexible to take account of the

different needs of deployments.

Several considerations are needed to provide security for the LTE solution. One

important consideration is to determine the standards relevant to the solution. LTE

is evolving and thus, the security standards for LTE are also evolving. Another

consideration is methodical hardening of the network elements within the solution

since one weak link can cause a breach of security of the whole solution. From an

end-to-end perspective, it is important to perform a X.805 analysis of the LTE

solution. The X.805 analysis analyzes all the threats and risks in the solution. With

the analysis, security transformation enablers can used to mitigate threats and

risks.

Security LTE Guide


3. STANDARDS

Depending on the deployment of the solution, the relevant 3GPP specifications are

security are as follows:

Security aspects of 3GPP based accesses to the EPS are covered by 33.401.

Network Domain Security and Network Domain Authentication are covered

by 33.210 and 33.310 respectively.

Security aspects of non-3GPP based accesses to the EPS are covered by

33.402.

Home eNodeB security aspects are covered in 33.320. (Future roadmap)

General details of 3GPP security are covered in 33.102.

Rationale of the Security Decisions for LTE is covered in 33.821.

Rationale of the Security Decisions for Home eNodeB is covered in 33.820.

(Future roadmap)

Moreover, it is important to adhere to other standards for a complete solution.

Therefore, the following management plane security specifications should be also

considered:

ATIS-0300276.2008 Operations, Administration, Maintenance and

Provisioning Security Requirements for the Public Telecommunications

Network: A Baseline of Security Requirements for the Management Plane

ITU-T M.3016.0-4 Security for the Management Plane

Additional details on the management plane specifications are described here.

[Add link]

Also, the security recommendations from the NGMN as well as the other general

International and National security specifications should be applied in accordance

to the requirements of the solution deployment.

Security LTE Guide


4. LTE SECURITY ANALYSIS

This section references some of the work produced by the SGCC Solution team.

Specifically, an analysis of the LTE solution is performed using the X.805

Methodology. Five security enablers are defined to mitigate the critical and major

risks. The 5 security enablers are the foundation of the security architecture

described in the subsequent sections of this document.

4.1 LTE Solution X.805 Analysis

The following risk analysis has been performed for the LTE end to end solution

using the X.805 methodology.

https://all1.na.alcatel-

lucent.com/teams/E2E4GSolnArchTeam/Shared%20Documents/Security/LTE%20-

%20Risk%20analysis%20-%20v0C.zip

This produced the following critical and major risks mitigation requirements.

4.1.1 Security requirements for CRITICAL risks mitigation

The table below lists the requirements for critical risks mitigation.

Num Security requirement

CRI-1 The LTE nodes exposed to UE must be protected against network-

based (Distributed) Denial of Services attacks.

CRI-2 LTE nodes must authenticate and control access to all

management interfaces and functionalities.

CRI-3

LTE EPC nodes exposed to end-user must be placed in a secured

DMZ (when possible) with restricted access from UE and

from/towards other EPC components. Access to those nodes must

be authenticated and authorized. Connectivity to external

networks and OAM network must be limited as well.

Monitoring should also be used for detection of intrusions.

CRI-4

LTE nodes network accesses must be restricted to limit access

from and to relevant interfaces, including within the EPC network.

This shall limit attack opportunities for DoS, masquerading,

unauthorized access and modification on LTE nodes.

CRI-5 Strong network segregation between EPC and external IS must be

enforced.

Security LTE Guide



CRI-6 LTE nodes must rely on sound back-up and recovery mechanisms to

cope with disasters incurring data loss.

CRI-7

LTE platform must provide strong separation between

management/control and end-user plane across the network. This

separation may rely on physical and/or logical mechanisms and

encompass a security device (i.e. a firewall).

CRI-8

LTE platform must ensure the UE access are properly

authenticated before interaction with the LTE services and

applications.

CRI-9 LTE platform must ensure appropriate protection for user traffic

PDUs on EPS bearer.

CRI-10

LTE platform must ensure appropriate protection for user profile

information that can be stored on HSS (i.e. user profile) or

elsewhere.

CRI-11

Interconnection of LTE platform with external domain outside of

the operator control (i.e. 3rd party PDN, peering partner) shall put

in place mechanisms to deter possible attacks from these domain

(IPS, proxies to break sessions) and log activity on the

interconnection points.

CRI-12

LTE platform must provide mechanisms to ensure messages

integrity and confidentiality for communication between UE and

LTE components exposed to UE. The integrity/confidentiality

properties of the underlying network may be leveraged when

appropriate (i.e. in 3G/LTE network).

4.1.2 Security requirements for CRITICAL risks mitigation

The table below lists the requirements for major risks mitigation.


MAJ-1 LTE nodes must perform encryption on management interfaces.

MAJ-2

LTE platform must generate activity logs for events on functional

components exposed to UE to monitor activity. These logs must be

actively monitored to detect attacks attempts.

MAJ-3

LTE nodes must generate logs for administrative events and provide

capabilities for efficient log collection and verification. These logs

must be actively monitored to detect attacks attempts.

Security LTE Guide



MAJ-4

LTE platform must rely on authentication mechanisms that provide

guarantee to the UE that it interacts with a legitimate UE-facing

components (MME/HSS) mutual authentication.

To prevent rogue and masquerading nodes accessing the control

plane data, authentication must be used and where possible

monitoring should be used for detection of these situations.

MAJ-5

LTE platform must be securely connected to providers core network

to mitigate risks of masquerading and eavesdropping on charging

interface. This connectivity must be restricted to the required sub-

system(s) and the underlying interfaces strongly authenticated and

encrypted.

MAJ-6

LTE platform must be securely connected to peering operators to

mitigate risks of masquerading and eavesdropping over shared

interfaces in roaming scenarios. This connectivity must be restricted

to the required sub-system(s) and the underlying interfaces strongly

authenticated and encrypted.

MAJ-7

LTE platform must provide a way to revoke credential in a timely

fashion in case of credential theft (this would usually be provided

through provisioning capabilities on the HSS).

MAJ-8

LTE platform must provide mechanisms to ensure messages integrity

and confidentiality for communication between UE and LTE

components in home-routed roaming scenarios. The

integrity/confidentiality properties of the underlying network may

be leveraged when appropriate.

Security LTE Guide


4.2 LTE Solution Security Enablers

From the X.805 analysis, the threats and risks to the LTE solution can be qualified.

Appropriate security enablers can be used to mitigate the risks and threats. The

following security transformation enablers are used for the LTE solution.

1

Secured hosting platform: provides a secured architectural platform

to implement defense-in-depth for enhanced protection of the LTE

network assets (including E-UTRAN eNodeBs, EPC and application

components). This requirement mandates the need to provide

additional protection for security-sensitive assets (i.e. HSS database

and LI components).

2

Secured presentation for EPC: provides an architectural framework to

limit exposure of the LTE infrastructure to external threat agents (i.e.

UE and PDNs such as Internet).

3

Secured peering: provides protection of IP peering interactions with

relevant IP peering partners (in case of various roaming scenarios). Up

to a certain extent, peering partners may be considered as external

threat agents.

4

Security mediation: includes the required element managers to

support the above-mentioned security building blocks and provide an

integration point to the Security Assurance capabilities introduced

below.

5

Security assurance: provides an OSS-level capacity that supports the

need to monitor security-relevant activity on the LTE platform through

log collection, aggregation and correlation from the various LTE

network elements and security building blocks mentioned above.

An overview of the five enablers is provided in section 4 of the following

document.

https://all1.na.alcatel-

lucent.com/teams/E2E4GSolnArchTeam/Shared%20Documents/Security/LTE%20-

%20Solution%20description%20-%20v0B.zip

Subsequent sections in this document will provide more details on the enablers,

and in particular what Alcatel-Lucent products are used for each of the enablers.

Security LTE Guide


4.3 Mapping of Mitigation Requirements to the Security Enablers

The following table shows the mapping of the risks to the security enablers.

Risk ID Security requirement Mitigated by

enablers

CRI-1

The LTE nodes exposed to UE must be

protected against network-based (Distributed)

Denial of Services attacks.

Secured

presentation

CRI-2

LTE nodes must authenticate and control

access to all management interfaces and

functionalities.

(depends on

capabilities)

Secured hosting

platform

CRI-3

LTE EPC nodes exposed to end-user must be

placed in a secured DMZ (when possible) with

restricted access from UE and from/towards

other EPC components. Access to those nodes

must be authenticated and authorized.

Connectivity to external networks and OAM

network must be limited as well.

Monitoring should also be used for detection of

intrusions.

Secured

presentation,

Secured mediation,

Security assurance

(auth. depends on

capabilities of LTE

nodes)

CRI-4

LTE nodes network accesses must be restricted

to limit access from and to relevant interfaces,

including within the EPC network. This shall

limit attack opportunities for DoS,

masquerading, unauthorized access and

modification on LTE nodes.

Secured hosting

platform

CRI-5 Strong network segregation between EPC and

external IS must be enforced.

Secured hosting

platform

CRI-6

LTE nodes must rely on sound back-up and

recovery mechanisms to cope with disasters

incurring data loss.

(general best

practices)

CRI-7

LTE platform must provide strong separation

between management/control and end-user

plane across the network. This separation may

rely on physical and/or logical mechanisms and

encompass a security device (i.e. a firewall).

Secured hosting

platform

Security LTE Guide



enablers

CRI-8

LTE platform must ensure the UE access are

properly authenticated before interaction with

the LTE services and applications.

Secured

presentation

CRI-9 LTE platform must ensure appropriate

protection for user traffic PDUs on EPS bearer.

Secured

presentation

CRI-10

LTE platform must ensure appropriate

protection for user profile information that can

be stored on HSS (i.e. user profile) or

elsewhere.

Secured hosting

platform

Secured

presentation

CRI-11

Interconnection of LTE platform with external

domain outside of the operator control (i.e. 3rd

party PDN, peering partner) shall put in place

mechanisms to deter possible attacks from

these domain (IPS, proxies to break sessions)

and log activity on the interconnection points.

Secured peering,

Security mediation,

Security assurance

CRI-12

LTE platform must provide mechanisms to

ensure messages integrity and confidentiality

for communication between UE and LTE

components exposed to UE. The

integrity/confidentiality properties of the

underlying network may be leveraged when

appropriate (i.e. in 3G/LTE network).

Secured

presentation


enablers

MAJ-1 LTE nodes must perform encryption on

management interfaces.

(general best

practices, but

mostly depends on

nodes capabilities)

MAJ-2

LTE platform must generate activity logs for

events on functional components exposed to UE

to monitor activity. These logs must be actively

monitored to detect attacks attempts.

Secured mediation

Security assurance

MAJ-3

LTE nodes must generate logs for administrative

events and provide capabilities for efficient log

collection and verification. These logs must be

actively monitored to detect attacks attempts.

Secured mediation

Security assurance

Security LTE Guide



enablers

MAJ-4

LTE platform must rely on authentication

mechanisms that provide guarantee to the UE

that it interacts with a legitimate UE-facing

components (MME/HSS) mutual

authentication.

To prevent rogue and masquerading nodes

accessing the control plane data, authentication

must be used and where possible monitoring

should be used for detection of these situations.

Secured

presentation

Secured mediation

Security assurance

MAJ-5

LTE platform must be securely connected to

providers core network to mitigate risks of

masquerading and eavesdropping on charging

interface. This connectivity must be restricted

to the required sub-system(s) and the underlying

interfaces strongly authenticated and

encrypted.

Secured hosting

platform

MAJ-6

LTE platform must be securely connected to

peering operators to mitigate risks of

masquerading and eavesdropping over shared

interfaces in roaming scenarios. This

connectivity must be restricted to the required

sub-system(s) and the underlying interfaces

strongly authenticated and encrypted.

Secured peering

MAJ-7

LTE platform must provide a way to revoke

credential in a timely fashion in case of

credential theft (this would usually be provided

through provisioning capabilities on the HSS).

(provided by OSS)

MAJ-8

LTE platform must provide mechanisms to

ensure messages integrity and confidentiality for

communication between UE and LTE

components in home-routed roaming scenarios.

The integrity/confidentiality properties of the

underlying network may be leveraged when

appropriate.

Secured Peering

Security LTE Guide


5. SECURITY ENABLERS

As mentioned in the previous section, five security enablers are used for the LTE

solution. These are:

1. Secured Hosting Platform

2. Secured Presentation

3. Secured Peering

4. Security Mediation

5. Security Assurance

5.1 Secured Hosting Platform

Secured Hosting Platform provides a secured platform to implement defense-in-

depth protection of the LTE network assets (including E-UTRAN eNodeBs, EPC and

application components).

5.1.1 Universal Threat Management

Beside the specific security requirement of the customer, the following key

principles should be followed:

Reduce the attack surface: the SAE architecture minimizes its points of

exposure to external networks. Only a very limited subset of the

infrastructure is provided with a public IP address.

Implement the defense-in-depth principle: Best common practices in

term of multi-tiers domains implementation have to be followed. For

instance, through the definition of security domains (or tiers).

Apply due care to protect sensitive information: The SAE infrastructure

may host information whose disclosure may affect subscribers privacy.

These components are best located in a dedicated data tier appropriately

protected.

Clear segregation of security planes: relevant nodes must use dedicated

network interfaces (either physical or logical) to ensure that different

network planes are used for management, signaling, media and access

connectivity. This separation at the node level must be maintained at the L2

and L3 level.

Security LTE Guide


It is crucial to allow communication between network components that require it,

but it is also important to deny communications between components that have no

such requirements. Perimeter firewalls are used to maintain a level of segregation

between networks while permitting the requisite level of connectivity.

The problem, however, is that many exploits attempt to take advantage of

weaknesses in the very protocols that are allowed through perimeter firewalls:

once a network component has been compromised, this can often be used as a

springboard to launch additional attacks on other internal components.

The inadequacies inherent in current defenses have driven the development of a

new breed of security products known as Intrusion Detection & Prevention

systems. IDS/IPS are used as detective and reactive defense mechanisms for both

network and application targeted attacks. Those systems work at the network layer

by listening to network traffic destined to protected systems for attacks against

vulnerable services, data manipulation attacks on applications, privilege escalation

on hosts, multiple failed unauthorized logins, and even access to sensitive data.

This is extremely important in locations where an attack can lead to anything from

a service outage to the actual loss of data.

The management network, for instance, is often the most trusted location in a

network: it has privileged access to both network event data and configurations on

network devices. If an attacker can find a way into the management network,

serious harm could be done. Deploying an IDS/IPS system inside the management

network might be appropriate in an effort to find network attacks, to analyze and

correlate these anomalies, and to react as needed.

The traditional perimeter firewall is still necessary, but is no longer enough. The

next step is to integrate the firewall capability with the IDS/IPS in order to extend

the firewall protection inside the perimeter and harden the core of the network.

The Secured Hosting Platform is built on top of a carrier-grade Unified Threat

Management (UTM) appliance. As such, the following UTM features may be

leveraged to enhance the overall protection level of the LTE infrastructure:

Basic UTM services:

o Firewalling, to filter interactions among network domains and

support the defense-in-depth strategy;

o IDS/IPS, to further reduce exposure of the SAE architecture,

especially when interconnected to non-trusted/external network;

o VPN (IPSec or SSL), when secured communication links with

appropriate 3rd party or providers IS domains are required;

o Anti-Virus, that can prove useful e.g. on the management plane when

a remote 3rd party access is involved for maintenance purposes.

Security LTE Guide


o Virtual Domains: Definition of virtualized UTM instances (a.k.a.

virtual domains, or VDOMs) for each security plane (user, control and

management), in order to ensure a strong segregation between planes

and simplify routing and UTM configuration for plane-specific virtual

domains;

o Virtual Interfaces: Creation of virtual interfaces within each virtual

domain, for enhanced flexibility in network deployments and

evolutions.

Advanced features:

o Definition of virtualized UTM instances (a.k.a. virtual domains, or

VDOMs) for each security plane (user, control and management), in

order to ensure a strong segregation between planes and simplify

routing and UTM configuration for plane-specific virtual domains;

o Creation of virtual interfaces within each virtual domain, for

enhanced flexibility in network deployments and evolutions.

The following figure illustrates the principles depicted by the proposed solution:

UTM appliance

E2E user traffic (data)

Med. E2E (data)

User-plane virtual UTM

Pres. Ctrl (SIG)

Core Ctrl (SIG)

Med. Ctrl (SIG)

Data Ctrl (SIG)Control virtual UTM

Data Mgmt (OAM)

Core Mgmt (OAM)

Med. Mgmt (OAM)

Pres. Mgmt (OAM)

Management virtual UTM

EPC and PDNs 3rd parties / Providers CN

LEA network(CALEA)

LTE

roaming peer

B/OSS domain;

Providers CN

Figure 1 Traffic and plane segregations with UTM and virtual domains

Security LTE Guide


5.1.2 Alcatel-Lucent Solution

Alcatel-Lucent provides two options for the UTM:

ALVI Brick

Fortinet

Details of the Brick Solution are described here.

[Add link]

Details of the Fortinet Solution are described here.

[Add link]

Security LTE Guide


5.2 Secured Presentation

Secured Presentation of the EPC provides an architectural framework to limit

exposure of the LTE infrastructure to external threat agents (i.e. UE and PDNs such

as Internet).

The design of LTE terminates the user-plane security at the eNodeB. Therefore,

the overall architecture includes two security levels (a.k.a. domains): the first

protects interfaces between the end-users handset and eNodeBs, while the second

protects X2 (connecting eNodeBs with each other) and S1 (between eNodeBs and

the EPC) internal interfaces, as shown Erreur ! Source du renvoi introuvable.:

Figure 2 LTE security layers

Security of the first layer is provided as per 33.401 specifications. Security of the

second layer is provided using IPSEC to a security gateway. IPsec requirements are

defined as per 33.210.

5.2.1 Layer 1 - Security between the UE and the eNB

This section summarizes the security capabilities that are between the UE and the

eNB. In general, 3GPP TS 33.401 shall be used for reference.

In this section, Authentication and Key Agreement algorithm is discussed briefly.

Signaling Protection between the UE and the EPC are applied to the Non-Access

Stratum (NAS) which is Integrity and Confidentiality protected, and Radio Resource

Control (RRC) which is Integrity and Confidentiality Protected. The User Plane (Uu)

Security LTE Guide


is Encryption protected. No Integrity protection is provided on the Uu for

performance reasons.

5.2.1.1 User Identity Confidentiality

During network access, the serving MME allocates a Globally Unique Temporary

Identity (GUTI) to the UE which is used to avoid frequent exchange of the UEs IMSI

over the radio access.

5.2.1.2 User Device Confidentiality

The International Mobile Equipment Identity (IMEI) is sent upon request from the

network using confidentiality protected NAS procedures. The IMEI can be checked

with the EIR to check if the User Device is stolen or not. (To be checked when this

will be supported on MME).

5.2.1.3 Authentication and Key Agreement

SGi

S12

S3

S1-MME

PCRF

Gx

S6a

HSS

Operator's IP Services

(e.g. IMS, PSS etc.)

Rx

S10

UE

SGSN

LTE-Uu

E-UTRAN

MME

S11

S5 Serving Gateway

PDN Gateway

S1-U

S4

UTRAN

GERAN

The EPS Authentication and Key Agreement (AKA) procedure is used to provide

mutual authentication between the user and the network, and agreement on

the Key Access Security Management Entity (KASME). The KASME is used to create

the NAS encryption and integrity keys, UP encryption key, RRC encryption and

integrity keys. The HSS generates authentication and provides it to the MME.

MME and UE use the challenge-response authentication and key agreement

procedures to derive the keys.

Security LTE Guide


SGi

S12

S3

S1-MME

PCRF

Gx

S6a

HSS



Rx

S10

UE

SGSN

LTE-Uu

E-UTRAN

MME

S11

S5 Serving Gateway

PDN Gateway

S1-U

S4

UTRAN

GERAN

NAS enc, int

RRC - enc, int,

S1-MME

The RRC signaling is between the UE and eNB. Encryption and Integrity

protection is provided using the RRCenc and RRCint keys generated from the

UMTS AKA procedure above.

The NAS signaling is between the UE and the MME. Encryption and Integrity

protection is provided using the NASenc and NASint keys generated from the

UMTS AKA procedure.

The S1-MME interface is protected using the Network Domain Security function

which is not UE specific. (See IPsec section)

SGi

S12

S3

S1-MME

PCRF

Gx

S6a

HSS



Rx

S10

UE

SGSN

LTE-Uu

E-UTRAN

MME

S11

S5 Serving Gateway

PDN Gateway

S1-U

S4

UTRAN

GERAN

S1-U

Uu enc

The Uu user plane is protected using the UPenc key generated from the UMTS

AKA procedure.

The S1-U interface is protected using the Network Domain Security function

which is not UE specific. (See IPsec section)

Security LTE Guide


5.2.1.4 Key Hierarchy

The key hierarchy is shown below.

USIM / AuC

UE / MME

KASME

K

KUPenc

KeNB / NH

KNASint

UE / HSS

UE / eNB

KNASenc

CK, IK

KRRCint KRRCenc

An EPS security context is created after the UMTS AKA procedure and is

identified by the evolved Key Set Identifier (eKSI) of Type KSIASME. An EPS

context consists of both AS and NAS components.

The ciphering keys and integrity keys are dependent on the algorithms in use.

Two sets of algorithms are supported:

Encryption key algorithms - 128-EEA1 (SNOW 3G) and 128-EEA2 (AES)

Integrity key algorithms 128-EIA1 (SNOW 3G) and 128-EIA2 (AES)

5.2.1.5 Key Handling in Handovers

Handovers are possible directly between eNBs for performance reasons. The

KeNB (initial) is derived by the MME and sent to the serving eNB as the UE

transits from ECM-IDLE to ECM-CONNECTED. KeNB (initial) has a Next Hop

Chaining Counter (NCC) of 0. During an intra- or inter-eNB (S1 or X2) handover,

the source eNB derives the KeNB* which is sent to the target eNB to derive the

KeNB that becomes the base key for derivations. The KeNB* is derived from the

Security LTE Guide


PCI of the target cell and the current KeNB or NH parameter. Horizontal key

derivation is defined using the KeNB moving across the chain model. Veritical

key derivation is defined using the NH parameter, moving down the chain.

For inter-eNB Handovers, vertical key derivation is used when source eNB holds

a {NCC, NH} pair with the NCC larger than the current KeNB. Otherwise,

horizontal key derivation is used. For intra-eNB handovers, the source eNB has a

choice of either derivation algorithms.

KASME

NH

NHKeNB*

(KeNB)

Initial

NAS uplink COUNT

NCC = 1

NCC = 2

NCC = 0KeNB KeNB KeNB

PCI,

EARFCN-DL

KeNB* KeNB*

KeNB KeNB KeNBKeNB* KeNB*

PCI,

EARFCN-DL

PCI,

EARFCN-DL

PCI,

EARFCN-DL

PCI,

EARFCN-DL

NHKeNB*

NCC = 3KeNB KeNB KeNBKeNB* KeNB*

PCI,

EARFCN-DL

PCI,

EARFCN-DL

PCI,

EARFCN-DL

5.2.1.6 Key Change

Dynamic key changing can be the result of explicit (re-keying) or implicit (key

refresh) procedures.

Re-keying of AS occurs when the AS EPS security context to be activated differs

from the currently AS active context. Similarly, re-keying of NAS occurs when

the NAS EPS security context to be activated differs from the currently active

NAS security context.

Key-Refresh occurs for the AS occurs when the eNB detects that the PDCP

COUNT values are about to wrap around. Similarly, key-refresh of NAS occurs

when the MME detects that the NAS COUNT values are about to wrap around.

Security LTE Guide


5.2.1.7 Interworking with GERAN/UTRAN

A UE may be registered in both SGSN and MME simultaneously e.g. When

moving from one system (source) to the other (target) both:

Native Content (Keys created earlier in the target system); and

Mapped Content (Keys converted from source system)

Idle Mode Transition

From E-UTRAN to UTRAN: either mapped or native keys are used depending

on the identity used in Routing Area Request as per section 9.1.1.of 3GPP

33.401.

From UTRAN to E-UTRAN: native keys are used with exception as per 9.1.2

of 3GPP 33.401.

Handover

From E-UTRAN to UTRAN: mapped keys are used as per 9.2.1 of 3GPP

33.401.

From UTRAN to E-UTRAN: mapped keys are used (but possible to activate

native key using key-change procedure) as per 9.2.2 of 3GPP 33.401

5.2.1.8 Alcatel-Lucent Solution

The eNB and MME supports security between the UE and the EPS based on the

following features:

L92638: Ciphering and Integrity Protection

m10607-02: MME for NAS Integrity

m10607-01: MME for NAS Ciphering

Security LTE Guide


5.2.2 Layer 2 - Security between the eNB and EPC for S1 and eNB

and eNB for X2

5.2.2.1 IPsec Solution for LTE

3GPP has defined NDS/IP for LTE to cover the protection of IP-based control-plane

signaling and user-plane data for the EPC and the E-UTRAN, as defined in 33.401.

This standardizes the use of IPSec ESP in accordance with RFC 4303, using Internet

Key Exchange version 2 (with IKEv1 being optional) and with certificate-based

authentication (or pre-shared secrets) for both S1-MME and S1-U interfaces as well

as the X2 inter-eNB traffic.

The use of IPSec in tunnel mode allows the architecture to be realized using a

separate SEG used to protect the S1 interface, which leads to the segmentation of

the all-IP RAN network into the RAN access domain (which may well be untrusted)

and the RAN aggregation domain (which represents the trusted part of the RAN

transport network). As mobile operators may not control or own the access

network, the SEG provides them a secure entry point into their core network for

monitoring and managing traffic.

5.2.2.2 Alcatel-Lucent Solution

The following features are applicable for IPsec security for the Alcatel-Lucent

solution:

L92078 IPSEC IKEv2 (eNB)

L101808 Security Support of IPsec enhancement above Ipv4 and Ipv6

(eNB)

L101812 IPSEC with Certificates (Future) (eNB)

TBD IPSEC on the PGW/7750SR+ISA

M10600-1 IPsec support for connections between MME and SEG for S1

(Future)

5.2.2.2.1 LTE eNB LA2.0 (Ref L92078)

LA2.0 introduces IPsec in the eNB. For LA2.0, the eNB can support one IPsec tunnel

with the Security Gateway (SEG) with a hub and spoke architecture. The IPSEC

tunnel is optional, and is used for the encryption and integrity protection of the X2

and S1 (Telecom) traffic. OAM traffic (SNMP, SSH, FTP, NTP) are not protected in

Security LTE Guide


LA2.0. There are two VLAN possibilities in LA2.0 no VLAN tagging, VLAN for OAM

and Telecom traffic. In LA2.0, IPSEC is only applicable when VLAN is used. i.e. No

IPSEC in case of no VLAN tagging. As mentioned earlier, there is only one IPSEC

tunnel either for the OAM traffic VLAN or the Telecom traffic VLAN.

Note: Due to the hub and spoke architecture, X2 traffic needs to be sent to from

the originating eNB the SEG and then from the SEG to the terminating eNB.

In LA2.0, only IKEv2 ESP Tunnel mode (as per RFC4306) with pre-shared keys is

supported using the IP address of the eNB for IKEv2 peer identity. Only IPv4 is

supported for IPSEC.

The following encryption and integrity protection algorithms are supported.

1. 3DES CBC for encryption (recommended by RFC 4835)

2. AES CBC 128 for encryption 128 bits and 256 bits keys (RFC 3602 and required by RFC 4835)

3. HMAC-SHA1-96 for integrity protection and authentication

IKEV2 uses the HMAC-SHA1 pseudo random function. Perfect Forward Secrecy (PFS) is

optional.

Support of Diffie-Hellman exchange group 2 with 1024 bit MODP (RFC 2409, RFC 4307 and

RFC 3526) is used for:

1. IKE_SA security association

2. CHILD_SA when PFS is enabled

The ESP protocol in the eNB supports the following encryption ciphers as referenced in RFC

4835:

1. NULL (required by RFC 4835)

2. 3DES CBC (recommended by RFC 4835)

3. AES-CBC 128 bits key length (required by RFC 4835)

4. AES-CBC 256 bits key length (not required by RFC 4835)

The ESP protocol in the eNB shall support the following authentication ciphers as referenced

in RFC 4385:

1. NULL (recommended by RFC 4835)

2. HMAC-MD5-96 (optional by RFC 4835)

3. HMAC-SHA-1-96 (required by RFC 4835)

4. AES-XCBC-MAC-96 (RFC 3566 and RFC 3664)

In LA2.0, in terms of failover, the eNB supports only one IPsec tunnel per eNB (e.g. no

redundant IPsec tunnel) between the eNB and the SEG. The eNB tests the aliveness of the

IKE connection periodically using keep-alive message that contains no payload between the

Security LTE Guide


IKEv2 peers. If the IKE connection fails, the eNB retries to initiate IKEv2 with the SEG

periodically with a period that is provisioned. The solution relies on the SEG to provide

resiliency.

5.2.2.2.2 LTE eNB LA3.0 (Ref L101808)

LA3.0 enhances IPsec IKEv2 with ESP in the eNB to support IPv6 and IPv4. It is still

based on the spoke and hub architecture for the following traffic types: OAM, S1-C,

S1-U, X2-C, X2-U.

Note: The 1588 traffic type is not IPSEC protected in this release.

Note: Due to the hub and spoke architecture, X2 traffic needs to be sent to from

the originating eNB the SEG and then from the SEG to the terminating eNB.

In LA3.0, the eNB can support multiple IPsec tunnels over several VLANS based on the

following rules:

1. Each VLAN supports zero or one IPsec tunnel. One IPsec tunnel is configured if at least one traffic type in the VLAN uses IPsec. If there is no VLAN supported in the

eNB, then the same rule used for a single tagged VLAN applies: support zero or one

IPsec tunnel per eNB.

2. All traffic types mapped to an IPsec tunnel must be assigned to the same VLAN.

3. All the eNB inner IP addresses mapped to a given eNB outer IP address must be assigned to the same VLAN.

4. OAM traffic types appear only once per eNB. Telecom traffic types (S1-C, S1-U, X2-C and X2-U) appear once on per eNB per operator.

5. The IKEv2 authentication method (pre-shared secret key or X.509 digital certificates) is common to all the IPsec tunnels in a given eNB.

6. Support specific IPsec policies for specific combinations of traffic types (the IPsec policies are: No IPsec, integrity protection only, and integrity protection and

encryption). Depending on the VLAN support, the following policies are used:

a. Different policies for Control (S1-C, X2-C), User (S1-U, X2-U), OAM traffic

b. Different Policies for Telecom and OAM traffic

c. No IPSEC for 1588.

In terms of failover, the eNB supports only one IPsec tunnel per eNB VLAN (e.g. no

redundant IPsec tunnel). The eNB tests the aliveness of the IKE connection

periodically using keep-alive message that contains no payload between the IKEv2

peers. If the IKE connection fails, the eNB retries to initiate IKEv2 with the SEG

periodically with a period that is provisioned.

Security LTE Guide


5.2.2.2.3 7750SR with IPsec-ISA R7.0 (Ref 7750SR Boiler Plate R7.0)

The 7750 Service Router (SR) IPsec-Integrated Service Adapter (IPsec-ISA) provides

comprehensive network-integrated Layer 3 IPsec virtual private network (VPN)

deployment options, such as Remote Access Concentrator (RAC), site-to-site and

network-to-network encrypted IPsec security.

ISA-IPsec offers the following IPsec capabilities:

Up to four (4) active/standby IPsec ISA groups are supported in a single

chassis (eight total IPsec ISAs)

Each IPsec ISA or active/standby ISA group supports up to 16K tunnels

Support for dynamic LAN-to-LAN tunnels

Support for Soft Clients using X-Auth

Encryption algorithms: DES, 3DES, AES-128, AES-192 & AES-256

Authentication/Hashing Algorithms: HMAC-MD5, HMAC-SHA1

Key Distribution: IKEv1, perfect forward secrecy (PFS) support

IPSec Modes: ESP+Auth Tunnel Mode

Auth Modes: Shared Secret

IP Versions: v4

Services:

Terminate SAP tunnels into an IP-VPN (through IES or VPRN

Services)

Support L3 forwarding down an interface tied to an IPSec tunnel.

5.2.2.2.4 7750SR with IPsec-ISA R8.0

The 7750SR with IPsec-ISA is enhanced to support IKEv2. In SR7.0, only IKEv1 is supported. Support of IPv6 is a TBD item.

5.2.2.2.5 Alcatel-Lucent Brick (Ref Brick Boiler Plate)

The Alcatel Lucent Brick product can support IPSEC for both LAN-LAN VPN as well as

Client-LAN VPNs.

Security LTE Guide


The following encryption methods are available:

Diffie-Hellman Group 1






The following key negotiation methods are supported:

Internet Key Exchange Version 1 (IKEv1)

Internet Key Exchange Version 2 (IKEv2)


DES

3DES

AES (CBC-128, CBC-192, CBC-256)


SHA-1

MD5

AES-XCBC-MAC (for client tunnel endpoints only)

The following authentication methods are available:

X.509 compatible certificates

PKCS #12 Certificate Import

SecurID (Client-to-LAN only)

RADIUS (Client-to-LAN only)

Locally managed shared secrets

Pre-shared keys

The Brick SEG performs traffic selection based on source and destination IP

address, as well as protocol type (TCP/UDP/SCTP) and TCP/UDP port #.

Brick device failover and state sharing is accomplished by installing two Brick

devices, each connected to the same sets of networks on both sides. The Brick

devices are bootstrapped identically, even down to the IP addresses and VLANs.

One Brick device then elects to be the Active device, and one becomes the

Standby device.

The Active Brick device processes all packets through each interface. The Standby

Brick does not process any packets, but does maintain communications with the

Active Brick device.

Security LTE Guide


When health check information ceases to be heard by the Standby Brick, or when

health check information indicates that the Active is less healthy than the Standby

(determined by the number of physical interfaces up and available), the Standby

Brick transitions to the Active state. Failover detection and full activation occurs

in about 400 milliseconds, preserving all session state information on the previously

Active Brick device.

The Active Brick device also exchanges state information with the Standby Brick

device. State information is sent from the active to the standby in real-time.

Active/Standby Brick pairs share IP addresses and virtual MAC addresses. When

failover occurs, the now-Active Brick will transmit short non-IP frames for each of

its virtual MAC addresses, so connected switching elements will update their

MAC/interface binding.

From the perspective of the eNB, the failover mechanism of the Brick is completely

transparent.

Security LTE Guide


5.3 Secured Peering

Secured peering provides protection of IP peering interactions with relevant IP

peering partners (in case of various roaming scenarios).

3GPP EPC allows roaming interfaces for exchanging of operators policies (S9

interface between V-PCRF and H-PCRF), authentication exchanges (S6a interface

of HSS), routing user-plane traffic to the HPLMN (S8 interface), or routing the user-

plane traffic to the VPLMN for accessing local services or the Internet (SGi).

5.3.1 Diameter exchanges (S6a & S9 interfaces)

Diameter interfaces exposed to roaming scenarios should be proxied to protect the

backend network against various kinds of attacks that could affect their operation.

Diameters proxy agents are used to forward Diameter traffic to another Diameter

peer in order to handle the request. Proxy agents may modify packets and may

originate rejection messages in case of policy violation, for example, in case of

receiving requests from unknown PLMNs.

The Base Diameter protocol (RFC 3588) does not provide end-to-end security. For

ensuring security between two Diameter peers or hop-by-hop, the Diameter

protocol can run over IPSec or TLS.

5.3.2 Home-routed traffic (S8 interface)

Protection of the user-plane traffic (S8) has different considerations. The firewall

function needs to consider the lack of security inherent in GTP. Specific security

countermeasures to implement should include:

Ingress and egress packet filtering: this will help prevent the PLMN from

being used as source to attack other roaming partners.

Stateful GTP packet filtering: only allow the traffic required and only from

the sources and destinations of roaming partners. This will prevent other

PLMNs from initiating many kinds of attacks. It will also prevent PDN-GW

from having to process traffic from PLMNs that are not roaming partners as

well as illegal or malformed traffic.

GTP traffic shaping: in order to prevent DoS attacks directed against

PDN-GW and shared resources of bandwidth from being consumed by an

attacker or a subscriber, GTP rate-limiting should be implemented.

IPSec tunnels between roaming partners: due to the fact that GTP-U and

the embedded user-plane PDUs are not encrypted, an attacker who has

access to the S8 path (such as a malicious employee or hacker) who has

compromised access to the GRX (GPRS Roaming eXchange) can potentially

capture a subscribers data session. IPSec tunnels can be used as a

countermeasure to such threats.

Security LTE Guide



A mutualized solution that covers both roaming scenarios is shown in the diagram

au-dessous:

LTE EPC

S6a

S11

S7/Gx

MME

S5S-GW

HPLMN VPLMN

S9

S6a

PDNGW

PCRF

Diameter

proxy agent

HSS

S-GW

MME

PCRF

S8

Carrier-grade GTP firewall (S8):

Protocol anomaly

detection and prevention

Sanity checking

Stateful inspection

Etc.

HSS/PCRF Diameter

interfaces protection

Policy enforcement

LTE EPC

S11

S7/Gx

VPLMN

HPLMN

S5S-GWPDNGW

S6a S9

PCRFHSS

PCRFMME

Local breakout

LTE EPC

S6a

S11

S7/Gx

HSS

PCRF

MME

VPLMN HPLMN

S8 PDNGW

S-GW

Home-routed traffic

Legend

Monitoring points

UTM appliance

Figure 3 Secured roaming configuration

Stateful firewalling (to protect interfaces involved in all roaming scenarios) and

GTP packet inspection are devoted to a Brick or Fortinet UTM appliance, whereas

the proxying of Diameter S6a and S9 messages can be either dedicated to:

A front-end version of the 8650 SDM component explicitly configured as a

proxy agent

8950AAA acting as a proxy agent.

When necessary, the UTM appliance can also be used as a termination point for

IPSec tunnels between roaming partners to avoid any confidentiality and

authentication issues

Details of the features

Security LTE Guide


8650 SDM - It is TBD for LE3.0 if the 8650 SDM can be support of the AAA

functionality.

8950 AAA - It is TBD for 8950AAA to be used as a proxy for the E2E LTE solution.

Security LTE Guide


5.4 Security Mediation

The Security Mediation security enabler includes a set of capabilities that may be

added on the LTE OAM zone to enhance security manageability of the platform.

5.4.1 OAM&P Security Principles

The six principles for OAM&P security as defined by T1.276 are:

1. Secure management traffic with strong encryption and authentication.

2. Authenticate and attribute all management actions.

3. Manage security resources and configurations with integrity.

4. Maintain logs for all of the above.

5. Support least privilege.

6. Support security alarms.

The principles are applicable from a LTE solutions perspective. It is necessary to

ensure secure management traffic from the EMS to the NE and vice versa. The

management actions performed by the element management system must be

authenticated for both user and system transactions. Configuration of the

resources must be managed with integrity. Security logs provide repudiation

assurance. The concept of least privilege is applicable for user authentication for

users accessing the EMS and NE. Lastly, alarms are important to inform operators

of incidents.

According to TMN FCAPS model, Security management ensures network reliability

and integrity. This is achieved by separating the roles and responsibilities of users

and administrators, logging their actions, and providing data privacies. The

following activities are essential for security management:

Selective Resource Access

Network Element Function enablement and control

Access Logs

Security Alarms/Event Reporting

Data Privacy

User Rights Checking

Security Breaches and Attempts management

Security LTE Guide


Security Audit Trail Log

These six OAM&P security principles from T1.276 and the TMN FCAPS security items

can be broadly consolidated into the following areas of discussions:

Security of the OAM&P Interfaces

o This area covers ensures that the management traffic is secure with

strong encryption and authentication. The concepts of data privacy,

resource access are ensured.

Configuration and System Security

o This area covers the authentication, and attribution of management

actions, management of security resources and the support of least

privileged through user rights checking. Another area is security

hardening of the LTE products to ensure that they are protected

against various intrusion attacks e.g. DoS etc.

Security Logs and Alarms

o This area covers the security alarms and logs associated with the

solution. Security breach management can be handled accordingly.

Security LTE Guide


5.4.2 OAM&P Interface Security

One key aspect of OAM&P security is the security of the interfaces used by the

management plane. With the different protocols used for OAM (Fault Management,

Configuration Management etc), it is important to define the security requirements

for these interfaces since different protocols have different security capabilities.

This section describes the protocols used in the LTE solution, and provides some

recommendations on the security capabilities required to provide secure

communication for OAM.

5.4.2.1 Protocols Used for OAM in the LTE Solution

A high level view of the different OAM protocols used is highlighted below:

JMS or EJB This Java based protocol is used for GUI client connections to

EMSs.

HTTPS, HTTP Used for XML communication to the OSS.

SSH, Telnet Used for connection to the NEs for configuration (e.g. Via

NETCONF) or provisioning (CLI).

SNMPv3 (v1, v2) Used for commissioning, fault management and

configuration management.

sFTP, FTP Used for file transfers from the NE to the EMS.

RADIUS Used for Accounting and Authentication.

CORBA Used as NBI to the OSS.

XML Used as NBI to the OSS.

Note: Telnet, rlogin, rcp, ftp protocols are not recommended to be used since

these provide the password in cleartext.

Security LTE Guide


A high level summary is shown below:

Note: This is a generic view. The architectures for the EMSs used in the LTE

solutions are shown below.

Security LTE Guide


5.4.2.2 9354 XMS Element Management System Interfaces (LE2.0)

The 9354 XMS is used to provision the 9412 and 9226 eNBs in the Alcatel-Lucent LTE

solution.

Both XML and CORBA are used for North Bound Interfaces to the OSS. For security,

these protocols are protected with SSL. [Ref XMS-CPO].

For communication from the eNB towards the XMS, sFTP is supported for file

transfers. Also, SNMPv3 is used for fault management.

For communication from the XMS to the eNB, SNMPv3 is used for fault management

and performance management etc. NETCONF/SSH is used for configuration

management.

Local client access (via the Network Element Manager) to the eNB is managed using

the CLI over the SSH protocol. Commissioning is done using SNMP v3.

Remote client access to the eNB via the XMS is done using a Windows based

protocol.

As an added security in case the backhaul is insecure, the OAM traffic from the eNB

to the IPSEC Security Gateway can be protected using an IPSEC tunnel.

A diagram of the protocols is shown below:

Security LTE Guide


5.4.2.2.1 Enhancements identified for OAM with XMS and ENB

The current offering, as of LA2.0 does not provide server authentication for SSH.

Without server authentication, the SSH client may unintentionally pass their

credential information to an imposter. Moreover, the user information may be

eavesdropped. Also, the SNMPv3 implementation on the eNB does not use

encryption. Since the same user name is used for SSH and SNMPv3, the eNB can be

accessed by a third party eavesdropping the username from the SSH access, and

then using the user information to commissioning the eNB. [Ref 101810 OAM

chalktalk]

Enhancements to the protocols are planned in the LA4.0 release to remove these

limitations.

5.4.2.3 5620 SAM Element Management System Interfaces

The 5620 SAM is used to manage the 9471 MME, 5780 DSC, 7750 PGW/SGW as well

as the 7705 SAR, 7750 SR products in the Alcatel-Lucent LTE solution.

Note: The 5620 SAM will also manage the 9412 and 9926 eNBs in LE3.0.

Network communication between the 5620 SAM server and clients is carried out

using XML/SOAP, EJB, or JMS messages.

The OSS clients have two options for message security. When HTTPS is used

to transport XML/SOAP messages, messages are protected by SSL

functionality.

The Java GUI clients use the EJB interface, which is protected by an SSL

connection.

Both OSS and GUI clients use JMS, which is protected by SSL.

In a redundant configuration, the secondary 5620 SAM server acts as a client of the

primary server. This is protected by SSL.

SSH and SNMPv3 are supported between the 5620 SAM and network elements.

SNMPv3 supports USM and VACM.

RADIUS is also supported as an option to connect to an external AAA for

authentication.

Certain network elements support GUI based access using secure HTTP.

Additionally, SSL can be used to provide further security.

Security LTE Guide


A diagram of the protocols is shown below:

Note: Certain NEs do not support some of the protocols above.

Security LTE Guide


5.4.2.4 Recommendations for Security of the OAM Protocols

The following are recommendations for Security of the OAM Interfaces used in LTE.

SNMPv3 should be used instead of v1, v2. Also, SNMPv3 USM (RFC2274) and VACM

(RFC2275) should be used to provide security of the SNMP interface. USM (User

Security Model) can be used to encrypt the SNMPv3 PDU and authenticate the users

involved. VACM (View-Based Access Control) is used to provide access control at

the PDU level to determine whether access to a managed object in a local MIB by a

remote party should be allowed.

SSH should be used instead of Telnet, Rlogin. SSH server should be authenticated

using RFC4253. The SSH user should be authenticated using RFC4252.

SSLv3/TLS security protocol should be used to provide data encryption, server

authentication, message integrity, and optional client authentication for a TCP/IP

connection at the transport layer (layer 4). SSL/TLS can be used to protect HTTP,

LDAP TCP/IP based protocols.

An AAA can be used to simplify the management of authenticating users. If Radius

is used, at least CHAP is used for the authentication protocol. EAP should also be

supported.

PKI (Public Key Infrastructure) and x.509 Certificates should also be used to

simplify key management by removing the need to maintain shared secrets

between nodes.

Security LTE Guide


5.4.2.5 Alcatel-Lucent LTE products Security of OAM&P Interfaces

The following table describes the secured OAM&P interfaces for each of the LTE

products.

Network

Element

Security of OAM&P Interfaces

5620 SAM SNMPv3 & SNMPv2c for NE PM and FM, SCP for file transfer,

SSHv2 for User Access, HTTPS over SLS/TLS, Java over SLS/TLS

for client access.

9354 XMS HTTPS over SLS/TLS for XML, sFTP for file transfer, SSH (No

Server Auth) for NETCONF and user access, SNMPv3 (No

encryption) for PM and FM

9412 eNodeB HTTPS over SLS/TLS for XML, sFTP for file transfer, SSH (No

Server Auth) for NETCONF and user access, SNMPv3 (No

encryption) for PM and FM, IPSEC optional to SEG for OAM

interface

5780 DSC/

PCRF

SNMPv2c for PM and FM , HTTPS/TLS, SSHv2 for user access,

sFTP for file transfer

7750 SGW SNMPv3 or SNMPv2c for PM and FM, SCP for file transfer, SSHv2

for user access, HTTPS for XML.

7750 PGW SNMPv3 or SNMPv2c for PM and FM, SCP for file transfer, SSHv2

for user access, HTTPS for XML.

9417 MME SNMPv2c for PM and FM, HTTPS/TLS, SSHv2 for user access,

sFTP for file transfer.

[Reference to be added]

Security LTE Guide


5.4.3 System and Configuration Security

Another important area of OAM&P security is to ensure that the system of nodes is

individually secure. This is done with security hardening.

It is also important to configure essential services securely. Mechanisms should be

provided to allow services to be configured without compromise. The use of secure

access control e.g. via authentication, password management, data

confidentiality and communication security should be used for each network

element.

5.4.3.1 Network Element Hardening

The main goals of hardening are:

1. When the customer receives the product, it is secure by default.

2. The default installation process will maintain this level of security.

Systems are made up of a number of components. It is essential that these

components have all necessary security patches applied. One of the main vectors

for network attack is though the network services that a system offers. For

example, if a system offers a Telnet service it will be listening for connections on

TCP port 23 and anyone with network access can attempt to connect to that

service. Once connected, they will be challenged to enter a userid and password,

which will presumably protect the system from unauthorized access. However, if

telnet is not required for normal operation, it should be turned off entirely.

Therefore, all non-essential services including ports should be turned off and not

Depending on the system, different toolkits are available for network element

hardening. It is recommended to adopt a systematic and methodical approach for

network hardening to ensure that the individual nodes of the LTE solutions are

secure.

5.4.3.1.1 Alcatel-Lucent Solution

Each product in the LTE solution is individually hardened using the STEPS process.

More information on the STEP process is available at the following reference.

[Add Link]

5.4.3.2 Certificate Support and Management

While security with pre-shared secrets/keys is relatively simple to configure, and it

does not require huge investment in the security architecture, the main problem

Security LTE Guide


with pre-shared keys/secrets is with key management. As the network grows with

more and more nodes, the difficulty of managing the keys for each security

association becomes more difficult.

The use of certificates, X.509 in particular is based on the public key

infrastructure. It is advantageous to the pre-shared secrets approach since key

management is simplified. From an operators perspective, only the certificates of

the corresponding nodes (and the certificate authority) need to be provisioned in

order for secure communication between them. However, this solution relies on

the infrastructure being available e.g. Certificate Authority which signs the

certificates, as well as mechanisms to generate and update the certificates, and

functions to check the validity of certificates.

5.4.3.2.1 Protocols in LTE applicable for Certificates

A high level view of which protocols are applicable for certificates is shown below:

IPSEC

SSL/TLS

SSH

5.4.3.2.2 General Aspects for Certificate Support

Several Aspects are needed for Certificate Support:

1) CSR Certificate Signing Request

2) CRL management Certificate Revocation List Management

3) Private Key Storage

4) Multiple CA support

5) Certificate Expiry Management

5.4.3.2.3 Alcatel-Lucent Support

[More to add on certificates]

Security LTE Guide


5.4.3.3 Centralized Authentication

Management access into network elements must be secure users must be

authenticated and authorized, and the transactions encrypted. Both CLI and web

based access are common, which can be secured by SSH and HTTPS respectively.

Note that both server-side and client-side authentication need to be performed for

SSH and HTTPS.

One solution to establish credential is through the use of X.509 certificates as

discussed in the previous section. However the need for possession of private key

tends to complicate client side operating procedures, especially for access via

remote PCs or laptops.

A username-password approach is more desirable in these cases particularly from

the stand point of operation simplicity; and having a centralized management of

user credentials provides for a scalable solution. The use of RADIUS is a suitable

solution, where each network element that allows management access represents

a NAS, handling SSH or HTTP requests from end users and authenticating end users

against RADIUS server. All authentication and authorization information are

maintained centrally on the RADIUS server (or a combination of RADIUS and LDAP).

5.4.3.3.1 Alcatel-Lucent Support

[More to add on centralized authentication]

5.4.4 Security Logs and Alarms

Centralized logging is one of the keys to a good security posture. Log records play

an extremely important role in any well-constructed security program. They help

in the detection of anomalous activity both in real-time, as well as reactively

during an incident-response event. Centralized logging provides two important

benefits:

all log records are placed in a single location, greatly simplifying log

analysis and correlation tasks;

a secure storage area for log data, making it difficult for an attacker to

tamper with the logs stored in the central log repository.

Setting up a central log repository is also a primary step to centralized analysis

techniques that will be discussed in next section.

Security LTE Guide


5.4.4.1 Alcatel-Lucent Support

[More to add on Centralized Logging]

Security LTE Guide


5.5 Security Assurance

In information security, due diligence means a complete and comprehensive effort

is made to avoid a security breach which could cause detrimental effects and

identify various threats that may be exploited for a possible security breach.

Telecom providers need to practice due care in the operation of their telecom

networks to prevent security breaches and to have controls in place to mitigate

the effect when breaches occur. Failure to practice such due care is negligence

and increases business risk.

One objective of security assurance is to monitor information system security

controls on an ongoing basis to ensure the continued effectiveness of the

controls.

Security monitoring provides two primary benefits for organizations of all sizes: the

ability to identify attacks as they occur, and the ability to perform forensic

analysis on the events that occurred before, during, and after an attack. Security

monitoring also helps in:

Reducing the effect of attacks;

Providing for security staff to identify unusual patterns of behavior quickly;

Creating audit information to meet regulatory requirements.

One important aspect of security management is a process for collecting, storing,

and examining security audit logs. To effectively analyze the security of a network

and to respond to security incidents, procedures should be established for

collecting network activity data. For networks with strict security policies, audit

data should include user and host names for login and logout attempts, but also log

all attempts by users to change their access rights.

Besides the inherent benefits of log management, a number of laws and

regulations further compel organizations to store and review certain logs. In order

to comply with several corporate audit standards (e.g. Sarbanes-Oxley), a

corporate policy must be in place to cover the subject of critical system log

archive retention. Depending on the standards, the retention duration and other

requirements vary. However, they all require some specific duration during which

log files must be kept.

Typically, the best way to meet this need is to archive the files off of the system

where they were generated and store them with other data that has a long-term

retention need.

Collecting audit data can result in a rapid accumulation of data. The required

storage can be minimized by keeping data for a short period of time and

summarizing the data. One drawback to keeping less data, however, is that it

makes it harder to investigate security incidents: there should be as much data as

Security LTE Guide


possible available to parse through in search of clues to such issues. Compressing

the data, instead of keeping less data, is often a better solution.

However, as the number of monitored devices grows, the ability to manually follow

what is happening on each individual device decreases. Implementing a centralized

logging system as mentioned earlier moves the responsibility of the log file

retention and archival from the individual systems and to a centralized system (or

set of systems). This allows for easier purging when the storage duration has been

exceeded as well as a single place to look for log files regardless of which system

or application generated them.

Note: This enabler makes use of the Centralized Logging capability in the Secured

Mediation enabler.

As an additional benefit, centralization enhances the overall security of the

system: if a single host on the network is breached, the attacker may attempt to

modify the logs to hide his/her traces. This is more difficult when logs are

duplicated on a central log server. Encryption may also be used to prevent hackers

from altering log files, but usually placing them on a secure system on the network

or even an out-of-band system is acceptable.

A log management solution can significantly enhance an environment in both

prevention and detection of attacks, helping any organization in both achieving

compliance and protecting the network against insider threats. However,

performing effective log monitoring is resource intensive and requires advanced

technology to process all the logs and alerts being generated by the monitored

infrastructure.

Security Assurance provides an OSS-level capacity that supports the need to

monitor security-relevant activity on the LTE platform through log collection,

aggregation and correlation from the LTE network elements and security building

blocks mentioned previously.


As an added service to operators, the management of security assurance can be

managed by Alcatel-Lucent Services organization with resources dedicated to

monitoring and managing the logs.

[Add link to the services offer]

Security LTE Guide


6. SECURITY ARCHITECTURE

6.1 Architecture Guideline

Using the security enablers, it is possible to build a high level security architecture

of the LTE solution. The following architecture shall be used as a guideline.

Note: Redundancy is not shown on the diagram, but the solution requires

redundancy e.g. pair of 7750SR etc.

6.2 NE and EMS Mapping

The following Network Elements and Element Managers are applicable in the

Security Architecture.

Network Element

Name

Interface(s) affected Comments

9412/9926 eNodeB RRC, UP between UE and

eNB.

eNB and SeGW for S1-MME,

S1-U, S1-OAM, X2.

OAM between eNB and 9453

XMS.

Note: 5620 SAM

will be used as the

EMS for eNB

starting from

LE3.0.

9471 MME NAS between UE and MME

Security LTE Guide


Network Element

Name


OAM between MME and 5620

SAM.

S1-MME between MME and

eNB.

7750 S-GW OAM between 7750 SGW and

5620 SAM. It is planned to

provide combined

PGW/SGW/7750SR

with ISA (IPSEC).

For the security

requirements,

please refer to the

7750SR NE below.

7750 P-GW OAM between 7750 PGW and

5620 SAM. It is planned to

provide combined

PGW/SGW/7750SR

with ISA (IPSEC).

For the security

requirements,

please refer to the

7750SR NE below.

9453 XMS OAM between eNB and 9453

XMS. Note: 5620 SAM

will be used as the

EMS for eNB

starting from

LE3.0.

5620 SAM OAM between 5620 SAM with

9471 MME, 7750SR, 7750 SGW,

7750 PGW, 5780 DSC, 7705

SAR-F

Note: 5620 SAM

will be used as the

EMS for eNB

starting from

LE3.0.

8950 AAA S6a and S9 Interfaces.

8950AAA diameter

proxy. It is TBD if

this product will

be used for proxy

purposes in LE3.0

or if the AAA

functionality will

Security LTE Guide


Network Element

Name


be incorporated in

the 8650 SDM.

8650 SDM (HSS) OAM between 8950 SAM and

8560 SDM Note: This

interface is not

supported for LTE

only subscribers as

of LE3.0.

5780 DSC (PCRF) OAM between 7750 PGW and

5780 DSC.

ALVI Brick with

ALSMS or Fortinet

with Forti-Manager

SGi and S8

Optionally S1-MME, S1-U

protection

Optionally, S9, S6a protection

Optionally, OAM protection

7750SR+ISA for

IPSEC

OAM between 7750 SR and

5620 SAM.

S1-U, S1-MME, S1-OAM, X2

7705 SAR-F OAM between 7705 SAR-F and

5620 SAM

8950 SAM OAM between 8950 SAM and

8560 SDM Note: This

interface is not

supported for LTE

only subscribers as

of LE3.0.

Security LTE Guide


7. LTE E2E SECURITY FEATURES LIST

This section provides a list of the relevant security features applicable to the LTE

solution.

FID Title Summary

L92088 eNB Security Generic eNB hardening

L92078 eNB with IPSEC IKEv2 IPv4 of IPSEC IKEv2 ESP

L92638 Ciphering and Integrity Protection Protection of the radio interface as per 3GPP 33.401

m10607-02 MME for NAS Integrity Protection of the NAS as per 3GPP 33.401

m10607-01 MME for NAS Ciphering Protection of the NAS as per 3GPP 33.401

36004-01 Validation of Security Solution Verification of the Security Solution

L101810 OAM, 802.1x, Alarms, Certificate Management Security Alarms

L101808 IPSEC on IPv6 IPSEC with IKEv2 on IPv6 and IPv4

L101812 IPSEC with Certificates IPSEC with IKEv2 with certificates

TBD IPSEC on SGW/PGW IPSEC integrated with PGW/SGW

30028-01 Centralized Authentication Support of Centralized Authentication for all NE and NEMs

30027-01 Centralized Certificate Management Support of a centralized method of certificate management

L112784 Security Support of the PKI infrastructure Content from L101810

L112786 802.1x Content from L101810

L112787 Support of AAA Content from L101810

m10600-01 MME and IPSEC IPSEC support on MME for connection to IPSEC

m10602-01 MME and OAM Hardening OAM Hardening on MME

m10601-01 Attack Trace Back MME trace back functionality

m10505-01 Netconf over SSH OAM Security enhancement for NETCONF

TBD Centralized Logging Centralized logging capabilities

Security LTE Guide


A. CALEA/LEGAL INTERCEPT INTERFACES

The requirements mentioned below are applicable to LTE Core NE - MME, HSS, SGW

and PGW and IMS core NE 5450 ISC/5060 ICS/CSCF/SBC

The goal for providing security on LI interfaces is to prevent interception detection

by unauthorized personnel. LI administration should be operated only by LI

authorized personnel

Communication between LI nodes (IAP) and LIG should be totally secured

(Authentication and encryption). Minimally each IAP node should support SSH for

Xi, IPSec (with IKE both v1 and v2) for X2 and for UDP based X3 IPSec (encryption

of X3 data is optional based on operator deployment needs). When a NE does not

support such capability, use of external firewall/SEG should be recommended.

(Refer RFC-4835).

As LIG supports additional secured interfaces NEs could optionally support

following additional interfaces

X1: IPSec, HTTPS, SSL/TLS or SNMPv3 can also be used

X2: SSL/TLS can also be used if X2 is over TCP/IP.

X3: only IPSec can be used over UDP/IP. In case of high X3 throughput, a

specific HW may be required because SW encryption may reduce

dramatically the system capacities.

Access to and controlling of any LI functions or data in the IAP nodes shall require a

dedicated authorization level, which will be independent from any possible

operator authorization levels

LIG and all IAP nodes will support periodic audit and associated correction of LI X1-

Configuration data using LIG/MF as master DB.

From ETSI TR 102528:

Target information and intercept states in the IAP nodes shall not be accessible to

unauthorized personnel from any operational management station, via

management protocols, Command Line Interfaces (CLI) and traces or dumps, and

shall not be stored in Non Volatile Memory. If the LI node fails or re-boots, all

intercept related information and states shall disappear and shall not be accessible

by any means.

From CALEA T1.678

Access to any file, record, or report containing data that would compromise the

ability to protect the information regarding the lawful interception of

Security LTE Guide


communications and access to call-identifying information shall be restricted to

authorized users. Examples of such files, records, or reports are:

the log file of surveillance administrative activities discussed above,

any file containing information about existing or past surveillances,.

Any persistent LI related data on IAP nodes should be stored only after encryption.

Backup and restore operations for LI stored encrypted data will retain its