Amf 5G

Indian Telecommunication Security Assurance Requirements (ITSAR)
Access and Mobility Management Function (AMF) of 5G
Release Date: Version: 1.0.0

Enforcement Date:
Security Assurance Standards Facility

National Centre For Communication Security
Department of Telecommunications, Bengaluru-560027
About NCCS
National Centre for communication Security (NCCS), with headquarters at Bengaluru was
set up in 2018 with the objective to establish and operationalize a framework of security
testing and certification within the country. NCCS is mandated to prepare Telecom security
requirements/standards called Indian Telecom Security Assurance Requirements (ITSAR)
that addresses the country specific security needs in telecommunication landscape and
notify the same.
i
Document History
Sl. No ITSAR Reference Title Remarks

1
ii
Contents
A) Outline iv
B) Scope v
C) Conventions v
Chapter 1 – Overview 1
Chapter 2 – Common Security Requirements 6
Chapter 3 – Specific Security Requirements 45
Annexure-I (Definition) 49
Annexure-II(Acronyms) 53
Annexure-III (List of Submissions) 57
Annexure-IV (References) 58
iii
A) Outline
The objective of this document is to present a comprehensive, country-specific security
requirements for the Access and Mobility Management (AMF) network function of 5G Core.
As a control plane function, AMF terminates the interfaces from access network and User
Equipment (UE). Its main functionalities include Registration management, Connection
management, Reachability management, access authentication, access authorization,
support for Lawful Intercept and network slice. AMF provides these functionalities for
both 3GPP and non-3GPP accesses.
The specifications produced by various regional/ international standardization bodies/

organizations/associations like 3GPP, ITU-T, ISO, ETSI, IEEE, IETF, NGMN, O-RAN, TIP,
IRTF, GSMA, TSDSI along with the country-specific security requirements are the basis for
this document. The TEC/TSDSI references made in this document implies that the
respective clause has been adopted as it is or with certain modifications.
This document commences with a brief description of 5G system architecture, AMF and its
functionalities and then proceeds to address the common and entity specific security
requirements of AMF.
iv
B) Scope
This document targets on the security requirements of the 5G Core AMF network function
as defined by 3GPP. This document does not cover the security requirements at the
virtualization and infrastructure layers.
Remote Access regulations are governed by Licensing Wing of DoT.
C) Conventions
1. Must or shall or required denotes the absolute requirement of a particular clause of
ITSAR.
2. Must not or shall not denote absolute prohibition of a particular clause of ITSAR.
3. Should or Recommended denotes that the particular clause of ITSAR may be ignored
under justifiable circumstances but after careful examination of its implications.
4. Should not or not Recommended denotes the opposite meaning of (3) above.
v
Chapter 1 – Overview
Introduction: The fifth generation of mobile technologies - 5G - is expected to connect

people, things, data, applications, transport systems and cities in a smart networked
communication environment. 5G is standardized by the 3rd Generation Partnership Project
(3GPP) and the requirement framework for 5G are specified by ITU under IMT-2020. The
usage scenario/use cases identified for 5G are i) Enhanced Mobile Broadband (eMBB) ii)
Massive Machine Type Communication (mMTC) and iii) Ultra Reliable and Low Latency
Communications (URLLC).
5G Architecture: The generic 5G system (5GS) architecture consists of User Equipment,

Radio Access Network supporting New Radio (NR) and the cloud-native 5G core networks
(5G-CN). 5G base station is called as Next Generation Node B (gNB). The deployment
strategies possible are Non-Stand Alone (NSA) and Stand Alone (SA). SA denotes 5G NR
connecting to 5G CN. In NSA mode, 5G NR gets connected to 4G EPC but uses LTE as anchor
in control plane.
5G Core Network: Core network is the central part of mobile network. 5G Core network
provides authentication, security, mobility management, session management services and
enables the subscribers to avail the services. These functionalities are specified as
“network functions”. Some of the important core network functions are 1) AMF 2) SMF 3)
AuSF 4) UPF 5) AF 6) NEF 7) NRF 8) PCF 9) UDM 10) UDR
The salient features of 5G Core are
1) Separation of user plane and control plane

2) Service Based Architecture (SBA)
3) Network Slicing
4) Network function virtualization and Software Define Networking
5) Automation
6) Access Agnostic
7) Framework for policy control and support of QoS
8) Secure exposure of network functions to 3rd party providers
In a SBA framework, the individual elements are defined as Network Functions (NFs)
instead of Network entities. Through Service Based Interface (SBI) each of the NFs
consumes services offered by other service producer-other NFs. RESTful APIs are used in
5G SBA which use HTTP/2 as application layer protocol.
1
Access and Mobility Management Function (AMF): AMF can be compared to MME of
LTE which handles both mobility and session management functions. However, in 5G
mobility management is handled by AMF and SMF handles the session management.
The Access and Mobility Management function (AMF) includes the following functionality.
Some or all of the AMF functionalities may be supported in a single instance of an AMF:
- Termination of RAN CP interface (N2).
- Termination of NAS (N1), NAS ciphering and integrity protection.
- Registration management.
- Connection management.
- Reachability management.
- Mobility Management.
- Lawful intercept (for AMF events and interface to LI System).
- Provide transport for SM messages between UE and SMF.
- Transparent proxy for routing SM messages.
- Access Authentication.
- Access Authorization.
- Provide transport for SMS messages between UE and SMSF.
- Security Anchor Functionality (SEAF).
- Location Services management for regulatory services.
- Provide transport for Location Services messages between UE and LMF as well as
between RAN and LMF.
- EPS Bearer ID allocation for interworking with EPS.
- UE mobility event notification.
- S-NSSAIs per TA mapping notification.
- Support for Control Plane CIoT 5GS Optimization.
- Support for User Plane CIoT 5GS Optimization.
- Support for restriction of use of Enhanced Coverage.
- Provisioning of external parameters (Expected UE Behaviour parameters or Network
Configuration parameters).
2
- Support for Network Slice-Specific Authentication and Authorization.
- Support for charging.
In addition to the functionalities of the AMF described above, the AMF may include the
following functionality to support non-3GPP access networks:
- Support of N2 interface with N3IWF/TNGF.
- Support of NAS signaling with a UE over N3IWF/TNGF.
- Support of authentication of UEs connected over N3IWF/TNGF.
- Management of mobility, authentication, and separate security context state(s) of a
UE connected via a non-3GPP access or connected via a 3GPP access and a non-3GPP
access simultaneously.
- Support of co-ordinated RM management context valid over a 3GPP access and a
Non 3GPP access.
- Support of dedicated CM management contexts for the UE for connectivity over non-
3GPP access.
In addition to the functionalities of the AMF described above, the AMF may include policy
related functionalities.
The AMF uses the N14 interface for AMF re-allocation and AMF to AMF information
transfer. This interface may be either intra-PLMN or inter-PLMN (e.g. in the case of inter-
PLMN mobility).
In addition to the functionality of the AMF described above, the AMF may include the
following functionality to support monitoring in roaming scenarios:
- Normalization of reports according to roaming agreements between VPLMN and
HPLMN (e.g. change the location granularity in a report from cell level to a level that
is appropriate for the HPLMN); and
- Generation of charging/accounting information for Monitoring Event Reports that are
sent to the HPLMN.
In addition to the functionality of the AMF described above, the AMF may provide support
for Network Slice restriction and Network Slice instance restriction based on NWDAF
analytics.
In addition to the functionalities of the AMF described above, the AMF may provide support
for the Disaster Roaming.
In addition to the functionalities of the AMF described above, the AMF may also include
following functionalities to support Network Slice Admission Control:
- Support of NSAC for maximum number of UEs.
3
In addition to the functionality of the AMF described above, the AMF may include the
following functionality to support SNPNs:
- Support for Onboarding of UEs for SNPNs.
Architectural representation: 3GPP Release specifies 5G Core network functions in two
ways i) reference point based architecture and ii) service based architecture. Please refer
Figure 1.
Figure 1: Roaming 5G System architecture- local breakout scenario

in service-based interface.
As shown in Figure 1, AMF is connected to UE with the N1 interface. N1 interface messages

are physically passed through the access network (AN) to show the logical connection; a
direct connection in the service-based architecture is illustrated in Figure 1. The N2
interface in Figure 1 is the interface between the Access Network and AMF.
AMF plays an important role in ciphering the N1 NAS messages. NAS message’s
Confidentiality and Integrity protection is a key requirement that AMF will fulfill. When a
UE establishes communication with the core network, the Subscriber privacy is also taken
into account with the help of AMF. The security anchor function (SEAF) provides
authentication via the AMF in the serving network.
AMF Security: TEC 25878:2022/TSDSI STD T1.3GPP 33.501-16.9.0 V1.0.0 includes

requirements for the AMF as for signaling data confidentiality, signaling data integrity,
4
subscriber privacy and requirements on Security Anchor Function (SEAF). Security for
Service Based Architecture, protection at management plane, protection at control plane,
protection at data plane, protection at synchronization plane, platform security, secure
implementation of crypto modules & algorithms are some of the base line security
requirements.
5
Chapter 2 – Common Security Requirements
_________________________________________________________________________________________________________
Section 1: Access and Authorization
_________________________________________________________________________________________________________
2.1.1 Management Protocols Mutual Authentication
Requirement:
The network product management shall support mutual authentication mechanisms, the
mutual authentication mechanism can rely on the protocol used for the interface itself or
other means.
Secure cryptographic controls prescribed in Table 1 of the latest document “Cryptographic

Controls For Indian Telecom Security Assurance Requirements (ITSAR)” shall only be used
for AMF management and maintenance.
[Ref: TEC 25848:2022 /TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section 4.2.3.4.4.1]
_________________________________________________________________________________________________________
2.1.2 Management Traffic Protection
Requirement:
AMF management traffic shall be protected strictly using secure cryptographic controls
prescribed in Table 1 of the latest document “Cryptographic Controls For Indian Telecom
Security Assurance Requirements (ITSAR)” only.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section 4.2.3.2.4]
_________________________________________________________________________________________________________
2.1.3 Role-based access control policy
Requirement:
AMF shall support Role-Based Access Control (RBAC). A role-based access control system
uses a set of controls that determines how users interact with domains and resources. The
RBAC system controls how users or groups of users are allowed access to the various
domains and what type of operation they can perform, i.e., the specific operation command
or command group (e.g View, Modify, Execute). AMF supports RBAC with minimum of 3
user roles, in particular, for OAM privilege management for AMF Management and
6
Maintenance, including authorization of the operation for configuration data and software
via the network product console interface.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section 4.2.3.4.6.2]
Note: The reference to Console interface may not be applicable here for GVNP Models of
Type 1& 2
_________________________________________________________________________________________________________
2.1.4. User Authentication – Local/Remote
Requirement:
The various user and machine accounts on a system shall be protected from misuse. To this
end, an authentication attribute is typically used, which, when combined with the
username, enables unambiguous authentication and identification of the authorized user.
Authentication attributes include

