ETSI TS 187 001 V3.7.1 (2011-03)

Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN SECurity (SEC); Requirements

RTS/TISPAN-07036-NGN-R3

General Information

• Status: Published
• Publication Date: 20-Mar-2011
• Technical Committee: TISPAN 7 - TISPAN Security
• Current Stage: 12 - Completion
• Due Date: 23-Mar-2011
• Completion Date: 21-Mar-2011

Standards Content (Sample)

Technical Specification
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
NGN SECurity (SEC);
Requirements
2 ETSI TS 187 001 V3.7.1 (2011-03)

Reference
RTS/TISPAN-07036-NGN-R3
Keywords
security, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone] Fax: [phone]

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

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

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 187 001 V3.7.1 (2011-03)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4a Security Objectives. 9
4 Security Requirements . 12
4.1 Security Policy Requirements . 12
4.2 Authentication, Authorization, Access Control and Accountability Requirements . 12
4.3 Identity and Secure Registration Requirements . 15
4.4 Communications and Data Security Requirements . 15
4.4.1 General Communications and Data Security Requirements . 15
4.4.2 Integrity and Replay Protection Requirements . 16
4.4.3 Confidentiality Requirements . 16
4.5 Privacy Requirements . 17
4.6 Key Management Requirements . 18
4.7 Secure Management Requirements . 18
4.8 NAT/Firewall Interworking Requirements . 18
4.9 Non-Repudiation Requirements . 18
4.10 Availability and DoS protection Requirements . 18
4.11 Assurance Requirements . 19
4.12 Requirements on Strength of Security Mechanisms . 19
4.13 IPTV Security Requirements . 19
4.13.1 Common IPTV Security Requirements . 19
4.13.2 IPTV Service Protection Requirements . 20
4.13.3 IPTV Content Protection Requirements . 20
4.13.4 IMS-based IPTV Security Requirements . 20
4.13.5 Non-IMS-based IPTV Security Requirements. 21
4.13.6 Availability and DoS Protection Requirements . 21
4.14 DRM . 21
4.15 Media Security Requirements . 22
4.15.1 Common Media Security Requirements . 22
4.15.1.1 Regulatory Requirements . 22
4.15.1.2 Non-broadcast media paths . 22
4.15.1.3 NGN Requirements . 22
4.15.1.4 NGCN Requirements . 23
4.15.2 IMS-based Media Security Requirements . 23
4.15.3 Non-IMS-based Media Security Requirements . 23
4.16 Security Requirements to Counter Unsolicited Communications . 23
4.17 Business communication security requirements . 23
4.17.1 General security requirements . 23
4.17.2 Specific security requirements for NGN/NGCN interconnection . 24
4.17.3 Specific security requirements for hosted enterprise services . 24
4.17.4 Specific security requirements for business trunking application . 24
4.17.4.1 Security requirements for (subscription-based) business trunking application . 24
4.17.4.2 Security requirements for (peering-based) business trunking application. 24
4.17.5 Specific security requirements for virtual leased line . 24
4.18 NAT Traversal Security Requirements . 24
ETSI
4 ETSI TS 187 001 V3.7.1 (2011-03)
4.19 Home Networking Security Requirements . 25
4.19.1 Confidentiality requirements . 25
4.19.2 Identification, authentication and authorization requirements . 25
4.19.3 Integrity requirements . 26
4.19.4 Availability and DoS protection requirements . 26
4.19.5 Service protection and/or content protection software upgrade security requirements. 26
4.20 H.248 Security Requirements . 27
5 NGN Security Release 2 Requirements Mapping . 27
5.1 Network Access SubSystem (NASS) . 28
5.2 Resource and Admission Control Subsystem (RACS) . 29
5.3 The Core IP Multimedia Subsystem (IMS) . 30
5.4 The PSTN/ISDN Emulation subsystem (PES) . 33
5.5 Application Server (AS) . 33
Annex A (informative): Bibliography . 35
Annex B: Void . 36
Annex C (informative): Trust domains in NGN . 37
C.1 Definition of trust for the NGN - analysis . 37
C.2 Requirements for creation of trusted channel . 38
C.2.1 Functional security requirements for trusted channel in the NGN . 38
C.3 Existing NGN capabilities . . 38
Annex D (informative): Security Objective Categories . 39
D.1 Security Objective Categories Definitions . 39
Annex E (informative): Security Objectives . 40
E.1 General objectives . 40
E.2 Security objective category confidentiality . 40
E.3 Security objective category integrity . 41
E.4 Security objective category availability . 41
E.5 Security objective category authenticity . 41
Annex F (informative): Change history . 42
History . 43

