Download gisfi_sp_201212337

GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Technical Report
Global ICT Standardisation Forum for India;
Technical Working Group Security and Privacy;
Security in mobile communication systems;
Comparison and proposals for India
(Release 1)
The present document has been developed within GISFI and may be further elaborated for the purposes of GISFI.
Release 1
2
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
GISFI
GISFI office address
Suite 303, 3rd Floor, Tirupati Plaza, Plot No. 4,
Sector 11, Dwarka, New Delhi-110075, India
Tel.: +91-11-47581800 Fax: +91-11-47581801
Internet
http://www.gisfi.org
E-mail: [email protected]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© 2011, GISFI
All rights reserved.
GISFI
Release 1
3
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Contents
Foreword............................................................................................................................................................. 5
Introduction ........................................................................................................................................................ 5
1
Scope ........................................................................................................................................................ 6
2
References ................................................................................................................................................ 6
3
Definitions, symbols and abbreviations ................................................................................................... 9
3.1
3.2
4
4.1
4.1.1
4.1.1.1
4.1.1.2
4.1.2
4.2
4.2.1
4.2.2
4.2.2.1
4.2.2.2
4.3
5
5.1
5.1.1
5.1.1.1
5.1.1.2
5.1.2
5.2
5.2.1
5.2.2.
5.2.2.1
5.2.2.2
5.2.3
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
Definitions ......................................................................................................................................................... 9
Abbreviations ..................................................................................................................................................... 9
Security Mechanisms or Architecture in Mobile Communication Systems .......................................... 10
Security Provisions in the Second Generation (2G) and Second Generation - Transitional (2.5G/ 2.75G
[3]) Mobile Communication Systems .............................................................................................................. 10
The GSM Evolution ................................................................................................................................... 10
The 2G Global System for Mobile Communication (GSM)................................................................. 10
The General Packet Radio Service (GPRS) and subsequent Enhanced Data Rates for GSM
Evolution (EDGE) ................................................................................................................................ 10
The Code Division Multiple Access (CDMA)-based 2G/2.5G evolution .................................................. 10
Security Provisions in the Third Generation (3G) and Third Generation – Transitional (3.5G [25]/ 3.95G
[26]) Mobile Communication Systems ............................................................................................................ 11
The Third Generation Partnership Project-based (3GPP-based) Mobile Communication Systems ........... 11
The Third Generation Partnership Project 2-based (3GPP2-based) Mobile Communication Systems ...... 13
The CDMA2000 1x Mobile Communication Systems [17] ................................................................. 13
The CDMA2000 1xEV-DO Mobile Communication Systems [17] ..................................................... 14
Security Provisions in the Fourth Generation (4G [27]) Mobile Communication Systems ............................. 15
Security Issues in Mobile Communication Systems .............................................................................. 16
Security Issues in the Second Generation (2G) and Second Generation - Transitional (2.5G/ 2.75G [3])
Mobile Communication Systems ..................................................................................................................... 16
The GSM Evolution ................................................................................................................................... 16
The 2G Global System for Mobile Communication (GSM) [28] ......................................................... 16
The General Packet Radio Service (GPRS) and subsequent Enhanced Data Rates for GSM
Evolution (EDGE) [31] [32] ................................................................................................................. 17
The Code Division Multiple Access (CDMA)-based 2G/2.5G evolution [34] .......................................... 18
Security Issues in the Third Generation (3G) and Third Generation Transitional (3.5G [25]/ 3.95G [26])
Mobile Communication Systems ..................................................................................................................... 19
The Third Generation Partnership Project-based (3GPP-based) Mobile Communication Systems ........... 19
The Third Generation Partnership Project 2-based (3GPP2-based) Mobile Communication Systems ...... 20
The CDMA2000 1x Mobile Communication Systems [39] [40].......................................................... 20
The CDMA2000 1xEV-DO Mobile Communication Systems [43] ..................................................... 20
Security Issues (perceived) in the 3GPP Fourth Generation (4G [27]) Mobile Communication
Systems ...................................................................................................................................................... 20
List of Mandatory and Optional Security Features derived from 3GPP (33-series) Security
Technical Specifications ........................................................................................................................ 21
From 3GPP TS 33.102, V11.3.0, (2012-06) (Release 11) [49]: ...................................................................... 21
From 3GPP TS 33.401, V11.4.0, (2012-06) (Release 11) [50]: ...................................................................... 23
From 3GPP TS 33.210, V12.0.0, (2012-06) (Release 12) [51]: ...................................................................... 25
From 3GPP TS 33.310, V11.0.1, (2012-07) (Release 11) [52]: ...................................................................... 27
From 3GPP TS 33.402, V11.4.0, (2012-06) (Release 11) [53]: ...................................................................... 31
From 3GPP TS 33.320, V11.6.0, (2012-06) (Release 11) [54]: ...................................................................... 32
From 3GPP TS 33.328, V10.0.0, (2011-03) (Release 10) [55]: ...................................................................... 37
From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11) [56]: ...................................................................... 40
From 3GPP TS 33.105, V10.0.0, (2011-03) (Release 10) [57]: ...................................................................... 43
From 3GPP TS 33.110, V10.1.0, (2011-06) (Release 10) [58]: ...................................................................... 43
From 3GPP TS 33.141, V12.0.0, (2012-06) (Release 12) [59]: ...................................................................... 44
From 3GPP TS 33.203, V12.0.0, (2012-06) (Release 12) [60]: ...................................................................... 45
From 3GPP TS, 33.220, V11.3.0, (2012-06) (Release 11) [61]: ..................................................................... 48
GISFI
Release 1
6.14
6.15
4
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11) [62]: ...................................................................... 50
From 3GPP TS 33.246, V10.0.0, 2010-12 (Release 10) [63]: ......................................................................... 52
7
Void ........................................................................................................................................................ 53
8
Void ........................................................................................................................................................ 53
9
Conclusions ............................................................................................................................................ 53
Annex A: Change history ............................................................................................................................... 54
GISFI
Release 1
5
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Foreword
This Technical Report has been produced by GISFI.
The contents of the present document are subject to continuing work within the Technical Working Group (TWG) and
may change following formal TWG approval. Should the TWG modify the contents of the present document, it will be
re-released by the TWG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit shows the release to which the document belongs
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.
.
Introduction
This report introduces the subject of the “Security in Mobile Communication Systems” that is of paramount importance
in the times of evolving technologies that also is challenged by threats and attacks on them. It provides an overview of
the security implementations/architectures provided in the various generations of wireless/mobile communication
technologies. This report also provides a brief description of the various security issues in the various phases of
technology evolutions in the various generations of wireless/mobile communication technologies.
Further, this report enlists the Mandatory and Optional requirements, regarding the implementation and/or use of
security features, as specified in the 3GPP 33-series Technical Specifications (TSs). It does not mention whether a given
security item/feature is mandatory/optional for implementation or use, unless explicitly specified in this document and
in the respective TS which has been referred to. This list of Mandatory and Optional requirements has been derived by
searching for the keywords: Mandate/ Mandatory, and Optional, as mentioned in the various 3GPP 33-series Technical
Specifications that have been referenced.
This list also provides an overview to the concerned Indian Government departments on the 3GPP Standards-based
security features, both mandatory and optional, that are to be considered by vendors and operators as part of the Indian
Network Security requirements.
GISFI
Release 1
6
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
1 Scope
This document, study report on Security in Mobile Communication Systems is a deliverable of Security and Privacy
working group. The scope of this technical report is to perform a study on the security mechanisms or architecture in
different wireless technologies, designed and enhanced over successive evolution phases of a particular wireless
technology. Items within the scope of this study are:
1. Identify the Standardized security mechanisms or architecture in the 3GPP and 3GPP2 wireless communication
technologies, across successive generations of each technology platform.
2. Identify security issues in each of the wireless technology generation, for the 3GPP and 3GPP2 technology
family.
3. Present a gap analysis between the security mechanisms or architectures in each of the wireless technology
generation, for the 3GPP and 3GPP2 technology Standards family and the weaknesses or security flaws in the
same and provide recommendations for resolution of the same.
4. Propose a list of Mandatory and Optional security features for implementation and/or use, for the latest wireless
technologies to be adopted and implemented in the Indian Telecom industry.
2
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
[1] Eric Southern, Abdelkader Ouda, Abdallah Shami, “Securing USIM-based Mobile Communications from
Interoperation of SIM-based Communications”; International Journal for Information Security Research (IJISR),
Volume 2, Issues 1/2, March/June 2012; pg. 315, 316.
http://www.infonomics-society.org/IJISR/IJISR_Paper%209.pdf.
[2] Introduction of GPRS and EDGE: http://www.3gpp.org/article/functionality-in-early-gsm.
[3] On GPRS and EDGE: http://www.3gpp.org/article/gprs-edge.
[4] Charles Brookson, “GPRS Security”; December 2001; Pg. 3; http://www.brookson.com/gsm/gprs.pdf.
[5] Ali Dinckan, Aktul Kavas, “Authentication And Ciphering In GPRS Network”; May 2005; pg. 2;
www.emo.org.tr/ekler/fedcaffc4aba6e5_ek.pdf.
[6] About cdmaOne: http://www.cdg.org/technology/cdmaone.asp.
[7] About CDMA Technology: http://www.cdg.org/technology/cdmatechnology.asp.
[8] David Tipper, “IS-95 cdmaOne”; University of
http://www.sis.pitt.edu/~dtipper/2720/2720_Slides9.pdf.
Pittsburgh,
February
2008;
Pg.
38
(Slide
[9] 3GPP TS 33.102, “3G Security: Security Architecture”; Ver. 11.2.0; February 2012; Pgs. 12, 13.
[10] 3GPP “Overview of 3GPP Release 1999”; V0.1.1; February 2010; Pg. 44.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-99_description_20100214.zip.
[11] 3GPP “Overview of 3GPP Release 5”; V0.1.1; February 2010; Pg. 19.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-05_description_20100214.zip.
[12] 3GPP “Overview of 3GPP Release 6”; V0.1.1; February 2010; pg. 66.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-06_description_20100214.zip.
GISFI
93);
Release 1
7
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
[13] 3GPP “Overview of 3GPP Release 7”; V0.9.16; January 2012; Pg. 56- 64.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-07_description_20120124.zip.
[14] 3GPP “Overview of 3GPP Release 8”; V0.2.6; March 2012; Pg. 82, 126, 127.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-08_description_20120316.zip.
[15] 3GPP “Overview of 3GPP Release 9”; V0.2.5; March 2012; Pg. 48 – 54.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-09_description_20120316.zip.
[16] About CDMA2000: http://www.cdg.org/technology/cdma2000.asp.
[17] Naidu Mullaguru, “Security Provisions in CDMA2000 Networks – A Whitepaper”; 80-W3633-1 Rev A,
November 2011; Pgs. 4, 13, 17, 19 - 21, 22-29, 30, 32.
http://www.cdg.org/resources/files/white_papers/Qualcomm_Security_Provisions_in_CDMA2000_Networks_80W3633-1_RevA[2]_Nov2011.pdf.
[18] 3GPP2 C.S0024-0, "cdma2000 High Rate Packet Data Air Interface Specification"; Version 4.0, October 25, 2002;
Pgs. 1-2.
[19] 3GPP “Overview of 3GPP Release 10”; V0.1.4; March 2012; Pgs. 37, 90.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-10_description_20120316.zip.
[20] 3GPP “Overview of 3GPP Release 11”; V0.1.0; March 2012; Pgs. 65 -74.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-11_description_20120316.zip.
[21] 3GPP “Overview of 3GPP Release 12”; V0.0.3; March 2012; Pg. 19.
http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-12_description_20120316.zip.
[22] About the SNOW3G cipher: http://www.heliontech.com/3gpp.htm; http://www.ipcores.com/Snow3G.htm.
[23] About the AES cipher: http://www.heliontech.com/3gpp.htm; http://www.ipcores.com/aes_ip_core.htm.
[24] On the LTE platform integration by the 3GPP and 3GPP2: http://www.gsma.com/aboutus/gsm-technology/lte/.
[25] 3.5G, Terminology, usage of, 3GPP: http://www.3gpp.org/article/w-cdma.
[26] 3.95G, Terminology, usage of, 3GPP: http://www.3gpp.org/A-few-Mbps-ought-to-make-just.
[27] 4G, Terminology, usage of, 3GPP: http://www.3gpp.org/LTE-Advanced.
[28] Mohsen Toorani, Ali A. Beheshti, "Solutions to the GSM Security Weaknesses"; (Copyright © 2008 IEEE.
Reprinted from the Proceedings of the 2nd International Conference on Next Generation Mobile Applications, Services,
and Technologies (NGMAST'08), pp.576-581, University of Glamorgan, Cardiff, UK, Sep. 2008); Pgs. 2, 3;
http://arxiv.org/ftp/arxiv/papers/1002/1002.3175.pdf.
[29] Impersonation of a user and the network, Description of: Emmanuel Gadaix, "GSM and 3G Security, April 2001,
Slide: 7.
http://www.google.co.in/url?sa=t&rct=j&q=%22gadiax.ppt%22&source=web&cd=1&ved=0CE8QFjAA&url=http%3A
%2F%2Fwww.blackhat.com%2Fpresentations%2Fbh-asia-01%2Fgadiax.ppt&ei=6vMIUJbFIctrAfWuIjJCA&usg=AFQjCNFfwYvxKR1O5chC15u_Ztu7NWX1oA.
[30] On “Security through Obscurity”: Jeremy Quirke, “Security in the GSM System”; 2004:
http://www.it.iitb.ac.in/~kavita/GSM_Security_Papers/Security%2520in%2520the%2520GSM%2520system%2520010
52004.pdf.
[31] Hakima Chaouchi, Maryline Laurent-Maknavicius, "Wireless and Mobile Network Security"; ISTE Ltd. and John
Wiley & Sons, Inc., 2009; Pgs. 343 – 346.
http://mobilemarketingcn.com/ebooks/hotsaleebooks/wireless-and-mobile-network-security.pdf.
GISFI
Release 1
8
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
[32] Christos Xenakis, "Malicious Actions Against the GPRS Technology"; 2006; Pgs. 10-18.
http://www.google.co.in/url?sa=t&rct=j&q=%22Malicious+Actions+Against+the+GPRS+Technology%22&source=we
b&cd=1&ved=0CEoQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1
.106.8814%26rep%3Drep1%26type%3Dpdf&ei=pPQIUKnrF4i0rAfSwN3ICA&usg=AFQjCNGDpaqAL5D3S925ndn1EnsBKKN5Q.
[33] EDGE network security vulnerabilites, similar to those of GPRS networks:
http://www.cse-cst.gc.ca/its-sti/publications/itspsr-rpssti/itspsr16a-eng.html#a393.
[34] IS-95 security issue: Abstract: http://www.springerlink.com/content/g3cekhvu9wpududq/.
[35] Muxiang Zhang, Christopher Carroll and Agnes Chan, "Analysis of IS-95 CDMA Voice Privacy"; Lecture Notes
in Computer Science, 2001, Volume 2012/2001.
https://springerlink3.metapress.com/content/g3cekhvu9wpududq/resourcesecured/?target=fulltext.pdf&sid=k3tsrxjhiisqzjlxhmy2xtq5&sh=www.springerlink.com.
[36] L. Ertaul, S. Natte, and G. Saldamli, "Security Evaluation of CDMA2000"; Pg. 1.
http://www.mcs.csueastbay.edu/~lertaul/Security%20Evaluation%20of%20CDMA2000CamReady.pdf.
[37] 3G Networks, Reasons for Vulnerabilities:
http://www.mid-day.com/lifestyle/2010/aug/020810-Hacker-3G-mobile-network.htm.
[38] Kameswari Kotapati, Peng Liu, Yan Sun, Thomas F. LaPorta, "A Taxonomy of Cyber Attacks on 3G Networks";
2005; Pg. 10.
http://nsrc.cse.psu.edu/tech_report/NAS-TR-0021-2005.pdf.
[39] Sangram Gayal and Dr. S. A. Vetha Manickam, "Comparative analysis Of GSM and CDMA technologies"; 2002;
Pg. 14.
http://www.google.co.in/url?sa=t&rct=j&q=%22Comparative+analysis+Of+GSM+and+CDMA+technologies%22&sou
rce=web&cd=1&ved=0CE0QFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3
D10.1.1.11.3538%26rep%3Drep1%26type%3Dpdf&ei=-_UIUIaFJMvOrQel_sTICA&usg=AFQjCNFwSt32JcT8pGhASEdnswmLzGoHA.
[40] CDMA20001x Vulnerabilities: http://www.cse-cst.gc.ca/its-sti/publications/itspsr-rpssti/itspsr16a-eng.html#a343.
[41] D. Wagner, L. Simpson, E. Dawson, J. Kelsey, W. Millan, and B. Schneier, "Cryptanalysis of ORYX"; 1999.
http://packetstorm.igor.onlinedirect.bg/cracked/oryx/oryx.pdf.
[42] David Wagner, Bruce Schneier, John Kelsey, "Cryptanalysis of the Cellular Message Encryption Algorithm";
1999; http://www.schneier.com/paper-cmea.pdf.
[43] CDMA2000
eng.html#a353.
1xEV-DO
Vulnerabilties:
http://www.cse-cst.gc.ca/its-sti/publications/itspsr-rpssti/itspsr16a-
[44] LTE brings new security concerns for telcos: http://www.zdnet.com/lte-brings-new-security-concerns-for-telcos1339323236/.
[45] Dr. Jinyuan (Stella) Sun, “Computer and Network Security”; Dept. of Electrical Engineering and Computer
Science, University of Tennessee, Fall 2011; Slide number: 46; http://web.eecs.utk.edu/~jysun/files/Lec15.pptx.
[46] CDG Document 138, “CDMA Authentication”; Version 0.34; Oct. 12, 2006; Pg. 1
http://www.google.co.in/url?sa=t&rct=j&q=Fraud_WG_CDG138_CDMA_Authentication.doc&source=web&cd=3&ca
d=rja&ved=0CE4QFjAC&url=https%3A%2F%2Fwiki.cdg.org%2Fw%2Fimages%2Fc%2Fc7%2FFraud_WG_CDG13
8_CDMA_Authentication.doc&ei=aNktUK7mNY3wrQee9ICwBQ&usg=AFQjCNHAwPGXzzz0vGJeztcFP9r4t3EuIg.
[47] Greg Rose, “The Future of CDMA2000 Security”; 2005; Pg. 6.
http://www.cdg.org/news/events/cdmaseminar/050513_tech_forum/5-%20CDG%20-%20Qualcomm.pdf.
GISFI
Release 1
9
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
[48] N. Seddigh, “Security advances and challenges in 4G wireless networks”, Eighth Annual International Conference
on Privacy Security and Trust (PST) 2010, 17 – 19 Aug. 2010.
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5593244&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2
Fabs_all.jsp%3Farnumber%3D5593244.
[49] 3GPP TS 33.102, “3G Security; Security Architecture”, V11.3.0, 2012-06 (Release 11).
[50] 3GPP TS 33.401, “3GPP System Architecture Evolution (SAE); Security architecture”, V11.4.0, 2012-06 (Release
11) .
[51] 3GPP TS 33.210, “3G security; Network Domain Security (NDS); IP network layer security”, V12.0.0, 2012-06
(Release 12).
[52] 3GPP TS 33.310, “Network Domain Security (NDS); Authentication Framework (AF)”, V11.0.1, 2012-07
(Release 11).
[53] 3GPP TS 33.402, “3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses”, V11.4.0,
2012-06 (Release 11).
[54] 3GPP TS 33.320, “Security of Home Node B (HNB) / Home evolved Node B (HeNB)”, V11.6.0, 2012-06
(Release 11).
[55] 3GPP TS 33.328, “IP Multimedia Subsystem (IMS) media plane security”, V10.0.0, 2011-03 (Release 10).
[56] 3GPP TS 33.234, “3G security; Wireless Local Area Network (WLAN) interworking security”, V11.4.0, 2012-06
(Release 11).
[57] 3GPP TS 33.105, “3G Security; Cryptographic Algorithm Requirements”, V10.0.0, 2011-03 (Release 10).
[58] 3GPP TS 33.110, “Key establishment between a Universal Integrated Circuit Card (UICC) and a terminal”,
V10.1.0, 2011-06 (Release 10).
[59] 3GPP TS 33.141, “Presence service; Security”, V12.0.0, 2012-06 (Release 12).
[60] 3GPP TS 33.203, “3G Security; Access security for IP-based services”, V12.0.0, 2012-06 (Release 12).
[61] 3GPP TS 33.220, “Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)”,
V11.3.0, 2012-06 (Release 11).
[62] 3GPP TS 33.234, “3G Security; Wireless Local Area Network (WLAN) interworking security”, V11.4.0, 2012-06
(Release 11).
[63] 3GPP TS 33.246, “3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)”, V10.0.0, 2010-12
(Release 10).
3
Definitions, symbols and abbreviations
3.1
Definitions
This document defines the following items.
3.2
DoT
ICT
Abbreviations
Department of Telecommunications
Information and Communication Technologies
GISFI
Release 1
10
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
4
Security Mechanisms or Architecture in Mobile
Communication Systems
4.1
Security Provisions in the Second Generation (2G) and
Second Generation - Transitional (2.5G/ 2.75G [3]) Mobile
Communication Systems
4.1.1
The GSM Evolution
4.1.1.1
The 2G Global System for Mobile Communication (GSM)
The 2G GSM technology is a digital technology, succeeding the analog (1G) Advanced Mobile Phone System (AMPS),
where the radio signals are digitally encrypted. It was made available around the early 90s.
The GSM uses security hashing algorithms (A8, A3, and A5), with different versions of the same such as the A5/1,
A5/2, etc. A Private Key encrypts message to the server. The authentication in GSM is a one-way authentication
algorithm to authenticate the mobile device to the service provider network. Since the mobile device cannot authenticate
the network, it poses threats such as a false base station attack that can listen into user conversations and inject
information into the channel. [1]
4.1.1.2
The General Packet Radio Service (GPRS) and subsequent Enhanced Data
Rates for GSM Evolution (EDGE)
The 3GPP classifies the 2.5G and the 2.75G systems as follows [2]:
 GSM Phase 2+ (Release 1998)
 GSM Phase 2+ (Release 1997)
 GSM Phase 2+ (Release 1996),