- Cryptographic keys
- Token
- Passwords
This means that authentication based on a parameter that can be spoofed is not permitted.
Exceptions are attributes that cannot be faked or spoofed by an attacker.
Minimum two of the above Authentication attributes shall be mandatorily combined for
protecting all the accounts from misuse. An exception to this requirement is local access
and machine accounts where atleast one authentication attribute shall be supported.
Note: Local interface may not be applicable here for GVNP Models of Type 1& 2
_________________________________________________________________________________________________________
2.1.5 Remote login restrictions for privileged users
Requirement:
Direct Login to AMF as root or equivalent highest privileged user shall be limited to the
system console only. Root user will not be allowed to login to AMF remotely.
This remote root user access restriction is also applicable to application software’s / tools
7
such as TeamViewer, desktop sharing which provide remote access to the AMF.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section 4.3.2.6]
_________________________________________________________________________________________________________
2.1.6 Authorization Policy
Requirement:
The authorizations for accounts and applications shall be reduced to the minimum
required for the tasks they have to perform.
Authorizations to a system shall be restricted to a level in which a user can only access data
and use functions that he needs in the course of his work. Suitable authorizations shall also
be assigned for access to files that are components of the operating system or of
applications or that are generated by the same (e.g. configuration and logging files).
Alongside access to data, execution of applications and components shall also take place
with rights that are as low as possible. Applications should not be executed with
administrator or system rights.
_________________________________________________________________________________________________________
2.1.7 Unambiguous identification of the user & group accounts removal
Requirement:
Users shall be identified unambiguously by the AMF.
AMF shall support the assignment of individual accounts per user, where a user could be a
person, or, for Machine Accounts, an application, or a system.
AMF shall not enable the use of group accounts or group credentials, or sharing of the same
account between several users.
_________________________________________________________________________________________________________
Section 2: Authentication Attribute Management
_________________________________________________________________________________________________________
2.2.1 Authentication Policy
Requirement:
The usage of a system function without successful authentication on basis of the user
identity and at least two authentication attribute (e.g. password, certificate) shall be
8
prevented. For machine accounts and local access one authentication attribute will be
sufficient. System functions comprise, for example network services (like SSH, SFTP, Web
services), local access via a management console, local usage of operating system and
applications. This requirement shall also be applied to accounts that are only used for
communication between systems.
Note: The reference to ‘Local access’ and ‘Console’ may not be applicable here for GVNP
Models of Type 1& 2
_________________________________________________________________________________________________________
2.2.2 Authentication Support – External
Requirement:
If the AMF supports external authentication mechanism such as AAA server (for
authentication, authorisation and accounting services), then the communication between
AMF and the external authentication entity shall be protected using the authentication and
related service protocols built strictly using the Secure cryptographic controls prescribed
in Table 1 of the latest document “Cryptographic Controls For Indian Telecom Security
Assurance Requirements ( ITSAR )” only.
_________________________________________________________________________________________________________
2.2.3 Protection against brute force and dictionary attacks
Requirement:
A protection against brute force and dictionary attacks that hinder authentication attribute
guessing shall be implemented in AMF.
Brute force and dictionary attacks aim to use automated guessing to ascertain
authentication attribute for user and machine accounts.
Various measures or a combination of the following measures can be taken to prevent this:
a) Using the timer delay (this delay could be the same or increased depending the
operator's policy for each attempt) for each newly entered password input following an
incorrect entry ("tar pit").
b) Blocking an account following a specified number of incorrect attempts. However, it has
to be taken into account that this solution needs a process for unlocking and an attacker
can force this to deactivate accounts and make them unusable.
c)Using an authentication attribute blacklist to prevent vulnerable passwords.
d)Using CAPTCHA to prevent automated attempts (often used for Web applications).
9
In order to achieve higher security, two or more of the measures indicated above shall be
mandatorily supported by AMF. An exception to this requirement is machine accounts.
_________________________________________________________________________________________________________
2.2.4 Enforce Strong Password
Requirement:
a) The configuration setting shall be such that AMF shall only accept passwords that
comply with the following complexity criteria:
i)Absolute minimum length of 8 characters (shorter lengths shall be rejected by the AMF).
It shall not be possible setting this absolute minimum length to a lower value by
configuration.
ii) Password shall mandatorily comprise all the following four categories of characters:
- at least 1 uppercase character (A-Z)
- at least 1 lowercase character (a-z)
- at least 1 digit (0-9)
- at least 1 special character (e.g. @;!$.)
b) The minimum length of characters in the passwords and the set of allowable special
characters shall be configurable by the operator. The special characters may be categorized
in sets according to their Unicode category.
c) If a central system is used for user authentication password policy, then additional
assurance shall be provided that the central system enforces the same password
complexity rules as laid down for the local system in this sub-clause.
d) If a central system is not used for user authentication, the assurance on password
complexity rules shall be performed on the AMF.
e) When a user is changing a password or entering a new password, AMF /central system
checks and ensures that it meets the password requirements. Above requirements shall be
applicable for all passwords used (e.g. application-level, OS-level, etc.).
Password shall not be stored in clear text in the system; passwords shall be salted and
hashed.
_________________________________________________________________________________________________________
2.2.5 Inactive Session timeout
Requirement:
10
An OAM user interactive session shall be terminated automatically after a specified period
of inactivity. It shall be possible to configure an inactivity time-out period.
AMF shall monitor inactive sessions of administrative login users and initiate session
locking mechanism based on user configurable timers. Unlocking the session shall be
permissible only by authentication. If the inactivity period further continues for a defined
period, Session /user ID time out must occur after this inactivity.
The timer values can be admin configurable as per requirement, normally set between 2 to
5 minutes.
_________________________________________________________________________________________________________
2.2.6 Password Changes
Requirement:
If a password is used as an authentication attribute, then the system shall offer a function
that enables a user to change his password at any time. When an external centralized
system for user authentication is used, it should be possible to implement this function on
this system.
Password change shall be enforced after initial login.
AMF shall enforce password change based on password management policy.
In particular, the system shall enforce password expiry. AMF shall support a configurable
period for expiry of passwords.
Previously used passwords shall not be allowed upto a certain number (Password History).
The number of disallowed previously used passwords shall be:

• Configurable;
• Greater than 0;
• And its minimum value shall be 3. This means that the AMF shall store at least the three
previously set passwords. The maximum number of passwords that the AMF can store for
each user is up to the manufacturer.
When a password is about to expire, a password expiry notification shall be provided to the
user.
Above requirements shall be applicable for all passwords used (e.g. application-level, OS-
level, etc.). An exception to this requirement is machine accounts.
AMF to have in-built mechanism to support this requirement.
If a central system is used for user authentication password policy, then additional
assurance shall be provided that the central system enforces the same password change
policies as laid down for the local system in this subclause.
11
And if a central system is not used for user authentication, the assurance on password
changes rules shall be performed on the AMF.
_________________________________________________________________________________________________________
2.2.7 Protected Authentication feedback
Requirement:
The Authentication attribute shall not be displayed in such a way that it could be seen and
misused by a casual local observer. Typically, the individual characters of the password are
replaced by a character such as "*".
_________________________________________________________________________________________________________
2.2.8 Removal of predefined or default authentication attributes
Requirement:
Predefined or default authentication attributes shall be deleted or disabled.
Normally, authentication attributes such as password or cryptographic keys will be
preconfigured from producer, OEM or developer of a system. Such authentication
attributes shall be changed by automatically forcing a user to change it on 1st time login to
the system or the OEM provides instructions on how to manually change it.
_________________________________________________________________________________________________________
2.2.9 Logout function
Requirement:
The system shall have a function that allows a signed-in user to logout at any time. All
processes under the logged-in user ID shall be terminated on logout. The network product
shall be able to continue to operate without interactive sessions.
Only for debugging purposes, processes under a logged-in user ID may be allowed to
continue to run after detaching the interactive session.
[Reference: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section 4.2.3.5.1]
12
_________________________________________________________________________________________________________
2.2.10 Policy regarding consecutive failed login attempts
Requirement:
a) The maximum permissible number of consecutive failed user account login attempts
should be configurable by the operator. The definition of the default value set at
manufacturing time for the maximum number of failed user account login attempts shall be
less than or equal to 8, typically 5. After the maximum permissible number of consecutive
failed user account login attempts is exceeded by a user, there shall be a block delay in
allowing the user to attempt login again. This block delay and the capability to set the
period of the block delay, e.g., double the delay, or 5 minutes delay, or 10 minutes delay,
after each login failure should be configurable by the operator. The default value set at
manufacturing time for this delay shall be greater than or equal to 5 sec.
b) If supported, infinite (permanent) locking of an account that has exceeded the maximum
permissible number of consecutive failed user account login attempts should also be
possible via configuration, with the exception of administrative accounts, which shall get
only temporarily locked.
_________________________________________________________________________________________________________
Section 3: Software Security
_________________________________________________________________________________________________________
2.3.1 Secure Update
Requirement:
a) Software package integrity shall be validated during software update stage.
b) AMF shall support software package integrity validation via cryptographic means, e.g.
digital signature using Secure cryptographic controls prescribed in Table 1 of the latest
document “Cryptographic Controls For Indian Telecom Security Assurance Requirements
(ITSAR)” only. To this end, the network product has a list of public keys or certificates of
authorised software sources, and uses the keys to verify that the software update is
originated from only these sources.
c) Tampered software shall not be executed or installed if integrity check fails.
d) A security mechanism is required to guarantee that only authorized individuals can
initiate and deploy a software update, and modify the list mentioned in bullet b.
Note: Code signing (valid and not time expired) is also allowed as as an option in bullet b.
_________________________________________________________________________________________________________
13
2.3.2 Secure Upgrade
Requirement:
a) Software package integrity shall be validated during software upgrade stage.
b) AMF shall support software package integrity validation via cryptographic means, e.g.
digital signature using Secure cryptographic controls prescribed in Table 1 of the latest
document “Cryptographic Controls For Indian Telecom Security Assurance Requirements
(ITSAR)” only. To this end, the network product has a list of public keys or certificates of
authorised software sources, and uses the keys to verify that the software update is
originated from only these sources.
c) Tampered software shall not be executed or installed if integrity check fails.
d) A security mechanism is required to guarantee that only authorized individuals can
initiate and deploy a software upgrade, and modify the list mentioned in bullet b.
Note: Code signing (valid and not time expired) is also allowed as as an option in bullet b.
_________________________________________________________________________________________________________
2.3.3 Source code security assurance
Requirement:
a) OEM shall follow best security practices including secure coding for software
development. Source code shall be made available either at TSTL premises or at the
mutually agreed location for source code review by the designated TSTL. It may be
supported by furnishing the Software Test Document (STD).
b) Also, OEM shall submit the undertaking as below:
i) Industry standard best practices of secure coding have been followed during the entire
software development life cycle of the AMF Software which includes OEM developed code,
third party software and opensource code libraries used/embedded in the AMF.
ii) AMF software shall be free from CWE top 25, OWASP top 10 security vulnerabilities and
OWASP top 10 API Security vulnerabilities as on the date of latest release of product or
three months prior to the date of offer of product for testing, whichever is latest. For
security weaknesses, vulnerabilities identified or discovered during the interim period,
OEM shall give mitigation plan.
iii) The binaries for AMF and upgrades/updates thereafter generated from the source code
are free from all known security vulnerabilities stated in bullet (ii) above.
14
_________________________________________________________________________________________________________
2.3.4 Known Malware and backdoor Check
Requirement:
OEM shall submit an undertaking stating that AMF is free from all known malware and
backdoors as on the date of offer of AMF to designated TSTL for testing and shall submit
their internal Malware Test Document (MTD) of the AMF to the designated TSTL.
_________________________________________________________________________________________________________
2.3.5 No unused software