ETSI
5 ETSI TS 187 001 V3.7.1 (2011-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
Introduction
The TISPAN NGN R3 security is defined by the security requirements in the present document, while the architectural
aspects and stage 2 implementations outline are covered in the Security Architecture for R3 (TS 187 003 [1]).
ETSI
6 ETSI TS 187 001 V3.7.1 (2011-03)
1 Scope
The present document defines the security requirements pertaining to TISPAN NGN Release 3. The present document
holds requirements for the various NGN subsystems defined at a stage 1 level. The present document covers security
requirements for both the NGN core network, and the NGN access network(s).
The main scope of the security requirements for the different subsystems are to identify requirement in the following
main areas:
• Security Policies.
• Authentication, Authorization, Access Control and Accountability.
• Identity and Secure Registration.
• Communications and Data Security Requirements (including confidentiality, integrity aspects).
• Privacy.
• Key Management.
• NAT/Firewall Interworking.
• Availability and DoS protection.
• Assurance.
• Strength of Security Mechanisms.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Security; Security Architecture".
[2] ETSI TS 133 203: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; 3G security; Access security for IP-based services
(3GPP TS 33.203)".
[3] ETSI TS 133 210: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; 3G security; Network Domain Security (NDS); IP
network layer security (3GPP TS 33.210)".
ETSI
7 ETSI TS 187 001 V3.7.1 (2011-03)
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ISO 15408-1: "Information technology - Security techniques - Evaluation criteria for IT security -
Part 1: Introduction and general model".
[i.2] IEEE 802.1X: "Port Based Network Access Control".
[i.3] ISO 15408-2: "Information technology - Security techniques - Evaluation criteria for IT security -
Part 2: Security functional components".
[i.4] IETF RFC 3324: "Short Term Requirements for Network Asserted Identity".
[i.5] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks".
[i.6] ISO 27000: "Information technology - Security techniques - Information security management
systems - Overview and vocabulary".
[i.7] ETSI TR 187 011: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Security; Application of ISO-15408-2 requirements to
ETSI standards - guide, method and application with examples".
[i.8] ETSI TR 187 010: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Security; Report on issues related to security in identity
imanagement and their resolution in the NGN".
[i.9] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229)".
[i.10] ISO/IEC TR 13335:2004: "Information technology - Guidelines for management of IT Security".
[i.11] ETSI TR 187 002: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); TISPAN NGN Security (NGN-SEC); Threat, Vulnerability and
Risk Analysis".
[i.12] ETSI EG 202 238: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Evaluation criteria for cryptographic algorithms".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
anonymous communication: anonymous communication session is given when a user receiving a communication
session cannot identify the originating user
trusted channel: means by which an NGN and a remote NGN/NGCN can communicate with necessary confidence to
support the security policies of the NGN (from ISO 15408-1 [i.1])
trusted domain: in the context of one or more NGNs interconnected by the NNI as defined in TS 124 229 [i.9],
clause 4.4 then trust is achieved by implementing one or more of the security mechanisms defined in TS 187 003 [1]
trusted path: means by which a user and a NGN/NGCN can communicate with necessary confidence to support the
security policies of the NGN/NGCN (from ISO 15408-1 [i.1])
ETSI
8 ETSI TS 187 001 V3.7.1 (2011-03)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3G 3 Generation
rd
3GPP 3 Generation Partnership Project
AA Authentication & Authorization
ACR Anonymous Communications Rejection
ADSL Asymetrical Digital Subscriber Line
AF Application Function
ALG Application Layer Gateway
AP Authentication Proxy
AS Application Server
CND Customer Network Gateway
CNG Customer Network Gateway
CP Content Protection
CPE Customer Premises Equipment
CPF Content Protection Function
CPN Customer Premise Network
CPN Customer Premises Network
CSCF Call Session Control Function
CSP Content Service Provider
DoS Denial-of-Service
DRM Digital Right Management
EMTEL EMergency TELecommunications
HSS Home Subscriber Server
HW HardWare
ID Identity
IKE Internet Key Exchange
IMPU IMS Public user ID
IMS IP Multimedia Subsystem
IP Internet Protocol
IPTV Internet Protocol TeleVision
ISDN Integrated Services Digital Network
ISIM IMS Subscriber Identity Module
IT Information Technology
MAC Message Authentication Code
MD Message Digest
NAF operator controlled Network Application Function
NASS Network Access SubSystem
NAT Network Address Translation
NATP Network Address and Port Translation
NDS Network Domain Security
NGCN Next Generation Corporate Network
NGN Next Generation Network
NGN Next Generation Network
NNI Network to Network Interface
OIR Originating Identification Restriction
PAI Public Administration International
P-CSCF Proxy - Call Session Control Function
PES PSTN/ISDN Emulation Subsystem
PSAP Public Safety Answering Point
PSTN Public Switched Telephone Network
RACS Resource Admission Control Subsystem
RTP Realtime Transport Protocol
RTSP Real Time Streaming Protocol
S-CSCF Serving - Call Session Control Function
SEGF Security Gateway Functions
SIP Session Initiation Protocol
SP Service Protection
SPF Service Protection Function
ETSI
9 ETSI TS 187 001 V3.7.1 (2011-03)
SW SoftWare
TCP Transmission Control Protocol
TISPAN Telecommunication and Internet converged Services and Protocols for Advanced Networking
TS Technical Specification
TSF Target of Evaluation
TSP TOE (Target of Evaluation) Security Policy
TVRA Threat, Vulnerability and Risk Analysis
UA User Agent
UAS User Agent Server
UC Unsolicited Communications
UE User Equipment
UICC Universal Integrated Circuit Card
UMTS Universal Mobile Telecommunication System
UNI User to Network Interface
VoIP Voice over Internet Protocol
4a Security Objectives
Whilst the primary objective of the NGN is to provide a secure and trusted framework for users a complete list of
objectives is given in table 1a.
The domain to which an objective applies is one of the following:
• System, e.g. Architecture, Policy, NGN, NASS, RACS
• Service, e.g. IPTV, VoIP
• Technology, e.g. NAT Traversal, SIP, DIAMETER.
Table 1a: NGN security objectives (multi-page table)
Objective Objective text Domain Functional
identifier requirement
identifier
OBJ-1 The NGN should be logically and physically divided into security System - R-SP- 1
domains allowing for separation of application, transport and Architecture
content in accordance with the Framework Directive.
OBJ-2 NGN operators should be able to operate their own security System - Policy R-SP- 1
policies.
OBJ-3 Security mechanisms and other parameters beyond default System - R-SP- 2
security mechanisms should be statically configured at the NNI. management and
configuration
OBJ-4 Security mechanisms and other parameters beyond default System - R-SP- 2
security mechanisms should be configurable dynamically at the management and
UNI. configuration
OBJ-5 Users should be able to reject communications that do not conform System - Policy R-SP- 2
to their minimum security policy.
OBJ-6 Security mechanisms should be partitioned such that each of the System - R-SP- 3
functions of authentication, data integrity, replay detection, and Architecture
confidentiality may be implemented and selected independently of
each other.
OBJ-7 NGN operators may deploy alternatives to the IMS authentication Service - R-AA- 2
defined in TS 133 203 [2] in early deployment. Authentication
OBJ-8 In the NGN authentication in one security domain should be Service - R-AA- 3
independent of authentication in any other security domain. Authentication
OBJ-9 NGN operators should be able to prevent the use of a particular Technology - ISIM R-AA- 7
ISIM to access NGN networks and services.
OBJ-10 NGN operators should be able to revoke a specific ISIM. R-AA- 7
OBJ-11 NGN relevant ISIM specific information should be protected Technology - ISIM R-AA- 8
against unauthorized access.
OBJ-12 NGN relevant ISIM specific information should be protected Technology - ISIM R-AA- 8
against unauthorized alteration.
ETSI
10 ETSI TS 187 001 V3.7.1 (2011-03)
Objective Objective text Domain Functional
identifier requirement
identifier
OBJ-13 Where passwords are used for authentication they should be Service - R-AA- 12
protected from exposure during transmission Authentication
OBJ-14 Each NGN security domain should have and enforce a user Service - R-AA- 14
authorization policy. Authentication
OBJ-15 An NGN security domain should be able to act as a proxy for System - R-AA- 16
another peer domain with respect to authentication. Architecture
OBJ-16 An NGN security domain acting as a proxy for another peer System - R-AA- 18
domain should follow its own policy with respect to routing of Architecture
authorisation requests.
OBJ-17 Mutual authentication should be supported between the CPE and Service - R-AA- 20
the NASS during access network level registration. Authentication
OBJ-18 Data held on the ISIM should be updated by authorised parties Technology - ISIM R-CD- 9
only.
OBJ-19 The NGN should provide means to protect sensitive data (such as System R-CD- 10
Presence information and notifications) from attack
(e.g. eavesdropping, tampering, and replay attacks).
OBJ-20 The NGN should provide mechanisms to ensure the origin, Service - R-CD- 14
integrity and freshness of authentication data. Authentication
OBJ-21 Confidentiality of signalling and control messages should be System - Policy R-CD- 19
managed by the security policy of the security domain.
OBJ-22 The security policy should associate each security association with System - Policy R-CD- 19
specific functions (e.g. confidentiality, integrity) and identify the
algorithms to be used.
OBJ-23 The NGN should ensure that user-related data that is stored or R-CD- 22
processed by a provider are visible only to authorised parties.
OBJ-24 Each domain of the NGN should ensure that details of the network R-P- 1
topology of the domain are visible only to authorised parties.
OBJ-25 The NGN should ensure that user location and usage patterns are R-P- 2
visible only to authorised parties.
OBJ-26 The NGN should ensure that user identity data is visible only to R-P- 3
authorised parties.
OBJ-27 The NGN should provide mechanisms to prove the authenticity of R-P- 7
a user identity presented for an incoming call to a user where the
call is wholly within that operator's network (i.e. originating and
terminating parties are subscribers to, and resident in, a single
NGN).
OBJ-28 The NGN should ensure that presence services respect the R-P- 9
privacy policies of the affected parties.
OBJ-29 The NGN should provide a means for an affected user to manage R-P- 9
their privacy policy per call or per session.
OBJ-30 The NGN should ensure that presence services respect the R-P- 10
privacy policies of the affected parties.
OBJ-31 The NGN should ensure that presence services respect the R-P- 11
privacy policies of the affected parties.
OBJ-32 The NGN should provide a means for an affected user to manage R-P- 12
their privacy policy per call or per session.
OBJ-33 Each domain of the NGN should ensure that details of the network R-P- 14
topology of the domain are visible only to authorised parties.
OBJ-34 The NGN should provide means to detect denial-of-service
attacks.
OBJ-35 The NGN should provide means to mitigate denial-of-service R-AD- 3
attacks.
OBJ-36 Availability of EMTEL PSAPs should be maintained when the R-AD- 5
system is subjected to DoS attacks
OBJ-37 The security association between an NGN IPTV service user and R-IPTV-CN-3
the NGN IPTV service provider should define mechanisms to
assure the integrity and confidentiality of communication and the
authenticity of the user and provider
OBJ-38 The NGN IPTV service protection functions applied on a service R-IPTV-CN-7
providing access to IPTV content should interoperate with Content
Protection solutions.
OBJ-39 The NGN IPTV service and content protection functions should R-IPTV-CP-6
provide the means for retrieving related rights and/or keys for
chosen protected content items.
ETSI
11 ETSI TS 187 001 V3.7.1 (2011-03)
Objective Objective text Domain Functional
identifier requirement
identifier
OBJ-40 The NGN IPTV service should provide a means to prevent R-IPTV-CP-7
unauthorised use of content.
OBJ-41 The NGN IPTV service should provide a means to prevent R-IPTV-CP-8
unauthorised distribution of content.
OBJ-42 The NGN IPTV content protection functions should provide a R-IPTV-CP-9
means to prevent consumption of content after a specific time.
OBJ-43 The NGN IPTV service should provide a general framework for the R-IPTV-DRM-1
integration of content protection solutions (e.g. DRM).
OBJ-44 The NGN should support the integration of one or more DRM R-IPTV-DRM-2
solutions for IPTV content protection.
OBJ-45 An NGN operator should provide mechanisms to ensure the R-MS-REG-4
interception and handover of signalling of specific NGN users if
required to by a lawful authority.
OBJ-46 An NGN operator should provide mechanisms to ensure the R-MS-REG-1
interception and handover of the content of communication of
specific NGN users if required to by a lawful authority.
OBJ-47 An NGN operator should provide mechanisms to ensure the R-MS-REG-2
retention and handover of signalling of specific NGN users if
required to by a lawful authority.
OBJ-48 An NGN should ensure that non-broadcast media paths are R-MS-GEN-1
constructed such that eavesdropping cannot be achieved without
intrusion to the media path.
OBJ-49 An NGN should ensure that broadcast media paths (e.g. radio) R-MS-GEN-2
should be protected by encryption of media content.
OBJ-50 An NGN should ensure that the key used for encryption is only R-MS-GEN-3
known to the parties directly involved in the transfer of media over
the broadcast path.
OBJ-51 The NGN should ensure source and destination address R-MS-3
authentication, confidentiality and integrity protection of media
transfer in point-to-point topologies.
OBJ-52 The NGN should ensure source and destination address R-MS-4
authentication, confidentiality and integrity protection of media
transfer in point-to-multipoint topologies.
OBJ-53 The NGN should ensure source and destination address R-MS-5
authentication, confidentiality and integrity protection of media
transfer in broadcast topologies.
OBJ-54 The NGN should provide the ability for an affected user to request R-UC-3
the rating of an UC call.
OBJ-55 The NGN should provide the ability for an affected user to R-UC-4
challenge the ratings made by the UC detection system.
OBJ-56 The NGN should provide the ability to the affected CSP to extract R-UC-5
from the call signalling sufficient information to provide a UC rating
for the call.
OBJ-57 The NGN should provide a mechanism to convey the UC rating in R-UC-6
the call signalling.
OBJ-58 The NGN should provide a mechanism to allow variation in the call R-UC-7
handling for calls with particular UC ratings.
OBJ-59 NAT traversal in the NGN should minimize the number of R-NAT TRAV-10
messages that are transmitted solely for NAT traversal.
OBJ-60 NAT traversal in the NGN should minimize additional session R-NAT TRAV-12
setup delay.
OBJ-61 NAT traversal in the NGN should take into account the scalability, R-NAT TRAV-15
complexity and compatibility with other relevant NGN
requirements.
OBJ-62 Any solution recommended for NAT traversal in the NGN should R-NAT TRAV-16
not impact the inherent ability of TLS to operate across NAT.
OBJ-63 Internally to the CPN, a CNG receiving private or other critical R-CPN-CR-3
information (i.e. from a CND) should verify that the data was
protected from unauthorised disclosure.
OBJ-64 The authentication protocol in the CPN should be designed to R-CPN-IAAR-2
cater for authentication failure.
OBJ-65 On detection of any system failure or discontinuity not specifically R-CPN-AR-3
handled by other mechanisms the CNG should revert to a known
safe state.
ETSI
12 ETSI TS 187 001 V3.7.1 (2011-03)
4 Security Requirements
Security requirements described in clause 4 are identified by a symbolic security requirement identifier (e.g. R-SP-n)
for quick reference and along with some textual description. The security requirements are listed without any implied
preference or priority. It is pointed out that not all security requirements are mutually exclusive, but there is indeed
some unavoidable overlap among them.
ISIM shall be hosted on a UICC. Use of the ISIM on UICC is the preferred solution for achieving the security
requirements to access the NGN IMS features. The ISIM may reside within the device itself, or be accessed remotely,
via a local interface to the "device holding the UICC".
4.1 Security Policy Requirements
A security policy defines the legitimate users of a system and what they are allowed to do. It states what information
must be protected from which threats. In environments with heterogeneous user communities, multiple vendors'
equipment, differing threat models, and uneven deployment of security functionality, assurance that security is
functioning correctly is extremely difficult without enforceable policies.
(R-SP- 1) The TISPAN NGN network shall be logically and physically divided into security domains
allowing for separation of application (e.g. IMS) and transport (e.g. ADSL or UMTS). Also
different operators of similar networks (e.g. IMS) shall be able to operate their own security
policies.
(R-SP- 2) Security mechanisms and other parameters beyond default security mechanisms shall be
configurable. This shall be static for NNI interface and may be negotiated for UNI interfaces. The
security mechanism negotiation shall have a certain minimum level to be defined by the security
domain; e.g. avoid bidding-down attacks. Users shall be able to reject communications that do not
conform to their minimum security policy.
(R-SP- 3) The security mechanisms shall be partitioned such that the functions of authentication, data
integrity, replay detection, and confidentiality may be implemented and selected independently of
each other, insofar as this makes sense.
(R-SP- 4) The UE shall always offer encryption algorithms for P-CSCF to be used for the session and the
P-CSCF policy shall define whether to use encryption or not.
(R-SP- 5) The UE and the P CSCF shall negotiate the integrity algorithm that shall be used for the session.
(R-SP- 6) The policy of the HN shall be used to decide if an authentication shall take place for the
registration of different IMPUs e.g. belonging to same or different service profiles.
(R-SP- 7) The security gateway functions (SEGF) shall be responsible for enforcing security policies for the
interworking between networks.
NOTE: The actual inter-security domain policy is not standardized and is left to the discretion of the roaming
agreements of the operators.
(R-SP- 8) SEGFs are responsible for security sensitive operations and shall offer capabilities for secure
storage of long-term keys used for IKE authentication.
4.2 Authentication, Authorization, Access Control and
Accountability Requirements
General Access authentication
(R-AA- 1) Access to NGN networks, services, and applications shall be provided for authorized users only.
(R-AA- 2) NGN IMS authentication shall support early deployment scenarios, although it is optional for
operators to deploy such scenarios.
ETSI
13 ETSI TS 187 001 V3.7.1 (2011-03)
(R-AA- 3) In non-early deployment scenarios, IMS authentication shall be independent from access
authentication.
(R-AA- 4) An ISIM shall be used to access any IMS service, however, exceptions may be allowed for
emergency calls and early deployment scenarios.
(R-AA- 5) ISIM based Authentication between the IMS-subscriber and the network shall comply to the
authentication part of Access Security for IP-based services TS 133 203 [2].
(R-AA- 6) ISIM based Re-authentication of an IMS-subscriber shall comply to the authentication part of
Access Security for IP-based services TS 133 203 [2].
(R-AA- 7) It shall be possible to prevent the use of a particular ISIM to access NGN networks and services
and it should be possible to revoke a specific ISIM.
(R-AA- 8) NGN relevant ISIM specific information shall be protected against unauthorized access or
alteration.
(R-AA- 9) User authentication may either be hardware-based (for 3GPP UE: ISIM on UICC; i.e. proof by
possession of a physical token) or be software-based (i.e. proof by knowledge of some secret
information).
Early Deployments
(R-AA- 10) User Authentication to the NGN IMS using SIP Digest mechanisms shall be supported as an early
deployment scenario.
(R-AA- 11) Where more than one authentication mechanism are deployed by an NGN IMS operator, that
operator shall determine the authentication mechanism (e.g. SIP Digest or ISIM-based) on a per-
device basis. The authentication mechanism shall be enforced according to both the subscription
information in the user's service profile and the specific policies of the NGN IMS operator. Where
a terminal supports the ISIM solution and the network operator supports both ISIM and early
deployment solutions, ISIM solution shall be used.
(R-AA- 12) Transmitted passwords shall be sufficiently protected; e.g. by encryption or other techniques.
(R-AA- 13) For the special early deployment scenarios (see note 1), where IMS authentication is linked to
access authentication, it shall be possible to gain access to IMS services after an authentication
procedure. This authentication provides simultaneous access to the access network and IMS
services.
NOTE 1: The two special early deployment scenarios are (also referred to as NASS Bundled authentication):
(A) IMS authentication is linked to access line authentication (no nomadicity).
(B) IMS authentication is linked to access authentication for IP Connectivity (limited nomadicity can
be provided).
NOTE 2: Access authentication may result in IMS services being tied to the access point (line) or to the current IP
Connectivity (device). In the latter case limited nomadicity may be available. No IMS specific
authentication is therefore required from the CPE/Terminal to gain access to IMS services.
(R-AA- 14) The NGN subsystems shall be able to be able to define and enforce policy with respect to validity
of user authorization.
Ut Interface
(R-AA- 15) Mutual authentication shall be supported between the UE and the AS before providing
authorization.
(R-AA- 16) It should also be possible to support an Authentication Proxy based architecture.
NOTE 1: The purpose of the AP is to separate the authentication procedure and the AS specific application logic to
different logical entities.
ETSI
14 ETSI TS 187 001 V3.7.1 (2011-03)
(R-AA- 17) Mutual authentication shall be supported between the UE and the AP.
(R-AA- 18) The AP shall decide whether a particular subscriber (i.e. the UE), is authorized to access a
particular AS.
(R-AA- 19) If an AP is used, the AS shall only authorize the access request to the requested resource.
NOTE 2: The AS does not need to explicitly authenticate the user.
NASS
(R-AA- 20) Mutual authentication should be supported between the CPE and the NASS during access network
level registration.
(R-AA- 21) The access network shall be able to authenticate and authorize the access subscriber.
(R-AA- 22) Authentication and authorization to the Access Network is controlled by the operator of the Access
Network.
(R-AA- 23) The attributes required for authentication of a user by the access network maybe provided by the
network operator to whom the user has a NGN IMS subscription.
(R-AA- 24) NASS shall support both the use explicit (e.g. PPP or IEEE 802.1x [i.2]) and/or implicit line
authentication (e.g. MAC address authentication or line authentication) of the users/subscribers. In
the case of the implicit access authentication, it shall rely only on an implicit authentication
through physical or logic identity on the layer 2 (L2) transport layer.
(R-AA- 25) In case the CNG is a routing modem and the Customer Premises Network (CPN) is a private IP
realm, authentication shall be initiated from the CNG.
(R-AA- 26) In case the CNG is a bridge, each UE shall authenticate with the NASS as the IP realm in the CPN
is known to the Access Network.
RACS
(R-AA- 27) RACS and AF shall be mutually authenticated prior to resource authorization.
(R-AA- 27A) AF and SPDF in RACS shall be able to mutually identify each other when performing the
authentication.
CPN - RACS
(R-AA- 28) RACS and CPN shall be mutually authenticated prior to resource authorization.
NOTE: For emergency services alternative procedures are required.
Other Specific Requirements
(R-AA- 28.1) A media gateway controller must be able to handle authentication of multiple media gateways,
i.e. to maintain multiple security associations with different media gateways.
(R-AA- 28.2) Authentication of NGN users and authentication of NGN terminals shall be separate.
(R-AA- 29) Caller id and location information shall be stored according to the Common European regulatory
framework by the EMTEL Service Provider. Caller ID and location information shall be validated
by the EMTEL Service Provider.
ETSI
15 ETSI TS 187 001 V3.7.1 (2011-03)
4.3 Identity and Secure Registration Requirements
The following requirements aim to mitigate against masquerading, spoofing, and impersonation of NGN terminals,
devices/systems (HW/SW) and users. The requirements aim to provide measures against identity theft,
misuse/authorized use of NGN services/applications.
(R-IR- 1) It shall be possible to implicitly register IMPU(s). The implicitly registered IMPU(s) all belong to
the same Service Profile. All the IMPU(s) being implicitly registered shall be delivered by the
HSS to the S-
...