with the introduction of the GPRS in Release 1997, followed by the introduction of the EDGE in Release 1998.
Based on specifications in Release 97, GPRS typically reached speeds of 40Kbps in the downlink and 14Kbps in the
uplink by aggregating GSM time slots into one bearer. Enhancements in Releases R’98 and R’99 meant that GPRS
could theoretically reach downlink speeds of up to 171Kbps. The increase in data speeds to 384Kbps placed EDGE as
an early pre-taste of 3G, although it was labelled 2.75G by industry watchers. [3]
The GPRS security model, built on the GSM security aspects, includes seven GPRS Encryption Algorithms (GEA)
allowed for in the GPRS specifications, along-with the A3, A8 and A5 algorithms. [4]
The GPRS security model also has an identification key Ki (128-bit long identification key) and a ciphering key GPRSKc (64-bit key) [5]
4.1.2
The Code Division Multiple Access (CDMA)-based 2G/2.5G
evolution
cdmaOne is the brand name that describes a complete digital wireless telecommunications solution based on the
TIA/EIA IS-95 CDMA standard, including IS-95A (that provides circuit-switched data connections at 14.4 kbps) and
IS-95B (that provides packet-switched data services at 64 kbps) revisions. It represents a second generation (2G) digital
radio solution that uses the spectrally efficient Code Division Multiple Access (CDMA) scheme to send voice, data and
signalling data (e.g., Caller ID) between mobile telephones and cell sites in a variety of spectrum and regulatory
environments, including cellular, personal communication services (PCS), wireless local loop (WLL) and fixed
wireless. [6]
GISFI
Release 1
11
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
CDMA is a "spread spectrum" technology, allowing many users to occupy the same time and frequency allocations in a
given band/space. CDMA (Code Division Multiple Access) assigns unique codes to each communication to
differentiate it from others in the same spectrum. [7] Owing to this uniquely generated code for communication between
every user and the network, it also increases security of the communication channel.
cdmaOne uses the Cellular Authentication And Voice Encryption (CAVE) algorithm which uses a 64 bit
Authentication-key (A-key) along with Electronic Serial Number (ESN) and Random number to generate a 128-bit
Shared Secret Data (SSD). The SSD is divided into two 64 bit blocks as SSD-A for authentication and SSD-B for
encryption. cdmaOne employs the Challenge/Response technique for authentication whereas a random number used to
create a key for encryption of voice and data. [8]
4.2
Security Provisions in the Third Generation (3G) and Third
Generation – Transitional (3.5G [25]/ 3.95G [26]) Mobile
Communication Systems
4.2.1
The Third Generation Partnership Project-based (3GPP-based)
Mobile Communication Systems
Post the introduction of the GSM Phase2+ (Release 1998) the 3GPP group has framed a security architecture
(modified/updated over subsequent 3G technology releases), that not only includes Network Access Control, but also
other domains of the mobile communication system.
The 3GPP-based Mobile communication systems between Release 99 (Rel99) until Release 7 are commonly termed as
‘Third Generation (3G) systems’. Likewise, the 3GPP-based Mobile communication systems post-Release 8 until
Release 12 (released, as of date) are commonly termed as ‘Fourth Generation (4G) systems’
However, the security architecture designed by the 3GPP, starting from Release 99 until Release 12 remains the same,
with modifications/updates over the successive technology releases.
This 3GPP security architecture is as follows [9]:
(IV)
User Application
Provider Application
(I)
(I)
(III)
USIM
HE
(II)
(I)
(I)
SN
(I)
ME
AN
Transport
stratum
Figure 1. Overview of the 3GPP Security Architecture.
GISFI
Application
stratum
Home
stratum/
Serving
Stratum
Release 1
12
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Five security feature groups are defined. Each of these feature groups meets certain threats and accomplishes certain
security objectives [9]:
 Network access security (I): the set of security features that provide users with secure access to 3G 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 in the provider domain to securely
