GSM Association Non-confidential

Official Document FS.34 - Key Management for 4G and 5G inter-PMN Security

Key Management for 4G and 5G inter-PMN Security

Version 5.0
19 October 2022

This is a Non-binding Permanent Reference Document of the GSMA

Security Classification: Non-confidential

Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is subject to
copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be
disclosed or in any other way made available, in whole or in part, to persons other than those permitted under the security classification without
the prior written approval of the Association.

Copyright Notice
Copyright © 2022 GSM Association

Disclaimer
The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept
any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document.
The information contained in this document may be subject to change without prior notice.

Compliance Notice
The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy.

This Permanent Reference Document is classified by GSMA as an Industry Specification, as such it has been developed and is maintained by
GSMA in accordance with the provisions set out in GSMA AA.35 - Procedures for Industry Specifications.

V5.0 Page 1 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Table of Contents
1 Introduction 4
1.1 Overview 4
1.2 Scope 4
1.3 Definitions 5
1.4 Abbreviations 5
1.5 References 6
1.6 Conventions 7
2 Key Management Principles 7
2.1 Cryptographic Keys 7
2.2 Certificates 8
2.3 Trust relationships between interconnection partners 8
2.4 Certification Authorities 9
2.5 Manual Exchange of Certificates 10
3 Key Management and Processing Details 11
3.1 Certificate Hierarchy 11
3.1.1 Certificate Hierarchy when an entity runs own CA 12
3.1.2 Certificate Hierarchy when 3rd party runs CA 13
3.2 Certificate Verification 14
3.3 Certification Authority requirements 15
4 Exchange Procedures 15
4.1 Responsibilities 15
4.2 Prerequisites 16
4.3 Determine Certificates to be Exchanged 16
4.4 Certificate Management Procedures 16
4.4.1 Certificate Exchange Procedure 16
4.4.2 Certificate Revocation 18
4.4.3 CA certificate renewal procedure 19
4.4.4 Non-CA (Intermediate or Leaf) certificate renewal procedure 19
4.5 Certificate exchange specifically for DESS Phase 1 19
4.5.1 Certificate exchange between MNO and own IPX provider 20
4.5.2 Leaf Certificate exchange between MNOs 20
4.5.3 Peer MNO Certificate exchange between an MNO and its own IPX
provider 21
4.5.4 DESS Phase 1 functionality delegation 21
5 Naming Scheme 21
5.1 SEPP 22
5.1.1 MNO SEPP 22
5.1.2 Non-MNO SEPP 22
5.2 DESS Phase 1 related entities 23
5.2.1 MNO DESS Phase 1 equipment 23
5.2.2 IPX provider intermediate signing DESS Phase 1 equipment 23
5.2.3 IPX provider security delegation DESS Phase 1 equipment 24

Page 2 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

5.3 N9 operator-to-operator security 24

Annex A Public Key Infrastructure (PKI) 25
A.1 Introduction to PKI 25
A.2 Example PKI using EJBCA 25
Annex B Example certificates 27
B.1 Root Certificates 27
B.1.1 MNO Root Certificate: 27
B.1.2 IPX entity Root Certificate 28
B.2 Leaf certificates 29
B.2.1 MNO SEPP certificate issued by MNO 29
B.2.2 MNO SEPP certificate issued by IPX entity 30
B.2.3 Outsourced SEPP certificate issued by MNO 31
B.2.4 Outsourced SEPP or MNO Group SEPP certificate issued by IPX entity 32
Annex C Document Management 33
C.1 Document History 33
C.2 Other Information 33

Page 3 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

1 Introduction

1.1 Overview
For 5G Security Edge Protection Proxy (SEPP) interconnect security and for 4G Diameter
interconnect security, a key management solution is required.

Both 5G inter-PMN roaming security (as defined in 3GPP TS 33.501 ‎[1]) and 4G roaming
inter-PMN security (as defined in GSMA PRD FS.19 ‎[2]) require cryptographic keys to
achieve peer authentication, message integrity and confidential communication. These
cryptographic keys need to be managed and exchanged between stakeholders involved in
roaming.

Key management in the context of this document refers to the process and technology used
by mobile network operators (MNOs) and IPX providers to exchange their certificates, and
how the trust relations are established between interconnect partners.

A solution in two stages is proposed for the introduction of key management for interconnect
security:

 Stage 1: Light solution (mainly based on a manual exchange of certificates)

 Stage 2: Key management with enhanced scalability (e.g. DNSSec or other technical
approach to be selected)

This document describes the stage 1 solution only. The stage 2 solution is under
development and will be described in a later version of this document.

The stage 1 solution is meant to be used for early 5G roaming agreements and 4G LTE
roaming with Diameter end-to-end security measures as described in FS.19, Annex D and
Annex E ‎[2]. This includes:

 DESS Phase 1: Authentication and integrity protection by introducing digital

signatures on inter-PMN Diameter signalling messages.
 N9 operator-to-operator security: inter-PMN user plane protection with NDS/IP as per
3GPP Release 16 TS 33.501 ‎[1].

As soon as the full stage 2 solution is defined, implemented and widely rolled-out, the stage
2 solution is expected to eventually replace the stage 1 solution. All security requirements,
technical functionality and certificate handling aspects also apply to stage 2. Stage 1 is a
preparatory step for stage 2. The main difference is that in stage 2, certain manual tasks will
be automated.

Although the key management procedures strive for a uniform procedure between 5G and
LTE roaming, technical limitations prescribe a slightly different procedure for DESS Phase 1.

1.2 Scope
This document describes the key management process, i.e. the exchange of certificates and
key materials that are used between the interconnect parties to secure the inter-PMN
communication.

Page 4 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

This document does not describe the technical details of the protection of the inter-PMN
communication. Related technical specifications are listed in section ‎1.5.

Although this document mentions the possibility of outsourcing or delegating the inter-PMN
security (section ‎4.1), the details of such an approach will be described in a later version of
this document.

1.3 Definitions
Term Description
A certificate signing request (CSR) is a request sent to a CA by an entity
Certificate signing
that wishes to obtain a certificate from that CA. The CSR contains the
request
entity’s public key and unique identifier.
An entity that verifies the identity of another entity and issues a certificate
that confirms the identity of this other entity by binding its public key to a
unique identifier. Cryptographic algorithms are used by the certification
Certification authority
authority (CA) to perform its tasks and to allow recipients of the certificates
to verify the certificates’ validity. There is a hierarchy of CAs. Details of the
role of a certification authority are described in this document.
Certificate which is in the middle of a chain of trust. The certificate is
Intermediate
typically signed by a CA or by another intermediate certificate. Intermediate
certificate / Sub CA
certificates can be used to sign leaf certificates or other intermediate
certificate
certificates.
Issuer certificate/ CA The term “issuer certificate” is used in this document to refer to a root CA
certificate certificate or an intermediate CA certificate.
End entity certificate, e.g. an individual certificate for network equipment.
Examples of such certificates are individual certificates for SEPP, Diameter
Leaf certificate
Edge Agent (DEA)/signalling firewall (SigFW), IPX providers’ network
equipment, etc.
Root CA A root CA is a CA at the topmost position of the hierarchy of CAs.
Sub CA/ intermediate A subordinate CA (also known as Sub CA or intermediate CA) is a CA at
CA one or more levels below the root CA in the hierarchy of CAs.

1.4 Abbreviations
Term Description
5GMRR 5G Mobile Roaming Revisited (GSMA cross-working group activity)
5GS 5G System
AVP Attribute Value Pair
CA Certification Authority
CN Common Name
CRL Certificate Revocation List
CSR Certificate Signing Request
DESS Diameter End-to-end Security Subgroup
DEA Diameter Edge Agent
DNS Domain Name System