Requirement:
Software components or parts of software which are not needed for operation or
functionality of the AMF shall not be present.
Orphaned software components /packages shall not be present in AMF.
OEM shall provide the list of software that are necessary for AMF’s operation.
In addition, OEM shall furnish an undertaking as “AMF does not contain Software that is not
used in the functionality of AMF.”
_________________________________________________________________________________________________________
2.3.6 Unnecessary Services Removal
Requirement:
AMF shall only run protocol handlers and services which are needed for its operation and
which do not have any known security vulnerabilities. By default, all other ports and
services will be permanently disabled. AMF Shall not support following services:
- FTP
- TFTP
- Telnet
- rlogin, RCP, RSH
- HTTP
- SNMPv1 and v2
- SSHv1
- TCP/UDP Small Servers (Echo, Chargen, Discard and Daytime)
15
- Finger
- BOOTP server
- Discovery protocols (CDP, LLDP)
- IP Identification Service (Identd)
- PAD
- MOP
Any other protocols, services that are vulnerable are also to be permanently disabled.
Full documentation of required protocols and services (communication matrix) of the AMF
and their purpose needs to be provided by the OEM as prerequisite for the test case.
_________________________________________________________________________________________________________
2.3.7 Restricting System Boot Source
Requirement:
The AMF can boot only from the memory devices intended for this purpose.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section- 4.2.3.3.2]
Note: This may not be applicable here for GVNP Models of Type 1& 2.
_________________________________________________________________________________________________________
2.3.8 Secure Time Synchronization
Requirement:
AMF shall establish secure communication channel with the NTP/PTP server.
AMF shall establish secure communication channel strictly using Secure cryptographic
controls prescribed in Table 1 of the latest document “Cryptographic Controls For Indian
Telecom Security Assurance Requirements (ITSAR)” with NTP/PTP server.
AMF shall generate audit logs for all changes to time settings.
Note: RFC 8915 which proposes Network Time Security (NTS) as an extension field for the
NTP version 4 is also permitted.
_________________________________________________________________________________________________________
2.3.9 Restricted reachability of services

Requirement:
16
The AMF shall restrict the reachability of services such that they can be reached only on
interfaces meant for the purpose. On interfaces where services are active, the reachability
should be limited to legitimate communication peers.
Administrative services (e.g. SSH, HTTPS, RDP) shall be restricted to interfaces in the
management plane for separation of management traffic from user traffic.
2.3.10 Self Testing

Requirement:
The AMF’s cryptographic module shall perform power-up self-tests and conditional self-
tests to ensure that the module is functioning properly. Power-up self-tests shall be
performed when the cryptographic module is powered up. Conditional self-tests shall be
performed when an applicable security function or operation is invoked (i.e., security
functions for which self-tests are required). If a cryptographic module fails a self-test, the
module shall enter an error state and output an error indicator via the status output
interface. The cryptographic module shall not perform any cryptographic operations while
in an error state.
_________________________________________________________________________________________________________
Section 4: System Secure Execution Environment
_________________________________________________________________________________________________________
2.4.1 No unused functions
Requirement:
Unused functions i.e the software and hardware functions which are not needed for
operation or functionality of the AMF shall be deactivated in the AMF’s software and/or
hardware.
The list of hardware and software functions installed in the system shall match with the
ones that have been mentioned and deemed necessary for the operation of the AMF.
Note: The reference to hardware may not be applicable here for GVNP Models of Type 1& 2.
_________________________________________________________________________________________________________
2.4.2 No unsupported components
Requirement:
OEM to ensure that the AMF shall not contain software and hardware components that are
17
no longer supported by them or their 3rd Parties including the opensource communities,
such as components that have reached end-of-life or end-of-support. An undertaking in this
regard shall be given by OEM.
Note: The reference to hardware may not be applicable here for GVNP Models of Type 1& 2.
_________________________________________________________________________________________________________
2.4.3 Avoidance of Unspecified mode of Access
Requirement:
AMF shall not contain any wireless access mechanism which is unspecified or not declared.
An undertaking shall be given by the OEM as follows:
"The AMF does not contain any wireless, optical, magnetic or any other component that
may be used as a covert channel."
_________________________________________________________________________________________________________
Section 5: User Audit
_________________________________________________________________________________________________________
2.5.1 Audit trail storage and protection
Requirement:
The security event log shall be access controlled (file access rights) so only privileged users
have access to the log files.
_________________________________________________________________________________________________________
2.5.2 Audit Event Generation
Requirement:
The AMF shall log all important Security events with unique System Reference details as
given in the Table below.
AMF shall record within each audit record at least information pertaining to date and time
of the event, type of event, subject identity, and the outcome (success or failure) of the
event.
Additional audit record information, depending on the audit event, shall also be provided
as given in the Table below:
18
Event Types
(Mandatory or Description Event data to be logged
optional)
Incorrect login attempts Records any user incorrect login Username
(Mandatory) attempts to the AMF. Source (IP address) if
remote access
Outcome of event (Success
or failure)
Timestamp
Administrator access Records any access attempts to Username
(Mandatory) accounts that have system Timestamp
privileges.
Length of session
or failure)
Source (IP address) if
remote access
Account administration Records all account Administrator username
(Mandatory) administration activity, i.e. Administered account
configure, delete, copy, enable,
Activity performed
and disable.
(configure, delete, enable
and disable)
or failure)
Timestamp
Resource Usage Records events that have been Value exceeded
(Mandatory) triggered when system parameter
Value reached
values such as disk space, CPU
load over a longer period have (Here suitable threshold
exceeded their defined values shall be defined
thresholds. depending on the individual
system.)
Outcome of event
(Threshold Exceeded)
Timestamp
Configuration change Changes to configuration of the Change made
(Mandatory) network device Timestamp
or failure)
19
Username
Reboot/shutdown/crash This event records any action on Action performed (boot,
(Mandatory) the network device/AMF that reboot, shutdown, etc.)
forces a reboot or shutdown OR Username (for intentional
where the network device/AMF actions)
has crashed.
or failure)
Timestamp
Interface status change Change to the status of interfaces Interface name and type
(Mandatory) on the network device/AMF (e.g. Status (shutdown, down
shutdown) missing link, etc.)
or failure)
Timestamp
Change of group Any change of group membership Administrator username
membership or accounts for accounts Administered account
(Optional)
Activity performed (group
added or removed)
or failure)
Timestamp
Resetting Passwords Resetting of user account Administrator username
(Optional) passwords by the Administrator Administered account
Activity performed
(configure, delete, enable
and disable)
or failure)
Timestamp
Services (Optional) Starting and Stopping of Services Service identity
(if applicable) Activity performed (start,
stop, etc.)
Timestamp
or failure)
X.509 Certificate Unsuccessful attempt to validate a Timestamp
Validation (Optional) certificate Reason for failure
Subject identity
Type of event
20
Secure Update Attempt to initiate manual User identity
(Optional) update, initiation of update, Timestamp
completion of update
or failure)
Activity performed
Time change Change in time settings Old value of time
(Mandatory) New value of time
Timestamp
origin of attempt to change
time (e.g.IP address)
Subject identity
or failure)
User identity
Session unlocking/ Any attempts at unlocking of an User identity (wherever
termination (Optional) interactive session, termination of applicable)
a remote session by the session Timestamp
locking mechanism, termination Outcome of event (Success
of an interactive session or failure)
Subject identity
Activity performed
Type of event
Trusted Communication Initiation, Termination and Timestamp
paths with IT entities Failure of trusted Communication Initiator identity (as
such as Authentication paths applicable)
Server, Audit Server, Target identity (as
NTP Server, etc. and for
applicable)
authorised remote
administrators User identity (in case of
(Optional) Remote administrator
access)
Type of event
or failure, as applicable)
Audit data changes Changes to audit data including Timestamp
(Optional) deletion of audit data Type of event (audit data
deletion, audit data
modification)
or failure)
21
Subject identity
User identity
origin of attempt to change
time (e.g.IP address)
Details of data deleted or
modified
User Login (Mandatory) All use of Identification and User identity
authentication mechanisms. Origin of attempt (IP
address)
or failure)
Timestamp
2.5.3 Secure Log Export
Requirement:
a) The AMF shall support forwarding of security event logging data to an external system
available in redundant configuration by push or pull mechanism through diverse links.
b) Log functions should support secure uploading of log files to a central location or to a
system external for the AMF.
c) AMF shall be able to store the generated audit data locally. The memory for this purpose
shall be dimensioned to cater for the continuous storage of two days of audit data. OEM
shall submit justification document for sufficiency of local storage requirement.
d) Secure Log export shall comply the secure cryptographic controls prescribed in Table 1
of the latest document “Cryptographic Controls For Indian Telecom Security Assurance
Requirements (ITSAR)” only.
_________________________________________________________________________________________________________
2.5.4 Logging access to personal data
Requirement:
In some cases, access to personal data in a clear text might be required. If such access is
required, access to this data shall be logged, and the log shall contain who accessed what
data without revealing personal data in clear text. When for practical purposes, such
logging is not available, a coarser grain logging is allowed. In some cases, the personal data
22
stored in the log files may allow the direct identification of a subscriber. In such cases, the
revealed
personal information may not expose the subscriber to any kind of privacy violation.
_________________________________________________________________________________________________________
Section 6: Data Protection
2.6.1 Cryptographic Based Secure Communication
Requirement:
AMF shall Communicate with the connected entities strictly using the secure cryptographic
controls prescribed in Table 1 of the latest document “Cryptographic Controls For Indian
Telecom Security Assurance Requirements (ITSAR)” only.
OEM shall submit to TSTL, the list of the connected entities with AMF and the method of
secure communication.
2.6.2 Cryptographic Module Security Assurance

