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)

• http://xmpp.org/extensions/xep-0178.html• http://tools.ietf.org/html/draft-meyer-xmpp-sasl-cert-management-01

SASL Framework

XMPP IMAP

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

XMPP Client A(Source/Destination)

XMPPServer1.com(Source HISP)

XMPPServer2.com(Destination HISP)

XMPP Client B(Destination)

Internet InternetInternet

Send and Receive Messages

Send and Receive Messages

Clients registered with XMPPServer2.com, which provides the NHIN Direct HISP services to its client B

Send and Receive Messages

Send and Receive Messages

Clients registered with XMPPServer1.com, which provides the NHIN Direct HISP services to its client A

DNS SystemsDNS SRV Lookup DNS SRV Lookup

DNS SystemsDNS Lookups

Server Application(HISP)

Open Fire XMPP Server

MySQLDB

OpenLDAPDirectory

LDAP

JDBC

Client Application

JavaApplication

Smack XMPP Client

Library

Eclipse + JDK Libraries

Security Model of the XMPP Implementation

8

XMPP Client A(Source/Destination)

XMPPServer1.com(Source HISP)

TLS Channel+

Signed payload +

Encrypted payload

SASL Authentication of client to Server

XMPPServer2.com(Destination HISP)

XMPP Client B(Destination)

SASL Authentication of client to Server

TLS Channel+

Signed payload +

Encrypted payload

TLS Channel+

Signed payload +

Encrypted payload

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

XMPP Client A(Source/Destination)

XMPPServer.com(Source/Destination

HISP)

XMPP Client B(Destination)Internet Internet

Send and Receive Messages using XMPP

DNS SystemsDNS SRV Lookup DNS SRV Lookup

Scenario1: Source and Destination belong to the same HIO

Send and Receive Messages using XMPP

XMPP Client A(Source/Destination)

XMPPServer1.com(Source HISP)

XMPPServer2.com(Destination HISP)

XMPP Client B(Destination)

Internet InternetInternet

DNS SystemsDNS SRV Lookup DNS SRV Lookup

DNS SystemsDNS Lookups

Scenario2: Source and Destination belong to different HIO’s but both HIO’s support NHIN Direct XMPP Implementation

Send and Receive Messages using XMPP

Send and Receive Messages using XMPP

Send and Receive Messages using XMPP

HIE Interoperability Cont’d

11

XMPPServer.com(HISP)

Regular NHIN Direct HISP Services

Source HIO Proxy Services

Destination HIO Proxy Services

NHIN Exchange Services

XMPP Client A(Source)

XMPP Client B(Destination)

Internet

Source Without a HIO

Destination Without a HIO

NHIN Exchange Gateways

Send and Receive Messages using XMPP

Send and Receive Messages

Send and Receive Messages

Send and Receive Messages using SOAP

Scenario3: HISP provides services for Source and Destination’s without HIO’s and services for Interaction with NHIN Exchange Gateways

Scenario4: Interacting with existing EHR/EMR systems