ETSI TS 133 204 V9.0.0 (2010-02)

ETSI TS 133 204 V9.0.0 (2010-02)
Technical Specification
Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS);
LTE;
3G Security;
Network Domain Security (NDS);
Transaction Capabilities Application Part (TCAP)
user security
(3GPP TS 33.204 version 9.0.0 Release 9)
---------------------- Page: 1 ----------------------
3GPP TS 33.204 version 9.0.0 Release 9 1 ETSI TS 133 204 V9.0.0 (2010-02)
Reference
RTS/TSGS-0333204v900
Keywords
GSM, LTE, SECURITY, UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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

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

If you find errors in the present document, please send your comment to one of the following services:

DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered

3GPP is a Trade Mark 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.

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

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

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

Intellectual Property Rights ................................................................................................................................ 2

Foreword ............................................................................................................................................................. 2

Foreword ............................................................................................................................................................. 5

Introduction ........................................................................................................................................................ 5

1 Scope ........................................................................................................................................................ 6

2 References ................................................................................................................................................ 6

3 Definitions, symbols and abbreviations ................................................................................................... 6

3.1 Definitions .......................................................................................................................................................... 6

3.2 Symbols .............................................................................................................................................................. 7

3.3 Abbreviations ..................................................................................................................................................... 7

3.4 Conventions ........................................................................................................................................................ 8

4 Principles of TCAP user security ............................................................................................................. 8

4.1 Overview ............................................................................................................................................................ 8

4.2 Network architecture .......................................................................................................................................... 8

4.2.1 General .......................................................................................................................................................... 8

4.2.2 End-to-end architecture ................................................................................................................................. 9

4.2.3 Hub-and-Spoke architecture ......................................................................................................................... 9

5 TCAP user security (TCAPsec) ............................................................................................................. 10

5.1 Security services provided by TCAPsec .......................................................................................................... 10

5.2 Properties and tasks of an SS7-SEG ................................................................................................................. 10

5.3 Policy requirements for the TCAPsec Security Policy Database (SPD) .......................................................... 11

5.4 TCAPsec security association attribute definition ............................................................................................ 11

5.5 TCAPsec structure of protected messages ........................................................................................................ 12

5.5.1 TCAPsec security header ............................................................................................................................ 13

5.5.2 Protected payload ........................................................................................................................................ 13

5.5.2.1 Protection Mode 1 ................................................................................................................................. 13

5.5.2.2 Protection Mode 2 ................................................................................................................................. 14

5.6 TCAPsec algorithms......................................................................................................................................... 14

5.6.1 Mapping of TCAPsec SA encryption algorithm identifiers ........................................................................ 14

5.6.1.1 Description of SEA-0 ............................................................................................................................ 14

5.6.2 Mapping of TCAPsec SA integrity algorithm identifiers ........................................................................... 14

5.6.2.1 Description of SIA-0 ............................................................................................................................. 15

5.6.3 Construction of IV ...................................................................................................................................... 15

Annex A (informative): Guidelines for manual key management ..................................................... 16

A.1 Inter-domain Security Association and Key Management Procedures .................................................. 16

A.2 Local Security Association Distribution ................................................................................................ 16

Annex B (normative): TCAPsec message flows ................................................................................. 17

Annex C (informative): High level migration strategy ....................................................................... 19

C.1 Transition phase from unprotected to protected message transfer ......................................................... 19

C.2 Transition phase from protected message transfer to unprotected message transfer. ............................. 20

C.3 Transition phase from protected mode to another protected mode ........................................................ 20

Annex D (normative): Using TCAP handshake for SMS transfer .................................................. 21

D.1 Mobile Terminated SMS ........................................................................................................................ 21

D.2 Mobile Originated SMS ......................................................................................................................... 22

Annex E (informative): Change history ............................................................................................... 24

History .............................................................................................................................................................. 25

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

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,

z the third digit is incremented when editorial only changes have been incorporated in the document.

The absence of security in Signalling System No. 7 (SS7) networks is an identified security weakness in 2G systems.

This was formerly perceived not to be a problem, since the SS7 networks were the provinces of a small number of large

institutions. This is no longer the case, and so there is now a need for security precautions.

For 3G systems it is a clear goal to be able to protect the core network signalling protocols, and by implication this

means that security solutions shall be found for both SS7 and IP based protocols.

Various protocols and interfaces are used for control plane signalling within and between core networks. The security

