XMPP Concrete Implementation Updates: 1

Why XMPP 2 »XMPP protocol provides capabilities that allows realization of the NHIN Direct. Simple – Built on Internet and DNS, Many open source libraries to implement applications, user interfaces and integrate with existing systems and workflows. Direct – Realized using asynchronous message delivery, along with a publish-subscribe mechanism for specific events. Secure – Realized using TLS channel encryption, SASL authentication and authorization mechanisms, and extensive support for X509 based PKI infrastructure. Scalable – Realized using direct “Server Federation”, Clustering features of XMPP servers, A single XMPP server can support 1000’s of end points. »In addition, XMPP can serve as the “Innovation Platform” providing capabilities for HISP’s to innovate and create the next generation healthcare applications using: Presence features Direct Server to Server federation, no intermediaries thus reducing the probability of attack on the internet. Out of band File Transfer features Service Discovery and negotiation features Publish-Subscribe services Collaboration services Protocol binding support for HTTP/S, SOAP etc. Real time communication features.

HITSC Comments »XMPP SASL mechanism support for X509 certificates SASL External provides support for X509 certificates for authentication. »Details: TLS TCP connection is established between a client and server –As part of the negotiation client certificate is presented. After TLS is established, SASL verification process is started and “SASL External” mechanism is selected. –Server uses the certificate already presented in the TLS handshake to authenticate the client. »References: (SASL External with Certificates) SASL Framework XMPPIMAP External DIGEST PLAIN ….

Concrete Implementation Group Q & A »Presence and Implicit assumption of availability: 4 different Presence states –Away (Resource Temporarily not available) –Available (Resource available and interested in chatting) –Busy –Extended Away (Away for a long time) Clients can add text to each of these states to more accurately represent state like “In a Meeting”, “Do not Disturb” etc. »Out of Band File Transfer when user is offline Can be accomplished in multiple ways: –File Transfer can be accomplished by adding exception handling software to client software to store the file on the server for user to retrieve the file later. –Creating a “User Proxy” that is always online and mediates the file transfer based on the user status.

Concrete Implementation Group Q & A Cont’d »Certificate model for Interoperability between XMPP Servers The most secure way of communicating between the servers is to use TLS + SASL EXTERNAL –Certificates need to be rooted in same CA. –XMPP Standards Foundation runs an Intermediate CA (StartCom) to generate certificates for XMPP servers. –Servers can request certificates for their domain which can be exchanged during the TLS and SASL negotiations. Most XMPP Server to Server communication use “Server Dialback Authentication” (e.g Google Talk) –Weak Identity verification technique compared to SASL. –XMPP servers use DNS to verify a server generated key to verify the identity of the server.

Concrete Implementation Group Q & A Cont’d »Existing Client and Server Software: Open Source Servers –New Extension is needed to achieve interoperability with NHIN Exchange –New Extension is needed to provide HISP services to end points that are not associated with a HISP. Open Source Clients –Most of the existing clients don’t support “Signing and Encryption” of messages. –Most of the existing clients don’t support SASL External.

Prototype Instantiation and Configuration 7

Security Model of the XMPP Implementation 8 Channel Security: »The client to server communication (Source/Destination to HISP) is encrypted using TLS based on X509 server certificates. »The clients are authenticated to the server using SASL mechanisms. SASL PLAIN uses (user + pwd) SASL EXTERNAL supports client X509 certificates. »The Server to Server communication will be encrypted using TLS. »The Server to Server authentication/authorization is performed using SASL EXTERNAL mechanism. (X509 certificates)

Security Model of the XMPP Implementation Cont’d 9 Certificate Support: »Client Certificates are distinct from server certificates Client certificates can be at the individual level or at the organization level »Server Certificates are distinct from client certificates The most secure way of communicating between the servers is to use TLS + SASL EXTERNAL –Certificates need to be rooted in same CA. –XMPP Standards Foundation runs an Intermediate CA (StartCom) to generate certificates for XMPP servers. –Servers can request certificates for their domain which can be exchanged during the TLS and SASL negotiations. »Allows certificate chains and/or anchors for certificate validation. »Allows certificate revocation using OSCP and/or locally cached CRL’s. »Payload Signing and Encryption will be accomplished using NHIN-D JAgent.

HIE Interoperability 10

HIE Interoperability Cont’d 11 Scenario4: Interacting with existing EHR/EMR systems