Page 5 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Term Description
DTLS Datagram Transport Layer Security
FQDN Fully Qualified Domain Name
HSM Hardware Security Module
IP Internet Protocol
IPX IP eXchange
iSEPP Initiating SEPP
JSON JavaScript Object Notation
MCC Mobile Country Code
MNC Mobile Network Code
MNO Mobile Network Operator
OCSP Online Certificate Status Protocol
PEM Privacy Enhanced Mail
PGP Pretty Good Privacy
PKI Public Key Infrastructure
Public Mobile Network. Note that references to 3GPP specifications or their contents
PMN may use the abbreviation “PLMN” representing “Public Land Mobile Network” (e.g.
PLMN-ID).
PRD Permanent Reference Document
PRINS Protocol for N32 Interconnect Security
Root CA Root Certification Authority
rSEPP Receiving SEPP
RVAS Roaming Value Added Services
S/MIME Secure/Multipurpose Internet Mail Extensions
SAN Subject Alternative Name
SEG Security Gateway
SEPP Security Edge Protection Proxy
SigFW Signalling Firewall
Sub CA Subordinate Certification Authority
TLS Transport Layer Security
UPF User Plane Function
URL Uniform Resource Locator

1.5 References
Ref Doc Number Title
Security architecture and procedures for 5G System,
[1] 3GPP TS 33.501
https://www.3gpp.org/DynaReport/33501.htm
GSMA PRD
[2] Diameter Interconnect Security
FS.19
[3] TR 02102-2 BSI Technical Guideline – Cryptographic Mechanisms:

Page 6 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Ref Doc Number Title

Recommendations and Key Lengths, Part 2,
https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr0210
2/tr02102_node.html
Handbook of
Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone:
[4] Applied
Handbook of Applied Cryptography, http://cacr.uwaterloo.ca/hac/
Cryptography
Numbering, addressing and identification,
[5] 3GPP TS 23.003
https://www.3gpp.org/DynaReport/23003.htm
BSI Technical Guideline 03145 Secure Certification Authority
Operation,
[6] TR 03145
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications
/TechGuidelines/TR03145/TR03145.pdf
Introduction into
Public key cryptography, Wikipedia,
[7] Public Key
https://en.wikipedia.org/wiki/Public-key_cryptography
Cryptography
Internet X.509 Public Key Infrastructure Certificate and Certificate
[8] RFC 5280
Revocation List (CRL) Profile
“Key words for use in RFCs to Indicate Requirement Levels”, S.
[9] RFC 2119
Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
[10] RFC 8174
https://www.rfc-editor.org/info/rfc8174
GSMA PRD
[11] DNS Guidelines for Service Providers and GRX and IPX Providers
IR.67
GSMA PRD
[12] 5GS Roaming Guidelines
NG.113

1.6 Conventions
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in RFC 2119 ‎[9] and clarified by RFC8174 ‎[10], when, and only
when, they appear in all capitals, as shown here.

2 Key Management Principles

Cryptographic algorithms enable the protection (confidentiality and integrity protection) of
data and the authentication of remote entities over an insecure network. In the context of
signalling and user plane messages, both protection and authentication are required, as
messages traverse networks that are subject to traffic manipulation attacks. This section
provides a high-level and simplified introduction to this topic. For detailed treatment, the
reader is referred to ‎[4] or other sources.

2.1 Cryptographic Keys

Cryptographic algorithms such as those used for encryption, integrity protection and
authentication of remote entities require cryptographic keys. You can generally distinguish
between two types of cryptography and keys:

Page 7 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

 Symmetric cryptography: All parties share and use the same key. This key must
remain secret.
 Asymmetric cryptography: Each party has a key pair consisting of a private key and a
public key. The private key is not shared with anyone and must remain secret, and
the public key, which may be freely disclosed to everyone, must be distributed to all
communication partners. It is crucial that partners obtain an authentic copy of the
public key.

In the context of roaming security, a combination of symmetric and asymmetric cryptography

is used. In order for the asymmetric algorithms to work, involved communication parties
(MNOs and IPX providers) need to generate asymmetric key pairs and exchange their public
keys.

2.2 Certificates
Certificates enable a scalable exchange and management of public keys in a setting with a
large number of communication partners. The purpose of a certificate is to bind an entity’s
public key to its (unique) identifier. A standard public key certificate consists of at least:

 An issuer ID: The unique identifier of the entity issuing the certificate;
 A public key;
 A subject ID: At least one unique identifier of the entity to whom the public key (and
corresponding private key) belongs;
 A lifetime (timestamps indicating “valid from” and “valid until”);
 A unique certificate identifier that enables revocation;
 A pointer to a location where the revocation status can be retrieved; and
 A cryptographic signature of the issuer, generated by a certification authority (CA);

Given two communication partners, say “Alice” and “Bob”: “Alice” has obtained “Bob’s” public
key and must decide whether or not that public key is authentic, i.e. whether it really belongs
to Bob. If the public key is embedded in a certificate, and if Alice trusts the issuer of the
certificate, then Alice can verify the signature of the certificate and obtain some assurance
that the certificate is indeed authentic. If Alice trusts the issuer, she can verify the
authenticity of all certificates issued by that issuer, and hence the binding of public keys to
communication partners’ identifiers.

For security reasons, certificates have a limited lifetime. Well before a certificate has expired,
a new certificate must be exchanged for secure communication to continue. Often, a
certificate has already been renewed and exchanged before it is due to expire.

2.3 Trust relationships between interconnection partners

Different levels of trust may be applicable between the entities involved in the roaming
relationship of interconnection partners. While direct connection between MNOs is usually
based on high trust, having intermediary nodes in between could result in less trust as
illustrated by example in below figure.

Page 8 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Figure 1 – Example of a possible security trust model relationship

Trust can be achieved by technical means but can also be based on a strong contractual
relations, including financial relationships for roaming traffic.

Trust assumptions and how they are achieved between MNO-MNO, MNO-own IPX carrier or
MNO-other IPX carrier or any other intermediary such as a RHUB (roaming hub) need to be
clearly stated for each deployment scenario. Depending on the services rendered, e.g. by
the IPX carrier, the trust model may vary, but is necessary to be defined.

2.4 Certification Authorities

The issuer of a certificate is called a certification authority (CA).

A certification authority is an entity that verifies the identity of another entity and issues a
certificate that confirms the identity of this other entity by binding its public key to a unique
identifier. Its main task is to ensure that:

 only legitimate parties obtain certificates; and

 certificates contain the correct values in all fields, especially the subject unique
identifier (i.e. no entity can obtain a certificate issued under another entity’s name).

In the context of roaming security, MNOs and other players in the IPX ecosystem will use the
functionality of a CA and issue certificates to be used with signalling or user plane
equipment. Afterwards, MNOs exchange issuer certificates with parties that they have a
contractual relationship with.

In the model described in this document, it is assumed that every MNO is using at least one
root CA. The reason for this is that there is no single global CA which could be considered
as trusted for all MNOs located in different geopolitical regions. A dedicated public key
infrastructure (PKI) for inter-PMN security is required. It is assumed that every MNO
independently operates a PKI including a root CA, or alternatively a sub CA and that it uses

Page 9 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

this PKI to issue certificates for its own network elements and servers, as well as for the IPX
providers that it has a contractual relationship with. It is further assumed that the policies and
procedures governing the operation of the PKI, including the issuance and revocation of
certificates, has been documented by each MNO.

As an alternative, MNOs and other players MAY use their existing root CA to sign network
equipment certificates or introduce an intermediate CA instead.

More details about certification authorities, root CAs, sub CAs, PKI and certificate hierarchy
are contained in section ‎3.

2.5 Manual Exchange of Certificates

In the stage 1 solution, issuer certificates are exchanged manually on a bilateral basis. This
requires staff involvement.

As anybody could create an issuer certificate containing an identifier and a public key, there
is a need to verify that a particular certificate actually belongs to a particular entity. This
verification requires the use of a separate communication channel, i.e. not the one used to
transport the issuer certificate.

Page 10 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

3 Key Management and Processing Details

3.1 Certificate Hierarchy

Certificates are typically issued by an authority that is part of a hierarchy. On the top, there is
a single issuer certificate, the so-called root certificate. The root certificate is used by the root
CA to generate certificates for other entities, typically (non-root) CAs. These CAs are called
subordinate CAs (sub CAs) or intermediary CAs. Entities that request and receive
certificates in their role of communication partners, and that do not issue certificates
themselves, are the main reason for which the system is set-up. Their certificates are called
leaf certificates. The entire certification hierarchy and surrounding procedures is called a
public key infrastructure (PKI).