services that have been identified as necessary are confidentiality, integrity, authentication and anti-replay protection.

This technical specification covers the security mechanisms and procedures necessary to protect all TCAP user

messages which are sent between different security domains. The complete set of enhancements and extensions to

facilitate security protection for the TCAP protocol is termed TCAPsec and it covers transport security in the TCAP

This technical specification contains the stage 2 specification for security protection of the TCAP protocol. The actual

The following documents contain provisions which, through reference in this text, constitute provisions of the present

• References are either specific (identified by date of publication, edition number, version number, etc.) or

• 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

[3] NIST Special Publication 800-38A "Recommendation for Block Cipher Modes of Operation"

[4] ISO/IEC 9797: "Information technology -- Security techniques -- Message Authentication Codes

[5] FIPS Publication 197: "Specification for the Advanced Encryption Standard (AES)",

[6] 3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security".

[7] W3C DTF profile of ISO 8601: 2000 - Data Elements and Interchange Formats - Information

Interchange - Representation of Dates and Times. International Organization for Standardization.

[9] 3GPP TS 29.204: "Signalling System No. 7 (SS7) security gateway; Architecture, functional

In addition to the definitions included in TR 21.905 [1], for the purposes of the present document, the following

Anti-replay protection: Anti-replay protection is a special case of integrity protection. Its main service is to protect

against replay of self-contained packets that already have a cryptographic integrity mechanism in place.

Confidentiality: The property that information is not made available or disclosed to unauthorised individuals, entities

Data integrity: The property that data has not been altered in an unauthorised manner.

Data origin authentication: The corroboration that the source of data received is as claimed.

Entity authentication: The provision of assurance of the claimed identity of an entity.

Key freshness: A key is fresh if it can be guaranteed to be new, as opposed to an old key being reused through actions

Security Association: A logical connection created for security purposes. All traffic traversing a security association is

provided the same security protection. The security association specifies protection levels, algorithms to be used,

SS7 Security Gateway: A Network Node that terminates and initiates TCAPsec. Similar to a SEG (see TS 33.210 [6]),

the SS7 security Gateway is used for communication between two SS7 security domains.

TCAPsec: The complete collection of protocols and procedures needed to protect TCAP user messages.

Zf TCAPsec reference point between SS7-SEGs engaged in security protected signalling.

In addition to the abbreviations included in TR 21.905 [1], for the purposes of the present document, the following

TCAP user Application Part identified by the SCCP Subsystem Numbers of TS 23.003 [8]

All data variables in this specification are presented with the most significant substring on the left hand side and the

least significant substring on the right hand side. A substring may be a bit, byte or other arbitrary length bitstring.

Where a variable is broken down into a number of substrings, the leftmost (most significant) substring is numbered 0,

the next most significant is numbered 1, and so on through to the least significant.

This technical specification defines mechanisms for protecting all TCAP user messages called TCAPsec. Another

approach which could partially achieve the same goal as TCAPsec is the use of NDS/IP [6] at the network layer when

IP is used as the transport protocol. However, whenever inter-working with networks using SS7-based transport is

The benefit for an operator applying TCAPsec will gradually increase when more interconnected operators also apply

TCAPsec. TCAPsec can be used together with TCAP handshake solutions, however when using TCAPsec for MAP

SMS transfers between two PLMNs, running TCAP handshake in addition does not add more security.

NOTE 1: A limited level of MAP message authenticity can be achieved without the use of SS7-SEGs by using a

TCAP handshake prior to the MAP payload exchange. Annex D describes the use of the TCAP

NOTE 2: TCAPsec does not validate the TCAP user payload content (e.g. SMS payload address correlation as

described for TCAP handshake in Annex D). Message screening functions for particular message types

NOTE 3: In order to prevent all active attacks all interconnected operators shall route all SS7 traffic via SS7-SEGs.

Before protection can be applied, Security Associations (SA) need to be established between the respective SS7-SEG.

Security associations define, among other things, which keys and algorithms to use at the SS7-SEG. The necessary SAs

between networks are negotiated between the respective network operators. The negotiated SA will be effective PLMN-

wide and distributed to all SS7-SEGs. Each SS7-SEG contains policy information containing the protection mode that

shall be applied. Protected TCAP user signalling traffic will, for routing purposes, be indistinguishable from

unprotected traffic to all parties except for the sending and receiving entities.

