10.2.10 | Netwerk level security mTLS 1.3

In a secure network, certificates play a crucial role by enabling the establishment of secure connections using TLS. They also ensure the authenticity and integrity of published data.

Both the Sending System and Receiving System expose endpoints that must be protected from unauthorized and malicious interactions. More specifically, access control measures must be applied to the following endpoints:

• Receiving System: Notification endpoint (FHIR Task endpoint)

• Sending System: Resource endpoint

Mutual TLS shall be used to protect these endpoints in the following ways:

• Authentication: The sending and receiving system are mutually verifying each other's identity before establishing a secure connection. In this way only systems that are trusted (are a GtK) are allowed to set up connections.

• Encryption: an mTLS connection is encrypted. This means that only the sending and receiving systems can read the exchanged data and no third, unauthorized party can ‘listen in’.

• Integrity: mTLS assures that the data has not been modified by any unauthorized party during transmission. Any tampering attempts would alerting the recipient.

• Protection against replay attacks: Each message sent over the connection includes a sequence number, and the recipient keeps track of the sequence numbers it has received. If a message with a previously received sequence number arrives, it is considered a replayed message and is rejected. This prevents attackers from intercepting and resending previously valid messages.

Terminology

• Certificate Authority (CA): A trusted entity responsible for issuing and managing certificates used in secure network connections.

• Certificate Revocation List (CRL): A list maintained by a Certificate Authority, containing revoked certificates to prevent the use of compromised or invalid certificates.

• Public Key Infrastructure overheid (PKIo): A PKI structure controlled by the Dutch government, governing the issuance and management of certificates in the Netherlands.

• Trusted Service Provider (TSP): A party authorized to issue PKIo certificates within the PKIo infrastructure, ensuring the integrity and security of the certificates they issue.

Network level security: mTLS 1.3

On network level mutual TLS (mTLS) must be applied. The TLS-implementation must comply with the security level “Good” as specified by the National Cyber Security Centre (NCSC). At the time of writing, the https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1 require version 1.3 of the TLS standard for the security level “Good”.

The exchange of a client certificate during the mTLS handshake does not only enable the server to authenticate the client on network level, but it also enables the server to issue certificate bound access tokens as specified in https://www.rfc-editor.org/rfc/rfc8705 as an additional security measure on application level. See section Resource server authorization: OAuth 2.0 for requirements on application level security using OAuth 2.0.

CRL / OCSP / CPS

Minimaal elk uur check.

PKIoverheid

Both the client and server certificates must be PKIo-certificates that are issued under the CA “Staat der Nederlanden Private Services CA – G1” (this includes UZI server certificates issued by UZI-registry (CIBG)). https://cert.pkioverheid.nl/

Note: that the requirements as specified in this paragraph apply to Notification, FHIR, and token endpoints.

PvE:

tabel overgenomen vanuit Babyconnect, met aanpassingen ihkv twiin. @Wouter Tesink @Marc eens?