ModularSpecificationsCertificateDiscoveryArchitecture

DIRECTCERTIFICATEDISCOVERY TECHNICALARCHITECTURE
OfficeoftheNationalCoordinatorforHealthInformationTechnology Version1.0

March29,2012

PreparedBy:ReferenceImplementationTeam

ModularSpecificationsCertificateDiscoveryArchitecture

TableofContents
1. 2. 3. 4. 5. 6. 7. Introduction..........................................................................................................................................4 Purpose.................................................................................................................................................4 Scope.....................................................................................................................................................4 Research&References.........................................................................................................................5 Goals......................................................................................................Error!Bookmarknotdefined. ConstraintsandAssumptions................................................................Error!Bookmarknotdefined. CertificateDiscoveryUsingDNSLDAPHybridApproach......................Error!Bookmarknotdefined. Scenario ........................................................................................................................................7 . HighLevelProcessWorkflow........................................................................................................8 Assumptions...................................................................................Error!Bookmarknotdefined.

7.1 7.2 7.3 8.

CertificateDiscoveryDetailedWorkflow...........................................................................................9

8.1 StepsforCertificateDiscoveryforDIRECTProjectUsingDNSLDAPWorkflow.Error!Bookmark notdefined. 9. Advantages ............................................................................................Error!Bookmarknotdefined. .

10. Risks.....................................................................................................Error!Bookmarknotdefined.1 11. Recommendations...............................................................................Error!Bookmarknotdefined.2 12. Glossary................................................................................................Error!Bookmarknotdefined.2 2

ModularSpecificationsCertificateDiscoveryArchitecture

DocumentChangeHistory
Version 1.0 Date 3/29/12 ChangedBy RITeam Changes

ModularSpecificationsCertificateDiscoveryArchitecture

1. Introduction
This document provides a highlevel technical architectural perspective of the Certificate Discovery process using Direct as developed by the Office of the National Coordinator for Health Information Technology(ONC)aspartoftheDirectProject. The Certificate Discovery architecture defines the components, technologies and their workflow to enablecertificatediscoveryusingtheDirectReferenceImplementation.

2. Purpose
The purpose of the Certificate Discovery Technical Architecture described by this architecture is to promotemodularization,andtoprovideconsistencyinapplyingtechnologytothesolutiondesigns.ONC has applied a modular architectural approach to the analysis of specifications in order to achieve interoperabilityamongevolvingpartsoftheStandardsandInteroperability(S&I)Framework.

3. Scope
Thescopeofthisarchitectureislimitedtoexploringthefollowingscenarios: 1. CertificateDiscoveryusingDNSandLDAP(HybridApproach). 2. Certificate Discovery using DNS (RFC 4398). If an LDAP server is unavailable, this scenario gets coveredunderthehybridapproach. ThearchitecturemodelfocusesonthetechnicalaspectsofCertificateDiscoveryaspartofabasicDirect Project conversation between two email clients, each using a "full service" HISP that provides mail serverfunctionality,serversidesecurityagentprocessingandDNSservices. 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 architecturetomodeltoonlyonerecipientfornow. Other configurations are possible; however they may be out of current project scope or may need a separateanalysis.

ModularSpecificationsCertificateDiscoveryArchitecture

4. Research&References
Thescopeofthisarchitectureislimitedtoexploringtwokeyapproachestodiscoveringcertificates 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 scopeofthisdocument. Someoftheartifactsconsultedare: 1. ApplicabilityStatementforSecureHealthTransportdocumentat http://wiki.directproject.org/file/view/20110428%20PDF%20 %20Applicability%20Statement%20for%20Secure%20Health%20Transport_FINAL.pdf 2. CertificatePilotRecommendationDiscussionat http://wiki.directproject.org/Certificate+Pilot+Recommendations+Discussion 3. ThreatModelforSMTPwithfullserviceHISPat http://wiki.directproject.org/Threat+Model++SMTP+with+Full+Service+HISPs 4. DirectCertificateDiscoveryRTM,preparedbytheModularSpecificationTeam 5. DirectTrustCommunityWikiwww.DirectTrust.wikispaces.com

ModularSpecificationsCertificateDiscoveryArchitecture

5. Goals
ThegoalsoftheCertificateDiscoveryarchitectureareto: ProvideasimpledesignforCertificateDiscoverybasedonexistingDirectRIcomponentsto promoteinteroperabilityandsecureexchangebetweenDirectparticipants. Modelthecertificatediscoverymechanismandprovidetechnicalandrisk/benefitanalysis. Addressgapsinexistingspecifications/requirementswithrecommendations.
Address privacy and security concerns.