Requirement:
Cryptographic module embedded inside the AMF (in the form of hardware, software or
firmware) that provides all the necessary security services such as authentication, integrity
and confidentiality is designed and implemented in compliance with FIPS 140-2 or later as
prescribed by NIST standards.
Till further instructions, this clause will be considered ‘complied’ by submission of an

undertaking by the OEM in specified format.
An undertaking is to be submitted by the OEM mentioning that “Cryptographic module

embedded inside the AMF (in the form of hardware, software or firmware) that provides all
the necessary security services such as authentication, integrity and confidentiality is
designed and implemented in compliance with FIPS 140-2 or later as prescribed by NIST
standards.”
_________________________________________________________________________________________________________
2.6.3. Cryptographic Algorithms implementation Security Assurance
Requirement:
Cryptographic algorithm implemented inside the Crypto module of AMF shall be in
compliance with the respective FIPS standards (for the specific crypto algorithm).
23
Till further instructions, this clause will be considered ‘complied’ by submission of an
undertaking by the OEM in specified format.
An undertaking is to be submitted by the OEM mentioning that “Cryptographic algorithms

implemented inside the Crypto module of AMF is in compliance with the respective FIPS
standards (for the specific crypto algorithm embedded inside the AMF).”
2.6.4. Protecting data and information – Confidential System Internal Data
Requirement:
a) When AMF is in normal operational mode (i.e., not in maintenance mode) there shall be
no system function that reveals confidential system internal data in the clear text to users
and administrators.
b) Access to maintenance mode shall be restricted only to authorised privileged user.
2.6.5. Protecting data and information in storage
Requirement:
a) For sensitive data (persistent or temporary) in storage, read access rights shall be
restricted. Sensitive files of AMF system that are needed for the functionality shall be
protected against manipulation strictly using the Secure cryptographic controls prescribed
in Table 1 of the latest document “Cryptographic Controls For Indian Telecom Security
Assurance Requirements (ITSAR)” with appropriate non-repudiation controls.
b) In addition, the following rules apply for:

i)Systems that need access to identification and authentication data in the clear/readable
form e.g. in order to perform an authentication. Such systems shall not store this data in
the clear/readable form, but scramble or encrypt it by implementation-specific means.
ii)Systems that do not need access to sensitive data in the clear. Such systems shall hash
this sensitive data strictly using the cryptographic controls prescribed in Table 1 of the
latest document “Cryptographic Controls For Indian Telecom Security Assurance
Requirements (ITSAR)” only.
iii)Stored files in the AMF: Shall be protected against manipulation strictly using the NCCS
approved Secure cryptographic controls prescribed in Table 1 of the latest document
“Cryptographic Controls For Indian Telecom Security Assurance Requirements (ITSAR)”
only.
_________________________________________________________________________________________________________
24
2.6.6 Protection against Copy of Data
Requirement:
a) Without authentication & authorization and except for specified purposes, AMF shall not
support copying of control plane and user plane data.
b) Protective measures should exist against use of available system functions / software
residing in AMF to create copy of control plane and user plane data for illegal transmission.
_________________________________________________________________________________________________________
2.6.7 Protection against Data Exfiltration - Overt Channel
Requirement:
a) AMF shall have mechanisms to prevent data exfiltration attacks for theft of control plane
and user plane data in use and data in transit.
b) Establishment of outbound overt channels such as, HTTPS, IM, P2P, Email etc. are to be
forbidden if they are auto-initiated by / auto-originated from the AMF.
c) Session logs shall be generated for establishment of any session initiated by either user
or AMF.
_________________________________________________________________________________________________________
2. 6.8 Protection against Data Exfiltration - Covert Channel
Requirement:
a) AMF shall have mechanisms to prevent data exfiltration attacks for theft of control plane
and user plane data in use and data in transit.
b) Establishment of outbound covert channels and tunnels such as DNS Tunnel, HTTPS
Tunnel, ICMP Tunnel, TLS, SSL, SSH, IPSEC VPN, RTP Encapsulation etc. are to be forbidden
if they are auto-initiated by / auto-originated from the AMF.
c) Session logs shall be generated for establishment of any session initiated by either user
or AMF system.
_________________________________________________________________________________________________________
Section 7: Network Services
________________________________________________________________________________________________________
2.7.1 Traffic Filtering – Network Level Requirement
Requirement:
AMF shall provide a mechanism to filter incoming IP packets on any IP interface.
In particular the AMF shall provide a mechanism:
a) To filter incoming IP packets on any IP interface at Network Layer and Transport Layer
of the stack ISO/OSI.
25
b) To allow specified actions to be taken when a filter rule matches. In particular at least
the following actions should be supported:
-Discard/Drop: the matching message is discarded, no subsequent rules are applied and no
answer is sent back.
-Accept: the matching message is accepted.
-Account: the matching message is accounted for i.e. a counter for the rule is incremented.
This action can be combined with the previous ones.
This feature is useful to monitor traffic before its blocking.
c) To enable/disable for each rule the logging for Dropped packets, i.e. details on messages
matching the rule for troubleshooting.
d) To filter on the basis of the value(s) of source IP, destination IP and port addresses of
protocol header.
e) To reset the accounting.
f) The AMF shall provide a mechanism to disable/enable each defined rule.
_________________________________________________________________________________________________________
2.7.2 Traffic Separation
Requirement:
The AMF shall support the physical or logical separation of traffic belonging to different
network domains. For example, O&M traffic and control plane traffic belong to different
network domains. See RFC 3871 for further information.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. section 4.3.5.1].
_________________________________________________________________________________________________________
2.7.3 Traffic Protection –Anti-Spoofing
Requirement:
AMF shall not process IP Packets if their source address is not reachable via the incoming
interface. Implementation example: Use of "Reverse Path Filter" (RPF) provides this
function.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. section 4.3.3.1.1]
_________________________________________________________________________________________________________
26
2.7.4 GTP-C Filtering (when 5GC is interworking with EPC)
Requirement:
The following capability is conditionally required:
- For each message of a GTP-C-based protocol, it shall be possible to check whether the
sender of this message is authorized to send a message pertaining to this protocol.
- At least the following actions should be supported when the check is satisfied:
- Discard: the matching message is discarded.
- Accept: the matching message is accepted.
- Account: the matching message is accounted for, i.e., a counter for the rule is incremented.
This action can be combined with the previous ones. This feature is useful to monitor traffic
before its blocking.
This requirement is conditional in the following sense: It is required that at least one of the
following two statements holds:
- AMF supports the capability described above, and this is stated in the product
documentation.
- The AMF’s documentation states that the capability is not supported and that the AMF
needs to be deployed together with a separate entity that provides the capability described
above.
Note: This clause is applicable for AMF.

_________________________________________________________________________________________________________
2.7.5 GTP-U Filtering
Requirement:
The following capability is conditionally required:
- For each message of a GTP-U-based protocol, it shall be possible to check whether the
sender of this message is authorized to send a message pertaining to this protocol.
- At least the following actions should be supported when the check is satisfied:
- Discard: the matching message is discarded.
- Accept: the matching message is accepted.
- Account: the matching message is accounted for, i.e., a counter for the rule is incremented.
This action can be combined with the previous ones. This feature is useful to monitor traffic
before its blocking.
27
This requirement is conditional in the following sense: It is required that at least one of the
following two statements holds:
- AMF supports the capability described above, and this is stated in the product
documentation.
- The AMF’s product documentation states that the capability is not supported and that the
AMF needs to be deployed together with a separate entity which provides the capability
described above.
Note: This clause is applicable for UPF.

_________________________________________________________________________________________________________
Section 8: Attack Prevention Mechanisms
________________________________________________________________________________________________________
2.8.1 Network Level and application-level DDoS
Requirement:
AMF shall have protection mechanism against Network level and Application-level DDoS
attacks.
AMF shall provide security measures to deal with overload situations which may occur as a
result of a denial of service attack or during periods of increased traffic. In particular,
partial or complete impairment of system availability shall be avoided.
For example, potential protective measures may include:
- Restricting of available RAM per application

