This policy applies to testing of the Audit Trail and Node Authentication (ATNA) Integration profile at the IHE North American Connectathon in January 2010.
In September 2009, IT Infrastructure Technical Committee balloted and approved a change proposal to
ATNA, CP-417 within CP Ballot #3 .
This CP changes the way audit records are transmitted. In summary, the audit record remains the same, but the Berkeley syslog protocol is retired and replaced by two other protocols -- you should read the details in the CP text itself.
The Connectathon Managers (Steve Moore, Lynn Felhofer) will enforce the following policy to encourage the adoption of the changes required by the CP. We have learned much in October and
November while vendors started implementation and tools were being built.
1.
At the January 2010 Connectathon, we will not test the now-retired syslog protocols (RFC 3164 and RFC 3195). a.
Given that it is going away, we do not want to encourage new vendors to do work on something that is obsolete. b.
It would make no sense to give someone an ATNA “pass” for something that is to be replaced. c.
We will not grade any tests using the retired transport (RFC 3164 and RFC 3195).
2.
We will only give Connectathon credit for successfully testing ATNA to Secure Node /Secure
Application actors who correctly implement both a.
the ATNA TLS requirements on their non-syslog transactions (HL7, DICOM, HTTPS, …), and b.
the logging requirements with the new protocols

RFC 5426 – Syslog over UDP or

RFC 5425 – Syslog over TLS.
This RFC required TLS 1.2. Due to a lack of tools support for TLS 1.2, we will
now accept TLS 1.0 for NA2010. This is a change from our Nov 11 announcement where we said only TLS 1.2 would be accepted

Secure Node/Secure Application actors are welcome and encouraged to test
both transports.
3.
For Connectathon credit, ATNA Audit Record Repositories must support a.
RFC 5426 – Syslog over UDP
and b.
RFC 5425 – Syslog over TLS.
This RFC required TLS 1.2. Due to a lack of tools support for TLS 1.2, we will now
accept TLS 1.0 for NA2010. This is a change from our Nov 11 announcement where we said only TLS 1.2 would be accepted
4.
the new requirements in order to pass. We know this is an inconvenience, but we don’t want to pass anyone who has not done all of the work.

5.
We will not grade any tests using the retired transport.
6.
We recognize that those who implement the XDS family of profiles that require grouping with an
ATNA Secure Node or Secure Application (eg XDS.b, XCA and others) are at risk of not meeting the new requirements. We understand they may not get credit for successfully testing ATNA in this cycle. For the North American Connectathon 2010, we will pass these systems on XDSrelated profiles without the ATNA profile itself, but they must demonstrate the ATNA TLS requirements on their non-syslog transactions (HL7, DICOM, HTTP, …). That is, you will demonstrate web services communication secured by TLS; you will demonstrate other communication (HL7, DICOM) secured by TLS; you will not be required to demonstrate secure logging to pass XDS-related profiles.
7.
We suspect that many systems will not pass ATNA because they do not meet the logging requirements, even though they did them last year with the old logging. The fall coming months of implementation will give has given us better evidence. a.
If systems do not pass ATNA because of the logging, Lynn/Steve recommend that the
HIMSS Showcase still accept them for XDS demonstrations.
8.
Do not imply that we are discouraging testing with the new transport mechanisms for logging.
We want participants to implement the protocol. The purpose of the policy is to clearly define
Connectathon requirements and expected outcomes.
9.
We know that time is short, but we encourage Secure Node/Secure Application actors to implement RFC 5425 using TLS 1.0. This will help your Audit Repository cousins who want to test with you.
These are based on closer reading of the ATNA profile, related transactions and change proposals.
Ciphers:
1.
The ITI Technical Framework + CPs clearly define ciphers for some protocols (ITI TF 2: 3.19.6, CP
417 which references RFC 5425).
2.
ITI TF-2:3.19.6.4 Web-Services references a page on ws-i.org on basic security that does not exist today. The page listed below (a is title, b is URL, c is relevant section) and will be used for reference for the NA 2010 Connectathon: a.
Basic Security Profile Version 1.1 / Board Approval Draft / 2009-11-11 b.
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1-BdAD.html
c.
See section 4: Transport Layer Mechanisms.
3.
WS-I Basic Security Profile 1.1 requires the 3DES cipher for web services
4.
ITI TF-2:3.19.6.4 references WS-I with a note indicating this is the same requirement as the IHE requirement for HTTP (AES). Thus, the ITI documentation and WS-I documentation are in conflict. Because of this conflict, we will accept either 3DES or AES as the cipher for web services.
5.
The compromise on ciphers for web services does not extend to DICOM, HL7 V2 and HTTP.
Those requirements are clearly documented.
6.
The table below lists the ciphers that will be accepted as a function of communication protocol.
If your software does not support the appropriate cipher, you will fail the ATNA profile. We will still recommend that the HIMSS Showcase will accept your system for demonstration.

