Isode's XMPP Cross Domain Solution

Cross Domain and XMPP

Military networks are deployed as domains. There will typically be several national networks in a country, each operating at a specified security level. Then there will be networks deployed for specific missions. These networks (domains) are kept strictly separate at the network level. There is often a requirement to communicate between these networks, which is called Cross Domain. Cross Domain traffic must be strictly controlled.

XMPP is the eXtensible Messaging and Presence Protocol, which is widely used for military real time communication, sometimes referenced as the JCHAT service. More information on Military XMPP functions and Isode’s solution are given on Isode's Market Page for Military XMPP.

Deployment Architectures

XMPP has a client/server architecture, where XMPP Clients communicate with XMPP Servers using a Client to Server (C2S) protocol. XMPP Clients can use different servers that connect to each other using the XMPP Server to Server (S2S) protocol. This basic communication can be seen within each of the domains illustrated above.

The domains are connected by an “XMPP Cross Domain Service”, which communicates with servers in each domain using standard XMPP S2S protocol. This multi-hop architecture uses “XMPP Trunking” as described in the Isode whitepaper [Providing XMPP Trunking with M-Link Peer Controls].

In this deployment model, the XMPP Cross Domain Service is independent of the two domains. This deployment model is appropriate when both domains can trust a single provider, such as when connecting a national network to a national mission network.

The second architecture illustrated above is for scenarios where there is no common trusted provider, for example when connecting two national networks. Here each domain provides its own XMPP Cross Domain Service which is controlled by domain policy. This can connect using XMPP S2S protocol to the other domain.   

Solution Components

We can now consider how the Isode XMPP Cross Domain Solution is put together. The centre of the solution is M-Guard, which is an XML Guard. M-Guard provides the Security Enforcing Functionality (SEF) of the cross domain solution. M-Guard will sit at a network boundary, so that all XMPP traffic will go through M-Guard as no other connections are possible.

On each side of M-Guard is an M-Link Edge product which communicates with XMPP servers using the XMPP S2S protocol. M-Link Edge communicates with M-Guard using the GCXP (Guard Content eXchange Protocol), which is a secure open protocol for communicating with an XML Guard. M-Link Edge could use it communicate to an alternative XML Guard if desired.

The primary function of M-Link Edge is to communicate with external XMPP servers using the standard S2S protocol and to convey messages to and from M-Guard using GCXP. The functionality of the cross domain solution is controlled by an XMPP Application Profile for XML Guard. This is a generic product independent specification set out in the Isode white paper [XMPP Application Profile for XML Guard]. This defines system behaviour, specifying an outer envelope as XML Schema that defines the maximum that is allowed through. The intent is that this can support full behaviour of a modern XMPP Client, such as Isode's Swift, across the domain boundary. Then there are rules which can constrain this behaviour, which are described in more detail later.

The XMPP Application Profile for XML Guard is also an Isode product which is used by M-Guard to define and provide the Security Enforcing Functionality of the solution. M-Guard has primary responsibility to support the Application Profile
M-Link Edge also provides support for the XMPP Application Profile functions, to facilitate support of the Application Profile using an  implementation independent of M-Guard. The model is that M-Link Edge will usually send to M-Guard messages that conform to the application profile and associated rules. This means that M-Guard should only expect valid messages, and that any invalid messages are quite likely a significant breach. M-Link Edge facilitates this in three ways:

1. It can reject messages that do not follow policy. For example if there is a configured maximum message body size, M-Link Edge will provide an appropriate rejection back to the user.
2. It can drop messages that do not follow policy. For example if policy does not allow Chat State Notifications, which do things like inform that user is typing, M-Link Edge will simply drop the message.
3. It can transform messages to ensure that they follow policy. For example, if the policy is to not allow HTML, M-Link Edge will strip the HTML, leaving on the plain text version of the message.

So, the expectation is that in a correctly configured setup, M-Guard will usually only receive messages from M-Link Edge that conform to the Application Profile and associated rules that M-Guard is configured to enforce. This means that rejections will be rare and can be treated as severe, as they may indicate a significant problem.

