Ts 133401v121200p
Ts 133401v121200p
Ts 133401v121200p
0 (2014-10)
TECHNICAL SPECIFICATION
Reference
RTS/TSGS-0333401vcc0
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 enregistre la
Sous-Prfecture de Grasse (06) N 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
European Telecommunications Standards Institute 2014.
All rights reserved.
TM
TM
TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.
ETSI
Contents
Intellectual Property Rights ................................................................................................................................2
Foreword.............................................................................................................................................................2
Modal verbs terminology....................................................................................................................................2
Foreword.............................................................................................................................................................8
1
Scope ........................................................................................................................................................9
References ................................................................................................................................................9
3.1
3.2
3.3
3.4
Definitions ........................................................................................................................................................ 10
Symbols ............................................................................................................................................................ 12
Abbreviations ................................................................................................................................................... 12
Conventions ...................................................................................................................................................... 14
5.1
5.1.0
5.1.1
5.1.2
5.1.3
5.1.3.1
5.1.3.2
5.1.4
5.1.4.1
5.1.4.2
5.2
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.4a
5.3.5
5.4
6
6.0
6.1
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
6.2
6.3
6.4
6.5
7
7.0
7.1
7.2
7.2.1
ETSI
7.2.2
7.2.3
7.2.4
7.2.4.1
7.2.4.2
7.2.4.2.1
7.2.4.2.2
7.2.4.2.3
7.2.4.2.4
7.2.4.3
7.2.4.3.1
7.2.4.3.2
7.2.4.4
7.2.4.5
7.2.4a
7.2.5
7.2.5.1
7.2.5.2
7.2.5.2.1
7.2.5.2.2
7.2.5.2.3
7.2.6
7.2.6.1
7.2.6.2
7.2.6.3
7.2.7
7.2.8
7.2.8.1
7.2.8.1.1
7.2.8.1.2
7.2.8.2
7.2.8.3
7.2.8.4
7.2.8.4.1
7.2.8.4.2
7.2.8.4.3
7.2.8.4.4
7.2.9
7.2.9.1
7.2.9.2
7.2.9.3
7.2.9.4
7.2.10
7.3
7.3.1
7.3.2
7.4
7.4.1
7.4.2
7.4.3
7.5
8
8.0
8.1
8.1.1
8.1.2
8.2
9
9.1
ETSI
9.1.1
9.1.2
9.2
9.2.1
9.2.2
9.2.2.1
9.2.2.2
9.3
9.4
9.4.1
10
10.1
10.2
10.2.1
10.2.2
10.3
10.3.1
10.3.2
10.3.2.1
10.4
10.5
10.5.1
General ............................................................................................................................................................. 57
RAU and TAU procedures ............................................................................................................................... 58
RAU procedures in GERAN ....................................................................................................................... 58
TAU procedures in E-UTRAN ................................................................................................................... 58
Handover .......................................................................................................................................................... 58
From E-UTRAN to GERAN ...................................................................................................................... 58
From GERAN to E-UTRAN ...................................................................................................................... 58
Procedures ............................................................................................................................................. 58
Recommendations on AKA at IRAT-mobility to E-UTRAN .......................................................................... 58
Attach procedures ............................................................................................................................................. 59
Attach in GERAN ....................................................................................................................................... 59
11
12
13
14
14.1
14.2
14.3
14.3.1
15
15.1
15.2
15.2.1
15.2.1.1
15.2.1.2
15.2.2
15.2.2.1
15.2.2.2
15.2.3
15.2.4
15.2.4.1
15.2.4.2
General ............................................................................................................................................................. 65
Security procedures and their applicability ...................................................................................................... 66
Authenticated IMS Emergency Sessions .................................................................................................... 66
General .................................................................................................................................................. 66
UE and MME share a current security context ..................................................................................... 66
Unauthenticated IMS Emergency Sessions ................................................................................................ 67
General .................................................................................................................................................. 67
UE and MME share no security context ............................................................................................... 68
Void ............................................................................................................................................................ 69
Key generation procedures for unauthenticated IMS Emergency Sessions ................................................ 69
General .................................................................................................................................................. 69
Handover ............................................................................................................................................... 69
Annex A (normative):
A.1
A.1.1
A.1.2
A.2
A.3
A.4
NH derivation function...........................................................................................................................71
A.5
A.6
Void ........................................................................................................................................................71
A.7
ETSI
A.8
A.9
B.0
B.1
B.1.1
B.1.2
B.1.3
B.1.4
B.2
B.2.1
B.2.2
B.2.3
B.2.4
Annex C (informative):
C.1
C.1.1
C.1.2
C.1.3
C.1.4
C.1.5
C.1.6
C.2
C.2.1
C.2.2
C.2.3
C.2.4
C.2.5
C.2.6
C.2.7
C.2.8
128-EEA2 ...............................................................................................................................................79
Test Set 1 .......................................................................................................................................................... 79
Test Set 2 .......................................................................................................................................................... 80
Test Set 3 .......................................................................................................................................................... 81
Test Set 4 .......................................................................................................................................................... 81
Test Set 5 .......................................................................................................................................................... 82
Test Set 6 .......................................................................................................................................................... 83
128-EIA2 ................................................................................................................................................86
Test Set 1 .......................................................................................................................................................... 87
Test Set 2 .......................................................................................................................................................... 88
Test Set 3 .......................................................................................................................................................... 89
Test Set 4 .......................................................................................................................................................... 90
Test Set 5 .......................................................................................................................................................... 91
Test Set 6 .......................................................................................................................................................... 92
Test Set 7 .......................................................................................................................................................... 93
Test Set 8 .......................................................................................................................................................... 95
C.3
128-EEA1 .............................................................................................................................................106
C.4
128-EIA1 ..............................................................................................................................................106
C.4.1
C.4.2
C.4.3
C.4.4
C.4.5
C.4.6
C.4.7
Annex D (normative):
D.1
Introduction ..........................................................................................................................................111
D.2
Solution ................................................................................................................................................111
ETSI
D.2.1
D.2.2
D.2.3
D.2.4
D.2.5
D.2.6
D.3
D.3.1
D.3.2
D.3.3
D.3.3.1
D.3.3.2
D.3.3.3
D.3.3.4
D.3.4
D.3.5
Annex E
Dual connectivity..........................................................................................120
E.1
Introduction ..........................................................................................................................................120
E.2
E.2.1
E.2.2
E.2.3
E.2.4
E.2.4.1
E.2.4.2
E.2.4.3
E.2.5
E.2.5.1
E.2.5.2
E.2.6
E.2.7
E.2.8
Annex F (informative):
History ............................................................................................................................................................130
ETSI
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
Scope
The present document specifies the security architecture, i.e., the security features and the security mechanisms for the
Evolved Packet System and the Evolved Packet Core, and the security procedures performed within the evolved Packet
System (EPS) including the Evolved Packet Core (EPC) and the Evolved UTRAN (E-UTRAN).
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
-
References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1]
[2]
3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".
[3]
[4]
[5]
3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security".
[6]
[7]
[8]
[9]
3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);
Stage 3".
[10] [11]
Void.
[12]
3GPP TS 36.323: "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data
Convergence Protocol (PDCP) specification"
[13]
[14]
3GPP TS 35.215: "Confidentiality and Integrity Algorithms UEA2 & UIA2; Document 1: UEA2
and UIA2 specifications"
[15]
[16]
NIST Special Publication 800-38A (2001): "Recommendation for Block Cipher Modes of
Operation".
[17]
NIST Special Publication 800-38B (2001): "Recommendation for Block Cipher Modes of
Operation: The CMAC Mode for Authentication".
[18] [20]
Void.
ETSI
10
[21]
3GPP TS 36.331:"Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control
(RRC); Protocol specification".
[22]
3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".
[23]
3GPP TS 22.101: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Service aspects; Service principles".
[24]
3GPP TS 25.331: "3rd Generation Partnership Project; Technical Specification Group Radio
Access Network; Radio Resource Control (RRC); Protocol Specification ".
[25]
[26]
3GPP TS 23.122: "3rd Generation Partnership Project; Technical Specification Group Core
Network and Terminals; Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in
idle mode".
[27]
3GPP TS 33.320: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Security of Home Node B (HNB) / Home evolved Node B (HeNB)".
[28]
(void)
[29]
ETSI TS 102 484 V10.0.0: "Smart Cards; Secure channel between a UICC and an end-point
terminal".
[30]
3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[31]
3GPP TS 31.116 "Remote APDU Structure for (Universal) Subscriber Identity Module (U)SIM
Toolkit applications".
[32]
ETSI TS 102 221 V9.2.0: "Smart Cards; UICC-Terminal interface; Physical and logical
characteristics".
[33]
3GPP TS 35.221: "Confidentiality and Integrity Algorithms EEA3 & EIA3; Document 1: EEA3
and EIA3 specifications".
[34]
3.1
Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1], in TS 33.102 [4] and the
following apply. A term defined in the present document takes precedence over the definition of the same term, if any,
in TR 21.905 [1].
Access Security Management Entity: entity which receives the top-level keys in an access network from the HSS. For
E-UTRAN access networks, the role of the ASME is assumed by the MME
Activation of security context: the process of taking into use a security context.
Authentication data: Data that is part of a security context or of authentication vectors.
Chaining of KeNB: derivation of a new KeNB from another KeNB (i.e., at cell handover)
Current EPS security context: The security context which has been activated most recently. Note that a current EPS
security context originating from either a mapped or native EPS security context may exist simultaneously with a native
non-current EPS security context.
ETSI
11
ECM-CONNECTED state: This is as defined in TS 23.401 [2]. The term ECM-CONNECTED state corresponds to
the term EMM-CONNECTED mode used in TS 24.301 [9].
ECM-IDLE state: As defined in TS 23.401 [2]. The term ECM-IDLE state corresponds to the term EMM-IDLE mode
used in TS 24.301 [9].
EPS-Authentication Vector: KASME, RAND, AUTN, XRES
EPS security context: A state that is established locally at the UE and a serving network domain. At both ends "EPS
security context data" is stored, that consists of the EPS NAS security context, and the EPS AS security context.
NOTE 1: An EPS security context has type "mapped", "full native" or "partial native". Its state can either be
"current" or "non-current". A context can be of one type only and be in one state at a time. The state of a
particular context type can change over time. A partial native context can be transformed into a full
native. No other type transformations are possible.
EPS AS security context: the cryptographic keys at AS level with their identifiers, the Next Hop parameter NH, the
Next Hop Chaining Counter parameter NCC used for next hop access key derivation, the identifiers of the selected AS
level cryptographic algorithms, counters used for replay protection and SCG Counter used as freshness input into SKeNB derivations. Note that the EPS AS security context only exists when cryptographically protected radio bearers are
established and is otherwise void.
NOTE 2: NH and NCC need to be stored also at the MME during connected mode.
EPS AS Small Cell security context: This context consists of the cryptographic keys for SeNB (S-KeNB and KUPenc),
the identifier of the selected AS SC level cryptographic algorithm and counters used for replay protection. Note that the
EPS AS SC security context exists at SeNB only when cryptographically protected radio bearers for SeNB are
established and is otherwise void.
EPS NAS security context: This context consists of KASME with the associated key set identifier, the UE security
capabilities, and the uplink and downlink NAS COUNT values. In particular, separate pairs of NAS COUNT values are
used for each EPS NAS security contexts, respectively. The distinction between native and mapped EPS security
contexts also applies to EPS NAS security contexts. The EPS NAS security context is called "full" if it additionally
contains the keys KNASint and KNASenc and the identifiers of the selected NAS integrity and encryption algorithms.
Full native EPS security context: A native EPS security context for which the EPS NAS security context is full
according to the above definition. A full native EPS security context is either in state "current" or state "non-current".
Forward security: In the context of KeNB key derivation, forward security refers to the property that, for an eNB with
knowledge of a KeNB, shared with a UE, it shall be computationally infeasible to predict any future KeNB, that will be
used between the same UE and another eNB. More specifically, n hop forward security refers to the property that an
eNB is unable to compute keys that will be used between a UE and another eNB to which the UE is connected after n or
more handovers (n=1 or 2).
Legacy security context: A security context which has been established according to TS 33.102 [4].
Mapped security context: Security context created by converting the current security context in the source system to a
security context for the target system in inter-system mobility, e.g., UMTS keys created from EPS keys. The EPS NAS
security context of a mapped security context is full and current.
Native EPS security context: An EPS security context whose KASME was created by a run of EPS AKA.
Non-current EPS security context: A native EPS security context that is not the current one. A non-current EPS
security context may be stored along with a current EPS security context in the UE and the MME. A non-current EPS
security context does not contain an EPS AS security context. A non-current EPS security context is either of type "full
native" or of type "partial native".
Partial native EPS security context: A partial native EPS security context consists of KASME with the associated key
set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values, which are initially set to
zero before the first NAS SMC procedure for this security context. A partial native EPS security context is created by
an EPS AKA, for which no corresponding successful NAS SMC has been run. A partial native context is always in state
"non-current".
Re-derivation of NAS keys: derivation of new NAS keys from the same KASME but including different algorithms (and
no freshness parameter)
ETSI
12
Refresh of KeNB: derivation of a new KeNB from the same KASME and including a freshness parameter
Re-keying of KeNB: derivation of a new KeNB from a new KASME in ECM-CONNECTED (i.e., . to activate a partial
native EPS security context, or to re-activate a non-current full EPS security context)
Re-keying of NAS keys: derivation of new NAS keys from a new KASME
UE security capabilities: The set of identifiers corresponding to the ciphering and integrity algorithms implemented in
the UE. This includes capabilities for EPS AS and NAS, and includes capabilities for UTRAN and GERAN if these
access types are supported by the UE.
UE EPS security capabilities: The UE security capabilities for EPS AS and NAS.
3.2
Symbols
For the purposes of the present document, the following symbols apply:
||
Concatenation
3.3
Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
AES
AK
AKA
AMF
AN
AS
AUTN
AV
ASME
Cell-ID
CK
CKSN
C-RNTI
CRL
DeNB
DoS
DSCP
EARFCN-DL
ECM
EEA
EIA
eKSI
EMM
eNB
EPC
EPS
EPS-AV
E-UTRAN
GERAN
GUTI
HE
HFN
HO
HSS
ETSI
IK
IKE
IMEI
IMEISV
IMSI
IRAT
ISR
KDF
KSI
LSB
LSM
MAC-I
MACT
MeNB
ME
MME
MME-RN
MS
MSC
MSIN
NAS
NAS-MAC
NCC
NH
OCSP
OTA
PCI
PDCP
PLMN
PRNG
PSK
P-TMSI
RAND
RAU
RN
RRC
SCG
SEG
SGSN
SIM
SMC
SeNB
SN
SN id
SQN
SRB
SRVCC
S-TMSI
TAI
TAU
UE
UEA
UIA
UICC
UMTS
UP
USIM
UTRAN
XRES
13
Integrity Key
Internet Key Exchange
International Mobile Station Equipment Identity
International Mobile Station Equipment Identity and Software Version number
International Mobile Subscriber Identity
Inter-Radio Access Technology
Idle Mode Signaling Reduction
Key Derivation Function
Key Set Identifier
Least Significant Bit
Limited Service Mode
Message Authentication Code for Integrity (terminology of TS36.323 [12])
Message Authentication Code T used in AES CMAC calculation
Master eNB
Mobile Equipment
Mobility Management Entity
MME serving the RN
Mobile Station
Mobile Switching Center
Mobile Station Identification Number
Non Access Stratum
Message Authentication Code for NAS for Integrity (called MAC in TS24.301 [9])
Next hop Chaining Counter
Next Hop
Online Certificate Status Protocol
Over-The-Air (update of UICCs)
Physical Cell Identity as used in TS 36.331 [21]
Packet Data Convergence Protocol
Public Land Mobile Network
Pseudo Random Number Generator
Pre-shared Key
Packet- Temporary Mobile Subscriber Identity
RANDom number
Routing Area Update
Relay Node
Radio Resource Control
Secondary Cell Group
Security Gateway
Serving GPRS Support Node
Subscriber Identity Module
Security Mode Command
Secondary eNB
Serving Network
Serving Network identity
Sequence Number
Source Route Bridge
Single Radio Voice Call Continuity
S-Temporary Mobile Subscriber Identity
Tracking Area Identity
Tracking Area Update
User Equipment
UMTS Encryption Algorithm
UMTS Integrity Algorithm
Universal Integrated Circuit Card
Universal Mobile Telecommunication System
User Plane
Universal Subscriber Identity Module
Universal Terrestrial Radio Access Network
Expected Response
ETSI
3.4
14
Conventions
All data variables in the present document 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.
(IV)
User Application
Provider Application
(I)
Application
stratum
(I)
(III)
USIM
HE
(II)
(I)
ME
(I)
(I)
Home
stratum/
Serving
Stratum
SN
(II)
AN
Transport
stratum
(I)
Network access security (I): the set of security features that provide users with secure access to services, and
which in particular protect against attacks on the (radio) access link.
Network domain security (II): the set of security features that enable nodes to securely exchange signalling
data, user data (between AN and SN and within AN), and protect against attacks on the wireline network.
User domain security (III): the set of security features that secure access to mobile stations.
Application domain security (IV): the set of security features that enable applications in the user and in the
provider domain to securely exchange messages.
Visibility and configurability of security (V): the set of features that enables the user to inform himself
whether a security feature is in operation or not and whether the use and provision of services should depend on
the security feature.
NOTE:
Relay nodes are not explicitly shown in Figure 4-1. They combine the functionalities of ME and AN in a
way described in 3GPP TS 36.300 [30]. The present document describes how to apply security features to
relay nodes.
ETSI
15
Security Features
5.1
User-to-Network security
5.1.0
General
The statements relating to eNBs in clause 5.1 apply also to RNs regarding the security between a UE and a relay node.
The statements relating to UEs in clause 5.1 apply also to RNs regarding the security between a relay node and a Donor
eNB and between a relay node and its MME unless stated otherwise.
5.1.1
5.1.2
Entity authentication
5.1.3
5.1.3.1
Ciphering may be provided to RRC-signalling to prevent UE tracking based on cell level measurement reports,
handover message mapping, or cell level identity chaining. RRC signalling confidentiality is an operator option.
All S1 and X2 messages carried between RN and DeNB shall be confidentiality-protected.
NOTE 0: Encryption is subject to national regulation.
Synchronization of the input parameters for ciphering shall be ensured for the protocols involved in the ciphering.
The NAS signalling may be confidentiality protected. NAS signalling confidentiality is an operator option.
NOTE 1: RRC and NAS signalling confidentiality protection is recommended to be used.
When authentication of the credentials on the UICC during Emergency Calling in Limited Service Mode, as defined in
the TS 23.401 [2], can not be successfully performed, the confidentiality protection of the RRC and NAS signaling, and
user plane shall be omitted (see clause 15). This shall be accomplished by the network by selecting EEA0 for
confidentiality protection of NAS, RRC and user plane.
ETSI
16
User plane confidentiality protection shall be done at PDCP layer and is an operator option.
NOTE 2: User plane confidentiality protection is recommended to be used.
NOTE 3: Confidentiality protection for RRC and UP is applied at the PDCP layer, and no layers below PDCP are
confidentiality protected. Confidentiality protection for NAS is provided by the NAS protocol.
5.1.3.2
All algorithms specified in this subclause are algorithms with a 128-bit input key except Null ciphering algorithm.
NOTE:
Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list
below.
Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier. Currently, the following values have been
defined for NAS, RRC and UP ciphering:
"00002"
EEA0
"00012"
128-EEA1
"00102"
128-EEA2
"00112"
128-EEA3
5.1.4
5.1.4.1
Synchronization of the input parameters for integrity protection shall be ensured for the protocols involved in the
integrity protection.
Integrity protection, and replay protection, shall be provided to NAS and RRC-signalling.
All NAS signaling messages except those explicitly listed in TS 24.301 [9] as exceptions shall be integrity-protected.
All RRC signaling messages except those explicitly listed in TS 36.331 [21] as exceptions shall be integrity-protected.
When authentication of the credentials on the UICC during Emergency Calling in Limited Service Mode, as defined in
the TS 23.401 [2], can not be successfully performed, the integrity and replay protection of the RRC and NAS signaling
shall be omitted (see clause 15). This shall be accomplished by the network by selecting EIA0 for integrity protection of
NAS and RRC. EIA0 shall only be used for unauthenticated emergency calls.
User plane packets between the eNB and the UE shall not be integrity protected on the Uu interface. User plane packets
between the RN and the UE shall not be integrity protected. All user plane packets carrying S1 and X2 messages
between RN and DeNB shall be integrity-protected. Integrity protection for all other user plane packets between RN
and DeNB may be supported.
5.1.4.2
All algorithms specified in this subclause are algorithms with a 128-bit input key.
NOTE:
Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list
below.
Each EPS Integrity Algorithm (EIA) will be assigned a 4-bit identifier. Currently, the following values have been
defined:
ETSI
"00002"
EIA0
"00012"
128-EIA1
"00102"
128-EIA2
"00112"
128-EIA3
17
5.2
Although in general the security features should be transparent to the user, for certain events and according to the user's
concern, greater user visibility of the operation of following security feature shall be provided:
-
indication of access network encryption: the property that the user is informed whether the confidentiality of user
data is protected on the radio access link, in particular when non-ciphered calls are set-up;
enabling/disabling user-USIM authentication: the user should be able to control the operation of user-USIM
authentication, e.g., for some events, services or use.
5.3
5.3.1
General
The security requirements given in this section apply to all types of eNodeBs. More stringent requirements for specific
types of eNodeBs may be defined in other 3GPP specifications.
5.3.2
Setting up and configuring eNBs shall be authenticated and authorized so that attackers shall not be able to modify the
eNB settings and software configurations via local or remote access.
1. The support of security associations is required between the Evolved Packet Core (EPC) and the eNB and
between adjacent eNBs, connected via X2. These security association establishments shall be mutually
authenticated and used for user and control plane communication between the entities. However, in cases when a
DeNB acts as proxy for control or user plane messages to and from a RN, hop-by-hop security associations shall
be used for user and control plane. The security associations shall be realized according to clauses 11 and 12 of
the present document except for the Un interface between RN and DeNB. The decision on whether or not to use
the certificate enrolment mechanism specified in TS 33.310 [6] for eNB is left to operators.
ETSI
18
2. Communication between the O&M systems and the eNB shall be confidentiality, integrity and replay protected
from unauthorized parties. The support of security associations is required between the eNB and an entity in the
Evolved Packet Core (EPC) or in an O&M domain trusted by the operator. These security association
establishments shall be mutually authenticated. The security associations shall be realized according to clause 13
for eNBs and clause D.2.5 for RNs.
3. The eNB shall be able to ensure that software/data change attempts are authorized
4. The eNB shall use authorized data/software.
5. Sensitive parts of the boot-up process shall be executed with the help of the secure environment.
6. Confidentiality of software transfer towards the eNB shall be ensured.
7. Integrity protection of software transfer towards the eNB shall be ensured.
5.3.3
TheEPC provides subscriber specific session keying material for the eNBs, which also hold long term keys used for
authentication and security association setup purposes. Protecting all these keys is important.
1. Keys stored inside eNBs shall never leave a secure environment within the eNB except when done in accordance
with this or other 3GPP specifications.
5.3.4
It is eNB's task to cipher and decipher user plane packets between the Uu reference point and the S1/X2 reference
points and to handle integrity protection for user plane packets for the S1/X2 reference points.
1. User plane data ciphering/deciphering and integrity handling shall take place inside the secure environment
where the related keys are stored.
2. The transport of user data over S1-U and X2-U shall be integrity, confidentially and replay-protected from
unauthorized parties. If this is to be accomplished by cryptographic means, clause 12 shall be applied except for
the Un interface between RN and DeNB.
NOTE: The use of cryptographic protection on S1-U and X2-U is an operator's decision. In case the eNB has been
placed in a physically secured environment then the 'secure environment' may include other nodes and
links beside the eNB.
5.3.4a
It is eNB's task to provide confidentiality and integrity protection for control plane packets on the S1/X2 reference
points.
1. Control plane data ciphering/deciphering and integrity handling shall take place inside the secure environment
where the related keys are stored.
2. The transport of control plane data over S1-MME and X2-C shall be integrity-, confidentiality- and replayprotected from unauthorized parties. If this is to be accomplished by cryptographic means, clause 11 shall be
applied except for the Un interface between RN and DeNB.
NOTE: The use of cryptographic protection on S1-MME and X2-C is an operator's decision. In case the eNB has
been placed in a physically secured environment then the 'secure environment' may include other nodes
and links beside the eNB.
5.3.5
The secure environment is logically defined within the eNB and is a composition of functions for the support of
sensitive operations.
1. The secure environment shall support secure storage of sensitive data, e.g. long term cryptographic secrets and
vital configuration data.
ETSI
19
2. The secure environment shall support the execution of sensitive functions, e.g. en-/decryption of user data and
the basic steps within protocols which use long term secrets (e.g. in authentication protocols).
3. Sensitive data used within the secure environment shall not be exposed to external entities.
4. The secure environment shall support the execution of sensitive parts of the boot process.
5. The secure environment's integrity shall be assured.
6. Only authorised access shall be granted to the secure environment, i.e. to data stored and used within, and to
functions executed within.
5.4
Void
6.0
General
The statements relating to eNBs in clause 6 apply also to RNs regarding the security between a UE and a relay node.
The statements relating to UEs and MEs in clause 6 apply also to RNs regarding the security between a relay node and a
Donor eNB and between a relay node and its MME unless stated otherwise.
6.1
6.1.1
AKA procedure
NOTE 1: Authentication data in this subclause stands for EPS Authentication vector(s).
EPS AKA is the authentication and key agreement procedure that shall be used over E-UTRAN.
A Rel-99 or later USIM application on a UICC shall be sufficient for accessing E-UTRAN, provided the USIM
application does not make use of the separation bit of the AMF in a way described in TS 33.102 [4] Annex F. Access to
E-UTRAN with a 2G SIM or a SIM application on a UICC shall not be granted.
An ME that has E-UTRAN radio capability shall support the USIM-ME interface as specified in TS 31.102 [13]
EPS AKA shall produce keying material forming a basis for user plane (UP), RRC, and NAS ciphering keys as well as
RRC and NAS integrity protection keys.
NOTE 2: Key derivation requirements of AS and NAS keys can be found in subclause 7.2.1.
The MME sends to the USIM via ME the random challenge RAND and an authentication token AUTN for network
authentication from the selected authentication vector. It also includes a KSIASME for the ME which will be used to
identify the KASME (and further keys derived from the KASME) that results from the EPS AKA procedure.
At receipt of this message, the USIM shall verify the freshness of the authentication vector by checking whether AUTN
can be accepted as described in TS 33.102[4]. If so, the USIM computes a response RES. USIM shall compute CK and
IK which are sent to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3
as described in TS 33.102 [4], and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS
Kc on USIM or in ME. If the verification fails, the USIM indicates to the ME the reason for failure and in the case of a
synchronisation failure passes the AUTS parameter (see TS 33.102 [4]).
An ME accessing E-UTRAN shall check during authentication that the "separation bit" in the AMF field of AUTN is
set to 1. The "separation bit" is bit 0 of the AMF field of AUTN.
ETSI
20
NOTE 3: This separation bit in the AMF can not be used anymore for operator specific purposes as described by
TS 33.102 [4], Annex F.
NOTE 4: If the keys CK, IK resulting from an EPS AKA run were stored in the fields already available on the
USIM for storing keys CK and IK this could lead to overwriting keys resulting from an earlier run of
UMTS AKA. This would lead to problems when EPS security context and UMTS security context were
held simultaneously (as is the case when security context is stored e.g. for the purposes of Idle Mode
Signaling Reduction). Therefore, "plastic roaming" where a UICC is inserted into another ME will
necessitate an EPS AKA authentication run if the USIM does not support EMM parameters storage.
UE shall respond with User authentication response message including RES in case of successful AUTN verification
and successful AMF verification as described above. In this case the ME shall compute KASME from CK, IK, and
serving network's identity (SN id) using the KDF as specified in clause A.2. SN id binding implicitly authenticates the
serving network's identity when the derived keys from KASME are successfully used.
NOTE 5: This does not preclude a USIM (see TS 31.102 [13]) in later releases having the capability of deriving
KASME.
Otherwise UE shall send an authentication failure message with a CAUSE value indicating the reason for failure. In
case of a synchronisation failure of AUTN (as described in TS 33.102 [4]), the UE also includes AUTS that was
provided by the USIM. Upon receipt of an authentication failure message, the MME may initiate further identity
requests and authentications towards the UE. (see TS 24.301 [9]).
The MME checks that the RES equals XRES. If so the authentication is successful. If not, depending on type of identity
used by the UE in the initial NAS message, the MME may initiate further identity requests or send an authentication
reject message towards the UE (see TS 24.301 [9]).
Figure 6.1.1-1 describes EPS AKA procedure, which is based on UMTS AKA (see TS 33.102[4]). The following keys
are shared between UE and HSS:
K is the permanent key stored on the USIM on a UICC and in the Authentication Centre AuC.
CK, IK is the pair of keys derived in the AuC and on the USIM during an AKA run. CK, IK shall be handled
differently depending on whether they are used in an EPS security context or a legacy security context, as
described in subclause 6.1.2.
As a result of the authentication and key agreement, an intermediate key KASME shall be shared between UE and MME
i.e. the ASME for EPS.
ME/USIM
MME
6.1.2
NOTE 1: Authentication data in this subclause stands for EPS Authentication vector(s).
The purpose of this procedure is to provide the MME with one or more EPS authentication vectors (RAND, AUTN,
XRES, KASME) from the user's HE (HSS) to perform user authentication. Each EPS authentication vector can be used to
authenticate the UE.
ETSI
21
NOTE 2: It is recommended that the MME fetch only one EPS authentication vector at a time as the need to perform
AKA runs has been reduced in EPS through the use of a more elaborate key hierarchy. In particular,
service requests can be authenticated using a stored KASME without the need to perform AKA.
Furthermore, the sequence number management schemes in TS 33.102, Annex C [4], designed to avoid
re-synchronisation problems caused by interleaving use of batches of authentication vectors, are only
optional. Re-synchronisation problems in EPS can be avoided, independently of the sequence number
management scheme, by immediately using an authentication vector retrieved from the HSS in an
authentication procedure between UE and MME.
MME
HE
Authentication data request
IMSI, SN identity, Network Type
Type
Authentication data response
EPS-Authentication Vector (s)
6.1.3
The user identification mechanism should be invoked by the serving network whenever the user cannot be identified by
means of a temporary identity (GUTI). In particular, it should be used when the serving network cannot retrieve the
IMSI based on the GUTI by which the user identifies itself on the radio path.
The mechanism described in figure 6.1.3-1 allows the identification of a user on the radio path by means of the
permanent subscriber identity (IMSI).
ETSI
22
ME/USIM
MME
Identity Request
Identity Response (IMSI)
6.1.4
NOTE 1: Authentication data in this subclause stands for EPS security contexts and EPS authentication vector(s).
The purpose of this procedure is to provide a newly visited MME with authentication data from a previously visited
MME within the same serving network domain.
NOTE 2: The following procedure in this clause is based on TAU procedure and it can also be applied for Attach
procedure where all the corresponding texts for "TAU" in the following procedure should be replaced
with "Attach".
The procedure is shown in Figure 6.1.4-1
MMEn
MMEo
Figure 6.1.4-1: Distribution of IMSI and authentication data within one serving domain
The procedure shall be invoked by the newly visited MMEn after the receipt of a Tracking Area update request from the
user wherein the user is identified by means of a temporary user identity GUTIo and the Tracking area identity TAIo
under the jurisdiction of a previously visited MMEo that belongs to the same serving network domain as the newly
visited MMEn.
The protocol steps are as follows:
a) The MMEn sends a message to the MMEo, this message contains GUTIo and the received TAU message.
b) The MMEo searches the user data in the database and checks the integrity protection on the TAU message.
If the user is found and the integrity check succeeds, the MMEo shall send a response back that:
i) shall include the IMSI,
ii) may include a number of unused EPS-authentication vectors ordered on a first-in / first-out basis, and
iii) may include any EPS security contexts it holds
ETSI
23
The MMEo subsequently deletes the EPS-authentication vectors and any EPS security contexts which have been
sent.
If the user cannot be identified or the integrity check fails, then the MMEo shall send a response indicating that
the user identity cannot be retrieved.
c) If the MMEn receives a response with an IMSI, it creates an entry and stores any EPS-authentication vectors and
any EPS security context that may be included.
If the MMEn receives a response indicating that the user could not be identified, it shall initiate the user
identification procedure described in clause 6.1.3 during the Initial E-UTRAN Attach procedure, or it shall reject
the TAU Request message initiated by UE during the TAU procedure (see clause 4.4.4.3 in TS24.301[9]).
The same procedure does not apply to distribution of EPS authentication data between MME and SGSN in the same
serving network domain, i.e. EPS authentication data shall not be forwarded from an MME towards an SGSN.
NOTE 3: This is due to the fact that EPS authentication data does not contain CK and IK and, hence, is not useful
for the SGSN.
6.1.5
NOTE 1: Authentication data in this subclause stands for EPS security contexts and EPS authentication vector(s).
In general, the distribution of IMSI and authentication data between MMEs belonging to different serving network
domains of shall be performed as described for the distribution of IMSI and authentication data within the same service
network domain in subclause 6.1.4. In particular, the current EPS security context data may be transferred between
MMEs belonging to different serving network domains. However, there is the following restriction:
-
Unused EPS authentication vectors, or non-current EPS security contexts, shall not be distributed between
MMEs belonging to different serving domains (PLMNs).
The same procedure does not apply to distribution of EPS authentication data between MME and SGSN in different
serving network domains, i.e. EPS authentication data shall not be forwarded from an MME towards an SGSN.
NOTE 2: This is due to the fact that EPS authentication data does not contain CK and IK and, hence, is not useful
for the SGSN.
6.1.6
This subclause applies to both distribution of UMTS authentication vectors within one serving network domain and
distribution of UMTS authentication vectors between different serving network domains. The following rules apply to
the distribution of UMTS authentication vectors between two MMEs, and between an SGSN and an MME:
a) MME to MME
UMTS authentication vectors that were previously received from an SGSN shall not be forwarded between
MME's.
b) SGSN to MME
An SGSN may forward unused UMTS authentication vectors to an MME. only if MME and SGSN are in the
same serving network domain.
c) MME to SGSN
UMTS AVs which were previously stored in the MME may be forwarded back towards the same SGSN.
UMTS AVs which were previously stored in the MME shall not be forwarded towards other SGSNs.
ETSI
6.2
24
USIM / AuC
K
CK, IK
UE / HSS
KASME
UE / MME
KNASenc
KNASint
KeNB / NH
UE / eNB
KUPint
KUPenc
KRRCint
KRRCenc
KeNB is a key derived by ME and MME from KASME or by ME and target eNB.
KNASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm
This key is derived by ME and MME from KASME, as well as an identifier for the integrity algorithm using the
KDF as specified in clause A.7.
KNASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption
algorithm. This key is derived by ME and MME from KASME, as well as an identifier for the encryption
algorithm using the KDF as specified in clause A.7.
KUPenc is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm.
This key is derived by ME and eNB from KeNB, as well as an identifier for the encryption algorithm using the
KDF as specified in clause A.7.
KUPint is a key, which shall only be used for the protection of UP traffic between RN and DeNB with a
particular integrity algorithm. This key is derived by RN and DeNB from KeNB, as well as an identifier for the
integrity algorithm using the KDF as specified in clause A.7.
ETSI
25
KRRCint is a key, which shall only be used for the protection of RRC traffic with a particular integrity
algorithm. KRRCint is derived by ME and eNB from KeNB, as well as an identifier for the integrity algorithm
using the KDF as specified in clause A.7.
KRRCenc is a key, which shall only be used for the protection of RRC traffic with a particular encryption
algorithm. KRRCenc is derived by ME and eNB from KeNB as well as an identifier for the encryption algorithm
using the KDF as specified in clause A.7.
Intermediate keys:
-
NH is a key derived by ME and MME to provide forward security as described in clause 7.2.8.
KeNB* is a key derived by ME and eNB when performing an horizontal or vertical key derivation as specified in
clause 7.2.8 using a KDF as specified in clause A5.
Figure 6.2-2 shows the dependencies between the different keys, and how they are derived from the network nodes
point of view. Figure 6.2-3 shows the corresponding relations and derivations as performed in the ME. Two dashed
inputs to a KDF means one of the inputs is used depending on the circumstances of the key derivation.
NOTE: Figures 6.2-2 and 6.2-3 do not cover the derivations at IRAT mobility (see clauses 9 and 10).
CK,IK
SN id, SQN AK
256
MME
KeNB*
KeNB
256
NH
KDF
KDF
HSS
KeNB
eNB
256
KDF
NH
eNB
256
KDF
256
KASME
NAS-int-alg,
Alg-ID
256
RRC-enc-alg, Alg-ID
RRC-int-alg, Alg-ID
256
KDF
KeNB
UP-enc-alg, Alg-ID
UP-int-alg, Alg-ID
KDF
KDF
KDF
256
Trunc
128
MME KNASenc
KDF
KDF
256
256
KNASenc
256
KNASint
KUPint
Trunc
Trunc
128
128
KNASint
KUPenc
256
256
KUPint
256
256
KRRCint
256
256
Trunc
Trunc
128
128
KUPenc
KRRCint
256
KRRCenc
256
Trunc
128
KRRCenc
Figure 6.2-2: Key distribution and key derivation scheme for EPS (in particular E-UTRAN) for network
nodes.
ETSI
26
KeNB*
ME
CK,IK
NH
KDF
KDF
SN id, SQN AK
256
KeNB
256
256
KDF
NH
256
KDF
256
KASME
RRC-int-alg, Alg-ID
256
NAS UPLINK COUNT
NAS-enc-alg,
Alg-ID
NAS-int-alg,
Alg-ID
KDF
256
eNB
256
RRC-enc-alg, Alg-ID
UP-enc-alg, Alg-ID
UP-int-alg, Alg-ID
KDF
KDF
KDF
256
Trunc
128
KNASenc
KDF
256
256
KNASenc
KDF
KNASint
KUPint
Trunc
Trunc
128
128
KNASint
KUPenc
256
256
256
KUPint
256
KRRCint
256
256
Trunc
Trunc
128
128
KUPenc
KRRCint
256
KRRCenc
256
Trunc
128
KRRCenc
Figure 6.2-3: Key derivation scheme for EPS (in particular E-UTRAN) for the ME.
As the figures 6.2-2 and 6.2-3 show, the length of KASME, KeNB and NH is 256 bits, 256-bit NAS, UP and RRC keys are
always derived from KASME and KeNB respectively. In case the encryption or integrity algorithm used to protect NAS,
UP or RRC requires a 128-bit key as input, the key is truncated and the 128 least significant bits are used. Figures 6.2-2
and 6.2-3 illustrate the truncation to 128 bits keys.
The function Trunc takes as input a 256-bit string, and returns a truncated output as defined in Annex A.7.
6.3
The key KASME shall be identified by the key set identifier eKSI. eKSI may be either of type KSIASME or of type
KSISGSN. An eKSI shall be stored in the UE and the MME together with KASME and the temporary identifier GUTI, if
available.
NOTE 1: The GUTI points to the MME where the KASME is stored.
The key set identifier KSIASME is a parameter which is associated with the KASME derived during EPS AKA
authentication. The key set identifier KSIASME is allocated by the MME and sent with the authentication request
message to the mobile station where it is stored together with the KASME. The purpose of the KSIASME is to make it
possible for the UE and the MME to identify a native KASME without invoking the authentication procedure. This is used
to allow re-use of the KASME during subsequent connection set-ups.
The key set identifier KSISGSN is a parameter which is associated with the mapped KASME derived from UMTS keys
during inter-RAT mobility, cf. clauses 9 and 10 of the present specification. The key set identifier KSISGSN is generated
in both the UE and the MME respectively when deriving the mapped KASME during idle procedures in E-UTRAN and
during handover from GERAN/UTRAN to E-UTRAN. The KSISGSN is stored together with the mapped KASME.
ETSI
27
The purpose of the KSISGSN is to make it possible for the UE and the MME to indicate the use of the mapped KASME in
inter-RAT mobility procedures (for details cf. clauses 9 and 10).
The format of eKSI shall allow a recipient of such a parameter to distinguish whether the parameter is of type 'KSIASME'
or of type 'KSISGSN'. The format shall further contain a value field. KSIASME and KSISGSN have the same format. The
value fields of KSIASME and KSISGSN are three bits each. Seven values are used to identify the key set. A value of '111' is
used by the UE to indicate that a valid KASME is not available for use. Format of eKSI is described in [9].
The value '111' in the other direction from network to mobile station is reserved.
NOTE 2: In addition to EPS security contexts, the UE may also cache UMTS security contexts. These UMTS
security contexts are identified by the KSI, as defined in TS 33.102 [4].
6.4
6.5
Each separate KASME has a distinct pair of NAS COUNTs associated with it. It is essential that the NAS COUNTs for a
particular KASME are not reset to the start values (that is the NAS COUNTs only have their start value when a new
ETSI
28
KASME is created). This prevents the security issue of using the same NAS COUNTs with the same NAS keys, e.g. key
stream re-use, in the case a UE moves back and forth between two MMEs and the same NAS keys are re-derived.
The NAS COUNTs shall only be set to the start value in the following cases:
-
for a partial native EPS NAS security context created by a successful AKA run,
NOTE:
The NAS COUNTs are not actually needed at the UE for a native context until it has successfully
received the first NAS Security Mode Command for that security context. The NAS COUNTs are not
needed at the MME until it sends the first NAS Security Mode Command for that security context. Before
the MME sends the first NAS Security Mode Command for a given partial native security context, the
MME sets the NAS COUNTs for the security context to 0. After the NAS SMC message is sent for that
partial native security context the NAS COUNTs for that partial native context are increased for each
following sent NAS message as specified in TS 24.301.
or for an EPS NAS security context created through a context mapping during a handover from
UTRAN/GERAN to E-UTRAN,
or for an EPS NAS security context created through a context mapping during idle mode mobility from
UTRAN/GERAN to E-UTRAN.
The NAS COUNTs shall not be reset during idle mode mobility or handover for an already existing native EPS NAS
security context.
The start value of NAS COUNT shall be zero (0).
ETSI
29
7.0
General
The statements relating to eNBs in clause 7 apply also to RNs regarding the security between a UE and a relay node.
The statements relating to UEs in clause 7 apply also to RNs regarding the security between a relay node and a Donor
eNB and between a relay node and its MME unless stated otherwise.
7.1
The MME shall allocate a GUTI to a UE in order to support the subscriber identity confidentiality. The GUTI is defined
in TS 23.003 [3].
S-TMSI, the shortened form of the GUTI, is used to support the subscriber identity confidentiality with more efficient
radio signalling procedures (e.g. paging and Service Request). A new GUTI shall be sent to the UE only after a
successful activation of NAS security.
7.2
7.2.1
Authentication and key setting are triggered by the authentication procedure. Authentication and key setting may be
initiated by the network as often as the network operator wishes. Key setting can occur as soon as the identity of the
mobile subscriber (i.e. GUTI or IMSI) is known by the MME. A successful run of AKA results in a new KASME that is
stored in the UE and MME.
NAS keys, KeNB and the RRC and UP keys are derived from KASME using the KDFs specified in Annex A.
The NAS keys derived from the new KASME are taken in use in the MME and the UE by means of the NAS security
mode set-up procedure (see subclause 7.2.4.4). The AS keys are taken into use with the AS security mode set-up
procedure (see subclause 7.2.4.5) or with the key change on the fly procedure (see subclause 7.2.9.2).
7.2.2
Clause 6.3 of this specification states how the key KASME is identified, namely by the key set identifier eKSI. Keys
KNASenc and KNASint in the E-UTRAN key hierarchy specified in clause 6.2, which are derived from KASME, can be
uniquely identified by eKSI together with those parameters from the set {algorithm distinguisher, algorithm identifier},
which are used to derive these keys from KASME according to Annex A.
The initial KeNB can be uniquely determined by the key set identifier, i.e. eKSI, together with the uplink NAS COUNT
are used to derive it. The intermediate key NH as defined in clause 7 can be uniquely determined by the key set
identifier, i.e. eKSI, together with the initial KeNB derived from the current NAS security context for use during the
ongoing CONNECTED state and a counter counting how many NH-derivations have already been performed from this
initial KeNB.according to Annex A.4. The next hop chaining count, NCC, represents the 3 least significant bits of this
counter.
Intermediate key KeNB*, defined in clause 7, as well as keys non-initial KeNB, KRRCint, KRRCenc, KUPint, and KUPenc in the
E-UTRAN key hierarchy specified in clause 6.2 can be uniquely identified by eKSI together with those parameters
from the set {Initial KeNB or NH, algorithm distinguisher, algorithm identifier, and sequence of PCIs and EARFCN-DLs
used in horizontal key derivations from the initial KeNB or NH}, which are used to derive these keys from KASME
according to clause 7 and clause A.7.
It is specified in the remainder of clause 7, as well as in clause 9 and 10, which of the above parameters need to be
included in a security-relevant message to allow the entity receiving the message to uniquely identify a certain key.
ETSI
7.2.3
30
All E-UTRAN keys are derived based on a KASME. The key hierarchy which is described in clause 6.2 does not allow
direct update to RRC and UP keys, but fresh RRC and UP keys are derived based on a fresh KeNB, which is bound to
certain dynamic parameters (like PCI) or fresh key derivation parameter(s) in state transitions (like NAS uplink
COUNT). This results as fresh RRC and UP keys in the eNB between inter-eNB handovers and state transitions (see
subclauses 7.2.6 to 7.2.8). The handling (creation, modification and update) of the E-UTRAN keys in the various state
transitions is described in clauses 7.2.5, 7.2.6, 7.2.7 and 7.2.8.
KASME shall be created only by running a successful AKA or by the inter-RAT procedures towards E-UTRAN (cf
clauses 9 and 10). In case the UE does not have a valid KASME, a KSIASME with value "111" shall be sent by the UE to
the network, which can initiate (re-)authentication procedure to get a new KASME based on a successful AKA
authentication.
7.2.4
7.2.4.1
a)
RRC ciphering and RRC integrity protection (to be used between UE and eNB)
NAS ciphering and NAS integrity protection (to be used between UE and MME)
An active RN and a network serving the RN shall additionally agree upon algorithms for UP integrity.
b) The serving network shall select the algorithms to use dependent on
c)
the configured allowed list of security capabilities of the currently serving network entity
The same set of ciphering and integrity algorithms shall be supported by the UE both for AS and NAS level.
d) Each selected algorithm shall be acknowledged to the UE in an integrity protected way such that the UE is
ensured that the algorithm selection was not manipulated, i.e. that the UE security capabilities were not bidden
down.
e)
The UE security capabilities the ME sent to the network shall be repeated in an integrity protected NAS level
message to the ME such that "bidding down attacks" against the UE's security capabilities can be detected by
the ME. The UE security capabilities apply to both AS and NAS level security.
f)
Separate AS and NAS level security mode command procedures are required. AS level security mode
command procedure shall configure AS security (RRC and UP) and NAS level security mode command
procedure shall configure NAS security.
a.
Both integrity protection and ciphering for RRC shall be activated within the same AS SMC
procedure, but not necessarily within the same message.
b.
User plane ciphering shall be activated at the same time as RRC ciphering.
c.
User plane integrity shall be activated at the same time as RRC ciphering. User plane integrity shall
be applied to a data radio bearer if integrity protection is configured for that data radio bearer at the
time of data radio bearer set-up.
ETSI
31
g) It shall be possible that the selected AS and NAS algorithms are different at a given point of time.
7.2.4.2
7.2.4.2.1
Each eNB shall be configured via network management with lists of algorithms which are allowed for usage. There
shall be one list for integrity algorithms, and one for ciphering algorithms. These lists shall be ordered according to a
priority decided by the operator. When AS security context is established in the eNB, the MME shall send the UE EPS
security capabilities to the eNB. The eNB shall choose the ciphering algorithm which has the highest priority from its
configured list and is also present in the UE EPS security capabilities. The eNB shall choose the integrity algorithm
which has the highest priority from its configured list and is also present in the UE EPS security capabilities. The
chosen algorithms shall be indicated to the UE in the AS SMC. The ciphering algorithm is used for ciphering of the user
plane and RRC traffic. The integrity algorithm is used for integrity protection of the RRC traffic, and, if applicable, for
the integrity protection of user plane traffic between RN and DeNB.
7.2.4.2.2
X2-handover
At handover from a source eNB over X2 to a target eNB, the source eNB shall include the UE EPS security capabilities
and ciphering and integrity algorithms used in the source cell in the handover request message. The target eNB shall
select the algorithm with highest priority from the UE EPS security capabilities according to the prioritized locally
configured list of algorithms (this applies for both integrity and ciphering algorithms). The chosen algorithms shall be
indicated to the UE in the handover command if the target eNB selects different algorithms compared to the source
eNB. If the UE does not receive any selection of integrity and ciphering algorithms it continues to use the same
algorithms as before the handover (see TS 36.331 [21]). In the path-switch message, the target eNB shall send the UE
EPS security capabilities received from the source eNB to the MME. The MME shall verify that the UE EPS security
capabilities received from the eNB are the same as the UE EPS security capabilities that the MME has stored. If there is
a mismatch, the MME may log the event and may take additional measures, such as raising an alarm.
NOTE:
7.2.4.2.3
Transferring the ciphering and integrity algorithms used in the source cell to the target eNB in the
handover request message is for the target eNB to decipher and integrity verify the
RRCReestablishmentComplete message on SRB1 in the potential RRCConnectionRe-establishment
procedure. The information is also used by the target eNB to decide if it is necessary to include a new
selection of security algorithms in the handover command.
S1-handover
At handover from a source eNB to a target eNB over S1 (possibly including an MME change and hence a transfer of the
UE security capabilities from source MME to target MME), the target MME shall send the UE EPS security capabilities
to the target eNB in the S1 AP HANDOVER REQUEST message. The target eNB shall select the algorithm with
highest priority from the UE EPS security capabilities according to the prioritized locally configured list of algorithms
(this applies for both integrity and ciphering algorithms). The chosen algorithms shall be indicated to the UE in the
handover command if the target eNB selects different algorithms compared to the source eNB. If the UE does not
receive any selection of integrity and ciphering algorithms it continues to use the same algorithms as before the
handover (see TS 36.331 [21]).
7.2.4.2.4
Intra-eNB handover
It is not required to change the AS security algorithm during intra-eNB handover. If the UE does not receive any
selection of new AS security algorithms during an intra-eNB handover, the UE continues to use the same algorithms as
before the handover (see TS 36.331 [21]).
7.2.4.3
7.2.4.3.1
Each MME shall be configured via network management with lists of algorithms which are allowed for usage. There
shall be one list for NAS integrity algorithms, and one for NAS ciphering algorithms. These lists shall be ordered
according to a priority decided by the operator.
ETSI
32
To establish the NAS security context, the MME shall choose one NAS ciphering algorithm and one NAS integrity
protection algorithm. The MME shall then initiate a NAS security mode command procedure, and include the chosen
algorithms and UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the
message to the UE (see clause 7.2.4.4). The MME shall select the NAS algorithms which have the highest priority
according to the ordered lists.
7.2.4.3.2
MME change
In case there is change of MMEs and algorithms to be used for NAS, the target MME shall initiate a NAS security
mode command procedure and include the chosen algorithms and the UE security capabilities (to detect modification of
the UE security capabilities by an attacker) in the message to the UE (see clause 7.2.4.4). The MME shall select the
NAS algorithms which have the highest priority according to the ordered lists (see 7.2.4.3.1).
NOTE: After an S1-handover with MME change a TAU procedure is executed. The same is true for an inter-RAT
handover to E-UTRAN and for both inter- and intra-RAT idle mode mobility resulting in a change of
MMEs.
7.2.4.4
The NAS SMC procedure consists of a roundtrip of messages between MME and UE. The MME sends the NAS
security mode command to the UE and the UE replies with the NAS security mode complete message.
The NAS security mode command message from MME to UE shall contain the replayed UE security capabilities, the
selected NAS algorithms, the eKSI for identifying KASME, and both NONCEUE and NONCEMME in the case of creating a
mapped context in idle mobility (see clause 9.1.2). This message shall be integrity protected (but not ciphered) with
NAS integrity key based on KASME indicated by the eKSI in the message (see figure 7.2.4.4-1).
The UE shall verify the integrity of the NAS security mode command message. This includes ensuring that the UE
security capabilities sent by the MME match the ones stored in the UE to ensure that these were not modified by an
attacker and checking the integrity protection using the indicated NAS integrity algorithm and the NAS integrity key
based on KASME indicated by the eKSI. In addition, when creating a mapped context for the case described in clause
9.1.2, the UE shall ensure the received NONCEUE is the same as the NONCEUE sent in the TAU Request and also
calculate K'ASME from CK, IK and the two nonces (see Annex A.11).
If the MME receives no response to a NAS Security Mode Command that included nonces to create a mapped context
and it wishes to try again to create the mapped context, the MME shall use the same values of NONCEUE and
NONCEMME.
If the UE receives a re-transmitted NAS Security Mode Command, i.e one containing the nonces, after it has
successfully received a previous one (and hence created a mapped EPS NAS security context), the UE shall process the
message as above, except that it is not required to re-generate the K'ASME or check the NONCE UE if it does not regenerate the K'ASME.
If the checks of the NAS Security Mode Command pass the UE shall respond with a NAS Security Mode Complete.
The UE shall delete NONCE_UE once the TAU procedure is complete.
If successfully verified, the UE shall start NAS integrity protection and ciphering/deciphering with this security context
and sends the NAS security mode complete message to MME ciphered and integrity protected The NAS security mode
complete message shall include IMEISV in case MME requested it in the NAS SMC Command message.
The MME shall de-cipher and check the integrity protection on the NAS Security Mode Complete using the keys and
algorithms indicated in the NAS Security Mode Command. NAS downlink ciphering at the MME with this security
context shall start after receiving the NAS security mode complete message. NAS uplink deciphering at the MME with
this context starts after sending the NAS security mode command message.
If any verification of the NAS security mode command is not successful in the ME, the ME shall reply with a NAS
security mode reject message (see TS 24.301 [9]). The NAS security mode reject message and all following NAS
messages shall be protected with the EPS NAS security context, i.e., the EPS NAS security context used prior to the
NAS security mode command that failed (until a new EPS NAS security context is established, e.g., via a new NAS
security mode command procedure). If no EPS NAS security context existed prior to the NAS security mode command,
the NAS security mode reject message cannot be protected.
ETSI
NOTE:
33
If the uplink NAS COUNT will wrap around by sending the security mode reject message, the UE
releases the NAS connection as specified in TS 24.301 [9] instead of sending the security mode reject
message.
ME
MME
Start integrity
protection
NAS Security Mode Command (eKSI, UE sec capabilities,
Ciphering algorithm, Integrity algorithm,
[IMEISV request,] [NONCEUE, NONCEMME,] NAS-MAC)
Start uplink
deciphering
7.2.4.5
The AS SMC procedure consists of a roundtrip of messages between eNB and UE. The eNB sends the AS security
mode command to the UE and the UE replies with the AS security mode complete message. See figure 7.2.4.5-1.
The AS security mode command message from eNB to UE shall contain the selected AS algorithms. This message shall
be integrity protected with RRC integrity key based on the current KASME.
The AS security mode complete message from UE to eNB shall be integrity protected with the selected RRC algorithm
indicated in the AS security mode command message and RRC integrity key based on the current KASME.
RRC and UP downlink ciphering (encryption) at the eNB shall start after sending the AS security mode command
message. RRC and UP uplink deciphering (decryption) at the eNB shall start after receiving and successful verification
of the AS security mode complete message.
RRC and UP uplink ciphering (encryption) at the UE shall start after sending the AS security mode complete message.
RRC and UP downlink deciphering (decryption) at the UE shall start after receiving and successful verification of the
AS security mode command message
If any control of the AS security mode command is not successful in the ME, the ME shall reply with an unprotected
security mode failure message (see TS 36.331[21]).
AS security mode command always changes the AS keys.
ETSI
34
ME
eNB
Start RRC
integrity protection
Start RRC/UP
uplink ciphering
7.2.4a
UEs that are in limited service mode (LSM) and that cannot be authenticated by the MME (for whatever reason) may
still be allowed to establish emergency calls by sending the emergency attach request message. It shall be possible to
configure whether the MME allows unauthenticated UEs in LSM to establish bearers for emergency calls or not. If an
MME allows unauthenticated UEs in LSM to establish bearers for an emergency call, the MME shall for the NAS
protocol use EIA0 and EEA0 as the integrity and ciphering algorithm respectively.
If the MME allows an unauthenticated UE in LSM to establish bearers for emergency calls after it has received the
emergency attach request message from the UE, the MME shall:
-
Select EIA0 and EEA0 as the NAS algorithms and signal this to the UE via the NAS security mode command
procedure when activating the EPS NAS security context.
Set the UE EPS security capabilities to only contain EIA0 and EEA0 when sending these to the eNB in the
following messages:
-
S1 HANDOVER REQUEST
NOTE 1: As a result of that the MME only sends a UE EPS security capability containing EIA0 and EEA0 to the
eNB when selecting EIA0 for NAS integrity protection is that the eNB is only capable of selecting EIA0
for AS integrity protection and EEA0 for AS confidentiality protection. That is, if EIA0 is used for NAS
integrity protection, then EIA0 will always be used for AS integrity protection.
The rules for when the MME shall select EIA0 for NAS integrity protection, and when the UE shall accept a NAS
security mode command selecting EIA0 for NAS integrity protection depends on whether the UE and MME can be
certain that no EPS NAS security context can be established. The rules for determining this is defined in clause 15 of
this specification. If the MME has selected EIA0 as the NAS integrity protection algorithm, the UE shall accept
selection of EIA0 as the AS integrity protection algorithm. Selection of AS integrity protection algorithm happens via
the AS security mode command procedure or via a handover command. The UE shall under no other circumstances
accept selection of EIA0 as the AS integrity protection algorithm.
NOTE 2: A Rel-8 eNB that is the target eNB of a handover, where EIA0 is the only integrity protection algorithm
in the UE's EPS security capabilities, rejects the handover since the eNB does not support EIA0.
ETSI
7.2.5
35
7.2.5.1
Transition to EMM-DEREGISTERED
There are different reasons for transition to the EMM-DEREGISTERED state. If a NAS messages leads to state
transition to EMM-DEREGISTERED, it shall be security protected by the current EPS NAS security context (mapped
or native), if such exists in the UE or MME.
NOTE:
The present specification only considers the states EMM-DEREGISTERED and EMM-REGISTERED
and transitions between these two states. Other specifications define additional EMM states (see, e.g.,
TS 24.301 [9]).
the current native EPS NAS security context (as in clause 6.1.1), which should remain stored in the
MME and UE, and
any unused authentication vectors, which may remain stored in the MME.
ii. If the reason is not switch off then MME and UE shall keep all the remaining authentication data.
b. MME-initiated
i. Explicit: all the remaining authentication data shall be kept in the UE and MME if the detach type is reattach.
ii. Implicit: all the remaining authentication data shall be kept in the UE and MME.
c. HSS-initiated: If the message is "subscription withdrawn" then all the remaining authentication data shall be
removed from the UE and MME.
3. TAU reject: There are various reasons for TAU reject. The action to be taken shall be as given in TS 24.301.
Storage of the full native EPS NAS security context, excluding the UE security capabilities and the keys KNASint and
KNASenc, in the UE when the UE transitions to EMM-DEREGISTERED state is done as follows:
a)
If the ME does not have a full native EPS NAS security context in volatile memory, any existing native EPS
NAS security context stored on the UICC or in non-volatile memory of the ME shall be marked as invalid.
b) If the USIM supports EMM parameters storage, then the ME shall store the full native EPS NAS security
context parameters on the USIM (except for KNASenc and KNASint), mark the native EPS NAS security context on
the USIM as valid, and not keep any native EPS NAS security context in non-volatile ME memory.
c)
If the USIM does not support EMM parameters storage, then the ME shall store the full native EPS NAS
security context (except for KNASenc and KNASint) in a non-volatile part of its memory, and mark the native EPS
NAS security context in its non-volatile memory as valid.
ETSI
36
For the case that the MME or the UE enter EMM-DEREGISTERED state without using any of the above procedures,
the handling of the remaining authentication data shall be as specified in TS 24.301 [9].
7.2.5.2
7.2.5.2.1
When starting the transition away from EMM-DEREGISTERED state with the intent to eventually transitioning to
EMM-REGISTERED state, if no current EPS NAS security context is available in the ME, the ME shall retrieve native
EPS NAS security context stored on the USIM if the USIM supports EMM parameters storage and if the stored native
EPS NAS security context on the USIM is marked as valid. If the USIM does not support EMM parameters storage the
ME shall retrieve stored native EPS NAS security context from its non-volatile memory if the native EPS NAS security
context is marked as valid. The ME shall derive the KNASint and KNASenc after retrieving the stored EPS NAS security
context; see clause A.7 on NAS key derivation. The retrieved native EPS NAS security context with the derived KNASint
and KNASenc shall then become the current EPS NAS security context.
When the ME is transitioning away from EMM-DEREGISTERED state with the intent to eventually transitioning to
EMM-REGISTERED state, if the USIM supports EMM parameters storage, the ME shall mark the stored EPS NAS
security context on the USIM as invalid. If the USIM does not support EMM parameters storage, the ME shall mark the
stored EPS NAS security context in its non-volatile memory as invalid.
If the ME uses an EPS NAS security context to protect NAS messages, the NAS COUNT values are updated in the
volatile memory of the ME. If the attempt to transition away from EMM-DEREGISTERED state with the intent to
eventually transitioning to EMM-REGISTERED state fails, the ME shall store the (possibly updated) EPS NAS
security context on the USIM or non-volatile ME memory and mark it as valid.
NOTE:
The present specification only considers the states EMM-DEREGISTERED and EMM-REGISTERED
and transitions between these two states. Other specifications define additional EMM states (see, e.g.,
TS 24.301 [9]).
7.2.5.2.2
The UE shall transmit a NAS Attach Request message. This message is integrity protected and for the case that the EPS
NAS security context used by the UE is non-current in the MME, the rules in clause 6.4 apply. Furthermore provided
there is no NAS SMC procedure before the AS SMC the NAS COUNT of the Attach Request message shall be used to
derive the KeNB with the KDF as specified in clause A.3. As a result of the NAS Attach Request, the eNB shall send an
AS SMC to the UE to activate AS security. The KeNB used, is derived in the current EPS NAS security context.
When the UE receives the AS SMC without having received a NAS Security Mode Command after the Attach Request,
it shall use the NAS COUNT of the Attach Request message (i.e. the uplink NAS COUNT) that triggered the AS SMC
to be sent as freshness parameter in the derivation of the KeNB. From this KeNB the RRC protection keys and the UP
protection keys shall be derived as described in subclause 7.2.1.
The same procedure for refreshing KeNB can be used regardless of the fact if the UE is connecting to the same MME to
which it was connected previously or to a different MME. In case UE connects to a different MME and this MME
selects different NAS algorithms, the NAS keys have to be re-derived in the MME with the new algorithm IDs as input
using the KDF as specified in clause A.7.
In addition, there is a need for the MME to send a NAS SMC to the UE to indicate the change of NAS algorithms and
to take the re-derived NAS keys into use. The UE shall assure that the NAS keys used to verify the integrity of the NAS
SMC are derived using the algorithm ID specified in the NAS SMC. The NAS SMC Command and NAS SMC
Complete messages are protected with the new NAS keys.
If there is a NAS Security Mode Command after the Attach Request but before the AS SMC, the UE and MME use the
NAS COUNT of the most recent NAS Security Mode Complete (i.e. the uplink NAS COUNT) and the related KASME as
the parameter in the derivation of the KeNB. From this KeNB the RRC protection keys and the UP protection keys are
derived as described in subclause 7.2.1.
ETSI
7.2.5.2.3
37
If in the process described in clause 7.2.5.2.2, there is no full native EPS NAS security context available in the MME
(i.e. either the UE has sent an unprotected Attach Request message or the UE has protected the Attach Request message
with a current native EPS security context which no longer is stored in the MME) an EPS AKA run is required. If there
is a full native EPS NAS security context available in the MME, then the MME may (according to MME policy) decide
to run a new EPS AKA and a NAS SMC procedure (which activates the new EPS NAS security context based on the
KASME derived during the EPS AKA run) after the Attach Request but before the corresponding AS SMC. The NAS
(uplink and downlink) COUNTs are set to start values, and the start value of the uplink NAS COUNT shall be used as
freshness parameter in the KeNB derivation from the fresh KASME (after AKA) when UE receives AS SMC the KeNB is
derived from the current EPS NAS security context, i.e., the fresh KASME is used to derive the KeNB The KDF as
specified in clause A.3 shall be used to derive the KeNB.
NOTE:
Using the start value for the uplink NAS COUNT in this case cannot lead to the same combination of
KASME and NAS COUNT being used twice. This is guaranteed by the fact that the first integrity protected
NAS message the UE sends to the MME after AKA is the NAS SMC complete message.
The NAS SMC complete message shall include the start value of the uplink NAS COUNT that is used as freshness
parameter in the KeNB derivation and the KASME is fresh. After an AKA, a NAS SMC needs to be sent from the MME to
the UE in order to take the new NAS keys into use. Both NAS SMC and NAS SMC Complete messages are protected
with the new NAS keys.
7.2.6
7.2.6.1
The UE sends an initial NAS message to initiate transition from ECM-IDLE to ECM-CONNECTED state [9]. On
transitions to ECM-CONNECTED, the MME should be able to check whether a new authentication is required, e.g.
because of prior inter-provider handover.
When cryptographic protection for radio bearers is established RRC protection keys and UP protection keys shall be
generated as described in subclause 7.2.1 while KASME is assumed to be already available in the MME.
The initial NAS message shall be integrity protected by the current EPS NAS security context if such exists. If no
current EPS NAS security context exists the ME shall signal "no key available" in the initial NAS message.
KASME may have been established in the MME as a result of an AKA run, or as a result of a security context transfer
from another MME during handover or idle mode mobility. When the eNB releases the RRC connection the UE and the
eNB shall delete the keys they store such that state in the network for ECM-IDLE state UEs will only be maintained in
the MME.
7.2.6.2
The procedure the UE uses to establish cryptographic protection for radio bearers is initiated by an (extended) NAS
Service Request message or TAU Request message with the active flag set from the UE to the MME. The MME may
initiate the procedure to establish cryptographic protection for radio bearers when the "active flag" is not set in the TAU
request and there is pending downlink UP data or pending downlink signalling.
Upon receipt of the NAS message, if the MME does not require a NAS SMC procedure before initiating the S1-AP
procedure INITIAL CONTEXT SETUP, the MME shall derive key KeNB as specified in subclause A.3 using the NAS
COUNT [9] corresponding to the NAS message and the KASME of the current EPS NAS security context. The MME
shall further initialize the value of the Next hop Chaining Counter (NCC) to zero. The MME shall further derive a next
hop parameter NH as specified in subclause A.4 using the newly derived KeNB and the KASME as basis for the derivation.
The MME shall further set the the value of the Next hop Chaining Counter (NCC) to one. This fresh {NH, NCC=1}
pair shall be stored in the MME and shall be used for the next forward security key derivation. The MME shall
communicate the KeNB to the serving eNB in the S1-AP procedure INITIAL CONTEXT SETUP. The UE shall derive
the KeNB from the KASME of the current EPS NAS security context.
As a result of the (extended) NAS Service Request or TAU procedure, radio bearers are established, and the eNB sends
an AS SMC to the UE. When the UE receives the AS SMC without having received a NAS Security Mode Command,
it shall use the NAS uplink COUNT of the NAS message that triggered the AS SMC as freshness parameter in the
ETSI
38
derivation of the KeNB. The KDF as specified in Annex A.3 shall be used for the KeNB derivation using the KASME of the
current EPS NAS security context. The UE shall further derive the NH parameter from the newly derived KeNB and the
KASME in the same way as the MME. From the KeNB the RRC protection keys and the UP protection keys are derived by
the UE and the eNB as described in subclause 6.2.
NOTE:
At the UE, the NH derivation associated with NCC=1 could be delayed until the first handover
performing vertical key derivation.
If the NAS procedure establishing radio bearers contains an EPS AKA run (which is optional), the NAS uplink and
downlink COUNT for the new KASME shall be set to the start values (i.e. zero). If the NAS procedure establishing radio
bearers contains a NAS SMC (which is optional), the value of the uplink NAS COUNT from the most recent NAS
Security Mode Complete shall be used as freshness parameter in the KeNB derivation from fresh KASME of the current
EPS NAS security context when executing an AS SMC. The KDF as specified in Annex A.3 shall be used for the KeNB
derivation also in this case.
7.2.6.3
On ECM-CONNECTED to ECM-IDLE transitions the eNB does no longer need to store state information about the
corresponding UE.
In particular, on ECM-CONNECTED to ECM-IDLE transitions:
-
The eNB and the UE shall release all radio bearers and delete the AS security context.
MME and the UE shall keep the EPS NAS security context stored with the following exception: if there is a new
and an old KASME according to rules 3, 4, 8 or 9 in clause 7.2.10 of this specification then the MME and the UE
shall delete the old KASME and the corresponding eKSI. The MME shall delete NH and NCC.
7.2.7
Before the UE can initiate the TAU procedure, the UE needs to transition to ECM-CONNECTED state. The UE shall
use the current EPS security context to protect the TAU Request and include the corresponding GUTI and eKSI value.
The TAU Request shall be integrity-protected, but not confidentiality-protected. UE shall use the current EPS security
context algorithms to protect the TAU Request message. For the case that this security context is non-current in the
MME, the rules in clause 6.4 apply.
If the "active flag" is set in the TAU request message or the MME chooses to establish radio bearers when there is
pending downlink UP data or pending downlink signalling, radio bearers will be established as part of the TAU
procedure and a KeNB derivation is necessary.If there was no subsequent NAS SMC, the uplink NAS COUNTof the
TAU request message sent from the UE to the MME is used as freshness parameter in the KeNB derivation using the
KDF as specified in clause A.3. The TAU request shall be integrity protected.
In the case an AKA is run successfully, the uplink and downlink NAS COUNT shall be set to the start values (i.e. zero).
In the case source and target MME use different NAS algorithms, the target MME re-derives the NAS keys from KASME
with the new algorithm identities as input and provides the new algorithm identifiers within a NAS SMC. The UE shall
assure that the NAS keys used to verify the integrity of the NAS SMC are derived using the algorithm identity specified
in the NAS SMC.
If there is a NAS Security Mode Command after the TAU Request but before the AS SMC, the UE and MME use the
NAS COUNT of the most recent NAS Security Mode Complete (i.e. the uplink NAS COUNT) and the related KASME as
the parameter in the derivation of the KeNB. From this KeNB the RRC protection keys and the UP protection keys are
derived as described in subclause 7.2.1.
7.2.8
7.2.8.1
7.2.8.1.1
ETSI
39
ETSI
7.2.8.1.2
40
A NAS aspect that needs to be considered is possible NAS algorithm change at MME change that could occur at a
handover. At an eNB handover with MME relocation, there is the possibility that the source MME and the target MME
do not support the same set of NAS algorithms or have different priorities regarding the use of NAS algorithms. In this
case, the target MME re-derives the NAS keys from KASME using the NAS algorithm identities as input to the NAS key
derivation functions (see clause A.7) and sends NAS SMC. All inputs, in particular the KASME, will be the same in the
re-derivation except for the NAS algorithm identity.
In case the target MME decides to use NAS algorithms different from the ones used by the source MME, a NAS SMC
including eKSI (new or current value depending on whether AKA was run or not) shall be sent from the MME to the
UE.
This NAS Key and algorithm handling also applies to other MME changes e.g. TAU with MME changes.
NOTE:
It is per operator's policy how to configure selection of handover types. Depending on an operator's
security requirements, the operator can decide whether to have X2 or S1 handovers for a particular eNB
according to the security characteristics of a particular eNB.
7.2.8.2
Void
7.2.8.3
As outlined in subclause 7.2.8.1, whenever a fresh KeNB is calculated from the KASME (as described in Annex A.3), the
MME shall transfer the KeNB to the serving eNB in a message modifying the security context in the eNB. The MME and
the UE shall also compute the NH parameter from the KASME and the fresh KeNB as described in Annex A.4 according to
the rules in clause 7.2.9.2. An NCC value 1 is associated with the NH parameter derived from the fresh KeNB and NCC
value 0 with the KeNB. The UE shall compute KeNB and NH in the same way as the MME. From the newly computed
KeNB, the eNB and the UE shall compute the temporary KeNB* and then the final KeNB from that KeNB* as described in
clause 7.2.9.2.
NOTE 1: Since MME does not send the NH value to eNB in S1 UE CONTEXT MODIFICATION REQUEST, the
NH value associated with the NCC value one can not be used in the next X2 handover or the next intraeNB handover. So for the next X2 handover or the next intra-eNB handover the horizontal key derivation
(see Figure 7.2.8.1-1) will apply.
NOTE 2: One of the rules specified for the MME in subclause 7.2.8.4 of this specification states that the MME
always computes a fresh {NH, NCC} pair that is given to the target eNB. An implication of this is that the
first {NH, NCC} pair, i.e., the one with NCC equal to 1 will never be used to derive a KeNB. It only serves
as an initial value for the NH chain.
NOTE 3: At the UE, the NH derivation associated with NCC=1 could be delayed until the first handover performing
vertical key derivation.
7.2.8.4
7.2.8.4.1
When the eNB decides to perform an intra-eNB handover it shall derive KeNB* as in Annex A.5 using target PCI, its
frequency EARFCN-DL, and either NH or the current KeNB depending on the following criteria: the eNB shall use the
NH for deriving KeNB* if an unused {NH, NCC} pair is available in the eNB (this is referred to as a vertical key
derivation), otherwise if no unused {NH, NCC} pair is available in the eNB, the eNB shall derive KeNB* from the
current KeNB (this is referred to as a horizontal key derivation).
The eNB shall use the KeNB* as the KeNB after handover. The eNB shall send the NCC used for KeNB* derivation to UE
in HO Command message.
7.2.8.4.2
X2-handover
As in intra-eNB handovers, for X2 handovers the source eNB shall perform a vertical key derivation in case it has an
unused {NH, NCC} pair. The source eNB shall first compute KeNB* from target PCI, its frequency EARFCN-DL, and
ETSI
41
either from currently active KeNB in case of horizontal key derivation or from the NH in case of vertical key derivation
as described in Annex A.5.
Next the source eNB shall forward the {KeNB*, NCC} pair to the target eNB. The target eNB shall use the received
KeNB* directly as KeNB to be used with the UE. The target eNB shall associate the NCC value received from source eNB
with the KeNB. The target eNB shall include the received NCC into the prepared HO Command message, which is sent
back to the source eNB in a transparent container and forwarded to the UE by source eNB.
When the target eNB has completed the handover signaling with the UE, it shall send a S1 PATH SWITCH REQUEST
to the MME. Upon reception of the S1 PATH SWITCH REQUEST, the MME shall increase its locally kept NCC value
by one and compute a new fresh NH by using the KASME and its locally kept NH value as input to the function defined
in Annex A.4. The MME shall then send the newly computed {NH, NCC} pair to the target eNB in the S1 PATH
SWITCH REQUEST ACKNOWLEDGE message. The target eNB shall store the received {NH, NCC} pair for further
handovers and remove other existing unused stored {NH, NCC} pairs if any.
NOTE:
7.2.8.4.3
Because the path switch message is transmitted after the radio link handover, it can only be used to
provide keying material for the next handover procedure and target eNB. Thus, for X2-handovers key
separation happens only after two hops because the source eNB knows the target eNB keys. The target
eNB can immediately initiate an intra-cell handover to take the new NH into use once the new NH has
arrived in the S1 PATH SWITCH REQUEST ACKNOWLEDGE.
S1-Handover
Upon reception of the HANDOVER REQUIRED message the source MME shall increase its locally kept NCC value
by one and compute a fresh NH from its stored data using the function defined in Annex A.4. The source MME shall
store that fresh pair and send it to the target MME in the S10 FORWARD RELOCATION REQUEST message. The
S10 FORWARD RELOCATION REQUEST message shall in addition contain the KASME that is currently used to
compute {NH, NCC} pairs and its corresponding eKSI.
The target MME shall store locally the {NH, NCC} pair received from the source MME.
The target MME shall then send the received {NH, NCC} pair to the target eNB within the S1 HANDOVER
REQUEST.
Upon receipt of the S1 HANDOVER REQUEST from the target MME, the target eNB shall compute the KeNB to be
used with the UE by performing the key derivation defined in Annex A.5 with the fresh{NH, NCC} pair in the S1
HANDOVER REQUEST and the target PCI and its frequency EARFCN-DL. The target eNB shall associate the NCC
value received from MME with the KeNB. The target eNB shall include the NCC value from the received {NH, NCC}
pair into the HO Command to the UE and remove any existing unused stored {NH, NCC} pairs.
NOTE: The source MME may be the same as the target MME in the description in this subclause. If so the single
MME performs the roles of both the source and target MME, i.e. the MME calculates and stores the fresh
{NH, NCC} pair and sends this to the target eNB.
For S1-handover, the source eNB shall include AS algorithms used in the source cell (ciphering and integrity
algorithms) in the source to target transparent container that shall be sent to the target eNB. The AS algorithms used by
in the source cell are provided to the target eNB so that it can decipher and integrity verify the
RRCReestablishmentComplete message on SRB1 in the potential RRCConnectionRe-establishment procedure.
7.2.8.4.4
UE handling
ETSI
7.2.9
7.2.9.1
42
Key-change-on-the fly
General
7.2.9.2
KeNB re-keying
The KeNB re-keying procedure is initiated by the MME. It may be used under the following conditions:
-
after a successful AKA run with the UE as part of activating a partial native EPS security context, or
as part of re-activating a non-current full native EPS security context after handover from GERAN or UTRAN
according to subclauses 9.2.2.1 and 10.3.2, or
NOTE 1: To perform a key change on-the-fly of the entire key hierarchy, the MME has to change the EPS NAS
security context before changing the AS security context..
In order to be able to re-key the KeNB, the MME requires a fresh uplink NAS COUNT from a successful NAS SMC
procedure with the UE. In the case of creating a new KeNB from the current KASME a NAS SMC procedure shall be run
first to provide this fresh uplink NAS COUNT. This NAS SMC procedure does not have to change other parameters in
the current EPS NAS security context. T he MME derives the new KeNB using the key derivation function as specified
in Annex A.3 using the KASME and the uplink NAS COUNT used in the most recent NAS Security Mode Complete
message. The KeNB is sent to the eNB in an S1 AP UE CONTEXT MODIFICATION REQUEST message triggering the
eNB to perform the re-keying. The eNB runs the key-change-on-the-fly procedure with the UE. During this procedure
the eNB shall indicate to the UE that a key change on-the-fly is taking place. The procedure used is based on an intracell handover, and hence the same KeNB derivation steps shall be taken as in a normal handover procedure.
When the UE receives an indication that the procedure is a key change on-the-fly procedure, the UE shall derive a
temporary KeNB by applying the key derivation function as specified in Annex A.3 using the KASME from the current
EPS NAS security context and the uplink NAS COUNT in the most recent NAS Security Mode Complete message.
From this temporary KeNB the UE shall derive the KeNB* as normal (see clause A.5). The eNB shall take the KeNB it
received from the MME, which is equal to the temporary KeNB, as basis for its KeNB* derivations. From this step
onwards, the key derivations continue as in a normal handover.
If the AS level re-keying fails, then the MME shall complete another NAS security mode procedure before initiating a
new AS level re-keying. This ensures that a fresh KeNB is used.
ETSI
43
UE and MME shall use NH derived from old KASME before the context modification is complete, i.e. for the UE
when it sends the RRC Connection Reconfiguration Complete, and for the MME when it receives the UE
CONTEXT MODIFICATION RESPONSE. In particular, the MME shall send an NH derived from old KASME in
the S1AP HANDOVER RESOURCE ALLOCATION, S10 FORWARD RELOCATION, and S1AP PATH
SWITCH REQUEST ACKNOWLEDGE messages before the context modification is complete.
The eNB shall delete any old NH upon completion of the context modification.
The UE and MME shall delete any old NH upon completion of the context modification. After the completion of
the context modification, the UE and the MME shall derive any new NH parameters from the KeNB calculated
from the uplink NAS COUNT and the KASME used to calculate that KeNB according to Annex A.4.
7.2.9.3
KeNB refresh
This procedure is based on an intra-cell handover. The KeNB chaining that is performed during a handover ensures that
the KeNB is re-freshed w.r.t. the RRC and UP COUNT after the procedure.
7.2.9.4
After an AKA has taken place, new NAS keys from a new KASME shall be derived, according to Annex A.7.
To re-activate a non-current full native EPS security context after handover from GERAN or UTRAN, cf. clause 9.2.2
B step 7, the UE and the MME take the NAS keys into use by running a NAS SMC procedure according to clause
7.2.4.5.
MME shall activate fresh NAS keys from an EPS AKA run or activate native security context with sufficiently low
NAS COUNT values before the NAS uplink or downlink COUNT wraps around with the current security context.
7.2.10
Concurrent runs of security procedures may, in certain situations, lead to mismatches between security contexts in the
network and the UE. In order to avoid such mismatches, the following rules shall be adhered to:
1. MME shall not initiate any of the S1 procedures Initial Context Setup or UE Context Modification including a
new KeNB towards a UE if a NAS Security Mode Command procedure is ongoing with the UE.
2. The MME shall not initiate a NAS Security Mode Command towards a UE if one of the S1 procedures Initial
Context Setup or UE Context Modification including a new KeNB is ongoing with the UE.
3. When the UE has cryptographically protected radio bearers established and the MME has initiated a NAS SMC
procedure in order to take a new KASME into use, the MME shall continue to include AS security context
parameters based on the old KASME in the HANDOVER REQUEST or PATH SWITCH REQUEST
ACKNOWLEDGE message, until the MME takes a KeNB derived from the new KASME into use by means of a
UE Context Modification procedure.
4. When the UE has cryptographically protected radio bearers established and has received a NAS SMC message in
order to take a new KASME into use, the UE shall continue to use AS security context parameters based on the old
KASME in handover until the network indicates in an RRCConnectionReconfiguration procedure to take a KeNB
derived from the new KASME into use.
5. The source eNB shall reject an S1 UE Context Modification Request when the eNB has initiated, but not yet
completed, an inter-eNB handover. When a RRCConnectionReconfiguration procedure triggered by a UE
Context Modification is ongoing the source eNB shall wait for the completion of this procedure before initiating
any further handover procedure.
6. When the MME has initiated a NAS SMC procedure in order to take a new KASME into use and receives a request
for an inter-MME handover or an inter-RAT handover from the serving eNB, the MME shall wait for the
completion of the NAS SMC procedure before sending an S10 FORWARD RELOCATION message or
initiating an inter-RAT handover.
7. When the MME has initiated a UE Context Modification procedure in order to take a new KeNB into use and
receives a request for an inter-MME handover from the serving eNB, the MME shall wait for the (successful or
ETSI
44
unsuccessful) completion of the UE Context Modification procedure before sending an S10 FORWARD
RELOCATION message.
8. When the MME has successfully performed a NAS SMC procedure taking a new KASME into use, but has not yet
successfully performed a UE Context Modification procedure, which takes a KeNB derived from the new KASME
into use, the MME shall include both the old KASME with the corresponding eKSI, NH, and NCC, and a full EPS
NAS security context based on the new KASME in the S10 FORWARD RELOCATION message.
9. When an MME receives a S10 FORWARD RELOCATION message including both the old KASME with the
corresponding eKSI, NH, and NCC, and a full EPS NAS security context based on the new KASME the MME
shall use the new KASME in NAS procedures, but shall continue to include AS security context parameters based
on the old KASME in the HANDOVER REQUEST or PATH SWITCH REQUEST ACKNOWLEDGE message
until the completion of a UE Context Modification procedure, which takes a KeNB derived from the new KASME
into use.
10. Once the source MME has sent an S10 FORWARD RELOCATION message to the target MME at an interMME handover, the source MME shall not send any downlink NAS messages to the UE until it is aware that the
handover has either failed or has been cancelled.
7.3
UP security mechanisms
7.3.1
UP confidentiality mechanisms
The user plane data is ciphered by the PDCP protocol between the UE and the eNB as specified in TS 36.323 [12]..
The use and mode of operation of the 128-EEA algorithms are specified in Annex B.
The input parameters to the 128-bit EEA algorithms as described in Annex B are an 128-bit cipher key KUPenc as KEY, a
5-bit bearer identity BEARER which value is assigned as specified by TS 36.323 [12], the 1-bit direction of
transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction
dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.
7.3.2
UP integrity mechanisms
This subclause applies only to the user plane on the Un interface between RN and DeNB:
The user plane data is integrity-protected by the PDCP protocol between the RN and the DeNB as specified in TS
36.323 [12]. Replay protection shall be activated when integrity protection is activated. Replay protection shall ensure
that the receiver only accepts each particular incoming PDCP COUNT value once using the same AS security context.
The use and mode of operation of the 128-EIA algorithms are specified in Annex B.
The input parameters to the 128-bit EIA algorithms as described in Annex B are a 128-bit integrity key KUPint as KEY, a
5-bit bearer identity BEARER which value is assigned as specified by TS 36.323 [12], the 1-bit direction of
transmission DIRECTION, and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds
to the 32-bit PDCP COUNT.
The supervision of failed UP integrity checks shall be performed both in the RN and the DeNB. In case of failed
integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message
shall be discarded. This can happen on the DeNB side or on the RN side.
NOTE:
ETSI
45
7.4
7.4.1
RRC integrity protection shall be provided by the PDCP layer between UE and eNB and no layers below PDCP shall be
integrity protected. Replay protection shall be activated when integrity protection is activated (except for when the
selected integrity protection algorithm is EIA0, see Annex B). Replay protection shall ensure that the receiver only
accepts each particular incoming PDCP COUNT value once using the same AS security context.
The use and mode of operation of the 128-EIA algorithms are specified in Annex B.
The input parameters to the 128-bit EIA algorithms as described in Annex B are an 128-bit integrity key KRRCint as
KEY,, a 5-bit bearer identity BEARER which value is assigned as specified by TS 36.323 [12], the 1-bit direction of
transmission DIRECTION and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds
to the 32-bit PDCP COUNT.
The supervision of failed RRC integrity checks shall be performed both in the ME and the eNB. In case of failed
integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message
shall be discarded. This can happen on the eNB side or on the ME side.
NOTE: This text does not imply that the concerned message is silently discarded. In fact, TS 36.331 [21] specifies
that the UE shall trigger a recovery procedure upon detection of a failed RRC integrity check. When the
cause for integrity protection failure is not a context mismatch, such as a key or HFN mismatch, the run
of a recovery procedure unnecessarily adds load to the system. However, in the absence of a means for
the UE to reliably detect the cause of an integrity protection failure and the fact that the only identified
consequence of an active attack is limited to non-persistent DoS effects, priority was given to a procedure
allowing recovery from the deadlock caused by a context mismatch.
7.4.2
RRC confidentiality protection is provided by the PDCP layer between UE and eNB.
The use and mode of operation of the 128-EEA algorithms are specified in Annex B.
The input parameters to the 128-bit EEA algorithms as described in Annex B are an 128-bit cipher Key KRRCenc as KEY,
a 5-bit bearer identity BEARER which corresponds to the radio bearer identity, the 1-bit direction of transmission
DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction dependent 32-bit
input COUNT which corresponds to the 32-bit PDCP COUNT.
7.4.3
The KeNB* and token calculation at handover preparation are cell specific instead of eNB specific. At potential RRC
Connection re-establishment (e.g, in handover failure case), the UE may select a cell different from the target cell to
initiate the re-establishment procedure. To ensure that the UE RRCConnectionRe-establishment attempt is successful
when the UE selects another cell under the control of the target eNB at handover preparation, the serving eNB could
prepare multiple KeNB*s and tokens for multiple cells which are under the control of the target eNB. The serving eNB
may prepare cells belonging to the serving eNB itself.
The preparation of these cells includes sending security context containing KeNB*s and tokens for each cell to be
prepared, as well as the corresponding NCC, the UE EPS security capabilities, and the security algorithms used in the
source cell for computing the token, to the target eNB. The source eNB shall derive the KeNB*s as described in Annex
A.5 based on the corresponding target cells physical cell ID and frequency EARFCN-DL.
In order to calculate the token, the source eNB shall use the negotiated EIA-algorithm from the AS Security context
from the source eNB with the following inputs: source C-RNTI, source PCI and target Cell-ID as defined by
VarShortMAC-Input in TS 36.331 [21], where source PCI and source C-RNTI are associated with the cell the UE last
had an active RRC connection with and target cell ID is the identity of the target cell where the
RRCConnectionReestablishmentRequest is sent to.
- KEY shall be set to KRRCint of the source cell;
ETSI
46
7.5
The following procedure is used optionally by the eNB to periodically perform a local authentication. At the same time,
the amount of data sent during the AS connection is periodically checked by the eNB and the UE for both up and down
streams. If UE receives the Counter Check request, it shall respond with Counter Check Response message.
The eNB is monitoring the PDCP COUNT values associated to each radio bearer. The procedure is triggered whenever
any of these values reaches a critical checking value. The granularity of these checking values and the values
themselves are defined by the visited network. All messages in the procedure are integrity protected.
ETSI
47
UE
eNB
1. Counter Check
8.0
General
The statements relating to UEs in clause 8 apply also to RNs regarding the security between a relay node and its MME.
8.1
Integrity protection for NAS signalling messages shall be provided as part of the NAS protocol.
8.1.1
Input parameters to the NAS 128-bit integrity algorithms as described in Annex B are an 128-bit integrity key KNASint as
KEY, an 5-bit bearer identity BEARER which shall equal the constant value 0x00, the direction of transmission
DIRECTION, and a bearer specific, time and direction dependent 32-bit input COUNT which is constructed as follows:
COUNT := 0x00 || NAS OVERFLOW || NAS SQN
Where
-
NAS OVERFLOW is a 16-bit value which is incremented each time the NAS SQN is incremented from the
maximum value.
NAS SQN is the 8-bit sequence number carried within each NAS message.
ETSI
NOTE:
48
The BEARER identity is not necessary since there is only one NAS signalling connection per pair of
MME and UE, but is included as a constant value so that the input parameters for AS and NAS will be the
same, which simplifies specification and implementation work.
The use and mode of operation of the 128-bit integrity algorithms are specified in Annex B.
The supervision of failed NAS integrity checks shall be performed both in the ME and the MME. In case of failed
integrity check (i.e. faulty or missing NAS-MAC) is detected after the start of NAS integrity protection, the concerned
message shall be discarded except for some NAS messages specified in TS 24.301 [9]. For those exceptions the MME
shall take the actions specified in TS 24.301 [9] when receiving a NAS message with faulty or missing NAS-MAC.
Discarding NAS messages can happen on the MME side or on the ME side.
8.1.2
NAS integrity shall be activated using the NAS SMC procedure or after a handover to E-UTRAN from
UTRAN/GERAN. Replay protection shall be activated when integrity protection is activated (except for when the
selected integrity protection algorithm is EIA0, see Annex B). Replay protection shall ensure that the receiver only
accepts each particular incoming NAS COUNT value once using the same NAS security context. Once NAS integrity
has been activated, NAS messages without integrity protection shall not be accepted by the UE or MME. Before NAS
integrity has been activated, NAS messages without integrity protection shall only be accepted by the UE or MME in
certain cases where it is not possible to apply integrity protection as specified in TS 24.301 [9]. While some NAS
messages such as reject messages need to be accepted by the UE without integrity protection, the MME shall only send
a reject message that causes the CSG list on the UE to be modified after the start of NAS security. The UE shall discard
any message modifying the CSG list if it is not integrity protected.
NAS integrity stays activated until the EPS security context is deleted in either the UE or MME. In particular the NAS
service request shall always be integrity protected and the NAS attach request message shall be integrity protected if the
EPS security context is not deleted while UE is in EMM-DEREGISTERED. The length of the NAS-MAC is 32 bit. The
full NAS-MAC shall be appended to all integrity protected messages except for the NAS service request. Only the 16
least significant bits of the 32 bit NAS-MAC shall be appended to the NAS service request message.
The use and mode of operation of the 128-EIA algorithms are specified in Annex B.
8.2
The input parameters for the NAS 128-bit ciphering algorithms shall be the same as the ones used for NAS integrity
protection as described in clause 8.1, with the exception that a different key, KNASenc , is used as KEY, and there is an
additional input parameter, namely the length of the key stream to be generated by the encryption algorithms.
The use and mode of operation of the 128-bit ciphering algorithms are specified in Annex B.
9.1
9.1.1
This subclause covers both the cases of idle mode mobility from E-UTRAN to UTRAN and of Idle Mode Signaling
Reduction (ISR), as defined in TS 23.401 [2].
NOTE 1: TS 23.401 states conditions under which a valid P-TMSI or a P-TMSI that is mapped from a valid GUTI
("mapped GUTI") is inserted in the Information Element "old P-TMSI" in the Routing Area Update
Request. It depends on the old P-TMSI which security context can be taken into use after completion of
the Routing Area Update procedure.
Use of an existing UMTS security context
ETSI
49
If the UE sends the RAU Request with the "old P-TMSI" Information Element including a valid P-TMSI it shall also
include the KSI relating to this P-TMSI. This KSI is associated with the UMTS security context stored on the UE, and it
indicates this fact to the SGSN. In this case the UE shall include P-TMSI signature into the RAU Request if a P-TMSI
signature was assigned by the old SGSN. If the network does not have a valid security context for this KSI it shall run
AKA. In case of an SGSN change keys from the old SGSN shall overwrite keys in the new SGSN if any.
NOTE 2: if the UE has a valid UMTS security context then this context is stored on the USIM according to TS
33.102 [4].
Mapping of EPS security context to UMTS security context
If the UE sends the RAU Request with the "old P-TMSI" Information Element including mapped GUTI it shall also
include the KSI equal to the value of the eKSI associated with the current EPS security context (cf. clause 3). The UE
shall include a truncated NAS-token, as defined in this clause further below, into the P-TMSI signature IE. The MME
shall transfer UE's UTRAN and GERAN security capabilities and CK' || IK' with KSI equal to the value of the eKSI
associated with the current EPS security context to SGSN with Context Response/SGSN Context Response message.
The MME and UE shall derive CK' and IK' from the KASME and the NAS uplink COUNT value corresponding to the
truncated NAS-token received by the MME from SGSN as specified in clause A.13. Keys CK' and IK' and KSI sent
from the MME shall replace all the UTRAN PS key parameters CK, IK, s KSI in the target SGSN if any. Keys CK' and
IK' and the KSI shall replace all the currently stored UTRAN PS key parameters CK, IK, KSI values on both USIM and
ME. The handling of STARTPS shall comply with the rules in 3GPP TS 25.331 [24]. The UE may set the STARTPS
value to 0 if it is done before establishment of the RRC connection.
The ME shall use CK' and IK' to derive the GPRS Kc using the c3 function specified in 3GPP TS 33.102 [4]. The ME
shall assign the eKSI value (associated with CK and IK) to the GPRS CKSN. The ME shall update the USIM and ME
with the new GPRS Kc and GPRS CKSN.
NOTE 3: The new derived security context (including CK and IK) replacing the old stored values in the USIM is
for allowing to reuse the derived security context without invoking the authentication procedure in the
subsequent connection set-ups , and also for avoiding that one KSI indicates to two different key sets and
consequently leads to security context desynchronization.
NOTE 4: An operator concerned about the security of keys received from another operator may want to enforce a
policy in SGSN to run a UMTS AKA as soon as possible after the run of an idle mode mobility
procedure. An example of ensuring this is the deletion of the mapped UMTS security context in the
SGSN after the completion of the idle mode mobility procedure.
NOTE 5: Due to replacing all the UTRAN PS key parameters CK, IK, KSI with CK, IK and eKSI on USIM and in
ME, a new GPRS Kc needs to be derived from the new UTRAN PS key parameters CK and IK (i.e. CK
and IK), which is part of the new UMTS security context as well, as any old GPRS Kc stored on USIM
and in ME belongs to an old UMTS security context and can no longer be taken into use.
SGSN shall include the allowed security algorithm and transfer them to RNC. An SMC shall be sent to the UE
containing the selected algorithms.
The 16 least significant bits available in the P-TMSI signature field shall be filled with the truncated NAS-token
according to 3GPP TS 23.003 [3].The truncated NAS-token is defined as the 16 least significant bits of the NAS-token.
The NAS-token is derived as specified in Annex A.9. The UE shall use the uplink NAS COUNT value that it would use
in the next NAS message to calculate the NAS-token and increase the stored uplink NAS COUNT value by 1.
SGSN shall forward the P-TMSI signature including the truncated NAS token to the old MME, which compares the
received bits of the truncated NAS-token with the corresponding bits of a NAS-token generated in the MME, for the UE
identified within the context request. If they match, the context request message is authenticated and authorized and
MME shall provide the needed information for the SGSN. Old MME shall respond with an appropriate error cause if it
does not match the value stored in the old MME. This should initiate the security functions in the new SGSN.
To avoid possible race condition problems, the MME shall compare the received truncated NAS-token with the 16 least
significant bits of NAS-tokens generated from the current NAS uplink COUNT value up to current NAS uplink
COUNT value +L, i.e. the interval [current NAS uplink COUNT, current NAS uplink COUNT+L]. A suitable value for
the parameter L can be configured by the network operator. MME shall not accept the same NAS-token for the same
UE twice except in retransmission cases happening for the same mobility event. If the MME finds a match, it shall set
the stored uplink NAS COUNT value as though it had successfully received an integrity protected NAS message with
the uplink NAS COUNT value that created the match.
ETSI
9.1.2
50
This subclause covers both the cases of idle mode mobility from UTRAN to E-UTRAN and of Idle Mode Signaling
Reduction, as defined in TS 23.401 [2].
The TAU Request and ATTACH Request message shall include the UE security capabilities. The MME shall store
these UE security capabilities for future use. The MME shall not make use of any UE security capabilities received
from the SGSN.
In this procedure, the START values shall be kept in the volatile memory of the ME, cf. also clause 6.8.11 of TS 33.102
[4].
NOTE 1: TS 23.401 states conditions under which a valid GUTI or a GUTI that is mapped from a valid P-TMSI is
inserted in the Information Element "old GUTI" in the Tracking Area Update Request. The value in the
"old" GUTI IE informs the MME, which SGSN/MME to fetch the UE context from.
Case 1: P-TMSI not included in "old GUTI" IE in TAU Request
This case is identical to that described in clause 7.2.7.
Case 2: Mapped P-TMSI included in "old GUTI" IE in TAU Request
The UE shall include in the TAU Request:
-
the KSI with corresponding P-TMSI and old RAI to point to the right source SGSN and key set there. This
allows the UE and MME to generate the mapped EPS NAS security context, as described below, if current EPS
NAS security context is not available in the UE and network. The KSI shall correspond to the set of keys most
recently generated (either by a successful UMTS AKA run in UTRAN (which may or may not yet have been
taken into use by the UE and SGSN) or a UMTS security context mapped from an EPS NAS security context
during a previous visit in UTRAN).
a P-TMSI signature, if the UE was previously connected to UTRAN where the SGSN assigned a P-TMSI
signature to the UE
a 32bit NONCEUE (see clause A.11 for requirements on the randomness of NONCEUE).
If the UE has a current EPS NAS security context, then it shall include the corresponding eKSI value and if it exists, the
corresponding GUTI, in the TAU Request. If the UE includes the eKSI, but not the corresponding GUTI, the MME may
treat the TAU request as if the EPS NAS security context did not exist. The TAU Request shall be integrity-protected,
but not confidentiality-protected. The UE shall use the current EPS NAS security context algorithms to protect the TAU
Request message.
NOTE 2: The current EPS NAS security context may be of type "mapped", and hence the value of the eKSI be of
type "KSISGSN". This value of KSISGSN may be different from the KSI pointing to the set of keys most
recently generated in UTRAN as an UMTS AKA run may have happened in UTRAN after the current
mapped EPS NAS security context indicated by the eKSI with the value KSISGSN was generated
NOTE 3: The UE has a current EPS NAS security context in the following scenario: a UE established a current
EPS NAS security context during a previous visit to EPS, then moves to UTRAN/GERAN from EUTRAN and storing the current EPS NAS security context. When the UE moves back to E-UTRAN there
is a current EPS NAS security context.
If a current EPS NAS security context is not available in the UE, the UE shall send the TAU request unprotected.
If the MME received a P-TMSI signature from the UE, the MME shall include that P-TMSI signature in the Context
Request message sent to the SGSN. The SGSN shall transfer CK || IK to MME in the Context Response/SGSN Context
Response message. In case the MM context in the Context Response/SGSN Context Response indicates GSM security
mode, the MME shall abort the procedure.
In case the TAU Request was protected and the MME has the indicated EPS NAS security context it shall verify the
TAU Request message. If it is successful, the UE and the MME share a current EPS NAS security context. In case the
TAU Request had the active flag set or the MME chooses to establish radio bearers when there is pending downlink UP
data or pending downlink signalling, KeNB is calculated as described in clause 7.2.7.
If the MME wants to change the algorithms, the MME shall use a NAS security mode procedure (see clause 7.2.4.4).
ETSI
51
If the MME does not have the EPS NAS security context indicated by the eKSI by the UE in the TAU request, or the
TAU request was received unprotected, the MME shall create a new mapped EPS NAS security context (that shall
become the current EPS NAS security context). In this case, the MME shall generate a 32bit NONCEMME (see clause
A.10 for requirements on the randomness of NONCEMME). and use the received NONCEUE with the NONCEMME to
generate a fresh mapped K'ASME from CK and IK, where CK, IK were identified by the KSI and P-TMSI in the TAU
Request. See Annex A.11 for more information on how to derive the fresh K'ASME. The MME initiates a NAS Security
mode command procedure with the UE as described in clause 7.2.4.4 including the KSISGSN, NONCEUE, and
NONCEMME in the NAS Security mode command. The uplink and downlink NAS COUNT for mapped EPS NAS
security context shall be set to start value (i.e., 0) when new mapped EPS NAS security context is created in UE and
MME.
If the TAU Request had the active flag set or the MME chooses to establish radio bearers when there is pending
downlink UP data or pending downlink signalling, the uplink NAS Count which is set to zero shall be used to derive the
KeNB in MME and UE as specified in clause A.3. MME shall deliver the KeNB to the target eNB on the S1 interface.
The TAU Accept shall be protected using the current EPS NAS security context.
9.2
Handover
9.2.1
NAS and AS security shall always be activated before handover from E-UTRAN to UTRAN can take place.
Consequently the source system in the handover shall always send a key set to the target system during handover. The
security policy of the target PLMN determines the selected algorithms to be used within the UTRAN HO command.
NOTE :
The security activation in target system is not the same as handover within E-UTRAN. Only the ciphering
algorithm is indicated within the UTRAN HO command. The confidentiality protection begins
immediately upon UE reception of the UTRAN HO command while the integrity protection in UTRAN is
activated by SMC procedure following the handover from E-UTRAN to UTRAN. Further details are in
3GPP TS 25.331 [24].
The MME shall select the current NAS downlink COUNT value to use in the handover and then increase the stored
NAS downlink COUNT value by 1.
NOTE 0: Increasing the NAS downlink COUNT by 1 is to ensure that a fresh NAS downlink COUNT is used for
any future purposes.
UE and MME shall derive a confidentiality key CK', and an integrity key IK' from the KASME and the selected NAS
downlink COUNT value of the current EPS key security context with the help of a one-way key derivation function
KDF as specified in clause A.8.
Whether UTRAN PS key ciphering is considered active in the target UTRAN after handover from E-UTRAN shall be
determined according to the principles for handover to UTRAN in TS 25.331 [24].
UE and MME shall assign the value of eKSI to KSI. MME shall transfer CK' || IK' with KSI to SGSN. The target SGSN
shall replace all stored parameters CK, IK, KSI, if any, with CK' , IK', KSI received from the MME. The UE shall
replace all stored parameters CK, IK, KSI, if any, with CK' , IK', KSI in both ME and USIM. STARTPS shall comply
with the rules in 3GPP TS 25.331 [24]. The ME shall use CK and IK to derive the GPRS Kc using the c3 function
specified in 3GPP TS 33.102 [4]. The ME shall assign the eKSI value (associated with CK and IK) to the GPRS
CKSN. The ME shall update the USIM and ME with the GPRS Kc and GPRS CKSN.
NOTE 1: The new mapped UMTS security context (including CK, and IK ) replacing the stored values in the
USIM and ME, is for allowing to reuse the mapped UMTS security context without invoking the
authentication procedure in subsequent connection set-ups, and also for avoiding that one KSI value gets
associated with two different key sets and consequently leads to UMTS security context
desynchronization.
NOTE 2: An operator concerned about the security of keys received from an E-UTRAN of another operator may
want to enforce a policy in SGSN to run a UMTS AKA as soon as possible after the handover. One
example of ensuring this is the deletion of the mapped UMTS security context in the SGSN after the UE
has left active state in UMTS.
ETSI
52
NOTE 3: Due to replacing all the UTRAN PS key parameters CK, IK, KSI with CK, IK and eKSI on USIM and
in ME, a new GPRS Kc needs to be derived from the new UTRAN PS key parameters CK and IK (i.e.
CK and IK), which is part of the new UMTS security context as well, as any old GPRS Kc stored on
USIM and in ME, belongs to an old UMTS security context and can no longer be taken into use.
After HO from E-UTRAN to UTRAN the current EPS NAS security context shall (if it is kept ) be considered as the
current one in E-UTRAN in the UE and the MME.
MME shall also provide at least the 4 LSB of the selected NAS downlink COUNT value to the source eNB, which then
shall include the bits in the MobilityFromE-UTRANCommand to the UE. The UE shall use the received 4 LSB and its
stored NAS downlink COUNT to estimate the NAS downlink COUNT selected by the MME.
NOTE 4: It is left to the implementation how to estimate the NAS downlink COUNT.
The UE shall ensure that the estimated NAS downlink COUNT has not been used to calculate a CK' and IK' in a
previous successful or unsuccessful PS or SRVCC handover. If the estimated NAS downlink COUNT is greater than all
the estimated NAS downlink COUNTs either used by the UE for key derivation in a handover or received in a NAS
message that passed its integrity check, the UE shall update its stored NAS downlink COUNT as though it has
successfully integrity checked a NAS message with that estimated NAS downlink COUNT. In particular, the stored
NAS downlink COUNT shall never be decreased.
MME shall transfer the UE security capabilities to the SGSN. The selection of the algorithms in the target system
proceeds as described in TS 33.102 [4] for UTRAN.
If the handover is not completed successfully, the new mapped UMTS security context can not be used in the future.
The SGSN shall delete the new mapped UMTS security context and the stored UMTS security context which has the
same KSI as the new mapped UMTS security context.
9.2.2
9.2.2.1
The procedure for handover from UTRAN to E-UTRAN, as far as relevant for security, proceeds in the following two
consecutive steps:
A) Handover signalling using the mapped EPS security context (cf. also Figure 9.2.2.1-1);
B) Subsequent NAS signalling to determine whether a native EPS security context can be taken in use (not shown in
Figure 9.2.2.1-1).
In this procedure, the START values shall be kept in the volatile memory of the ME, cf. also clause 6.8.11 of TS 33.102
[4].
The activation of NAS and AS security in E-UTRAN, and selection of the key set from the source system for the
handover shall be according to following principles:
i) As described for inter-SGSN PS handover cases in TS 33.102 [4], the source SGSN shall select the key set most
recently generated (either by a successful UMTS AKA run in UTRAN (which may or may not yet have been
taken into use by the UE and SGSN) or a UMTS security context mapped from an EPS security context during a
previous visit to UTRAN) and transfer this key set to the MME in the Forward Relocation Request.
NOTE 0: The MME is considered as a target SGSN in case of Gn/Gp interface.
ii) Activation of AS security (for details cf. TS 36.331 [21]):
The E-UTRAN HO command received at the UE shall activate AS security.
The HO Complete received at the eNB shall activate AS security.
iii) Activation of NAS security (for details cf. TS 24.301 [9]):
The E-UTRAN HO command received at the UE shall activate NAS security.
The HO Notify received at the MME shall activate NAS security. In case the MME does not have the UE
security capabilities stored from a previous visit, then no NAS message shall be sent or accepted by the
ETSI
53
MME other than a TAU request before a successful check of the UE security capabilities in the TAU request
was performed by the MME.
iv) Both AS and NAS ciphering and integrity protection algorithms shall be selected according to the policy of the
target PLMN.
The above four principles consequentially always activate ciphering (potentially NULL ciphering) in E-UTRAN even if
it was not active in the source system.
Source
RNC
UE
eNB
SGSN
MME
Relocation Required
FW relocation Request
(security context from
source system, MM
context)
K'ASME = KDF (CK, IK, NONCE)
Create
transparent
container i.e.
RRCConnect
ionReconfig
uration with
NONCE
included
S1 HO Request
(NONCE; KeNB based on K'ASME )
S1 HO Request Ack
(RRCConnectionReconfiguration
in TS 36.331)
Relocation command
UTRAN HO
Command
(RRCConnectionReconfig
uration)
FW relocation
Response
(RRCConnectionRecon
figuration)
(RRCConnection
Reconfiguration)
K'ASME = KDF (CK, IK, NONCE)
HO complete
(equals
RRCConnectionReconfiguration
complete in TS 36.331)
HO notify
FW relocation
complete
FW relocation
Complete Ack
If the 64 most significant bits of the CK are not identical to the 64 least significant bits of the CK, the RNC can
deduce that the UE was authenticated via UMTS AKA. (The bits are identical if the CK is derived from a Kc via
the c4 key conversion function [4], and it is very unlikely that they are equal for a CK derived from UMTS
AKA.)
If the 64 most significant bits of the CK are identical to the 64 list significant bits of the CK, the RNC can further
check if the IK fulfils the equation given by the c5 key conversion function [4]. If the IK does not fulfil this
equation, the RNC can deduce that the UE was authenticated with UMTS AKA, and if the IK does, then the
RNC can deduce that the UE was authenticated using GSM AKA.
ETSI
54
If the source RNC does not conclude that the UE is authenticated using UMTS AKA, the source RNC may select an
appropriate network for the UE at the handover decision stage and may send a Relocation Required message to the
SGSN. This message does not contain any security-relevant parameters.
1. The SGSN shall transfer MM context (including CK and IK (or the Kc), KSI and the UE security capabilities) to
MME in the Forward relocation request message. In case the MM context in the Forward relocation request
message indicates GSM security mode(i.e., it contains a Kc), the MME shall abort the non-emergency call
procedure. The UE security capabilities, including the UE EPS security capabilities, were sent by the UE to the
SGSN via the UE Network Capability IE, in Attach Request and RAU Request. It is possible that an SGSN
does not forward the UE EPS security capabilities to the MME. When the MME does not receive UE EPS
security capabilities from the SGSN, the MME shall assume that the following default set of EPS security
algorithms is supported by the UE (and shall set the UE EPS security capabilities in the mapped EPS NAS
security context according to this default set):
a.
EEA0, 128-EEA1 and 128-EEA2 for NAS signalling ciphering, RRC signalling ciphering and UP
ciphering;
b.
128-EIA1 and 128-EIA2 for NAS signalling integrity protection and RRC signalling integrity
protection.
NOTE 1: When an EPS algorithm is specified which is not part of the default set, the MME cannot assume that a
UE handing over from GERAN/UTRAN to E-UTRAN will support that algorithm in the case that the
SGSN does not support transfer of the UEs EPS security capabilities to the MME. In this case the MME
will select one of the algorithms from the default set instead at handover, and can then switch to the
algorithm that is not part of the default set after the MME has received the UE EPS security capabilities
from the UE in the Tracking Area Update request.If the operator requires that an algorithm that is not part
of the default set has to be taken into use immediately after handover from GERAN/UTRAN to EUTRAN, then the operator has to upgrade the SGSNs to support transfer of the UE EPS security
capabilities to the MME.
NOTE 1a: If the UE has an unauthenticated IMS Emergency Service without integrity protection ongoing before the
IRAT handover to LTE, the SGSN must be Rel-9 + and thus be able to forward the UE EPS security
capabilities including EIA0 to the MME. In this case the MME would select EIA0 algorithm.
2.
The MME shall create a NONCEMME to be used in the K'ASME derivation (see clause A.10 for requirements on
the randomness of NONCEMME).. MME shall derive K'ASME from CK and IK with the help of a one-way key
derivation function as defined in clause A.10 and associate it with a Key Set Identifier KSISGSN. The value field
of the KSISGSN shall be derived by assigning the KSI corresponding to the set of keys most recently generated
(either by a successful UMTS AKA run in UTRAN (which may or may not yet have been taken into use by the
UE and the SGSN) or a UMTS security context mapped from an EPS security context during a previous visit
in UTRAN). MME shall derive KeNB from K'ASME using the key derivation function defined in clause A.3. The
uplink and downlink NAS COUNT values for the mapped EPS security context shall be set to start value (i.e.
0) in the MME.
3. MME shall select the NAS security algorithms (including ciphering and integrity protection) which have the
highest priority from its configured list and are also present in the UE EPS security capabilities, MME shall
derive the NAS keys from K'ASME using the algorithm types and algorithm IDs as input to the NAS key
derivation functions(see Annex A.7), MME shall include KSISGSN, NONCEMME , the selected NAS security
algorithms in the NAS Security Transparent Container IE of S1 HO Request message to the target eNB. MME
further shall include KeNB and the UE EPS security capabilities, either the capabilities received from the SGSN
or, in the absence of these, the default set of EPS security algorithms, in the S1 HO Request message to the
target eNB.
4. The target eNB shall select the AS algorithms (including ciphering for both RRC and UP, and integrity
protection for RRC ) which have the highest priority from its configured list and is also present in the UE EPS
security capabilities. The target eNB shall create a transparent container (RRCConnectionReconfiguration)
including the selected RRC, UP algorithms and the NAS Security Transparent Container IE, and send it in the
S1 HO Request Ack message towards the MME. The eNB shall derive the RRC and UP from KeNB using the
key derivation function defined in clause A.7.
NOTE 2: This transparent container is not protected by the target eNB.
5. MME shall include the transparent container received from the target eNB in the FW Relocation Response
message sent to SGSN.
ETSI
55
6. SGSN shall include the transparent container in the relocation command sent to the RNC.
7. The RNC shall include the transparent container in the UTRAN HO command sent to the UE.
NOTE 3: The UTRAN HO command is integrity protected and optionally ciphered as specified by TS 33.102 [4].
8. The UE shall derive K'ASME, associate it with KSISGSN and derive KeNB in the same way the MME did in step 2
The UE shall also derive the NAS key as the MME did in step 3 and the RRC and UP keys as the eNB did in
step 4. The UE shall send a RRCConnectionReconfiguration Complete messages to the eNB. The uplink and
downlink NAS COUNT values for the mapped EPS security context shall be set to start value (i.e. 0) in the
UE.
9. The mapped EPS security context shall become the current (cf. subclause 3.1) EPS security context at AS and
NAS level and overwrite any existing current mapped EPS security context. If the current EPS security context
is of type native, then it shall become the non-current native EPS security context and overwrite any existing
non-current EPS security context. The HO Complete messages and all following AS messages in E-UTRAN
shall be ciphered and integrity protected according to the policy of the target PLMN.
If the handover is not completed successfully, the new mapped EPS security context can not be used in the future. The
MME shall delete the new mapped EPS security context.
B) Subsequent NAS signalling
In order to prevent that successful bidding down on the UE security capabilities in a previous RAT have an effect on the
selection of EPS security algorithm for NAS and AS, the UE security capabilities shall be included in the TAU request
after IRAT-HO and be verified by the MME.
NOTE 4: Any TAU request following the handover will be integrity protected. Details are described in subclause
9.2.2.1
In any case UE security capability information received from the UE overwrites any capabilities received with the
context transfer as specified in TS 23.401 [2].
It can happen that the MME receives different UE EPS security capabilities in the TAU Request from the already stored
UE EPS security capabilities in MME (received from the source SGSN or the default UE EPS security capabilities
when MME uses the default set of EPS security algorithms for the UE according to A) step 1 above). If it happens, the
MME shall perform as follows:
-
In case the TAU Request contains a higher priority NAS algorithm (according to the priority list stored in the
MME), the MME run a NAS security mode command procedure to change the NAS algorithms according to
subclause 7.2.4.4.
MME shall send an S1 CONTEXT MODIFICATION REQUEST message to inform the eNB about the correct
UE EPS security capabilities.
The eNB shall trigger a change of AS algorithms if the received UE EPS security capabilities from the S1 CONTEXT
MODIFICATION REQUEST message would contain higher priority AS algorithm (according to the priority list stored
in the eNB).
1 If the MME has native security context for the UE and does not receive a TAU request within a certain period
after the HO it shall assume that UE and MME share a native security context.
NOTE 5: A TAU procedure following handover from UTRAN to E-UTRAN is mandatory if the Tracking Area has
changed, but optional otherwise, cf. TS 23.401[2].
2 When the UE sends a TAU request it shall protect the request using the mapped EPS security context identified
by KSISGSN. The UE shall also include KSIASME in the TAU request if and only if it has native EPS security
context. The KSIASME shall be accompanied by a GUTI. When the MME receives a TAU request with a KSIASME
and GUTI corresponding to the non-current native EPS security context stored on that MME it knows that UE
and MME share a non-current native EPS security context.
3 Void.
4 When the MME receives a TAU request without a KSIASME it shall delete any non-current native EPS security
context for any GUTI it may have for the user who sent the TAU request.
ETSI
56
5 If the MME shares the non-current native EPS security context indexed by the KSIASME and GUTI from the TAU
Request with the UE, the MME may run a NAS security mode command procedure with the UE to activate the
non-current native EPS NAS security context according to clause 7.2.9.4. The MME may in addition change the
KeNB on the fly according to clause 7.2.9.2. In case the GUTI received in the TAU Request message pointed to a
different MME, the allocation of a new GUTI, replacing the received GUTI, and the association of this new
GUTI with KSIASME is required.
6 Void.
NOTE 6: The TAU Request is integrity protected with the mapped EPS security context even if the UE and the
MME share a non-current native EPSsecurity context since the UE cannot know for sure if the MME still
has the non-current native EPS security context at the time of sending the TAU Request.
7 When the MME knows, after having completed the TAU procedure in the preceding steps, that it shares a noncurrent native EPS security context with the UE, the MME may (depending on configured policy and if the
MME did not do it already in step 5) activate this non-current native EPS security context. This activation may
occur in three ways:
a When the UE has cryptographically protected radio bearers established: the MME shall initiate a key change
on the fly procedure according to subclause 7.2.9 for the entire EPS key hierarchy.
b After the next transition to ECM-IDLE state following the handover from UTRAN: Upon receiving the first
message from the UE after the UE has gone to ECM-IDLE state the MME shall use the procedures defined in
subclauses 7.2.4.4 and 7.2.4.5 to activate the non-current native EPS security context if such exists.
c At the next transition to EMM-DEREGISTERED (see clause 7.2.5.1).
8 If a non-current native EPS security context has been established, then the UE and the MME shall delete the
mapped EPS security context and set the non-current native EPS security context to the current EPS security
context.
9 If the SN id changed during the IRAT handover, the MME shall delay authenticating the UE until after the
network has concluded that the UE has received the TAU Accept message which contains the current SN id. Doing
this ensures that the UE and the MME use the same SN id in the KASME derivation.
NOTE 7: The run of a NAS SMC procedure ensures that the uplink NAS COUNT has increased since the last time
a KeNB was derived from the KASME.
NOTE 8: For the handling of native and mapped EPS NAS security contexts after a state transition to EMMDEREGISTERED cf. subclause 7.2.5.1.
9.2.2.2
Derivation of NAS keys and KeNB during Handover from UTRAN to E-UTRAN
MME and UE shall derive the NAS keys from the mapped key K'ASME as specified in clause A.7.
The MME and UE shall derive KeNB by applying the KDF defined in Annex A.3 using the mapped key K'ASME and 232-1
as the value of the uplink NAS COUNT parameter.
NOTE:
9.3
The MME and UE only uses the 232-1 as the value of the uplink NAS COUNT for the purpose of deriving
KeNB and do not actually set the uplink NAS COUNT to 232-1. The reason for choosing such a value not
in the normal NAS COUNT range, i.e., [0, 224-1] is to avoid any possibility that the value may be used to
derive the same KeNB again.
After a handover from GERAN or UTRAN into E-UTRAN, it is strongly recommended to run an AKA and perform a
key change on-the-fly of the entire key hierarchy as soon as possible after the handover if there is no native security
context in E-UTRAN.
When a UE moves in IDLE mode from GERAN or UTRAN into E-UTRAN, it is strongly recommended to run an
AKA if there is no native security context in E-UTRAN, either after the TAU procedure that establishes an EPS
security context in the MME and UE, or when the UE establishes cryptographically protected radio bearers.
ETSI
9.4
Attach procedures
9.4.1
Attach in UTRAN
57
This subclause covers the case that the UE includes a mapped GUTI into the "old P-TMSI" Information Element of the
Attach Request.
NOTE 1: TS 23.060 states conditions under which a valid P-TMSI or a P-TMSI that is mapped from a valid GUTI
("mapped GUTI") is inserted in the Information Element "old P-TMSI" in the Attach Request.
If the UE has a current EPS NAS security context, it shall include a truncated NAS-token, as defined in subclause 9.1.1,
into the P-TMSI signature IE of the Attach Request. It shall also include the KSI equal to the value of the eKSI
associated with the current EPS security context.
If the UE does not have a current EPS NAS security context, the UE shall set the truncated NAS-token to all zero and
the KSI to 111 to indicate the UE has no keys available.
The SGSN shall forward the P-TMSI signature including the truncated NAS-token to the old MME. The MME may
check a non-zero NAS-token as described in subclause 9.1.1. If successful, the MME responds with an Identification
Response to the SGSN. If unsuccessful the MME responds with an appropriate error cause which should initiate the
security functions in the SGSN.
If P-TMSI Signature includes an all zero NAS-token or the MME chooses not to check the NAS-token, the MME may
respond with an Identification Response that does not include keys.
If needed, the MME and UE shall derive CK' and IK' from the KASME as in subclause 9.1.1. Keys CK' and IK' and KSI
sent from the MME shall replace all the UTRAN PS key parameters CK, IK and KSI in the target SGSN if any. Keys
CK' and IK' and the KSI shall replace all the currently stored UTRAN PS key parameters CK, IK, KSI values on both
the USIM and ME. The handling of STARTPS shall comply with the rules in 3GPP TS 25.331 [24]. The UE may set the
STARTPS value to 0 if it is done before establishment of the RRC connection.
The ME shall use CK and IK to derive the GPRS Kc using the c3 function specified in 3GPP TS 33.102 [4]. The ME
shall assign the eKSI value (associated with CK and IK) to the GPRS CKSN. The ME shall update the USIM and ME
with the GPRS Kc and GPRS CKSN.
NOTE 2: Due to replacing all the UTRAN PS key parameters CK, IK, KSI with CK, IK and eKSI on USIM and in
ME, a new GPRS Kc needs to be derived from the new UTRAN PS key parameters CK and IK (i.e. CK
and IK), which is part of the new UMTS security context as well, as any old GPRS Kc stored on USIM
and in ME belongs to an old UMTS security context and can no longer be taken into use.
10
10.1
General
An SGSN supporting interworking between E-UTRAN and GERAN is capable of handling UMTS security contexts
and supports the key conversion function c3 specified in TS 33.102 [4]. Such a SGSN is, according to TS 33.102,
required to ensure that the UE is authenticated using UMTS AKA, if the UE supports UMTS AKA. Furthermore, the
UE must have a USIM to be able to access EPS, except for unauthenticated emergency calls if allowed by regulations.
Hence, UMTS AKA is used when the UE is authenticated to the SGSN supporting interworking between E-UTRAN
and GERAN even when attached to GERAN, and UMTS security contexts are available. The security procedures for
interworking between E-UTRAN and GERAN are therefore quite similar to those between E-UTRAN and UTRAN.
ETSI
58
10.2
10.2.1
This subclause covers both the cases of idle mode mobility from E-UTRAN to GERAN and of Idle Mode Signaling
Reduction, as defined in TS 23.401 [2].
As the target SGSN and UE are capable of handling UMTS security contexts clause 9.1.1 applies here with the
following changes
-
the target SGSN shall derive GPRS cipher key Kc from CK and IK with the help of the key conversion function
c3 defined by TS 33.102 [4] , and the target SGSN and UE shall derive GPRS Kc128 as defined by TS 33.102 [4]
from CK' and IK' when the new encryption algorithm selected by the target SGSN requires Kc128; the target SGSN
and UE shall assign the eKSI value (associated with the CK and IK) to the GPRS CKSN associated with the
GPRS Kc128 .
the target SGSN shall select the encryption algorithm to use in GERAN.
10.2.2
This subclause covers both the cases of idle mode mobility from GERAN to E-UTRAN and of Idle Mode Signaling
Reduction, as defined in TS 23.401 [2].
As the SGSN shares a UMTS security context with the UE clause 9.1.2 applies here without changes.
10.3
Handover
10.3.1
As the target SGSN and the UE are capable of handling UMTS security contexts clause 9. 2.1 applies here with the
following changes:
-
the target SGSN shall derive GPRS cipher key Kc from CK' and IK' with the help of the key conversion function
c3 as defined by TS 33.102 [4], and target SGSN and UE shall derive GPRS Kc128 as defined by TS 33.102 [4]
from CK' and IK' when the new encryption algorithm selected by the target SGSN requires Kc128. The target
SGSN and UE shall assign the eKSI value (associated with the CK and IK) to the GPRS CKSN associated with
the GPRS Kc128 .
the target SGSN shall select the encryption algorithm to use in GERAN after handover.
Whether ciphering is considered active in the target GERAN after handover from E-UTRAN shall be determined
according to the principles for handover to GERAN in TS 44.060 [25].
10.3.2
10.3.2.1
As the SGSN shares a UMTS security context with the UE clause 9.2.2 applies here without changes.
10.4
ETSI
10.5
Attach procedures
10.5.1
Attach in GERAN
59
As the SGSN is capable of handling UMTS security contexts clause 9.1.1 applies here with the following changes
-
the SGSN and UE shall derive GSM cipher key Kc as defined by TS 33.102 [4] from CK' and IK' , and the SGSN
and UE shall derive Kc128 as defined by TS 33.102 [4] from CK' and IK' when the new encryption algorithm
selected by the target SGSN requires Kc128;
11
The protection of IP based control plane signalling for EPS and E-UTRAN shall be done according to NDS/IP as
specified in TS 33.210 [5]. S3, S6a and S10 interfaces carry subscriber specific sensitive data, e.g. cryptographic keys.
Thus in addition to the mandatory integrity protection according to NDS/IP, traffic on these interfaces shall be
confidentiality-protected according to NDS/IP.
In order to protect the S1 and X2 control plane as required by clause 5.3.4a, it is required to implement IPsec ESP
according to RFC 4303 [7] as specified by TS 33.210 [5]. For both S1-MME and X2-C, IKEv2 certificates based
authentication according to TS 33.310 [6] shall be implemented. For S1-MME and X2-C, tunnel mode IPsec is
mandatory to implement on the eNB. On the core network side a SEG may be used to terminate the IPsec tunnel.
NOTE 1: In case control plane interfaces are trusted (e.g. physically protected), there is no need to use protection
according to TS 33.210 [5] and TS 33.310 [6].
Transport mode IPsec is optional for implementation on the X2-C and S1-MME.
NOTE 2: Transport mode can be used for reducing the protocol overhead added by IPsec.
If the sender of IPsec traffic uses DiffServ Code Points (DSCPs) to distinguish different QoS classes, either by copying
DSCP from the inner IP header or directly setting the encapsulating IP headers DSCP, the resulting traffic may be
reordered to the point where the receiving nodes anti-replay check discards the packet. If different DSCPs are used on
the encapsulating IP header, then to avoid packet discard under one IKE SA and with the same set of traffic selectors,
distinct Child-SAs should be established for each of the traffic classes (using the DSCPs as classifiers) as is specified in
RFC 4301 [34].
Other 3GPP specifications may specify other IKEv2 and certificate profiles and IPsec implementation details for
specific types of eNBs. The provisions in such other 3GPP specifications shall take precedence over the provisions in
the present clause for those specific eNB types only if explicitly listed here. In particular, the provisions for HeNBs
specified in TS 33.320 [27] shall take precedence over the provisions in this clause.
12
The protection of user plane data between the eNB and the UE by user specific security associations is covered by
clause 5.1.3 and 5.1.4.
In order to protect the S1 and X2 user plane as required by clause 5.3.4, it is required to implement IPsec ESP according
to RFC 4303 [7] as profiled by TS 33.210 [5], with confidentiality, integrity and replay protection.
On the X2-U and S1-U, transport mode IPsec is optional for implementation.
NOTE 1: Transport mode can be used for reducing the protocol overhead added by IPsec.
Tunnel mode IPsec is mandatory to implement on the eNB for X2-U and S1-U. On the core network side a SEG may be
used to terminate the IPsec tunnel..
ETSI
60
If the sender of IPsec traffic uses DiffServ Code Points (DSCPs) to distinguish different QoS classes, either by copying
DSCP from the inner IP header or directly setting the encapsulating IP headers DSCP, the resulting traffic may be
reordered to the point where the receiving nodes anti-replay check discards the packet. If different DSCPs are used on
the encapsulating IP header, then to avoid packet discard under one IKE SA and with the same set of traffic selectors,
distinct Child-SAs should be established for each of the traffic classes (using the DSCPs as classifiers) as is specified in
RFC 4301 [34].
For both S1 and X2 user plane, IKEv2 with certificates based authentication shall be implemented. The certificates shall
be implemented according to the profile described by TS 33.310 [6]. IKEv2 shall be implemented conforming to the
IKEv2 profile described in TS 33.310 [6]. Other 3GPP specifications may specify other IKEv2 and certificate profiles
and IPsec implementation details for specific types of eNBs. The provisions in such other 3GPP specifications shall
take precedence over the provisions in the present clause for those specific eNB types only if explicitly listed here. In
particular, the provisions for HeNBs specified in TS 33.320 [27] shall take precedence over the provisions in this
clause.
NOTE 2: In case S1 and X2 user plane interfaces are trusted (e.g. physically protected), the use of IPsec/IKEv2
based protection is not needed.
13
For the management plane protection of relay nodes the provisions in clause D.2.5 apply instead of the provisions given
in this clause.
For management plane protection the requirements in clause 5.3.2 apply.
In order to achieve such protection, IPsec ESP according to RFC 4303 [7] as profiled by TS 33.210 [5] shall be
implemented for all O&M related traffic, i.e. the management plane, with confidentiality, integrity and replay
protection.
Tunnel mode IPsec shall be implemented on the eNB for supporting the management plane. On the core network side a
SEG may be used to terminate the IPsec tunnel. If no SEG is used, the IPsec tunnel may be terminated in the element
manager.
If the sender of IPsec traffic uses DiffServ Code Points (DSCPs) to distinguish different QoS classes, either by copying
DSCP from the inner IP header or directly setting the encapsulating IP headers DSCP, the resulting traffic may be
reordered to the point where the receiving nodes anti-replay check discards the packet. If different DSCPs are used on
the encapsulating header, then to avoid packet discard under one IKE SA and with the same set of traffic selectors,
distinct Child-SAs should be established for each of the traffic classes (using the DSCPs as classifiers) as is specified in
RFC 4301 [34].
For the management plane, IKEv2 with certificates based authentication shall be implemented on the eNB. The
certificates shall be implemented according to the profile described by TS 33.310 [6]. IKEv2 shall be implemented
conforming to the IKEv2 profile described in TS 33.310 [6]. Other 3GPP specifications may specify other IKEv2 and
certificate profiles and IPsec implementation details for specific types of eNBs.
Other 3GPP specifications may specify other security mechanisms and certificate profiles for specific types of eNBs for
the case when the management traffic is not carried over the same backhaul link as S1 traffic. If other security
mechanisms are specified, they shall provide mutual authentication based on certificates, as well as confidentiality,
integrity and replay protection. These functions shall have at least equal strength as that provided by the use of
IKEv2/IPsec.
The provisions in such other 3GPP specifications shall take precedence over the provisions in the present clause for
those specific eNB types only if explicitly listed here. In particular, the provisions for HeNBs specified in TS 33.320
[27] shall take precedence over the provisions in this clause.
NOTE 1: X2 does not carry management plane traffic.
NOTE 2: In case the S1 management plane interfaces are trusted (e.g. physically protected), the use of protection
based on IPsec/IKEv2 or equivalent mechanisms is not needed
ETSI
61
14
14.1
Single Radio Voice Call Continuity (SRVCC) is specified in 3GPP TS 23.216 [22].
The MME shall select the current NAS downlink COUNT value to use in the handover and then increase the stored
NAS downlink COUNT value by 1.
NOTE 0: Increasing the NAS downlink COUNT by 1 is to ensure that a fresh NAS downlink COUNT is used for
any future purposes.
The MME and the UE shall derive a confidentiality key CKSRVCC, and an integrity key IKSRVCC from KASME of the
current EPS security context and the selected NAS downlink COUNT with the help of a one-way key derivation
function KDF as specified in clause A.12.
The KDF returns a 256-bit output, where the 128 most significant bits are identified with CKSRVCC and the 128 least
significant bits are identified with IKSRVCC.
The MME shall also provide the 4 LSB of the selected NAS downlink COUNT value to the source eNB, which then
includes the bits to the HO Command to the UE. The UE shall use the received 4 LSB and its stored NAS downlink
COUNT to estimate the NAS downlink COUNT selected by the MME.
NOTE 1: It is left to the implementation how to estimate the NAS downlink COUNT.
The UE shall ensure that the estimated NAS downlink COUNT has not been used to calculate a CK' and IK' in a
previous successful or unsuccessful PS or SRVCC handover. If the estimated NAS downlink COUNT is greater than all
the estimated NAS downlink COUNTs either used by the UE for key derivation in a handover or received in a NAS
message that passed its integrity check, the UE shall update its stored NAS downlink COUNT as though it has
successfully integrity checked a NAS message with that estimated NAS downlink COUNT. In particular, the stored
NAS downlink COUNT shall never be decreased.
UE and MME shall assign the value of eKSI to KSI. MME shall transfer CKSRVCC, IKSRVCC with KSI and the UE
security capability to the MSC server enhanced for SRVCC. The MSC server enhanced for SRVCC shall replace all the
stored UTRAN CS key parameters CK, IK, KSI, if any, with CKSRVCC, IKSRVCC, KSI received from the MME when the
SRVCC handover is successful. The UE shall replace all the stored UTRAN CS key parameters CK, IK, KSI, if any,
with CKSRVCC, IKSRVCC, KSI in both ME and USIM. STARTCS shall comply with the rules in 3GPP TS 25.331 [24].
The ME shall use CKSRVCC and IKSRVCC to derive the GSM CS Kc using the c3 function specified in 3GPP TS 33.102
[4]. The ME shall assign the eKSI value (associated with CKSRVCC and IKSRVCC) to the GSM CS CKSN (associated with
the GSM CS Kc). The ME shall update the USIM and ME with the GSM CS Kc and GSM CS CKSN.
NOTE 2: The new derived security context (including CKSRVCC, IKSRVCC, and KSI) replacing the stored values in
the USIM is for allowing to reuse the derived security context without invoking the authentication
procedure in subsequent connection set-ups, and also for avoiding that one KSI value indicates to two
different key sets and consequently leads to security context desynchronization.
NOTE 3: An operator concerned about the security of keys received from an E-UTRAN of another operator may
want to enforce a policy in the MSC server enhanced for SRVCC to run a UMTS AKA as soon as
possible after the handover. One example of ensuring this is the deletion of the mapped UMTS security
context in the enhanced MSC server after the UE has left active state.
NOTE 4: Due to replacing all the UTRAN CS key parameters CK, IK, KSI with CKSRVCC, IKSRVCC and KSI on
USIM and in ME, a new GSM CS Kc needs to be derived from the new UTRAN CS key parameters CK
and IK (i.e. CKSRVCC and IKSRVCC), which is part of the new UMTS security context as well, as any old
GSM CS Kc stored on USIM and in ME, belongs to an old UMTS security context and can no longer be
taken into use.
If the SRVCC is from E-UTRAN to GERAN, the above description in this section applies as well for the MME, the
enhanced MSC server and the UE. The enhanced MSC server shall in addition derive GSM CS cipher key Kc from
CKSRVCC and IKSRVCC with the help of the key conversion function c3 as specified in TS 33.102 [4], and assign the value
ETSI
62
of eKSI to GSM CS CKSN associated with the GSM CS Kc, and the target MSC server and UE shall compute the 128bit GSM CS cipher key Kc128 as specified in TS 33.102 [4] when the new encryption algorithm selected by the target
BSS requires Kc128. The UE and the enhanced MSC Server shall assign the value of eKSI to GSM CS CKSN associated
with the GSM CS Kc128.
Non-voice bearers may be handed over during the SRVCC handover operation. For this case, k ey derivation for nonvoice bearers is specified in clause 9.2.1 and 10.3.1 of the present specification. If non-voice bearers are not handed
over during the SRVCC handover operation and if the UE subsequently resumes PS services in UTRAN/GERAN, key
derivation for the PS domain is specified in clause 9.1.1 and 10.2.1 of the present specification.
If the SRVCC handover is not completed successfully, the new mapped CKSRVCC, IKSRVCC and KSISRVCC can not be used
in the future. The MSC server enhanced for SRVCC shall delete the new mapped CKSRVCC, IKSRVCC and KSISRVCC and
the stored parameters CKCS and IKCS which has the same KSI as the new mapped CKSRVCC, IKSRVCC (if such exist).
14.2
If the SRVCC is for an emergency call and the session in EUTRAN complies with clause 15.2.1, the security procedure
in clause 14.1 shall be applied.
If the SRVCC is for an emergency call and the session in EUTRAN complies with clause 15.2.2, the security procedure
in clause 14.1 shall not be applied, i.e., no key derivation is needed.
Procedure
The procedure for SRVCC handover from UTRAN/GERAN CS to E-UTRAN, as far as relevant for security, proceeds
as described below.
The activation of NAS and AS security in E-UTRAN, and selection of the key set from the source system for the
handover shall be according to following principles:
i) The source MSC server enhanced for SRVCC shall select the key set most recently generated. This key set may
have been generated by either a successful UMTS AKA run in UTRAN or from a UMTS security context
mapped from an EPS security context during a previous visit to UTRAN. The UE and source MSC server
enhanced for SRVCC may or may not have taken the key set into use. The MSC server enhanced for SRVCC
shall transfer this key set to the MME in the CS to PS HO request.
ii) Activation of AS security in the UE (for details cf. TS 36.331 [21]):
The CS to PS HO command received at the UE shall activate AS security in the UE.
The CS to PS HO Confirmation received at the eNB shall activate AS security in the eNB.
iii) Activation of NAS security (for details cf. TS 24.301 [9]):
The CS to PS HO request received at the UE shall activate NAS security in the UE.
The Handover Notify received at the MME shall activate NAS security in the MME. In case the MME does not
have the UE security capabilities stored from a previous visit, then the MME shall only accept TAU requests
from this UE, and shall not send any messages to this UE, until the MME has successfully checked the UE
security capabilities received in a TAU request from this UE.
iv) Both AS and NAS ciphering and integrity protection algorithms shall be selected according to the policy of the
target PLMN.
The above four principles consequentially always activate ciphering (potentially NULL ciphering) in E-UTRAN even if
it was not active in the source system.
ETSI
63
Figure 14.3.1-1: SRVCC handover from UTRAN/GERAN to E-UTRAN. Key derivations in the figure are
only shown for UMTS subscribers.
Handover signalling in case of successful handover
Before attempting a handover for a UE, the source RNC/BSC may check if the UE is authenticated using UMTS AKA
as described in clause 9.2.2.1 of the present document, and may avoid doing a SRVCC handover to E-UTRAN in case
the UE is not authenticated using UMTS AKA and does not have an ongoing emergency call.
NOTE 1: The numbering in the followingrefers to the signalling numbering in Figure 14.3.1-1.
1. The source BSC/RNC sends HO required to the source MSC server enhanced for SRVCC.
2. For UMTS and GSM subscribers, the source MSC server enhanced for SRVCC shall generate a NONCEMSC.
For UMTS subscribers, the source MSC server enhanced for SRVCC shall derive CK'PS and IK'PS from the
NONCEMSC and the latest CKCS and IKCS using the key derivation function as specified in annex B.6 of TS
33.102 [2]. The source MSC server enhanced for SRVCC shall further set the KSI'PS equal to the KSICS
associated with the latest key set as specified for SRVCC from UTRAN/GERAN to HSPA in TS 33.102 [2].
For GSM subscribers, the source MSC server enhanced for SRVCC shall derive GPRS Kc' from the NONCEMSC
and the latest GSM Kc using the key derivation function as specified in annex B.7 of TS 33.102 [2] . The source
MSC server enhanced for SRVCC shall further set the CKSN'PS equal to the CKSNCS associated with the latest
key set as specified for SRVCC from UTRAN/GERAN to HSPA in TS 33.102 [2].
For UMTS subscribers, the MSC server enhanced for SRVCC shall transfer the CK'PS/IK'PS and the KSI'PS, to the
target MME in the CS to PS handover request.
For GSM subscribers, the MSC server enhanced for SRVCC shall transfer the GPRS Kc' and the CKSN'PS, to the
target MME in the CS to PS handover request.
ETSI
64
NOTE 2: The MSC server enhanced for SRVCC does not include any authentication vectors in the CS to PS HO
request, since this could result in that authentication vectors intended for use only in the CS domain
would end up being used in a PS domain by accident.
NOTE 3: The MSC server enhanced for SRVCC does not include any UE security capability information in the CS
to PS HO request, since the target MME either has this information available, or will retrieve the information
from the old SGSN. Further, the MSC may not have access to the complete UE security capabilities.
If the MME receives a GPRS Kc' from the source MSC server enhanced for SRVCC in the CS to PS HO request,
the MME shall reject the request.
3 and 4. The MME shall discard any CK, IK, Kc, CKSN and KSI retrieved from the old SGSN in a context
request procedure
The MME shall create a mapped EPS security context by setting the K'ASME of the mapped EPS security context
equal to the concatenation CK'PS || IK'PS, where the CK'PS and IK'PS were received in the CS to PS handover
request. The MME shall further associate the K'ASME with a KSISGSN. The value of the KSISGSN shall be the same
as the value of the KSI'PS received in the CS to PS handover request.
NOTE 4: The naming of the KSISGSN hints at that this identifier is somehow related to an SGSN. However, in this
case it is related to the MSC server enhanced for SRVCC. Even though KSIMSC could have been a more
appropriate name here, the name KSISGSN is kept to avoid introducing a new name for the same entity.
The MME shall derive KeNB by applying the KDF as defined in Annex A. 3 using the mapped key K'ASME and
232-1 as the value of the uplink NAS COUNT parameter. The uplink and downlink NAS COUNT values for the
mapped EPS security context shall be set to start value (i.e. 0) in the MME.
If the MME does not have access to the UE EPS security capabilities the MME shall assume that the default set
of EPS security algorithms defined in clause 9.2.2.1 of the present document is supported by the UE (and the
MME shall set the UE EPS security capabilities in the mapped EPS security context according to this default
set). The same considerations regarding security algorithm selection using the default set as noted in clause
9.2.2.1 of the present document applies here. If the security context information received from the old SGSN
contains EPS security capabilities or the MME already have access to EPS security capabilities for the UE, the
MME shall populate the mapped EPS security context with these EPS security capabilities instead of falling
back to the default set of security algorithms.
If the MME received any authentication vectors from the old SGSN, the MME shall process these authentication
vectors according to clause 6.1.6 of the present document.
5. MME shall select the NAS security algorithms (including ciphering and integrity protection) which have the
highest priority from its configured list and are also present in the UE EPS security capabilities. MME shall
derive the NAS keys from K'ASME using the algorithm types and algorithm IDs as input to the NAS key derivation
functions (see Annex A.7). MME generates NONCEMME. MME shall include KSISGSN, NONCEMMEand the
selected NAS security algorithms in the NAS Security Transparent Container IE of Allocate resources message
to the target eNB. MME shall further include KeNB and the UE EPS security capabilities from the mapped EPS
security contextin the Allocate resources message to the target eNB.
6. The target eNB shall select the AS algorithms (including ciphering for both RRC and UP, and integrity
protection for RRC) which have the highest priority from its configured list and is also present in the UE EPS
security capabilities. The target eNB creates a target to source transparent container that contains a handover
command (the target to source transparent container is denoted "E-UTRAN RRC container" in Figure 14.3.1-1).
The handover command incluesd the selected RRC, UP algorithms and the NAS Security Transparent Container
IE, and the eNB sends the target to source transparent container in the Allocate resources Ack message towards
the MME. The eNB shall derive the keys for RRC and UP protection from the received KeNB using the key
derivation function defined in clause A.7.
NOTE 5: The handover command in the target to source transparent container is not security protected by the target
eNB.
7. MME shall include the target to source transparent container received from the target eNB in the CS to PS HO
Response message sent to source MSC server enhanced for SRVCC.
8. Source MSC server enhanced for SRVCC shall include the NONCEMSC and the target to source transparent
container in the relocation command sent to the BSC/RNC in the CS to PS HO command.
ETSI
65
9. The RNC/BSC shall include the NONCEMSC and the transparent container in the CS to PS HO command sent to
the UE.
NOTE 6: The CS to PS HO command is integrity protected and optionally ciphered in UTRAN. It is optionally
ciphered in GERAN as specified by TS 33.102 [4].
10. For UMTS subscribers the ME shall silently discard the NONCEMME received in received in the NAS Security
Transparent Container. The ME shall further derive K'ASME, associate it with KSISGSN recived in the NAS
Security Transparent Container IE and derive NAS keys and KeNB following the same key derivations as the
MSC and MME performed in steps 2, 3 and 4. The ME shall also derive the RRC and UP keys as the eNB did in
(see description for message 6 above). The UE sends a CS to PS HO Confirmation message to the target eNB.
The ME shall set the uplink and downlink NAS COUNT values for the mapped EPS security context to start
value (i.e. 0)
NOTE 7: Since the MME denies access to E-UTRAN for GSM subscribers, the UE never has to perform any key
derivations for GSM subscribers..
The mapped EPS security context established as above shall become the current (cf. subclause 3.1) EPS security
context at AS and NAS level. The MME and ME shalloverwrite any existing current mapped EPS security
context with the newly created one. If the current EPS security context is of type native, then it shall become the
non-current native EPS security context. The MME and ME shall in this case also overwrite any existing noncurrent EPS security context with this current native EPS security context. The CS to PS HO Confirmation
messages and all following AS messages in E-UTRAN shall be ciphered and integrity protected according to the
policy of the target PLMN.
If the SRVCC handover is not completed successfully, the new mapped EPS security context cannot be used in the
future. The MME and the ME shall in this case delete the new mapped EPS security context.
The text regarding subsequent NAS signalling in bullet B) in clause 9.2.2.1 of the present specification applies also after
an SRVCC handover from GERAN/UTRAN to E-UTRAN.
In SRVCC handover from GERAN/UTRAN to E-UTRAN, the STARTPS and STARTCS values used in UTRAN shall
be kept in the volatile memory of the ME, cf. also clause 6.8.11 of TS 33.102 [4].
15
15.1
General
Support for IMS Emergency Sessions is defined in the TS 23.401 [2]. Limited service state of a UE is defined in TS
23.122 [26]. IMS Emergency Sessions can be made by normally attached UEs or UEs attached for EPS emergency
bearer services. IMS Emergency Services can be authenticated or unauthenticated as defined in clauses below. It
depends on the serving network policy if unauthenticated IMS Emergency Sessions are allowed. Any behaviour not
explicitly specified as being special to IMS Emergency Sessions is handled in accordance to normal procedures.
The E-UTRAN Initial Attach procedure, with Attach Type "Emergency", is used by UEs that need to receive EPS
emergency bearer services but cannot receive normal services from the network.
For an Initial Attach with Attach Type "Emergency" the UE includes the IMSI in the Attach request if the UE does not
have a valid GUTI. The UE shall include the IMEI when the UE has no IMSI, no valid GUTI according to [2].
When involved in an Attach for EPS emergency bearer services the MME applies the parameters from MME
Emergency Configuration Data for the EPS emergency bearer establishment. Any potentially stored IMSI related
subscription data is ignored by the MME according to [2].
When involved in an Attach for EPS emergency bearer services the MME does not send any Notify Request to an HSS.
A UE attached for EPS emergency bearer services using NULL algorithms shall keep the NULL algorithms and
corresponding NAS COUNTs when in EMM-IDLE mode so that it is reachable for subsequent IMS Emergency
Sessions without the need to attach for EPS emergency bearer services again. The NULL algorithms shall be de-
ETSI
66
selected and corresponding NAS COUNTs shall be removed when the UE goes to EMM-DEREGISTERED state or
when another EPS NAS security context is activated.
The MME or UE shall always release any established non-emergency bearers, when the authentication fails in the UE
or in the MME.
15.2
15.2.1
15.2.1.1
General
UEs that are not in limited service state, shall initiate normal initial attach when not already attached to receive EPS
emergency bearer services.
The security mode control procedure shall be applied as part of EPS emergency bearer establishment as defined in
TS 23.401 [2]. Thus, integrity protection (and optionally ciphering) shall be applied as for normal EPS bearers. If
authentication fails for any reason, the handling of the EPS emergency bearer services shall be handled as specified in
clauses 15.2.1 and 15.2.2 below. Once the IMS Emergency Session is in progress with NAS and AS integrity protection
(and optionally ciphering) applied, failure of integrity checking or ciphering (for both NAS and AS) is an unusual
circumstance and shall be treated as in the case of a normal EPS bearer.
15.2.1.2
If the UE already has a current EPS security context and attempts to set up an IMS Emergency Session, the UE shall use
this EPS security context to protect NAS, RRC and UP traffic. If the MME successfully validates a request for EPS
emergency bearer services using the current EPS security context, the MME should accept this request. A request for
EPS emergency bearer services is defined to be, for the purposes of this document, an Attach request message for EPS
emergency bearer services or a PDN Connectivity request message for EPS emergency bearer services.
NOTE 1: It is defined in TS 23.401 [2] and TS 24.301 [9] how Attach requests and/or PDN Connectivity requests
are used to set up EPS emergency bearer services.
If the authentication fails during a normal Attach procedure, or a Service request procedure, while the UE is in normal
service mode, and the UE intends to set up an IMS Emergency Session, the UE shall retry by sending an Attach request
for EPS emergency bearer services.
If the MME attempts to authenticate the UE after receiving a request for EPS emergency bearer services which was
integrity protected by the current EPS NAS security context and the authentication failed and if the serving network
policy does not allow unauthenticated IMS Emergency Sessions, the UE and MME shall proceed as for set up of normal
EPS bearers as described in clause 6.1.1.
If the MME attempts to authenticate the UE after receiving a request for EPS emergency bearer services which was
integrity protected by the current EPS NAS security context and the authentication failed and the serving network
policy allows unauthenticated IMS Emergency Sessions, then the UE and the MME behaviours are described in the
paragraph below.
If the authentication failure is detected in the UE or in the MME during an attach procedure for EPS emergency bearer
services or a PDN connectivity request procedure for EPS emergency bearer services, and the related signalling
messages were correctly integrity-protected by the current EPS security context, the set up of the EPS emergency
bearers shall then proceed in one of two ways:
a) The set-up proceeds according to clause 15.2.2. In this case, there is no need for the UE to re-attach, and the
MME requests the use of the NULL ciphering and integrity algorithms in the same way as described in clause
15.2.2.2 for the case that UE and MME share no EPS security context.
NOTE 2: If the authentication failure is detected in the MME then the UE is not aware of the failure in the MME,
but still needs to be prepared, according to the conditions specified in TS 24.301, to accept a NAS SMC
from the MME requesting the use of the NULL ciphering and integrity algorithms.
ETSI
67
b) Or else, if the serving network policy allows unauthenticated IMS Emergency Sessions and MME continues
using the current security context, the use of the EPS emergency bearers may proceed as described below for the
case of an AKA run while a PDN connection for emergency bearer services exists.
NOTE 3: Regardless of if the authentication failed in the UE or in the MME, the MME can assume that the UE will
accept that NULL integrity and ciphering algorithms are selected in the security mode control procedure.
If AKA is run while a PDN connection for emergency bearer services exists, the MME and UE shall behave as follows:
UE behavior:
-
Upon successful authentication verification in the UE, the UE shall send RES to the MME.
NOTE 4: If the authentication failure is detected in the MME, the UE is not aware of the failure in the MME if the
MME continues to use the current security context with the UE. The UE consider itself to be in normal
service, if it was normal attached before the PDN connectivity request procedure for EPS emergency
bearer services was initiated, until the MME releases the non-emergency bearers established with the UE.
-
Alternatively, upon authentication verification failure in the UE, the UE shall send an Authentication Failure
message to the MME. The UE shall continue using the current EPS security context. If the UE receives a NAS
security mode command selecting NULL integrity and ciphering algorithms, the UE shall accept this as long as
the IMS Emergency session progresses.
MME behavior:
-
If the serving network policy requires IMS Emergency Sessions to be authenticated, the MME shall, after the
unsuccessful comparison of RES to XRES, i.e. AKA failure, proceed as if the request for EPS emergency
bearers was a request for normal EPS bearer services. The MME should not send an Authentication Reject
message if authentication failed in the MME and the serving network policy allows unauthenticated IMS
Emergency Sessions. If the MME does not send an Authentication Reject message it shall continue using the
current security context with the UE.
After receiving both, the EC Indication and the Authentication Failure message, the MME shall continue using
the current security context with the UE for establishing an EPS emergency bearer.
NOTE :
15.2.2
15.2.2.1
In the case that NAS COUNT values are about to wrap around, and AKA fails, or if the MME is unable to
fetch new authentication vectors, the handling of the EPS emergency beares are as described by TS
24.301 [9].
Authentication may fail for a UE attached for EPS emergency bearer services just as for a UE attached for normal EPS
bearer services when the UE tries to establish an IMS Emergency Session.
As defined in TS 23.401 [2] and as a serving network option, IMS Emergency Sessions may be established in limited
service state without the network having to authenticate the UE or apply ciphering or integrity protection for either AS
or NAS.
The following are the only identified cases where the "security procedure not applied" option may be used:
a) Authentication is impossible because the USIM is absent;
b) Authentication is impossible because the serving network cannot obtain authentication vectors due to a network
failure;
c) Authentication is impossible because the USIM is in limited service mode in the serving network (e.g. there is no
roaming agreement or the IMSI is barred, etc.);
d) Authentication is possible but the serving network cannot successfully authenticate the USIM.
If the ME receives a NAS SMC selecting EIA0 (NULL integrity) for integrity protection, and EEA0 (NULL ciphering)
for encryption protection, then:
ETSI
68
- the ME shall mark any stored native EPS NAS security context on the USIM /non-volatile ME memory as invalid;
and
- the ME shall not update the USIM/non-volatile ME memory with the current EPS NAS security context.
These two rules override all other rules regarding updating the EPS NAS security context on the USIM/non-volatile
ME memory, in this specification.
If EIA0 is used, and the NAS COUNT values wrap around, and a new KASME has not been established before the NAS
COUNT wrap around, the NAS connection shall be kept.
NOTE:
For unauthenticated emergency calls, EIA0, i.e., null integrity algorithm, is used for integrity protection.
Additionally, as the NAS COUNT values are allowed to wrap around, the initialization of the NAS
COUNT values are not crucial. Uplink and downlink NAS COUNT are incremented for NAS message
that use EIA0, as for any other NAS messages.
Since a UE with a 2G SIM cannot be in authenticated via EPS AKA, it shall be considered by the MME to be
unauthenticated in E-UTRAN. A UE with a 2G SIM shall at an IRAT handover to E-UTRAN when an IMS Emergency
Service is active, be considered by the MME to be unauthenticated. In such a scenario, EIA0 shall be used in E-UTRAN
after handover if the target network policy allows unauthenticated IMS Emergency Sessions.
A handover from E-UTRAN to another RAT, of an unauthenticated IMS Emergency Session, shall result in an
unauthenticated IMS Emergency Session or a circuit switched emergency call (depending on if it is a PS handover or
SRVCC) in the other RAT.
15.2.2.2
If the MME attempts to authenticate the UE after receiving the EPS emergency bearer setup request and the
authentication failed and if the serving network policy does not allow unauthenticated IMS Emergency Sessions, the UE
and MME shall proceed as for normal EPS bearer setup requests as described in clause 6.1.1.
If the UE is not yet authenticated and while the UE is trying to setup an IMS Emergency Session, the authentication
failed in the UE, the UE shall wait for a NAS SMC command to set up an unauthenticated emergency bearer. If the
serving network policy supports unauthenticated IMS Emergency Sessions, only then the MME shall support
unauthenticated EPS emergency bearer setup. In this case, the behaviours of the UE and the MME are as described
below.
The confluence of EPS emergency bearer setup and authentication failure means that the UE is considered by the MME
and UE itself to be in LSM even though the UE could have been in normal service mode before the EPS emergency
bearer setup.
UE behavior:
After sending EC Indication to the serving network the UE shall know of its own intent to establish an IMS
Emergency Session.
-
The UE will proceed as specified for the non-emergency case in clauses 6 and 7 of this specification except that
the UE shall accept a NAS SMC selecting EEA0 and EIA0 algorithms from the MME.
NOTE: In case of authentication success the MME will send a NAS SMC selecting algorithms as defined in clause 7
of this specification, i.e. with a non-NULL integrity algorithm, and the UE will accept it.
MME behavior:
After receiving EC Indication from the UE, the MME knows of that UEs intent to establish an IMS Emergency
Session.
-
If the MME cannot identify the subscriber, or cannot obtain authentication vectors, the MME shall send NAS
SMC with NULL algorithms to the UE.
After the unsuccessful comparison of RES to XRES, i.e. AKA failure, the MME shall send NAS SMC with
NULL algorithms to the UE.
After the receiving of both, the EC Indication and the Authentication Failure messages, the MME shall send
NAS SMC with NULL algorithms to the UE.
ETSI
69
If the serving network policy does not allow unauthenticated IMS Emergency Sessions, the MME shall reject the
unauthenticated EPS emergency bearer setup request from the UE.
15.2.3
Void
15.2.4
15.2.4.1
General
An unauthenticated UE does not share a complete EPS NAS security context with the network. Since there has been no
successful EPS AKA run, the UE and the MME does not share a KASME. When the UE and the MME does not share a
KASME the only possibility for an MME that allows unauthenticated IMS Emergency Sessions is to run with the NULL
integrity algorithm EIA0 and the NULL ciphering algorithm EEA0. These algorithms are not affected by the choice of
key. Therefore the UE and the MME independently generate a KASME in an implementation defined way and populate
the EPS NAS security context with this KASME to be used when activating an EPS NAS security context for which no
successful EPS AKA run has been made. After this EPS NAS security context is activated all key derivations proceed
as if they were based on a KASME generated from an EPS AKA run.
Even if no confidentiality or integrity protection is provided by EIA0 and EEA0, the UE and network treat the EPS
security context with the independently generated KASME as if it contained a normally generated KASME and hence share
an EPS security context (see TS 24.301[9]).
15.2.4.2
Handover
When UE attempts to make X2/S1 handover, UE and eNB derive and transfer the keys as normal to re-use the normal
handover mechanism. Since the derived keys have no ability to affect the output of the NULL algorithms it is irrelevant
that the network and the UE derive different keys. Furthermore, section 7.2.4a describes how the algorithm selection is
handled for unauthenticated emergency call. This implies that source eNB will forward UE EPS security capability
which contains EIA0 and EEA0 only to target eNB. So the target eNB can only select EIA0 for integrity protection and
EEA0 for confidential protection. If the UE does not receive any selection of new AS security algorithms during a intraeNB handover, the UE continues to use the same algorithms as before the handover (see TS 36.331 [21]).
NOTE:
If the target eNB is a Rel-8 eNB, it cant support EIA0 and EEA0. The handover will be rejected because
of the failure of algorithm negotiation.
ETSI
70
Annex A (normative):
Key derivation functions
A.1
A.1.1
General
All key derivations (including input parameter encoding) for EPS shall be performed using the key derivation function
(KDF) specified in TS 33.220 [8]. This clause specifies how to construct the input string, S, to the KDF (which is input
together with the relevant key). For each of the distinct usages of the KDF, the input parameters S are specified below.
A.1.2
FC value allocations
The FC number space used is controlled by TS 33.220 [8], FC values allocated for this specification are in range of
0x10 0x1F.
A.2
When deriving a KASME from CK, IK and SN id when producing authentication vectors, and when the UE computes
KASME during AKA, the following parameters shall be used to form the input S to the KDF.
-
FC = 0x10,
P0 = SN id,
P1 = SQN AK
The exclusive or of the Sequence Number (SQN) and the Anonymity Key (AK) is sent to the UE as a part of the
Authentication Token (AUTN), see TS 33.102. If AK is not used, AK shall be treated in accordance with TS 33.102,
i.e. as 0000.
The SN id consists of MCC and MNC, and shall be encoded as an octet string according to Figure A.2-1.
MCC digit 2
MCC digit 1
octet 1
MNC digit 3
MCC digit 3
octet 2
MNC digit 2
MNC digit 1
octet 3
ETSI
A.3
71
When deriving a KeNB from KASME and the uplink NAS COUNT in the UE and the MME the following parameters shall
be used to form the input S to the KDF.
-
FC = 0x11,
A.4
NH derivation function
When deriving a NH from KASME the following parameters shall be used to form the input S to the KDF.
-
FC = 0x12
P0 = SYNC-input
The SYNC-input parameter shall be the newly derived KeNB for the initial NH derivation, and the previous NH for all
subsequent derivations. This results in a NH chain, where the next NH is always fresh and derived from the previous
NH.
The input key shall be the 256-bit KASME.
A.5
When deriving a KeNB* from current KeNB or from fresh NH and the target physical cell ID in the UE and eNB as
specified in clause 7.2.8 for handover purposes the following parameters shall be used to form the input S to the KDF.
-
FC = 0x13
The input key shall be the 256-bit NH when the index in the handover increases, otherwise the current 256-bit KeNB.
A.6
Void
ETSI
A.7
72
When deriving keys for NAS integrity and NAS encryption algorithms from KASME and algorithm types and algorithm
IDs, and keys for RRC integrity, UP integrity in the case of relay nodes, and RRC/UP encryption algorithms from KeNB,
in the UE, MME and eNB the following parameters shall be used to form the string S.
-
FC = 0x15
P1 = algorithm identity
The algorithm type distinguisher shall be NAS-enc-alg for NAS encryption algorithms and NAS-int-alg for NAS
integrity protection algorithms. The algorithm type distinguisher shall be RRC-enc-alg for RRC encryption algorithms,
RRC-int-alg for RRC integrity protection algorithms, UP-enc-alg for UP encryption algorithms and, in the case of relay
nodes, UP-int-alg for UP integrity protection algorithms (see table A.7-1). The values 0x07 to 0xf0 are reserved for
future use, and the values 0xf1 to 0xff are reserved for private use.
Table A.7-1: Algorithm type distinguishers
Algorithm
distinguisher
NAS-enc-alg
NAS-int-alg
RRC-enc-alg
RRC-int-alg
UP-enc-alg
UP-int-alg
Value
0x01
0x02
0x03
0x04
0x05
0x06
The algorithm identity (as specified in clause 5) shall be put in the four least significant bits of the octet. The two least
significant bits of the four most significant bits are reserved for future use, and the two most significant bits of the most
significant nibble are reserved for private use. The entire four most significant bits shall be set to all zeros.
For NAS algorithm key derivations, the input key shall be the 256-bit KASME, and for UP and RRC algorithm key
derivations, the input key shall be the 256-bit KeNB.
For an algorithm key of length n bits, where n is less or equal to 256, the n least significant bits of the 256 bits of the
KDF output shall be used as the algorithm key.
A.8
This input string is used when there is a need to derive CK' || IK' from KASME during mapping of security contexts from
E-UTRAN to GERAN/UTRAN at handover. KASME is a 256-bit entity, and so is the concatenation of CK and IK (which
are 128 bits each). The following input parameters shall be used.
-
FC = 0x16
ETSI
A.9
73
The NAS-token used to ensure that a RAU is originating from the correct UE during IDLE mode mobility from EUTRAN to UTRAN and GERAN, shall use the following input parameters.
-
FC = 0x17
FC = 0x18
P0 = NONCEMME
FC = 0x19,
P0 = NONCEUE
P1 = NONCEMME
ETSI
74
FC = 0x1A
A.13
This input string is used when there is a need to derive CK' || IK' from KASME during mapping of security contexts from
E-UTRAN to GERAN/UTRAN at idle mobility. KASME is a 256-bit entity, and so is the concatenation of CK and IK
(which are 128 bits each). The following input parameters shall be used.
-
FC = 0x1B
A.14
(Void)
A.15
This input string is used when the MeNB and UE derive S-KeNB from KeNB during dual connectivity. The following
input parameters shall be used:
-
FC = 0x1C
ETSI
75
Annex B (normative):
Algorithms for ciphering and integrity protection
B.0
The EEA0 algorithm shall be implemented such that it has the same effect as if it generates a KEYSTREAM of all
zeroes (see subclause B.1.1). The length of the KEYSTREAM generated shall be equal to the LENGTH input
parameter. The generated KEYSTREAM requires no other input parameters but the LENGTH. Apart from this, all
processing performed in association with ciphering shall be exactly the same as with any of the ciphering algorithms
specified in this Annex.
The EIA0 algorithm shall be implemented in such way that it shall generate a 32 bit MAC-I/NAS-MAC and XMACI/XNAS-MAC of all zeroes (see subclause B.2.1). Replay protection shall not be activated when EIA0 is activated. All
processing performed in association with integrity (except for replay protection) shall be exactly the same as with any
of the integrity algorithms specified in this annex except that the receiver does not check the received MAC.
NOTE 1: The reason for mentioning the replay protection here is that replay protection is associated with integrity.
EIA0 shall be used only for emergency calling for unauthenticated UEs in LSM.
NOTE 2: a UE with a 2G SIM is considered to be in LSM in E-UTRAN.
NOTE 3: EEA0 and EIA0 provide no security.
B.1
B.1.1
The input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, a 32-bit COUNT, a 5-bit bearer
identity BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the length of the keystream required i.e.
LENGTH. The DIRECTION bit shall be 0 for uplink and 1 for downlink.
Figure B.1-1 illustrates the use of the ciphering algorithm EEA to encrypt plaintext by applying a keystream using a bit
per bit binary addition of the plaintext and the keystream. The plaintext may be recovered by generating the same
keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext.
ETSI
76
DIRECTION
COUNT
BEARER
KEY
LENGTH
EEA
DIRECTION
COUNT
BEARER
KEY
KEYSTREAM
BLOCK
PLAINTEXT
BLOCK
LENGTH
EEA
KEYSTREAM
BLOCK
CIPHERTEXT
BLOCK
Sender
PLAINTEXT
BLOCK
Receiver
B.1.2
128-EEA1
128-EEA1 is based on SNOW 3G and is identical to UEA2 as specified in [14]. The used IV is constructed the same
way as in subclause 3.4 of that TS.
B.1.3
128-EEA2
B.1.4
128-EEA3
ETSI
77
B.2
B.2.1
The input parameters to the integrity algorithm are a 128-bit integrity key named KEY, a 32-bit COUNT, a 5-bit bearer
identity called BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the message itself i.e
MESSAGE. The DIRECTION bit shall be 0 for uplink and 1 for downlink. The bit length of the MESSAGE is
LENGTH.
Figure B.2-1 illustrates the use of the integrity algorithm EIA to authenticate the integrity of messages.
COUNT
DIRECTION
MESSAGE
KEY
COUNT
BEARER
MESSAGE
KEY
EIA
Sender
DIRECTION
BEARER
EIA
XMAC-I/XNAS-MAC
MAC-I/NAS-MAC
Receiver
B.2.2
128-EIA1
128-EIA1 is based on SNOW 3G and is implemented in the same way as UIA2 as specified in [14]. The used IV is
constructed the same way as in subclause 4.4 of that TS, with the only difference being that FRESH [0], FRESH [31]
shall be replaced by BEARER[0] BEARER[4] 027 (i.e. 27 zero bits)
B.2.3
128-EIA2
ETSI
78
AES in CMAC mode is used with these inputs to produce a Message Authentication Code T (MACT) of length Tlen =
32. T is used directly as the 128-EIA2 output MACT[0] .. MACT[31], with MACT[0] being the most significant bit of
T.
B.2.4
128-EIA3
ETSI
79
Annex C (informative):
Algorithm test data
C.1
128-EEA2
This section includes six test data sets; all are presented in hex, while the first is also presented in binary. Some
intermediate computational values are included to assist implementers in tracing bugs. Some notation is taken from the
specification of CTR mode [16].
Bit ordering should be largely self explanatory, but in particular:
-
The 5-bit BEARER is written in hex in a "right aligned" form, i.e. as a two-hex-digit value in the range 00 to 1F
inclusive, with BEARER [0] as the msb of the first digit.
Similarly the single DIRECTION bit is written in hex in "right aligned" form, i.e. the DIRECTION bit is the lsb
of the hex digit.
Where the length of plaintext and ciphertext is not a multiple of 32 bits, they are written in hex in a "left
aligned" form, i.e. the least significant few bits of the last word will be zero.
C.1.1
Test Set 1
Key
Key
Count
= (hex) 398a59b4
Count
Bearer
= (hex) 15
Bearer
= (bin) 10101
Direction = (hex) 1
Direction = (bin) 1
Length
= 253 bits
Plaintext = (hex) 981ba682 4c1bfb1a b4854720 29b71d80 8ce33e2c c3c0b5fc 1f3de8a6 dc66b1f0
Plaintext = (bin) 10011000 00011011 10100110 10000010 01001100 00011011 11111011 00011010
10110100 10000101 01000111 00100000 00101001 10110111 00011101 10000000
10001100 11100011 00111110 00101100 11000011 11000000 10110101 11111100
00011111 00111101 11101000 10100110 11011100 01100110 10110001 11110
ETSI
80
Keystream block 1 = (bin) 01110001 11100101 01111110 00100100 01110001 00001110 10101000 00011110
01100011 10011000 10110101 00101011 11011010 01011111 00111111 10010100
Counter block T2 = (hex) 398a59b4 ac000000 00000000 00000001
Counter block T2 = (bin) 00111001 10001010 01011001 10110100 10101100 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001
Keystream block 2 = (hex) 3eede9f6 11328620 231f3f1b 328b3f88
Keystream block 2 = (bin) 00111110 11101101 11101001 11110110 00010001 00110010 10000110 00100000
00100011 00011111 00111111 00011011 00110010 10001011 00111111 10001000
Ciphertext = (hex) e9fed8a6 3d155304 d71df20b f3e82214 b20ed7da d2f233dc 3c22d7bd eeed8e78
Ciphertext = (bin) 11101001 11111110 11011000 10100110 00111101 00010101 01010011 00000100
11010111 00011101 11110010 00001011 11110011 11101000 00100010 00010100
10110010 00001110 11010111 11011010 11010010 11110010 00110011 11011100
00111100 00100010 11010111 10111101 11101110 11101101 10001110 01111
C.1.2
Test Set 2
Key
Count
= c675a64b
Bearer
= 0c
Direction = 1
Length
= 798 bits
ETSI
81
C.1.3
Test Set 3
Key
Count
= 544d49cd
Bearer
= 04
Direction = 0
Length
= 310 bits
C.1.4
Test Set 4
Key
Count
= 72d8c671
Bearer
= 10
Direction = 1
ETSI
Length
82
= 1022 bits
C.1.5
Test Set 5
Key
Count
= c675a64b
Bearer
= 0c
Direction = 1
Length
= 1245 bits
ETSI
83
C.1.6
Test Set 6
Key
Count
= aca4f50f
ETSI
Bearer
84
= 0b
Direction = 0
Length
= 3861 bits
ETSI
85
ETSI
86
C.2
128-EIA2
This section includes eight test data sets; all are presented in hex, while the first is also presented in binary. Many
intermediate computational values are included to assist implementers in tracing bugs. Some notation is taken from the
specification of CMAC mode [17].
Bit ordering should be largely self explanatory, but in particular:
ETSI
87
The 5-bit BEARER is written in hex in a "right aligned" form, i.e. as a two-hex-digit value in the range 00 to 1F
inclusive, with BEARER [0] as the msb of the first digit.
Similarly the single DIRECTION bit is written in hex in "right aligned" form, i.e. the DIRECTION bit is the lsb
of the hex digit.
Where the length of the message, or of a message sub-block, is not a multiple of 32 bits, it is written in hex in a
"left aligned" form, i.e. the least significant few bits of the last word will be zero.
NOTE: This section provides both byte aligned and non byte aligned test data sets. For EPS implementation
verification, byte alignment test data sets (2, 5 and 8) can be used, as EPS RRC and EPS NAS messages
are byte aligned. The non byte aligned test data sets may be used to verify implementations that support
non byte aligned messages.
C.2.1
Test Set 1
= (hex) 18
Bearer
= (bin) 11000
Direction = (hex) 0
Direction = (bin) 0
IK
IK
Length
= 58 bits
CMAC(K, M):
K
Mlen
= 122
Subkey Generation:
L
ETSI
88
K1
K1
K2
K2
MAC Generation:
n
=1
Mn*
Mn*
Mn
Mn
C0
C0
M1
M1
C1
C1
MACT
= (hex) 118c6eb8
MACT
C.2.2
Test Set 2
Count-I
= 398a59b4
Bearer
= 1a
Direction = 1
IK
Length
= 64 bits
Message
= 484583d5 afe082ae
ETSI
89
CMAC(K, M):
K
Mlen
= 128
Subkey Generation:
L
K1
K2
MAC Generation:
n
= 1
Mn*
Mn
C0
M1
C1
MACT
= b93787e6
C.2.3
Test Set 3
Count-I
= 36af6144
Bearer
= 18
Direction = 1
IK
Length
= 254 bits
Message
CMAC(K, M):
K
Mlen
= 318
Subkey Generation:
L
K1
K2
ETSI
90
MAC Generation:
n
= 3
Mn*
= eeaf1321 ba5929dc
Mn
C0
M1
C1
M2
C2
M3
C3
MACT
= 1f60b01d
C.2.4
Test Set 4
Count-I
= c7590ea9
Bearer
= 17
Direction = 0
IK
Length
= 511 bits
Message
CMAC(K, M):
K
Mlen
= 575
Subkey Generation:
L
K1
K2
MAC Generation:
n
= 5
Mn*
= 05d84580 bee5bc7e
Mn
ETSI
M1
C1
M2
C2
M3
C3
M4
C4
M5
C5
MACT
= 6846a2f0
C.2.5
91
Test Set 5
Count-I
= 36af6144
Bearer
= 0f
Direction = 1
IK
Length
= 768 bits
Message
CMAC(K, M):
K
Mlen
= 832
Subkey Generation:
L
K1
K2
MAC Generation:
n
= 7
ETSI
= 74cda5a4 85f74d7a
Mn
C0
M1
C1
M2
C2
M3
C3
M4
C4
M5
C5
M6
C6
M7
C7
MACT
= e657e182
C.2.6
92
Test Set 6
Count-I
= 36af6144
Bearer
= 18
Direction = 0
IK
Length
= 383 bits
Message
CMAC(K, M):
K
Mlen
= 447
Subkey Generation:
L
K1
K2
ETSI
93
MAC Generation:
n
= 4
Mn*
= c0b5fc1f 3de8a6dc
Mn
C0
M1
C1
M2
C2
M3
C3
M4
C4
MACT
= f0668c1e
C.2.7
Test Set 7
Count-I
= 7827fab2
Bearer
= 05
Direction = 1
IK
Length
= 2558 bits
Message
CMAC(K, M):
K
Mlen
= 2622
ETSI
94
Subkey Generation:
L
K1
K2
MAC Generation:
n
= 21
Mn*
= f977fbac 4dfa35ec
Mn
C0
M1
C1
M2
C2
M3
C3
M4
C4
M5
C5
M6
C6
M7
C7
M8
C8
M9
C9
M10
ETSI
M11
C11
M12
C12
M13
C13
M14
C14
M15
C15
M16
C16
M17
C17
M18
C18
M19
C19
M20
C20
M21
C21
MACT
= f4cc8fa3
C.2.8
95
Test Set 8
Count-I
= 296f393c
Bearer
= 0b
Direction = 1
IK
Length
= 16448 bits
Message
ETSI
96
ETSI
97
CMAC(K, M):
K
Mlen
= 16512
ETSI
98
ETSI
99
Subkey Generation:
L
K1
K2
MAC Generation:
n
= 129
Mn*
Mn
C0
M1
C1
M2
C2
M3
C3
M4
C4
M5
C5
M6
C6
M7
C7
M8
C8
M9
C9
M10
C10
M11
C11
ETSI
C12
M13
C13
M14
C14
M15
C15
M16
C16
M17
C17
M18
C18
M19
C19
M20
C20
M21
C21
M22
C22
M23
C23
M24
C24
M25
C25
M26
C26
M27
C27
M28
C28
M29
C29
M30
C30
M31
C31
100
ETSI
C32
M33
C33
M34
C34
M35
C35
M36
C36
M37
C37
M38
C38
M39
C39
M40
C40
M41
C41
M42
C42
M43
C43
M44
C44
M45
C45
M46
C46
M47
C47
M48
C48
M49
C49
M50
C50
M51
C51
101
ETSI
C52
M53
C53
M54
C54
M55
C55
M56
C56
M57
C57
M58
C58
M59
C59
M60
C60
M61
C61
M62
C62
M63
C63
M64
C64
M65
C65
M66
C66
M67
C67
M68
C68
M69
C69
M70
C70
M71
C71
102
ETSI
C72
M73
C73
M74
C74
M75
C75
M76
C76
M77
C77
M78
C78
M79
C79
M80
C80
M81
C81
M82
C82
M83
C83
M84
C84
M85
C85
M86
C86
M87
C87
M88
C88
M89
C89
M90
C90
M91
C91
103
ETSI
C92
M93
C93
M94
C94
M95
C95
M96
C96
M97
C97
M98
C98
M99
C99
M100
C100
M101
C101
M102
C102
M103
C103
M104
C104
M105
C105
M106
C106
M107
C107
M108
C108
M109
C109
M110
C110
M111
C111
104
ETSI
C112
M113
C113
M114
C114
M115
C115
M116
C116
M117
C117
M118
C118
M119
C119
M120
C120
M121
C121
M122
C122
M123
C123
M124
C124
M125
C125
M126
C126
M127
C127
M128
C128
M129
C129
MACT
= ebd5ccb0
105
ETSI
C.3
106
128-EEA1
No new test data are provided for 128-EEA1, because the test data for UEA2 can be reused directly there is an exact,
one-to-one mapping between UEA2 inputs and 128-EEA1 inputs.
C.4
128-EIA1
This section includes seven test data sets; all are presented in hex, while the first is also presented in binary
Bit ordering should be largely self explanatory, but in particular:
-
The 5-bit BEARER is written in hex in a "right aligned" form, i.e. as a two-hex-digit value in the range 00 to 1F
inclusive, with BEARER [0] as the msb of the first digit.
Similarly the single DIRECTION bit is written in hex in "right aligned" form, i.e. the DIRECTION bit is the lsb
of the hex digit.
Where the length of the message, or of a message sub-block, is not a multiple of 32 bits, it is written in hex in a
"left aligned" form, i.e. the least significant few bits of the last word will be zero.
NOTE: This section provides both byte aligned and non byte aligned test data sets. For EPS implementation
verification, byte alignment test data sets (1, 4 and 7) can be used, as EPS RRC and EPS NAS messages
are byte aligned. The non byte aligned test data sets may be used to verify implementations that support
non byte aligned messages.
C.4.1
Test Set 1
Count-I
= (hex) 38a6f056
Count-I
Bearer
= (hex) 1f
Bearer
= (bin) 11111
Direction = (hex) 0
Direction = (bin) 0
IK
IK
Length
= 88 bits
Message
Message
MACT
= (hex) 731f1165
MACT
C.4.2
Test Set 2
Count-I
= 36af6144
Bearer
= 18
Direction = 1
IK
ETSI
107
Length
= 254 bits
Message
MACT
= e3259f6f
C.4.3
Test Set 3
Count-I
= c7590ea9
Bearer
= 17
Direction = 0
IK
Length
= 511 bits
Message
MACT
C.4.4
= 9a16c77d
Test Set 4
Count-I
= 36af6144
Bearer
= 0f
Direction = 1
IK
Length
= 768 bits
Message
MACT
C.4.5
= bba74492
Test Set 5
Count-I
= 36af6144
Bearer
= 18
Direction = 0
IK
Length
= 383 bits
Message
MACT
C.4.6
= 4145e4b0
Test Set 6
Count-I
= 7827fab2
Bearer
= 05
Direction = 1
ETSI
108
IK
Length
= 2558 bits
Message
MACT
C.4.7
= 0fa2b1ee
Test Set 7
Count-I
= 296f393c
Bearer
= 0b
Direction = 1
IK
Length
= 16448 bits
Message
ETSI
109
ETSI
110
= abf3e651
ETSI
111
Annex D (normative):
Security for Relay Node Architectures
D.1
Introduction
This Annex provides the security procedures applied to relay nodes. Security requirements and security features applied
to relay nodes can be found in the main body of the present specification.
The overall stage 2 description for relay nodes can be found in 3GPP TS 23.401 [2] and 3GPP TS 36.300 [30].
D.2
Solution
D.2.1
General
The basic idea of the solution for relay node security presented in this Annex is realizing a one-to-one binding of an RN
and a USIM called USIM-RN. Such a one-to-one binding is realized in this solution either by using symmetric preshared keys (psk) or by certificates. In the psk case, the binding needs to be pre-established in the UICC and in the RN
prior to deployment; in the certificate case, the binding needs to be pre-established only in the UICC prior to
deployment. The use of certificates has the advantage that there is a standardized procedure for enrolling the private key
corresponding to the certificate in the secure environment of the RN while the use of a psk requires manual operation
for establishing the psk. A further advantage is that the name (identity) in the certificate can be given at time of
enrolment, and does not have to be pre-established. On the other hand, the use of a psk has the advantage that no PKI is
required and the procedure after pre-establishment of the psk is simpler. When using certificates for this one-to-one
binding, a part of the usual certificate handling is replaced by subscription handling, as explained in Annex D.2.6.
The certificate-based procedures are mandatory to support.
The pre-shared-key-based procedures are mandatory to support.
NOTE 1: The provisioning of pre-shared keys is out of the scope of this document.
When using certificates the UICC inserted in the RN shall contain two USIMs: a USIM-RN which shall perform any
communication only via a secure channel, and a USIM-INI communicating with the RN without secure channel and
used for initial IP connectivity purposes prior to RN attachment. The UICC shall establish a secure channel only with a
particular relay node, as detailed in the procedures described in D.2.2. The UICC verifies this relay node by means of
data pre-established in the UICC.
When using psk only the USIM-RN is required. This USIM-RN shall perform any communication only via a secure
channel.
NOTE 2: USIM-INI and USIM-RN are described in TS 31.102 [3].
D.2.2
Security Procedures
The start-up of an RN shall proceed in the following steps, which are arranged in three phases. The Preparation Phase
and Phase II procedures are the same for the certificate-based and the PSK-based case. Phase I procedures differ
between the certificate-based case and the pre-shared key based case. If one of the steps fails in any of the involved
entities the procedure shall be aborted by that entity, and the steps that follow the failed step shall not be executed (but
the sending of failure messages is possible).
Preparation Phase:
The RN platform secure environment shall perform an integrity check of the RN platform. This shall include checking
the integrity of the sensitive parts of the boot process and proceeding with the boot process only if the integrity checks
of all these parts are successful.
ETSI
112
Void.
Ec2.
Ec3. The RN shall obtain an operator certificate through the enrolment procedure defined in TS 33.310 [6] unless
an operator certificate is already available. Details can be found in clause D.2.4. The RN may optionally
establish a secure connection to an OAM server. Details can be found in clause D.2.5. The RN shall retrieve a
CRL from a suitable server if no valid CRL is available locally in the RN and the RN supports and is configured
to perform CRL checks. For revocation checking of UICC certificates see clause D.2.6. For the handling of
CRLs for UICC certificates see also clause D.3.3.4.
Ec4. After completing step Ec3, the RN shall detach from the network and de-activate the USIM-INI if it attached
in step Ec2. If the UICC needs to be configured over the air (OTA) this may also be done in this step.
Ec5. The RN platform secure environment and the UICC shall establish a Secure Channel between RN and USIMRN according to ETSI TS 102 484 [29] clause 7 "Secured APDU" with TLS handshake. This TLS handshake
shall be initiated by the RN and use certificates on both sides. The RN shall either use a pre-established
certificate or the certificate enrolled in step Ec3. The UICC shall verify that this certificate belongs to the relay
node the USIM-RN is bound to. The UICC shall be pre-provisioned with an operator root certificate to verify the
RN certificate. The UICC certificate shall be pre-installed in the UICC by the operator. The RN shall be
provisioned with a root certificate to verify the UICC certificate.
Ec6. A certificate validation client on the UICC shall verify the signatures in the RN certificate chain up to the
root certificate. The check of revocation status and expiry time shall be omitted. A certificate validation client on
the RN shall check the verification of the signatures in the UICC certificate chain up to the root certificate as
well as the expiry time. The revocation status of the UICC certificate should be checked by means of CRLs.
Furthermore, the requirements in clause D.2.3 on USIM Binding Aspects shall apply.
NOTE 1: The root certificate, and potentially other data required, that need to be stored in the UICC could be
provisioned in the UICC during its personalization. The operator provides to smart card manufacturer a
list of data (e.g. IMSI, key K, etc) to be provisioned in the UICC during its personalization phase, before
issuance of the UICC. The root certificate, and potentially other data, could be provided by the operator
as part of the data to be personalized in the UICC by the smart card manufacturer. In the field, the root
certificate, and potentially other data, could also be updated by OTA means, if needed.
The private key corresponding to the RN certificate and the root certificate used to verify the UICC certificate shall be
stored in the secure environment of the RN platform validated in the Preparation Phase, and the TLS connection as well
as the secure channel with the UICC shall terminate there. From the completion of this step onwards, all communication
between the USIM-RN and the RN shall be protected by the Secure Channel.
The USIM-RN shall not engage in any communication with any entity prior to the the completion of establishment of
the Secure Channel according to steps Ec5 and Ec6 other than messages for establishing the Secure Channel according
to ETSI TS 102 484 [29] clause 7 "Secured APDU".
NOTE 2: Certificate use restriction may be made possible e.g. through a suitable name structure, or a particular
intermediate CA in the verification path, or policy information terms, e.g. by a suitable object identifier
(OID) in the certificate policies extension.
ETSI
113
NOTE 3: ETSI TS 102 484 [29] states in clause 6.2.2: "The UICC may present a self-signed certificate. The
terminal or terminal application should temporarily accept such a certificate during the TLS handshake
protocol, if it is able to establish by other means (e.g. successful network authentication) that the
handshake protocol is conducted with an authentic UICC." Similar considerations apply when the method
in ETSI TS 102 484 [29] in clause 7 "Secured APDU" with TLS handshake is used as is the case in the
present document. And in the present solution for relay node security, the RN indeed verifies the
authenticity of the USIM-RN by means of a successful RN attach procedure. However, the use of a selfsigned UICC certificate, or no UICC certificate at all, is not allowed here as this would weaken the
protection against certain attacks, cf. clause D.2.6.
NOTE 4: It is proposed here that the RN assumes the role of TLS client in line with ETSI TS 102 484 [29], clause
7, on "Secured APDU" with TLS handshake.
NOTE 5: One may want to limit the lifetime of a secure channel between USIM-RN and RN for security reasons.
Suitable counters providing such a limit include a transaction counter, cf. clause 5 of ETSI TS 102 484
[29]. Details can be found in stage 3 specifications.
NOTE 6: Having two USIMs on one UICC is a standard feature available today (but only one USIM can be active
at a time in current 3GPP specifications).
NOTE 7: The RN could distinguish a USIM-RN from a USIM-INI e.g. by the use of so-called "Application
Identifiers (AID)" for UICC applications.
Phase I: Procedures prior to the RN attach procedure (pre-shared key based case)
For the psk-based case, there may be some cases when skipping of Phase I attachment is possible. Such cases are
outside the scope of the present document.
Ep1. Void.
Ep2. The RN platform secure environment and the UICC shall establish a Secure Channel between RN and USIMRN according to ETSI TS 102 484 [29] clause 7 "Secured APDU" using a pre-shared key. Furthermore, the
requirements in clause D.2.3 on USIM Binding Aspects shall apply.
The pre-shared key shall be stored in the secure environment of the RN platform validated in the Preparation
Phase, and the secure channel with the UICC shall terminate there. From the completion of this step onwards, all
communication between the USIM-RN and the RN shall be protected by the Secure Channel.
The USIM-RN shall not engage in any communication with any entity prior to the completion of the
establishment of the Secure Channel according to step Ep2 other than messages for establishing the Secure
Channel according to ETSI TS 102 484 [29] clause 7 "Secured APDU".
Ep3. The RN may optionally establish a secure connection to an OAM server. Details can be found in clause
D.2.5.
Ep4. The RN shall detach from to the network if it attached for performing step Ep3.
NOTE 8: The use of the pre-shared key variant requires that the RN is configured with this pre-shared key e.g. in
the factory, or at the operators premises or in the field during RN installation. The corresponding
procedures are out of scope of the present document. For the UICC, the regular personalization
procedures are expected to apply.
NOTE 9: One may want to limit the lifetime of a secure channel between USIM-RN and RN for security reasons.
Suitable counters providing such a limit include a record counter, cf. clause 6.4 of ETSI TS 102 484 [29],
or a transaction counter, cf. clause 5 of ETSI TS 102 484 [29]. Details can be found in stage 3
specifications.
Phase II: RN attach procedure (pre-shared key case and certificate-based case)
It is required that a secure channel between RN and USIM-RN exists throughout the execution of phase II.
The RN shall perform the RN attach procedure for EPS as defined in TS 36.300 [30], using the USIM-RN. In addition,
the following security-related steps shall be performed:
ETSI
114
A1. If the USIM-RN is not already active the RN shall activate it and shall establish a new secure channel
according to Ec5, Ec6 in the certificate-based case and Ep2 in the pre-shared key based case respectively. The
RN shall use the IMSI (or a related GUTI) pertaining to the USIM-RN in the RN attach procedure.
NOTE 10: In the certificate-based case this IMSI differs from the one pertaining to the USIM-INI, therefore the
network can distinguish the handling of the two USIMs.
A2. The S1 Initial UE message shall indicate that the attachment is for an RN. Upon receipt of this message the
MME-RN shall run EPS AKA with the RN and the USIM-RN. The RN shall accept only authentication
responses and keys in an RN attach procedure that were received from the USIM-RN over the Secure Channel.
A3. The MME-RN shall check from the RN-specific subscription data received from the HSS that the USIM-RN
is permitted for use in RN attach procedures. When this is not the case, but the S1 Initial UE message indicated
that the attachment is for an RN, the MME-RN shall reject the Attach request and indicate to the DeNB that the
set-up has failed.
A4. The MME-RN and RN shall establish NAS security. Upon receipt of the S1 INITIAL CONTEXT SETUP
message the DeNB and the RN shall set up AS security over Un as specified in the present document.
A5. The RN may establish a secure connection to an OAM server in this phase to complete the configuration.
Details can be found in clause D.2.5.
The RN start-up is now complete from a security point of view, and UEs can start attaching to the RN.
D.2.3
There shall be a one-to-one association between the USIM-RN and the RN.
In the pre-shared key case, this one-to-one association is ensured by the fact that the key that is pre-shared between the
USIM-RN and the RN shall not be available in any other entity.
In the certificate-based case, this one-to-one association is ensured by the following requirements:
-
The UICC shall verify the RN identity, represented by the RN identity in the certificate, through the TLS
handshake as part of the secure channel set-up, and shall check whether it coincides with the locally stored
identity of the RN authorized to set up a secure channel with the USIM-RN;
The procedures for managing the binding between USIM-RN and the RN are out of scope of the present document.
The UICC may know the identity of the RN authorized to set up a secure channel with the USIM-RN by configuration.
The standard secure OTA mechanisms (TS 31.116 [31]) can be used to update the configuration of UICC and renew the
stored identities if required.
NOTE: The RN identity is contained in the subject name of the RN certificate. It is described in detail in clause
D.3.3 of the present document and in TS 31.102 [13].
D.2.4
ETSI
115
(2) The RN may attach to an eNB like a normal UE using a USIM, called USIM-INI, different from the one used in
the RN attach procedure to the DeNB, called USIM-RN. No secure channel between RN and USIM-INI is
required.
In both cases, the network shall ensure that the destinations the RN can reach are restricted to only the PDN(s) where
the RA (Registration Authority for the certificate enrolment) and other servers to be contacted during phase I, e.g. the
OAM server are located. In case (2) this shall be ensured by restricting IP traffic originating from the RN and sent only
to certain destinations (APNs). The restrictions are assumed to be part of the profile relating to the subscription
associated with the USIM-INI.
D.2.5
The requirements on communication between the OAM systems and the eNB from clause 5.3.2 shall apply for relay
nodes in both phases I and II. The mechanisms used to fulfil these requirements shall include applying security
association(s) that extend between the RN and an entity in the Evolved Packet Core (EPC) or in an OAM domain
trusted by the operator.
NOTE 1: No mechanisms used to fulfil these requirements are mandated in the present document. But example
mechanisms are given in NOTE 3 below. NOTE 3 is followed by normative text, which applies if the
example mechanisms are used.
NOTE 2: In case of offline configuration of the RN, the security measures used to fulfil the requirements from
clause 5.3.2 are out of scope of the present document.
NOTE 3: Examples for mechanisms to secure OAM communication to and from RNs are:
- end-to-end security terminated within or just in front of the OAM server;
- hop-by-hop security via SEG in EPC which is particularly suited for multiple management connections
to separate OAM servers located within one "management domain".
If IKEv2/IPsec or TLS with authentication based on certificates is used for the security association(s), the protocol
profiles for IPsec in TS 33.210 [5] and for IKEv2 and TLS in TS 33.310 [6] and the certificate profiles given in
TS 33.310 [6] should be followed.
NOTE 4: As the USIM-INI can be accessed by any UE, an attacker can use the USIM-INI to connect to the APN
used for OAM in phase I. In case of end-to-end security the OAM server itself has to be secured
accordingly. In the hop-by-hop case the SEG can defend against attacks (e.g. DoS attacks) carried out via
this channel.
The RN requires IP connectivity for the management procedure to be able to reach the OAM server.
For the pre-shared key case in Phase I, IP connectivity can be established after step Ep2 with the RN attaching to an
eNB like a normal UE using the USIM-RN.
For the certificate-based case in Phase I, IP connectivity established for enrolment purposes according to clause D.2.4
may be re-used, or, if not available, it may be established in the same ways as described in clause D.2.4.
Restrictions on the destinations the RN can reach shall apply if the communication with the OAM server prior to the
RN attach procedure is based on USIM-INI. They shall be realized in the same way as described in clause D.2.4.
D.2.6
Whenever the operator intends to prevent the RN from attaching to the network the operator shall bar the subscription
relating to the USIM-RN in the HSS.
In the certificate-based case the barring of the subscription relating to the USIM-RN shall be performed also whenever
the RN certificate has to be revoked, or whenever the UICC certificate has to be revoked and the RN is not configured
to always check the UICC certificate against a CRL, cf. below.
In the pre-shared key case, the barring of the subscription relating to the USIM-RN may be performed also whenever
the operator sees a risk that the pre-shared key between the USIM-RN and RN has been compromised.
ETSI
116
NOTE 0: In the certificate-based case, checking the UICC certificate against a CRL and barring the subscription
relating to the USIM-RN are not equivalent. The former could prevent the following attack while the
latter could not: an attacker in possession of a compromised private key relating to the UICC certificate
could get stolen RNs to work in his own network as then the attacker could use a fake UICC, with
subscription data generated by himself, towards the RN to set up a secure channel. Subscription barring
would not be effective in the attackers network while the CRL check by the RN would ensure that the
RN cannot attach as an RN to a network other than the one of the operator who provisioned the root
certificate in the RN. If the operator deems the risk of such an attack low he may configure his RNs to not
use CRL checks against UICC certificates.
NOTE 0a: In the pre-shared key case, the proprietary measures may need to consider the attack described in the
preceding NOTE 0.
The remainder of this subclause applies only to the certificate-based case.
As described in clause D.2.2, step Ec6, the certificate validation client on the UICC verifies the signatures in the RN
certificate chain up to the root certificate, but omits the check of revocation status and expiry time. To achieve the same
effect as checking RN certificates revocation status and expiry time, the associated USIM-RN subscription shall be
barred in the HSS. This process is called invalidation in this document and is explained further below.
A certificate validation client on the RN shall check the verification of the signatures in the UICC certificate chain up to
the root certificate as well as the expiry time. The revocation status of the UICC certificate should be checked by means
of the CRL obtained by the RN in clause D.2.2, step Ec3. The CRL check is optional to support by the RN.
Further considerations on RN certificate and USIM-RN subscription handling:
By using the one-to-one binding of RN and USIM-RN, a part of the usual certificate handling is replaced by
subscription handling, as explained below:
Binding in network: The one-to-one binding of RN and USIM-RN shall be expressed by a one-to-one mapping of the
RN identity in any certificate issued to the RN and the IMSI in the USIM-RN. The operator shall maintain a table with
this mapping (the "mapping table").
Binding in UICC: cf. clause D.2.3.
Lifetime: The subscription shall have a limit on its lifetime. When the lifetime of the subscription is exceeded the
subscription shall be barred in the HSS. The lifetime shall not be greater than the lifetime of the RN certificate. The
latter is not checked in the UICC, cf. clause D.2.2.
RN Certificate revocation and invalidation: Whenever the operator decides that the RN certificate shall no longer be
used for setting up a secure channel with the USIM-RN the operator does not use CRLs or OCSP, but shall retrieve the
IMSI associated with the subject name in the RN certificate and bar the subscription corresponding to the IMSI in the
HSS. The certificate shall also be revoked, but the operator does not need to use CRLs or OCSP in this context. This
implies that no new certificate shall be issued for the same RN identity from that point onwards. In case the RN
certificate is also used for other purposes, e.g. for protecting an OAM connection, then, additionally, the usual PKI
revocation procedures apply.
RN compromise: If the operator has reason to believe that an RN has been compromised the RN certificate shall be
invalidated and revoked as described above.
RN Certificate renewal: This process may be used as normal as long as the RN identity in the RN certificate remains the
same.
NOTE 1: Certificate renewal with private key change may be useful even if the UICC does not check the expiry
time of the certificate as, in this way, the use of the private key can be limited if desired.
RN Certificate expiry:
NOTE 2: As the UICC has no clock it cannot check the expiry time and, hence, the RN could also use an expired
certificate in the secure channel set-up. As the certificate is only checked by the UICC for RN platform
authentication in the secure channel set-up this is not a problem as long as the corresponding private key
has not left the secure environment of the RN. More generally, if there is a risk that it has been
compromised the operator will bar the corresponding subscription in the HSS. The use of the certificate is
limited by the lifetime of the subscription bound to the RN. However, a UICC can be re-used with a
different RN after having been re-configured with a different RN identity.
ETSI
117
D.3
D.3.1
General
The clause D.3 profiles the algorithms to be used on the APDU secure channel, cf. ETSI TS 102 484 [29]. In addition it
specifies the profiles for the different key agreement methods.
For the case when certificates are used for key agreement, the profiles are given for the TLS handshake used to provide
key material for the Master SA of the secure channel between USIM-RN and RN, and for the certificates used in UICC
and RN for mutual authentication during TLS handshake. For the psk case requirements on the key agreement with preshared keys are given.
D.3.2
For communication between the USIM-RN and the RN a secure channel according to the APDU secure channel as
specified in ETSI TS 102 484 [29] shall be used. Further detailing of the secure channel is given in TS 31.102 [13].
For encryption, AES-CBC as specified in ETSI TS 102 484 [29] shall be mandatory to support. Other encryption
algorithms specified in ETSI TS 102 484 [29] may be supported. The algorithm "3DES - outer CBC using 2 keys" shall
not be used.
NOTE 1: The algorithm "3DES - outer CBC using 2 keys" is outdated.
For integrity protection, AES-CMAC as specified in ETSI TS 102 484 [29] shall be mandatory to support. Other
integrity protection algorithms specified in ETSI TS 102 484 [29] shall not be used.
NOTE 2: The algorithm CRC32 is for redundancy check only, and not a cryptographic checksum. The algorithm
"ANSI Retail MAC" is not fit for long-term usage in the scope of the present document.
D.3.3
the support of the ciphersuite mandatory for TLS 1.1 as described in TS 33.310 [6] is not required;
the support of fallback to TLS 1.0 as described in TS 33.310 [6] is not required;
the support of the SHA-1 algorithm for use before signing the certificate as described in TS 33.310 [6] is not
required;
ETSI
118
only the subject name format with "(C=<country>), O=<Organization Name>, CN=<Some distinguishing
name>" is mandatory to support.
the subject name shall be unique within all subject names issued by CAs under the same root CA;
the subject name may additionally contain the attribute "serialNumber=<serial number>";
the support of the countryName (C) and serialNumber attributes in the subject name is mandatory;
NOTE 1: The usage of the countryName (C) and serialNumber attributes can support the operator in generating a
unique identity for an RN.
-
the CRL distribution point is not used if the RN certificate is only used in the setup of the secure channel with
the UICC. Therefore the CRL distribution point is optional in this case.
NOTE 2: It may be desired to deploy the same RN certificate also for RN platform authentication to other network
elements of the operator, e.g. if TLS with mutual authentication is used for an OAM connection. The
profile given above is intended to allow such usage. Regarding the implementation of certificate handling
in the UICC it should be noted that for this additional usage of the RN certificate the existence of
additional fields in the certificate is possible, e.g. of the subjectAltName and/or the CRL distribution
point, which are not relevant for the secure channel between RN and UICC.
NOTE 1: The CRL distribution point and the support for CRL infrastructure for the UICC certificate is only needed
if the revocation check of the UICC certificate is performed during setup of the secure channel (cf. clause
D.2.6).
NOTE 2: In common TLS usage, the RN learns the UICC certificate only during TLS handshake, when the IP
connectivity to the core network using USIM-INI may no longer be available. Thus the CRL distribution
point for CRLs having UICC certificates in scope would be known too late to allow the RN to retrieve an
up-to-date CRL from the network. By reading the UICC certificate from the UICC before the
establishment of the secure channel starts, the RN may learn the CRL distribution point while it still has
IP connectivity based on USIM-INI, cf. step Ec3 in clause D.2.2. For access to the UICC certificate see
the definition of the EF for UICC certificate in TS 31.102 [13].
D.3.4
The key agreement for the psk case shall follow the mechanism "Strong Pre-shared Keys - Proprietary Pre-agreed keys"
as specified in ETSI TS 102 484 [29]. The pre-shared key shall be used directly to derive a Master secret for the Master
SA.
NOTE:
The above requirement includes that the pre-shared key fulfills the requirements for WeakKey=0 as
specified in clause 7.2 of ETSI TS 102 484 [29].
ETSI
D.3.5
119
The key agreement mechanisms specified in ETSI TS 102 484 [29] produce a value Ks_Local_Ref, which is a reference
to Ks_local. It is transferred from the RN to the UICC during the Master SA setup and is used as input to the derivation
of the 256 bit Master secret (MS) of the Master SA in the certificate exchange case.
Ks_Local_Ref is specified in ETSI TS 102 484 [29] as the concatenation of identities as follows:
Ks_Local_Ref = Terminal_ID || Terminal_appli_ID || UICC_ID || UICC_appli_ID.
The identities used in the scope of the present document for Ks_Local_Ref are specified as follows:
-
UICC_ID: This unique identifier for the UICC shall be the ICCID for the UICC as specified in ETSI TS 102 221
[32].
NOTE:
The UICC_ID may be read by the RN from the UICC before establishment of the secure channel.
UICC_appli_ID: This unique identifier for the UICC application that hosts the UICC endpoint shall be the
USIM-RN AID as specified in TS 31.102 [13].
Terminal_ID: This unique identifier for the RN shall be the subject name of the RN certificate as specified in
clause D.3.3.3. In the psk case, where no certificate is used, the same definition as for the certificate exchange
case shall apply.
Terminal_appli_ID: This unique identifier for the application that hosts the RN side endpoint shall be set to the
UTF-8 encoded string "Relay_Node_appli".
ETSI
120
Introduction
This clause describes the security functions necessary to support a UE that is simultaneously connected to more than
one eNB for the architectures for dual connectivity as described in TS 36.300 [30]. The security functions are described
in the context of the functions controlling the dual connectivity.
For dual connectivity architecture which hosts PDCP in MeNB the security functions described for the single
connectivity mode in this specification are sufficient. The reason for that they are sufficient, is that the end-point for the
encryption remains in the MeNB. That is, from a security point of view, the PDCP packets are still processed in the
same locations in the architecture; they have only travelled a different path via the SeNB.
The remainder of the present clause E deals with the architecture as shown in Figure E.1-1.
ETSI
121
E.2
E.2.1
The control plane signalling between MeNB and SeNB, that includes the transfer of the S-KeNB from the MeNB to the
SeNB, over the X2 reference point shall be confidentiality and integrity protected using X2-C security protection as
described in clause 5.3.4a and clause 11of the present specification. Any user plane data between MeNB and SeNB over
X2 reference point shall be confidentiality and integrity protected using X2-U security protection as described in clause
5.3.4 and clause 12 of the present specification.
E.2.2
When executing the SCG addition procedure (i.e. the initial offload of one or more radio bearers to the SeNB), or the
SCG modification procedure requiring an update of S-KeNB, the MeNB shall derive an S- KeNB as defined in clause
E.2.4, which results in a fresh S-KeNB. The MeNB shall forward the generated S-KeNB to the SeNB during the SCG
addition procedure or SCG modification procedure requiring key update.
The SeNB shall derive a key KUPenc from the received S-KeNB as defined in clause E.2.4 of the present specification and
use it for all radio bearers that were being added.
At any point of time, the same KUPenc is used for encrypting all radio bearers between the SeNB and the UE. Once the
KUPenc has been derived from the S-KeNB, the SeNB and UE may delete the S-KeNB.
The MeNB shall provide the value of the SCG Counter used in the derivation of the S-KeNB to the UE in the RRC
procedure adding the radio bearer(s) in the UE. The UE shall derive the S-KeNB and KUPenc as described in clause E.2.4.
When executing the SCG modification procedure for adding subsequent radio bearer(s) to the same SeNB, the MeNB
shall, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last S-KeNB
change.
If the MeNB cannot allocate an unused radio bearer identity for a new radio bearer in the SeNB, due to radio bearer
identity space exhaustion, the MeNB shall increment the SCG Counter and compute a fresh S-KeNB, and then shall
perform a SCG modification procedure to update the S-KeNB. The MeNB may chose to update the S-KeNB instead of
assigning a new radio bearer identity even when the latter would have been possible. The MeNB may instead release all
radio bearers in the SeNB, and then perform an SCG addition procedure, adding all radio bearers just released as well as
the new radio bearer to the SeNB. Since the procedure derived a fresh S-KeNB, radio bearer identities used before the
last S-KeNB change can be re-used.
Editor's note: According to the reply to question 2 and 3 in the LS from RAN2 in R2-141844, the working
assumption in RAN2 is that rekeying is performed by releasing all radio bearers and then adding them
again. Under this working assumption there can be no existing radio bearers active in the SeNB when the
MeNB includes a new S-KeNB when adding a new SCG. It is FFS whether RAN2 changes the WA and
hence the above statement needs updating to explain that a rekeying is performed at the same time as the
addition.
If the SeNB receives a new S-KeNB from the MeNB during the SCG modification procedure, the SeNB shall use the
KUPenc derived from the new S-KeNB as encryption key for all the radio bearer (s).
When the last radio bearer on the SeNB is released, the SeNB Release procedure is performed; the SeNB and the UE
shall delete the KUPenc. The SeNB and UE shall also delete the S-KeNB, if it was not deleted earlier.
E.2.3
Activation of encryption/decryption
The DRB offload procedure with activation of encryption/decryption follows the steps outlined on the Figure E.2.3-1.
ETSI
122
ETSI
E.2.4
123
ETSI
124
NOTE: In the present specification, only a user plane encryption key is required between UE and SeNB. But the key
derivation procedure permits deriving further keys according to Annex A.7 if this should be desired in the
future.
E.2.5
S-KeNB update
E.2.6
Handover procedures
During S1 and X2 handover, the offloaded DRB connection between the UE and the SeNB is released, and the AS SC
security context at SeNB and UE can be deleted since it shall not be used again.
E.2.7
SeNB may request the MeNB to execute a counter check procedure specified in clause 7.5 of this specification to verify
the value of the PDCP COUNT(s) associated with DRB(s) offloaded to the SeNB. To accomplish this, the SeNB shall
ETSI
125
communicate this request, including the expected values of PDCP COUNT(s) and associated radio bearer identities
(which are identified by E-RAB Id(s) in X2AP), to the MeNB over the X2-C.
If the MeNB receives a RRC counter check response from the UE that contains one or several PDCP COUNT values
(possibly associated with both MeNB and SeNB), the MeNB may release the connection or report the difference of the
PDCP COUNT values to the serving MME or O&M server for further traffic analysis for e.g. detecting the attacker.
E.2.8
Since the MeNB holds the control plane functions even in dual connectivity, the UE runs the RRC re-establishment
procedure with the MeNB as specified in clause 7.4.3 of the present specification.
After the RRC re-establishment procedure is completed, if the MeNB still has offloaded radio bearers to the SeNB, then
the MeNB shall update the S-KeNB in the SeNB and UE..
ETSI
126
Annex F (informative):
Change history
Date
TSG #
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-09 SA#45
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
TSG
Doc.
SP090518
SP090636
SP090636
SP090636
SP090518
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090636
SP090518
SP090518
SP090518
SP090636
SP090811
SP090812
SP090812
SP090811
SP090811
SP090812
SP090812
SP090811
SP090811
CR Rev
Change history
Subject/Comment
Old
9.0.0
261 -
269 -
277 -
279 -
281 -
301 1
287 1
285 1
283 1
361 1
304 -
306 -
360 1
Miscellaneous Modifications
275 1
289 1
297 1
299 1
291 1
293 1
305 2
280 1
Clarification for the Clauses 5.1.4.1 and 5.1.4.2 of the Rel-9 TS 33.401
EPS NAS security context handling in UE at EC when NULL algorithms are
established
260 2
271 1
310 1
311 -
313 2
316 1
318 2
321 -
322 2
324 3
326 1
ETSI
New
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.0.0
9.1.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2009-12 SA#46
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
SP090812
SP090811
SP090811
SP090812
SP090811
SP090811
SP090812
SP090811
SP090811
SP090811
SP090811
SP090812
SP090811
SP090811
SP090811
SP090812
SP090811
SP090811
SP090812
SP090812
SP090811
SP090811
SP090812
SP090889
SP100097
SP100099
SP100099
SP100103
SP100103
SP100101
SP100101
SP100103
SP100103
SP100101
SP100101
SP100101
SP100106
127
328 1
330 1
332 1
334 -
336 -
338 1
340 -
343 1
348 2
352 -
Clarifying the calculation of KeNB when there is more than one NAS SMC (Rel-9)
354 3
356 4
Behaviour for lost NAS SMC message when creating mapped context (Rel-9)
Clarification of Authentication Data and transition to EMM-DEREGISTERED and
Correction of text on authentication data transfer
359 -
360 1
362 1
364 1
366 -
Correcting A.11
Not resetting STARTPS to 0 in HO from EUTRAN to UTRAN and not resetting
STARTCS to 0 in SRVCC (Rel-9).
367 1
368 369 1
371 -
373 -
375 1
376 4
384 -
386 -
377 -
319 2
387 1
392 1
403 378 1
389 -
382 1
399 1
GPRS Kc handling
Desynchronization of PS keys between the UE and the network in case of PS HO
failure
383 1
395 2
ETSI
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
2010-04 SA#47
2010-04 SA#47
2010-04 SA#47
2010-04 -2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-06 SA#48
2010-10 SA#49
2010-10 SA#49
2010-12 SA#50
2010-12 SA#50
2010-12 SA#50
2010-12 SA#50
2011-03 SA#51
2011-03 SA#51
2011-03 SA#51
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 SA#52
2011-06 -2011-09 SA#53
2011-09 SA#53
SP100106
SP100101
SP100106
-SP100382
SP100382
SP100383
SP100383
SP100382
SP100383
SP100383
SP100382
SP100382
SP100382
SP100477
SP100569
SP100850
SP100721
SP100721
SP100852
SP110016
SP110015
SP110015
SP110256
SP110256
SP110256
SP110256
SP110256
SP110256
SP110256
SP110256
SP110256
SP110259
SP110256
SP110270
-SP110505
SP110505
128
376 2
397 1
404 ---
414 1
420 1
Editorial Corrections
408 1
409 1
410 1
412 2
413 1
415 1
416 1
418 1
423 1
Corrections
424 -
425 1
426 1
427 -
429 1
431 1
437 1
438 1
440 1
444 1
445 1
448 1
449 1
451 1
452 1
453 1
454 1
459 2
460 -
428 ---
461 1
468 1
ETSI
9.2.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
9.3.0
9.3.1
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.3.1
9.4.0
9.4.0
9.5.0
9.4.0
9.5.0
9.5.0
9.6.0
9.5.0
9.6.0
9.5.0
9.6.0
9.5.0
9.6.0
9.6.0
10.0.0
9.6.0
10.0.0
9.6.0
10.0.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.0.0
10.1.0
10.1.0
11.0.0
11.0.0
11.0.1
11.0.1
11.1.0
11.0.1
11.1.0
2011-09 SA#53
2011-09 SA#53
2011-09 SA#53
2011-09 SA#53
2011-09 SA#53
2011-09 SA#53
2011-12 SA#54
2011-12 SA#54
2011-12 SA#54
2011-12 SA#54
2012-03 SA#55
2012-06 SA#56
2012-06 SA#56
2012-06 SA#56
2012-06 SA#56
2012-06 SA#56
2012-09 SA#57
2012-09 SA#57
2012-09 SA#57
SP110505
SP110505
SP110505
SP110505
SP110505
SP110505
SP110848
SP110848
SP110848
SP110848
SP120039
SP120341
SP120341
SP120339
SP120343
SP120343
SP120605
SP120605
SP120602
2012-12 SA#58
2013-03 SA#59
2013-06 SA#60
SP120856
SP120856
SP130038
SP130252
471 2
473 -
475 1
477 1
479 1
483 1
484 1
486 1
487
488
489
491
493
1
1
1
1
1
2013-12 SA#62
2014-06 SA#64
2014-09 SA#65
SP140590
11.1.0
11.0.1
11.1.0
11.0.1
11.1.0
11.0.1
11.1.0
11.0.1
11.1.0
11.0.1
11.1.0
11.1.0
11.2.0
11.1.0
11.2.0
11.1.0
11.2.0
11.1.0
11.2.0
11.2.0
11.3.0
11.4.0
11.3.0
11.4.0
499 1
11.3.0
11.4.0
501
11.3.0
11.4.0
502 1
11.3.0
11.4.0
504 -
11.4.0
11.5.0
505 -
11.4.0
11.5.0
11.5.0
12.5.0
12.5.0
12.5.1
12.5.1
12.6.0
12.5.1
12.6.0
12.6.0
12.7.0
12.7.0
12.8.0
12.8.0
12.8.1
12.8.1
12.9.0
12.9.0
12.10.0
494 495 1
503 -
506 1
CR-Corrections to 33.401
507 1
518 1
SRVCC-correction-REL-12
519 1
SP130838
SP130667
SP140314
11.0.1
11.3.0
2013-06
2013-09 SA#61
469 1
2012-10
2012-12 SA#58
129
522 1
523 -
Correction of a typo
525 1
526 532 1
535 1
ETSI
12.10.0 12.11.0
12.11.0 12.12.0
130
History
Document history
V12.12.0
October 2014
Publication
ETSI