On this page you'll find information on M-Link's security features. On other pages in this section, you’ll find information on M-Link’s use of Directory for configuration/authentication, support for wide and local area clustering, operation over constrained/unreliable networks, Federated/Multi-User Chat, Archive & Search, and support for Military Forms using FDP.

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

The two screenshots below security labelled multi-user chat showing two different views from participants with differing security clearances.

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. M-Link can configure a default (per server or per domain) catalog, and can also support personal catalogs stored in the directory, so that users can customize their own set of security labels.

Overall control is Security Policy based, using the mechanisms described in the product page covering Isode's Security Policy Infrastructure.

M-Link supports a number of features designed to provide interoperability, to the extent feasible, between the XEP 258 security label services and CDCIE Client Chat Protocol clients like TransVerse and JChat.

Further information is given in the Isode whitepaper, [Using Security Labels to Control Message Flow in XMPP Services].

Working with Clients/Servers with no Security Labels Support

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


XMPP Client/Server authentication uses SASL, enabling a number of authentication 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 authentication uses SASL EXTERNAL authentication which in turn uses X.509 authentication at the TLS level. Isode products, including M-Link, Swift, and Sodium CA, support XMPP-specific Subject Alternative Names as detailed in RFC 6120 as well as more commonly used Subject Alternative Names such those for DNS names and email addresses. Flexible mappings facilitate client use of smart cards. Strong Authentication includes directory based path discovery and CRL checking and is compliant to RFC 5280. Server private keys can be held securely in the M-Link server or in the Windows Certificate Store. Strong Authentication is recommended for secure deployments.

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

FIPS 140-2

FIPS 140-2 is a US Government specification relating to the use of cryptography in computer software. M-Link provides a FIPS 140-2 compliant mode of operation which ensures that only certified implementations of approved cryptographic algorithms are used.

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.
  • Constraint to MUC only or 1:1 chat only.
  • Prevention of in-band file transfer and negotiation of out of band file transfer.

Use of peering controls is described in two Isode whitepapers. [XMPP Boundary and Cross Domain Protection] looks at applying boundary controls using peering and [Peering Controls in M-Link and M-Link Edge] looks at peering controls in more detail. Whilst peering controls are the simplest way to apply boundary controls, use of an XMPP Boundary Guard (such as M-Link Edge), gives a number of advantages over this approach by enabling controls to be applied and checks made separate to the XMPP server.