6. ConstraintsandAssumptions
1. The Direct Project allows secure communication of health data between health care participants whoalreadyknowandtrusteachotherandthusareboundbyasetofsimplifyingassumptions.The Direct Project assumes that the sender is responsible for enforcement of minimal requirements beforesendingdata,includingthecollectionofpatientconsent,whereappropriate. 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 informationaccordingtolawandpolicy. 3. The sender of a Direct message has determined, through outofband means, that it is legally appropriatetosendtheinformationtotheReceiver.TheSenderhasdeterminedthattheReceivers addressiscorrect. 4. AllnormalDirectProjectConsensusProposalAssumptionsareinplay. 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 mentionedhere. 6. The Modular Specifications Phase 3 specifications include a number of ambiguous statements/requirementsthatneedfurtherclarity.

ModularSpecificationsCertificateDiscoveryArchitecture

7. CertificateDiscoveryUsingDNSLDAPHybridApproach

Figure1:CertificatediscoveryusingDNSLDAPhybridarchitecture

7.1Scenario
provider1@hisp1.comwishestosendasecureDIRECTmessage/emailtoprovider2@hisp2.com. Figure1modelsabasicDirectProjectconversationbetweentwoemailclients,eachusinga"fullservice" HISPthatprovidesmailserverfunctionality,DirectprocessingandDNSservices. Additionally,HISP2hasanLDAPserverwhereitstorescertificates. Inorderforasecuremessageexchangetooccur,HISP1mustretrievethedigitalcertificateof provider2@HISP2.comusingaDNSand/orLDAPquery. DirectatHISP1useslocalandpublicDNShierarchytoqueryforcertificatesforprovideratHISP2.Ifit cannotretrieveacertificateusingDNS,itwilllookforanLDAPserverandqueryitforcertificates.The useofLDAPserverisoptional,howevermanyorganizationsmaydeployLDAP.Onceacertificateis obtained,itsreturnedtoHISP1.Ifnocertificateisfound,HISPswillneedtoexchangecertificatesusing someoutofbandapproachwhichisbeyondthescopeofthisarchitecture. TheDNSresolversdefaulttosearchingforuserlevelcertificatesbeforelookingfororglevelcertificates. TheDNSlookupquerywillhavetheemailaddressoftherecipient:provider2@hisp2.comforour exampleandtheresponsewillcontaineitherthecertificateforprovider2oranorglevelcertificatefor hisp2butnotboth(ifDNShasentriesforbothuserlevelandorglevelcertificates).ThesendingHISPwill usethecertificatetosecureallcommunicationwiththereceivingHISP. HISP1encryptstheemailmessageusingthecertificateobtainedfromHISP2(publickey)andsendsthe messagetotherecipient.

ModularSpecificationsCertificateDiscoveryArchitecture

7.2HighLevelProcessWorkflow
1a)DNSQueries I. QueryforanIndividualCertificate.Ifacertificateisfound,usethatforsecuremessage exchangewithHISP2. II. IfanIndividualCertificateisnotfound,then: QueryforanOrganizationalCertificate.Ifacertificateisfound,usethatforsecure messageexchangewithHISP2. III. IfanOrganizationalCertificateisnotfound,then: QueryforlocationofLDAPserverhostedonHISP2. 1b)LDAPQuery(ifnocertificateisfoundinstep1a) IfanLDAPserverisfound,then: DirectatHISP1queriesLDAPserveronHISP2foracertificate.Iffound,useforsecuring message. 2)Ifacertificateisfound,thecertificateisreturnedtoDirectatHISP1. 3)DirectatHISP1usesthecertificatetoencryptandsendsecuremessagetoprovideratHISP2.

7.3Assumptions
1. Sender(HISP1)andreceiver(HISP2)haveexchangedtrustanchors,thusestablishingtrust betweenthem.Establishmentoftrustisconsideredoutofbandforthisarchitecture. 2. Organizationsconductduediligencebysigningupwithareliablecertificateauthority,ensuring properidentityproofingandothersafeguardsbeforetrustinganyexternalorganization. 3. HISP2willhavesomemechanismtofilterforonlythosedomainsthattheywanttoreceive messagesfrom.Furtherguidelinesareneededtoestablishhowthiswillbeaccomplished. 4. Organization[s] has 'split' (internal + external) LDAP services already configured, is willing to exposetheirexistinginternalLDAPservice,oriswillingtosetupanexternalLDAPservice. 5. Organization[s]reliesonlyonasingleexternalLDAPservice. 6. HISP2iscapableandwillingtoallowanonymousbindingtotheirexternalLDAPservice. 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 schemaobjectsfortheirDirectendpointassociatedrecordsareexposed. 8. Organization[s] may optionally further secure their external LDAP service with transport layer security(ldapsprotocol:LDAP+SSL[TLS]). 9. Organization[s] may optionally further secure their external LDAP service with whitelist basedbindingfiltering. 8

