Security Overview
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.
Table of Contents
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
- Threat Model - SMTP with Full Service HISPs
- Such as using the Direct Project Security Agent
- Threat Model - Simple SMTP
- Full Service e-mail Client,
- Full Service Web Portal, or
- where S/MIME is integrated into the EHR or PHR)
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.