I have been pulled into many discussions that are not taking 'all' of ATNA. They are either just taking the audit logging, or just taking the Secure Communications. Then there are the discussions that are taking the Secure Communications but don't want to take the Client authentication. All of these discussions are missing the point of ATNA, and/or are missing the configurability that is built into ATNA.
Let me explain:
1. ATNA is a grouping of three functions: Security Audit, Secure Communications, and local Access Controls. It is only when you are assured that ALL of these functions exist that you should administratively accept the node/application, and provision a certificate. When I see groups picking and choosing parts, I worry that they might not be understanding the overall. I don’t mind treating them independent as long as this overall design is understood.
2. ATNA Secure Communications (actually Authenticate Node). is not just mutual-authenticated-TLS, although this is the predominant form (The only form for point-to-point protocols like HL7 v2, and DICOM). It also includes SMTP end-to-end security used by Direct. It includes end-to-end security for SOAP using XML-Signature and XML-Encryption….
3. ATNA Secure Communications expects that you will do certificate management (PKI) properly, that is that authenticating a node is more than just proving that the claimed identity is the one authenticated. If you don’t manage your truststore, then you are just authenticating that the identity is the one claimed in the certificate. This is the kind of https used on the internet, one that only looks to prove that the server you connected to is 'most likely' the one you intended. When you don't manage your trust-store, all you can know is that the identity seems 'most likely' to be the one you intended to connect to. This is indeed not very helpful. This is why ATNA has a long discussion around certificate management. Managing the trust-store, usually through removing the hundreds of internet Certificate Authorities (CA), and leaving only CAs that you really trust.
4. Further there is an expectation that you don’t stop at authentication, but also check that the remote node is authorized. The ATNA Secure Communications is just the “Interoperability” way to get authentication done, you still must use that authenticated identity in an authorization decision. If you fail to do this then you will certainly fail to be secure. This fact is true about ALL authentication mechanisms.
5. ATNA Secure Communications can be grouped with a user authentication profile like EUA, XUA, or IUA. This is less clear in the ATNA profile and transaction, as the transaction doesn’t mention these (beyond EUA). So you can authenticate the user at the client, in addition to authenticating the client they are on.
6. ATNA Secure Communications does specify TLS 1.0 or better, and the use of TLS_RSA_WITH_AES_128_CBC_SHA; this is an “Interoperability” statement, not a security statement. Meaning it is there to set a low bar that assures interoperability can happen. Policy is expected to take over from there, where policy can push the security criteria up as high as the actors can handle. If you are in the space of Policy, you can certainly set the Policy higher. I emphasize that IHE is focused on assuring that products come with capability that will interoperate, it is NOT constraining on the top-end and can’t constrain on the top-end; that is policy space. The profile does recommend that all crypto algorithms, and key sizes be configurable. It only specifies one set, so that interoperabililty will work, as without this it is likely two systems choose non-overlapping crypto algorithms and key sizes.
7. IHE has further explained that for HTTP traffic, it is likely that policy will allow HTTPS with no client-authentication, where the client is authenticated using IUA (OAuth). This is the same recommendation you will find in FHIR, and SMART. OAuth is an acceptable standard, it “can” represent the application as being authorized by the User. In this way it meets the expectation of ATNA Secure Communications. So if you are focused on HTTP like things, FHIR, then stop worrying about the client certificate in ATNA Secure Communications, and start demanding OAuth for client; as this does meet the ATNA requirement and is far more easy to manage in HTTP like architectures (Mutual-Auth-TLS is very hard to deal with in web centric architectures).
8. That said, although OAuth can be used to authorize background tasks for authorized applications (e.g. Facebook app does this); OAuth doesn’t work as well for cases where the identity that needs to be claimed is NOT HUMAN. Meaning it works fine for Facebook, but doesn’t work all that well for “The XCA Gateway of Kaiser”. In these cases certificates work better as they are inherently more manageable as automaton identity, vs human identity.
Let me explain:
1. ATNA is a grouping of three functions: Security Audit, Secure Communications, and local Access Controls. It is only when you are assured that ALL of these functions exist that you should administratively accept the node/application, and provision a certificate. When I see groups picking and choosing parts, I worry that they might not be understanding the overall. I don’t mind treating them independent as long as this overall design is understood.
2. ATNA Secure Communications (actually Authenticate Node). is not just mutual-authenticated-TLS, although this is the predominant form (The only form for point-to-point protocols like HL7 v2, and DICOM). It also includes SMTP end-to-end security used by Direct. It includes end-to-end security for SOAP using XML-Signature and XML-Encryption….
3. ATNA Secure Communications expects that you will do certificate management (PKI) properly, that is that authenticating a node is more than just proving that the claimed identity is the one authenticated. If you don’t manage your truststore, then you are just authenticating that the identity is the one claimed in the certificate. This is the kind of https used on the internet, one that only looks to prove that the server you connected to is 'most likely' the one you intended. When you don't manage your trust-store, all you can know is that the identity seems 'most likely' to be the one you intended to connect to. This is indeed not very helpful. This is why ATNA has a long discussion around certificate management. Managing the trust-store, usually through removing the hundreds of internet Certificate Authorities (CA), and leaving only CAs that you really trust.
4. Further there is an expectation that you don’t stop at authentication, but also check that the remote node is authorized. The ATNA Secure Communications is just the “Interoperability” way to get authentication done, you still must use that authenticated identity in an authorization decision. If you fail to do this then you will certainly fail to be secure. This fact is true about ALL authentication mechanisms.
5. ATNA Secure Communications can be grouped with a user authentication profile like EUA, XUA, or IUA. This is less clear in the ATNA profile and transaction, as the transaction doesn’t mention these (beyond EUA). So you can authenticate the user at the client, in addition to authenticating the client they are on.
6. ATNA Secure Communications does specify TLS 1.0 or better, and the use of TLS_RSA_WITH_AES_128_CBC_SHA; this is an “Interoperability” statement, not a security statement. Meaning it is there to set a low bar that assures interoperability can happen. Policy is expected to take over from there, where policy can push the security criteria up as high as the actors can handle. If you are in the space of Policy, you can certainly set the Policy higher. I emphasize that IHE is focused on assuring that products come with capability that will interoperate, it is NOT constraining on the top-end and can’t constrain on the top-end; that is policy space. The profile does recommend that all crypto algorithms, and key sizes be configurable. It only specifies one set, so that interoperabililty will work, as without this it is likely two systems choose non-overlapping crypto algorithms and key sizes.
7. IHE has further explained that for HTTP traffic, it is likely that policy will allow HTTPS with no client-authentication, where the client is authenticated using IUA (OAuth). This is the same recommendation you will find in FHIR, and SMART. OAuth is an acceptable standard, it “can” represent the application as being authorized by the User. In this way it meets the expectation of ATNA Secure Communications. So if you are focused on HTTP like things, FHIR, then stop worrying about the client certificate in ATNA Secure Communications, and start demanding OAuth for client; as this does meet the ATNA requirement and is far more easy to manage in HTTP like architectures (Mutual-Auth-TLS is very hard to deal with in web centric architectures).
8. That said, although OAuth can be used to authorize background tasks for authorized applications (e.g. Facebook app does this); OAuth doesn’t work as well for cases where the identity that needs to be claimed is NOT HUMAN. Meaning it works fine for Facebook, but doesn’t work all that well for “The XCA Gateway of Kaiser”. In these cases certificates work better as they are inherently more manageable as automaton identity, vs human identity.
Conclusion
So, keep ATNA together, it is an important set of capabilities that if not used together don't provide security. Recognize that ATNA is just one security profile, user authentication is done with IUA, XUA, and EUA. Lastly recognize that IHE is enabling default interoperability, it is not restricting the security to that level.