- Restricting of maximum sessions for a Web application
- Defining the maximum size of a dataset
- Restricting CPU resources per process
- Prioritizing processes
- Limiting of amount or size of transactions of an user or from an IP address in a specific
time range
- Limiting of amount or size of transactions to an IP address/Port Address in a specific time
range
[Reference: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section 4.2.3.3.1]
________________________________________________________________________________________________________
28
2.8.2 Excessive Overload Protection
Requirement:
AMF shall act in a predictable way if an overload situation cannot be prevented. AMF shall
be built in this way that it can react on an overload situation in a controlled way.
However, it is possible that a situation happens where the security measures are no longer
sufficient. In such case it shall be ensured that AMF cannot reach an undefined and thus
potentially insecure, state.
OEM shall provide a technical description of the AMF’s Over Load Control mechanisms.
(especially whether these mechanisms rely on cooperation of other network elements e.g.
RAN)
_________________________________________________________________________________________________________
2.8.3 Manipulated packets that are sent to an address of the network device shall not
lead to an impairment of availability.
Requirement:
AMF shall not be affected in its availability or robustness by incoming packets from other
network elements that are manipulated or differing the norm. This means that appropriate
packets shall be detected as invalid and be discarded. The process shall not be affecting the
performance of the AMF. This robustness shall be just as effective for a great mass of
invalid packets as for individual or a small number of packets.
Examples of such packets are:

- Mass-produced TCP packets with a set SYN flag to produce half-open TCP
connections (SYN flooding attack).
- Packets with the same IP sender address and IP recipient address (Land attack).
- Mass-produced ICMP packets with the broadcast address of a network as target
address (Smurf attack).
- Fragmented IP packets with overlapping offset fields (Teardrop attack).
- ICMP packets that are larger than the maximum permitted size (65,535 Bytes) of
IPv4 packets (Ping-of-death attack).
- Uncorrelated reply packets (i.e. packets which cannot be correlated to any request).
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. section 4.2.6.2.2]
29
Note: This clause may not be applicable for GVNP Type 1.
_________________________________________________________________________________________________________
Section 9: Vulnerability Testing Requirements
2.9.1 Fuzzing – Network and Application Level
Requirement:
It shall be ensured that externally reachable services of AMF are reasonably robust when
receiving unexpected input.

[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. section 4.4.4]
2.9.2 Port Scanning
Requirement:
It shall be ensured that on all network interfaces of AMF, only documented ports on the
transport layer respond to requests from outside the system.
2.9.3 Vulnerability Scanning
Requirement:
The vulnerabilities found during the Vulnerability Scanning/Assessment process shall be
remediated as below. For other than critical vulnerabilities, OEM shall provide remediation
plan.
Sl No CVSS Score Severity Remediation

1 9.0-10.0 Critical To be patched immediately
2 7.0-8.9 High To be patched within a month
3 4.0-6.9 Medium To be patched within three months
4 0.1-3.9 Low To be patched within a year
_________________________________________________________________________________________________________
30
Section 10: Operating System
____________________________________________________________________________________________________
2.10.1 Growing Content Handling
Requirement:
a) Growing or dynamic content shall not influence system functions.
b) A file system that reaches its maximum capacity shall lead to an event getting logged
with appropriate message parameters and shall not stop AMF from operating properly.
Therefore, countermeasures shall be taken to ensure that this scenario is avoided.
________________________________________________________________________________________________________
2.10.2 Handling of ICMP
Requirement:
Processing of ICMPv4 and ICMPv6 packets which are not required for operation shall be
disabled on the AMF.
AMF shall not send certain ICMP types by default but it may support the option to enable
utilization of these types which are marked as "Optional" in below table:
Type Type Description Send Respond to

(IPv4) (IPv6)
0 128 Echo Reply Optional (i.e. as N/A

automatic reply to
"Echo Request")
3 1 Destination Unreachable Permitted N/A
8 129 Echo Request Permitted Optional
11 3 Time Exceeded Optional N/A
12 4 Parameter Problem Permitted N/A
N/A 2 Packet too Big Permitted N/A
N/A 135 Neighbor Solicitation Permitted Permitted
N/A 136 Neighbor Advertisement Permitted N/A
31
AMF shall not respond to, or process (i.e., do changes to configuration) under any
circumstances certain ICMP message types as marked in the below table.
Type Type Description Send Respond to Process

(IPv4) (IPv6) (i.e., do
changes to
configurat
ion)
5 137 Redirect N/A N/A Not

Permitted
13 N/A Timestamp N/A Not N/A

Permitted
14 N/A Timestamp Reply Not Permitted N/A N/A

(i.e. as automatic
reply to
"Timestamp")
N/A 133 Router Solicitation N/A Not Not

Permitted Permitted
N/A 134 Router N/A N/A Not

Advertisement Permitted
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section 4.2.4.1.1.2.]
_________________________________________________________________________________________________________
2.10.3 Authenticated Privilege Escalation only
Requirement:
AMF shall not support a privilege escalation method in interactive sessions (both CLI and
GUI) which allows a user to gain administrator/root privileges from another user account
without re-authentication.
_________________________________________________________________________________________________________
32
2.10.4 System account identification
Requirement:
Each system account in AMF shall have a unique identification.
_________________________________________________________________________________________________________
2.10.5 OS Hardening - Minimized kernel network functions
Requirement:
Kernel-based network functions not needed for the operation of the network element shall
be deactivated. In particular, the following ones shall be disabled by default:
1. IP Packet Forwarding between different interfaces of the network product.

2. Proxy ARP
3. Directed broadcast
4. IPv4 Multicast handling
5. Gratuitous ARP messages
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section - 4.3.3.1.2]
Note: This clause may not be applicable for GVNP Type 1.
_________________________________________________________________________________________________________
2.10.6 No automatic launch of removable media
Requirement:
AMF shall not automatically launch any application when a removable media device is
connected.
Note: This clause may not be applicable for GVNP Type 1 and 2.
_________________________________________________________________________________________________________
33
2.10.7 Protection from buffer overflows
Requirement:
AMF shall support mechanisms for buffer overflow protection. Documentation which
describes these buffer overflow mechanisms and also how to check that they have been
enabled and/or implemented shall be provided by OEM.
_________________________________________________________________________________________________________
2.10.8 External file system mount restrictions
Requirement:
If normal users are allowed to mount external file systems (attached locally or via the
network), OS-level restrictions shall be set properly in AMF in order to prevent privilege
escalation or extended access permissions due to the contents of the mounted file systems.
OS-level restrictions shall apply to normal users against mount / use of removable media
devices (e.g. USB drive, CD ROM etc.) for data transfer.
Note: This clause may not be applicable for GVNP Type 1 and 2.
_________________________________________________________________________________________________________
2.10.9 File-system Authorization privileges
Requirement:
AMF shall be designed to ensure that only users that are authorized to modify files, data,
directories or file systems have the necessary privileges to do so.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section - 4.3.2.7]
_________________________________________________________________________________________________________
2.10.10 SYN Flood Prevention
Requirement:
AMF shall support a mechanism to prevent Syn Flood attacks. This feature shall be enabled
by default.
_________________________________________________________________________________________________________
34
2.10.11 Handling of IP options and extensions
Requirement:
IP packets with unnecessary options or extension headers shall not be processed. IP
options and extension headers (e.g., source routing) are only required in exceptional cases.
So, all packets with enabled IP options or extension headers shall be filtered.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. Section - 4.2.4.1.1.3]
_________________________________________________________________________________________________________
2.10.12 Restrictions on running Scripts / Batch-processes
Requirement:
Scheduled tasks for carrying out the activities such as taking the backups, monitoring disk
space and system maintenance activities shall be executed by the privileged user such as
administrator only. Similarly, AMF shall have feature to restrict Scripts / Batch-processes /
Macros usage among various users. It shall be possible to administratively configure
scheduled tasks usage i.e Cron-Job usage (permit / deny) among various users like Normal
users, privileged users.
2.10.13 Restrictions on Soft-Restart
Requirement:
AMF shall restrict software-based system restart options usage among various users. The
software reset / restart either through command or use of key-combinations like
CTRL+ALT+DEL is not available to normal users for prevention of unintended / malicious
trigger of system reset / restart.
Note: Hardware based restart may not be applicable for GVNP Type 1 and 2.
_________________________________________________________________________________________________________
Section 11: Web Servers
_________________________________________________________________________________________________________
This entire section of the security requirements is applicable if the AMF supports web
management interface.
2.11.1 HTTPS
Requirement:
The communication between Web client and Web server shall be protected strictly using
the Secure cryptographic controls prescribed in Table 1 of the latest document
35
only.
[Ref: TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. section 4.2.5.1]
________________________________________________________________________________________________________
2.11.2 Webserver logging

Requirement:
Access to the AMF webserver (for both successful as well as failed attempts) shall be logged
by AMF.
The web server log shall contain the following information:
- Access timestamp
- Source (IP address)
- Account (if known)
- Attempted login name (if the associated account does not exist)
- Relevant fields in http request. The URL should be included whenever
possible.
- Status code of web server response
_________________________________________________________________________________________________________
2.11.3 HTTPS input validation

Requirement:
The AMF shall have a mechanism in place to ensure that web application inputs are not
vulnerable to command injection or cross-site scripting attacks.
AMF shall validate, filter, escape, and encode user-controllable input before it is placed in
output that is used as a web page that is served to other users.
_________________________________________________________________________________________________________
2.11.4 No system privileges
Requirement:
No AMF web server processes shall run with system privileges.
_________________________________________________________________________________________________________
36
2.11.5 No unused HTTPS methods
Requirement:
HTTPS methods that are not required for AMF operation shall be deactivated.
_________________________________________________________________________________________________________
2.11.6 No unused add-ons
Requirement:
All optional add-ons and components of the web server shall be deactivated if they are not
required for AMF operation.
In particular, CGI or other scripting components, Server Side Includes (SSI), and WebDAV
shall be deactivated if they are not required.
_________________________________________________________________________________________________________
2.11.7 No compiler, interpreter, or shell via CGI or other server-side scripting

Requirement:
If CGI (Common Gateway Interface) or other scripting technology is used, the CGI directory or
other corresponding scripting directory shall not include compilers or interpreters.
_________________________________________________________________________________________________________
2.11.8 No CGI or other scripting for uploads

Requirement:
If CGI or other scripting technology is used, the associated CGI/script directory shall not be
used for uploads.
_________________________________________________________________________________________________________
2.11.9 No execution of system commands with SSI

