This clause specifies the following certificate management procedures in SBA for 5GC NFs:
Set up of initial trust between NF and operator CA/RA.
Certificate enrolment and renewal for 5GC NFs.
Validation of usage of X.509 certificates in SBA.
Certification revocation procedures.
The validation of the trust chain of CA hierarchy is required, ensuring the legitimacy and credibility of the CA. The solutions to establish the trust chain of CA hierarchy are left to implementation.
Other mechanisms and use cases related to certificate management for 5GC NFs are described in informative Annex I and left to implementation.
This clause describes the architecture and the procedures for the set up of the initial trust between the operator CA/RA and the NF or the end entity acting on behalf of the NF for the certificate enrolment.
The protection of the NF certificate enrolment procedure has the prerequisite to build initial trust between the 5GC NF and the operator CA/RA.
OAM facilitates the initial trust establishment between NF and operator CA/RA.
Figure 10.2.2-1 depicts the general schema to set up initial trust between 5GC NF and operator CA/RA.
The assumption is that the OAM system is trusted for the operator CA/RA, i.e., the trust between the OAM system and the operator CA/RA shall have been preestablished.
The OAM system of the 5GC NF, which instantiates the NF, shall provide it with the initial trust to be used during the 5GC NF operator certificate enrolment procedure, as part of the initial configuration of the NF.
Three options are described below on how to set up the initial trust. The initial trust can be implemented by 1) OAM issued certificates, 2) an Initial Authentication Key (IAK), or 3) OAM issued signature of certain NF profile parameters. The initial trust shall be implemented by one of these mechanisms. The requirements are the following:
The deployment of the initial trust as OAM certificate requires the configuration of a local CA used for 5GC NFs within SBA domain (specifically within the same security trust domain of the NF managed by the OAM system), and the configuration of the root CA public certificate of the local CA as trust anchor in the operator CA/RA.
The deployment of the initial trust as IAK requires the distribution of such key out-of-band between the operator CA/RA and the NF via OAM system. This initial credential is used as initial trust by the operator CA/RA to authenticate the NF. The management aspects of IAK are left to implementation (e.g., provisioning, one time use, etc.).
The deployment of the signature of certain NF profile selected parameters requires the pre-configuration of such signature out-of-band in the NF. The signature is used by the operator CA/RA to authenticate the NF. The selection of the parameters considered in the signature is left to implementation.
The operator CA/RA shall be able to verify that the NF Instance Id in the certificate enrolment request belongs to the NF instance requesting the certificate.
The OAM system shall configure the initial trust used for the enrolment of the operator certificate in the 5GC NF. If the initial trust is established by an initial certificate during or after the NF initialization, the local CA in the OAM system should issue such initial certificate to the NF as part of its configuration. This certificate shall be configured with the NF Instance Id in SubjectAltName field. The fetching procedure of this certificate by the NF is left to implementation.
The 5GC NF generates the private-public key pair and the request of an EE operator certificate to the operator CA/RA. The Certificate Signing Request (CSR) shall include the initial trust (initial OAM issued certificate, signature of NF profile parameters, or IAK) fetched in step 1 and the NF Instance Id in SubjectAltName field. The NF shall sign the request with its private key and includes the digital signature in the request.
If the initial trust is established by an initial certificate, the request shall include the certificate chain of local CA.
If the initial trust is established by IAK, the Operator CA/RA shall validate CSR using the IAK.
If the initial trust is established by a signature of NF profile parameters, the operator CA/RA shall verify the signature in the CSR.
The operator CA/RA shall verify the initial trust in the request from the NF and the identity of the NF (NF Instance Id). If verified, the operator CA/RA shall generate the EE operator certificate for the NF. Specifically, by checking the digital signature on the certificate enrolment request against the trust anchor configured in step 1, and the proof of possession of the private key for the requested operator certificate. It shall verify as well that the NF Instance Id in the SubjectAltName field of the Certificate Enrolment Request corresponds to the NF Instance Id of the initial OAM issued certificate. If those verifications are successful, the operator CA/RA shall generate an EE certificate for the 5GC NF.
The following requirements shall apply to CMPv2 usage in Service Based Architecture:
This CMPv2 profile shall only include certificate request and key update functions. Revocation processing, Cross-Certification and PKCS#10 requests shall not be part of this CMPv2 profile.
For PKI Message integrity protection, this CMP profile shall only use asymmetric algorithms, or alternatively use shared secret information established via out-of-band means as defined in RFC 4210.
If shared secret information is used, it is recommended to use individual one-time secrets. Shared secrets for all NFs shall not be used.
The NF may be pre-provisioned with the operator root CA certificate.
If the NF is not pre-provisioned with the operator root CA certificate, then the NF shall take the operator root certificate from the certificates received in the initialization response. The selection shall be based on checking which root certificate can be used to validate the received NF certificate.
The RA/CA shall support the authentication of initialization requests (ir) based on the verification of out-of-band distributed Initial Authentication Key (IAK) and reference value (mandatory scheme in RFC 4210).
The RA/CA shall authenticate key update requests based on signatures which are validated against the operator root CA.
The RA/CA shall be configured with the SBA root certificate of the operator.
The RA/CA shall be configured with a RA/CA certificate which is signed either by the operator root CA or by an intermediate CA under the operator root CA.
If the RA/CA uses different private keys to sign the generated certificates and the CMPv2 messages, the RA/CA shall be configured with the two related certificates, i.e., the RA/CA certificate for signing signatures and the RA/CA certificate for signing CMP messages.
If the RA/CA certificate or certificates (two in case separate private keys are used for signing of certificates and CMP messages) are not signed directly by the operator root CA, also the certificates of the intermediate CAs shall be configured into the RA/CA.
The hash algorithms used before generating signatures in the protection field of PKIMessage and for proof-of-possession shall be the same as the hash algorithms specified in subclause 6.1.1 for certificate signatures. The signature algorithms shall be the same as that used in the related certificate profile.
The following profile is applied to the PKIMessage as specified in RFC 4210:
The support and usage of the optional protection field of type PKIProtection is required by this profile. The message-specific private key to be used in the NF is specified in the subclause 10.3.1.4 in the profiling of the single PKI message bodies for requests sent by the NF. For the RA/CA the RA/CA private key shall be used, or the separate RA/CA private key for signing CMP messages, if NF certificates and CMPv2 messages are signed by different private keys.
The support of the optional extraCerts field is required by this profile. The certificates within this field may be ordered in any order. The message-specific content of this field is specified in the subclause 10.3.1.4 in the profiling of the single PKI message bodies.
All CMPv2 messages used within this profile shall consist of exactly one PKIMessage, i.e., the size of the sequence for PKIMessages shall be 1 in all cases.
The following profile is applied to the PKIHeader field as specified in RFC 4210:
The sender field shall contain the identity of the NF as EE. This identity shall be identical to the subject name of the NF instance present in the certificate for the public key whose related private key is used to sign the PKIMessage.
The recipient field shall contain the identity of the RA/CA.
As the field "protection" of PKIMessage is mandatory, also the field "protectionAlg" of PKIHeader is mandatory. The protectionAlg shall be of type MSG_SIG_ALG. The signature algorithm shall be based upon the algorithm contained in the algorithm field of the SubjectPublicKeyInfo field of the signer's certificate (belonging to the NF or the RA/CA). The hash algorithm used before signing the PKIMessage shall follow the same specification as given for usage before certificate signing in clause 6.1.1 of the present document.
The usage of the transactionID field is mandatory. The recommended procedures for handling of the transactionID given in  shall be followed. The NF shall set this field to a random number that is at least 8 bytes long for the first message and use the same random number in any subsequent message in the transaction.
The usage of the senderNonce and the recipNonce fields is mandatory. The length of the fields as recommended in  shall be used. The recipNonce in the very first message in the transaction should be set to 0 by the sender and shall be disregarded by the recipient of the message.
The Initialization Request as specified in RFC 4210 shall contain exactly one CertReqMessages as specified in RFC 4210 and RFC 4211, i.e., the size of the sequence for CertReqMessages shall be 1 in all cases.
The following profile shall be applied to the CertReqMessage field and its sub-fields:
The subjectAltName field of the CertTemplate contains the nfInstanceID of the NF.
The publicKey field of the CertTemplate is mandatory and shall contain the public key of the NF to be certified by the RA/CA. The private/public key pair may be pre-provisioned to the NF, or generated inside the NF, or generated by a certificate management NF acting on behalf of the NF, for the CMPv2 protocol run. The format of this field shall follow RFC 5280.
The CertReqMessage shall contain a POP field of type ProofOfPossession. The POP field shall contain a signature field of type POPOSigningKey. The algorithmIdentifier field of the POPOSigningKey field shall contain the signing algorithm which is used by the NF to produce the Proof-of-Possession value, i.e., the signature within POPOSigningKey field.
If the poposkInput field of type POPOSigningKeyInput within POPOSigningKey field is used, the sender field within POPOSigningKeyInput shall be mandatory and shall contain the identity of the NF Instance ("nfInstanceID").
The PKIMessage sent by the NF is signed by the generated or provided private key.
The Initialization Response as specified in RFC 4210 shall contain exactly one generated NF certificate, i.e., the size of the sequence for CertResponse shall be 1 in all cases.
The following profile shall be applied to the CertRepMessage field and its sub-fields:
The generated certificate shall be transferred to the NF in the certifiedKeyPair field of the CertResponse field. The transfer shall not be encrypted (i.e., the certificate field in CertorEncCert is mandatory).
The extraCerts field of the PKIMessage carrying the initialization response shall be mandatory and shall contain the operator root certificate (or 'full chain' if NF contacted to SubCA using CMPv2) and the RA/CA certificate (or certificates if separate private keys are used for signing of certificates and CMP messages). If the RA/CA certificate(s) are not signed by the operator root CA, also the intermediate certificates for the chain(s) up to the operator root certificate shall be included in the extraCerts field. If additional (self-signed) Root CA certificates are required, they shall be carried in the extraCerts field or caPubs field of the PKIMessage. Since extraCerts field is not under CMP message integrity protection, CMP over TLS should be used as a security transport mechanism. Since CMP already supports integrity protection for caPubs field, the use of security transport mechanisms is optional.
The Certification Request (cr) and Certification Response (cp) messages as specified in RFC 4210 and RFC 4211 are intended to be used when additional certificates with specific purpose are required by the NF.
The structure and content of these messages is identical to initialization requests and responses, thus the profiling given in the previous subclauses for Initialization Request and Initialization Response shall equally apply, with the following exceptions:
The PKIMessage sent by the NF shall be signed with the private key which is related to the last received operator provided NF certificate. The extraCertsField is mandatory and shall contain the NF certificate related to the private key used for signing the PKIMessage. Any intermediate CA certificates shall also be included if the NF certificate is not signed directly by a root CA.
The PKIMessage carrying the certification response should not contain the operator root certificate in the extraCerts field.
The structure and content of these messages is identical to initialization requests and responses, thus the profiling given in the previous subclauses for Initialization Request and Initialization Response apply equally, with the following exceptions:
The PKIMessage sent by the NF shall be signed with the private key which is related to the last received operator provided NF certificate. The extraCertsField is mandatory and shall contain the NF certificate related to the private key used for signing the PKIMessage. Any intermediate CA certificates shall also be included, if the NF certificate is not signed directly by a root CA.
The PKIMessage carrying the key update response should not contain the operator root certificate in the extraCerts field.
Initialization responses and key update responses shall always be followed by a Certificate Confirm request and Confirmation response message exchange.
The PKIMessage sent by the NF shall be signed by the same private key which was used in the preceding initialization request or key update request.
The extraCerts field of the PKIMessage carrying the Certificate Confirm request and Confirmation response shall be omitted.
Transport of CMPv2 messages between end entities (network elements) and RA/CA shall be done using HTTP-based protocol as specified in RFC 6712, with the exception that support for TLS is not mandated.
Support is mandatory for communication initiated by the end entities where every CMP request triggers a CMP response message from the CA or RA. Support for RA/CA initiated HTTP requests (i.e., announcements) is not mandatory.
Operator RA/CA should be able to verify that the nfinstanceID in the certificate signing request ('ir' and 'cr' messages in CMP protocol) belongs to the NF instance requesting the certificate.
During the set up of initial trust between NF and operator RA/CA, the operator RA/CA gets to know the NF identity (nfInstanceID), that can be verified at the certificate enrolment and renewal procedures. Note that the nfInstanceID is included in Subject Alt Name field as per the SBA certificate profile in 6.1.3c.
The 5G Core NFs in SBA might need to support multiple operator certificates for different purposes, such as TLS authentication, JSON signing and JSON encryption (e.g., for signing access tokens for service access authorization, signing CCA tokens, etc.).
The Extended Key Usage (EKU) extension of the X.509 certificate as defined in RFC 5280 and IETF draft-ietf-lamps-nf-eku-01  can be used to indicate the purpose of the X.509 certificates used in SBA. Accordingly, the CA is expected to be configured with policies to validate the purpose of the certificate and add it to the issued certificate, thus the usage of the certificate can be further verified in corresponding procedures (e.g., TLS authentication).
In the implementation of a certificate lifecycle management framework, the NF lifecycle can be considered.
For example, when the certificate of an NF producer instance has been revoked without the knowledge of the NRF, the NRF might return that instance to the NF consumer during the discovery procedure, leading to unnecessary signalling due to the use of non-valid certificates. In that case, during the NF discovery procedure, the NRF may check that the potential producers, to be included in the response, do have valid certificates. How such a check is performed is left to implementation. For example, it can be based on locally stored information or by querying other network entities such as OCSP/CRL servers.