Simple Health Transport

From Direct Project
Jump to navigation Jump to search
THIS DOCUMENT HAS BEEN DEPRECATED.

Please use Applicability Statement for Secure Health Transport instead.


Simple Health Transport


Status of this Specification


Status: This document is up for a Call for Consensus by the Documentation and Testing Workgroup (DUE: Tues, November 19, 2010)


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 describes an interoperable method using specific commonly available elements of secure e-mail (i.e., S/MIME 3.1) to communicate Healthcare Information between two parties.

Table of Contents

Introduction


Purpose


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


This document describes a method for securing and transporting sensitive health documents. It provides four components:

  1. Use of secure e-mail standard S/MIME, with specific limitations on usage provided in this document
  2. Trust validation
  3. Use of DNS for certificate discovery
  4. Use of message wrapping


Conformance


The Direct Project solution mandates the use of S/MIME as the means to provide end-to-end authenticity, confidentiality and integrity protection. Care was taken in selection of requirements to be those commonly found in mature S/MIME implementations. There are some recommended functionality that may be available to a lesser extent, but are not critical to success.

Addressing


  • All Direct Project solutions SHALL support an addressing mechanism conforming to the addr-spec requirements of RFC 5322


Content


  • All Direct Project solutions SHALL support a content container conforming to RFC 5322


Digital Certificate Issuance

  • All Direct Project solutions SHALL support some means by which their digital certificate is issued
    • Direct Project solutions MAY use a Certificate Request to request a certificate be issued by a trusted certificate authority
    • Direct Project solutions MAY support importing a PKCS12 package as issued from a manually trusted certificate authority
    • Direct Project solutions MAY issue self-signed Certificates, although this will present trust challenges.
  • All Direct Project solutions SHALL protect their private key against reasonable risks of exposure.

Digital Certificate Discovery/Distribution

  • All Direct Project solutions SHALL support some means by which the recipient's digital certificates are discovered or configured. (BER or DER encoded certificates)
    • For universal digital certificate distribution, implementations SHOULD support DNS certificate distribution.
    • Implementations that do not support the DNS digital certificate distribution MUST have an alternate method for discovering recipient digital certificates
  • Direct Project solutions MAY use LDAP discovery mechanism
  • Direct Project solutions MAY obtain digital certificates from prior e-mail exchanges of S/MIME signed messages
  • Direct Project solutions MAY obtain digital certificates through some other out-of-band and thus manual means


NOTE: During the current pilot phase we recognize that DNS may or may not be the most effective real-world option for digital certificate distribution. We encourage pilot implementations to experiment with alternatives such as those outlined above. Post-pilot, taking into account the learnings from that work, this specification will be edited to provide more explicit guidance as to the default mechanism for certificate distribution.

Digital Certificate Validation

  • All Direct Project solutions SHALL validate digital certificates before using them to send or receive an S/MIME message.
    • Direct Project solutions SHALL assure that the digital certificates timeframe is valid (e.g. not expired)
    • Direct Project solutions SHALL assure that the digital certificates signature validates to an individual or certificate chain that is trusted.
    • Direct Project solutions MAY use OCSP or CRL to validate that the digital certificate has not been revoked
    • Direct Project solutions SHALL assure that the digital certificate was issued to the expected entity (sender or recipient)

End-to-End Message Authentication

  • All Direct Project solutions SHALL support the authentication of S/MIME messages using digital certificates.
  • The Direct Project content SHALL include the sender's digital certificate and whole trust path

End-to-End Message Encryption

  • All Direct Project solution SHALL support encrypting with at least one algorithm endorsed by FIPS 140-2 Annex A
  • Direct Project solutions SHOULD default to using AES-128
  • Implementations MUST either support full message wrapping or take responsibility for ensuring that header information that is not secured does not contain protected health information or other data that could compromise the privacy and security of health transport.

End-to-End Message Integrity

  • All Direct Project solution 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.


Addressing


Synopsis


Direct Addresses consist of a Health Domain Name portion, which is a fully qualified domain name, and a Health Endpoint Name. The intent of a Direct Address is to provide a method of routing from an origination point to the addressed recipient, not to provide a single, definitive ID for the intended recipient. The same real-world person may have multiple Direct Addresses (e.g. one address for each practice location, multiple addresses for different processing purposes such as labs, routed to the EHR, vs unstructured messaging, routed to the secure messaging client and copied to the chart).

Health Domain Name

A Health Domain Name is a string conforming to the requirements of RFC 1034.
 
  A Health Domain Name identifies the organizations that assigns the Health Endpoint Names and assures that they correspond to the real-world person, organization, machine or other endpoint that they purport to be. Example: nhin.sunnyfamilypractice.example.org. A Health Domain Name MUST be a fully qualified domain name, and SHOULD be dedicated solely to the purposes of health information exchange.
 
  Organizations that manage Health Domain Names MUST maintain DNS entries for the Health Domain Name.
  Organizations that manage Health Domain Names MUST ensure that a transport mechanism meeting the requirements of this document is available for that address. Organizations MAY elect to provide additional transport mechanisms with equivalent semantics if and only if they have determined that both the sending and receiving address support that alternate transport.
 
  Organizations may take on the encryption, signature and certificate trust validation roles or assign this function to another organization (the Health Internet Service Provider or HISP) performing those functions as a service..

Health Endpoint Name


A Health Endpoint Name is a string conforming to the local-part requirements of RFC 5322

Health Endpoint Names express real-world origination points and endpoints of health information exchange, as vouched for by the organization managing the Health Domain Name. Example: drsmith (referring to in individual), sunnyfamilypractice, memoriallab (referring to organizational inboxes), diseaseregistry (referring to a processing queue).

Formatting


A Direct Address may be formatted as an e-mail address by following the addr-spec requirements of RFC 5322, using the Health Domain Name for the domain, and the Health Endpoint Name for the local-part.

Health Content Container


A Health Content Container (prior to signing and encrypting, as otherwise described in this document) SHALL be an Internet Message Format document conforming to RFC 5322.

When explicitly creating a Health Content Container, the message body SHALL be:


When processing a Health Content Container, there are three levels of conformant processing for a Health Content Container:

  1. Basic processing, which MUST process simple content type bodies and multipart/mixed (where the main body part is multipart/mixed) content type message bodies, including base64 encoded body parts, and properly interpret the associated content type metadata (but need not understand all possible content types) as documented in this specification. Basic processors MUST follow the RFCs in understanding all other multipart not explicitly otherwise understood as multipart/mixed.
  2. Email processing, which MUST be able to understand a message sent over the ordinary email, including the de facto standard use of multipart/alternative for richtext/html formatted messages, and the de facto standard uses of attachments in ordinary email.
  3. XDS Metadata processing, which MUST interpret a multipart/mixed format where the body parts are base64 encoded compressed XDM files (XDM zip files)


Multipart is a recursive container specification, in that body parts may themselves be multipart messages. Notwithstanding that, Health Content Containers are RECOMMENDED to be flat, such that the multipart/mixed or multipart/related sections contain only simple content types, and conformant processors are NOT REQUIRED to interpret nested multipart body parts (except as specified for multipart/signed and multipart/encrypted, where the main body part will be a multipart content type). The RECOMMENDED method for transporting highly structured and nested sets of folders and documents is by means of XDM compressed files using the multipart/mixed message body.

Message Headers


The following message headers documented in RFC 5322 are required:

Header
 Content
 Example
from
 Source addressee as a Direct Address formatted as an email address
 drsmith@nhin.sunnyfamilypractice.example.org
to
 Destination addressee as a Direct Address formatted as an email address
 drjones@nhin.happyvalleypractice.example.org
orig-date
 As per RFC 5322
 Thu, 8 Apr 2010 16:00:19 -0400
message-id
 As per RFC 5322. If explicitly created as a Health Content Container, left part constrained to be a GUID, right part the Heath Domain Name
 <db00ed94-951b-4d47-8e86-585b31fe01bf@nhin.sunnyfamilypractice.example.org>
in-reply-to, references
 As per RFC 5322
cc
 If intended, the CC header SHOULD be populated
MIME-Version
 Always "1.0"


While common use in e-mail may have SMTP headers different from RFC 5322 headers, it is RECOMMENDED that the RECV FROM SMTP command match the RFC 5322 from header. It is also RECOMMENDED that the SMTP TO command match the union of to and cc. It is RECOMMENDED that the bcc header not be used. A processing model that accepts data originated by e-mail clients is RECOMMENDED to handle {bcc}} explicitly, but no guidance (beyond that provided by RFC 5322) is provided in this document for how that should be done.

The use of other headers, both those specified by RFC 5322 and those commonly used by email clients is optional.

SMTP Background


Use of this specification is not confined to SMTP transport, but does use SMTP at some leg of the communications. In addition some implementations of this specification are of a "security agent" model operating as a filter in the SMTP processing pipeline. Therefore, the relevant aspects of the SMTP message routing pipeline are described here.

This section is non-normative.

SMTP Message Routing


A sender transfers a message to an SMTP Server by issuing SMTP commands in this order:

MAIL FROM:<bob@nhind.source.example.org>
RCPT TO:<alice@nhind.dest.example.com>
DATA
< raw ASCII encoded message, including all headers>


It is important to note is that all source and destination addresses used by the SMTP Server are separate from the message itself. The SMTP Server does not need to parse the message to route it.

  1. Servers do not use message Destination Headers - To, CC or BCC - to determine the list of message recipients. All recipients must be specified using one or more rcpt to commands.
  2. Servers do not use message Originator Headers – From or Sender - to determine message sender. The message sender must be specified using the mail from command.


Consequently:

  1. The recipients specified using RCPT TO might not be found in the message Destination headers
  2. The sender specified using MAIL FROM need not match the sender in the message Originator headers


Both scenarios can occur legitimately, such as for implementing features like mailing lists and BCC.

SMTP Message Envelope


To process a message, the SMTP Server creates an internal message envelope. This envelope contains:

  1. Recipients – the list of all recipients submitted using the RCPT TO command.
  2. Sender – the message sender submitted using the MAIL FROM command.
  3. Message – exactly the message data submitted by the user.


The message envelope is conceptually represented by an MessageEnvelope pseudo class:

//
// Pseudo Class
//
public class MessageEnvelope
{
    public MailAddressCollection Recipients;
    public MailAddress Sender;
    public MailMessage Message;
}


SMTP Local Domain


SMTP Servers are configured with their local domain.

A mail message may be sent to addresses in multiple domains. Some of these addresses are local (internal) and others may be remote (external). The mail client transfers the message to its SMTP Server, which categorizes each address as local or remote – by comparing their address domain to its configured local domain. Mail sent to local addresses is delivered to the message store of IMAP/POP3 server or even a file folder. Messages sent to remote addresses are relayed to the SMTP Servers for those domains, which is discovered by resolving DNS MX records.

S/MIME Overview


The following represents a high level overview to RFC 3851, which should be referred to for details. This section assumes a solid understanding of MIME and standard cryptographic methods.

Details such as S/MIME’s usage of Cryptographic Message Syntax (CMS) and PKS7 standards are not discussed. Please refer to RFC 3851 as necessary as well as widely available documentation on cryptographic methods.

This section is non-normative.

What is secured?


S/MIME secures MIME entities.

A MIME entity is defined as:

  1. The MIME specific headers and
  2. The MIME content/body (the portion consisting of the empty line and the subsequent body content)


MIME specific headers have names that begin with Content- . These include:

  • Content-Type
  • Content-Transfer-Encoding
  • Content-Disposition


All non-content header – i.e. any headers whose name does not begin with “Content-“ - are not secured.

S/MIME secures the entity as is – the raw “wire” octets of both MIME Body Content and Headers. S/MIME implementations must avoid accidental loss of wire text fidelity during entity serialization.

Header Fidelity


Two headers that are functionally equal need not be byte identical or occur in the same order in the RFC 5322 message. The serialized wire text for the headers thus may be different even though they convey the same information. Headers with different wire texts will always have different signatures.

MIME libraries often normalize headers during serialization. The library can automatically unfold a header during de-serialization. When the same header is serialized back out, the MIME library may not fold the header, or write header parameters in a different order. These alterations break signatures.

S/MIME implementations must ensure that:

  1. Text case sensitivity is maintained
  2. Character Escape sequences are maintained
  3. If a header uses line folding, then the header is secured with the line folding in place – the whitespace must not be lost.
  4. Header parameters are in the same order, with the same escape sequences and whitespace.


Accidental loss of header fidelity by MIME libraries is a frequent cause of S/MIME interoperability issues and unexpected signature verification failures.

Encryption


S/MIME encrypts entities by combining symmetric and asymmetric encryption. S/MIME can encrypt an entity for multiple recipients without creating a separate copy of the entity for each recipient. It does so using facilities provided by CMS. The concepts behind the algorithm are explained below.

Encryption Algorithm

  1. Get all public keys for each recipient
  2. Generate a secret symmetric encryption key
  3. Use the symmetric key to encrypt the MIME entity into encrypted bytes
  4. Encrypt the secret symmetric key with each public key (separately) to create an encrypted key collection
  5. Combine the encrypted bytes, the encrypted key collection into an envelope


Decryption Algorithm

  1. Scan encrypted key collection to locate an encrypted key that was encrypted with the recipient’s public key
  2. Decrypt the encrypted key using the associated recipient private key to get the secret symmetric key
  3. Get the encrypted bytes from the envelope.
  4. Decrypt encrypted bytes using the secret symmetric key to obtain original MIME entity.


Signatures

This specification follows the S/MIME specification recommendation by requiring use of so-called "detached signatures", which separate the signature data from the original signed content by use of the multipart/signed content type. (It sometimes causes confusion that the "detached" signatures show up as attachments in e-mail clients, because such clients interpret multipart/signed as multipart/mixed, and thus interpret the signature as an unknown attachment type).

