Follow Join Read

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 and reliability, 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).


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 the product page covering Isode's Security Policy Infrastructure.

As well as support for XEP-0258, M-Link supports the IC-ISM XML label mechanism used by the Transverse client. Further 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 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.

Authentication

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. 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. 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 in PKCS#12 files or Windows Certificate Store. Strong Authentication is recommended for secure deployments.

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

FIPS 140-2

M-Link has FIPS 140-2 compliance. This US standard relates to use of cryptography. These changes give M-Link an option to ensure that cryptographic algorithms are used in an approved manner and that non-approved algorithms are not 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 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.