MNOs tend to operate their own their certification authorities (CAs) and are able to issue
certificates for network equipment. In some cases, it is useful to introduce a hierarchy of
CAs. An organisation has one root CA and multiple intermediate (sub) CAs. The root CA
signs all the intermediate certificates. The intermediate CAs sign certificates of network
equipment (leaf certificates) for certain domains. All the CAs, their hierarchy, creation and
management of certificates are collectively referred to by the term public key infrastructure.

The CA (root CA or sub CA) shall be used to sign every individual certificate in certain MNO
networks. By using this principle, it is sufficient for certain protection models just to exchange
the root CA certificate between the roaming partners. Every MNO receiving inter-PMN
messages shall use the chain of trust to verify the root CA, the intermediate CA and the
individual certificates of DEA, SEPP or further network equipment, and to validate that they
all have been correctly signed by a proper CA.

All CAs are issuers, as they issue certificates for entities below them in the chain of trust. An
issuer certificate is the one that was issued for the issuer. It contains the public key of the
issuer.

Operating a PKI in a secure manner requires a set of mechanisms and procedures to be in

place, some of which are beyond the scope of this document. The guidelines in ‎[6] should be
followed by MNOs. It is further recommended to consult TR 02102-1 ‎[3] in order to select
appropriate encryption and signature algorithms as well as key lengths for operating the PKI.

A different hierarchy may exist depending on whether the key management itself and/or the
network equipment is outsourced. The different options are outlined in sections ‎3.1.1 to ‎3.1.2
below. To help explain each option, the following example parameter values are provided:

Parameter Value
MNO 1 MNC 10
MNO 1 MCC 207
Additional PLMN IDs MNO 207-11, 207-12
1
MNO 2 MNC 01
MNO 2 MCC 10
Unique IPX provider name ipxa

Page 11 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Parameter Value
FQDN suffix for MNOs 3gppnetwork.org
FQDN suffix for all other ipxnetwork.org
entities

Table 1 – Example Parameter Values for Illustrating Certificate Hierarchies

Details of the naming conventions can be found in section ‎5.

3.1.1 Certificate Hierarchy when an entity runs own CA

It is strongly preferred that MNOs and other entities run their own CA. Below an example of
the certificate hierarchy when an MNO runs its own CA with an in-house SEPP for 5G
security:

Figure 2 – MNO CA, In-house SEPP

Page 12 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

In the case of N9 operator-to-operator security, the hierarchy would be as illustrated

in ‎Figure 3.

Figure 3 – MNO CA, N9 Operator-to-Operator Security

In case of DESS Phase 1 the certificate hierarchy is as follows:

Figure 4 – MNO CA, DESS Phase 1

While the examples outlined in this document outline MNOs, also other players need CAs.
For instance IPX providers to provide IPsec or RVAS services.

3.1.2 Certificate Hierarchy when 3rd party runs CA

If MNOs or other entities do not have the resources or capability to run their own CA, they
may outsource this functionality to a trusted 3rd party provider on the IPX network. In this
case, the 3rd party provider operates and runs a CA on behalf of the entity. The trusted 3rd
party must meet a minimum set of security requirements, as specified in ‎[6]. While there may
be a trusted third party PKI provider providing PKI services for one or more MNOs, this
provider is required to offer this service exclusively on the IPX network and not exposed to
the Internet, including downloading CRLs or obtaining certificate revocation information via
OCSP. The root CA certificate SHALL NOT be the same as other customers from the trusted
3rd party i.e. a different CA per MNO if that CA is run by an IPX provider or other 3rd party.
Alternatively a sub CA per MNO can be introduced.3rd party CAs shall make sure that

Page 13 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

services connected to the certificate authority (e.g. OCSP) work exclusively on the IPX
network. This includes domain resolution via DNS.

An example hierarchy for an IPX carrier acting as a trusted 3rd party for 2 MNOs in
combination with hosted SEPP is as follows:

Figure 5 – Trusted 3rd Party CA with Hosted SEPP

NOTE 1: In the example above 2 sub CAs are introduced. Alternatively the trusted 3rd
party may deploy 2 separate root CAs for the 2 MNOs.

NOTE 2: Trusted 3rd parties are not bound to IPX providers, other players fulfilling the
requirements in this section can offer such services to all MNOs and other
entities.

3.2 Certificate Verification

Certificate verification logic must not be limited to checking that a valid path exists to any
trusted CA and that the current date lies within the validity period of all certificates in the
chain. As described in section ‎4.4.1, once a CA certificate is bound to a particular roaming
partner, all messages from that roaming partner must be rooted in that particular CA
certificate, and this MUST be checked.

Page 14 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

The following aspects SHALL be checked as well.

 The Issuer and Subject fields of the leaf certificate MUST follow the specified format
and correspond to equipment that is eligible to send messages over the interface
over which the message was received.
 For all certificates in the chain: The issuer of the certificate MUST match the subject,
i.e. they must both correspond to the same entity.

3.3 Certification Authority requirements

Each MNO or other entity on the IPX network SHALL provide at least one root or sub CA
and is strongly recommended to operate its own PKI. This may be an existing certificate
authority or a new one dedicated to this purpose.

The policies and procedures governing the operation of the PKI MUST be documented.

Operating a CA is security critical and involves a number of organisational and technical

security measures, for example as defined in ‎[6].

If a trusted 3rd party PKI provider operates the CA on behalf of the MNO, this trusted 3rd
party must adhere to the same security requirements.

4 Exchange Procedures
The exchange of issuer certificates and DESS Phase 1 leaf certificates is a manual process.
MNOs and other players within the IPX ecosystem need to assign responsibilities for
performing key management to staff. This includes key generation, certificate issuing, and
certificate exchange.

During negotiation of the roaming agreement, MNOs should agree on the detailed procedure
and the technical means for exchanging certificates. This document defines a high-level
process that should be followed by the MNOs by default.

NOTE: Exceptions can be made and different procedures can be used if both MNOs
mutually agree.

4.1 Responsibilities
MNOs are responsible for performing the procedures described in this section. Depending
on the service offering of IPX providers and on the agreements between MNOs and IPX
providers, some of the inter-PMN security functionality may be operated by the IPX provider
on behalf of the MNO. In such a case, responsibilities move from the MNO to the IPX
provider. The IPX provider will then have to perform the steps described in this document.

5G – Depending on the roaming relation between two MNOs, the IPX provider needs to
attach the corresponding certificate to the modified 5G signalling message so that the
receiving MNO can validate the modification against the root CA certificate of the sending
MNO.

Diameter DESS Phase 1 – As defined in FS.19 ‎[2], for DESS, MNOs issue certificates for
their serving IPX providers. The corresponding keys, belonging to the IPX provider, are to be
used by the IPX provider when it modifies signalling messages on transit.

Page 15 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

The IPX provider for the modified Diameter signalling messages should re-sign the message
by using the DESS signature. The receiving MNO should validate the signature by using the
IPX certificate which should be properly signed by the sending MNO’s issuer certificate.

4.2 Prerequisites
 Roaming partners SHALL be able to issue and distribute certificates according to ‎[6]
and to inform their peers about expiry and revocation of certificates. Staff with the
relevant expertise MUST be assigned.
 Roaming partners SHALL keep contact details of responsible staff on file. Roaming
partners SHALL update each other on any changes of the contact details.
 Roaming partners SHALL keep track of certificate expiry and issue a new certificate
early enough before the current one expires. It is the joint responsibility of the
certificate subject and the issuer to ensure that a new certificate is available well
before expiry.
 For DESS Phase 1, MNOs SHALL ensure that IPX providers with which they have a
