ATNA testing & digital certificates for IHE Connectathons

ATNA is a widely tested profile.  This page contains guidelines that address frequently asked questions about testing expectations.


ATNA Requirements

(1) The ATNA requirements are in the IHE Technical Framework.

(2) UPDATES were made in 2019 to options related to [ITI-19] Authentication Node.   The changes are summarized here, and the details now in the Final Text Technical Framework.

  • Secure Node and Secure Application actors must support one or more of these Secure Transport (ie "STX") options:
    • STX: No Secure Transport Option 
    • STX: TLS 1.0 Floor with AES Option
    • STX: TLS 1.0 Floor using BCP195 Option
    • STX: TLS 1.2 Floor using BCP195 Option
    • STX: S/MIME
    • STX: WS-Security
  • FQDN Validation of Server Certificate Option (first tested in Jan/Apr 2019)

(3) UPDATES were made to add options related to [ITI-20] Record Audit Event.

  • New options for the Secure Node, Secure Application, Audit Record Repository, and Audit Record Forwarded to enable those actors to more precisely specify the Audit Transport (ie "ATX") that they use to send audit messages.  These actors must support one or more of these options:
    • ATX: TLS Syslog Option
    • ATX: UDP Syslog Option
    • ATX: FHIR Feed Option (specified in the RESTFUL ATNA Supplement linked below)

Security Policy (TLS & audit) for 2021 IHE NA and EU Connectathons

The "STX" options described above introduce variability in the Connectathon testing environment that did not exist in IHE Connectathons before 2019.  Depending on the TLS-related options a Connectathon test system supports, it may be able to support TLS 1.0, TLS 1.1, and/or TLS 1.2, and one or more of several ciphers.  During a Connectathon, different systems with a mix of TLS versions and ciphers would be a barrier to connectivity. 

So, in order to ensure interoperability between systems doing peer-to-peer testing over TLS (e.g. XDS, XCA...) the Connectathon technical managers have selected a TLS version and cipher to use for peer-to-peer tests during Connectathon week.  (This is analagous to a hospital mandating similar requirements at a given deployment.)

TLS POLICY for [ITI-19] (stronger cipher suites are NEW for 2021 IHE Connectathons):

*** For 2021 IHE NA and EU Connectathons, peer-to-peer testing over TLS shall be done using:

    • TLS 1.2
    • cipher suite  - any one of:
    • A digital certificate, issued by the Gazelle Security Suite (GSS) tool.  See the next section..


Before 2020, an ATNA Audit Record Repository (ARR) was required to support receiving audit messages with TLS syslog, and with UDP syslog.   That meant that all Secure Node/Applications could send their audit messaes to any ARR.

Now, all actors sending and receiving audit messages may choose to support TLS Syslog, UDP Syslog, and/or FHIR Feed for transport.   We expect that the Audit Record Repositories at the NA and EU Connectathons will provide good coverage of the options (TLS, UDP, FHIR), though some ARRs may support a subset.  In particular, the FHIR Feed in ITI-20 may have less support because it was new as of 2020.

So, Connectathon technical managers will not select one transport for all audit records exchanged during Connectathon.  Instead, Secure Node/Applications will choose ARRs for test partners that are compatible with the audit records they send in ITI-20.  Gazelle Test Management will show compatible partners for peer-to-peer tests for ITI-20 - test "ATNA_Logging_*.

Gazelle Security Suite (GSS) Tool for ATNA testing:

Tool-based testing of TLS (node authentication) and of the format and transport of your audit messages is consolidated in one tool - the Gazelle Security Suite (GSS).

  • Link to the tool:  
  • Instructions for use of the tool are contained in ATNA test descriptions - here.
  • Recorded training on the Gazelle Security Suite - here 

*** For the 2021 IHE NA and EU Connectathons, we will use the Gazelle Security Suite tool to specifically test the new ATNA options: 

  • client behavior for a Secure Node/Application supporting the 'FQDN Validation of Server Certificate' option
  • the ability of a Secure Node/Application to negotiate down from TLS 1.2 to 1.1 to 1.0 as required by the 'STX: TLS 1.0 Floor using BCP195' option
  • the ability of a Secure Node/Application to require that transactions occur with TLS 1.2 and one of the required ciphers in the 'STX: TLS 1.2 Floor using BCP195' option
  • pre-Connectathon test 11109 contains instructions for testing with the GSS client & server simulators for the new STX options.

==> GSS: Digital Certificates for IHE Connectathons

The Gazelle Security Suite (GSS) tool is the SINGLE PROVIDER OF DIGITIAL CERTIFICATES for both NA and EU Connectathons.  

To obtain a digital certificate from the GSS tool for pre-Connectathon & Connectathon testing, follow the instructions in pre-Connectathon test 11100.   That test contains instructions that apply to an IHE Connectathon, whether face-to-face or online.

Some facts about the digital certificates for Connectathon testing:

  1. The digital certificate you generate in GSS:
    1. is from a new Certificate Authority (CA) with a stronger key - 2048 length (before Nov 2018, the CA created certificates with 1024 key length).  You must add the certificate for the new CA in your trust store.
    2. will contain the fully-qualified domain name (FQDN) of your Connectathon test system.   When you use GSS to request the certificate, the tool will prompt you for this value.  The FQDN value(s) will be in the subjectAltName entry of your digital certificate.  (You may need to provide more than one FQDN when you generate your certificate, e.g., if you will use your system to test TLS connections outside of the Connectathon network, such as using the NIST XDS Tools in your local test lab.)
  2. Pre-Connectathon test 11100 contains detailed instructions for generating your certificate, including how to get the fully-qualified domain name for your test system.
  3. Item (1.b.) means that each system testing TLS transactions during Connectathon week will have a digital certificate that is compatible with the FQDN validation option in ATNA.  Thus, TLS connections with test partners will work whether the client is performing FQDN validation, or not.  This is intentional.

Note that the certificates are only for testing purposes and cannot be used outside of the IHE Connectathon context.

==> GSS: ATNA Questionnaire

Systems testing ATNA are required to complete the ATNA Questionnaire in the GSS tool, ideally during pre-Connectathon testing.  Embedded in the questionnaire are Audit Record tests and TLS tests customized for the profiles & actors you will test at Connectathon.

  • Follow instructions in pre-Connectathon test 11106.

==> GSS: ATNA Logging Tests - ATX: TLS Syslog Option

Read the Technical Framework documentation; you are responsible for all requirements in Record Audit Event [ITI-20] transaction. We will not repeat the requirements here.

WHICH SCHEMA???:  The Record Audit Event [ITI-20] specifies use of the DICOM schema for audit messages sent using the ATX: TLS Syslog and ATX: UDP Syslog options.  The DICOM schema is found in DICOM Part 15, Section A.5.1.  

We expect implementations to be compliant; we have tested audit messages using the DICOM schema at IHE Connectathons since 2016.

  • The GSS tool will only provide validation against the DICOM schema. If you fail that test, it is our signal to you that your audit messages are not compliant with the latest DICOM schema.  See pre-Connectathon test 11116.
  • We expect peer-to-peer testing at the Connectathon to occur using messages compliant with the DICOM schema.

SENDING AUDIT MESSAGES:   You can send your audit records to the GSS tool simulating an Audit Record Repository  See pre-connectathon test 11117.

Questions about ATNA Testing?

Contact Lynn Felhofer, Technical Project Manager for the IT Infrastructure domain.

PDF icon IHE_and_Cybersecurity.pdf158.21 KB
PDF icon CP-ITI-1151-04-ballot54.pdf196.39 KB