Content for TS 33.310 Word version: 18.2.0
C Decision for the CRL repository access protocol for SEGs
D Decision for storing the cross-certificates in CR
E TLS protocol profile
F Manual handling of TLS certificates
F.0 General
F.1 TLS certificate enrolment
F.2 TLS Certificate revocation
...
...
C Decision for the CRL repository access protocol for SEGs p. 61
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 was chosen as the more future-proof protocol. Although more complex than HTTP, LDAP is well established amongst PKI vendors and operators.
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) |
D Decision for storing the cross-certificates in CR p. 62
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 is 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 is removed from several places, that is, from all SEGs
|
Pros:
The cross-certificate is removed from one single place only
Cons:
-
|
Pros:
-
Cons:
The cross-certificate is 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.
alternative C) is the most feasible choice, because it combines good points of alternatives A) and B).
E TLS protocol profile |R8| p. 63
The TLS protocol profiles are located in TS 33.210.
F Manual handling of TLS certificates |R8| p. 64
F.0 General |R13| p. 64
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.
F.1 TLS certificate enrolment p. 64
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.
F.2 TLS Certificate revocation p. 64
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.
