CMP Within 3GPP Environments
What is CMPv2
Certificate enrolment over Certificate Management Protocol (CMPv2) is a standardized protocol defined in RFC 4210 for managing X.509 certificates. CMPv2 is widely used for automating certificate lifecycle operations such as enrolment, renewal, and revocation. Note that RFC 9480 and RFC9481 provide updates to RFC 4210.
What is 3GPP
3GPP (3rd Generation Partnership Project) is a collaboration between telecommunications standards bodies that develops protocols for mobile telephony. This includes:
- GSM (2G)
- UMTS (3G)
- LTE (4G)
- 5G NR (New Radio)
3GPP defines standards for:
- Radio access networks (RAN)
- Core Networks (e.g. EPC for LTE, 5GC for 5G)
- Service capabilities
- Security frameworks (including authentication, encryption and identity management)
3GPP and CMP
In 3GPP standards, especially in 5G and LTE network security, CMP plays a role in certificate lifecycle management for:
Network Functions (NFs) Authentication:
- 3GPP introduces Service-Based Architecture (SBA) in 5G, where network functions communicate using HTTPS and mutual TLS. CMP is used to provision and manage 509 certificates for these NFs.
gNB (Radio Access Network) and Core Network Communication:
- The gNB (5G base station) requires certificates to securely communicate with the 5G core network. CMP is used during bootstrap or rekeying to:
- Request new certificates
- Update expiring certificates
UICC and eSIM profiles:
- For remotely provisioned UICC (SIM card) or eSIMs, CMP may be used to securely provision device certificates to enable mutual authentication with the network, especially for IoT devices.
CMP References within 3GPP
- CMP is referenced in:
- 3GPP TS 33.310 (Security aspects of the 3GPP access network).
- 3GPP TS 33.210 (Security architecture and procedures for access network entities)
- 3GPP TS 33.501 (Security architecture and procedures for 5G system)
3GPP TS 33.310 – Security for Network Elements Using PKI
TS 33.310 defines the use of Public Key Infrastructure (PKI) for authenticating network elements in 3G and 4G (LTE) networks. It outlines how X.509 certificates are issued, managed, and validated using CMPv2 (RFC 4210).
CMP is used with TS 33.310 for:
Certificate Enrolment and Management:
- CMP is used by network elements (e.g. eNodeB, MME, HSS) to:
- request initial certificates
- Update or revoke certificates
- Retrieve CA certificates and CRLs
Entities involved:
- End Entity (EE): The network node (e.g., base station) requesting a certificate.
- RA (Registration Authority): Optional intermediary for policy enforcement.
- CA (Certification Authority): Issues and manages certificates.
- CMP Server: Interfaces with the CA/RA to handle CMP messages.
Transport Mechanism
- CMP messages are typically sent over HTTP or HTTPS, as specified in RFC 6712.
Security of CMP Messages
- CMP messages are protected using password-based MAC (for bootstrapping) or certificate-based protection (for renewal and revocation).
Bootstrap and Renewal Process
- Bootstrap: The EE authenticates using a shared secret to get its first certificate.
- Renewal: The EE uses its current certificate to request a new one.
3GPP TS 33.501
TS 33.501 defines the comprehensive security architecture for the 5G System (5GS), including authentication, integrity, encryption, and secure service communication.
CMP is used with TS 33.501 for:
Used for SBA (Service-Based Architecture)
- CMP is used for provisioning and managing certificates for Network Functions (NFs) in the 5GC.
- Each NF (like AMF, SMF, PCF) must have an X.509 certificate for establishing mutual TLS (mTLS) connections.
CMP-Based Certificate Operations
- Similar to TS 33.310, the same CMP operations are followed: enrolment, update, revocation.
- Certificates can also be pre-provisioned or dynamically obtained using CMP
Support for multiple PKI Domains
- The architecture allows multiple CAs and PKI domains (e.g., per operator, per trust domain).
- CMP ensures that each domain can manage its certificates securely and independently
Enhanced CMP Usage for IoT and Edge:
- In edge deployments or with constrained devices (like UE or IoT), CMP is simplified or optimized using gateway-based solutions (e.g., proxy RA).
| Aspect | TS 33.310 | TS 33.501 |
| Scope | 3G/4G network element PKI | 5G Network Function (NF) security |
| CMP Use | Certificate issuance, update, revocation | Same, plus dynamic NF certificate management |
| Transport | CMP over HTTP/HTTPS (RFC6712) | Same |
| Authentication | MAC (bootstrap) and certificate based | Same, with optional pre-provisioning |
| Key Entities | EE, RA, CA, CMP Server | NF, SEPP, NRF, UDM, CA |
Role of CMP in 3GPP Environments
CMP is the standard protocol used to securely manage certificates across network entities. It is referenced in multiple 3GPP specifications, notably:
- TS 33.310 – for LTE/4G and general PKI-based security
- TS 33.501 – for 5G networks, particularly Service-Based Architecture (SBA)
Key Components involved
| Component | Description |
| End Entity (EE) | The node requesting a certificate (e.g. eNodeB, gNB, AMF, UDM) |
| Registration Authority (RA) | Optional intermediary to validate and forward requests |
| Certification Authority (CA) | Issues and revokes certificates |
| CMP Server | Implements CMP Endpoints for handling protocol messages |
CMP Message Exchange Use Cases
Initial Enrolment (Bootstrap)
- A network element (e.g., a gNB) generates a key pair and sends a CMP Initialization Request (IR) to the CA or via an RA.
- Authentication can be:
- Shared secret (MAC-based) for first-time setup; or
- existing certificate for renewal scenarios
- CA returns a certificate via an Initialisation Response (IP)
Certificate Renewal
- An entity with a valid certificate signs a CMP Key Update Request (KUR).
- CA verifies and returns the new certificate, replacing the old one.
Certificate Revocation
- The entity (or RA) sends a Revocation Request (RR) when a key is compromised or no longer needed.
- CA responds with a Revocation Response (RP) and updates the CRL.
CA Certificate and CRL Retrieval
- Entities can request CA certificates or CRLs using CMP messages to keep trust anchors and revocation lists up to date.
CMP in Specific 3GPP Use Cases
In LTE / TS 33.310
- eNodeBs use CMP to get certificates used for IPSec tunnels to the EPC.
- Certificates authenticate:
- Certificates authenticate
- MME to HSS, etc.
In 5G / TS 33.501
- Used for mTLS setup in SBA.
- All network functions (e.g., AMF, SMF, PCF, AUSF) require valid certificates for service discovery and secure communication.
- CMP enables:
- Dynamic certificate provisioning
- Rotation without downtime
- Integration into operator PKI or third-party trust models
CMP Message flow in 3GPP
[EE (e.g., gNB)] —> IR —> [RA/CMP Server] —> [CA]
[CA] —> IP —> [RA/CMP Server] —> [EE]
- Messages can be transported over HTTP(S) as per [RFC 6712]
- TLS protection is used for CMP over HTTPS, and the messages themselves can be signed/encrypted using CMS
Benefits of CMP in 3GPP
- Automated certificate management.
- Secure and scalable in distributed network environments
- Compliant with Zero Trust principles
- Supports network slicing and multi-domain PKI
TLS bootstrapping and Mutual Authentication
The processes described here enable secure mutual TLS (mTLS) between two NFs (e.g., AMF and SMF), where both use X.509 certificates provisioned via the Certificate Management Protocol (CMP
Key Components Involved
| Component | Role |
| NF (e.g. AMF) | A network function that must authenticate and communicate securely |
| NF (e.g. SMF) | The peer network function |
| PKI System | Includes CA and optionally an RA |
| CMP Server | Endpoints (CA.RA) supporting CMP over HTTP(S) |
| Network Repository Function (NRF) | Registers in the NF and shares end point / service information |
| Service-Based Interfaces (SBI) | Use HTTPS with mTLS for communication |
Step by Step Walkthrough:
- Key Generation:
- Each NF (e.g. AMF) generates:
- A key pair (public and private)
- A Certificate Signing Request (CSR) wrapped in a CMP Initialization Request (IR) message.
- Each NF (e.g. AMF) generates:
NF Generates: Public key + Private key -> wraps in CMP IR Message
- Initialization Request via CMP:
- The CMP IR includes:
- Subject name (NF ID, domain etc.)
- Public key info
- The CMP IR includes:
- Proof of Possession of private key
- Optional authentication data (e.g. shared secret or certificate-based)
- The IR is sent to the CMP Server over the HTTP(S).
NF -> CMP -> RA/CMP Server -> CA
- Certificate Issuance:
- The CA:
- validates the request (via RA if applicable)
- Verifies proof of possession.
- The CA:
- Issues the certificate.
- The CA replies with a CMP Initialization Response (IP) containing:
- X.509 Certificate
- Optionally, a CA chain and CRL pointers
CA -> CMP IP -> RA/CMP Server -> NF
- Certificate Installation:
- The NF(e.g. AMF):
- Stores the certificate
- Stores the private key securely
- The NF(e.g. AMF):
- Associates it with the CA trust anchor.
- Optionally fetches CRLs or OCSP stapling information
- The NF is ready to authenticate using its identity certificate.
- NF Registration with NRF
- The NF uses the certificate to register itself with the Network Registry Function (NRF) over mTLS
AMF -> HTTPS (mTLS) -> NRF
- The NRF stores the identity and the TLS endpoint of the AMF
- Mutual TLS with Peer NF
- Another NF (e.g. SMF) also having completed CMP provisioning, queries the NRF and discovers the AMF’s endpoint.
- The SMF initiates an HTTPS connection with the AMF using mutual TLS:
- Both ends present their certificates
- The TLS handshakes verify both identities using the certificates and trust anchors.
SMF > HTTPS (mutual TLS) > AMF
Certificate Renewal via CMP
Before expiration:
- The NF sends a CMP Key Update Request (KUR)
- Receives a new certificate in the Key Update Response (KUP).
Having this process automated avoids downtime due to certificate expiration.
Security Notes
- CMP messages are signed or MAC-protected to prevent tampering
- CA certificates and revocation data (CRL/OCSP) must be verified regularly.
- Certificates used must comply with TS 33.310 format including proper Subject fields and extensions.
Summary of Certificate Format
3GPP mandates the use of X.509 v3 certificates as per [ITU-T X.509 (2016)] and [RFC 5280].
Key fields and structure
| Field | Description |
| Version | Must be v3 (value = 2) |
| Serial Number | Unique identifier assigned by the CA |
| Signature Algorithm | E.g. sha256WithRSAEncryption, ecdsa-with-SHA256 |
| Issuer | Distinguished Name (DN) of the issuing CA |
| Validity | Not before / Not after timestamps |
| Subject | DN of the entity (e.g. CN=AMF1.Ops.5G.example.com) |
| Subject Public Key info | Public key algorithm and value (e.g., RSA 2048-bit or EC P-256) |
| Extensions | V3-specific info (see below) |
| Signature | Signature over the tbsCertificate using CA’s private key |
Mandatory v3 Extensions in TS 33.310
TS 33.310 mandates specific extensions to support interoperability and security within telecom networks:
| Extension | Required | Critical | Notes |
| BasicConstraints | Yes | Yes | CA:FALSE for end-entity certs |
| KeyUsage | Yes | Yes | digitalSignature, keyEncipherment (or keyAgreement) |
| ExtendedKeyUsage (EKU) | Yes | No | E.g., id-kp-serverAuth, id-kp-clientAuth |
| SubjectAltName | Yes | No | Fully Qualified Domain Name (FQDN) or IP Address of the NF |
| AuthorityKeyIdentifier | Yes | No | Key ID of the Issuing CA |
| Subject Key Identifier | Yes | No | Unique hash of subject public key |
| CRLDistributionPoints | Yes | No | URI of CRL |
| Autthroity Information Access | Optional | No | OCSP URI or CA issuer URL |