Direct Certificate Discovery Technical Architecture

Modular Specifications – Certificate Discovery Architecture

1

DIRECT CERTIFICATE DISCOVERY TECHNICAL ARCHITECTURE

Office of the National Coordinator for Health Information Technology Version 1.0

March 29, 2012

Prepared By: Reference Implementation Team


2

Table of Contents 1. Introduction .......................................................................................................................................... 4

2. Purpose ................................................................................................................................................. 4

3. Scope ..................................................................................................................................................... 4

4. Research & References ......................................................................................................................... 5

5. Goals ...................................................................................................... Error! Bookmark not defined.

6. Constraints and Assumptions ................................................................ Error! Bookmark not defined.

7. Certificate Discovery Using DNS‐LDAP Hybrid Approach ...................... Error! Bookmark not defined.

7.1 Scenario ......................................................................................................................................... 7

7.2 High Level Process Workflow ........................................................................................................ 8

7.3 Assumptions ................................................................................... Error! Bookmark not defined.

8. Certificate Discovery – Detailed Workflow ........................................................................................... 9

8.1 Steps for Certificate Discovery for DIRECT Project Using DNS LDAP Workflow . Error! Bookmark

not defined.

9. Advantages ............................................................................................. Error! Bookmark not defined.

10. Risks ..................................................................................................... Error! Bookmark not defined.1

11. Recommendations ............................................................................... Error! Bookmark not defined.2

12. Glossary ................................................................................................ Error! Bookmark not defined.2


3

Document Change History

Version Date Changed By Changes 1.0 3/29/12 RI Team


4

1. Introduction

This document provides a high‐level technical architectural perspective of the Certificate Discovery

process using Direct as developed by the Office of the National Coordinator for Health Information

Technology (ONC) as part of the Direct Project.

The Certificate Discovery architecture defines the components, technologies and their workflow to

enable certificate discovery using the Direct Reference Implementation.

2. Purpose

The purpose of the Certificate Discovery Technical Architecture described by this architecture is to

promote modularization, and to provide consistency in applying technology to the solution designs. ONC

has applied a modular architectural approach to the analysis of specifications in order to achieve

interoperability among evolving parts of the Standards and Interoperability (S&I) Framework.

3. Scope

The scope of this architecture is limited to exploring the following scenarios:

1. Certificate Discovery using DNS and LDAP (Hybrid Approach).

2. Certificate Discovery using DNS (RFC 4398). If an LDAP server is unavailable, this scenario gets

covered under the hybrid approach.

The architecture model focuses on the technical aspects of Certificate Discovery as part of a basic Direct Project conversation between two email clients, each using a "full service" HISP that provides mail server functionality, server‐side security agent processing and DNS services.

Participants in the exchange are identified using standard email addresses (RFC 5322) associated with X.509 certificates. Although messages may contain multiple recipients, we have constrained our architecture to model to only one recipient for now.

Other configurations are possible; however they may be out of current project scope or may need a

separate analysis.


5

4. Research & References

The scope of this architecture is limited to exploring two key approaches to discovering certificates

The Reference Implementation team studied the Direct Project specifications, referred to technical

articles on the Direct Wiki, and consulted with technical experts within the Direct community. Our

understanding of the Certificate Discovery process based on the above research activities defines the

scope of this document.

Some of the artifacts consulted are:

1. Applicability Statement for Secure Health Transport document at

http://wiki.directproject.org/file/view/2011‐04‐28%20PDF%20‐

%20Applicability%20Statement%20for%20Secure%20Health%20Transport_FINAL.pdf

2. Certificate Pilot Recommendation Discussion at

http://wiki.directproject.org/Certificate+Pilot+Recommendations+Discussion

3. Threat Model for SMTP with full service HISP at

http://wiki.directproject.org/Threat+Model+‐+SMTP+with+Full+Service+HISPs

4. Direct Certificate Discovery RTM, prepared by the Modular Specification Team

5. Direct Trust Community Wiki ‐ www.DirectTrust.wikispaces.com


6

5. Goals

The goals of the Certificate Discovery architecture are to:

Provide a simple design for Certificate Discovery based on existing Direct RI components to

promote interoperability and secure exchange between Direct participants.

Model the certificate discovery mechanism and provide technical and risk/benefit analysis.

Address gaps in existing specifications/requirements with recommendations.

Address privacy and security concerns.

6. Constraints and Assumptions

1. The Direct Project allows secure communication of health data between health care participants who already know and trust each other and thus are bound by a set of simplifying assumptions. The Direct Project assumes that the sender is responsible for enforcement of minimal requirements before sending data, including the collection of patient consent, where appropriate.

2. The sender and receiver have ensured that agents of the sender and receiver (for example, HIO, HISP, intermediary) are authorized to act as such and are authorized to handle protected health information according to law and policy.

3. The sender of a Direct message has determined, through out‐of‐band means, that it is legally appropriate to send the information to the Receiver. The Sender has determined that the Receiver’s address is correct.

4. All normal Direct Project Consensus Proposal ‐ Assumptions are in play.