Syslog / TLS:
1.
Section 4.2 of RFC 5425 very clearly states requirements for TLS version (1.2) and cipher (AES).
2.
ITI CP 417 requires RFC 5425 but makes no comment about TLS version or cipher.
3.
We understand there are few implementations of TLS 1.2, but are bound by the written documentation.
4.
ITI CP 417 allows the Secure Node or Secure Application to choose either RFC 5425 or 5426. The
Audit Record Repository is required to support both.
5.
A Secure Node or Secure Application that can demonstrate RFC 5426 will pass the transport requirement of the ATNA logging tests.
6.
An Audit Record Repository must implement BOTH RFC 5425 and RFC 5426 to pass the transport requirements of the ATNA logging tests.
Syslog / BOM:
1.
RFC 5424 / Section 6.4 describes the use of BOM (byte order mark) for UTF-8 encoded messages. ITI CP 417 also describes the use of BOM. We find the language in both RFC 5424 and
ITI CP 417 confusing.
2.
A Secure Node will be allowed to send an Audit Message that includes the BOM or excludes the
BOM.
3.
We will require the Audit Record Repository to process both formats (with the BOM, missing the
BOM). This will likely match what you will see in the field.

Table of Acceptable Ciphers for NA 2010:
Protocol
DICOM
DICOM
HL7 V2 MLLP
HL7 V2 MLLP
Cipher
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Notes
ITI TF 2:3.19.6.2
ITI TF 2:3.19.6.2 (Encryption option)
ITI TF 2:3.19.6.2
ITI TF 2:3.19.6.2 (Encryption option)
HTTP
Syslog / TLS 1.2 / RFC
5425
Web Services (HL7 V3,
XDS.b, XDR, XDS-I)
TLS_RSA_WITH_AES_128_CBC_SHA ITI TF 2:3.19.6.3
TLS_RSA_WITH_AES_128_CBC_SHA RFC 5425: 4.2
TLS_RSA_WITH_AES_128_CBC_SHA or
TLS_RSA_WITH_3DES_EDE_CBC_SHA http://www.wsi.org/Profiles/BasicSecurityProfile-
1.1-BdAD.html
This selection of ciphers is based on our interpretation of the ITI TF, CP 417 and RFC 5425. We understand that the cipher requirements are not uniform, TLS 1.2 is not widely available and the AES and NULL cipher are not readily available on Windows XP using .NET.
Our goal at NA 2010 is to better document what participants are able to accomplish rather than loosening requirements. Use this as a push to support the requirements. If you disagree with the requirements, please submit Change Proposals to the ITI technical committee.
Secure Node vs Secure Application
In addressing the difference between Secure Node and Secure Application actors, ITI TF-1: 9.7 indicates that a Secure Application actor implements ATNA security features (authentication and auditing) for functions appropriate to its IHE task, whereas a product which is a Secure Node is “integrated so that all of the operating system and other environmental security features are present”. At past connectathons, we have asked our monitors to work with participants to determine whether your connectathon test system is a Secure Node or a Secure Application. This year these monitors will verify your auditing and node authentication capabilities. If you pass those tests, you will pass ATNA as the actor you registered for in kudu (Secure Node / Secure Application).