ModularSpecificationsCertificateDiscoveryArchitecture

8. CertificateDiscoveryDetailedWorkflow
Thefigurebelow(Fig2)showsadetailedworkflowforatypicalDNSLDAPbasedcertificatediscovery process.

Fig2:CertificateDiscoveryWorkflow:DNSLDAPHybridModel

ModularSpecificationsCertificateDiscoveryArchitecture

8.1

StepsforCertificateDiscoveryforDIRECTProjectUsingDNSLDAP Workflow

Start: provider1@hisp1.comsendsanemailmessagetoprovider2@hisp2.com. 1. AnyavailablelocalcachesarefirstexaminedforthepresenceofProvider2'scertificate.Thesemay potentiallyrangefromasimplecachingDNSservertomoreelaboratelargescaleandcertificate specificsolutions. 1.1. Ifthecertificatecanbelocallyresolved,certificatediscoveryishalted. 1.2. IfthecertificateisunavailablewithinHISP1,aDNSquery(RFC1035,sec.4)foraCERTResource Record(RR)(RFC4398)associatedwithProvider2'sDirectaddressisdispatched(RFC1034,sec. 3.7). a) Initially,thequerywillbehandledbytheTopLevelDomain(TLD)associatedwiththeHealth DomainName(asdefinedbytheApplicabilityStatementforSecureHealthTransport)portion ofthedirectaddress. b) Untilanauthoritativeanswer(RFC1034,sec.4.3)forProvider2'sDirectaddressisfound,any authoritiesgarneredfromresponsesarerecursivelyfolloweduntilexhausted. 2. IfanauthoritativenameserverfortheHealthDomainNameisnotfound,nofurtherstepscanbe taken. 3. Otherwise,thenameserverrespondstotheinitialquerywithanyCERTRRwhoseFullyQualified DomainName(FQDN)matchestheDirectaddress. 3.1. IfaCERTRRforProvider2hasbeenretrieved,certificatediscoveryhasfinishedandthe contentsoftherecordareusedforfurthervalidationbeforebeingutilizedformessageencryption anddigitalsigning. 3.2. IfnocertificateexistsinDNSforProvider2,anotherDNSqueryisdispatchedforaCERTRR,but nowgeneraltotheentireorganization(HISP2),intheformoftheHealthDomainNameitself. 4. Once/ifthequeryisroutedsuccessfullythroughtheDNShierarchy,theendpoint,authoritative nameserverrespondswiththeassociatedCERTRR,ifavailable. 5. TheresponseanswerisexaminedforthepresenceofaCERTRR. 5.1. IfaRRwasreturnedfortheorganization,itscontentsisusedforfurtherprocessingandno furtherdiscoverystepsaretaken. 5.2. Otherwise,aDNSqueryisdispatchedforthelocationof[a]LDAPservice[s]atHISP2,capableof communicatingoverTCP,viaaSRVRRwiththeFQDN'_ldap._tcp.<HealthDomainName>'. 6. Followingrouting,theHISP2nameserverrespondswithallSRVRR'smatchingthegivenFQDN. 7. IfanyLDAPservicelocationsarereturned,oneischosenbythelowestprioritythenweight(incase ofmatchingpriorities)attributes. 7.1. IfnoLDAPservicelocationsareavailable,certificatediscoverycannotproceedfurtherandthe HISP'smayneedtouseanoutofbandmethodofcertificateexchange. 7.2. Otherwise,anLDAPqueryforaninetOrgPersonobjectwhosemailattributematchesProvider 2'sDirectaddressisdispatched. 8. TheLDAPserviceresponds,ifitexists,withamatchinginetOrgPersonobject,ifavailable. 9. IfaninetOrgPersonobjecthasbeenreturned,itsuserCertificateattributeisextractedandits contentsareused.

10

ModularSpecificationsCertificateDiscoveryArchitecture

