TLS+Encryption+Clarification

Problem Statement: The current eHealth Exchange Production Specifications have gaps related to the use of TLS for the exchange of production messages. A key aspect of this, is ensure that federal partners, which are subject to FIPS, are compliant.

Resolution: A significant amount of research has been conducted on this issue, and the following text has been drafted and proposed for addition to the eHealth Exchange specifications.

Current Draft as of 2016-11-10 ** TLS Versions Clarifications ** ** Change Proposal ** ** DRAFT v005 for Public Review **

There is considerable interest in ensuring that the connections between eHealth Exchange Participants maintain a very high degree of security. TLS is subject to somewhat complex configuration requirements and hand shake protocols. Further complicating the issue is that some “consumerized” information has been propagated leading to the (arguably incorrect) conclusion that certain versions of TLS are “insecure”. We assert all versions of TLS 1.0, 1.1, 1.2 and even 1.3 draft can be configured to use insecure or weak parameters. And, we assert that all versions of TLS 1.0, 1.1 and 1.2 can be configured securely. Thus this change proposal is being advanced to address these issues by helping to ensure that only “strong” configurations of TLS are used in production for the eHealth Exchange. Unlike all other eHealth Exchange policies and specifications, due to the rapid change in security vulnerabilities, this policy requires Participants to adopt the most recently published versions of the referenced documents. Participants are also cautioned that they may need to rapidly deploy new configurations in response to newly discovered vulnerabilities.
 * Background**


 * Change Proposal**
 * Normative**: eHealth Exchange Participants MUST support TLS 1.0. Participants SHOULD support TLS 1.1, 1.2 and subsequent versions. Participants MUST configure their systems to negotiate the highest mutually-agreeable version of TLS supported by both Participants. Participants MUST also exchange using the highest strength cipher suite and key establishment mechanisms available to both Participants. Participants SHOULD use a TLS service listed on the most recently updated FIPS 140-2 Module Validation Lists as being validated, and not revoked, under the Cryptographic Module Validation Program [] lists at []. Participants using a validated cryptomodule MUST install, configure, and operate the FIPS 140-2 validated cryptomodule in either an approved or an allowed mode including, without limit, approved security requirements [], approved security functions [], approved protection profiles [], random number generation [] , and key establishment techniques [] as listed in the latest version of []. Participants using an unvalidated cryptomodule MUST configure their cryptomodule to operate in the same manner as a validated cryptomodule and MUST disable functionality not on the above referenced approved FIPS lists.


 * Non-normative**: Updates to this policy MAY be requested in a time sensitive manner in reaction to newly discovered vulnerabilities. Stating the normative requirements differently, Participants MUST configure their TLS service to operation in FIPS 140-2 mode, or its equivalent and eHealth Exchange Participants MUST NOT use SSLv2 and Participants MUST NOT use SSLv3.

Copyright© 2016 The Sequoia Project

FAQ: Q: Doesn't PCI require that organizations stop using TLS 1.0? A: As of 2016-11-23, the PCI issued the following text on their public web site at: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls which states "The Payment Card Industry Security Standards Council (PCI SSC) is **extending the migration completion date to** **30 June 2018** for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher). These dates provided by PCI SSC as of **December 2015 supersede** the original dates issued in both [|PCI Data Security Standard v3.1] (DSS 3.1) and in the [|//Migrating from SSL and early TLS//] Information Supplement in **April 2015**."

THE BELOW TEXT IS FROM PRIOR DISCUSSIONS AND IS NOT PART OF THE NOV 2016 CHANGE PROPOSAL

“Normative: Organizations utilizing this specification MUST employ an x.509 mutually authenticated secure channel using a NIST CMVP validated cryptographic module. The cryptographic modules MUST be configured in a FIPS-Approved mode of operation as specified per [] or its successor document. The validated cryptographic module configured in a FIPS-Approved mode MUST implement the SSL or TLS protocols using FIPS-Approved key establishment methods and encryption algorithms for the protection of data on the channel.

Non-normative: This list, which is actively maintained by the NIST CMVP as of this writing, is the authoritative source of which products, modules, and modes are approved for use by NIST for Federal Information Processing. This list, or its successor, should be periodically reviewed for updated information as part of each organizations' internal best practices. Since security is a very dynamic area of the industry, we anticipate that the FIPS guidelines will change while this specification is still in effect and implementers are cautioned to create their implementations in such a way that the version of SSL and or TLS, and its associated configuration, can be changed to reflect updated NIST / FIPS security requirements and best practices.”

Updated text:

“Normative: Organizations utilizing this specification MUST employ an x.509 mutually authenticated secure channel using a NIST CMVP validated cryptographic module. The cryptographic modules MUST be configured in a FIPS-Approved mode of operation as specified per [] or its successor document. The validated cryptographic module configured in a FIPS-Approved mode MUST implement the SSL or TLS protocols using FIPS-Approved key establishment methods and encryption algorithms for the protection of data on the channel. Implementers must support a CMVP approved TLS 1.0 implementation, unless this version is specifically disapproved by the CMVP. Versions of TLS greater than 1.0 can be used as well provided such an implementation is approved by the CMVP."