exchange signalling data, and protect against attacks on the wire-line 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.
The modifications to the above-framed security architecture, starting from 3GPP Rel99 until Release 7, in sequence are
as follows:
a) Rel99/ Release 4, Release description [10]: Introduction of the Fraud Information Gathering Service (FIGS) that
provides the means for the HPLMN to monitor the activities of its subscribers in a VPLMN. Also introduced in
this Release, is the Immediate Service Termination (IST) feature that provides the means for the HPLMN to
terminate all the activities of an Home Public Land Mobile Network (HPLMN) subscriber in a Visitor Public
Land Mobile Network (VPLMN), if the HPLMN decides (based upon information received via FIGS or other
systems) that a roaming subscriber is behaving in a fraudulent or suspicious manner.
b) High Speed Packet Access – Downlink (HSPA-Downlink)/ (Release 5) description [11]: Enhanced Network
Domain Security as a stage-2 specification for IP-related security in the UMTS core network. These "Security
services" are confidentiality, integrity, authentication and anti-replay protection. They are actually ensured by
standard procedures, based on cryptographic techniques. It also defines the security architecture for the UMTS
network IP based control plane, covering the control signalling on selected interfaces between UMTS Network
Elements.
It was identified that 3G systems should provide enhanced security over 2G systems in the area of SS7 network
security due to the increased threats linked to the predicted larger Multi-Operator environment. Important
Signalling System No. 7 Mobile Application Part (SS7 MAP) signalling is protected with this release.
c) High Speed Packet Access – Uplink (HSPA-Uplink)/ (Release 6) description [12]: Release 6 has the following
security enhancements:
i. Enhanced Home Environment (HE) control of security (including positive authentication reporting): In order
to facilitate roaming with Telecommunications Industry Association’s (TIA's) Code Division Multiple
Access (cdma2000), the 3GPP authentication and key agreement mechanism has been adopted by the TIA
TR-45 group. TR-45 have identified requirements for enhancing the degree of control the home
environment can exert on the serving network with respect to authentication and key agreement. In
particular, two security features, required by TR-45, were added to the 3GPP standard:
ii. Authentication vector revocation
iii. Positive authentication result reporting
iv. Network Domain Security; Authentication Framework (NDS/AF): The primary objective was for the
authentication framework to provide entity authentication for the nodes that are using NDS/Internet
Protocol (IP). The authentication is developed to replace the (not so scalable) default IP Security
(IPsec)/Internet Key Exchange (IKE) use of pre-shared secrets to authenticate the network elements.
v. Key Management of group keys for Voice Group Call Services (VGCS)
d) High Speed Packet Access - Plus (HSPA+)/ (Release 7) description [13]: Release 7 has the following security
enhancements:
i. Liberty Alliance and 3GPP Security Interworking (LibSec)
ii. Trust Requirements for Open Platforms in 3GPP (TrustOP): An Open Platform is a computing platform with
an architecture allowing users to upgrade their hardware and/or update the software running on that
platform. Therefore, it is very much desirable that the Open Platform must have secure authentication and
GISFI
Release 1
iii.
iv.
v.
vi.
vii.
13
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
authorization mechanisms to protect against eavesdropping, and malicious modification of user data and
operator applications residing on the Open Platform.
Development of UEA2 and UIA2 (AlgUEA2): The need for backup algorithms for UTRAN access
confidentiality and integrity protection (UEA2, UIA2) was identified, in the event that the KASUMI
algorithm is ever broken. The SNOW3G is a stream cipher which uses a 128-bit Key. It provides the basis
for the UEA2 confidentiality and UIA2 integrity algorithms introduced in 3GPP Release 7 to provide data
security for signalling and user data within the UMTS standard. [22] The algorithms were provided by
European Telecommunication Standards Institute Security Algorithms Group of Experts (ETSI SAGE).
Lawful Interception in the 3GPP Rel-7 architecture (LI-7A)
Key establishment between a Universal Integrated Circuit Card (UICC) and a terminal (KeyEstUTerm):
defines how to provision a shared key between a UICC and a terminal that may host the UICC or be
connected to the device hosting the UICC via a local interface.
Security enhancements: Hypertext Transfer Protocol Secure (HTTPS) connection between the UICC and a
Network Application Function (NAF), 2G Generic Bootstrapping Architecture (GBA): 2G Subscriber
Identity Module (SIM) usage in 3GPP Generic Authentication Architecture (GAA) framework, Generic
Authentication Architecture usage extensions and optimisations, and SS7 Transaction Capabilities
Application Part (TCAP) security Gateway.
NDS Authentication Framework Extension for Transport Layer Security (NDSAFTLS)
e) Dual Cell/ Carrier High Speed Packet Access (DC-HSPA)/ (Release 8) description [14]: 3GPP Release 8
introduced confidentiality and integrity algorithms based on the Advanced Encryption Standard (AES) 128-bit
block cipher with 128-bit key size to provide data security within LTE networks. [23] Release 8 has the
following security enhancements:
i. Security Enhancements for IP-Multimedia Subsystem (IMS)
ii. Lawful Interception (LI) in the 3GPP Rel-8 (LI8)
iii. Generic Bootstrapping Architecture Push Function (GBAPush)
f) Long Term Evolution (LTE)/ (Release 9) description [15]: Long Term Evolution (LTE) is a mobile network
technology that is being deployed by mobile operators on both the GSM and the CDMA technology paths. [24]
It is specified by the 3GPP. Release 9 has the following security enhancements:
i. Access Security Enhancements
ii. GBAPush enhancements (Generic push layer)
iii. Protection against Unsolicited Communication for IMS (PUCI)
iv. IMS Media Plane Security (MEDIASEC)
v. Extended Identity Management (GBA-IdM)
vi. Network Domain Security enhancements to support backhaul security
vii. 128 bit encryption for GSM and GPRS (A5/4 – GEA4)
4.2.2
The Third Generation Partnership Project 2-based (3GPP2-based)
Mobile Communication Systems
The 3GPP2 is a collaborative 3G telecommunications specifications-setting project that has defined and published
specifications for the Code Division Multiple Access (CDMA2000) technology which represents a family of IMT-2000
(3G) standards providing high-quality voice and broadband data services over wireless networks. Currently,
CDMA2000 includes CDMA2000 1X (Single-Carrier) and CDMA2000 EV-DO (EV-DO) standards. [16]
4.2.2.1
The CDMA2000 1x Mobile Communication Systems [17]
CDMA2000 1X (IS-2000) supports circuit-switched voice up to and beyond 35 simultaneous call per sector and highspeed data of up to 153 kbps in both directions.
Along-with the security mechanisms (employing the CAVE algorithm) implemented in cdmaOne, new security
enhancements for CDMA2000 networks (Release C onwards), in the form of new algorithms such as Authentication
and Key Agreement (AKA) for authentication, Secure Hashing Algorithm-1 (SHA-1) for hashing and integrity and
Advanced Encryption Standard (AES) algorithm for message encryption, are introduced.
GISFI
Release 1
14
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Authentication: The CAVE-based authentication procedure in CDMA2000 is the same as that in cdmaOne. A new form
of authentication, based on 3GPP AKA (128-bit authentication key and a stronger standardized and well-studied
authentication algorithm) used in UMTS networks, is being introduced in CDMA2000 systems. It is called Enhanced
Subscriber Authentication (ESA) (also referred as 3rd generation (3G) authentication). The support for AKA in
CDMA2000 networks is included in all releases following CDMA2000 Rev C.
Encryption: In CAVE based security measures, a special Cellular Message Encryption Algorithm (CMEA) (and
Enhanced-CMEA (E-CMEA)) for signalling message encryption and a special ORYX algorithm for data encryption are
being used on the CDMA channel. Also a Private Long Code Mask (PLCM) is used for Voice Encryption.
The AKA mechanism allows for the generation of new cipher key (CK) and integrity key (IK). These 128-bit keys
enable a security association between the device and the serving MSC for supporting advanced security services such as
signalling message data integrity, signalling information element encryption and user data encryption.
Security Measures for 1x Packet Data service: In CDMA2000 1X networks, additional security measures exist for the
packet data services, in form of service/subscription authentication and ORYX/AKA based encryption measures.
Another new security mechanism that is gaining popularity in 3GPP2 (both 1X and EV-DO) packet data networks is
EAP-AKA (Extensible Authentication Protocol- Authentication and Key Agreement).
With AKA based encryption procedures applied, a CDMA2000 1X packet data call gets Enhanced Subscriber Privacy
(ESP) with encryption on all information bearers and also in multiple layers. At the air interface level, a strong
encryption algorithm ‘AES’ with large keys (128-bit) gets applied. Application encryption can also be applied with any
standard end-to-end encryption at the application layer level, such as IP security (IPsec) and Pretty Good Privacy
(PGP).
4.2.2.2
The CDMA2000 1xEV-DO Mobile Communication Systems [17]
CDMA2000 EV-DO (Evolution-Data Optimized) introduces new high-speed packet-switched transmission techniques
that are specifically designed and optimized for a data-centric broadband network that can deliver peak data rates
beyond 3 Mbps in a mobile environment.
Figure 2. Air Interface Layering Architecture
In CDMA2000 1xEV-DO systems, a separate layer called “Security Layer” [18] has been defined exclusively to take
care of all security related requirements. As shown in Figure 2. the security layer sits in between the MAC and
Connection layers of the 1xEV-DO layered architecture. The protocols defined within the security layer are as follows:
 Key Exchange protocol: Provides the procedures followed by the access network and by the access terminal to
exchange security keys for authentication and encryption. The DH Key Exchange Protocol provides a method
for session key exchange based on the Diffie-Hellman (DH) key exchange algorithm.
 Authentication protocol: Provides the procedures followed by the access network and the access terminal for
authenticating traffic. In CDMA2000 1xEV-DO systems, there are three distinct types of authentication
procedures in use and they are:
o RAN Access authentication using the Challenge Handshake Authentication Protocol (CHAP).
o IS-856 Air interface authentication for integrity protection using SHA-1 hashing algorithm to
authenticate every Access channel message.
o Service/Subscription authentication with the Operator/ISP
 With Packet Data Serving Node/ Foreign Agent (PDSN/FA) for Simple IP using CHAP
GISFI
Release 1
15
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
protocol.
 With Home Agent for Mobile IP using CHAP protocol and additional authentication by the
Home Agent.
 Encryption protocol: Provides the procedures followed by the access network and the access terminal for
encrypting traffic. The AES (Advanced Encryption System) is used for traffic channel encryption. The IPsec
protocol is supported for securing traffic between the Access Terminal and the nodes within the PDN (Packet
Data Network)
Femto cell Network Security Measures: The 3GPP2 specifications provide a complete security architecture that allows
CDMA2000 femto cell networks to support large numbers of femto cells via standard commercial IPsec/IKEv2-based
security gateways.
Security Developments for Machine-to-Machine (M2M) Communications: Enhancements in CDMA2000 1X (Rel C
onwards) as well as in 1xEV-DO systems provide end-to-end security by using improved encryption algorithms and
other means such as improved authentication, hashing, data protection through integrity and anonymity features.
4.3
Security Provisions in the Fourth Generation (4G [27])
Mobile Communication Systems
Based on the security architecture designed by the 3GPP, which is the same as illustrated in Figure 1. in Section 3
above, the 4G security architecture with further modifications is as follows:
a) LTE-Advanced/ Release 10 description [19]: Release 10 has the following security enhancements:
i. Lawful Interception in the 3GPP Rel-10 (LI10)
ii. Security for LTE Relay Nodes (Stage 2)
b) Release 11 description [20]: Release 11 has the following security enhancements:
i. EEA3 and EIA3 (new Encryption & Integrity EPS security Algorithms)
ii. Specification of Protection against Unsolicited Communication for IMS (PUCI)
iii. Home e-node B (H(e)NB) security features for User Equipment (UE) mobility scenarios (Stage2)
iv. Security enhancements for usage of Generic Bootstrapping Architecture (GBA) from the
browser
v. Generic Bootstrapping Architecture (GBA) extensions for re-use of SIP Digest credentials
vi. Lawful Interception in the 3GPP Rel-11
c) Release 12 description [21]: Release 12 includes Security aspects of Public Warning System (PWS_Sec).
GISFI
Release 1
16
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
5
Security Issues in Mobile Communication Systems
5.1
Security Issues in the Second Generation (2G) and Second
Generation - Transitional (2.5G/ 2.75G [3]) Mobile
Communication Systems
5.1.1
The GSM Evolution
5.1.1.1
The 2G Global System for Mobile Communication (GSM) [28]
a) Unilateral authentication and vulnerability to the man-in-the-middle attack [28]: This means that only
the GSM network authenticates the mobile station (MS). The MS does not authenticate network so the
attacker can use a false Base Station Transceiver (BTS) with the same mobile network code as the
subscriber's legitimate network to impersonate, both the network and a user, and perform a man-inthe-middle attack. The attacker can then perform several scenarios to modify or fabricate the
exchanged data. Impersonation of a user is the capability whereby the intruder sends signalling and/or
user data to the network, in an attempt to make the network believe they originate from the target
user. The required equipment is a modified Mobile Station (MS). Impersonation of the network (false
BTS) is the capability whereby the intruder sends signalling and/or user data to the target user, in an
attempt to make the target user believe they originate from a genuine network. [29]
b) Flaws in implementation of A3/A8 algorithms [28]: Although the GSM architecture allows operator to
choose any algorithm for A3 and A8, many operators used COMP128 (or COMP128-1) that was
secretly developed by the GSM association, to achieve ‘Security through Obscurity’ [30]. The
structure of COMP128 was finally discovered by reverse engineering and some revealed
documentations, and many security flaws were subsequently discovered. In addition to the fact that
COMP128 makes revealing Ki possible especially when specific challenges are introduced, it
deliberately sets ten rightmost bits of Kc equal to zero that makes the deployed cryptographic
algorithms 1024 times weaker and more vulnerable, due to the decreased keyspace. Some GSM
network operators tried another new algorithm for the A3/A8, called COMP128-2. COMP128-2 was
also secretly designed and inherited the problem of decreased keyspace.
c) Subscriber Identity Module (SIM) card cloning [28]: Another important challenge is to derive the root
key Ki from the subscriber's SIM. In April 1998, the Smartcard Developer Association (SDA) and the
ISAAC research group could find an important vulnerability in the COMP128 algorithm that helped
them to extract Ki in eight hours by sending many challenges to the SIM. Ultimately, a side-channel
attack, called partitioning attack, was proposed by the IBM researchers that makes attacker capable of
extracting Ki if he could access the subscriber's SIM just for one minute. The attacker can then clone
the SIM and use it for his fraudulent purposes.
d) Over-the-air cracking [28]: It is feasible to misuse the vulnerability of COMP128 for extracting the Ki
of the target user without any physical access to the SIM. This can be accomplished by sending
several challenges over the air to the SIM and analyzing the responses. However, this approach may
take several hours. The attacker can also extract International Mobile Subscriber Identity (IMSI) using
an approach explained in point (h). After finding Ki and IMSI of the target subscriber, the attacker
can clone the SIM and make and receive calls and other services such as SMS in the name of the
victim subscriber.
e) Flaws in cryptographic algorithms [28]: Both A5/1 and A5/2 algorithms were developed in secret. The
output of A5/1 is the XOR of three Linear Feedback Shift Registers (LFSRs). An efficient attack to
A5/1 can be used for a real-time cryptanalysis on a PC. A5/2 is the deliberately weakened variant of
A5/1.
f)
Short range of protection [28]: The encryption is only accomplished over the airway path between MS
and BTS. There is not any protection over other parts of network and the information is clearly sent
over the fixed parts. This is a major exposure for the GSM, especially when the communication
between BTS and Base Station Controller (BSC) is performed over the wireless links that have
potential vulnerabilities for interception. In some countries, the encryption facility of the air interface
GISFI
Release 1
17
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
is not activated at all. There are also security problems on the GSM backbone. The deployed
Signaling System no.7 (SS7) has also several security vulnerabilities. SS7 incorporates very limited
authentication procedures since it was originally designed for the closed telecommunication
communities. The interconnection with Internet can also have its potential vulnerabilities.
g) Lack of user visibility [28]: The ciphering is controlled by the BTS. The user is not alerted when the
ciphering mode is deactivated. A false BTS can also deactivate the ciphering mode and force MS to
send data in an unencrypted manner.
h) Leaking the user anonymity [28]: Whenever a subscriber enters a location area for the first time or
when the mapping table between the subscriber's Temporary Mobile Subscriber Identity (TMSI) and
IMSI is lost, the network requests the subscriber to clearly declare the IMSI. This can be misused to
fail the user's anonymity and can be accomplished by sending an IDENTITY REQUEST command
from a false BTS to the MS of the target user to find the corresponding IMSI.
i)
Vulnerability to the Denial of Service (DoS) attack [28]: A single attacker is capable of disabling an
entire GSM cell via a DoS attack. The attacker can send the CHANNEL REQUEST message to the
BSC for several times but he/she does not complete the protocol and requests another signaling
channel. Since the number of signaling channels is limited, this leads to a DoS attack. It is feasible
since the call setup protocol performs the resource allocations without adequate authentication.
j)
Absence of integrity protection [28]: Although the GSM security architecture considers authentication
and confidentiality, there is no provision for any integrity protection of information. Therefore, the
recipient cannot verify that a certain message was not tampered with.
k) Vulnerability to replay attacks [28]: The attacker can misuse the previously exchanged messages
between the subscriber and network in order to perform the replay attacks.
l)
5.1.1.2
Increased redundancy due to the coding preference [28] [45]: The Forward Error Correcting (FEC) is
performed prior to the ciphering so there is a redundancy, the pattern of which can be known, such
that attackers know part of the plaintext and the full ciphertext. That increases the security
vulnerabilities of deployed cryptographic algorithms.
The General Packet Radio Service (GPRS) and subsequent Enhanced Data
Rates for GSM Evolution (EDGE) [31] [32]
Based on the architecture of GPRS and the employed security measures, there are five critical areas where the GPRS
security is exposed and security attacks may be carried out, are as:
Figure 1. Attack points in the GPRS network[6]
GISFI
Release 1
18
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
a) The mobile station and the SIM-card [31] [32]: Authentication algorithms on the SIM card being
identical to those of the GSM, attacks similar to those described in section 5.1.1.1. can still be
initiated. A new vector of attack on the GPRS network has its roots in mobile terminals interacting
with computer systems and also, through GPRS, with the Internet. Therefore attacks from computer
viruses or worms that are very common on the Internet can also affect mobile stations and/or SIMcards.
b) The Access Network [31] [32]: interface between the Mobile Station (MS) and the Serving GPRS
Support Node (SGSN): The GPRS system protects this part of the network by employing a set of
security mechanisms that ensure authentication of mobile users (unilateral, as in the case of GSM),
confidentiality of user’ identity, and ciphering of users data and signalling information exchanged
through it. However, exploiting some weaknesses (to mention, an unauthorized BTS introduction due
to unilateral authentication, eavesdropping and interception possibility on (GPRS Encryption
Algorithm) GEA3 encryption, weak confidentiality due to a limited 64 bits of encryption key length
(Kc)) that these mechanisms present, an adversary may perform the following attacks, which may
result in the system breakdown or the compromise of end-user security, such as Denial of Service and
Man-in-the-Middle attack, similar to the GSM network security issues.
c) The GPRS backbone network [31] [32]: The Gn interface: Like the GSM network, the GPRS core
network infrastructure is very vulnerable. Partly based on SS7, it unfortunately inherits all its
weaknesses. The IP-based GPRS Tunelling Protocol (GTP) protocol being unsecured, eavesdropping
or interception of messages exchanged between SGSNs and Gateway GPRS Support Nodes (GGSNs)
is conceivable. An intruder may also initiate denial-of service (DoS) attacks on the signaling or may
try to obtain information from a Home Location Register (HLR) or the Authentication Center (AuC).
d) The packet network that connects different operators [31] [32]: The Gp interface: The Gp Interface,
which provides connectivity between GPRS networks that belong to different operators, is also
vulnerable to malicious actions. The security threats to the Gp interface mainly concern with the
availability of resources and services, the authentication and authorization of users and actions, and
the integrity and confidentiality of the data transferred. A vital security issue of the Gp interface is the
lack of security measures in the GTP protocol. This allows an attacker to cause denial of service to
users by (i) flooding GPRS nodes with useless and unwanted traffic that consumes the majority of
processing and communication resources, (ii) performing attacks that target the GTP protocol, such as
deleting or updating Packet Data Protocol (PDP) contexts. These actions remove or modify the GTP
tunnels between the SGSN and the GGSN (of an operator under attack) that are used for user data
transfer. A malicious operator or an attacker with access to the Gp Interface may create a bogus
SGSN to obtain unauthorized Internet access, and also to intercept the user data exchanged by the
sessions, compromising end-user security.
e) The public Internet [31] [32]: The Gi interface: exposes the GPRS network to multiple classes of
Internet-specific attacks such as worms and other viruses whose objectives are usually a denial of
service. Another form of potential attack is spam. Subscribers are charged based on the amount of
megabytes transferred on the GPRS network and thus a spam attack can cause overbilling for the user.
Denial of service attacks represent the largest threat to the Gi interface. Attackers may be able to flood
the links that connect the GPRS network to external packet data networks with useless traffic,
thereby, prohibiting legitimate traffic to pass. Apart from harm to the network availability, the GPRS
data are conveyed unprotected over the public Internet enabling anyone to read and/or manipulate
them, and, thus, compromising user data confidentiality and integrity.
The EDGE network is subject to the same vulnerabilities as the GPRS network. [33]
5.1.2
The Code Division Multiple Access (CDMA)-based 2G/2.5G
evolution [34]
Voice privacy of IS-95 CDMA cellular system is provided by means of the long code mask. The long code mask is not
transmitted through any channel; it is constructed by the base station and the mobile station. To recover the long code
sequence, the eavesdropper may exhaustively search the 42-bit long code mask, with a time complexity of O (242) [35]
GISFI
Release 1
19
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
On the downlink channel, to recover the long code sequence, the eavesdropper intercepts the downlink traffic channel,
demodulates the intercepted data frames, and dispreads the data frames using the Walsh code specific to the channel.
[35]
By exploiting information redundancy on the downlink traffic channel, it is shown that an eavesdropper can recover the
voice privacy mask after eaves-dropping the transmission on the downlink traffic channel for about one second. Thus,
IS-95 CDMA voice privacy is vulnerable under ciphertext-only attacks. [34]
The vulnerability of the voice privacy may have an effect on the security of the authentication process since the long
code mask is generated during the authentication process. [35]
cdmaOne/ IS-95 CDMA systems had the following security weaknesses [36]:
 Extensive cryptanalysis of algorithms used that results in weak authentication, data protection and user anonymity.
 64-bit keys used, are found to be too short for strong encryption.
 Unilateral authentication of the user by the network; lack of mutual authentication. In the context of CAVE, the term