5. Technical discussion is limited to implementing Certificate Discovery using the DNS and LDAP technologies only. There could be other means of certificate discovery; however they are not mentioned here.

6. The Modular Specifications Phase 3 specifications include a number of ambiguous

statements/requirements that need further clarity.


7

7. Certificate Discovery Using DNSLDAP Hybrid Approach

Figure 1: Certificate discovery using DNS‐LDAP hybrid architecture

7.1 Scenario

[email protected] wishes to send a secure DIRECT message/email to [email protected].

Figure 1 models a basic Direct Project conversation between two email clients, each using a "full service" HISP that provides mail server functionality, Direct processing and DNS services.

Additionally, HISP2 has an LDAP server where it stores certificates.

In order for a secure message exchange to occur, HISP1 must retrieve the digital certificate of [email protected] using a DNS and/or LDAP query.

Direct at HISP1 uses local and public DNS hierarchy to query for certificates for provider at HISP2. If it cannot retrieve a certificate using DNS, it will look for an LDAP server and query it for certificates. The use of LDAP server is optional, however many organizations may deploy LDAP. Once a certificate is obtained, it’s returned to HISP1. If no certificate is found, HISP’s will need to exchange certificates using some out of band approach which is beyond the scope of this architecture.

The DNS resolvers default to searching for user level certificates before looking for org level certificates. The DNS lookup query will have the email address of the recipient: [email protected] for our example and the response will contain either the certificate for provider2 or an org level certificate for hisp2 but not both (if DNS has entries for both user level and org level certificates). The sending HISP will use the certificate to secure all communication with the receiving HISP.

HISP1 encrypts the email message using the certificate obtained from HISP2 (public key) and sends the message to the recipient.


8

7.2 High Level Process Workflow

1a) DNS Queries I. Query for an Individual Certificate. If a certificate is found, use that for secure message

exchange with HISP2. II. If an Individual Certificate is not found, then:

Query for an Organizational Certificate. If a certificate is found, use that for secure message exchange with HISP2.

III. If an Organizational Certificate is not found, then: Query for location of LDAP server hosted on HISP2. 1b) LDAP Query (if no certificate is found in step 1a) If an LDAP server is found, then: Direct at HISP1 queries LDAP server on HISP2 for a certificate. If found, use for securing message. 2) If a certificate is found, the certificate is returned to Direct at HISP1. 3) Direct at HISP1 uses the certificate to encrypt and send secure message to provider at HISP2.

7.3 Assumptions

1. Sender (HISP1) and receiver (HISP2) have exchanged trust anchors, thus establishing trust between them. Establishment of trust is considered out‐of‐band for this architecture.

2. Organizations conduct due diligence by signing up with a reliable certificate authority, ensuring proper identity proofing and other safeguards before trusting any external organization.

3. HISP2 will have some mechanism to filter for only those domains that they want to receive messages from. Further guidelines are needed to establish how this will be accomplished.

4. Organization[s] has 'split' (internal + external) LDAP services already configured, is willing to expose their existing internal LDAP service, or is willing to setup an external LDAP service.

5. Organization[s] relies only on a single external LDAP service. 6. HISP2 is capable and willing to allow anonymous binding to their external LDAP service. 7. Organization[s] are capable/willing to secure their external LDAP service with Access Control

Layer (ACL) configuration so that the mail and userCertificate attributes of the inetOrgPerson schema objects for their Direct endpoint associated records are exposed.

8. Organization[s] may optionally further secure their external LDAP service with transport layer security (ldaps protocol: LDAP + SSL [TLS]).

9. Organization[s] may optionally further secure their external LDAP service with whitelist‐based binding filtering.


9

8. Certificate Discovery – Detailed Workflow

The figure below (Fig 2) shows a detailed workflow for a typical DNS‐LDAP based certificate discovery process.

Fig 2: Certificate Discovery Workflow: DNS‐LDAP Hybrid Model


10

8.1 Steps for Certificate Discovery for DIRECT Project Using DNS LDAP Workflow

Start: [email protected] sends an email message to [email protected].

1. Any available local caches are first examined for the presence of Provider 2's certificate. These may potentially range from a simple caching DNS server to more elaborate large scale and certificate‐specific solutions. 1.1. If the certificate can be locally resolved, certificate discovery is halted. 1.2. If the certificate is unavailable within HISP1, a DNS query (RFC 1035, sec. 4) for a CERT Resource

Record (RR) (RFC 4398) associated with Provider 2's Direct address is dispatched (RFC 1034, sec. 3.7). a) Initially, the query will be handled by the Top Level Domain (TLD) associated with the Health

Domain Name (as defined by the Applicability Statement for Secure Health Transport) portion of the direct address.

b) Until an authoritative answer (RFC 1034, sec. 4.3) for Provider 2's Direct address is found, any authorities garnered from responses are recursively followed until exhausted.

2. If an authoritative nameserver for the Health Domain Name is not found, no further steps can be taken.

3. Otherwise, the nameserver responds to the initial query with any CERT RR whose Fully Qualified Domain Name (FQDN) matches the Direct address. 3.1. If a CERT RR for Provider 2 has been retrieved, certificate discovery has finished and the