contractual relationship are in the position to securely generate and store key pairs,
issue certificate signing requests (CSR), and accept certificates issued by the MNO
and use them in the context of signalling as specified below. MNOs SHALL further
ensure that IPX providers are generating new certificate signing requests in
accordance with the certificate renewal procedures defined below, and that they
immediately inform the MNO if a certificate needs to be revoked. Certificate signing
requests from IPX providers SHOULD be kept on file by MNOs.

4.3 Determine Certificates to be Exchanged

Issuer certificates SHALL be exchanged for:

 5G – Transport Layer Security (TLS) + Protocol for N32 Interconnect Security

(PRINS1)
 N9 operator-to-operator security with NDS/IP

On top leaf certificates SHALL be exchanged for:

 4G – DESS Phase 1 (authentication and integrity protection only)

NOTE: Explanations on this special case are provided in section ‎4.5.

4.4 Certificate Management Procedures

4.4.1 Certificate Exchange Procedure

The certificate to be exchanged as per section ‎4.3, SHALL be exchanged as explained
below. While the section mentions MNO to improve the readability, it may also read any
other entity, including a trusted 3rd party.

1
PRINS is the application layer security protocol for the N32 interface described in clause 13.2 of TS
33.501 ‎[1]. PRINS is however out of scope for 5GMRR Phase 1

Page 16 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Publishing MNO:

1. Install the respective certificate on the equipment (SEPP, DEA/SigFW, User Plane
Function (UPF) / Security Exchange Gateway (SEG) or other) and ensure that it will
be offered to peers upon establishment of a secure roaming communication.
2. Prepare an initially empty certificate revocation list and publish it under a URL (CRL
URL which matches the field within the issued certificates) on the IPX network. As an
optional alternative, Online Certificate Status Protocol (OCSP) stapling can be used.
Note that each CA (i.e. root, intermediate) maintains its own CRL, hence there may
be multiple CRLs.
3. Send the certificate by email to the roaming partner. It is suggested that the email is
signed by PGP or S/MIME.
4. Prepare to receive a phone call for the purposes of verifying the certificate’s
fingerprint.

NOTE: The receiving MNO SHOULD initiate the phone call and not the sending
MNO. This is to avoid attacks with spoofed caller IDs.

Receiving MNO:

1. On receiving an email with an issuer certificate from a roaming partner, ring up the
responsible member of staff of the roaming partner and ask this person to read out
the fingerprint of the certificate. In case of a mismatch, make sure that the
organisation’s processes and procedures are followed and that an investigation is
completed to ensure this is not a malicious attack to inject a rogue certificate. In case
of a match, mark the certificate as verified.
2. Install the verified CA certificate on the equipment (SEPP, DEA/SigFW, UPF/SEG or
other) , mark it as trusted, and bind it to the configuration used to communicate with
this particular roaming partner. After this binding is activated, the server MUST
discard or reject all incoming messages from that particular roaming partner except
those that are protected by a certificate with a certificate chain that is rooted by the
bound certificate.
3. Have the system validate the noted CRLs in a timely manner and according to the
organisation’s policies, to verify that they can be resolved. Alternatively, using OCSP
stapling is an option.

If the above steps are omitted, there is a risk that an attacker could provide a certificate that
does not belong to the roaming partner and that future roaming traffic with that roaming
partner could be compromised.

4. Record the expiry date of the received certificate and ensure to be alerted at least
three months prior to its expiry, or earlier if specified by the organisation’s policies
and procedures, which allows sufficient time to be able to receive a new certificate
from the roaming partner.

Obtaining the certificate fingerprint:

The following procedure is suggested for obtaining the certificate fingerprint that must be
verified by phone call. It applies to both the publishing and the receiving MNO.

Page 17 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

5. Ensure that the publishing and receiving MNO have the certificate in the same format.
If format differs, convert the certificate into the PEM format.
6. Use the same tool for fingerprint verification on both sides and apply the SHA256
algorithm as the fingerprint algorithm. For example, the following command could be
used.

Openssl x509 -nooout -fingerprint -sha256 -inform pem -in cert.crt

Assuming the filename of the PEM-encoded certificate is cert.crt.

4.4.2 Certificate Revocation

If a private key is compromised (e.g. stolen from the network equipment on which it is
stored), all peers have to be informed that the corresponding certificate can no longer be
used. This process is called certificate revocation.

The process differs depending on whether the certificate to be revoked is the CA certificate,
or some certificate issued by the CA.

4.4.2.1 Revocation of an issued certificate

Revoking an issued (intermediate or leaf) certificate is a possibility that needs to be
accounted for. First, the party suffering the compromise (MNO or IPX provider) generates a
new key pair and issues a certificate signing request. The publishing entity then generates a
replacement certificate and puts it to use. For DESS Phase 1 specifically it is the
responsibility of IPX providers to inform MNOs about the need for certificate revocation.

The MNO MUST add the revoked certificate details to the CRL and publish the new CRL
version under the previously shared URL. There is no need for further manual actions, since
all peers that have correctly installed the URL in their network equipment configurations will
no longer accept the revoked certificates as the systems (should) automatically check the
CRL repository every 24 hours for newly revoked certificates.

4.4.2.2 Revocation of a CA certificate

Revoking the CA certificate is a relatively major incident, as this step immediately invalidates
all certificates that have been issued by that CA. It is expected that CA certificate revocation
is an extremely rare necessity, as the CA private key shall be protected more rigorously than
other keys, as described in ‎[6].

Publishing MNO:

1. Contact roaming partners (preferably by signed email) that the currently valid CA
certificate will be exchanged with a new one shortly.
2. Issue new intermediate and leaf certificates as necessary to resume operations after
CA certificate switch. Reusing existing requests may avoid undue delays.
3. Perform the actions from section ‎4.4.1 (publishing MNO) for each roaming partner.
4. Publish the revoked certificate in the CRL and publish a new version of the CRL. In
order to minimize the delay until partner MNOs check for an updated CRL, OCSP
stapling is also an option.

Page 18 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Receiving MNO:

1. When contacted by a roaming partner for the purposes of CA certificate

revocation/replacement, perform the actions from section ‎4.4.1 (receiving MNO).
Apart from verifying the fingerprint of the new CA certificate, it is crucial that the
identity of the responsible staff at the publishing MNO is properly verified via a
separate channel. If using a phone, only verifying the identity solely based on the
phone number is strongly discouraged.
2. In addition to installing the new CA certificate, delete all copies of the revoked one.

4.4.3 CA certificate renewal procedure

A new issuer (CA) certificate SHOULD be issued at least six months before the current one
expires. The steps to be followed are as specified in section ‎4.4.1 both for the publishing and
the receiving MNO.

NOTE 1: The old CA certificate SHALL remain valid in the equipment of both the
publishing MNO and the receiving MNO until the pre-defined time of expiry.

NOTE 2: After a CA certificate replacement (renewal or revocation), the CRL is

initially empty.

4.4.4 Non-CA (Intermediate or Leaf) certificate renewal procedure

Issued certificates SHOULD be renewed three months before expiry. MNOs are responsible
to issue new certificates for their servers in a timely manner, and they SHALL ensure that
they receive certificate signing requests from IPX providers on time.

If this renewal is not done in a timely manner it will lead to roaming traffic being impacted
due to the certificate not being valid and the SEPP, DEA, SigFW or other equipment not
being able to verify the protected traffic, causing the traffic to be dropped or rejected.

4.5 Certificate exchange specifically for DESS Phase 1

DESS Phase 1 enhances Diameter messages on the inter-PMN interface with additional
attribute value pairs (AVPs) to support digitally signed Diameter messages. The
implementation of DESS Phase 1 differs from the 5G PRINS 2 and the foreseen DESS Phase
2:

 There is no in-band exchange of MNO leaf certificates and IPX provider leaf
certificates.
 IPX providers do not append the certificate (chain) to the digital signature
 IPX providers sign modified messages (as in 5G they sign JavaScript Object Notation
(JSON) patches), but IPX providers also need to verify the message before they re-
sign the message. In 5G IPX providers have no role in message verification.

These characteristics imply a different key management procedure:

 In addition to the issuer certificate, individual leaf certificates need to be exchanged.

2
If 5GMRR proceeds with PRINS

