XMPP Boundary and Cross-Domain Protection

Why Boundary and Cross Domain Checks?

Many uses of XMPP based Instant Messaging and Presence have minimal requirements on checking of XMPP traffic. However these systems are increasingly being deployed in environments where checks are essential. This can include checks on traffic to and from government organizations, and checks on traffic between military partners (e.g., between two NATO countries participating in a combined operation) as well as boundary checking for commercial organizations. Checks that may need to be made include:

• That certain information does not leave an organization.
• That viruses and other malicious content do not enter an organization.
• That security labels on information are present and in line with policy for communication across organizational boundaries.

Server Checks

Checks at the boundary are complementary to checks at the server. The Isode white paper [Using Security Labels to Control Message Flow in XMPP Services] looks at Security labels, and the benefits of checking in both places. It is clear that checking in both locations will usually be desirable. By checking at the server, some checks can be made earlier, and thus give a better and faster service to the user by handling checking failures locally. There are also checks that cannot be handled at the boundary. In particular:

• Checks on messages between local users.
• Checks on MUC (Multi User Chat) groups or PubSub (Publish/Subscribe nodes), that may contain local and external members.
• Checks that messages conform to the policy of the server.

Isode’s M-Link products provide comprehensive checking at the server level. In this whitepaper the term “M-Link” is used to refer to all of Isode’s XMPP server products in the M-Link family, unless otherwise stated.

Peering Controls plus Firewall

The simplest way to apply boundary controls is by use of peering controls. The diagram above shows how this is done in Isode’s M-Link server products. The server is operating within an organization and communicating with an external server using the XMPP S2S (server to server) protocol through a (network) firewall.

The boundary checks (for both inbound and outbound traffic) are handled by the peering controls in the M-Link server. These provide:

• Control as to who can be peered with (either an explicit grant list, or any peer with an explicit deny list).
• Control over the level of authentication required for each peer (e.g., Strong Authentication).
• Application of content controls associated with the peer (described later).
• Application of access control based on a Security Label with the message and a Security Clearance associated with the peer.

Cluster Copy in the DMZ

A more complex approach can be used when an organization operates a two level network firewall with a DMZ (De-Militarized Zone) in the middle. This approach is often used to support external access. External services are allowed to access servers running in the DMZ, but do not get direct access to servers running in the core.

In this architecture, an M-Link cluster is operated in the DMZ. A common and important reason to do this is to enable clients belonging to the organization (e.g.., mobile) that are outside the organization to connect. This can also be used with peering controls as in the single firewall approach. The key benefit of this approach is that it moves the controls outside of the core organization and into the DMZ.

Application Level Checking

The approaches described so far have all relied on checks within an XMPP server being applied at the boundary. The rest of this paper will look at checks that are applied by an XMPP Boundary Guard that is separate from the XMPP servers, as shown above.

Although this approach adds complexity, it gives two key benefits:

1. It makes the boundary controls completely independent of the XMPP service. This is often highly desirable for security reasons.
2. It can support multiple independent XMPP servers within the organization, and not require each to configure peering controls.

A number of configurations are possible, and the choice will depend on overall security requirements.

Using XMPP Servers with Application Level Checks

When an XMPP boundary guard is used, an XMPP server talks XMPP S2S to the guard in exactly the same way that it would talk to the server. This is not transparent to the XMPP server for two reasons:

1. Routing. The XMPP server will attempt to connect to the destination server, not the boundary guard.
2. The XMPP server will expect to authenticate the destination server.

This can be worked around (e.g., by using different DNS systems on both sides of the guard with appropriate configuration, and issuing special certificates to the guard so that it can pretend to be the destination server). This sort of configuration trick is not very satisfactory.

M-Link provides configuration options to make it easy to use with XMPP boundary guards, and to avoid the problems, namely:

• Specific destinations can be routed through configured boundary guards.
• All destinations apart from specifically configured ones can be routed through a configured boundary guard.
• Allowing for authentication of the guard instead of the final destination

All of this makes M-Link easy to deploy when an XMPP boundary guard is used, including environments where DNS is not used.

M-Link Edge

M-Link Edge can be configured in a number of ways to provide an XMPP Boundary Guard service. M-Link Edge provides a number of checking capabilities. These are implemented as modules with checking capability that is cleanly separated from the core server. These are:

• Presence Folding. XMPP user presence can contain a lot of information that may be sensitive. Presence folding reduces this information to a small number of states (e.g., online/offline) so that only very basic presence information is made available outside the organization.
• Security Label Checks. Access control is applied based on a Governing Security Policy, Security Label on the XMPP message, and Security Clearance associated with source and/or destination.
• Security Label Mapping. Security Labels are mapped to a Security Policy associated with the destination, using label equivalence mappings defined within the Security Policy. If XEP-0258 is used, the original label may be retained along with the new one, which is generally desirable.

Other functions that can be provided in conjunction with the checking:

• Auditing of XMPP traffic.
• Alert of policy violations.
• Restriction on use of select XMPP features/extensions (e.g., disable file transfers, VOIP)

M-Link Edge Deployment Modes

There are three possible deployment modes for M-Link Edge.

1. Standalone: In its simplest deployment mode, M-Link Edge can be deployed as a single process XMPP boundary guard. This basic deployment will be appropriate for simple configurations that can operate single process control.
2. 2. Back to Back: In this second configuration, two M-Link Edges are operated back to back. There would generally be a firewall between them, and each M-Link Edge server would be operated according to the policy on its side of the firewall. The key benefit of this separation is that you get independent and clearly decoupled control of the checks being applied on each side.
3. With a High Assurance Guard: The final configuration is to use a pair of M-Link Edges in conjunction with a High Assurance Guard, such as the QinetiQ SyBard family of products. The High Assurance Guard will typically be accredited to at least EAL4, and likely belong to a family of guards used for various checks. It is likely to provide a mix of general purpose and XMPP specific checks.

More information on deployment modes can be found on the product page for M-Link Edge.

Conclusions

This paper has shown various options for providing XMPP Cross Domain checking. M-Link products can provide this as an XMPP server, or can integrate with XMPP boundary guards. M-Link Edge can provide guard capabilities on its own, or in conjunction with a High Assurance Guard.