Content for TS 33.310 Word version: 18.2.0
G Example CMPv2 message flow for initial enrolment
H Guidance on eNB certificate enrolment in MOCN LTE RAN sharing
G Example CMPv2 message flow for initial enrolment |R9| p. 65
The purpose of this Annex is to provide an overview how the initial enrolment of a base station may be executed.
The message flow for an initial enrolment of a base station to the RA/CA is shown in Figure 8 below. The text below the Figure gives a description of this message flow. Precondition for this message flow is that the base station contains the vendor provided private/public key pair and is pre-provisioned with the related base station certificate signed by a vendor CA. If there is a certificate chain up to the vendor root CA, also the intermediate certificates are pre-provisioned to the base station. The RA/CA is configured with the root certificate of the vendor and its own certificate(s). The exchanged messages are protected by setting the PKIHeader fields "protection" and "protectionAlg". Example of protectionAlg is set to the value {1 2 840 11359 1 1 11} (sha256With RSAEncrypt) when RSA and SHA-256 is used.
Step 1.
The base station discovers the RA/CA address.
Step 2.
The base station generates the private/public key pair to be enrolled in the operator CA, if this is not pre-provisioned.
Step 3.
The base station generates the Initialization Request (ir). The CertReqMsg inside ir specifies the requested certificate. If the suggested identity is known to the base station, it includes this in the subject field. To provide proof of possession the base station generates the signature for the POPOSigningKey field of the CertReqMsg using the private key related to the public key to be certified by the RA/CA. The base station signs the ir using the vendor provided private key, and includes the digital signature in the PKIMessage. Its own vendor signed certificate and any intermediate certificates are included in the extraCerts field of the PKIMessage carrying the ir.
Step 4.
The base station sends the signed ir message to the RA/CA.
Step 5.
The RA/CA verifies the digital signature on the ir message against the vendor root certificate using the certificate(s) sent by the base station. The RA/CA also verifies the proof of the possession of the private key for the requested certificate.
Step 6.
The RA/CA generates the certificate for base station. If the suggested identity of the base station is not included in the ir message, the RA/CA determines the suggested identity of the base station, e.g. based on the vendor provided identity of the base station contained in the base station certificate.
Step 7.
The RA/CA generates an Initialization Response (ip) which includes the issued certificate and uses the same certReqId value as in the Initialization Request. The RA/CA signs the ip with the RA/CA private key (or the private key for signing CMP messages, if separate), and includes the signature, the RA/CA certificate(s) and the operator root certificate in the PKIMessage. The appropriate certificate chains for authenticating the RA/CA certificate(s) are included in the PKIMessage.
Step 8.
The RA/CA sends the signed ip to the base station.
Step 9.
If the operator root certificate is not pre-provisioned to the base station, the base station extracts the operator root certificate from the PKIMessage. The base station authenticates the PKIMessage using the RA/CA certificate and installs the base station certificate on success.
Step 10.
The base station creates and signs the CertificateConfirm (certconf) message. The CertficateConfirm message uses the same certReqId value as in the Initialization Request.
Step 11.
The base station sends the PKIMessage that includes the signed CertificateConfirm to the RA/CA.
Step 12.
The RA/CA authenticates the PKI Message that includes the CertificateConfirm.
Step 13.
The RA/CA creates and signs a Confirmation message (pkiconf).
Step 14.
The RA/CA sends the signed PKIMessage including the pkiconf message to the base station.
Step 15.
The base station authenticates the pkiconf message.
H Guidance on eNB certificate enrolment in MOCN LTE RAN sharing |R12| p. 67
3GPP TS 23.251 defines two basic models for network sharing, namely the Gateway Core Network (GWCN) configuration and the Multi-Operator Core Network (MOCN) configuration. TS 23.251 does not guide on SEG placement in the architecture. In some LTE RAN sharing deployments according to the MOCN configuration, the eNB may need to connect not only to SEGs deployed by the hosting operator but also to SEGs deployed by participating operators. These SEGs are equipped with certificates issued by the RAs/CAs of the operators to which they belong.
The shared eNB is provisioned with the root certificate of the hosting operator's CA and an eNB certificate issued by the hosting operator's CA after the successful certificate enrolment procedure specified in clause 9 of the present document has been performed successfully. An IPsec security association between the eNB and the SEG of hosting operator can be set up and a link with an OAM entity can then be established. It is assumed that the shared eNB is managed by a single O&M entity controlled by the hosting operator.
The issue addressed in this Annex is when an IPsec security association between the eNB and the SEG of a participating operator is wanted. This cannot succeed because neither the shared eNB nor the SEG of the participating operator can verify the certificate held by the other entity unless additional steps are taken. Two solutions can be used to solve this issue.
Solution 1
The shared eNB can be provisioned with the root certificates of the participating operators' CAs by the OAM entity managing the eNB. Consequently the eNB can verify the certificates of the SEGs of the participating operators.
The SEGs of participating operators can be provisioned with the root certificate of the hosting operator's CA so that the SEGs of participating operators can verify the shared eNB certificate issued by the hosting operator. Consequently the shared eNB and the SEGs of the participating operators can set up IPsec security associations between them.
Solution 2
The shared eNB can be provisioned with the necessary participating operators' RA/CA information (e.g., address of the participating operators' RAs/CAs, root certificates of the participating operators' RAs/CAs, etc) by the OAM entity managing the eNB . The shared eNB can then perform the certificate enrolment procedure specified in clause 9 with every participating operator RA/CA. The shared eNB can get the root certificates of the participating operators' CA and the eNB certificate issued by the participating operators' RA/CA. Consequently the shared eNB and the SEGs of the participating operators can set up IPsec security associations between them.