Page 19 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

 As IPX providers need to verify digitally signed messages, they need to possess the
issuer certificate of their client MNO and the issuer certificate of the peer MNO, and
all underlying DEA/SigFW leaf certificates. This includes the peer MNOs’ IPX
certificates responsible for Diameter signing.

It is foreseen that DESS Phase 1 is an intermediate step towards DESS Phase 2, where
certificates will be exchanged in-band.

For DESS Phase 1 MNOs SHOULD introduce a dedicated intermediate CA for network
equipment connected to the IPX provider. This intermediate CA would sign all leaf
certificates of all the network equipment of the IPX provider of the serving MNO. This has
two major advantages:

 MNOs can assign responsibility for the intermediate CA to a different department than
the owners of the root CA. This simplifies issuing certificates for new network
equipment.
 For roaming partners, it is easier to determine which network equipment they could
trust for secure exchange of messages. It would be all certificates issued by this
particular sub CA.

The steps in section ‎4.5.1 SHALL be executed once in preparation of the first end-to-end
secured Diameter roaming relationship. The steps described in section ‎4.5.2 and
section ‎4.5.3 shall be executed for each end-to-end secured Diameter roaming relation.

4.5.1 Certificate exchange between MNO and own IPX provider

The following steps are executed only once in preparation of the first end-to-end Diameter
roaming relationship.

If an MNO anticipates that its IPX provider needs to make changes to Diameter messages
as described in Annex D of ‎[2], it SHALL:

 Exchange its own issuer certificate as described in section ‎4.4.1, where its own IPX
provider acts as receiving MNO
 MNO CA to sign for all leaf certificates and potentially sub CAs of the IPX provider,
see section ‎3.1.1 for the certificate hierarchy
 Exchange all leaf certificates of the MNO relevant entities for Diameter signing
(DEA/SigFW leaf certificates)

Leaf certificates are considered authentic if they are signed by the exchanged issuer
certificate. The method used to manually exchange leaf certificates is left to the MNO and
the IPX provider to agree.

4.5.2 Leaf Certificate exchange between MNOs

The following steps SHALL be executed for each end-to-end secured Diameter roaming
relationship.

For each end-to-end secured Diameter roaming relationship, leaf certificates need to be
exchanged. This means that, in addition to the procedure described in section ‎4.4.1, all
underlying DEA/SigFW leaf certificates, including the peer MNO’s IPX certificate entities
responsible for Diameter signing (if any), SHALL be manually exchanged.

Page 20 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Leaf certificates are considered authentic if they are signed by the exchanged issuer
certificate. The method used to manually exchange leaf certificates is left to the MNO to
decide.

4.5.3 Peer MNO Certificate exchange between an MNO and its own IPX
provider
The following steps SHALL be executed for each end-to-end secured Diameter roaming
relationship.

If an MNO anticipates that its IPX provider needs to make changes to messages (which
indicate that it needs to verify Diameter messages as well, see section ‎4.5) on the end-to-
end secured Diameter roaming relationship it shall:

 Exchange the issuer certificate of the peer operator as described in section ‎4.4.1
where its own IPX provider acts as receiving MNO.
 Exchange all leaf certificates of the peer operator obtained as described in
section ‎4.5.2 that are relevant for Diameter signing entities (DEA/SigFW leaf
certificates), including the peer MNO’s IPX certificates responsible for Diameter
signing (if any).

Leaf certificates are considered authentic if they are signed by the exchanged issuer
certificate. The method used to manually exchange leaf certificates is left to the MNO and
the IPX provider to agree.

4.5.4 DESS Phase 1 functionality delegation

As stated in FS.19 ‎[2], DESS Phase 1 functionality may be delegated to the serving IPX
provider of an MNO. This delegation SHALL be published in the IR.21 of the MNO.

See section ‎3.1.2 for the certificate hierarchy for DESS 1 delegation.

5 Naming Scheme
The naming scheme specified below follows section 28 of TS 23.003 ‎[5]. See ‎Annex B for
example certificates

Root or intermediate certificates SHALL:

 be X.509 v.3 certificates according to RFC 5280;

Leaf certificates SHALL:

 be X.509 v.3 certificates according to RFC 5280 with the Subject Alternative Name
(SAN) extension
 contain the values for MNC and MCC, each three digits long (zero prefix as
necessary) and correspond to the MNO (as in section 28.2 of TS 23.003 ‎[5])
reflecting the main PLMN ID of the MNO
 comply with the naming schemes in ‎5.1 to ‎5.3
 repeat the Common Name (CN) in the Subject Alternative Name (SAN) field
 Specifically for SEPP certificates: to contain all PLMN IDs that the SEPP represents
on a given N32 connection, refer to section ‎5.1

Page 21 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

 In order to avoid certificate mismatches include the well-known logical FQDN next to
the physical FQDN

The UNIQUE-IPX-PROVIDER-ID in root, intermediate and leaf certificates can be any valid
alphanumeric host ID that can be put into a Fully Qualified Domain Name (FQDN). It must
be unique across all IPX providers worldwide. GSMA PRD IR.67 ‎[11] describes the
procedure for how the alphanumeric host ID can be reserved and handed out. The FQDN
shall also be resolved by a DNS server on the IPX network.

5.1 SEPP
The naming scheme of the SEPPs differs depending on whether the SEPP is operated by
the MNO, or operated by another entity (e.g. outsourced SEPP or MNO group SEPP)

5.1.1 MNO SEPP

The Subject CN field SHALL be structured as

sepp<SEPPID>.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

where SEPPID is the SEPP ID as specified in section 13.2.2.4.2 of TS 33.501 ‎[1].

MNO SEPP certificates SHALL include all PLMN IDs in SAN fields as DNS name for where
it runs the N32 connection e.g.:

sepp<SEPPID>.5gc.mnc<PLMN ID 1>.mcc<MCC>.3gppnetwork.org
sepp<SEPPID>.5gc.mnc<PLMN ID 2>.mcc<MCC>.3gppnetwork.org

Signalling traffic containing other PLMNs IDs SHALL NOT be accepted.

The well-known SEPP FQDN sepp.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org as

described in GSMA PRD NG.113 ‎[12] is only a stepping stone to trigger SEPP discovery via
DNS. The well-known FQDN SHALL NOT be used for naming a SEPP. It SHALL NOT be
mentioned in CN or SAN fields of certificates.

5.1.2 Non-MNO SEPP

When the SEPP does not belong to an MNO, e.g. outsourced SEPP or MNO group SEPP,
the certificate SHALL clearly indicate this in the CN/SAN fields and SHALL also be published
in the IR.21 accordingly. The CN field SHALL be structured as:

sepp<SEPPID>.5gc.mnc<MNC>.mcc<MCC>.<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org

where SEPPID is the SEPP ID as specified in section 13.2.2.4.2 of TS 33.501 ‎[1].

Entities that operate an outsourced SEPP SHALL use separate SEPP certificates for each
MNO that it serves.

Non-MNO SEPP certificates SHALL include all PLMN IDs in SAN fields as DNS name from
the MNO for where it runs the N32 connection e.g.:

sepp<SEPPID>.5gc.mnc<PLMN ID 1>.mcc<MCC>.<UNIQUE-IPX-PROVIDER-
ID>.ipxnetwork.org

Page 22 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

sepp<SEPPID>.5gc.mnc<PLMN ID 2>.mcc<MCC>.<UNIQUE-IPX-PROVIDER-
ID>.ipxnetwork.org

Signalling traffic containing other PLMNs IDs SHALL NOT be accepted.

NOTE: MNO connection to non-MNO SEPP is out of scope of this document. The
type of connection (e.g. TLS or NDS/IP) and corresponding key
management is left to the MNO and outsourced SEPP provider or MNO
group SEPP.

An example of a non-MNO SEPP is outlined below:

Figure 6 – Outsourced (multi-tenant) SEPP

In order to avoid certificate mismatches in the TLS handshake the initiating SEPP (iSEPP)
SHALL always include the FQDN of the MNO tenant in the TLS SNI-parameter. Also, The
receiving SEPP (rSEPP) SHALL not duplicate FQDNs in CN/SAN in different certificates.

