Security Overview

From Direct Project
Jump to: navigation, search

Security Overview

This document is deprecated. Its content has been folded into the overall specifications

Status of this Specification


This specification is in Draft state.

This feels more like the "NHIN Direct Security Specification". I would recommend this be renamed to that.

The Security Overview is best represented by Direct Project Security Overview

IPR Statement


By contributing to this specification, all contributors warrant that all applicable patient or other intellectual policy rights have been disclosed and that any of which contributors are aware of will be disclosed in accordance with the Direct Project IPR Policy.

Abstract


This specification covers the mandatory and optional security technologies of the Direct Project specification.

Introduction


Purpose

The Direct Project specification is intended for communicating health information between individuals and organizations that have agreed to communicate using the Direct Project protocol. Due to the likelihood that this health information is highly sensitive we have mandated some security technology and recommended others be used in certain circumstances. The reason why we have some optional security capabilities is because not all deployment architectures bring out the same set of risks.

Requirements


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

Synopsis

The Direct Project mandates the use of commonly available S/MIME security.

Common Security Technology

The Direct Project mandates the use of S/MIME as the means to provide end-to-end authenticity, confidentiality and integrity protection.

Message Authentication

  • All Direct Project solutions SHALL support the authentication of S/MIME messages using X.509 certificates.
  • All Direct Project solutions SHALL protect their private key against reasonable risks of exposure.
  • All Direct Project solutions SHALL support some means by which their certificate is issued
    • Direct Project solutions MAY use a Certificate Request to request a certificate be issue by a trusted certificate authority
    • Direct Project solutions MAY support importing a PKCS12 package as issued from a manually trusted certificate authority
  • All Direct Project solutions SHALL support some means by which certificates are discovered or configured. (BER or DER encoded certificates)
    • Direct Project solutions MAY use the DNS discovery mechanism defined by NHIN Direct
    • Direct Project solutions MAY use LDAP discovery mechanism
    • Direct Project solutions MAY obtain certificates from prior e-mail exchanges of S/MIME signed messages
  • All Direct Project solutions SHALL validate certificates before using them to send or receive an S/MIME message.
    • Direct Project solutions SHALL assure that the certificates timeframe is valid (e.g. not expired)
    • Direct Project solutions SHALL assure that the certificates signature validates to an individual or certificate chain that is trusted.
    • Direct Project solutions MAY use OCSP or CRL to validate that the certificate has not been revoked

Encryption

  • All Direct Project solutions SHALL support encrypting with at least one algorithm endorsed by FIPS 140-2 Annex A
  • Direct Project solutions SHOULD default to using AES-128

Integrity

  • All Direct Project solutions SHALL support integrity with at least one algorithm endorsed by FIPS PUB 180-3 Annex A
  • Direct Project solutions SHOULD default to using SHA-1



Transport Security

Direct Project solutions SHOULD have the capability to use Mutually-Authenticated-TLS for all communications. 

Security Considerations

Given the Protections specified above, the Direct Project committee has executed Risk Assessments of some Deployment Architectures. These Risk Assessments include some residual risks that should be handled in the deployment or operational environment. These Risk Assessments followed a Threat Model Proces



Authors


John Moehrke

References


Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119

Copyright


By contributing to this specification, all contributors agree to license contributions according to the Creative Commons Attribution 3.0 License which is incorporated into this document by reference.