XMPP Concrete Implementation Updates:

1. XMPP Concrete Implementation Updates:

2. Why XMPP • 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. 2

3. HITSC Comments XMPP IMAP SASL Framework PLAIN DIGEST External …. …. • 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) • http://xmpp.org/extensions/xep-0178.html • http://tools.ietf.org/html/draft-meyer-xmpp-sasl-cert-management-01 • XMPP SASL mechanism support for X509 certificates • SASL External provides support for X509 certificates for authentication.

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

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

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

7. Prototype Instantiation and Configuration 7

8. Security Model of the XMPP Implementation 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) 8

9. Security Model of the XMPP Implementation Cont’d 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. 9

10. HIE Interoperability 10

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