5.2 DESS Phase 1 related entities

DESS Phase 1 related entities such as SigFW,DRA or DEA have a different naming
convention whether the below to the MNO or to the serving IPX provide.

5.2.1 MNO DESS Phase 1 equipment

The Subject CN/SAN field SHALL be structured as:

diameteridentity.mnc<MNC>.mcc<MCC>.3gppnetwork.org

where diameteridentity is the Diameter node (host) to which the certificate is issued. If
all Diameter nodes use the same certificate the Subject/SAN field shall be structured as:

diameter.mnc<MNC>.mcc<MCC>.3gppnetwork.org

For DESS Phase 1 the DESS-Signing-Identity AVP shall indicate the signee in the exact
format of the Subject/SAN field outlined above.

5.2.2 IPX provider intermediate signing DESS Phase 1 equipment

For intermediate signing as described in FS.19 ‎[2] the Subject CN/SAN field SHALL be
structured as:

Page 23 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

diameteridentity.<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org

where diameteridentity is the Diameter node (host) to which the certificate is issued. If
all Diameter nodes use the same certificate the Subject/SAN field shall be structured as:

diameter.<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org

For DESS Phase 1 the DESS-Signing-Identity AVP shall indicate the signee in the exact
format of the Subject/SAN field outlined above.

5.2.3 IPX provider security delegation DESS Phase 1 equipment

For security delegation, not be to confused with intermediate signing, as described in
FS.19 ‎[2] the Subject CN/SAN field SHALL be structured as:

diameteridentity.mnc<MNC>.mcc<MCC>.<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org

where diameteridentity is the Diameter node (host) to which the certificate is issued. If
all Diameter nodes use the same certificate the Subject/SAN field shall be structured as:

diameter.mnc<MNC>.mcc<MCC><UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org

For DESS Phase 1 the DESS-Signing-Identity AVP shall indicate the signee in the exact
format of the Subject/SAN field outlined above.

5.3 N9 operator-to-operator security

The Subject CN/SAN field SHALL be structured as either:

a) upf<upfIdentity>.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

or

b) seg<segIdentity>.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

(a) may indicate a UPF or a UPF cluster providing the secure tunnel.

(b) may indicate a or a Security Gateway (SEG) providing the secure tunnel.

NOTE: Outsourcing or delegating N9 operator-to-operator security is to be studied

in a later stage in collaboration with 5GMRR

Page 24 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Annex A Public Key Infrastructure (PKI)

A.1 Introduction to PKI

PKI, or public key infrastructure, is a summarizing term for the infrastructure and processes
that facilitate the use of certificates. In their essence certificates allow two parties to share
their identity via a standardized format, often X.509, and have a centrally trusted third party
verify that what both parties have sent is indeed true. Combine this service with the
assurance of provably strong asymmetric cryptography and you have a service that can
provide a very high level of trust between two parties.

In more technical terms, this infrastructure starts with a central entity called a root CA, or root
certification authority. This party is, within this PKI infrastructure, at the top of a pyramid and
trusted by all parties that use its services. If two parties want to create trust between each
other using certificates they start with creating a pair of keys – a public and a private part.
With this keypair they generate a certificate signing request (CSR) which in essence is their
certificate which they ask the root CA to sign. The root CA verifies the identity of the
requesting party according to specific procedures and, if OK, will sign the certificate with its
own keypair. Now, both parties can exchange these signed certificates, in combination a
signature from their key pair, and have a certain amount of verifiable proof that both parties
are who they say they are.

This methodology is also what provides the initial setup of a TLS transaction, or in the case
of Diameter DTLS, to setup a secure connection (HTTPS between two SEPPs) or provide
integrity and confidentiality protection of Diameter traffic. For more details a good start is the
Wikipedia page on this subject ‎[7].

A.2 Example PKI using EJBCA

There are multiple ways of operating a PKI. In this annex we have chosen to provide an
example of using EJBCA to run a PKI infrastructure, as it provides all aspects needed to do
this technically and procedurally, and has an unlimited free version that can be extended
with paid for support for those companies whose internal policies require it. However, the
certification authority required for a PKI infrastructure must be operated securely as it is key
to maintaining the trust between all the organisations participating in the infrastructure. There
are a number of global references that define how multi-organisation PKI infrastructures can
be secured, this includes ‎[6]. Due to the costs required to create a secure PKI infrastructure
MNOs are strongly advised to use existing PKI Infrastructure capabilities, either internal or
external to maintain inter-organisation trust.

EBJCA can be installed in two ways – standalone using JBOSS, or in a docker container.
Please follow the respective installation guide which can be found here –
https://www.ejbca.org/download/.

To setup the root CA, a keypair first needs to be created. It is advised, due to the importance
of these keys, to create and store these keys in a hardware security module (HSM). EJBCA
supports multiple solutions – https://download.primekey.com/docs/EJBCA-
Enterprise/6_15_2/Hardware_Security_Modules_(HSM).html. It is advised to be critical in
the evaluation when choosing an HSM – however, even a simple variant such as a Nitrokey
HSM or Yubikey HSM is better than storage on disk or in a SoftHSM.

Page 25 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

With these keys ready, a root CA can be created using the certification authority selector,
and then selecting ‘create new’ at the bottom. Information on how to fill in these fields can be
found in the EJBCA documentation as well as in RFC 5280 ‎[8]. If a root CA is already
present in an MNO organisation one should create a separate sub (or leaf) CA for signing
certificates used for mobile roaming traffic. This to reduce the impact of compromised key
material, clarify the scope a certificate is allowed to be used in, not share company internal
information, and keep a better overview of where certificates are used and for which
purpose.

When the root (or sub) CA is created it is advised to create a certificate profile. This is to
prevent differences between certificates within your infrastructure and reduce the burden on
employees. The details on defining the profile can be found in the EJBCA documentation or
RFC 5280 ‎[8].

When these steps have been concluded, the employee responsible for the SEPP, DEA or
SigFW can start the process for receiving a signed certificate from the root or sub CA. The
specific procedure will be vendor specific but the steps are always as follows:

1. Generate an asymmetric key pair on the system in question using the approach
specified in ‎[1]
2. Generate the certificate signing request (CSR) and have this signed by the root/sub
CA. If needed ONLY export the CSR to EJBCA. NEVER export the private key off the
system as this compromises its confidentiality and all traffic protected by it.
3. Import the signed certificate back onto the platform and configure your platform to use
only that certificate for all specific communication.

If the platform supports OpenSSL, the following website provides a short introduction on how
that might be used to create a CSR: https://support.rackspace.com/how-to/generate-a-csr/.

Page 26 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Annex B Example certificates

These examples only cover basic configuration and do not include CRL or OCSP
configuration

B.1 Root Certificates