Requirement:
If Server Side Includes (SSI) is active, the execution of system commands shall be
deactivated.
_________________________________________________________________________________________________________
37
2.11.10 Access rights for web server configuration
Requirement:
Access rights for AMF web server configuration files shall only be granted to the owner of
the web server process or to a user with system privileges.
_________________________________________________________________________________________________________
2.11.11 No default content
Requirement:
Default content that is provided with the standard installation of the AMF web server shall
be removed.
_________________________________________________________________________________________________________
2.11.12 No directory listings
Requirement:
Directory listings (indexing) / "Directory browsing" shall be deactivated.
2.11.13 Web server information in HTTPS headers
Requirement:
The HTTPS header shall not include information on the version of the AMF web server and
the modules/add-ons used.
2.11.14 Web server information in error pages
Requirement:
User-defined error pages and Error messages shall not include version information and
other internal information about the AMF web server and the modules/add-ons used.
38
Default error pages of the AMF web server shall be replaced by error pages defined by the
OEM.
2.11.15 Minimized file type mappings
Requirement:
File type or script-mappings that are not required for AMF operation shall be deleted.
_________________________________________________________________________________________________________
2.11.16 Restricted file access
Requirement:
Restrictive access rights shall be assigned to all files which are directly or indirectly reside
in the AMF web server's document directory.
In particular, the AMF web server shall not be able to access files which are not meant to be
delivered.
2.11.17 Execute rights exclusive for CGI/Scripting directory
Requirement:
If CGI or other scripting technology is used, only the CGI/Scripting directory is configured
with execute rights. Other directories used or meant for web content do not have execute
rights.
_________________________________________________________________________________________________________
2.11.18 HTTP User session
Requirement:
To protect user sessions, AMF shall support the following session ID and session cookie
requirements:
1. The session ID shall uniquely identify the user and distinguish the session from all other
active sessions.
2.The session ID shall be unpredictable.
39
3.The session ID shall not contain sensitive information in clear text (e.g., account number,
social security, etc.).
4.In addition to the Session Idle Timeout, AMF shall automatically terminate sessions after
a configurable maximum lifetime. This maximum lifetime defines the maximum session
span. When the maximum lifetime expires, the session shall be closed, the session ID shall
be deleted and the user shall be forced to (re)authenticate in the web application and to
establish a new session. The default value for this maximum lifetime shall be set to 8 hours.
5.Session IDs shall be regenerated for each new session (e.g., each time a user logs in).
6.The session ID shall not be reused or renewed in subsequent sessions.
7.The AMF shall not use persistent cookies to manage sessions but only session cookies.
This means that neither the "expire" nor the "max-age" attribute shall be set in the cookies.
8.Where session cookies are used the attribute 'HttpOnly' shall be set to true.
9.Where session cookies are used the 'domain' attribute shall be set to ensure that the
cookie can only be sent to the specified domain.
10.Where session cookies are used the 'path' attribute shall be set to ensure that the cookie
can only be sent to the specified directory or sub-directory.
11.The AMF shall not accept session identifiers from GET/POST variables.
12.The AMF shall be configured to only accept server generated session ID.
_________________________________________________________________________________________________________
Section 12: General SBA/SBI Aspects
_________________________________________________________________________________________________________
This general baseline requirements are applicable to all Network Function (NF) within the
5G Core (5GC) utilizing Service-Based Interfaces (SBI), independent of a specific network
product class.
2.12.1 No code execution or inclusion of external resources by JSON parsers
Requirement:
Parsers used by Network Functions (NF) shall not execute JavaScript or any other code
contained in JSON objects received on Service Based Interfaces (SBI). Further, these parsers
shall not include any resources external to the received JSON object itself, such as files from
the NF’s filesystem or other resources loaded externally.
_________________________________________________________________________________________________________
40
2.12.2 Validation of the unique key values in IEs
Requirement:
For data structures where values are accessible using names (sometimes referred to as
keys), e.g. a JSON object, the name shall be unique. The occurrence of the same name (or
key) twice within such a structure shall be an error and the message shall be rejected.
_________________________________________________________________________________________________________
2.12.3 Validation of the IEs limits
Requirement:
The valid format and range of values for each IE, when applicable, shall be defined
unambiguously:
- For each message the number of leaf IEs shall not exceed 16000.
- The maximum size of the JSON body of any HTTP request shall not exceed 16 million
bytes.
- The maximum nesting depth of leaves shall not exceed 32.
_________________________________________________________________________________________________________
2.12.4 Protection at the transport layer
Requirement:
NF Service Request and Response procedure shall support mutual authentication between
NF consumer and NF producer.
All network functions shall support TLS. Network functions shall support both server-side
and client-side certificates.
Authentication between network functions within one PLMN can use the following method:
- If the PLMN uses protection at the transport layer, authentication provided by the
transport layer protection solution shall be used for authentication between NFs.
Note: This may not be applicable for UPF and N3IWF.

_________________________________________________________________________________________________________
41
2.12.5 Authorization token verification failure handling within one PLMN
Requirement:
The NF Service producer shall verify the access token as follows:
- The NF Service producer ensures the integrity of the access token by verifying the
signature using NRF’s public key or checking the MAC value using the shared secret. If
integrity check is successful, the NF Service producer shall verify the claims in the access
token as follows: - It checks that the audience claim in the access token matches its own
identity or the type of NF service producer. If a list of NSSAIs or list of NSI IDs is present,
the NF service producer shall check that it serves the corresponding slice(s).
- If an NF Set ID is present, the NF Service Producer shall check the NF Set ID in the claim
matches its own NF Set ID.
- If the access token contains "additional scope" information (i.e. allowed resources and
allowed actions (service operations) on the resources), it checks that the additional scope
matches the requested service operation.
- If scope is present, it checks that the scope matches the requested service operation.
- It checks that the access token has not expired by verifying the expiration time in the
access token against the current data/time.
If the verification is successful, the NF Service producer shall execute the requested service
and respond back to the NF Service consumer. Otherwise, it shall reply based on the Oauth
2.0 error response defined in RFC 6749. The NF service consumer may store the received
token(s). Stored tokens may be re-used for accessing service(s) from producer NF type
listed in claims (scope, audience) during their validity time.
Note: This may not be applicable for UPF and SEPP.

_________________________________________________________________________________________________________
2.12.6 Authorization token verification failure handling in different PLMNs
Requirement:
The NF service producer shall check that the home PLMN ID of the audience claimed in the
access token matches its own PLMN identity.
Note: This may be applicable for SEPP.
42
_________________________________________________________________________________________________________
Section 13: Other Security requirements
2.13.1 Remote Diagnostic Procedure – Verification

Requirement:
If the AMF is providing Remote access for troubleshooting purposes/alarm maintenance
then it shall be allowed only for authorized users, other than the root user.
All activities performed by the remote user are to be logged with the following parameters:
1. User id
2. Time stamp
3. Interface type
4. Event level (e.g. CRITICAL, MAJOR, MINOR)
5. Command/activity performed
6. Result type (e.g. SUCCESS, FAILURE).
7. IP Address of remote machine
_________________________________________________________________________________________________________
2.13.2 No System Password Recovery
Requirement:
No provision shall exist for AMF System / Root password recovery.
2.13.3 Secure System Software Revocation

Requirement:
Once the AMF software image is legally updated/upgraded with New Software Image, it
shall normally not be possible to roll back to a previous software image. In case roll back is
essential, it shall be done by the administrator with appropriate non-repudiation controls.
AMF shall support a well-established control mechanism for rolling back to previous
software image.
43
2.13.4 Software Integrity Check –Installation
Requirement:
AMF shall validate the software package integrity before the installation stage strictly using
the Secure cryptographic controls prescribed in Table 1 of the latest document
only.
Tampered software shall not be executed or installed if integrity check fails.
2.13.5 Software Integrity Check – Boot

Requirement:
The AMF shall verify the integrity of a software component by comparing the result of a
measurement of the component, typically a standard cryptographic hash generated strictly
using the Secure cryptographic controls prescribed in Table 1 of the latest document
“Cryptographic Controls For Indian Telecom Security Assurance Requirements (ITSAR)” to
the expected reference value.
Note: This may not be applicable for GVNP Type 1 and Type 2.
_________________________________________________________________________________________________________
2.13. 6 Unused Physical and Logical Interfaces Disabling
Requirement:
AMF shall support the mechanism to verify both the physical and logical interfaces exist in
the product.
Physical and logical accessible interfaces (except console interface) which are not under
use shall be disabled so that they remain inactive even in the event of reboot.
Note: This may not be applicable for GVNP Type 1 and Type 2.
2.13.7 No Default Profile

Requirement:
Predefined or default user accounts (other than Admin/Root) in AMF shall be deleted or
disabled.
________________________________________________________________________________________________________
44
Chapter 3 – Specific Security Requirements
________________________________________________________________________________________________________
Section 1: Authentication and Key Agreement Procedure
_________________________________________________________________________________________________________
3.1.1 Synchronization failure handling
Requirement:
Upon receiving an authentication failure message with synchronization failure (AUTS)
from the UE, the SEAF sends an Nausf_UEAuthentication_Authenticate Request message
with a "synchronization failure indication" to the AUSF.
An SEAF will not react to unsolicited "synchronization failure indication" messages from
the UE. The SEAF does not send new authentication requests to the UE before having
received the response to its Nausf_UEAuthentication_Authenticate Request message with a
"synchronization failure indication" from the AUSF (or before it is timed out).
[Ref: TEC 25880:2022 / TSDSI STD T1.3GPP 33.512 V.16.6.0 Section 4.2.2.1.1]
_________________________________________________________________________________________________________
3.1.2 RES* verification failure handling
Requirement:
The SEAF shall proceed by sending RES*, as received from the UE, in a
Nausf_UEAuthentication_Authenticate Request to AUSF and after receiving the
Nausf_UEAuthentication_Authenticate Response message from the AUSF, it will proceed as
described below:
- If the AUSF has indicated in the Nausf_UEAuthentication_Authenticate Response message

to the SEAF that the verification of the RES* was not successful in the AUSF, or
- if the verification of the RES* was not successful in the SEAF, then the SEAF shall either
reject the authentication by sending an Authentication Reject to the UE if the SUCI was used
by the UE in the initial NAS message or the SEAF/AMF shall initiate an Identification
procedure with the UE if the 5G-GUTI was used by the UE in the initial NAS message to
retrieve the SUCI and an additional authentication aAMFmpt may be initiated.
Also, if the SEAF does not receive any Nausf_UEAuthentication_Authenticate Request
message from the AUSF as expected, then the SEAF shall either reject the authentication to
45
the UE or initiate an Identification procedure with the UE.
[Ref: TEC 25880:2022 / TSDSI STD T1.3GPP 33.512 -16.6.0 V.1.0.0 Section 4.2.2.1.2]
_________________________________________________________________________________________________________
Section 2: Security mode command procedure