authentication refers to primarily unilateral mechanisms that allow the network to validate the authenticity of the
roaming mobile station (MS) [46]. This can lead to false base station attacks [47].
5.2
Security Issues in the Third Generation (3G) and Third
Generation Transitional (3.5G [25]/ 3.95G [26]) Mobile
Communication Systems
5.2.1
The Third Generation Partnership Project-based (3GPP-based)
Mobile Communication Systems
3G security features counteract many security threats in 2G system. The 3G security architecture is much secure than
2G system.
However, with the introduction of higher data rates and a subsequent growing usage of Internet-related services by
users, which is achieved by the opening-up of earlier closed telecom networks connecting to external data networks and
non-3GPP networks (in the case of roaming), all this opens up the 3G system to vulnerabilities that are similar to those
of data networks.
In such scenarios, attacks on 3G networks can be classified as follows [38]:
a) Interception [38]: The attacker intercepts information, for example, reads signaling messages on a
cable (connecting to 3G Core Network Entities), but does not modify or delete them. This is a passive
attack. This affects the privacy of the subscriber and the network operator. The attacker may use the
data obtained from interception to analyze traffic and eliminate the competition provided by the
network operator.
b) Fabrication/Replay [38]: In this case the attacker may insert spurious objects into the system. These
objects depend on the level of the attackers physical access to the system. For example, in a 3G Core
Network Entity cable attack, the attacker may insert fake signaling messages. In a 3G Core Network
Entity Access attack, the attacker may insert fake service logic or fake subscriber data into this
system. The effects could result in the attacker masquerading as an authority figure.
c) Modification of Resources [38]: The attacker causes damage by modifying system resources. For
example, in a 3G Core Network Entity cable attack, the attacker may modify signaling messages in
and out of the cable. In a 3G Core Network Entity Access attack, the attacker may modify service
logic or modify subscriber data in the entity.
d) Denial Of Service [38]: The attacker causes an overload or a disruption in the system such that
network functions in an abnormal manner. The abnormal behaviour could be legitimate subscribers
not receiving service, illegitimate subscribers receiving service or the entire network may be disabled
as a result of the attack. For example, Denial of Service may be caused by the changing of the Call
GISFI
Release 1
20
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Forwarding (CF) number since the victim does not gain access to the voice message or the call itself.
Sending two or three call forward numbers to the Session Control Agent at the MSC may cause
confusion and the call may not be handled properly.
e) Interruption [38]: The attacker caused an Interruption by destroying resources. For example, in a 3G
Core Network Entity cable attack, the attacker may delete signaling messages in and out of the cable.
In a 3G Core Network Entity Access attack, the attacker may delete a subscriber data in the entity
such as an HLR and the attacker may not receive service. For example, in the CF case, In the
Interruption attack, the attacker may delete certain target subscriber profiles in the data sources so that
they may not receive CF service. At the Mail server, the emails in the Post office data store may be
deleted. Service logic of certain entities may be completely deleted such as the CFS Filtering Agent
so that they may be unable to provide any service.
5.2.2.
5.2.2.1
The Third Generation Partnership Project 2-based (3GPP2-based)
Mobile Communication Systems
The CDMA2000 1x Mobile Communication Systems [39] [40]
CDMA uses the CAVE algorithm for authentication along with encryption algorithms like Cellular Message Encryption
Algorithm (CMEA) and ORYX for privacy and integrity of data. These algorithms were considered to be secure till
recent times. But it is now known that there are possible cryptanalytic attacks possible on these algorithms as
documented in [41] [42]. The attacks are similar to those conducted on GSM system namely known plaintext and
known cipher text attacks. As with GSM-based systems, CDMA2000 1x systems are vulnerable to rogue networks
because of the lack of authentication on the network side.
Voice traffic in CDMA2000 1x systems is not encrypted, but is scrambled using spread spectrum techniques. This
makes it difficult to eavesdrop on voice traffic, but not impossible; specialized equipment for this purpose does exist.
However, both the spread spectrum scrambling and the data encryption algorithms (E-CMEA and ORYX) only protect
the traffic between the mobile station and the core network infrastructure. Once traffic reaches the core network, it is
decrypted and remains in the clear to the other end of the call. If the other end of the call is also a CDMA 2000 1x
mobile station, the traffic will be re-encrypted only for the wireless portion between the core network and the end
mobile station. [40]
5.2.2.2
The CDMA2000 1xEV-DO Mobile Communication Systems [43]
The CDMA2000 1xEV-DO (Revision 0) addresses some of the vulnerabilities present in CDMA2000 1x. The
cryptographic algorithms that are used in 1xEV-DO are well known and have been fully analyzed for weaknesses.
However, encryption is applied only to the air interface as in the case of CDMA2000 1x; it is not end-to-end. If an
operator uses 1xEV-DO with the older algorithms, that implementation will be subject to the same vulnerabilities as
CDMA2000 1x. Without Enhanced Subscriber Authentication (ESA) and Enhanced Subscriber Privacy (ESP), mutual
authentication is not supported and voice traffic is scrambled but not encrypted. No vulnerability information was found
concerning Revision A of 1xEV-DO.
5.2.3
Security Issues (perceived) in the 3GPP Fourth Generation (4G [27])
Mobile Communication Systems
Unlike existing networks, which are partially IP-based, LTE networks are all-IP networks. When devices are connected
to IP networks, with their own IP addresses, they become vulnerable to attack in much the same way as personal
computers: devices can be hacked, spoofed or infected with viruses. [44]
Also with the significant processing capability improvements on the end-user device types, these devices now operate
using full-fledged Operating Systems (OSs), similar to those of Personal Computers. Recent examples of such end-user
device and computer convergence are that of the announcements of the same OS working on computers, tablets and
smartphones. Smartphones and connected tablets are suddenly very more capable to run botnets and viruses, especially
GISFI
Release 1
21
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
as new services such as file-sharing and more advanced messaging services will emerge for smartphones and tablets.
One paper that presents/analyzes possible security challenges with LTE systems can be found at [48].
6
List of Mandatory and Optional Security Features
derived from 3GPP (33-series) Security Technical
Specifications
6.1
From 3GPP TS 33.102, V11.3.0, (2012-06) (Release 11)
[49]:
Title: 3G Security; Security Architecture[49]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
6.4.3
Cipher Key and Integrity key lifetime – at call-setup


6.4.5
Security mode set-up procedure: Initiation of
integrity protection of signalling messages at each
new signalling connection establishment between
MS and VLR/SGSN


6.4.5
Exception case: Security mode set-up procedure:
Signalling connection establishment and the only
result is periodic location registration, i.e. no
change of any registration information


6.4.5
Exception case: Security mode set-up procedure:
There is no MS-VLR/SGSN signalling after the
initial L3 signalling message sent from MS to
VLR/SGSN, i.e. in the case of deactivation
indication sent from the MS followed by
connection release


6.4.5
Exception case: Security mode set-up procedure:
The only MS-VLR/SGSN signalling after the initial
L3 signalling message sent from MS to
VLR/SGSN, and possible user identity request and
authentication (see below), is a reject signalling
message followed by a connection release


6.4.5
Exception case: Security mode set-up procedure:
VLR/SGSN to start integrity protection before
sending a reject signalling message that causes the
CSG list on the UE to be modified


6.4.5
Exception case: Security mode set-up procedure: If
the call is an emergency call teleservice as defined
in TS 22.003, also see section 6.4.9.2 of this TS (TS
33.102)


GISFI
Release 1
22
6.4.5
6.6
6.8.10.2
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Exception case: Security mode set-up procedure: If
the PS connection establishment is for an
emergency session, see clause 6.4.9.2 of this TS
(TS 33.102)


Access link data confidentiality (as mentioned in
Annex J. Change History section)




Interoperation and handover between UMTS and
GSM: SRVCC from circuit switched
UTRAN/GERAN to HSPA: CS to PS HO
command (sent from source BSC/RNC to ME) is
integrity protected for UTRAN
6.8.10.2
Interoperation and handover between UMTS and
GSM: SRVCC from circuit switched
UTRAN/GERAN to HSPA: CS to PS HO
command (sent from source BSC/RNC to ME) is
ciphered for UTRAN and GERAN

Annex C: C.3
Sequence number management profiles: Age limit
for sequence numbers


Annex I: I.3
Security mechanisms for interfaces with RNCs in
exposed locations: For Iu and Iur, tunnel mode
IPsec implementation


Annex I: I.3
Security mechanisms for interfaces with RNCs in
exposed locations: Transport mode IPsec
implementation on Iu and Iur




Sub-section 6.4.9.2: Emergency Call handling [49]:
Security procedures (Integrity Protection and Ciphering) not applied:
As a serving network option, emergency calls, or PS connections for emergency sessions, may be established without
the network having to apply the security mode procedure as defined in TS 24.008.
The following are the only cases where the "security procedure not applied" option may be used:
a) Authentication is impossible because the (U)SIM 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 (U)SIM is not permitted to receive non-emergency services from the
serving network (e.g. there is no roaming agreement or the IMSI is barred);
Authentication is possible but the serving network cannot successfully authenticate the (U)SIM.
GISFI
Release 1
6.2
23
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
From 3GPP TS 33.401, V11.4.0, (2012-06) (Release 11)
[50]:
Title: 3GPP System Architecture Evolution (SAE); Security architecture [50]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
5.1.3.1
User-to-Network security: User data and signalling
data confidentiality: Ciphering requirements: RRC
signalling confidentiality

5.1.3.1
User-to-Network security: User data and signalling
data confidentiality: Ciphering requirements: NAS
signalling confidentiality

5.1.3.1
User-to-Network security: User data and signalling
data confidentiality: Ciphering requirements: User
plane confidentiality protection done at PDCP layer

Security Procedures between UE and EPS Access
Network Elements: Signalling procedure for
periodic local authentication