contents of the record are used for further validation before being utilized for message encryption and digital signing.

3.2. If no certificate exists in DNS for Provider 2, another DNS query is dispatched for a CERT RR, but now general to the entire organization (HISP2), in the form of the Health Domain Name itself.

4. Once/if the query is routed successfully through the DNS hierarchy, the endpoint, authoritative nameserver responds with the associated CERT RR, if available.

5. The response answer is examined for the presence of a CERT RR. 5.1. If a RR was returned for the organization, its contents is used for further processing and no

further discovery steps are taken. 5.2. Otherwise, a DNS query is dispatched for the location of [a] LDAP service[s] at HISP‐2, capable of

communicating over TCP, via a SRV RR with the FQDN '_ldap._tcp.<Health Domain Name>'. 6. Following routing, the HISP2 nameserver responds with all SRV RR's matching the given FQDN. 7. If any LDAP service locations are returned, one is chosen by the lowest priority then weight (in case

of matching priorities) attributes. 7.1. If no LDAP service locations are available, certificate discovery cannot proceed further and the

HISP's may need to use an out‐of‐band method of certificate exchange. 7.2. Otherwise, an LDAP query for an inetOrgPerson object whose mail attribute matches Provider

2's Direct address is dispatched.

8. The LDAP service responds, if it exists, with a matching inetOrgPerson object, if available.

9. If an inetOrgPerson object has been returned, its userCertificate attribute is extracted and its contents are used.


11

9. Advantages

DNS 1) DNS is a lightweight and fast protocol. 2) Does not differentiate between organization or individual level certificates. 3) If the system has to deal with just org level certificates, it’s a highly scalable and low

maintenance option. 4) DNS caches certificate entries leading to better lookup performance.

LDAP 5) Optimized for search and read operations. 6) Does not differentiate between organization or individual level certificates. 7) Provides a scalable option for storing certificates.

10. Risks DNS 1) DNS by default is public. That makes it vulnerable to threats such as spoofing. 2) Certificate entries must be manually added to a DNS server’s zone file. These are large text

based records. This could present a sustainability concern for large HISPs that deal with hundreds of other providers/HIEs/HISPs.

Note: A detailed risk assessment and mitigation plan is documented on the Thread Model wiki page at http://wiki.directproject.org/Threat+Model+‐+SMTP+with+Full+Service+HISPs

LDAP 1) Exposing an internal LDAP service with anonymous binding without further security measures

means that anyone can retrieve any attribute from any object stored by the service. 2) Without a whitelist in place, an external LDAP service can be attacked via a Distributed Denial of

Service attack. If the service is also used internally, this would create a disruption of a potentially critical piece of organization infrastructure due to LDAP's common use as an organization authentication service.

3) A split LDAP setup requires that an organization actively synchronize the information between both services/environments.

4) All of the inetOrgPerson objects stored in LDAP must be actively synchronized with the canonical email address in use by that individual/group. Any changes on the mail server (account aliases, name changes) must immediately be reflected in the LDAP directory.


12

11. Recommendations

1. Organizations should secure their external LDAP service with Access Control Layer (ACL) configuration to avoid exposing the mail and userCertificate attributes of the inetOrgPerson schema objects for their Direct endpoint associated records.

2. Organizations may optionally further secure their external LDAP service with transport layer security (ldaps protocol: LDAP + SSL [TLS]).

3. Organizations may optionally further secure their external LDAP service with whitelist‐based binding filtering. Guidelines for implementing whitelists need to be discussed further.

4. Normally DNS queries are executed as UDP which has a limitation on the size of the response. The certificate responses for this usage could be over the implemented UDP size limit. In the event that the response is over the limit then one must repeat query using TCP or configure the DNS query to explicitly use TCP.


13

12. Glossary

Term Definition

LDAP LDAP (Lightweight Directory Access Protocol) is a software protocol for enabling anyone to locate organizations, individuals, and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet.

DNS DNS (Domain Name System) A system for converting hostnames and domain names into IP addresses on the Internet or on local networks that use the TCP/IP protocol.

Certificate A public key certificate is a digitally signed document that serves to validate the sender's authorization and name. The document consists of a specially formatted block of data that contains the name of the certificate holder (which may be either a user or a system name) and the holder's public key, as well as the digital signature of a certification authority for authentication.

HISP Health Information Service Provider. An actor that serves the backbone exchange needs of Source and Destination actors. In the current state of this Abstract Model, an HISP should be thought of in the context of message delivery/receipt and not in the context of governance responsibilities.

Direct Address A Direct‐prescribed address identifying both the domain and endpoint within the domain as defined by the Direct Addressing specification.

TCP TCP (Transmission Control Protocol) is a set of rules (protocol) used along with the Internet Protocol (IP) to send data in the form of message units between computers over the Internet.

UDP UDP (User Datagram Protocol) is a communications protocol that offers a limited amount of service when messages are exchanged between computers in a network that uses the Internet Protocol (IP). UDP is an alternative to the Transmission Control Protocol (TCP).

Direct Certificate Discovery Technical Architecture

Documents

Transcript of Direct Certificate Discovery Technical Architecture