_________________________________________________________________________________________________________
3.2.1 Replay protection of NAS signaling messages
Requirement:
AMF shall support integrity protection and replay protection of NAS signaling messages
between UE and AMF on the N1 interface.
[Ref: TEC 25880:2022 / TSDSI STD T1.3GPP 33.512 -16.6.0 V.1.0.0 section 4.2.2.3.1]
_________________________________________________________________________________________________________
3.2.2 NAS NULL integrity protection
Requirement:
NIA0(null security algorithm) shall be disabled in AMF in the deployments where support
of unauthenticated emergency sessions is not a regulatory requirement.
________________________________________________________________________________________________________
3.2.3 NAS integrity algorithm selection and use
Requirement:
The AMF shall then initiate a NAS security mode command procedure, and include the
chosen algorithm and UE security capabilities (to detect modification of the UE security
capabilities by an attacker) in the message to the UE. The AMF shall select the NAS
algorithm which has the highest priority according to the ordered lists.
_________________________________________________________________________________________________________
46
Section 3: Security in intra-RAT mobility
_________________________________________________________________________________________________________
3.3.1 Bidding down prevention in Xn-handover
Requirement:
In the Path-Switch message, the target gNB/ng-eNB shall send the UE's 5G security
capabilities received from the source gNB/ng-eNB to the AMF. The AMF shall verify that
the UE's 5G security capabilities received from the target gNB/ng-eNB are the same as the
UE's 5G security capabilities that the AMF has locally stored. If there is a mismatch, the
AMF shall send its locally stored 5G security capabilities of the UE to the target gNB/ng-
eNB in the Path-Switch Acknowledgement message. The AMF shall support logging
capabilities for this event and may take additional measures, such as raising an alarm.
_________________________________________________________________________________________________________
3.3.2 NAS protection algorithm selection in AMF change
Requirement:
If the change of the AMF at N2-Handover or mobility registration update results in the
change of algorithm to be used for establishing NAS security, the target AMF shall indicate
the selected algorithm to the UE for N2-Handover (i.e., using NAS Container) and for
mobility registration update (i.e., using NAS SMC). The AMF shall select the NAS algorithm
which has the highest priority according to the ordered lists.
________________________________________________________________________________________________________
Section 4: 5G-GUTI allocation
_________________________________________________________________________________________________________
3.4.1 5G-GUTI allocation
Requirement:
A new 5G-GUTI shall be sent to a UE only after a successful activation of NAS security.
Upon receiving a Registration Request message of type "initial registration" or "mobility
registration update" from a UE, the AMF shall send a new 5G-GUTI to the UE during the
registration procedure.
47
Upon receiving a Registration Request message of type "periodic registration update" from
a UE, the AMF should send a new 5G-GUTI to the UE during the registration procedure.
Upon receiving Service Request messages sent by the UE in response to a Paging message,
the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent before the
current NAS signaling connection is released or the N1 NAS signaling connection is
suspended.
Upon receiving an indication from the lower layers that the RRC connection has been
resumed for a UE in 5GMM-IDLE mode with suspend indication in response to a Paging
message, the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent
before the current NAS signaling connection is released or the suspension of the N1 NAS
signaling connection.
_________________________________________________________________________________________________________
Section 5: Security in registration procedure
_________________________________________________________________________________________________________
3.5.1 Invalid or unacceptable UE security capabilities handling
Requirement:
If the REGISTRATION REQUEST message is received with invalid or unacceptable UE
security capabilities (e.g. no 5GS encryption algorithms (all bits zero), no 5GS integrity
algorithms (all bits zero), mandatory 5GS encryption algorithms not supported or
mandatory 5GS integrity algorithms not supported, etc.), the AMF shall return a
REGISTRATION REJECT message.
_________________________________________________________________________________________________________
48
Annexure-I (Definition)
1. AUSF: AUSF is a network function with which SEAF and UDM interact during the
authentication of UE.
2. DDOS: DDoS is a distributed denial-of-service attack that renders the victim un-
usable by the external environment.
3. GUTI: The purpose of the GUTI is to provide an unambiguous identification of the UE
that does not reveal the UE or the user's permanent identity.
4. Generic Network Product: Generic Network Product (GNP) model as defined in
Section 4.1 and 4.3 of TSDSI RPT T1.3GPP 33.926-16.4.0 V1.0.0
5. Generic virtualized network product model (GVNP) Type 1: GVNP Model as defined
in Section 5.2.3 of TSDSI RPT T1.3GPP 33.818-17.1.0 V1.0.0
6. Generic virtualized network product model (GVNP)Type 2: GVNP Model as defined
7. Generic virtualized network product model (GVNP)Type 3: GVNP Model as defined
8. Downlink: Unidirectional radio link for the transmission of signals from a RAN
access point to a UE. Also, in general the direction from Network to UE.
9. Identifiable person: one who can be identified, directly or indirectly, in particular by
reference to an identification number, name or to one or more factors specific to his
physical, physiological, mental, economic, cultural or social identity. NOTE: personal
data can be gathered from user data and traffic data.
10. Local access: The access from Console interface, from local Console network, from
LMT (Local Maintenance Terminal interface) or from GNP’/NE’s local hardware
interface.
11. Local logical interface: It is an interface that can be used only via physical
connection to the GNP. That is, the connection requires physical access to the GNP.
The entire protocol stack is considered to be part of the local logical interface. The
entire protocol stack and the physical parts of the interface can be used by local
connections.
Local Logical Interfaces also include the local hardware interfaces and the Local
Maintenance Terminal interface (LMT) of the GNP used for its maintenance through
a console. i.e Local logical interface include OAM local console, LMT (Local
Maintenance Terminal) interface and GNP local hardware interfaces. Attaching to a
local interface may cause execution of complex internal procedures in the GNP like
loading USB device drivers, enumeration of attached devices, mounting file systems
etc.
49
12. Machine Accounts: These will be used for authentication and authorization from
system to system or between applications on a system and cannot be assigned to a
single person or a group of persons.
13. Medium Access Control: A sub-layer of radio interface layer 2 providing
unacknowledged data transfer service on logical channels and access to transport
channels.
14. Mobility: The ability for the user to communicate whilst moving independent of
location.
15. Network Element: A discrete telecommunications entity which can be managed over
a specific interface e.g. the RNC
16. NG-RAN: It is the radio access network introduced for accessing 5G.
17. Node B: A logical node responsible for radio transmission / reception in one or
more cells to/from the User Equipment. Terminates the Iub interface towards the
RNC.
18. Non-Access Stratum: Protocols between UE and the core network that are not
terminated in the RAN.
19. Original Equipment Manufacturer (OEM): manufacturer of communication and its
related products under whose brand, the products are sold or proposed to be sold to
operators in the country.
20. Packet: An information unit identified by a label at layer 3 of the OSI reference
model. A network protocol data unit (NPDU).
21. Personal data: any information relating to an identified or identifiable natural
person ('data subject'). NOTE: personal data can be gathered from user data and
traffic data.
22. PLMN Area: The PLMN area is the geographical area in which a PLMN provides
communication services according to the specifications to mobile users. In the
PLMN area, the mobile user can set up calls to a user of a terminating network. The
terminating network may be a fixed network, the same PLMN, another PLMN or
other types of PLMN. Terminating network users can also set up calls to the PLMN.
The PLMN area is allocated to a PLMN. It is determined by the service and network
provider in accordance with any provisions laid down under national law. In general
the PLMN area is restricted to one country. It can also be determined differently,
depending on the different telecommunication services, or type of MS. If there are
several PLMNs in one country, their PLMN areas may overlap. In border areas, the
PLMN areas of different countries may overlap. Administrations will have to take
precautions to ensure that cross border coverage is minimized in adjacent countries
unless otherwise agreed.
23. PLMN Operator: Public Land Mobile Network operator. The entity which offers
telecommunications services over an air interface.
50
24. Protocol data unit: In the reference model for OSI, a unit of data specified in an (N)-
protocol layer and consisting of (N)-protocol control information and possibly (N)-
user data.
25. Protocol: A formal set of procedures that are adopted to ensure communication
between two or more functions within the same layer of a hierarchy of functions.
26. QoS profile: a QoS profile comprises a number of QoS parameters. A QoS profile is
associated with each QoS session. The QoS profile defines the performance
expectations placed on the bearer network.
27. QoS session: Lifetime of PDP context. The period between the opening and closing of
a network connection whose characteristics are defined by a QoS profile. Multiple
QoS sessions may exist, each with a different QoS profile.
28. Quality of Service: The collective effect of service performances which determine the
degree of satisfaction of a user of a service. It is characterized by the combined
aspects of performance factors applicable to all services, such as;
- service operability performance;
- service accessibility performance;
- service retainability performance;
- service integrity performance; and
- other factors specific to each service.
29. Radio link: A "radio link" is a logical association between single User Equipment and
a single RAN access point. Its physical realization comprises one or more radio
bearer transmissions.
30. Radio Resource Control: A sublayer of radio interface Layer 3 existing in the control
plane only which provides information transfer service to the non-access stratum.
RRC is responsible for controlling the configuration of radio interface Layers 1 and
2.
31. Registered PLMN (RPLMN): This is the PLMN on which the UE has performed a
location registration successfully.
32. Registration Area: A (NAS) registration area is an area in which the UE may roam
without a need to perform location registration, which is a NAS procedure.
33. Remote Access: The access which is not Local access. This includes access from the
EMS (Element Management System) network, and access that originates or passes
through the internet.
34. RRC Connection: A point-to-point bi-directional connection between RRC peer
entities on the UE and the UTRAN sides, respectively. An UE has either zero or one
RRC connection.
35. SEAF is an entity which is subsumed by AMF which communicates with UE and
AUSF during device authentication.
36. Security: The ability to prevent fraud as well as the protection of information
availability, integrity, and confidentiality.
51
37. Sensitive data: data that may be used for authentication or may help to identify the
user, such as user names, passwords, PINs, cryptographic keys, IMSIs, IMEIs,
MSISDNs, or IP addresses of the UE, as well as files of a system that are needed for
the functionality such as firmware images, patches, drivers or kernel modules.
38. Serving Network: The serving network provides the user with access to the services
of the home environment.
39. Software refers to the programs and data components which are usually stored on
erasable media (e.g., disk), that can be dynamically written and modified during
execution. Two general categories of software are system software and application
software.
40. Subscriber: The responsibility for payment of charges incurred by one or more
users may be undertaken by another entity designated as a subscriber. This division
between use of and payment for services has no impact on standardization
41. Transmission or Transport is the transfer of information from one entity
(transmitter) to another (receiver) via a communication path.
42. Universal Subscriber Identity Module (USIM): An application residing on the UICC
used for accessing services provided by mobile networks, which the application is
able to register on with the appropriate security.
43. Uplink: An "uplink" is a unidirectional radio link for the transmission of signals from
a UE to a base station.
44. User Equipment: A device allowing a user access to network services. The interface
between the UE and the network is the radio interface. A User Equipment can be
subdivided into a number of domains, the domains being separated by reference
points.
52
Annexure-II(Acronyms)
5GC - 5G Core Network