Discussion: people need a specific version to be listed to make it simpler and clear for implementers.

Need to get test team feedback to ensure they will be able to test this.

Need to specify encryption in our WSDL.

From Tom D (is this the FIPS list as of a certain date): code        ->        <sp:Basic128Sha256Rsa15 /> <sp:TripleDesSha256Rsa15 /> </wsp:Policy> code

From IHE ANTA: TLS_RSA_WITH_AES_128_CBC_SHA

<span style="font-family: 'Arial','sans-serif';">For cross-reference, the following is the table from WS-SecurityPolicy.
 * **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">Algorithm Suite ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">[Dig] ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">[Enc] ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">[Sym KW] ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">[Asym KW] ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">[Enc KD] ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">[Sig KD] ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 8pt;">[Min SKL] ** ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic256 || Sha1 || Aes256 || KwAes256 || KwRsaOaep || PSha1L256 || PSha1L192 || 256 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic192 || Sha1 || Aes192 || KwAes192 || KwRsaOaep || PSha1L192 || PSha1L192 || 192 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic128 || Sha1 || Aes128 || KwAes128 || KwRsaOaep || PSha1L128 || PSha1L128 || 128 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">TripleDes || Sha1 || TripleDes || KwTripleDes || KwRsaOaep || PSha1L192 || PSha1L192 || 192 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic256Rsa15 || Sha1 || Aes256 || KwAes256 || KwRsa15 || PSha1L256 || PSha1L192 || 256 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic192Rsa15 || Sha1 || Aes192 || KwAes192 || KwRsa15 || PSha1L192 || PSha1L192 || 192 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">->Basic128Rsa15 || Sha1 || Aes128 || KwAes128 || KwRsa15 || PSha1L128 || PSha1L128 || 128 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">TripleDesRsa15 || Sha1 || TripleDes || KwTripleDes || KwRsa15 || PSha1L192 || PSha1L192 || 192 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic256Sha256 || Sha256 || Aes256 || KwAes256 || KwRsaOaep || PSha1L256 || PSha1L192 || 256 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic192Sha256 || Sha256 || Aes192 || KwAes192 || KwRsaOaep || PSha1L192 || PSha1L192 || 192 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic128Sha256 || Sha256 || Aes128 || KwAes128 || KwRsaOaep || PSha1L128 || PSha1L128 || 128 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">TripleDesSha256 || Sha256 || TripleDes || KwTripleDes || KwRsaOaep || PSha1L192 || PSha1L192 || 192 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic256Sha256Rsa15 || Sha256 || Aes256 || KwAes256 || KwRsa15 || PSha1L256 || PSha1L192 || 256 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic192Sha256Rsa15 || Sha256 || Aes192 || KwAes192 || KwRsa15 || PSha1L192 || PSha1L192 || 192 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">Basic128Sha256Rsa15 || Sha256 || Aes128 || KwAes128 || KwRsa15 || PSha1L128 || PSha1L128 || 128 ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 8pt; margin: 0in 0in 0pt;">TripleDesSha256Rsa15 || Sha256 || TripleDes || KwTripleDes || KwRsa15 || PSha1L192 || PSha1L192 || 192 ||

This is not inclusive, and not the TLS list. Authentication (key exchange), encryption, and hashing should be specified.

Outstanding issues:
 * 1) Can we express the type of security in the policy statement? For example, can we control, via policy, the use of TLS version 1.? WS-Security? Other?
 * 2) How do properly correct the existing ws policy to have both a common denom algorithm suite and provide for CMVP compatibility and provide for testing and provide for a practical implementations use (broad vendor support)?
 * 3) Can we provide a WSDL template that each implementer can change to reflect their specific policy and implementation constraints while still having interoperability with others?
 * 4) Considered WS-I BasicSecurity profile to see if this is addressed in there? IHE is a subset of this.

New issue: move to another location in the Wiki. How do we interoperate in the event of a emergency scenario? Perhaps consider have a NWHIN-wide continuity planning (risks, impact, mitigation, etc). Perhaps consider a floor for all to ensure broad NWHIN interop. Otherwise, if we don't have a specific, minimal, and required common configuration, then we don't have true interoperable.

Working decision: We need to express a single common configuration to assure interoperability. Also need to consider a risk mitigation workgroup. What is a minimal fall back in a disaster scenario.

Tom D and Eric H will resh. John M will review our findings.

Recommendation: Risk Managment workgroup.

Implementations MUST use TLS_RSA_WITH_AES_128_CBC_SHA as per IHE ATNA, plus any additional algorithims as appropriate for their implementtion. Federal entities must use a FIPS-approved impmention (as per the above text), and non-federal excnage can implement any of these policies plus any other policies as per best practices for their organization. Include the exact text of the WSDL policy segment.