7.5
9.2.2
Security interworking between E-UTRAN and
UTRAN: Handover Procedure from UTRAN to
EUTRAN: A) Handover signalling in case of
successful handover: The UTRAN HO command is
integrity protected
9.2.2
Security interworking between E-UTRAN and
UTRAN: Handover Procedure from UTRAN to
EUTRAN: A) Handover signalling in case of
successful handover: The UTRAN HO command is
ciphered
9.2.2
9.2.2
Security interworking between E-UTRAN and
UTRAN: Handover Procedure from UTRAN to
EUTRAN: B) Subsequent NAS signalling: A
Tracking Area Update (TAU) procedure following
handover from UTRAN to E-UTRAN is mandatory
if the Tracking Area has changed (TS 23.401)



Security interworking between E-UTRAN and
UTRAN: Handover Procedure from UTRAN to
EUTRAN: B) Subsequent NAS signalling: A
Tracking Area Update (TAU) procedure following
handover from UTRAN to E-UTRAN is mandatory
if the Tracking Area has not changed (TS 23.401)
11
Network Domain Control Plane protection:
Integrity protection of IP based control plane
signalling for EPS and E-UTRAN shall be done
according to NDS/IP
11
Network Domain Control Plane protection: For S1MME and X2-C, tunnel mode IPsec is mandatory
GISFI





Release 1
24
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
to implement on the eNB
11
Network Domain Control Plane protection: In case
control plane interfaces are trusted (e.g. physically
protected), protection according to TS 33.210 and
TS 33.310

11
Network Domain Control Plane protection:
Transport mode IPsec for implementation on the
X2-C and S1-MME

12
Backhaul link user plane protection: On the X2-U
and S1-U, transport mode IPsec implementation

12
Backhaul link user plane protection: Tunnel mode
IPsec implementation on the eNB for X2-U and S1U


14.3.1
SRVCC between E-UTRAN and Circuit Switched
UTRAN/GERAN: SRVCC from circuit switched
UTRAN/GERAN to E-UTRAN: Handover
signalling in case of successful handover: Integrity
Protection of the CS to PS HO command, sent from
the RNC/BSC to the UE, in the UTRAN


14.3.1
SRVCC between E-UTRAN and Circuit Switched
UTRAN/GERAN: SRVCC from circuit switched
UTRAN/GERAN to E-UTRAN: Handover
signalling in case of successful handover: Ciphering
of the CS to PS HO command, sent from the
RNC/BSC to the UE, in the UTRAN or in GERAN
(TS 33.102)


Annex D:
D.2.1
Security for Relay Node Architectures: Solution:
General: In the case of a USIM-RN binding
solution realized using certificates, the support for
certificate-based procedures detailed in TS 33.401
(Annex D)


Annex D:
D.2.1
Security for Relay Node Architectures: Solution:
General: In the case of a USIM-RN binding
solution realized using symmetric pre-shared keys,
the support for pre-shared-key-based procedures
detailed in TS 33.401 (Annex D)


Annex D:
D.3.2
Secure Channel Profiles: APDU secure channel
profile: For encryption, AES-CBC support as
specified in ETSI TS 102 484


Annex D:
D.3.2
Secure Channel Profiles: APDU secure channel
profile: Other encryption algorithms support,
specified in ETSI TS 102 484


Annex D:
D.3.2
Secure Channel Profiles: APDU secure channel
profile: For integrity protection, AES-CMAC
support as specified in ETSI TS 102 484


Annex D:
D.3.3.2
Secure Channel Profiles: Key agreement based on
certificate exchange: Common profile for RN and
UICC certificate: The subject name format support
with "(C=<country>), O=<Organization Name>,
CN=<Some distinguishing name>"


GISFI
Release 1
25
Annex D:
D.3.3.3
6.3
Secure Channel Profiles: Key agreement based on
certificate exchange: RN certificate profile: The
support of the countryName (C) and serialNumber
attributes in the subject name
GISFI TR SP.1xxx V1.0.0 (20xx-xx)


From 3GPP TS 33.210, V12.0.0, (2012-06) (Release 12)
[51]:
Title: 3G security; Network Domain Security (NDS); IP network layer security [51]
Document
Security Mechanism
Mandatory
5.1
Key management and distribution architecture for
NDS/IP: Security services afforded to the protocols:
Data integrity protection

5.1
Key management and distribution architecture for
NDS/IP: Security services afforded to the protocols:
Data origin authentication

5.1
Key management and distribution architecture for
NDS/IP: Security services afforded to the protocols:
Anti-replay protection

5.1
Key management and distribution architecture for
NDS/IP: Security services afforded to the protocols:
Confidentiality (with limited protection against
traffic flow analysis)
Section/ Subsection No.

5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-1 (ISAKMP SA):
Support of 3DES in CBC mode for confidentiality

5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-1 (ISAKMP SA):
Support of AES in CBC mode (RFC 3602) for
confidentiality

5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-1 (ISAKMP SA):
Support of SHA-1 for integrity/message
authentication

5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-1 (ISAKMP SA):
Support of Diffie-Hellman group 2 for DiffieHellman exchange

5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-2 (IPsec SA): Perfect
GISFI
Optional

Release 1
26
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Forward Secrecy
5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-2 (IPsec SA): Only IP
addresses or subnet identity types (address types)


5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-2 (IPsec SA): Support
of Notifications


5.4.1
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-1
(IKEv1): For IKEv1 phase-2 (IPsec SA): Support
of Diffie-Hellman group 2 for Diffie-Hellman
exchange

5.4.2
Key management and distribution architecture for
NDS/IP: Profiling of Internet Key Exchange-2
(IKEv2): For the CREATE_CHILD_SA exchange:
Perfect Forward Secrecy
5.6.2
Key management and distribution architecture for
NDS/IP: Network domain security key
management and distribution architecture for native
IP based protocols: Interface description: Zainterface (SEG-SEG): Authentication/integrity
protection on the Za-interface
5.6.2
Key management and distribution architecture for
NDS/IP: Network domain security key
management and distribution architecture for native
IP based protocols: Interface description: Zainterface (SEG-SEG): Encryption on the Zainterface

5.6.2
Key management and distribution architecture for
NDS/IP: Network domain security key
management and distribution architecture for native
IP based protocols: Interface description:
Implementation of the Zb interface (NE-SEG/ NENE)

5.6.2
Key management and distribution architecture for
NDS/IP: Network domain security key
management and distribution architecture for native
IP based protocols: Interface description: If Zb
interface is implemented, use of encryption on this
interface

Annex B: B.2
Security Protection for GTP: Policy discrimination
of GTP-C and GTP-U: NDS/IP support for pre-R99
versions of GTP

Annex D: D.2
Security protection of UTRAN/GERAN IP
transport protocols: Protection of UTRAN/GERAN
IP transport protocols and interfaces: Transport
mode IPsec implementation and use on the Iur/Iurh
interface, if a UTRAN node has implemented SEG
functionality within the same physical entity

GISFI



Release 1
27
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
3GPP TS 33.210: Section 5.6.1: Network domain security architecture outline [51]:
The NDS/IP key management and distribution architecture is based on the IKEv1 protocol (RFC 2401, RFC 2407, RFC
2408, RFC 2409) or IKEv2 (RFC-5996) protocol. A number of options available in the full IETF IPsec protocol suite
have been considered to be unnecessary for NDS/IP. Furthermore, some features that are optional in IETF IPsec have
been mandated for NDS/IP and lastly a few required features in IETF IPsec have been deprecated for use within
NDS/IP scope.
Additional guidelines on how to apply IPsec in SCTP are specified in RFC3554. This RFC is optional for
implementation unless otherwise explicitly indicated per reference point.
6.4
From 3GPP TS 33.310, V11.0.1, (2012-07) (Release 11)
[52]:
Title: Network Domain Security (NDS); Authentication Framework (AF) [52]
Document
Security Mechanism
Mandatory
1
Scope: Implementation of Za interface according to
TS 33 210

1
Scope: Implementation of Zb interface according to
TS 33 210


5.2.2.2
Architecture and use cases of the NDS/AF: Use
cases: Establishment of secure communications:
TLS case: During connection initiation,
‘CertificateRequest message’ from TLSb to TLSa


5.2.2.2
Architecture and use cases of the NDS/AF: Use
cases: Establishment of secure communications:
TLS case: Verification of “CertificateVerify
message” by TLSb, using TLSa’s public key


Section/ Subsection No.
Optional
6.1.1
Profiling: Certificate Profiles: Common rules to all
certificates: Hash algorithm for use before signing
certificate: SHA-1 and SHA-256 support
6.1.1
Profiling: Certificate Profiles: Common rules to all
certificates: Country field (C) in Subject and issuer
name format ((C=<country>), O=<Organization
Name>, CN=<Some distinguishing name>)


6.1.1
Profiling: Certificate Profiles: Common rules to all
certificates: Server field (ou) in Subject and issuer
name format (cn=<hostname>, (ou=<servers>),
dc=<domain>, dc=<domain>)


6.1.1
Profiling: Certificate Profiles: Common rules to all
certificates: Implementation of Certificate
extensions which are not mandated by TS 33 310
but which are mentioned within RFC5280


6.1.2
Profiling: Certificate Profiles: Interconnection CA
Certificate profile: Extensions: Non-critical
GISFI


Release 1
28
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
authority key identifier
6.1.2
Profiling: Certificate Profiles: Interconnection CA
Certificate profile: Extensions: Non-critical subject
key identifier
6.1.2
Profiling: Certificate Profiles: Interconnection CA
Certificate profile: Extensions: Critical key usage
(as specified in TS 33 310)

6.1.2
Profiling: Certificate Profiles: Interconnection CA
Certificate profile: Extensions: critical basic
constraints (as specified in TS 33 310)

6.1.3
Profiling: Certificate Profiles: SEG Certificate
profile: Extensions: Non-critical authority key
identifier

6.1.3
Profiling: Certificate Profiles: SEG Certificate
profile: Extensions: Non-critical subject key
identifier

6.1.3
Profiling: Certificate Profiles: SEG Certificate
profile: Extensions: Non-critical subjectAltName


6.1.3
Profiling: Certificate Profiles: SEG Certificate
profile: Extensions: critical key usage, (as specified
in TS 33 310)


6.1.3
Profiling: Certificate Profiles: SEG Certificate
profile: Extensions: Non-critical Distribution points
(as specified in TS 33 310)


6.1.3a
Profiling: Certificate Profiles: TLS entity certificate
profile: Extensions: non critical authority key
identifier
6.1.3a
Profiling: Certificate Profiles: TLS entity certificate
profile: Extensions: non critical subject key
identifier
6.1.3a
Profiling: Certificate Profiles: TLS entity certificate
profile: Extensions: critical key usage (as specified
in TS 33 310)
6.1.3a
Profiling: Certificate Profiles: TLS entity certificate
profile: Extensions: non-critical extended key usage
6.1.3a
Profiling: Certificate Profiles: TLS entity certificate
profile: Extensions: non-critical Distribution points
6.1.4
Profiling: Certificate Profiles: SEG CA certificate
profile: Extensions: non critical authority key
identifier

6.1.4
Profiling: Certificate Profiles: SEG CA certificate
profile: Extensions: non critical subject key
identifier

6.1.4
Profiling: Certificate Profiles: SEG CA certificate
profile: Extensions: critical key usage (as specified
in TS 33 310)
6.1.4
Profiling: Certificate Profiles: SEG CA certificate
profile: Extensions: critical basic constraints (as
GISFI












Release 1
29
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
specified in TS 33 310)
6.1.4a
Profiling: Certificate Profiles: TLS client/server CA
certificate profile: Extensions: non critical authority
key identifier

6.1.4a
Profiling: Certificate Profiles: TLS client/server CA
certificate profile: Extensions: non critical subject
key identifier

6.1.4a
Profiling: Certificate Profiles: TLS client/server CA
certificate profile: Extensions: critical key usage (as
specified in TS 33 310)


6.1.4a
Profiling: Certificate Profiles: TLS client/server CA
certificate profile: Extensions: critical basic
constraints (as specified in TS 33 310)


Profiling: CRL Profile: Hash algorithm for use
before signing CRL: SHA-1 (except for newly
created CRLs) and SHA-256 support


6.2a.1
Profiling: TLS Profiling: TLS Profile: The TLS
server always sends its own end entity certificate in
the Server Certificate message


6.2a.1
Profiling: TLS Profiling: TLS Profile: The TLS
client sends its own end entity certificate in the
Certificate message if requested by the TLS server


6.2a.1
Profiling: TLS Profiling: TLS Profile: Crosscertificates shall not be sent by the TLS entities in
the TLS handshake as they are available locally to
the TLS entities


9.4.3
Certificate Enrolment for Base Stations: Certificate
Profiles: Vendor CA Certificate: the CRL
distribution point extension in the certificate
9.5.3
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIHeader Field: The
field “protection” of PKIMessage and the field
“protectionAlg” of PKIHeader


9.5.3
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIHeader Field: The
usage of the transactionID field


9.5.3
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIHeader Field: The
usage of the senderNonce and the recipNonce fields


9.5.4.2
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIBody Field:
Initialization Request: The publicKey field of the
CertTemplate which shall contain the public key of
the base station to be certified by the RA/CA


9.5.4.2
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIBody Field:
Initialization Request: If the poposkInput field of
type POPOSigningKeyInput within
POPOSigningKey field is used, the (usage of)


6.1a
GISFI


Release 1
30
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
sender field within POPOSigningKeyInput
9.5.4.2
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIBody Field:
Initialization Request: If either the subject field or
the publicKey field of the CertTemplate field is
omitted, according to IETF RFC 4211, the
poposkInput field (usage)


9.5.4.2
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIBody Field:
Initialization Request: The extraCerts field of the
PKIMessage carrying the initialization request
which shall contain the base station certificate
provided by the vendor


9.5.4.3
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIBody Field:
Initialization Response: the certificate field in
CertorEncCert (the transfer shall not be encrypted)


9.5.4.3
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIBody Field:
Initialization Response: The extraCerts field of the
PKIMessage carrying the initialization response
which shall contain the operator root certificate and
the RA/CA certificate (or certificates if separate
private keys are used for signing of certificates and
CMP messages)


9.5.4.4
Certificate Enrolment for Base Stations: CMPv2
Profiling: Profile for the PKIBody Field: Key
Update Request and Key Update Response: The
extraCertsField which shall contain the base station
certificate related to the private key used for signing
the PKIMessage


9.6
Certificate Enrolment for Base Stations: CMPv2
Transport: Support for transport of CMPv2
messages between end entities (network elements)
and RA/CA, using HTTP-based protocol as
specified in draft-ietf-pkix-cmp-transport-protocols,
for communication initiated by the end entities
where every CMP request triggers a CMP response
message from the CA or RA


9.6
Certificate Enrolment for Base Stations: CMPv2
Transport: Support for transport of CMPv2
messages between end entities (network elements)
and RA/CA, using HTTP-based protocol as
specified in draft-ietf-pkix-cmp-transport-protocols,
for RA/CA initiated HTTP requests (i.e.
announcements)
Annex E
TLS Protocol Profile: For TLS compression,
CompressionMethod.null support as specified in
TLS 1.2 (RFC 5246)
Annex E
TLS Protocol Profile: Support of compression
methods as specified in RFC 3749
Annex E
TLS Protocol Profile: Support of the cipher suite
TLS_PSK_WITH_AES_128_CBC_SHA256
GISFI






Release 1
31
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
specified in RFC 5487
Section 8: Backward compatibility for NDS/IP NE's and SEGs [52]:
NDS/IP describes an authentication framework whereby the initial IKEv1/IKEv2 authentication is based on the Preshared Secret Key (PSK) authentication method. NDS/AF describes an optional authentication framework which
enables NDS/IP end entities (NEs and SEGs) to perform the initial IKEv1/IKEv2 authentication based on the RSA
Signatures authentication method. An NDS/AF compliant end entity shall also contain NDS/IP functionality. However,
an NDS/IP compliant end entity need not contain NDS/AF functionality unless specifically mandated by TS 33.210 or
any other 3GPP specification.
Annex A: Critical and non-critical Certificate Extensions [52]:
A receiving SEG or TLS entity shall be able to process an extension marked as critical that is mandatory to support in
NDS/AF. When optional to support, a received extension marked as critical shall lead to an error according to RFC
5280
Annex E: TLS Protocol Profile [52]:
The rules on allowed and mandatory cipher suites given in TLS 1.2 (RFC 5246) shall be followed. In addition, the
mandatory cipher suite of TLS 1.1 (RFC 4346) shall be supported.
6.5
From 3GPP TS 33.402, V11.4.0, (2012-06) (Release 11)
[53]:
Title: 3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses [53]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
5.2
Security Features Provided by EPS for non-3GPP
Accesses: User data and signalling data
confidentiality: Provision of User data
confidentiality between the UE and the PDN GW as
defined in clause 9.2.2 of TS 33 402 when DSMIPv6 is used
5.3
Security Features Provided by EPS for non-3GPP
Accesses: User data and signalling data integrity:
Provision of user data integrity between the UE and
the PDN GW as defined in clause 9.2.2 of TS 33
402 when DS-MIPv6 is used


6.3
Authentication and key agreement procedures: Fast
re-authentication procedure for trusted access:
Usage of UE and 3GPP AAA server
implementation of fast re-authentication for EAPAKA'


8.2.3
Establishment of security between UE and ePDG:
Mechanisms for the set up of UE-initiated IPsec
tunnels: Tunnel fast re-authentication and
authorization: Usage of UE and 3GPP AAA server
implementation of fast re-authentication for EAP-


GISFI

Release 1
32
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
AKA'
6.6
9.2.1.1
Security for IP based mobility signalling: Host
based Mobility: MIPv4: General: The MIPv4
signalling messages protection between the UE and
the node acting as FA (non-3GPP access specific)


9.2.1.2.1
Security for IP based mobility signalling: Host
based Mobility: MIPv4: Bootstrapping of MIPv4
FACoA parameters: Procedures: Inclusion of the
MN-FA Authentication Extension (AE) as specified
in RFC 3344, in UE Registration Request (RRQ)
message to the FA as specified in TS 23.402


9.2.2.2.2
Security for IP based mobility signalling: Host
based Mobility: DS-MIPv6: Bootstrapping of
DSMIPv6 parameters: Fast re-authentication and
authorization: Usage of UE and 3GPP AAA server
implementation of fast re-authentication for the use
of EAP-AKA with DSMIPv6


9.3.1.2
Security for IP based mobility signalling: Network
based Mobility: Proxy Mobile IP: PMIP security
requirements: Confidentiality Protection for
protecting PMIP messages

9.3.1.3
Security for IP based mobility signalling: Network
based Mobility: Proxy Mobile IP: PMIP security
mechanisms: For the case of an interface between
two entities in the same security domain, the
protection of the interface by means of IPsec,
according to TS 33.210

11
Network Domain Security: For the case of an
interface between two entities in the same security
domain, the protection of the interface by means of
IPsec, according to TS 33.210

From 3GPP TS 33.320, V11.6.0, (2012-06) (Release 11)
[54]:
Title: Security of Home Node B (HNB) / Home evolved Node B (HeNB) [54]
Document
Security Mechanism
Mandatory
4.1
Overview of Security Architecture and
Requirements: System architecture of H(e)NB: UE
access control by HNB-GW, in the case of nonCSG capable UEs or non-CSG capable HNBs

4.1
Overview of Security Architecture and
Requirements: System architecture of H(e)NB: UE
access control by HNB, in the case of non-CSG
capable UEs or non-CSG capable HNBs
Section/ Subsection No.
GISFI

Optional

Release 1
33
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
4.1
Overview of Security Architecture and
Requirements: System architecture of H(e)NB:
Deployment of HeNB-GW


4.1
Overview of Security Architecture and
Requirements: System architecture of H(e)NB:
Deployment of Local Gateway (L-GW)


4.4.2
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on H(e)NB:
Authentication of the hosting party of the H(e)NB
by the SeGW in cooperation with the AAA server
using EAP-AKA as specified in RFC 4187


4.4.5
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on Backhaul Link:
Implementation of IPsec for the backhaul link


4.4.5
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on Backhaul Link: Use of
IPsec for the backhaul link (based on operator
policy)


4.4.5
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on Backhaul Link:
Hosting Party Module (HPM) authentication


4.4.5
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on Backhaul Link:
Support of a suitable layer 2 protection mechanism
for backhaul link protection, if the H(e)NB is
configurable not to use IPsec
4.4.7
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on Local Gateway (LGW): Local Gateway (L-GW), from a security
point of view


4.4.8
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on the Direct Link
between H(e)NBs: The support of direct links
between two H(e)NBs as specified in clause 4.3.4
(Interface between H(e)NBs)


4.4.8
Overview of Security Architecture and
Requirements: Security Requirements and
Principles: Requirements on the Direct Link
between H(e)NBs: Usage of the security procedures
with IKEv2/IPsec on the direct links


5.2
Security Features: Device Mutual Authentication:
For/In H(e)NB, the device mutual authentication
support between H(e)NB and SeGW
5.3
Security Features: Hosting Party Mutual
Authentication: Performing the hosting party
mutual authentication by the operator’s network,
GISFI




Release 1
34
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
following successful device mutual authentication
between H(e)NB and SeGW.
6.3.1
Security Procedures in H(e)NB: Measures for
Clock Protection: Clock Synchronization Security
Mechanisms for H(e)NB: Use of other secure clock
servers, which do not use the secure backhaul link


7.2.1
Security Procedures between H(e)NB and SeGW:
Device Authentication: General: Support of an
appropriate authentication mechanism for mutual
authentication of H(e)NB and SeGW, if the H(e)NB
is configurable not to use IPsec


7.2.2
Security Procedures between H(e)NB and SeGW:
Device Authentication: SeGW and Device Mutual
Authentication Procedure: Support of the SHA-1
and SHA-256 hash functions, if H(e)NB checks the
revocation status of the SeGW certificate using
OCSP as specified in RFC 2560 and OMA-WAPOCSP (Open Mobile Alliance OMA-WAP-OCSP
V1.0: "Online Certificate Status Protocol Mobile
Profile")

7.2.2
Security Procedures between H(e)NB and SeGW:
Device Authentication: SeGW and Device Mutual
Authentication Procedure: Support for OCSP for
the operator network


7.2.2
Security Procedures between H(e)NB and SeGW:
Device Authentication: SeGW and Device Mutual
Authentication Procedure: Support for the
extension to IKEv2 in H(e)NB and SeGW, for the
SeGW to include OCSP response within IKEv2
according to RFC 4806 when OCSP
communication between H(e)NB and OCSP server
may use the in-band signaling of certificate
revocation status in IKEv2


7.2.2
Security Procedures between H(e)NB and SeGW:
Device Authentication: SeGW and Device Mutual
Authentication Procedure: Support of the SHA-1
and SHA-256 hash functions, if SeGW checks the
revocation status of the H(e)NB certificate using
CRLs according to TS 33.310 or OCSP as specified
in RFC 2560 and OMA-WAP-OCSP (Open Mobile
Alliance OMA-WAP-OCSP V1.0: "Online
Certificate Status Protocol Mobile Profile")
7.2.4
Security Procedures between H(e)NB and SeGW:
Device Authentication: SeGW/IKEv2 Processing
Requirements for H(e)NB Certificates: Certificate
status checking by SeGW, due to the existence of a
CRL or OCSP server information in the H(e)NB
certificate

7.2.5.2.1
Security Procedures between H(e)NB and SeGW:
Device Authentication: Security Profiles: IKEv2
Certificate Profile: IKEv2 Entity Certificates:
OCSP server information in the SeGW certificate,
if OCSP extension according to RFC 4806 is used

GISFI

Release 1
35
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
7.3
Security Procedures between H(e)NB and SeGW:
Hosting Party Authentication: Performing an EAPAKA-based hosting party authentication exchange
by SeGW, after Device Authentication of the
H(e)NB by the SeGW

7.5
Security Procedures between H(e)NB and SeGW:
Device Authorization: Use of a AAA server to
verify the authorization of the H(e)NB to connect to
the operator’s network based on the authenticated
device identity extracted from the H(e)NB
certificate

8.1.1
Security Aspects of H(e)NB Management: Location
Verification: General: Storage of one or more types
of location information of H(e)NB in the verifying
node by operators for location verification.

8.1.6
Security Aspects of H(e)NB Management: Location
Verification: Requirements: Storage of ancillary
information by the verifying node to perform
location verification such as geo-coordinates of
surrounding macrocells, postal address of H(e)NB
as claimed by H(e)NB hosting party, IP address
location information, etc.

8.3.2.1
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: Connection to H(e)MS accessible on
public Internet: General: Support of the SHA-1 and
SHA-256 hash functions, if H(e)NB checks the
revocation status of the H(e)MS certificate using
OCSP as specified in RFC 2560 and OMA-WAPOCSP (Open Mobile Alliance OMA-WAP-OCSP
V1.0: "Online Certificate Status Protocol Mobile
Profile")
8.3.2.1
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: Connection to H(e)MS accessible on
public Internet: General: Support for OCSP for the
operator network

8.3.2.1
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: Connection to H(e)MS accessible on
public Internet: General: Support for the extension
to TLS in H(e)NB and H(e)MS, if OCSP
communication between H(e)NB and OCSP server
may use the in-band signaling of certificate
revocation status in TLS according to TLS
Extensions as specified in Annex E of TS 33.310

8.3.2.1
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: Connection to H(e)MS accessible on
public Internet: General: Support of the SHA-1 and
SHA-256 hash functions, if the H(e)MS checks the
revocation status of the H(e)NB certificate using
CRLs according to TS 33.310 or OCSP as specified
in RFC 2560 and OMA-WAP-OCSP (Open Mobile
Alliance OMA-WAP-OCSP V1.0: "Online
GISFI




Release 1
36
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Certificate Status Protocol Mobile Profile")
8.3.3.1
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: TLS certificate profile: TLS entity
certificates: OCSP server information in the
H(e)MS certificate, if OCSP extension to TLS
according to TLS Extensions as specified in Annex
E of TS 33.310 is used
8.3.4
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: TR-069 protocol profile: Use of TLS to
transport the CPE WAN Management Protocol, in
case that the H(e)MS is accessible on public
internet or when TLS is used within the IPsec
tunnel
8.3.4
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: TR-069 protocol profile: The support of
TLS cipher suite RSA_WITH_RC4_128_SHA
8.3.4
Security Aspects of H(e)NB Management:
Protection of H(e)MS traffic between H(e)MS and
H(e)NB: TR-069 protocol profile: The support for
H(e)NB authentication using client-side (CPE side)
certificates
8.5.1
Security Aspects of H(e)NB Management:
Enrolment of H(e)NB to an Operator PKI: General:
Support and usage of enrolment of a H(e)NB to an
operator PKI
8.5.1
Security Aspects of H(e)NB Management:
Enrolment of H(e)NB to an Operator PKI: General:
According to TS 33 320, support of enrolment
according to the clause 8.5, if the establishment of
direct links between H(e)NBs according to clause
4.3.4 is supported


11.1
Security Procedures for Direct Interfaces between
Base Stations: General: Due to requirement of the
usage of operator certificates for all security
features specified in clause 11, according to TS 33
320, the support of enrolment according to clause
8.5 of the same TS


11.2
Security Procedures for Direct Interfaces between
Base Stations: Direct Link between two H(e)NBs:
Support of the security procedures specified in the
subclause 11.2 of TS 33 320, if direct links for Iurh
or X2 interfaces as specified in clause 4.3.4 of the
same TS are supported


Annex A: A.1
Authentication Call Flows: Device Authentication
Call-flow Example: Inclusion of a Notify Payload
in H(e)NB containing integrity information of
H(e)NB with a Notification Type of
INTEGRITY_INFO in the IKE_AUTH request
Annex A: A.2
Authentication Call Flows: Combined Device and
HP Authentication Call-flow Example: processing
GISFI









Release 1
37
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
of the whole EAP challenge message, including
verification of the received MAC with the newly
derived keying material may be performed within
the H(e)NB’s HPM
Annex A: A.2
Authentication Call Flows: Combined Device and
HP Authentication Call-flow Example: The
computation of the AUTH parameter is performed
within the H(e)NB’s HPM

Section 7.2.2: Security Procedures between H(e)NB and SeGW: Device Authentication: SeGW and Device
Mutual Authentication Procedure [54]:
NOTE 2: It is strongly recommended to support OCSP in the H(e)NB, as this feature may become mandatory for
H(e)NB in future releases.
Section 8.3.2.1: Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and
H(e)NB: Connection to H(e)MS accessible on public Internet: General [54]:
NOTE 2: It is strongly recommended to support OCSP in the H(e)NB, as this feature may become mandatory for
H(e)NB in future releases.
6.7
From 3GPP TS 33.328, V10.0.0, (2011-03) (Release 10)
[55]:
Title: IP Multimedia Subsystem (IMS) media plane security [55]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
5.1
IMS media plane security features: General: The
support for IMS media plane security mechanisms
and procedures in IMS UEs

5.1
IMS media plane security features: General: The
support for IMS media plane security mechanisms
and procedures in IMS core network

5.2
IMS media plane security features: Media Integrity
protection: The support for IMS media integrity
protection in an IMS UE supporting IMS media
plane security

5.2
IMS media plane security features: Media Integrity
protection: The support for IMS media integrity
protection in IMS core network elements (i.e., IMS
Access Gateway) supporting SDES based e2ae IMS
media plane security

5.2
IMS media plane security features: Media Integrity
protection: The use of IMS media integrity
protection, except that RTCP shall be integrity
protected using SRTCP, in accordance with RFC
3711
GISFI


Release 1
38
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
5.3
IMS media plane security features: Media
Confidentiality protection: The support for IMS
media confidentiality protection in an IMS UE
supporting IMS media plane security


5.3
IMS media plane security features: Media
Confidentiality protection: The support for IMS
media confidentiality protection in IMS core
network elements (i.e., IMS Access Gateway)
supporting SDES based e2ae IMS media plane
security


6.2.1.3
Security mechanisms: Key management
mechanisms for media protection: Key
management mechanisms for e2ae protection:
Functional extension of the Iq interface for e2ae
protection: Support of Cryptographic protection by
NDS/IP if the P-CSCF (IMS-ALG) and IMS
Access GW are located in the same security domain


6.2.1.3
Security mechanisms: Key management
mechanisms for media protection: Key
management mechanisms for e2ae protection:
Functional extension of the Iq interface for e2ae
protection: Implementation of Zb interface
according to TS 33.210


6.2.1.3
Security mechanisms: Key management
mechanisms for media protection: Key
management mechanisms for e2ae protection:
Functional extension of the Iq interface for e2ae
protection: Encryption support over Za (and
optional Zb) interface according to TS 33.210


6.2.2
Security mechanisms: Key management
mechanisms for media protection: Key
management mechanisms for e2e protection using
SDES: Use of TLS, in TS 33.203


Annex B: B.2:
B.2.3.1
KMS based key management: UE terminating
procedures: Procedures for the case with two KMS
domains: Preconditions: Confidentiality protection
(over Za) because keys are transported in the clear
over Zk


Annex C
SRTP profiling for IMS media plane security:
Support for all mandatory features, by an IMS UE
and IMS core network entity capable of supporting
IMS media plane security (SDES and/or KMS
based), defined in RFC 3711 except that it does not
have to support key derivation rates different from
zero (KDR <> 0)


Annex D:
D.3: D.3.1
MIKEY-TICKET profile for IMS media plane
security: Exchanges: Ticket Request: IDRkms: URI
for target KMS


Annex D:
D.3: D.3.1
MIKEY-TICKET profile for IMS media plane
security: Exchanges: Ticket Request: IDRkms: URI
for responding KMS


Annex D:
D.3: D.3.3
MIKEY-TICKET profile for IMS media plane
security: Exchanges: Ticket Resolve: IDRkms: URI


GISFI
Release 1
39
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
(for populating payloads in RESOLVE_INIT_PSK
as defined in TS 33 328)
Annex D:
D.3: D.3.3
MIKEY-TICKET profile for IMS media plane
security: Exchanges: Ticket Resolve: IDRkms: URI
(for populating payloads in RESOLVE_RESP_PSK
as defined in TS 33 328)

Annex E
Profiling of SDES: CRYPTOGRAPHIC
ALGORITHMS: cryptosuite: support and use

Annex E
Profiling of SDES: CRYPTOGRAPHIC
ALGORITHMS: cryptosuite: Additionally, support
of the cryptosuite
“AES_CM_128_HMAC_SHA1_80”, as defined in
RFC 4568

Annex E
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):









key: support and use
Annex E
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
salt: support and use
Annex E
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
Key lifetime: support and use for e2e security
Annex E
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
Master Key Index (MKI): Support
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
Annex E
Master Key Index (MKI): Use (if more than one set
of key parameters is contained in the crypto
attribute)
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
Annex E







Master Key Index (MKI): Use (if only one master
key parameter is contained in the crypto attribute)
Annex E
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
Length of MKI field: Support
Annex E
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
Length of MKI field: Support, if MKI is supported
Annex E
Profiling of SDES: "KEY PARAMETERS" (ONE
OR MORE TIMES):
Length of MKI field: Use, if MKI is used
GISFI

Release 1
40
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Annex E
Profiling of SDES: “SESSION PARAMETERS”
key derivation rate: support and use
Annex E
Profiling of SDES: UNENCRYPTED_SRTP:
Support
Annex E
Profiling of SDES: UNENCRYPTED_SRTP: Use
Annex E
Profiling of SDES: UNENCRYPTED_SRTCP:
Support
Annex E
Profiling of SDES: UNENCRYPTED_SRTCP: Use
Annex E
Profiling of SDES: UNAUTHENTICATED_SRTP:
Support
Annex E
Profiling of SDES: UNAUTHENTICATED_SRTP:
Use

Annex E
Profiling of SDES: UNAUTHENTICATED_SRTP:
key parameters for the FEC stream: Support and
Use

Annex E
Profiling of SDES: UNAUTHENTICATED_SRTP:
window size hint: Support and Use

Annex F
Change History: RFC 4771 for KMS based media
plane security












Annex E (normative): Profiling of SDES [55]:
This Annex contains a complete list of parameters that may be contained in an SDES crypto attribute, according to RFC
4568.
The following short-hand notation is used: “mandatory / optional to support / use” means: “This parameter shall / may
be supported / used in implementations conforming to 3GPP specifications.”
The default use is that the sender omits the parameters that are optional to use.
6.8
From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11)
[56]:
Title: 3G security; Wireless Local Area Network (WLAN) interworking security [56]
Document
Section/ Subsection No.
Security Mechanism
4.1.5
Security Requirements for 3GPP-WLAN
Interworking: Reference points description:
Implementation of reference point D’/Gr’ located
between 3GPP AAA Server and pre-R6 HLR/HSS
4.2.5
Security Requirements for 3GPP-WLAN
Interworking: Security Requirements: Link layer
security requirements: Provision by most WLAN
GISFI
Mandatory
Optional


Release 1
41
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
technologies of link-layer protection of user data
5.1.3
Security features: Authentication of the subscriber
and the network and Security Association
Management: Transport of WLAN Access
authentication signalling between the WLAN
access network and the 3GPP AAA proxy server:
The support of IPsec for Diameter as stated in
(IETF RFC 3588, September 2003: "Diameter base
protocol")

5.1.6
Security features: Authentication of the subscriber
and the network and Security Association
Management: User Identity Privacy in WLAN
Access: Support of the User Identity Privacy
(Anonymity) feature for implementation in the
network

5.1.6
Security features: Authentication of the subscriber
and the network and Security Association
Management: User Identity Privacy in WLAN
Access: Support of the User Identity Privacy
(Anonymity) feature for implementation in the
WLAN UE

5.1.6
Security features: Authentication of the subscriber
and the network and Security Association
Management: User Identity Privacy in WLAN
Access: Use of the User Identity Privacy
(Anonymity) feature in the network
5.1.6
Security features: Authentication of the subscriber
and the network and Security Association
Management: User Identity Privacy in WLAN
Access: Use of the User Identity Privacy
(Anonymity) feature in the WLAN UE
5.1.7
Security features: Authentication of the subscriber
and the network and Security Association
Management: Re-authentication in WLAN Access:
The use of EAP/SIM/AKA for fast reauthentication in the network, depending on
operator's policies


6.1.3.1
Security mechanisms: Authentication and key
agreement: EAP support in Smart Cards: EAPAKA procedure: Implementation to have the
termination of EAP in the UICC


6.1.3.2
Security mechanisms: Authentication and key
agreement: EAP support in Smart Cards: EAP-SIM
procedure: Implementation to have the termination
of EAP in the UICC


6.1.4.1
Security mechanisms: Authentication and key
agreement: Fast re-authentication mechanisms in
WLAN Access: EAP/AKA procedure: The
implementation of EAP/AKA including the fast reauthentication mechanism described in sub-clause
6.1.4.1. of TS 33 234


6.1.4.1
Security mechanisms: Authentication and key
agreement: Fast re-authentication mechanisms in


GISFI


Release 1
42
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
WLAN Access: EAP/AKA procedure: The use of
EAP/AKA including the fast re-authentication
mechanism described in sub-clause 6.1.4.1. of TS
33 234, depending on operator’s policies
6.1.4.2
Security mechanisms: Authentication and key
agreement: Fast re-authentication mechanisms in
WLAN Access: EAP/SIM procedure: The
implementation of EAP/SIM including the fast reauthentication mechanism described in sub-clause
6.1.4.2. of TS 33 234


6.1.4.2
Security mechanisms: Authentication and key
agreement: Fast re-authentication mechanisms in
WLAN Access: EAP/SIM procedure: The use of
EAP/SIM including the fast re-authentication
mechanism described in sub-clause 6.1.4.2. of TS
33 234, depending on operator’s policies


6.6A
Security mechanisms: Profile for PDG certificates:
Certificate processing requirements: Support for
CRLs in the UE


6.6A
Security mechanisms: Profile for PDG certificates:
Certificate processing requirements: Support for
OCSP in the UE
Annex A:
A.2.1.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: HIPERLAN/2 Security
architecture: Confidentiality protection: Defined
algorithm for confidentiality protection: Triple-DES


Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Use of the Unicast encryption


Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Implementation of DES algorithm
(defined for confidentiality protection) for AP/CC
and MT
Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Implementation of Triple-DES
(EDE mode) algorithm (defined for confidentiality
protection) for AP/CC and MT
Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: DES: Implementation of DES
Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Triple-DES: Implementation of
Triple-DES


Annex A:
A.2.2.2
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Authentication: Implementation of Authentication
with a pre-shared key


Annex A:
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:


GISFI








Release 1
43
A.2.2.2
Annex A:
A.2.2.2
6.9
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Authentication: Implementation of Authentication
with RSA based signatures
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Authentication: Implementation of one out of six
different key identifiers


From 3GPP TS 33.105, V10.0.0, (2011-03) (Release 10)
[57]:
Title: 3G Security; Cryptographic Algorithm Requirements [57]
Document
Section/ Subsection No.
6.10
Security Mechanism
Mandatory
Optional
5.1.1.1
Functional algorithm requirements: Authentication
and key agreement: Overview: Generation of
quintets in the AuC: Concealment of the sequence
number (SQN xor AK), generated by the HLR/AuC
along-with the anonymity key (AK)

5.1.6.7
Functional algorithm requirements: Authentication
and key agreement: Type of algorithm: f5: The use
of f5

5.1.6.8
Functional algorithm requirements: Authentication
and key agreement: Type of algorithm: f5*: The use
of f5*

From 3GPP TS 33.110, V10.1.0, (2011-06) (Release 10)
[58]:
Title: Key establishment between a Universal Integrated Circuit Card (UICC) and a terminal [58]
Document
Section/ Subsection No.
Security Mechanism
Annex F:
F.1.1
TLS profiles: TLS profile for certificate based
mutual authentication between Terminal and NAF
Key Center: Introduction: Implementation of all
other TLS extensions (except the server_name TLS
extension) as specified in RFC 3546
Annex F:
F.1.2
TLS profiles: TLS profile for certificate based
mutual authentication between Terminal and NAF
Key Center: Protection mechanisms: Terminal
implementation of all other Cipher Suites (except
CipherSuite TLS_RSA_
GISFI
Mandatory
Optional


Release 1
44
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
WITH_3DES_EDE_CBC_SHA and the
CipherSuite
TLS_RSA_WITH_AES_128_CBC_SHA) as
defined in RFC 2246 and RFC 3268
6.11
Annex F:
F.1.2
TLS profiles: TLS profile for certificate based
mutual authentication between Terminal and NAF
Key Center: Protection mechanisms: NAF Key
center implementation of all other Cipher Suites
(except CipherSuite TLS_RSA_
WITH_3DES_EDE_CBC_SHA and the
CipherSuite
TLS_RSA_WITH_AES_128_CBC_SHA) as
defined in RFC 2246 and RFC 3268

Annex F:
F.2.1
TLS profiles: TLS profile for Shared key-based
mutual authentication between Terminal and NAF
Key Center: Introduction: Implementation of all
other TLS extensions (except the server_name TLS
extension) as specified in RFC 3546

Annex F:
F.2.1
TLS profiles: TLS profile for Shared key-based
mutual authentication between Terminal and NAF
Key Center: Protection mechanisms: Terminal
implementation of all other Cipher Suites (except
CipherSuite
TLS_PSK_WITH_3DES_EDE_CBC_SHA and the
CipherSuite
TLS_PSK_WITH_AES_128_CBC_SHA) as
defined in PSK TLS

Annex F:
F.2.1
TLS profiles: TLS profile for Shared key-based
mutual authentication between Terminal and NAF
Key Center: Protection mechanisms: NAF Key
Centre implementation of all other Cipher Suites
(except CipherSuite
TLS_PSK_WITH_3DES_EDE_CBC_SHA and the
CipherSuite
TLS_PSK_WITH_AES_128_CBC_SHA) as
defined in PSK TLS

From 3GPP TS 33.141, V12.0.0, (2012-06) (Release 12)
[59]:
Title: Presence service; Security [59]
Document
Section/ Subsection No.
4.1
Security Mechanism
Security Architecture: Overview of the security
architecture: Depending on the implementation, the
Presence Server may authenticate an anonymous
watcher depending on the Subscription
Authorization Policy
GISFI
Mandatory
Optional

Release 1
45
Annex D
6.12
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
GPRS-IMS-Bundled Authentication for Ut
interface security: Support of TLS in the UE and in
the AS/AP in the present TS document

From 3GPP TS 33.203, V12.0.0, (2012-06) (Release 12)
[60]:
Title: 3G Security; Access security for IP-based services [60]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
5.1.4
Security features: Secure access to IMS: Integrity
protection: Note 1: Support of TLS by SIP proxies
according to RFC 3261
5.1.4
Security features: Secure access to IMS: Integrity
protection: Note 1: The intra-domain Zb interface


6.4
Security mechanisms: Hiding mechanisms:
Implementation of the Hiding Mechanism


7.1
Security association set-up procedure: Security
association parameters: Note 6: An already existing
TCP connection may be reused by both the P-CSCF
or the UE

7.1
Security association set-up procedure: Security
association parameters: Note 9: An already existing
TCP connection may be reused by both the P-CSCF
or the UE



The use of "Security Mechanism Agreement for
SIP Sessions" for security mode set-up: The
Algorithm parameter (Defines the authentication
algorithm)

Annex L: L.2
Application to fixed broadband access: Application
of clause 4: In 3GPP IMS, the ISIM to be present
on UICC which is usually inserted within the MT
component of the UE

Annex M:
M.7.1
Enhancements to the access security for IP based
services to enable NAT traversal for signaling
messages: Security association set-up procedure:
Security association parameters: Note: An already
existing TCP connection may be reused by both the
P-CSCF or the UE

Annex N: N.1
Enhancements to the access security to enable SIP
Digest: SIP Digest: Implementation of the
provisions in Annex N

Annex N: N.1
Enhancements to the access security to enable SIP
Digest: SIP Digest: Use of the provisions in Annex
N

Annex H
GISFI
Release 1
46
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Annex N: N.1
Enhancements to the access security to enable SIP
Digest: SIP Digest: The use of one of the
authentication mechanisms in the present TS
document
Annex N:
N.2.1.1
Enhancements to the access security to enable SIP
Digest: Authentication: Authentication
Requirements: Authentication Requirements for
Registrations: If “IMPI*” in SIP Message-1 (SM1),
the inclusion of the IP Multimedia Private Identity
(IMPI) in SM1
Annex N:
N.2.1.1
Enhancements to the access security to enable SIP
Digest: Authentication: Authentication
Requirements: Authentication Requirements for
Registrations: The inclusion of the IMPI and an
Authorization header in SM7
Annex O:
O.1.1
Enhancements to the access security to enable TLS:
TLS: TLS Access Security: Implementation of the
provisions in Annex O

Annex O:
O.1.1
Enhancements to the access security to enable TLS:
TLS: TLS Access Security: Use of the provisions in
Annex O

Annex O:
O.5.1
Enhancements to the access security to enable TLS:
TLS Certificate Profile and Validation: TLS
Certificate: CRL distribution point in the
certificates

Annex O:
O.5.3
Enhancements to the access security to enable TLS:
TLS Certificate Profile and Validation: Certificate
Revocation: Implementation of CRL infrastructure

Annex P: P.3
Co-existence of authentication schemes IMS AKA,
GPRS-IMS-Bundled Authentication, NASS-IMSbundled authentication, SIP Digest and Trusted
Node Authentication: P CSCF procedure selection:
For NASS-IMS-bundled authentication (NBA), the
inclusion of an Authorization header in a
REGISTER request

Annex P: P.3
Co-existence of authentication schemes IMS AKA,
GPRS-IMS-Bundled Authentication, NASS-IMSbundled authentication, SIP Digest and Trusted
Node Authentication: P CSCF procedure selection:
For Session Initiation Protocol (SIP) Digest, the
inclusion of an Authorization header in a
REGISTER request

Annex P: P.3
Co-existence of authentication schemes IMS AKA,
GPRS-IMS-Bundled Authentication, NASS-IMSbundled authentication, SIP Digest and Trusted
Node Authentication: P CSCF procedure selection:
The P CSCF to insert a P-Access-Network-Info
header containing the "network-provided"
parameter, under the additional conditions that the
REGISTER request contains no Authorization
header and was received over an access network
other than TISPAN NASS or 3GPP
Annex P: P.3
Co-existence of authentication schemes IMS AKA,
GISFI






Release 1
47
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
GPRS-IMS-Bundled Authentication, NASS-IMSbundled authentication, SIP Digest and Trusted
Node Authentication: P-CSCF procedure selection:
The removal of a P-Access-Network-Info header
with the "network-provided" parameter for PANIaware P-CSCFs even when the access network is
not a TISPAN NASS
Annex P: P.6
Co-existence of authentication schemes IMS AKA,
GPRS-IMS-Bundled Authentication, NASS-IMSbundled authentication, SIP Digest and Trusted
Node Authentication: Considerations on the Cx
interface: For NASS-IMS-bundled authentication
(NBA) the inclusion of an Authorization header in a
registration request


Annex Q: Q.1
Usage of the authentication mechanisms for nonregistration messages in Annexes N and O:
General: TLS, according to Annex O


Annex Q: Q.1
Usage of the authentication mechanisms for nonregistration messages in Annexes N and O:
General: The IP address check, according to Annex
N
Annex Q: Q.1
Usage of the authentication mechanisms for nonregistration messages in Annexes N and O:
General: The SIP Digest proxy-authentication,
according to Annex N


Annex S: S.2
Application to 3GPP2 Access: Application of
clause 4: For the purposes of this Annex, the
presence of the UICC in the UE


Annex S:
S.5.4.2.1
Application to 3GPP2 Access: Network Domain
Security for IMS: Profiles of Network Domain
Security Methods: Support of IPsec ESP: General:
The Confidentiality security service provided by
network domain security


Annex S:
S.5.4.2.2
Application to 3GPP2 Access: Network Domain
Security for IMS: Profiles of Network Domain
Security Methods: Support of IPsec ESP: Support
of ESP authentication and encryption: Support of
the ESP_3DES algorithm as default

Annex S:
S.5.4.2.2
Application to 3GPP2 Access: Network Domain
Security for IMS: Profiles of Network Domain
Security Methods: Support of IPsec ESP: Support
of ESP authentication and encryption: Support for
the AES CBC cipher algorithm (RFC 3602)

Annex T: T.4
GPRS-IMS-Bundled Authentication (GIBA) for
Gm interface: GIBA Security Mechanism: When
using IPv6, stateless autoconfiguration is the only
IP address allocation method supported by the
terminal in GPRS

GISFI

Release 1
6.13
48
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
From 3GPP TS, 33.220, V11.3.0, (2012-06) (Release 11)
[61]:
Title: Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) [61]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
Generic Bootstrapping Architecture: Reference
Model: Support of the reference point Zh’ for/by
the BSF


4.2.3
Generic Bootstrapping Architecture: Network
elements: HSS: Note 2: GBA User Security
Settings (GUSS) shall be able to contain the
timestamp indicating the time when the GUSS has
been last modified by the HSS


4.2.3
Generic Bootstrapping Architecture: Network
elements: HSS: Note 3: These parameters
(mentioned in sub-section 4.2.3). And if these
parameters are missing from subscriber's GUSS or
subscriber does not have GUSS then the BSF will
use the default values in the BSF local policy
defined by the particular MNO


4.4.4
Generic Bootstrapping Architecture: Requirements
and principles for bootstrapping: Requirements on
reference point Ub: Note 3: Protection of IMPI by
TLS tunnel
4.4.5
Generic Bootstrapping Architecture: Requirements
and principles for bootstrapping: Requirements on
reference point Zh: Note 1: The BSF may have the
capability able to send the timestamp of subscriber's
GBA user security settings to the HSS (timestamp
option)


4.4.5
Generic Bootstrapping Architecture: Requirements
and principles for bootstrapping: Requirements on
reference point Zh: Note 1: The HSS may have the
capability to indicate to the BSF whether the BSF
already has the latest copy of the GUSS based on
the GUSS timestamp (timestamp option)


4.4.12
Generic Bootstrapping Architecture: Requirements
and principles for bootstrapping: Requirements on
reference point Zh’: Support of the reference point
Zh’ for/by the BSF


4.5.2
Generic Bootstrapping Architecture: Procedures:
Bootstrapping procedures: Note 4: Ua uses a
protocol which transfers the host name (FQDN of
NAF as used by UE) to NAF (e.g. HTTP/1.1 with
Host request header field)


Annex I: I.0
2G GBA: Introduction: This annex specifies the
implementation to allow the use of SIM cards or


4.1
GISFI


Release 1
49
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
SIMs on UICC for GBA.
Annex I: I.2.3
2G GBA: Network Elements: HSS: Note 2:
Requirements on HSS are: GUSS shall be able to
contain the timestamp indicating the time when the
GUSS has been last modified by the HSS


Annex I: I.2.3
2G GBA: Network Elements: HSS: Note 3: These
parameters (mentioned in sub-Annex I.2.3). And if
these parameters are missing from subscriber's
GUSS or subscriber does not have GUSS then the
BSF will use the default values in the BSF local
policy defined by the particular MNO


Annex I: I.4.5
2G GBA: Requirements and principles for
bootstrapping: Requirements on reference point Zh:
Note 1: The BSF may have the capability able to
send the timestamp of subscriber's GBA user
security settings to the HSS (timestamp option)


Annex I: I.4.5
2G GBA: Requirements and principles for
bootstrapping: Requirements on reference point Zh:
Note 1: The HSS may have the capability to
indicate to the BSF whether the BSF already has
the latest copy of the GUSS based on the GUSS
timestamp (timestamp option)


Annex I: I.5.2
2G GBA: Procedures: Bootstrapping procedures:
Note 4: Ua uses a protocol which transfers the host
name (FQDN of NAF as used by UE) to NAF (e.g.
HTTP/1.1 with Host request header field)


Annex I: I.6
2G GBA: TLS Profile: Support of certificate
revocation and of the related fields in certificates


Annex J: J.1
Usage of USS with local policy enforcement in
BSF: General: 1) Access control within NAF for Ua
requests: Upon receiving the B-TID from the UE,
the NAF fetches the USSs, which typically contain
NAF specific persistent user identities, and
authorization flags


Annex M:
M.3.4
GBA_Digest: Network Elements: HSS: Note 2:
GUSS shall be able to contain the timestamp
indicating the time when the GUSS has been last
modified by the HSS


Annex M:
M.3.4
GBA_Digest: Network Elements: HSS: Note 3:
These parameters (mentioned in Annex M.3.4).
And if these parameters are missing from
subscriber's GUSS or subscriber does not have
GUSS then the BSF will use the default values in
the BSF local policy defined by the particular MNO


Annex M:
M.5.6
GBA_Digest: Requirements and principles for
bootstrapping: Requirements on reference point Zh:
Note 1: The BSF may have the capability able to
send the timestamp of subscriber's GBA user
security settings to the HSS (timestamp option)


Annex M:
M.5.6
GBA_Digest: Requirements and principles for
bootstrapping: Requirements on reference point Zh:
Note 1: The HSS may have the capability to


GISFI
Release 1
50
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
indicate to the BSF whether the BSF already has
the latest copy of the GUSS based on the GUSS
timestamp (timestamp option)
6.14
Annex M:
M.6.3
GBA_Digest: Procedures: Bootstrapping
procedures: Step 0: The use of TLS message
integrity
Annex M:
M.6.3
GBA_Digest: Procedures: Bootstrapping
procedures: Step 0: The use of TLS encryption

Annex M:
M.7.1
TLS Profile: General: Support of certificate
revocation and of the related fields in certificates


From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11)
[62]:
Title: 3G Security; Wireless Local Area Network (WLAN) interworking security [62]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
4.2.5
Security Requirements for 3GPP-WLAN
Interworking: Security Requirements: Link layer
security requirements: WLAN technologies provide
link-layer protection of user data


5.1.3
Security Features: Authentication of the subscriber
and the network and Security Association
Management: Transport of WLAN Access
authentication signalling between the WLAN
access network and the 3GPP AAA proxy server:
The support of IPsec for Diameter, as stated in
IETF RFC 3588(‘Diameter base protocol’,
September 2003)


5.1.6
Security Features: Authentication of the subscriber
and the network and Security Association
Management: User Identity Privacy in WLAN
Access: Implementation support of the User
Identity Privacy feature in the network


5.1.6
Security Features: Authentication of the subscriber
and the network and Security Association
Management: User Identity Privacy in WLAN
Access: Implementation support of the User
Identity Privacy feature in the WLAN UE


5.1.6
Security Features: Authentication of the subscriber
and the network and Security Association
Management: User Identity Privacy in WLAN
Access: Use of the User Identity Privacy feature in
the network


5.1.6
Security Features: Authentication of the subscriber
and the network and Security Association


GISFI
Release 1
51
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Management: User Identity Privacy in WLAN
Access: Use of the User Identity Privacy feature in
the WLAN UE
Security Features: Authentication of the subscriber
and the network and Security Association
Management: Re-authentication in WLAN Access:
Use of EAP/SIM/AKA for fast re-authentication in
the network, depending on operator's policies


6.1.4.1
Security mechanisms: Authentication and key
agreement: Fast re-authentication mechanisms in
WLAN Access: EAP/AKA procedure: Use of the
EAP/AKA, depending on operator’s policies


6.1.4.2
Security mechanisms: Authentication and key
agreement: Fast re-authentication mechanisms in
WLAN Access: EAP/SIM procedure: Use of the
EAP/SIM, depending on operator’s policies


6.6A
Security Mechanisms: Profile for PDG certificates:
Certificate Processing Requirements: k) Support for
CRLs in the UE


6.6A
Security Mechanisms: Profile for PDG certificates:
Certificate Processing Requirements: k) Support for
OCSP in the UE


Annex A:
A.2.1.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: HIPERLAN/2 Security
architecture: Confidentiality protection: Triple-DES


Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Use of the Unicast encryption


Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Implementation of DES algorithm
for confidentiality protection in AP/ CC


Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Implementation of DES algorithm
for confidentiality protection in MT


Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Implementation of Triple-DES
(EDE mode) algorithm for confidentiality
protection in AP/ CC


Annex A:
A.2.2.1
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Confidentiality: Implementation of Triple-DES
(EDE mode) algorithm for confidentiality
protection in MT


Annex A:
A.2.2.2
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Authentication: Implementation of Authentication
with a pre-shared key


5.1.7
GISFI
Release 1
6.15
52
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Annex A:
A.2.2.2
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Authentication: Implementation of Authentication
with RSA based signatures


Annex A:
A.2.2.2
Review of the security of existing WLAN-related
technologies: ETSI/BRAN: Security mechanisms:
Authentication: Implementation of one out of six
available, different key identifiers


From 3GPP TS 33.246, V10.0.0, 2010-12 (Release 10)
[63]:
Title: 3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS) [63]
Document
Section/ Subsection No.
Security Mechanism
Mandatory
Optional
4.2
MBMS security overview: Key management
overview: Support for master key lengths of 128,
192 and 256 bits for SRTP, according to RFC 3711
(Secure Real-time Transport Protocol) it is
mandatory


6.3.2.1A
Security mechanisms: Key management
procedures: MSK procedures: MBMS User Service
Registration procedure: Implementation of the Back
off mode in the BM-SC


6.3.2.1A
Security mechanisms: Key management
procedures: MSK procedures: MBMS User Service
Registration procedure: Implementation of the Back
off mode in the UE


6.4.5.1
Security mechanisms: MIKEY message creation
and processing in the ME: MIKEY message
structure: MSK message structure: Inclusion of the
SP payload into MSK delivery messages by the
BM-SC, when the MSK delivery was not triggered
by the UE using the MSK request procedure or the
MBMS User Service Registration procedure


6.6.2.1A
Security mechanisms: Protection of the transmitted
traffic: Protection of streaming data: Usage of
SRTCP: Encryption of SRTCP packets


Annex B: B.1
Security threats: Threats associated with attacks on
the radio interface: Encryption of the MBMS
service announcement at RAN level, in case it is
transferred over HTTP


Annex C: C.5
MBMS security requirements: Requirements on
integrity protection of MBMS User Service data:
R6a: Use of integrity


Annex L
Multicasting MBMS user data on Iub: The use of


GISFI
Release 1
53
confidentiality protection
7
Void
8
Void
9
Conclusions
To be prepared
GISFI
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Release 1
54
GISFI TR SP.1xxx V1.0.0 (20xx-xx)
Annex A: Change history
Change history
Date
TSG #
TSG Doc.
CR
Rev
Subject/Comment
201209- 13
Initial Release
201211-13
Added contents to Section 4 – 6 from GISFI Input
documents GISFI_SP_201206261, GISFI_SP_201209282
and GISFI_SP_201209286
GISFI
Old
New