5GMM - 5GS Mobility Management
5GS - 5G System
5GSM - 5G Session Management
AF - Application Function
AKA - Authentication and Key Agreement
AKA’ - AKA Prime
AKMA - Authentication and key management for applications
ARP - Address Resolution Protocol/Allocation and Retention Priority
ARPF - Authentication Credential Repository and Processing Function
AS - Access Stratum
ATSSS - Access Traffic Steering, Switching, Splitting
AUSF - Authentication Server Function
AUTS - Authentication failure message with synchronization failure
BSF - Binding Support Function
CHF - Charging Function
CIoT - Cellular Internet of things
CLI - Command Line Interface
CM - Connection Management
CP - Control Plane
CVE - Common Vulnerabilities and Exposures
CWE - Common Weakness Enumeration
CVSS - Common Vulnerability Scoring System
DCCF - Data Collection Coordination Function
DDoS - Distributed Denial of Service
DL - Downlink
DN - Data Network
DNN - Data Network Name
DS-TT - Device Side TSN Translator
DTLS - Datagram Transport Layer Security
EAP - Extensible Authentication Protocol
EASDF - Edge Application Server Discovery Function
ECS - EDNS Client Subnet
EDNS - Extension Mechanism for DNS
EMM - EPS Mobility Management
EPC - Evolved Packet Core
53
EPS - Evolved Packet System
F-TEID - Fully Qualified Tunnel Endpoint Identifier
FQDN - Fully Qualified Domain Name
gNB - 5G Next Generation base station
GNP - Generalized Network Product
GTP-C - GPRS Tunneling Protocol Control Plane
GTP-U - GPRS Tunneling Protocol User Plane
GUI - Graphical User Interface
GUTI - Globally Unique Temporary Identifier
GVNP - Generalized Virtual Network Product
HTTP - Hypertext Transfer Protocol
HTTPS - Hypertext Transfer Protocol Secure
ICMP - Internet Control Message Protocol
IE - Information Element
IMS - IP Multimedia Subsystem
IMPI - IMS Private Identity
IMPU - IMS Public Identity
IP - Internet Protocol
IPUPS - Inter-PLMN User Plane Security
IPX - IP exchange
ISO-OSI - International organization of Standardization – Open System
Interconnection
JSON - JavaScript Object Notation
JWS - JSON Web Signature
JWT - JSON Web Token
LBO - Local Breakout
LMF - Location Management Function
MA PDU - Multiple Access PDU
MFAF - Messaging Framework Adaptor Function
ML - Machine Learning
N3IWF - Non-3GPP Interworking Function
NAS - Non-Access Stratum
NEF - Network Exposure Function
NF - Network Function
NG - Next Generation
ng-eNB - Next Generation e-NodeB
NG-RAN - Next Generation Radio Access Network
NRF - Network Repository Function
NSAC - Network Slice Admission Control
NVD - National Vulnerability Database
54
NWDAF - Network Data Analytics Function
NW-TT - Network -side TSN Translator
O&M - Operations and Maintenance
OAM - Operations Administration Maintenance
OS - Operating System
PCF - Policy Control Function
PDR - Packet Detection Rule
PDU - Protocol Data Unit
PFCP - Packet Forwarding Control Protocol
PFD - Packet Flow Descriptor
PLMN - Public Land Mobile Network
PRINS - Protocol for N32 Interconnect Security
PSA - PDU Session Anchor
QoS - Quality of Service
RAM - Random Access Memory
RAN - Radio Access Network
RAT - Radio Access Technology
RES - Response
REST - Representational State Transfer
RFC - Request For Comments
RM - Registration Management
RRC - Radio Resource Control
S-NSSAI - Single - Network Slice Selection Assistance Information
SBI - Service Based Interfaces
SCP - Service Communication Proxy
SDF - Service Data Flow
SEAF - Security Anchor Function
SEPP - Security Edge Protection Proxy
SIDF - Subscription Identifier De-concealing Function
SMF - Session Management Function
SNPN - Stand Alone Non-Public Network
SSC - Session and Service Continuity
SUCI - Subscription Concealed Identifier
SUPI - Subscription Permanent Identifier
TA - Tracking Area
TNGF - Trusted Non-3GPP Gateway Function
TSC - Time Sensitive Communication
TSN - Time Sensitive Networking
TSTL - Telecom Security Testing Laboratory
TT function - TSN Translator Function
55
UDM - Unified Data Management
UDR - Unified Data Repository
UE - User Equipment
UL - Uplink
UPF - User Plane Function
URI - Uniform Resource Identifier
URL - Uniform Resource Locator
URLLC - Ultra Reliable Low Latency Communication
VN - Virtual Network
WLAN - Wireless Local Area Network
56
Annexure-III (List of Submissions)
1. Source Code Security Assurance (against test case 2.3.3)
2. Known Malware and backdoor Check (against test case 2.3.4)
3. No unused Software (against test case 2.3.5)
4. Communication matrix (against test case 2.3.6)
5. No Unused Functions (against test case 2.4.1)
6. Avoidance of Unspecified Wireless Access (against test case 2.4.3)
7. Cryptographic Based Secure Communication (against test case 2.6.1)
8. Cryptographic Module Security Assurance (against test case 2.6.2)
9. Cryptographic Algorithms implementation Security Assurance (against test case
2.6.3)
10. Vulnerability Scanning-Remediation Plan (against test case 2.9.3)
57
Annexure-IV (References)
1. TEC 25848:2022 / TSDSI STD T1.3GPP 33.117-16.7.0 V.1.0.0. "Catalogue of General

Security Assurance Requirements".
2. TEC 25880:2022 / TSDSI STD T1.3GPP 33.512 -16.6.0 V.1.0.0 5G Security Assurance
Specification (SCAS), Access and Mobility management Function (AMF).
3. TEC 25878:2022 / TSDSI STD T1.3GPP 33.501-16.9.0 V.1.0.0 Security architecture
and procedures for 5G System
4. RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2)
5. RFC 7515 JSON Web Signature (JWS)
6. RFC 7519 JSON Web Token (JWT)
7. RFC 6749 The OAuth 2.0 Authorization Framework
-End of Document-
58

Amf 5G

Uploaded by

Copyright:

Available Formats

Amf 5G

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Amf 5G

Uploaded by

Copyright:

Available Formats

Indian Telecommunication Security Assurance Requirements (ITSAR)

Access and Mobility Management Function (AMF) of 5G

Release Date: Version: 1.0.0

Security Assurance Standards Facility

Sl. No ITSAR Reference Title Remarks

The specifications produced by various regional/ international standardization bodies/

Remote Access regulations are governed by Licensing Wing of DoT.

Introduction: The fifth generation of mobile technologies - 5G - is expected to connect

5G Architecture: The generic 5G system (5GS) architecture consists of User Equipment,

The salient features of 5G Core are

1) Separation of user plane and control plane

Figure 1: Roaming 5G System architecture- local breakout scenario

As shown in Figure 1, AMF is connected to UE with the N1 interface. N1 interface messages

AMF Security: TEC 25878:2022/TSDSI STD T1.3GPP 33.501-16.9.0 V1.0.0 includes

2.1.1 Management Protocols Mutual Authentication

Secure cryptographic controls prescribed in Table 1 of the latest document “Cryptographic

2.1.2 Management Traffic Protection

2.1.3 Role-based access control policy

2.1.4. User Authentication – Local/Remote

Authentication attributes include

2.1.5 Remote login restrictions for privileged users

2.1.6 Authorization Policy

2.1.7 Unambiguous identification of the user & group accounts removal

2.2.1 Authentication Policy

2.2.2 Authentication Support – External

2.2.3 Protection against brute force and dictionary attacks

2.2.4 Enforce Strong Password

2.2.5 Inactive Session timeout

2.2.6 Password Changes

The number of disallowed previously used passwords shall be:

AMF to have in-built mechanism to support this requirement.

2.2.7 Protected Authentication feedback

2.2.8 Removal of predefined or default authentication attributes

2.2.9 Logout function

2.3.3 Source code security assurance

2.3.4 Known Malware and backdoor Check

2.3.5 No unused software

2.3.6 Unnecessary Services Removal

2.3.7 Restricting System Boot Source

2.3.8 Secure Time Synchronization

2.3.9 Restricted reachability of services

2.3.10 Self Testing

2.4.1 No unused functions

2.4.2 No unsupported components

regard shall be given by OEM.

2.4.3 Avoidance of Unspecified mode of Access

2.5.1 Audit trail storage and protection

2.5.2 Audit Event Generation

2.5.3 Secure Log Export

2.5.4 Logging access to personal data

2.6.1 Cryptographic Based Secure Communication

2.6.2 Cryptographic Module Security Assurance

Till further instructions, this clause will be considered ‘complied’ by submission of an

An undertaking is to be submitted by the OEM mentioning that “Cryptographic module

2.6.3. Cryptographic Algorithms implementation Security Assurance

An undertaking is to be submitted by the OEM mentioning that “Cryptographic algorithms

2.6.4. Protecting data and information – Confidential System Internal Data

2.6.5. Protecting data and information in storage

b) In addition, the following rules apply for: