SMTP Implementation

From Direct Project
Jump to navigation Jump to search

SMTP Implementation


THIS PAGE IS RETIRED. PLEASE REFER TO THE SMTP CONCRETE IMPLEMENTATION WORKGROUP PAGE FOR CURRENT INFORMATION.


Overview


This document suggests a mapping of the following technologies onto the associated NHIN Direct Abstract Model. The overarching theme of this mapping is the use of currently existing and widely understood Internet technologies/services/standards.

An SMTP Implementation Development Team is being organized to advance this proposal to a concrete instance. Please join that team if you have expertise, software development skills, and time to contribute. Source code.

Note that an HTTP/REST-based mapping and an IHE-based mapping exist. It is feasible that NHIN Direct could choose to specify both (or a mixture of both) to appeal to a wider audience. For example, SMTP/POP on the edges and HTTP/REST between HISPs.

NHIN Direct Message

  • Multipart MIME. A good overview of MIME may be found here including a listing of relevant IETF RFCs.


NHIN Direct Source Edge Protocol

  • SMTP potentially over TLS.


NHIN Direct Destination Edge Protocol

  • POP version 3 potentially over TLS. IMAP is another potential protocol choice, but POP is used here.


NHIN Direct Address

  • Standard e-mail address format: user@domain. It is possible that the domain is healthcare-specific. This implies an MX resource record in DNS for the healthcare domain name (e.g., nhind.NelsonCardiology.com) that maps to an SMTP server that is likely associate with an HISP.


NHIN Direct Certificate Directory

  • DNS using the CERT resource record. This choice is likely to be controversial in that the CERT resource record type is not often used in non-secured DNS (i.e., not DNSSEC). However, certificates are signed and with appropriate checking by the client could be verified as valid for an address. The advantage of using DNS is its wide availability.


NHIN Direct HISP Address Directory

  • DNS using the standard MX resource record type to associate the domain portion of the NHIN Direct Address (e.g., nhind.NelsonCardiology.com) with the SMTP server address of the HISP.


NHIN Direct Backbone Protocol

  • SMTP potentially over TLS.


Source to HISP


Transaction 1.1: Source authenticates to HISP

  • The authentication and privacy requirements on this transaction are intended to be a matter of NHIN Direct policy. In this implementation, the MUA (mail user agent) is authenticating to the MTA (mail transfer agent). If SMTP over TLS is used, then this could be done via the mechanisms in IETF RFC 3207. Note that this choice of technology (along with the choice of multipart MIME as the message specification) opens up the possibility of configuring an existing mail client as the Source. This would take the form of a separate secure email account tied to the Source's HISP. Any existing email accounts configured in the client would be unaffected.


Transaction 1.2: Source sends NHIN Direct Message to HISP

  • The Source formulates a standard multipart MIME message with content that it expects will be understood by the Destination. This is likely done through standard email client interactions (attachments, typed message body, etc...). An example might be:


  • MIME-Version: 1.0
  • Content-Type: multipart/mixed; boundary="8837833223134.12.9837473322"

  • This text is traditionally ignored but can
  • help non-MIME compliant readers provide
  • information.
  • --8837833223134.12.9837473322
  • Content-Type: text/plain

  • Attached is a clinical summary from a recent visit for patient John Doe
  • located at 123 Main Street, Eagan, MN. John will be scheduling with you for
  • follow-up in relation to his complaints of frequent headaches.

  • --8837833223134.12.9837473322
  • Content-Type: application/pdf; name="clinicalsummary-johndoe.pdf"
  • Content-Transfer-Encoding: base64
  • Content-Disposition: attachment; filename="clinicalsummary-johndoe.pdf"

  • <base64 encoded PDF here>
  • --8837833223134.12.9837473322--


  • The Source is expected to know the Destination's NHIN Direct Address. This can be obtained from a local directory likely populated from prior interactions. The Source inserts it into the "To" field of his email client.
  • Once the Source is done composing the email, he sends it to his HISP over the secure link established above. As mentioned above, the NHIN Direct Source Edge Protocol is SMTP possibly over TLS.
  • The HISP receives the multipart MIME message and, prior to persisting it, signs the message using the S/MIME format as specified in IETF RFC 3851. Specifically, the multipart/signed Content-Type is used. Because S/MIME is based on standard multipart MIME sub-types and because multipart MIME supports nested multipart entities, the original multipart/mixed message above becomes a single part of the resulting multipart/signed content. The private key associated with the Source is used. For example:


  • MIME-Version: 1.0
  • Content-Type: multipart/signed;
  • protocol="application/pkcs7-signature";
  • micalg=sha1;
  • boundary="boundary-signed736223"

  • --boundary-signed736223
  • Content-Type: multipart/mixed; boundary="8837833223134.12.9837473322"

  • This text is traditionally ignored but can
  • help non-MIME compliant readers provide
  • information.
  • --8837833223134.12.9837473322
  • Content-Type: text/plain

  • Attached is a clinical summary from a recent visit for patient John Doe
  • located at 123 Main Street, Eagan, MN. John will be scheduling with you for
  • follow-up in relation to his complaints of frequent headaches.

  • --8837833223134.12.9837473322
  • Content-Type: application/pdf; name="clinicalsummary-johndoe.pdf"
  • Content-Transfer-Encoding: base64
  • Content-Disposition: attachment; filename="clinicalsummary-johndoe.pdf"

  • <base64 encoded PDF here>
  • --8837833223134.12.9837473322--

  • --boundary-signed736223
  • Content-Type: application/pkcs7-signature; name=smime.p7s
  • Content-Transfer-Encoding: base64
  • Content-Disposition: attachment; filename=smime.p7s

  • uhyHhHTujhJhjH77m4HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
  • 4VQpfyG467GhIGfHfYT6jH77n8HHGgoyHhHUujhJh756tbB9HGTrfvbnj
  • n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhPGfHfYT6ghyHhHUujpfyF4
  • 7GhIHfHfYT64VQbnj354

  • --boundary-signed736223--


  • Using a DNS query for CERT resource records associated with the Destination domain name, the HISP looks up and retrieves the public key (certificate) of the destination. The feasibility and security of using DNS for CERT records should be debated thoroughly. The widespread availability of DNS is a strong benefit of this approach.
  • Before persisting or as part of persistence, the HISP encrypts the signed message above using the public key (certificate) associated with the Destination domain name. S/MIME is again used. At the end of this step, the payload is signed, encrypted, and persisted. MIME headers used for the outermost encrypted payload would look something like the following. Note that the symmetric algorithm used to encrypt the message content is effectively embedded into the metadata of the payload (part of the "enveloped-data" smime-type):


  • Content-Type: application/pkcs7-mime;
  • smime-type=enveloped-data;
  • name=smime.p7m
  • Content-Transfer-Encoding: base64
  • Content-Disposition: attachment; filename="smime.p7m"

  • y4uyKhHKujhJhjH77m4KHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
  • etc...


HISP to HISP


Transaction 2.1: Source HISP authenticates to destination HISP

  • As mentioned in the NHIN Direct Abstract Model, the authentication and privacy requirements for HISP to HISP transactions are a matter of policy. With the assumption of signed and encrypted payloads (S/MIME above), the requirements in this area become directly dependent on policy. SMTP over TLS could be used. Fundamentally, however, the intent in this implementation is to use SMTP as the transfer protocol between HISPs.


Transaction 2.2: Source HISP sends NHIN Direct Message to destination HISP

  • The source HISP sends the S/MIME signed and encrypted message to the destination HISP using SMTP (possibly over TLS). The destination HISP SMTP server is found via a DNS lookup for an MX record associated with the domain name of the destination (nhind.NelsonCardiology.com). Because an HISP can potentially host many source and destination domains, the HISP would be responsible for correct DNS population of MX records for all domains it supports.
  • The destination persists the S/MIME signed and encrypted messages and associates it with the specified NHIN Direct Address.


HISP to Destination


Transaction 3.1: Destination authenticates to HISP

  • A standard POP3-based authentication and privacy protocol is used to login and create a secure link from the Destination to the HISP. The mechanisms required are a matter of policy, but could be the standard POP3 USER and PASS commands and the TLS extensions to POP3 (e.g., STLS)


Transaction 3.2: Destination requests and downloads available NHIN Direct Messages from HISP

  • When a message is requested from the destination HISP via POP3, the HISP decrypts the S/MIME package using the private key associated with the logged in destination domain. It then verifies the signature using the public key associated with the domain of the source. The public key for the source is obtained using the same DNS lookup technique described above (via CERT resource records).
  • Using standard POP3, the HISP sends the original multipart MIME message (decrypted with no S/MIME signature) to the Destination.

Note that POP3 is based on the polling metaphor assumed between Destination and HISP in the NHIN Direct Abstract Model.
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=SMTP_Implementation&oldid=701"