You are on page 1of 13

Modular Specifications – Certificate Discovery Architecture 

 

  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   

1

Modular Specifications – Certificate Discovery Architecture 

 

Table of Contents 
1.  2.  3.  4.  5.  6.  7.  Introduction .......................................................................................................................................... 4  Purpose ................................................................................................................................................. 4  Scope ..................................................................................................................................................... 4  Research & References ......................................................................................................................... 5  Goals ...................................................................................................... Error! Bookmark not defined.  Constraints and Assumptions ................................................................ Error! Bookmark not defined.  Certificate Discovery Using DNS‐LDAP Hybrid Approach ...................... Error! Bookmark not defined.  Scenario  ........................................................................................................................................ 7  . High Level Process Workflow ........................................................................................................ 8  Assumptions ................................................................................... Error! Bookmark not defined. 

7.1  7.2  7.3  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                  2

Modular Specifications – Certificate Discovery Architecture 

   

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

3

Modular Specifications – Certificate Discovery Architecture 

 

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.           

4

Modular Specifications – Certificate Discovery Architecture 

 

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   

 

5

Modular Specifications – Certificate Discovery Architecture 

 

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.  

 
     

6

Modular Specifications – Certificate Discovery Architecture 

 

7. Certificate Discovery Using DNS­LDAP Hybrid Approach 
 

      Figure 1:  Certificate discovery using DNS‐LDAP hybrid architecture 

  7.1  Scenario 
  provider1@hisp1.com wishes to send a secure DIRECT message/email to provider2@hisp2.com.    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  provider2@HISP2.com 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: provider2@hisp2.com 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.   

7

Modular Specifications – Certificate Discovery Architecture 

 

  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.      8

Modular Specifications – Certificate Discovery Architecture 

     

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 

 
 

 

9

Modular Specifications – Certificate Discovery Architecture 

 

8.1 
 

Steps for Certificate Discovery for DIRECT Project Using DNS LDAP             Workflow 

Start:  provider1@hisp1.com sends an email message to provider2@hisp2.com.     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. 

10

Modular Specifications – Certificate Discovery Architecture 

 

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.     

11

Modular Specifications – Certificate Discovery Architecture 

 

11.
1.

Recommendations 

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.     

12

Modular Specifications – Certificate Discovery Architecture 

   

12.
  Term  LDAP 

Glossary 
Definition  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 (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.  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.  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.  A Direct‐prescribed address identifying both the domain and endpoint within the  domain as defined by the Direct Addressing specification.  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 (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). 

DNS  Certificate 

HISP 

Direct Address  TCP 

UDP 

   

13