DICOM PS3.15 2024e - Security and System Management Profiles

B.12 BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile

An implementation that supports the BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security protocol. It shall comply with [BCP 195] which includes [RFC 8996], and [RFC 9325]. In the context of this profile, “client” refers to the entity initiating the TLS connection and “server” refers to the entity that is responding to that TLS connection initiation request. This may differ from the role that the entity might play in any DICOM transactions over the TLS connection.

Note

  1. A device may support multiple TLS profiles. DICOM does not specify how such devices are configured in the field or how different TLS profile-related rules are specified. The site will determine what configuration is appropriate.

  2. The DICOM profiles for TLS describe the capabilities of a product. Product configuration may permit selection of a particular profile and/or additional negotiation rules. The specific cipher suite used is negotiated by the TLS implementation based on these rules.

Servers and clients shall support TLS 1.2 and may support TLS 1.3. Clients shall attempt to negotiate TLS 1.3 if it is supported. Servers shall prefer TLS 1.3 if offered by the client.

In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers shall prefer strict TLS configuration.

Application protocols typically provide a way for the server to offer TLS during an initial protocol exchange, and sometimes also provide a way for the server to advertise support for TLS (e.g., through a flag indicating that TLS is required). Unfortunately, these indications are sent before the communication channel is encrypted.

A client shall attempt to negotiate TLS even if the above indications are not communicated by the server.

All communications shall be encrypted with integrity checks enabled. Hence, implementations shall not use NULL key exchange, cipher, or signature/hash protocols.

Servers shall support bi-directional mutual authentication. Clients are not required, but are encouraged, to support and use bi-directional mutual authentication. The server may be configured to not use bi-directional mutual authentication.

The TCP ports on which an implementation accepts TLS connections for DICOMweb shall be different from those on which an implementation accepts TLS connections for DIMSE. The HTTP/HTTPS connection for DICOMweb can be shared with other HTTP/HTTPS traffic.

Note

It is recommended that systems supporting this Profile use the registered port number "2762 dicom-tls" for the DICOM Upper Layer Protocol on TLS, which is used by DIMSE.

The Conformance Statement shall indicate:

When an integrity check fails, the connection shall be dropped per the TLS protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The Conformance Statement shall document the provider reasons issued by the implementation.

DICOM PS3.15 2024e - Security and System Management Profiles