Signature Creation

  1. Get all the (private key, public certificate) pairs for each signer
  2. Compute a digest of the entity
  3. Create a signature for each signer by encrypting the digest using their private key.
  4. Attach information about each signer (their public certificates) to each signature
  5. Combine all signatures into a signature MIME entity (of type application/pkcs7-signature)
  6. Create a new container Multipart MIME entity of Content-Type: multipart/signed
  7. Insert the original entity as the first part of the Signed Entity.
  8. Insert the signature entity as the second part of the Signed Entity


Signature Verification

  1. Get the signature envelope from the Signed Entity
  2. Get the original entity from the first part of the Signed Entity
  3. Compute a digest of the entity
  4. Decrypt each signature using the attached signer public certificate
  5. Compare the digest to the signature value


Content Security for Simple Health Transport Use of S/MIME


Detached Signatures


Implementations of this specification MUST use detached signatures as specified by RFC 3851. They MUST use a multipart/signed main body part, and the the standard content type (application/pkcs-signature for the detached signature body part. They MUST be able to accept a content type of application/x-pkcs-signature as well.

Certificates in Signatures


Signatures MUST include the signing certificate and the full certificate chain up to the root CA, following the requirements of RFC 5652

Content Security


Implementations MUST support creation and processing of signed and encrypted MIME entities. That is, they MUST be capable of creating and reading documents that are:

  1. Encrypted as Enveloped Data, as specified by RFC 3851, with content type application/pkcs-mime (although implementations MUST be capable of also accepting application/x-pkcs-mime).
  2. A multipart/signed document, where the first part is the secured document and the second part is the detached signature.


Implementations that perform Content Security MUST take responsibility for securing all sensitive data, including data that might exist in RFC 5322 headers, such as Subject. Implementations are RECOMMENDED to use full message wrapping, as documented in this specification.

Digest Algorithms

The implementation MUST support the following Digest Algorithms:
  1. SHA1
  2. SHA256


Implementations MUST NOT support less secure Digest Algorithms, including additional algorithms listed as SHOULD- in RFC 5751 section 2.1 (e.g., MD5)

Implementations MAY support more secure Digest Algorithms, as listed as SHOULD+ in RFC 5751 section 2.2 but senders should be aware that receivers may not support more secure algorithms.

As security standards evolve, the list of MUST and MUST NOT algorithms is subject to change in future version of this specification. Implementations are RECOMMENDED to support configurable or pluggable support for algorithms.

Encryption Algorithms

The implementation MUST support the following Encryption Algorithms:
  1. AES 128
  2. AES 256



Implementations MUST NOT support less secure Digest Algorithms, including additional algorithms listed as SHOULD- in RFC 5751 section 2.2.

Implementations MAY support more secure Digest Algorithms, as listed as SHOULD+ in RFC 5751 section 2.1 but senders should be aware that receivers may not support more secure algorithms.

As security standards evolve, the list of MUST and MUST NOT algorithms is subject to change in future version of this specification. Implementations are RECOMMENDED to support configurable or pluggable support for algorithms.

DNS CERT

This section assumes familiarity with the DNS protocol and DNS Servers. It describes how to use the DNS capabilities described in RFC 4398 in this context.
 
  As noted, implementations SHOULD support these capabilities to achieve universal certificate discovery. Those that do MUST support the requirements in this section.
 
  DNS Resource Records are associated with a domain – which serves as the record’s primary key. RFC 4398 provides multiple mechanisms to associated a domain name to a certificate record. Implementations MUST support two mechanisms:
  1. E-mail Address to Domain Name
  2. Organization Level


E-mail Address To Domain Name


To associate DNS CERT records with e-mail addresses, the Direct Address address SHALL be formatted as a domain name.

cert-domain-name = health-endpoint-name '.' health-domain-name


That is, the DNS cert domain name is constructed by replacing the '@' in the e-mail address with ‘.’

For example: bob@nhind.example.org becomes bob.nhind.example.org

Note that in rare cases, a dotted last name may be confused with a subdomain. For example bob.smith@example.org and bob@smith.example.org may be confused. For organizations using CERT records for multiple purposes for the same domain name, the use of fully qualified domain names with special purpose subdomains is RECOMMENDED. For example, organizations should distinguish bob.smith@mail.example.org and bob.smith@exchange.example.org to limit this issue.

Organizational Level


Implementations supporting DNS MUST support organizational level certificates. Such certificates MUST be retrieved if no more specific certificate is found for the address.

Organizational level certificates are stored under the health-domain-name for the address.

For example: bob@nhind.example.org may have an organizational level certificate stored under nhind.example.org


Resource Record Format

RFC 4398 prescribes the DNS CERT record format. To store certificates in conformance with this specification, CERT records MUST be provided as follows:
  1. Certificate Type: 16 bit number field set to 1 [X509] .
  2. Key Tag: Unused and set to 0.
  3. Algorithm: Byte field set to 5 - [RSASHA1]. Note that this is a placeholder value.
  4. Certificate: MUST be the Base64 encoded DER representation of the X.509 Certificate.


Non-Normative Example

The following CERT record contains the X509 Certificate for [[1]]
 
 
bob.nhind.example.org. IN CERT 1 0 5 (
MIIDfzCCAuigAwIBAgIKcYxqqAAA
AAAAFzANBgkqhkiG9w0BAQUFADAV
MRMwEQYDVQQDEwpVTS1BTUFMR0Ex
MB4XDTEwMDYwMTE3NTM1NVoXDTEx
MDYwMTE4MDM1NVowgY0xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJXQTEQ
MA4GA1UEBxMHUmVkbW9uZDEMMAoG
… Removed for Brevity …
)


The following CERT record contains an organizational level X509 Certificate for [[2]]

nhind.example.org. IN CERT 1 0 5 (
MIIDfzCCAuigAwIBAgIKcYxqqAAA
AAAAFzANBgkqhkiG9w0BAQUFADAV
MRMwEQYDVQQDEwpVTS1BTUFMR0Ex
MB4XDTEwMDYwMTE3NTM1NVoXDTEx
MDYwMTE4MDM1NVowgY0xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJXQTEQ
MA4GA1UEBxMHUmVkbW9uZDEMMAoG
… Removed for Brevity …
)



Use of TCP

The DNS protocol can run on either UDP or TCP. Both methods use Port 53.
 
  Certificate records are relatively large (> 1.5K). A DNS response that returns Certificate Records is likely to exceed configured server side UDP buffer limits. The server will label these responses as Truncated.
 
  To retrieve DNS Certificates, the DNS Resolver is RECOMMENDED to use TCP. The resolver may have to be configured to use TCP by default. Some resolvers may automatically upgrade to TCP when they encounter truncated responses.
 
  Generally DNS traffic uses UDP and it is possible that TCP traffic on port 53 is disabled by default firewall rules.
 
  Firewalls may need to be configured to allow TCP traffic on Port 53.

Certificate Usage


Managed Addresses and Certificates and Keys


A given implementation will manage content security on behalf of a set of Direct Addresses (that set MAY be a single address or MAY be a set of organizations). Those addresses will be termed Managed Addresses in this document.

Each implementation MUST maintain a set of valid certificate and key pairs for each Managed Address. The mechanism by which keys are managed and stored is implementation specific, and MAY include files, memory, LDAP, a database, etc.

The implementation MUST return the certificate/key pairs for each Managed Address for the purpose of signature or decryption. Implementations MAY support these at the individual user or domain level.

The implementation SHOULD publish the certificates through the mechanism or mechanisms supported for discovery of non-managed certificates. That may include use of DNS as described in this document.

Trust Anchors


Each implementation MUST, for each Managed Address, be able to discover a set of trusted anchor certificates (trust anchors, as defined in RFC 5260, section 6). The mechanism by which that association is performed and by which trust anchors are selected and maintained is a critical matter of policy that is not defined in this document.

Note that by stating that implementations must discover a set of trust anchors by address, it is not implied that the set must be different for each Managed Address. Consistent with local policies, implementations MAY support the same set for each domain, or the same set for all supported addresses.

Certificate Verification


Each X509 Certificate has a Subject Distinguished Name, which contains one or more attributes. These attribute define who the certificate is issued to.

An X509 certificate used for the purposes of secure health message exchange MUST be issued to one of:

  1. A specific address. E.g. [[3]]
  2. A domain. E.g. nhind.example.org


A domain certificate is issued to a domain and can be used to secure message exchanges with or for any address in that domain.

The Agent MUST verify the address or domain that an X.509 certificate is issued to by following the guidance in sections 4.1.2.6 and 4.2.1.7 of RFC 5280:

  1. If the subjectAltName extension is present and an rfc822Name is included then it contains the e-mail address.
  2. If the Subject Distinguished Name contains an EmailAddress legacy attribute, then it contains the e-mail address.
  3. If both of the previous locations contain an e-mail address, they must match.
  4. If no e-mail address is found then if the subjectAltName extension is present and a dNSName is included then it will contain the domain.


Certificates may contain usage extensions that place restrictions on how the certificate key may be used. S/MIME implementations may also require that certificates be issued specifically to secure e-mail.

Implementations MAY by policy enforce either restriction (or any other more restrictive policy) but need not. Implementations MAY support any valid, non-expired, non-revoked and trusted certificate.

Implementations MUST check that a certificate is valid:

  1. Has not expired
  2. Has a valid signature
  3. Has not been revoked
  4. Was issued to the expected entity
  5. Is trusted (see below)


Certificate Paths and Trust


Certificate Paths


For each Managed Address or each non-Managed Address for which certificate discovery was successful and implementation will hold the leaf public certificate or certificates corresponding to that address. The implementation will then need to construct the full certificate path from the leaf certificate back to a supported trust anchor.

Discussion of certificate paths and path verification is found in RFC 5280, Section 6. A given leaf certificate MUST chain back to a trust anchor that is mutually trusted by sender and recipient.

For received messages, the message signature MUST include the full certificate chain. When sending, implementations MUST construct and verify the full certificate path for receivers. The mechanism by which this is done is left to the implementation, but may include:

  1. Local storage of full certificate paths accessed through out of band transfer (e.g., by prior receipt of a signed but unencrypted message).
  2. Use of the same mechanism used to discover recipient certificates (e.g. DNS, LDAP)
  3. Use of the Authority Information Access extension (RFC 5280, Section 4.2.2.1)


Use of the Authority Information Access extension mechanism is RECOMMENDED as it provides a secondary method for retrieving intermediate certificates.

Certificate Trust


Normative discussion of certificate path verification is found in RFC 5280, Section 6.

Each implementation MUST maintain an association with a supported address (sender or recipient) and a collection of Trusted Anchors. The address trusts any valid leaf certificate whose certificate chain contains at least one certificate from the address’s Anchor list.

To determine if a leaf certificate is trusted:

  1. Build a certificate chain for the leaf certificate (see above).
  2. If the chain cannot be built, reject leaf certificate as un-trusted.
  3. Traverse up the chain, starting at the bottom. For each certificate:
    1. If the certificate is invalid, then reject leaf certificate as un-trusted
    2. If an entry in the certificate chain is found in the Trusted Anchor list the leaf certificate is trusted.
    3. If the entire trust chain contains zero trusted anchors, the leaf certificate is un-trusted.


Implementations MAY store self-signed certificates in the collection of Trusted Anchors. Self signed certificates have a certificate chain of length 1. Consequently, a trusted self-signed leaf certificate must also be a trusted anchor.

Message Wrapping


There are deployment models where it is possible for the sending user to accidentally place sensitive information into the e-mail "Subject" field. Message bodies can be protected using digital signatures and encryption. Message headers are more challenging to protect because they are always transmitted in the clear. Signatures that include non-MIME specific headers break easily because SMTP servers legitimately add, remove and rewrite message headers in transit. Worse, some headers (such as Subject) may unwittingly contain Protected Health Information (PHI) or other sensitive health information. RFC 5731 (S/MIME 3.2), section 3.1 describes a method for protecting such headers by wrapping the full message.

As described in the Conformance section, implementations MAY perform full message wrapping. Implementations that support full message wrapping MUST conform to the requirements of this section.

To reliably protect the message body and all its headers, implementations MUST encrypt the entire Internet Message Format document. To do so, implementations:

  1. Ensure the document is a valid Internet Message Format document. This MAY require creation of required headers (e.g., Message-ID, Date). The resulting message (post required header creation) is termed the original document
  2. Copy required headers - as listed in the Content Container Specification - from the original document. No other headers are copied.
  3. Create a new message/822 MIME entity where the body is the bit-identical original document


The resulting message/822 MIME entity is termed the wrapped document

Unwrapping consists of extracting the MIME body and treating it as an RFC 5322 message. Implementation should note that receivers who do not understand message wrapping may present such messages in ways that are confusing to end users.

Content Security Algorithm Specification


The Content Security Algorithm operates on Message Envelope objects. It implements the following conceptual interface:

    // Conceptual interface
    interface IDirectAgent
    {
        OutgoingMessage ProcessOutgoing(MessageEnvelope messageEnvelope);
        IncomingMessage ProcessIncoming(MessageEnvelope messageEnvelope);
    }

These operations MAY be applied at various points, but typically are applied twice: once prior to sending, and once upon ultimate receipt or preparation for ultimate receipt. The operations MAY be applied by the sender and receiver of the message, or by agents of the sender and receiver. Such agents MAY be embedded in special purpose mail servers created to securely transfer health content.

The ProcessOutgoing step enforces the sender’s Trust setting, then signs and encrypts the outgoing message.
The ProcessIncoming step decrypts the incoming message, verifies signatures, and enforces each recipient’s Trust settings.

For implementations that are implemented as filters in the SMTP processing pipeline, the trust settings SHOULD be enforced on the addresses provided through SMTP in the RCPT TO and MAIL FROM commands, in preference to the header values contained in the RFC 5322 document itself.

Process Outgoing

An outgoing message is a new message being sent to a set of recipients.
 
  The implementation MUST ensure:
  1. The sender is trusted
  2. The message is sent to only those recipients who the sender trusts


To verify that the sender is configured to send Simple Health Transport messages, the implementation retrieves the sender’s private keys and public certificates. If no private key can be found, the implementation can assume that the sender is not configured to send messages and can reject the message.

To verify that the sender trusts a given recipient, the implementation retrieves the recipient’s public certificates. The implementation MUST use the DNS method and MAY use other locally supported methods.

To process outgoing messages, the implementation:

  1. Resolves private keys for messageEnvelope.Sender
  2. Resolves public certificates for each messageEnvelope.Recipients
  3. Enforces the Trust Model
  4. Wraps messageEnvelope.Message (see Message Wrapping)
  5. Signs and Encrypts the wrapped MIME entity with the sender certificates and private key pair and recipient public certificates
  6. Creates a new messageEnvelope.Message with the headers extracted in the message wrapping process and the MIME package created by signing and encrypting


The implementation MUST check recipient certificate trust. If the recipient is un-trusted, the implementation removes the recipient from the recipient list. If a message has no trusted recipients, the implementation MUST reject the message.

The implementation returns the following conceptual object to indicate success:

    // Conceptual Object
    public class OutgoingMessage
    {
        // The secured message
        public MessageEnvelope MessageEnvelope;
        // List of rejected/untrusted recipients
        public MailAddressCollection UntrustedRecipients;
        // Other Status Information for invoking code
        ...
    }

The implementation MUST indicate a rejected message by returning an appropriate error code or throwing an exception.

The mechanism for communicating message rejection and recipient removal to the sender is specific to how the agent is integrated with a message processing pipeline. For example, SMTP integrations MAY send message delivery failure notifications to the sender. Integrations may choose to log the list of untrusted recipients for internal auditing and/or debugging.

Process Incoming


An incoming message is signed and encrypted – i.e. it has passed through the ProcessOutgoing method.

The implementation MUST ensure that the message is delivered only to those recipients who:

  1. Really are the intended recipients of the message
  2. Trust the sender


To verify that a recipient is the intended recipient, the implementation attempts to decrypt the message using each of the recipient’s private keys until decryption succeeds. The implementation then MUST verify that the resulting message is in the expected signed format (e.g., has content type mulitpart/signed and corresponds the the requirements for that content type.

If the recipient has no private keys, or the decryption fails for all recipient keys, the implementation can assume that the message was not encrypted with the recipient’s equivalent public certificate and MUST reject the message.

To ensure that the recipient does not receive the message, The implementation removes the recipient from the message’s recipient list.

To verify if a recipient trusts a sender, the implementation MUST check if the sender signed the message with a certificate that the receiver trusts. A sender can sign the message using the private keys associated with multiple public certificates, each of which may represent its membership in different trust circles. The implementation finds at least one valid signature with a certificate whose trust chain contains an anchor that the recipient trusts.

An implementation MUST perform the following steps:

  1. Resolve private keys for domain recipients
  2. Decrypt messageEnvelope.Message
  3. Extract the signed Signed Entity
  4. Verify the signature
  5. Enforce Trust Model
  6. Unwrap message


Signatures are verified by:

  1. Ensuring the signature has an attached certificate
  2. Checking that the certificate is properly issued
  3. Verifying the signature with the certificate


If the implementation does not find at least one acceptable sender signature, it MUST reject the message.

Finally, the implementation unwraps the message and constructs a new MessageEnvelope with Sender, valid Recipients, and unwrapped message.

The implementation may return the following conceptual object to indicate success.

    // Conceptual object
    public class IncomingMessage
    {
        // The processed message - decrypted, signatures verified
        public MessageEnvelope MessageEnvelope;
        // Recipients in the local domain about to receive this message
        public MailAddressCollection DomainRecipients;
        // Recipients who were removed as Untrusted
        public MailAddressCollection UntrustedRecipients;
    }

The implementation MUST indicate a rejected message by returning an appropriate error code or throwing an exception.

The mechanism for communicating message rejection and recipient removal is specific to how the agent is integrated with a message processing pipeline. For example, SMTP integrations MAY send message delivery failure notifications to the sender. Integrations may also chose to log such events.


Use of Message Disposition Notification


Implementations SHALL send Message Disposition Notification messages conforming to RFC 3798, and implementing the message security requirements in this document (that is, the MDN messages MUST be signed and encrypted, from the original message receiver to the original message sender).

MDN messages MUST be sent on successful trust verification, and MAY be sent in other situations (e.g., error, successful client receipt, etc.). Note that MDN can not be sent in the situation where the message is not trust verified from the perspective of the receiver (because the reciprocal signature and encryption step for the MDN will fail). Unencrypted MDN MUST NOT be sent back to the original message sender in this case (to do so would create a means for an attacker to "sniff" for a valid address for later attack).

Simple Health Transport use of MDN


The Status MDN SHALL be an RFC 3798 Message Disposition Formatted Internet Message Format document.

The following clarifications and changes are applied in the use of RFC 3798 by this document:

disposition-type = "displayed"
                 / "processed"


Note that the production grammar for RFC 3798 removes the processed value from the disposition-type definition, but refers to them in the RFC text.

The disposition-type of processed SHALL be interpreted to mean that the message has been accepted by the Destination HISP but has not been delivered to the Destination.

The disposition-type of displayed SHALL be interpreted to mean that the message has been delivered successfully to the Destination.

The disposition-type of deleted, defined in RFC 3798, is not defined in this specification.

When the disposition-modifier is error, the error-field MUST be provided, and SHOULD provide error text that is formatted according to the error handling rules for the content that was transmitted (for example, HL7 V2 error reporting for HL7 V2 messages).

Security Considerations


Given the Protections specified, 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



S/MIME protects the message content end-to-end, that is the message can only be decrypted by the party holding the private key corresponding to the public certificate used for encryption. Therefore encrypted messages can travel in the wild without risk to the contents.

Summary of Risk and Mitigation


There are some common risks to all deployment models that need to be considered at the operational level.

  • Exposure of TO/FROM routing information (network, wireless, internet mailstop). Exposing that the addressee identified in the TO is having a private conversation with the addressee identified by the FROM. Where the conversation is provider-to-provider; there is no knowledge of the topic of the conversation, it could be about a golf game. Where the conversation is provider-to-patient; there is knowledge of types of conversations (e.g. where the provider is a specialist)
    • Each Recipient is in control of who they provide their endpoint address to, and each Sender is in control of who they communicate with.
    • Care should be taken when issuing Direct Project endpoint addresses to limit the exposure of sensitive information in an address itself
  • The user may accidentally send sensitive content without security.
    • The 'security agent' deployment model is designed to intercept all traffic and encrypt or reject it.
    • Some e-Mail clients can be configured to only send using S/MIME and will thus refuse to send to an address that can't be secured
    • Use of Integrated EHR/PHR with the e-mail infrastructure means user does not have access to e-Mail User Interface
    • Use of "Data Loss Prevention" systems to detect and block sensitive information from leaving an organization (see: Gartner report)
    • User training and inspection of audit logs and sent traffic/folder could detect violations of policy
  • The user may send the content securely but accidentally send sensitive content in the email "subject" field. Although S/MIME protects well the content of a message, it does not protect the subject or other email header values. The recommendation is to have a blank or non-descriptive subject to prevent this.
    • The 'security agent' deployment model is designed to intercept all traffic and encrypt or reject it.
    • Use of Integrated EHR/PHR with the e-mail infrastructure means user does not have access to e-Mail User Interface
    • Use of "Data Loss Prevention" systems to detect and block sensitive information from leaving an organization (see: Gartner report)
    • User training and inspection of audit logs and sent traffic/folder could detect violations of policy
    • The use of TLS can mitigate this risk to the extent that the point-to-point connection is controlled. TLS can only protect point-to-point, and thus would require that all pathways along the communications is similarly protected.
  • DNS can be spoofed to return an attacker’s IP addresses rather than the correct ones. This could cause messages to be sent to an attacker’s system.
    • TLS can be used at the SMTP level. This would add another layer of authentication that must be passed, but also adds to complexity of configurations.TLS is only guaranteed to the first point. This is an important step, but there may be other SMTP mail servers in the path





Examples


This section is non-normative.


Authors

Umesh Madan
  Sean Nolan
  Arien Malec

References


Normative References


RFC 1035

Mockapetris , Domain names - implementation and specification. RDC 1035, November 1987

RFC 2119

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

RFC 2045

Freed, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November 1996

RFC 3798

Hansen & Vaudreuil, Message Disposition Notification, RFC 3798, May 2004

RFC 4398

Josefsson, Storing Certificates in the Domain Name System (DNS), RFC 4398, March 2006

RFC 4034

Arends et al., Resource Records for the DNS Security Extensions, RFC 4034

RFC 5280

Cooper et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 5280, May 2008

RFC 5322

Resnick, Internet Message Format RFC 5322, October 2008

RFC 5652

Housley, Cryptographic Message Syntax, RFC 5662, September 2009

RFC 5751

Ramsdell and Turner, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751, January 2010


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.
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Simple_Health_Transport&oldid=754"