M-Link Security

On this page you'll find information on M-Link's security features.

On other pages you'll find a general overview of Isode's M-Link XMPP Server, M-Link's use of Directory, support for wide and local area clustering, boundary controls using M-Link Edge, management tools and standards conformance.

Security Labels

M-Link provides control of messages using Security Labels. This controls the flow of messages, based on security labels associated with the messages and the security clearance of the user. Isode supports security labels according to XEP-0258 (Security Labels in XMPP) with support for S/MIME ESS Labels (RFC 2634 - Enhanced Security Services for S/MIME) and for Isode XML Labels. Controls are based on Security Clearance of Sender, Recipient, and peer XMPP server. Security Label based controls are also provided for Multi User Chat (MUC).


A security labelled multi-user chat showing two different views from participants with differing security clearances (click images for more detail)

M-Link provides Client/Server support for XEP-0258 and in particular for the discovery mechanism that enables an XMPP client to determine which Security Labels can be used for a specific destination.

Overall control is Security Policy based, using the mechanisms described in our whitepaper [Isode Security Policy, Security Label and Security Clearance Infrastructure].

As well as support for XEP-0258, M-Link supports the IC-ISM XML label mechanism used by the Transverse client. Futher information is given in the Isode whitepaper, [Using Security Labels to Control Message Flow in XMPP Services].

Mixed Environments: Interworking with Clients/Servers that do not support Security Labels

To support deployments in mixed environments, where some servers and clients do not support security labels, M-Link supports:

Default Labels: these can be configured for servers, peers, MUC rooms or services (i.e. applied to one domain within a single server supporitng multiple IM domains).
FLOT (First Line of Text) labels: this allows for the insertion of a label at the start of any XMPP message, using the text from the XEP-0258 display marking. This ensures that clients not capable of XEP-0258 support will see security labels. See below.

Authentication

XMPP Client/Server authentication uses SASL, enabling a number of authnetication mechanisms. The basic mechanisms provided are password based. Kerberos authentication is also provided, see the Isode whitepaper [Isode Support for Kerberos, Active directory and Single Sign On].

Strong Authentication, based on X.509 Public Key Infrastructure (PKI), is supported for client/server and for server/server connections. This is preferable to the default server dialback mechanism. Strong authentcation uses SASL EXTERNAL authentication which in turn uses X.509 authentication at the TLS level. XMPP clients and servers use certificates with special Subject Alternate Names (defined in RFC 5290). M-Link supports the use of these certificates, and Isode's secure Identity Management capability in Sodium helps to generate them. Strong Authentication is recommended for secure deployments.

Data confidentiality can be provided either by TLS or by SASL/Kerberos.

Peering Controls

M-Link's peering controls allow for boundary checks on both inbound and outbound server to server XMPP traffic. These include:

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 access controls based on a Security Label with the message and a Security Clearance associated with the peer.
Transformation of security labels, including FLOT label mappings.
Presence Folding, which enables presence information to be filtered to reduce the information shared,
Message Folding, which enables fields in XMPP messages to be filtered to reduce the information shared,
Prevention of certain types of messages, such as MUC or Chat State Notifications.

Use of peering controls is described more fully in the Isode whitepaper [XMPP Boundary and Cross Domain Protection].

M-Link Edge

Whilst peering controls are the simplest way to apply boundary controls, use of an XMPP Boundary Guard enables controls to be applied and checks made separate to the XMPP server(s), giving two key benefits:

Boundary controls are completely independent of the XMPP service
As a boundary guard can support multiple XMPP servers within the organisation, there is no need to configure peering controls for each server.

M-Link Edge, based on M-Link, can be configured in a number of different ways to provide an XMPP boundary service. For more information, please see the M-Link Edge product page.

Isode Products