F.2 TLS Certificate revocation
33.3103GPPAuthentication Framework (AF)Network Domain Security (NDS)TS
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, CertA, from its certificate store. This removal can be done manually. In the third option the certificate of A, CertA, is not in B’s certificate store. For that reason B has to have a way to check the validity of CertA 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 CertA with the issuer of the certificate). This check may be done by using Online Certificate Status Protocol (OCSP) RFC 6960 [47 or by using Certificate Revocation Lists (CRLs) RFC 5280 [14] published by the issuer of CertA.
Annex G (informative):
Example CMPv2 message flow for initial enrolment
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.
Figure 8: Example message flow for initial base station enrolment
1. The base station discovers the RA/CA address.
2. The base station generates the private/public key pair to be enrolled in the operator CA, if this is not pre-provisioned.
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.
4. The base station sends the signed ir message to the RA/CA.
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.
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.
NOTE: The procedures for determination of the base station identity used by the operator are not in scope of the present document. According to [4], the RA/CA can replace a suggested identity sent by the base station with another identity based on local information.
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.
8. The RA/CA sends the signed ip to the base station.
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.
10. The base station creates and signs the CertificateConfirm (certconf) message. The CertficateConfirm message uses the same certReqId value as in the Initialization Request.
11. The base station sends the PKIMessage that includes the signed CertificateConfirm to the RA/CA.
12. The RA/CA authenticates the PKI Message that includes the CertificateConfirm.
13. The RA/CA creates and signs a Confirmation message (pkiconf).
14. The RA/CA sends the signed PKIMessage including the pkiconf message to the base station.
15. The base station authenticates the pkiconf message.
Annex H (informative):
Guidance on eNB certificate enrolment in MOCN LTE RAN sharing
3GPP TS 23.251 [31] defines two basic models for network sharing, namely the Gateway Core Network (GWCN) configuration and the Multi-Operator Core Network (MOCN) configuration. 3GPP TS 23.251 [31] 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.
Annex I (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2004-03 |
SP-23 |
SP-040168 |
– |
– |
Presented for approval at TSG SA #23 |
1.1.0 |
2.0.0 |
|
2004-03 |
SP-23 |
– |
– |
– |
Approved and placed under Change Control (Rel-6) |
2.0.0 |
6.0.0 |
|
2004-06 |
SP-24 |
SP-040393 |
001 |
– |
Removal of inconsistencies regarding SEG actions during IKE phase 1 |
6.0.0 |
6.1.0 |
|
2004-06 |
SP-24 |
SP-040394 |
002 |
– |
Removal of unnecessary restriction on CA path length |
6.0.0 |
6.1.0 |
|
2004-06 |
SP-24 |
SP-040395 |
003 |
– |
Correction of ‘Extended key usage’ extension in SEG Certificate profile |
6.0.0 |
6.1.0 |
|
2004-09 |
SP-25 |
SP-040623 |
004 |
– |
Splitting the Roaming CA into a SEG CA and an Interconnection CA |
6.1.0 |
6.2.0 |
|
2005-12 |
SP-30 |
SP‑050654 |
– |
– |
Raised to Rel-7 to allow reference by TISPAN |
6.2.0 |
7.0.0 |
|
2006-09 |
SP-33 |
SP-060507 |
0005 |
– |
Extending NDS/AF to support TLS |
7.0.0 |
7.1.0 |
|
2006-09 |
SP-33 |
SP-060504 |
0006 |
– |
Clarifications and corrections |
7.0.0 |
7.1.0 |
|
2006-09 |
SP-35 |
SP-070162 |
0008 |
– |
Specification of TLS protocol profile for future TLS endpoints |
7.1.0 |
8.0.0 |
|
2007-06 |
SP-36 |
SP-070335 |
0009 |
1 |
Correction of MCC implementation error for CR0008 |
8.0.0 |
8.1.0 |
|
2008-03 |
SP-39 |
SP-080143 |
0016 |
– |
Introduce Manual TLS certificate handling |
8.1.0 |
8.2.0 |
|
2008-03 |
SP-39 |
SP-080145 |
0017 |
1 |
Introducing a certificates-based Zb-interface and adding IKEv2 |
8.1.0 |
8.2.0 |
|
2008-03 |
Editorial correction ("NOTE" -> "Note") |
8.2.0 |
8.2.1 |
||||
|
2009-06 |
SP-44 |
SP-090274 |
0020 |
— |
Corrections for TS 33.310 |
8.2.1 |
8.3.0 |
|
2009-06 |
SP-44 |
SP-090274 |
0021 |
— |
Correction for TS 33.310: when a SEG may fetch a CRL for peer SEG |
8.2.1 |
8.3.0 |
|
2009-06 |
SP-44 |
SP-090274 |
0022 |
— |
Miscellaneous corrections to specification |
8.2.1 |
8.3.0 |
|
2009-06 |
SP-44 |
SP-090 |
0019 |
Update of referenced RFCs and hash algorithm |
8.3.0 |
9.0.0 |
|
|
2009-12 |
SP-46 |
SP-090859 |
0024 |
1 |
Some corrections for TS 33.310 |
9.0.0 |
9.1.0 |
|
2010-03 |
SP-47 |
SP-100106 |
0025 |
1 |
NDS enhancement to support backhaul security |
9.1.0 |
9.2.0 |
|
2010-03 |
SP-47 |
SP-100103 |
0029 |
– |
Alignment of TLS profile in NDS with TR-069 profile in H(e)NB |
9.1.0 |
9.2.0 |
|
2010-04 |
— |
— |
— |
— |
Corrections of clause references in clause 9 and editorial corrections in Annex E. |
9.2.0 |
9.2.1 |
|
2010-06 |
SP-48 |
SP-100250 |
0031 |
2 |
Correction of SEG CA and TLS client/server CA certificate profiles |
9.2.1 |
9.3.0 |
|
2010-06 |
SP-48 |
SP-100361 |
0034 |
1 |
Deprecation of SHA-1 and other changes to certificate and CRL profiles |
9.2.1 |
9.3.0 |
|
2010-06 |
SP-48 |
SP-100368 |
0032 |
1 |
X.509 Certificate profile alignment |
9.3.0 |
10.0.0 |
|
2010-10 |
SP-49 |
SP-100479 |
0038 |
2 |
Correction of certificate profiles for vendor-provided base station certificates |
10.0.0 |
10.1.0 |
|
2010-10 |
SP-49 |
SP-100479 |
0040 |
1 |
Correction to mandatory ciphersuites and compression method in TLS profile |
10.0.0 |
10.1.0 |
|
2010-10 |
SP-49 |
SP-100480 |
0041 |
– |
Adaptations of key lengths and hash algorithms used in certificates and CRLs |
10.0.0 |
10.1.0 |
|
2010-10 |
SP-49 |
SP-100480 |
0042 |
2 |
Additions to TLS profile in Annex E |
10.0.0 |
10.1.0 |
|
2010-10 |
SP-49 |
SP-100480 |
0043 |
– |
Update of reference to PKI-Forum publication |
10.0.0 |
10.1.0 |
|
2010-10 |
SP-49 |
SP-100571 |
0044 |
– |
Correction about clause 9.5.1 and Annex G |
10.0.0 |
10.1.0 |
|
2010-10 |
SP-50 |
SP-100731 |
0045 |
1 |
NDS corrections |
10.1.0 |
10.2.0 |
|
2010-10 |
SP-50 |
SP-100732 |
0047 |
1 |
NDS corrections |
10.1.0 |
10.2.0 |
|
2011-06 |
SP-52 |
SP-110257 |
0049 |
1 |
Removal of mandatory support for HTTPS in CMP transport-R10 |
10.2.0 |
10.3.0 |
|
2011-06 |
SP-52 |
SP-110265 |
0051 |
– |
Correction of reference for key usage bit in TLS certificate and some editorials |
10.2.0 |
10.3.0 |
|
2011-06 |
SP-52 |
SP-110265 |
0052 |
– |
Correction on CRL distribution point for vendor root CA certificates |
10.2.0 |
10.3.0 |
|
2011-09 |
SP-53 |
SP-110627 |
0053 |
1 |
CMPv2 profile |
10.3.0 |
10.4.0 |
|
2011-09 |
SP-53 |
SP-110509 |
0055 |
2 |
Correction of the signature algorithm used for CMP message protection |
10.3.0 |
10.4.0 |
|
2011-12 |
SP-54 |
SP-110692 |
0056 |
1 |
CMPv2 profile |
10.4.0 |
10.5.0 |
|
2012-06 |
SP-56 |
SP-120341 |
0057 |
– |
Addition of TLS Extensions References to TS 33.310 |
10.6.0 |
11.0.0 |
|
2012-06 |
SP-56 |
SP-120341 |
0058 |
1 |
Addition of ciphersuite with hash function SHA256 and profile and reference to IETF RFC for psk-TLS |
10.6.0 |
11.0.0 |
|
2012-07 |
Editorial change: removal of revision marks on page header |
11.0.0 |
11.0.1 |
||||
|
2012-09 |
SP-57 |
SP-120606 |
0064 |
1 |
Clarification of CMP requirements |
11.0.1 |
11.1.0 |
|
2012-09 |
SP-57 |
SP-120605 |
0065 |
1 |
Miscellaneous corrections to TS 33.310 |
11.0.1 |
11.1.0 |
|
2012-10 |
Editorial corrections |
11.1.0 |
11.1.1 |
||||
|
2012-12 |
SP-58 |
SP-120859 |
0066 |
— |
Update CMP Reference |
11.1.1 |
11.2.0 |
|
2013-06 |
SP-60 |
SP-130250 |
0069 |
2 |
Clarification on scope and support for certificate extensions |
11.2.0 |
12.0.0 |
|
2014-06 |
SP-64 |
SP-140381 |
0071 |
1 |
Certificate enrolment in MOCN LTE RAN sharing |
12.0.0 |
12.1.0 |
|
0072 |
1 |
Correction on certificate validation during IPsec/TLS procedure |
|||||
|
0073 |
2 |
Provisioning subject name of RA/CA before the CMPv2 run |
|||||
|
2014-09 |
SP-65 |
SP-140593 |
0075 |
1 |
Defining generic DTLS profile based on TS 33.310 TLS profile |
12.1.0 |
12.2.0 |
|
0076 |
1 |
Updating TLS profile for TLS session resumption |
|||||
|
0077 |
1 |
Correction of SEG Certificate Profile in TS 33.310 |
|||||
|
0078 |
– |
Correction of TLS profile regarding NULL encryption |
|||||
|
0079 |
– |
Correction of TLS profile regarding renegotiation |
|||||
|
2015-12 |
SP-70 |
SP-150731 |
0080 |
1 |
Updating certificate and CRL profiles in TS 33.310 |
12.2.0 |
13.0.0 |
|
0081 |
2 |
Updating TLS profiles in TS 33.310 |
|||||
|
0083 |
– |
Removing IKEv1 from TS 33.310 |
|||||
|
2016-03 |
SP-71 |
SP-160053 |
0084 |
1 |
Clarifying terms related to RA and CA in TS 33.310 |
13.0.0 |
13.1.0 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2016-12 |
SA#74 |
SP-160786 |
0089 |
1 |
F |
3GPP security profile update – IPsec |
13.2.0 |
|
2016-12 |
SA#74 |
SP-160788 |
0087 |
1 |
C |
3GPP security profile update – Certificates and CRLs |
14.0.0 |
|
2016-12 |
SA#74 |
SP-160788 |
0088 |
1 |
C |
3GPP security profile update – TLS |
14.0.0 |
|
2016-12 |
SA#74 |
SP-160788 |
0090 |
1 |
F |
3GPP security profile update – IPsec |
14.0.0 |
|
2018-06 |
SA#80 |
SP-180449 |
0093 |
2 |
B |
TLS 1.3 |
15.0.0 |
|
2018-06 |
SA#80 |
SP-180450 |
0094 |
1 |
B |
TLS 1.3 |
16.0.0 |
|
2018-12 |
SA#82 |
SP-181028 |
0098 |
– |
C |
Move TLS crypto profiles to TS 33.210 |
16.1.0 |
|
2018-12 |
SA#82 |
SP-181028 |
0100 |
– |
A |
Correction of references |
16.1.0 |
|
2019-06 |
SA#84 |
SP-190354 |
0101 |
– |
F |
References to several obsoleted RFCs |
16.2.0 |
|
2020-03 |
SA#87E |
SP-200143 |
0104 |
1 |
B |
IKEv2 profile update 33.310 |
16.3.0 |
|
2020-03 |
SA#87E |
SP-200143 |
0105 |
1 |
B |
Certificate and CRL profile update |
16.3.0 |
|
2020-07 |
SA#88E |
SP-200363 |
0108 |
– |
F |
Update on RSA exponent requirement |
16.4.0 |
|
2020-07 |
SA#88E |
SP-200363 |
0109 |
1 |
F |
Corrections on PKCS#1v1.5 padding and Elliptic Curves |
16.4.0 |
|
2020-07 |
SA#88E |
SP-200365 |
0110 |
1 |
B |
SBA Network Function certificate profile |
16.4.0 |
|
2020-09 |
SA#89e |
SP-200857 |
0112 |
– |
F |
Making NF instance id in SBA certificate profile mandatory to support |
16.5.0 |
|
2020-12 |
SA#90e |
SP-201009 |
0113 |
1 |
F |
Editorial corrections to NDS/AF |
16.6.0 |
|
2020-12 |
SA#90e |
SP-201011 |
0115 |
– |
F |
Clarification on format for SubjectAltName |
16.6.0 |
|
2020-12 |
SA#90e |
SP-201010 |
0116 |
– |
F |
Aligning TLS in 33.310 with the current 3GPP TLS profile |
16.6.0 |
|
2021-21 |
SA#91e |
SP-210111 |
0117 |
– |
F |
Clarification on the format of NF type in the NF certification |
16.7.0 |
|
2021-06 |
SA#92e |
SP-210433 |
0118 |
– |
F |
Correction to NF Certificate profile: Format of the apiRoot |
16.8.0 |
|
2021-09 |
SA#93e |
SP-210843 |
0120 |
– |
B |
Security updates for algorithms and protocols in 33.310 |
17.0.0 |
|
2021-12 |
SA#94e |
SP-211379 |
0124 |
– |
B |
Security updates for algorithms and protocols for 33.310 |
17.1.0 |
|
2022-03 |
SA#95e |
SP-220203 |
0126 |
1 |
A |
Correction of the format of the URN string in the NF certificate profile |
17.2.0 |
|
2022-06 |
SA#96 |
SP-220555 |
0128 |
1 |
A |
Clarification on CN-ID when it is presented in the certificate |
17.3.0 |
|
2022-09 |
SA#97e |
SP-220882 |
0132 |
– |
A |
Clarification on the format of callback URI in the NF certificate profile |
17.4.0 |
|
2022-09 |
SA#97e |
SP-220882 |
0134 |
1 |
A |
Clarification on the certificate profile for SCP |
17.4.0 |
|
2022-12 |
SA#98e |
SP-221155 |
0138 |
– |
F |
EN resolution on NF instance ID in cert profile |
17.5.0 |
|
2022-12 |
SA#98e |
SP-221154 |
0140 |
– |
A |
Correct SCP certificate profile |
17.5.0 |
|
2022-12 |
SA#98e |
SP-221154 |
0142 |
– |
A |
Clarify SEPP intra-domain certificate profile |
17.5.0 |
|
2022-12 |
SA#98e |
SP-221155 |
0143 |
– |
F |
Correct NF certificate profile |
17.5.0 |