Pages

Sunday, April 26, 2015

Why Mutual-Authorized-TLS?

The IHE-ATNA Profile only calls for "Mutual-Authenticated-TLS", where I have asserted that you really need Mutual-Authorized-TLS. I am not changing the IHE-ATNA perspective. From an Interoperability perspective one is using the TLS to Mutually Authenticate. This is the concern that is addressed through Interoperability Profiling. This is all that Profiling can address, in that the Interoperability layer defines how the two sides authenticate each other. This is enough from an Interoperability perspective, but is not the end of the story.

Updated: To be clear, I am not recommending a change to IHE-ATNA, it is fine the way it is and what it provides is foundational to what I am describing. What I am describing is that use of IHE-ATNA Secure Communications is not sufficient, as a 'bad-guy' could potentially be authenticated but not authorized. This is especially true if one uses a truststore like the ones found in Browsers. So what I am describing is that each endpoint must also functionally do Access Control decisions, aka Authorization.

The reason one Authenticates something is to prove that the Identity claimed is indeed the Identity of the one claiming that Identity. But knowing an Identity is just part of the story.

Why does the Server need to check if the Client is Authorized?

An
Authorized Client is one that is allowed to do the task that it is
asking to do. This authorization is based on an Identity that has been
Authenticated. An Identity that is not Authenticated is one that can be
spoofed easily. So you see that the Authorization is dependent on the
Authentication which is dependent on the Identity.

Servers need to
differentiate communications from partners that they should talk to,
from all the attackers that they should not talk to. This is rather obvious in the context of a Cloud
hosted Server. As that Server is on the internet, and thus every
attacker on the internet could be attacking. There are many proofs that
any machine placed on the internet will be attacked within a few
minutes.

The Server is often 'serving' up data or functions for Clients to use. Thus the Server is protecting that data from improper access. Cat videos need not be protected, but healthcare information and healthcare functionality really do need to be protected from improper access. Often times the server will use the identity in a simple Role-Based-Access-Control decision: Does this user possess roles that possess Permissions to this kind of access to this specific resource?

The basics are that the Server needs to protect itself, and this is done with Authorization decisions based on client identity authentication.

Why does the Client need to check if the Server is Authorized?

The Client
must be sure that it has actually gotten connected to the Server it
intended to get connected to. So the risk is that the Client will get
attached to the wrong Server. Worst case is that the Client gets
connected to a malicious Server. In this case the Client may be
controlled to expose healthcare information to the attacker, or to
falsify information into the hospital environment. This happens in the environment where a human is using a Browser, as the human is expected to do the authorization of the server step themselves. This however fails quite often, see phishing.

These attacks are
harder to achieve. The vulnerability is that the client attaches to a Server that
is not the right server (spoofing, tampering, repudiation, disclosure,
and denial-of-service). The attacker would likely be a skilled
and motivated attacker. But the attacks are not that hard to
achieve, and we have seen examples where this kind of attack has
happened.

For example the attacker could 'spoof' the DNS,
thus giving the Client a wrong IP address to connect to; thus causing
the Client to connect to their malicious Server. The attacker could cause routers to route the communications to their malicious Server.

Where node-to-node Authentication is Authorization

There
is a degenerate form where the truststore on both ends of the
communications contain only identities that are Authorized. Thus the
Authentication step, accomplished by the TLS layer, is sufficient. This
is not a violation of the above assessment. It is simply moving the
Authorization step to the configuration of the truststore, rather than
leaving it in real-time as part of the communications channel
establishment. This degenerate form simply is not scalable, and is much
harder to manage.

Authorization as an Interoperability Concern

Yes, there are some protocols that cover Authorization. This can be done using SAML, a claim of authorization can be communicated within a SAML assertion. More directly OAuth, is 'Authorization', and not authentication, although one gets authentication by way of the authorization claims. I am not trying to downplay these, but rather focus on the IHE-ATNA model. This does not mean one model is better than the others, just different. I am simply not covering anything but IHE-ATNA in this blog article. See other articles for other topics.

About Me

The information posted here are mine and not necessarily represent By Light Professional IT Services Inc. I am a Standards Architect specializing in Standards Architecture in Interoperability, Security, and Privacy for By Light Professional IT Services Inc. Primarily involved in the international standards development and the promulgation of those standards. Co-chair of the HL7 Security workgroup, a member of the FHIR Management Group, FHIR core team, and co-chair of IHE IT Infrastructure Planning Committee. Participate in ASTM, DICOM, HL7, IHE, ISO/TC-215, Kantara, W3C, IETF, OASIS-Open, and other. Was a core member of the Direct Project specification writing, authoring the security section, and supporting risk assessment. Active in many regional initiatives such as the S&I Framework, SMART, HEART, CommonWell, Carequality, Sequoia (NwHIN-Exchange), and WISHIN. Active in the Healthcare standardization since 1999, during which time authored various standards, profiles, and white papers.

Surely there are other copyright and trademarks that I should recognize, but everyone else seems to be reasonable; expecting readers of blogs know that I am not trying to claim or take ownership of their copyright and trademarks.