Note that where it is anticipated that general use of the system will not trigger M-Guard rules, M-Link Edge will not try to enforce these rules. This approach avoids complexity in the M-Link Edge configuration that would add management complexity without adding value. M-Link Edge can be configured to relay M-Guard rejections back to the message sender.

Note that M-Link Edge 19.2 does not provide support for some of the more restrictive rules that M-Guard supports, so deployments will rely on M-Guard for enforcement. Support in M-Link Edge will be added in future releases.

Approaches to Controlling Information Flow

There are a number of reasons for putting in place an XMPP Cross Domain solution, which are discussed below. These reasons will influence the details of the rules chosen. A list of rules associated with the Application Profile is provided in [XMPP Application Profile for XML Guard]. This section notes some of these rules, to give an idea of the approach that might be taken.

Preventing Non-XMPP Activity

A very basic requirement is to ensure that only XMPP traffic goes across the boundary, and that there is no possibility that a different service gets through. With a firewall approach, you simply open up ports without any means for controlling what actually is sent over the open ports. An XML Guard can address this  simple goal by using the XMPP Application Profile without any rules selected, which ensures that no other traffic (e.g., streams of data) goes across the boundary.

Preventing Malware and Other Attacks

A more specific goal is to prevent malware traversing the boundary. With bulk protocols such as email, attachments containing formats such as PDF provide a number of attack avenues.   XMPP protocol is highly structured XML with small elements, which limits the approaches that can be used to attack across a boundary.

Limiting the side of message body, which is the central free form field allowed, will make use of this field to carry malware impractical. It may also make sense to limit length of other fields (subject; presence status; forms elements) if they are allowed. It will generally make sense to prevent use of the HTML alternative body.

Protocol based attacks are hard to envisage with XMPP, but using the profile to constrain the types of messages exchanged, as discussed in the next section, can limit the possibilities of such an attack.

Controlling Information Exchanged

XMPP can provide a rich user experience, which needs a significant amount of protocol to support. The baseline XMPP Application Profile aims to allow through everything that is needed to support a full user experience. Rules provided with the profile allow things to be turned off, which can bring things right down to a basic SMS type experience. It may be considered that information exchanged provides information that should not be exchanged cross domain. The choice comes down to policy for the deployment. Some examples of things that might be controlled:

• Prevention of presence status, so that you can send to a user, but not know any current status information about the user.
• Restricting which users or services are allowed to send and receive messages.
• Preventing message delivery reports.
• Prevention of notifications such as “User is typing”.
• Blocking specific words, to prevent sharing of particularly sensitive information.

Many of the controls are quite technical, and best understood by detailed review of the XMPP Application Profile.

Enforcing Security Labelling

In some target environments mandatory labelling of information is enforced. This means that for XMPP each message will have a security label. Where this is in place, it can be used to control information exchanged cross domain, ensuring that information is appropriate for sending across the boundary, for example containing the correct information controlling release.

Secure Management

The components of the solution need to be securely managed, the diagram above shows how this is achieved. Notes:

• M-Link Edge has Web management on a secure network, separated from the XMPP domain by a firewall. This ensures that the M-Link Edge server can only be managed from within a secure network.
• XMPP Servers connect to M-Link Edge through a firewall that only allows this limited access to the boundary service.
• M-Link Edge connects on the same network using GCXP to M-Guard.
• M-Guard is configured by M-Guard Console. This will typically be connected directly to a dedicated management network interface of M-Guard using a non-networked computer. This computer will typically only be connected when configuration changes are needed and will otherwise be securely stored.
• Monitoring of M-Guard is achieved using the secure RELP protocol or by Syslog when RELP is not supported. On larger systems this will typically be done using a special management network with a dedicated interface to M-Guard. On smaller systems, this monitoring may be done on “high side” of the M-Guard.

Product Availability

Isode’s Cross Domain XMPP solution comprises three components:

• M-Guard
• XMPP Application Profile
• M-Link Edge

Summary

This paper has described Isode’s cross domain XMPP Solution, comprising M-Guard, M-Link and an XMPP Application Profile for XML Guard.   It has shown how this can address a range of cross domain XMPP requirements.