B.1.1 MNO Root Certificate:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ca1.mnc010.mcc207.3gppnetwork.org, O=Examplephone ltd.,
ST=Zuid-Holland, C=NL, L=Rotterdam/[email protected]
Validity
Not Before: Aug 6 07:25:54 2021 GMT
Not After : Aug 4 07:25:54 2031 GMT
Subject: CN= ca1.mnc010.mcc207.3gppnetwork.org, O= Examplephone
ltd., ST=Zuid-Holland, C=NL, L=Rotterdam/[email protected]
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (521 bit)
pub:
04:01:d7:99:4e:fe:9c:58:02:9a:ef:ce:24:f9:0e:
cc:33:61:64:e8:48:29:bd:88:ae:4c:a6:df:be:c3:
8c:12:9d:6e:e2:fd:6a:64:2f:e6:9a:61:47:d2:9c:
60:b5:49:26:7f:fe:9b:c7:fb:ae:a7:e6:89:a9:98:
a0:56:7c:3a:32:e1:f7:00:7e:98:64:c6:b9:d2:66:
36:e3:63:ec:89:c6:28:55:d9:61:c0:13:64:09:a5:
8f:ba:72:ab:4c:ff:e5:41:58:6c:ad:81:44:60:4b:
3b:b6:2a:e9:7b:67:08:fd:9e:6d:6d:8b:6f:11:2e:
8f:e2:37:14:f8:39:cb:3b:d6:b8:75:6b:fa
ASN1 OID: secp521r1
NIST CURVE: P-521
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Key Encipherment, Certificate Sign
Signature Algorithm: ecdsa-with-SHA256
30:81:88:02:42:01:c3:2f:fe:9f:e7:55:b2:da:cb:c3:3d:9d:
b0:c9:2e:20:de:9a:b4:ab:15:3c:87:bd:06:79:3b:a3:1b:aa:
13:9e:f7:80:cf:ef:f6:e6:3e:cb:fb:84:61:ea:b3:73:82:65:
a5:6e:78:cc:80:ec:8c:32:05:1e:6b:6b:72:ea:89:b0:eb:02:
42:01:1d:d7:f1:fa:b5:7f:d4:5e:d8:32:5f:bf:66:9d:92:83:
09:c1:ad:52:e0:39:7c:09:cd:46:49:ea:b2:ac:c4:64:a3:58:
5c:10:e3:e3:0e:11:f0:df:b3:1a:ac:85:c6:82:00:75:ac:43:
66:5e:b4:9b:12:7b:a2:40:11:f7:a8:3f:40

Page 27 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

B.1.2 IPX entity Root Certificate

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ca1.examplecarrier.ipxnetwork.org, O=Examplecarrier
ltd., ST=Zuid-Holland, C=NL,
L=Rotterdam/[email protected]
Validity
Not Before: Aug 6 07:25:54 2021 GMT
Not After : Aug 4 07:25:54 2031 GMT
Subject: CN= ca1.examplecarrier.ipxnetwork.org, O= Examplecarrier
ltd., ST=Zuid-Holland, C=NL,
L=Rotterdam/[email protected]
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (521 bit)
pub:
04:01:d7:99:4e:fe:9c:58:02:9a:ef:ce:24:f9:0e:
cc:33:61:64:e8:48:29:bd:88:ae:4c:a6:df:be:c3:
8c:12:9d:6e:e2:fd:6a:64:2f:e6:9a:61:47:d2:9c:
60:b5:49:26:7f:fe:9b:c7:fb:ae:a7:e6:89:a9:98:
a0:56:7c:3a:32:e1:f7:00:7e:98:64:c6:b9:d2:66:
36:e3:63:ec:89:c6:28:55:d9:61:c0:13:64:09:a5:
8f:ba:72:ab:4c:ff:e5:41:58:6c:ad:81:44:60:4b:
3b:b6:2a:e9:7b:67:08:fd:9e:6d:6d:8b:6f:11:2e:
8f:e2:37:14:f8:39:cb:3b:d6:b8:75:6b:fa
ASN1 OID: secp521r1
NIST CURVE: P-521
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Key Encipherment, Certificate Sign
Signature Algorithm: ecdsa-with-SHA256
30:81:88:02:42:01:c3:2f:fe:9f:e7:55:b2:da:cb:c3:3d:9d:
b0:c9:2e:20:de:9a:b4:ab:15:3c:87:bd:06:79:3b:a3:1b:aa:
13:9e:f7:80:cf:ef:f6:e6:3e:cb:fb:84:61:ea:b3:73:82:65:
a5:6e:78:cc:80:ec:8c:32:05:1e:6b:6b:72:ea:89:b0:eb:02:
42:01:1d:d7:f1:fa:b5:7f:d4:5e:d8:32:5f:bf:66:9d:92:83:
09:c1:ad:52:e0:39:7c:09:cd:46:49:ea:b2:ac:c4:64:a3:58:
5c:10:e3:e3:0e:11:f0:df:b3:1a:ac:85:c6:82:00:75:ac:43:
66:5e:b4:9b:12:7b:a2:40:11:f7:a8:3f:40

Page 28 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

B.2 Leaf certificates