Annex B includes detailed procedures on how secure TCAP user signalling is performed between two SS7-SEGs.

The first case is considered in the end-to-end architecture (cf. clause 4.2.2). This architecture is applied in case the

In a hub-and-spoke architecture, a concatenation of multiple second and third cases may happen (cf. clause 4.2.3).

Using this architecture is required if certain payload related services are performed by an SS7-carrier for whom the

In a PLMN that employs SS7-SEGs all TCAP user signalling messages entering or leaving the PLMN have to transit an

SS7-SEG which belongs to the PLMN and which performs the protection of outgoing messages and the protection

checking and de-protection or blocking of incoming messages. SS7-SEG shall do Global Title Translation. For all

unprotected messages from network elements inside one PLMN that are destined for another PLMN, the destination

point is a SS7-SEG of the originating PLMN. After the messages are protected by a SS7-SEG of the originating PLMN,

this SS7-SEG shall direct the message towards the destination NE (cf. figure 4.2-1).

An SS7-SEG may be co-located with any TCAP user NE or it may stand alone. However, for the purpose of this

specification and without imposing any restrictions, it is assumed that the SS7-SEG is stand alone.

It is further assumed that the SS7-SEGs are located at the border of the PLMN i.e. incoming messages transit an SS7-

SEG before they reach any other node within the PLMN, and outgoing messages transit an SS7-SEG immediately

An example of such a service is steering of roaming. Another example is an SMS hubbing architecture where the

HUB (i.e. the SS7 carrier) has to insert a virtual SMSC-address in the MAP message.

Using a hub-and-spoke architecture for SS7SEGs may be used for following cases but can also be performed in the end-

a) The intermediate SS7-carrier performs message screening (e.g. SPAM control) and may have to drop messages.

If the communicating PLMNs have agreed to use protection mode 1 then using the end-to-end architecture is

If the communicating PLMNs have agreed to use protection mode 2 and both PLMNs find it acceptable to share

the confidentiality key with the SS7 carrier then the end-to-end architecture can be used and is preferred from a

security point of view. If confidentiality key sharing is not acceptable then the hub-and-spoke architecture is the

NOTE: From a security point of view the number of intermediate hubs should be limited.

- SAD-SEG: A database containing TCAPsec SA information. SS7-SEG shall monitor the SA hard expiry time

- Secure TCAP user signalling (i.e. send/receive protected or unprotected messages) according to information in

SPD-SEG and SAD-SEG. The structure of protected messages is defined in clause 5.5 and the protection

The security policies for TCAPsec key management are specified in the SS7-SEG’s SPD. SPD entries define per peer

network whether protection shall be applied, and if protection shall be applied then which protection mode shall be

used. SPD entries of different SS7-SEGs within the same network shall be consistent.

- The "fallback to unprotected mode" (enabled/disabled) is a parameter for the receiving direction per network, if

enabled it allows the receiving network to accept unprotected traffic as well as protected traffic. If disabled, only

- The security measures specified in this TS are only fully useful for a particular network if it disallows fallback to

NOTE: The benefit gained for a sending operator A that applies TCAPsec for all or a subset of messages towards

a peer network B is that spoofing of the SCCP calling party address for all or a subset of messages can be

detected. The receiving network B is now able to reject unprotected messages for all or a subset of

- The SPD shall contain an entry for each network the SS7-SEG is allowed to communicate with.

- SPD administration shall be allowed on TCAP user application part level for each network the SS7-SEG is

- An SPD entry may contain two protection modes for the same network. If this is the case then both protection

modes shall be acceptable for incoming messages, but only one (preferred) protection mode shall be used for

The TCAPsec security association shall contain the following data elements which can be classified in two groups

In sending direction the SA identification is based on Destination Network Id. Per Destination Network Id more than

one SA may exist. In the case where more than one valid SA is available at the SAD, the sending SS7-SEG shall

In receiving direction the used SPI from within the TCAPsec security header can be used to retrieve the Origin

The Destination Network Id is a concatenation of the Country Code (CC) and National Destination Code (NDC)

of the receiving network. The Destination Network-Id is used to identify which SAD-entry shall be used when

SPI is a 32-bit value that is used in combination with Destination Network Id to uniquely identify a TCAPsec

SA. The SPI is used to identify which SAD entry shall be used when de-protecting traffic. Therefore the SPI

The Origin Network Id is a concatenation of the Country Code (CC) and National Destination Code (NDC) of