Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.310  Word version:  16.4.0

Top   Top   Up   Prev   None
0…   5…   5.2…   6…   7…   8   9…   B…   C…

 

C  Decision for the CRL repository access protocol for SEGsWord‑p. 50
In order to document the decision for the protocol for SEGs to access CRL repositories, this section summarises technical advantages and disadvantages of the two candidates.
LDAP
  • +  implemented by all PKI products (unless purely manual)
  • +  scalability
  • +  flexibility (integration possibility to other systems, automatic public key retrieval possibility)
  • -  complexity
HTTP
  • +  simple
  • -  not supported by all PKI products (although widely supported)
LDAP was chosen as the more future-proof protocol. Although more complex than HTTP, LDAP is well established amongst PKI vendors and operators.
Up

D  Decision for storing the cross-certificates in CRWord‑p. 51
In order to document the decision for storing the cross-certificates in Certificate Repository, fetching those with LDAP and caching them in SEGs, this section summarises technical advantages and disadvantages of the three alternatives.
The following table summarizes differences between alternatives:
Issue
A) Cross-certificates are stored into SEGs:
B) Cross-certificates are stored into CRs:
C) Cross-certificates are stored into CRs and cached in SEGs upon usage:

1)
Initialization issues: storing the cross-certificate during the cross-certification
The cross-certificate is initially stored in several places, that is, into all SEGs (estimated number is between 2 and 10).
Pros: -
Cons: Certificate must be initially copied in several places. SEGs from different manufacturers may have other O&M interfaces to handle the certificates.
The cross-certificate is initially stored in CR.
Pros: The handling is fully standardized. Certificate is initially copied in one place only. The operator should have the repository anyway (due to CRL handling).
Cons: -
The cross-certificate is initially stored in CR.
Pros and cons as in B).
2)
Usage issues: latency during the IKE Phase 1
Pros: No extra latency
Cons: -
Pros: -
Cons: More latency caused by extra LDAP query (the cross-certificate is queried)
Pros & cons: as in B) at the first time, and as in A) at subsequent times
3)
Cleanup issues: removing the cross-certificate
Pros: -
Cons: The cross-certificate has to be removed from several places, that is, from all SEGs
Pros: The cross-certificate has to be removed from one single place only
Cons: -
Pros: -
Cons: The cross-certificate has to be removed from both CR and each SEG.
NOTE:
this functionality is needed only to be able to revoke cross-certificates before the next CRL gets published.
4)
Security issues
Pros: No single point of failure exists.
Cons: -
Pros: -
Cons: CR represents a single point of failure suitable for an attacker, e.g. to submit a denial of service attack by breaking the communication at the CR.
Pros: Single point of failure partly mitigated
Cons: -

Analysis:
  • Alternative B) requires one additional LDAP query in every IKE Phase 1 negotiation and will introduce new error cases
  • Latency of LDAP: information from LDAP to local disk is cached and populating it takes some time, but in practice this time is not significant.
  • The benefit of alternative B) and C) compared to alternative A) is easier management, that is, storing and removing the certificate in/from one single place only.
Conclusion:
alternative C) is the most feasible choice, because it combines good points of alternatives A) and B).
Up

E  TLS protocol profile |R8|Word‑p. 52
The TLS protocol profiles are located in TS 33.210.

F  Manual handling of TLS certificates |R8|Word‑p. 53

F.0  General |R13|

The purpose of this annex is to provide alternative guidelines for TLS certificate handling in case of the absence of the authentication framework for TLS certificates.
Within this Annex following abbreviations are used: CA A is the certification authority in A's network and CA B is the certification authority in B's network. Cert A is the certificate of A and Cert B is the certificate of B. IA is the set of identifiers that A may use for identification towards B. TB is the set of peers trusted by B.
Up

F.1  TLS certificate enrolment

Mutual authentication in TLS is achieved based on public key technology and certificates. Both TLS peers A and B need to contain a certificate store and there shall be at least one certification authority CA that can issue certificates within the security domains in with A and B are part of. Cert A contains the set IA of A's identifiers. Each identifier is in the form of fully qualified domain name (FQDN). Similarly, B's certificate is Cert B.
The certificates in the store of B define the group TB of peers trusted by B. There are several options for creation and enrolment of certificates, three of which are described below.
1)
In one option there is a certification authority, CA B, only in the network of B. CA B issues a certificate Cert B to B and a certificate Cert A to A. The certificates are delivered from CA B to A and B in a secure way "out of band". Both A and B then add their peer into the group of their trusted peers by inserting that peer's certificate into the certificate store: A inserts Cert B into A's certificate store and B inserts Cert A into B's certificate store. This insertion is typically manual and the details depend on the implementation of the management interface to the certificate store.
2)
In another option both A's and B's networks contain certification authorities, CA B and CA A, respectively. CA B issues a certificate Cert B to B and CA A issues a certificate Cert A to A. The certificates are delivered from CA B to A and from CA A to B in a secure way "out of band". Both A and B then add their peer into the group of their trusted peers by inserting that peer's certificate into the certificate store: A inserts Cert B into A's certificate store and B inserts Cert A into B's certificate store.
3)
In a third option the CA certificates of both sides are exchanged: the certificate of CA B is delivered to A and the certificate of CA A is delivered to B in a secure way "out of band"', inserted to the certificate store, and marked trusted. The validation of Cert A and Cert B, that are exchanged during TLS handshake, is based on the presence of the corresponding CA certificates in the certificate store.
Up

F.2  TLS Certificate revocation

In the absence of PKI-revocation interfaces, certificate revocation needs to be performed manually. The revocation operation involves the removal of A from the group TB of peers trusted by B. In the first two enrolment options described above the revocation happens by B removing the certificate of A, Cert A, from its certificate store. This removal can be done manually. In the third option the certificate of A, Cert A, is not in B's certificate store. For that reason B has to have a way to check the validity of Cert A with the issuer of the certificate (also in the first two enrolment options the amount of manual maintenance operations will decrease if B can check the validity of Cert A with the issuer of the certificate). This check may be done by using Online Certificate Status Protocol (OCSP) RFC 6960 or by using Certificate Revocation Lists (CRLs) RFC 5280 published by the issuer of Cert A.
Up

G  Example CMPv2 Message Flow for Initial Enrolment |R9|Word‑p. 54
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 must be 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.
Reproduction of 3GPP TS 33.310, Figure 8: Example message flow for initial base station enrolment
Up
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.
Up

H  Guidance on eNB Certificate Enrolment in MOCN LTE RAN sharing |R12|Word‑p. 57
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 specification 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.
Up

$  Change historyWord‑p. 58

Up   Top