B.2.1 MNO SEPP certificate issued by MNO

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 245515457 (0xea244c1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN= ca1.mnc010.mcc207.3gppnetwork.org, O=Examplephone ltd.,
ST=Zuid-Holland, C=NL, L=Rotterdam/[email protected]
Validity
Not Before: Aug 6 07:35:36 2021 GMT
Not After : Aug 6 07:35:36 2022 GMT
Subject: CN=sepp1.5gc.mnc010.mnc207.3gppnetwork.org, O=Examplephone
ltd., ST=Zuid-Holland, C=NL, L=Rotterdam/[email protected]
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:a2:47:15:e4:be:85:2e:31:4c:b3:86:b0:16:82:
20:d3:ca:85:76:58:a7:c4:23:ca:11:9c:99:61:0d:
34:14:47:67:da:55:c4:65:57:44:54:ad:a3:96:22:
6e:f0:b6:17:d5:2b:d3:84:87:c6:0f:9c:49:c0:80:
12:37:b4:4d:55:2e:a3:dd:80:9c:d2:00:bd:3e:4f:
30:f0:af:4b:3d:5f:9a:55:f9:fa:2c:0b:2c:77:73:
c5:fb:ab:11:71:a2:01
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: critical
TLS Web Client Authentication, TLS Web Server
Authentication
X509v3 Subject Alternative Name:
DNS:sepp1.5gc.mnc010.mnc207.3gppnetwork.org,
DNS:sepp1.5gc.mnc011.mnc207.3gppnetwork.org,
DNS:sepp1.5gc.mnc012.mnc207.3gppnetwork.org

Signature Algorithm: ecdsa-with-SHA256

30:81:87:02:42:01:09:18:bc:30:13:ca:5a:a6:67:40:7d:63:
56:01:17:be:d6:ac:c2:c2:b3:40:3e:97:c8:80:5f:90:c1:92:
dc:b9:b1:49:d2:a9:02:33:d7:1e:35:7e:0a:eb:13:22:b9:70:
78:45:36:2c:85:f5:ce:ce:62:6a:d8:33:5b:08:6f:d6:08:02:
41:45:80:c4:d6:79:2e:d3:6c:e8:34:5a:95:d6:64:3b:66:a5:
30:81:27:43:b5:3a:37:f6:82:f4:3b:63:75:1e:10:dd:f4:80:
d3:c8:9f:4c:0e:40:60:0d:df:fa:1d:3f:7c:cc:c7:33:1d:13:
83:0a:b4:fb:e7:c9:c7:40:85:ef:ba:13

Page 29 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

B.2.2 MNO SEPP certificate issued by IPX entity

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 245515457 (0xea244c1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN= ca1.examplecarrier.ipxnetwork.org, O=Examplecarrier
ltd., ST=Zuid-Holland, C=NL,
L=Rotterdam/[email protected]
Validity
Not Before: Aug 6 07:35:36 2021 GMT
Not After : Aug 6 07:35:36 2022 GMT
Subject: CN=sepp1.5gc.mnc010.mnc207.3gppnetwork.org, O=Examplephone
ltd., ST=Zuid-Holland, C=NL, L=Rotterdam/[email protected]
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:a2:47:15:e4:be:85:2e:31:4c:b3:86:b0:16:82:
20:d3:ca:85:76:58:a7:c4:23:ca:11:9c:99:61:0d:
34:14:47:67:da:55:c4:65:57:44:54:ad:a3:96:22:
6e:f0:b6:17:d5:2b:d3:84:87:c6:0f:9c:49:c0:80:
12:37:b4:4d:55:2e:a3:dd:80:9c:d2:00:bd:3e:4f:
30:f0:af:4b:3d:5f:9a:55:f9:fa:2c:0b:2c:77:73:
c5:fb:ab:11:71:a2:01
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: critical
TLS Web Client Authentication, TLS Web Server
Authentication
X509v3 Subject Alternative Name:
DNS:sepp1.5gc.mnc010.mnc207.3gppnetwork.org,
DNS:sepp1.5gc.mnc011.mnc207.3gppnetwork.org,
DNS:sepp1.5gc.mnc012.mnc207.3gppnetwork.org

Signature Algorithm: ecdsa-with-SHA256

30:81:87:02:42:01:09:18:bc:30:13:ca:5a:a6:67:40:7d:63:
56:01:17:be:d6:ac:c2:c2:b3:40:3e:97:c8:80:5f:90:c1:92:
dc:b9:b1:49:d2:a9:02:33:d7:1e:35:7e:0a:eb:13:22:b9:70:
78:45:36:2c:85:f5:ce:ce:62:6a:d8:33:5b:08:6f:d6:08:02:
41:45:80:c4:d6:79:2e:d3:6c:e8:34:5a:95:d6:64:3b:66:a5:
30:81:27:43:b5:3a:37:f6:82:f4:3b:63:75:1e:10:dd:f4:80:
d3:c8:9f:4c:0e:40:60:0d:df:fa:1d:3f:7c:cc:c7:33:1d:13:
83:0a:b4:fb:e7:c9:c7:40:85:ef:ba:13

Page 30 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

B.2.3 Outsourced SEPP certificate issued by MNO

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 245515457 (0xea244c1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN= ca1.mnc010.mcc207.3gppnetwork.org, O=Examplephone ltd.,
ST=Zuid-Holland, C=NL, L=Rotterdam/[email protected]
Validity
Not Before: Aug 6 07:35:36 2021 GMT
Not After : Aug 6 07:35:36 2022 GMT
Subject: CN=sepp1.5gc.mnc010.mnc207.examplecarrier.ipxnetwork.org,
O=Examplephone ltd., ST=Zuid-Holland, C=NL,
L=Rotterdam/[email protected]
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:a2:47:15:e4:be:85:2e:31:4c:b3:86:b0:16:82:
20:d3:ca:85:76:58:a7:c4:23:ca:11:9c:99:61:0d:
34:14:47:67:da:55:c4:65:57:44:54:ad:a3:96:22:
6e:f0:b6:17:d5:2b:d3:84:87:c6:0f:9c:49:c0:80:
12:37:b4:4d:55:2e:a3:dd:80:9c:d2:00:bd:3e:4f:
30:f0:af:4b:3d:5f:9a:55:f9:fa:2c:0b:2c:77:73:
c5:fb:ab:11:71:a2:01
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: critical
TLS Web Client Authentication, TLS Web Server
Authentication
X509v3 Subject Alternative Name:
DNS:sepp1.5gc.mnc010.mnc207.examplecarrier.ipxnetwork.org,
DNS:sepp1.5gc.mnc011.mnc207.examplecarrier.ipxnetwork.org,
DNS:sepp1.5gc.mnc012.mnc207.examplecarrier.ipxnetwork.org
Signature Algorithm: ecdsa-with-SHA256
30:81:87:02:42:01:09:18:bc:30:13:ca:5a:a6:67:40:7d:63:
56:01:17:be:d6:ac:c2:c2:b3:40:3e:97:c8:80:5f:90:c1:92:
dc:b9:b1:49:d2:a9:02:33:d7:1e:35:7e:0a:eb:13:22:b9:70:
78:45:36:2c:85:f5:ce:ce:62:6a:d8:33:5b:08:6f:d6:08:02:
41:45:80:c4:d6:79:2e:d3:6c:e8:34:5a:95:d6:64:3b:66:a5:
30:81:27:43:b5:3a:37:f6:82:f4:3b:63:75:1e:10:dd:f4:80:
d3:c8:9f:4c:0e:40:60:0d:df:fa:1d:3f:7c:cc:c7:33:1d:13:
83:0a:b4:fb:e7:c9:c7:40:85:ef:ba:13

Page 31 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

B.2.4 Outsourced SEPP or MNO Group SEPP certificate issued by IPX entity
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 245515457 (0xea244c1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN= ca1.examplecarrier.ipxnetwork.org, O=Examplecarrier
ltd., ST=Zuid-Holland, C=NL, L=Rotterdam/[email protected]
Validity
Not Before: Aug 6 07:35:36 2021 GMT
Not After : Aug 6 07:35:36 2022 GMT
Subject: CN=sepp1.5gc.mnc010.mnc207.examplecarrier.ipxnetwork.org,
O=Examplephone ltd., ST=Zuid-Holland, C=NL,
L=Rotterdam/[email protected]
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:a2:47:15:e4:be:85:2e:31:4c:b3:86:b0:16:82:
20:d3:ca:85:76:58:a7:c4:23:ca:11:9c:99:61:0d:
34:14:47:67:da:55:c4:65:57:44:54:ad:a3:96:22:
6e:f0:b6:17:d5:2b:d3:84:87:c6:0f:9c:49:c0:80:
12:37:b4:4d:55:2e:a3:dd:80:9c:d2:00:bd:3e:4f:
30:f0:af:4b:3d:5f:9a:55:f9:fa:2c:0b:2c:77:73:
c5:fb:ab:11:71:a2:01
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: critical
TLS Web Client Authentication, TLS Web Server
Authentication
X509v3 Subject Alternative Name:
DNS:sepp1.5gc.mnc010.mnc207.examplecarrier.ipxnetwork.org,
DNS:sepp1.5gc.mnc011.mnc207.examplecarrier.ipxnetwork.org,
DNS:sepp1.5gc.mnc012.mnc207.examplecarrier.ipxnetwork.org
Signature Algorithm: ecdsa-with-SHA256
30:81:87:02:42:01:09:18:bc:30:13:ca:5a:a6:67:40:7d:63:
56:01:17:be:d6:ac:c2:c2:b3:40:3e:97:c8:80:5f:90:c1:92:
dc:b9:b1:49:d2:a9:02:33:d7:1e:35:7e:0a:eb:13:22:b9:70:
78:45:36:2c:85:f5:ce:ce:62:6a:d8:33:5b:08:6f:d6:08:02:
41:45:80:c4:d6:79:2e:d3:6c:e8:34:5a:95:d6:64:3b:66:a5:
30:81:27:43:b5:3a:37:f6:82:f4:3b:63:75:1e:10:dd:f4:80:
d3:c8:9f:4c:0e:40:60:0d:df:fa:1d:3f:7c:cc:c7:33:1d:13:
83:0a:b4:fb:e7:c9:c7:40:85:ef:ba:13

Page 32 of 33
GSM Association Non-confidential
Key Management for 4G and 5G inter-PMN Security

Annex C Document Management

C.1 Document History

Version Date Brief Description of Approval Editor / Company
Change Authority
1.0 6 Mar First version describing key TG DESS members including
2020 management stage 1 solution Martin Kacer (P1
for early 5G roaming Security), Ewout Pronk
agreements and 4G LTE (NetNumber), Pieter
roaming with Diameter end-to- Veenstra (NetNumber),
end security measures as Sven Lachmund
described in FS.19. (Deutsche Telekom),
Andreas Pashalidis (BSI),
Anja Jerichow (Nokia),
Daan Planqué (KPN)
2.0 30 Jun Added requirements related to ISAG Ewout Pronk
2021 N9 operator-to-operator (NetNumber), Martin
security. Updates to naming Kacer (Mobileum),
scheme section. Addition and Andreas Pashalidis (BSI),
application of key word Ahmad Muhanna
conventions (Mavenir), David Maxwell
(GSMA)
3.0 16 Dec Added 5GMRR Phase 1 scope ISAG
Ewout Pronk
2021 definitions and clarifications.
(NetNumber), Roger
Further refinements on the
Piqueras Jover (Google)
entire document
4.0 18 May Simplification of the ISAG
Ewout Pronk
2022 addressing structure for
(NetNumber)
SEPPs.
5.0 19 Oct Added certificate hierarchy ISAG Nataliya Stanetsky &
2022 when 3rd party runs CA. Roger Piqueras Jover,
(Google), Ewout Pronk
(Titan.ium Platform LLC)

C.2 Other Information

Type Description
Document Owner DESS
Editor / Company Ewout Pronk / Titan.ium Platform LLC

It is our intention to provide a quality product for your use. If you find any errors or omissions,
please contact us with your comments. You may notify us at [email protected]

Your comments or suggestions & questions are always welcome.

Page 33 of 33