ATNA is a widely tested profile. This page contains guidelines that address frequently asked questions about testing expectations.
THIS PAGE APPLIES TO ATNA TESTING AT IHE CONNECTATHONS IN 2020.
- ATNA Requirements
- Security Policy (TLS & audit) for 2020 IHE NA and EU Connectathons
- Gazelle Security Suite (GSS) tool for ATNA testing
- GSS: Digital Certificates for IHE Connectathons
- GSS: ATNA Questionnaire
- GSS: ATNA Logging Tests - TLS Syslog
- Questions about ATNA testing?
(1) The ATNA requirements are in the IHE Technical Framework.
- ITI Technical Framework, Vol 1, Section 9.
- ITI Technical Framework Vol 2a, for the [ITI-19] and [ITI-20] transactions.
(2) UPDATES were made to options related to [ITI-19] Authentication Node. These changes came from CP-ITI-1151. 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)
- Note: The STX Options from CP-ITI-1151 *replace* the following options added in 2019; i.e., these are now deprecated:
- BCP195 TLS Secure Connection - All TLS Versions Option
- BCP195 TLS Secure Connection - TLS 1.2 Floor Option
(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)
(4) Additional features for ATNA are in the RESTful ATNA (Query and Feed)Trial Implementation Supplement. Read it here.
- Now based on HL7 FHIR R4
The "STX" options described above introduce variability in the Connectathon testing environment that did not exist in previous Connectathons. 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] (same as 2019 Connectathons):
*** For 2020 IHE NA and EU Connectathons, peer-to-peer testing over TLS shall be done using:
- TLS 1.2
- cipher TLS_RSA_WITH_AES_128_CBC_SHA
- (Note that we intentionally chose a 'less secure' cipher for 2019 & 2020 testing and anticipate choosing one of the recommended ciphers from BCP195 for future IHE Connectathons.)
- A digital certificate, issued by the Gazelle Security Suite (GSS) tool. See the next section.
We have added pre-Connectathon test 11108. When you perform that test prior to Connectathon, you confirm that the client or server applications in your test system are configured to support the Connectathon policy.
AUDIT MESSAGE POLICY for [ITI-20]:
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 is new for 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_*.
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: http://gazelle.ihe.net/gss.
- Instructions for use of the tool are contained in ATNA test descriptions - here.
- Recorded training on the Gazelle Security Suite - here
*** For the 2020 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.
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.
Some facts about the digital certificates for Connectathon testing:
- The digital certificate you generate in GSS:
- 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.
- 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.)
- Pre-Connectathon test 11100 contains detailed instructions for generating your certificate, including how to get the fully-qualified domain name for your test system.
- 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.
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.
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 ITI Technical Framework defines the Record Audit Event [ITI-20] transaction, and specifies use of the DICOM schema for audit messages sent with the ATX: TLS Syslog Option.
- The DICOM schema is found in DICOM Part 15, Section A.5.1.
- The Gazelle Security Suite tool uses the DICOM schema with IHE modifications:
- For 2020 Connectathons in NA and EU, the schema used by the tool is based on DICOM 2017c here: https://gazelle.ihe.net/XSD/IHE/ATNA/dicom_ihe_ps3.15_a.5.1_2017c.xsd
We expect implementations to be compliant, and 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.
Contact Lynn Felhofer, Technical Project Manager for the IT Infrastructure domain.