9. Advantages
DNS 1) DNSisalightweightandfastprotocol. 2) Doesnotdifferentiatebetweenorganizationorindividuallevelcertificates. 3) Ifthesystemhastodealwithjustorglevelcertificates,itsahighlyscalableandlow maintenanceoption. 4) DNScachescertificateentriesleadingtobetterlookupperformance. LDAP 5) Optimizedforsearchandreadoperations. 6) Doesnotdifferentiatebetweenorganizationorindividuallevelcertificates. 7) Providesascalableoptionforstoringcertificates.

10.

Risks

DNS 1) DNSbydefaultispublic.Thatmakesitvulnerabletothreatssuchasspoofing. 2) CertificateentriesmustbemanuallyaddedtoaDNSserverszonefile.Thesearelargetext basedrecords.ThiscouldpresentasustainabilityconcernforlargeHISPsthatdealwith hundredsofotherproviders/HIEs/HISPs. Note:AdetailedriskassessmentandmitigationplanisdocumentedontheThreadModelwikipage athttp://wiki.directproject.org/Threat+Model++SMTP+with+Full+Service+HISPs LDAP 1) Exposing an internal LDAP service with anonymous binding without further security measures meansthatanyonecanretrieveanyattributefromanyobjectstoredbytheservice. 2) Withoutawhitelistinplace,anexternalLDAPservicecanbeattackedviaaDistributedDenialof Serviceattack.Iftheserviceisalsousedinternally,thiswouldcreateadisruptionofapotentially critical piece of organization infrastructure due to LDAP's common use as an organization authenticationservice. 3) AsplitLDAPsetuprequiresthatanorganizationactivelysynchronizetheinformationbetween bothservices/environments. 4) AlloftheinetOrgPersonobjectsstoredinLDAPmustbeactivelysynchronizedwiththecanonical emailaddressinusebythatindividual/group.Anychangesonthemailserver(accountaliases, namechanges)mustimmediatelybereflectedintheLDAPdirectory.

11

ModularSpecificationsCertificateDiscoveryArchitecture

11.
1.

Recommendations

Organizations should secure their external LDAP service with Access Control Layer (ACL) configurationtoavoidexposingthemailanduserCertificateattributesoftheinetOrgPersonschema objectsfortheirDirectendpointassociatedrecords. 2. OrganizationsmayoptionallyfurthersecuretheirexternalLDAPservicewithtransportlayersecurity (ldapsprotocol:LDAP+SSL[TLS]). 3. Organizations may optionally further secure their external LDAP service with whitelist basedbindingfiltering.Guidelinesforimplementingwhitelistsneedtobediscussedfurther. 4. NormallyDNSqueriesareexecutedasUDPwhichhasalimitationonthesizeoftheresponse.The certificateresponsesforthisusagecouldbeovertheimplementedUDPsizelimit.Intheeventthat theresponseisoverthelimitthenonemustrepeatqueryusingTCPorconfiguretheDNSqueryto explicitlyuseTCP.

12

ModularSpecificationsCertificateDiscoveryArchitecture

12.
Term LDAP

Glossary
Definition LDAP(LightweightDirectoryAccessProtocol)isasoftwareprotocolforenabling anyonetolocateorganizations,individuals,andotherresourcessuchasfilesand devicesinanetwork,whetheronthepublicInternetoronacorporateintranet. DNS(DomainNameSystem)Asystemforconvertinghostnamesanddomainnames intoIPaddressesontheInternetoronlocalnetworksthatusetheTCP/IPprotocol. Apublickeycertificateisadigitallysigneddocumentthatservestovalidatethe sender'sauthorizationandname.Thedocumentconsistsofaspeciallyformatted blockofdatathatcontainsthenameofthecertificateholder(whichmaybeeithera userorasystemname)andtheholder'spublickey,aswellasthedigitalsignatureof acertificationauthorityforauthentication. HealthInformationServiceProvider.Anactorthatservesthebackboneexchange needsofSourceandDestinationactors.InthecurrentstateofthisAbstractModel, anHISPshouldbethoughtofinthecontextofmessagedelivery/receiptandnotin thecontextofgovernanceresponsibilities. ADirectprescribedaddressidentifyingboththedomainandendpointwithinthe domainasdefinedbytheDirectAddressingspecification. TCP(TransmissionControlProtocol)isasetofrules(protocol)usedalongwiththe InternetProtocol(IP)tosenddataintheformofmessageunitsbetweencomputers overtheInternet. UDP(UserDatagramProtocol)isacommunicationsprotocolthatoffersalimited amountofservicewhenmessagesareexchangedbetweencomputersinanetwork thatusestheInternetProtocol(IP).UDPisanalternativetotheTransmissionControl Protocol(TCP).

DNS Certificate

HISP

DirectAddress TCP

UDP

13