Isode has incorporated into the M-Link User Server, M-Link Edge, M-Link IRC Gateway and Constrained Network variations features that make them the natural choice for instant messaging and presence in military, intelligence and government deployments. These features include message security using security labels, support for data confidentiality using TLS and support for SASL authentication, Kerberos authentication and Strong Authentication (based on X.509 Public Key Infrastructure), for client/server and for server/server connections and boundary checks on message traffic using peering controls.
Messages can be given Security Labels. Security Labels are used to control whether an entity (such as a user or a MUC) may access a message. The entity's Security Clearance is used to determine whether it may see a message with a given Security Label.Isode supports security labels according to XEP-0258 (Security Labels in XMPP) with support for S/MIME ESS Labels (RFC 2157 - 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). In the screenshot below security labelled chat in a multi-user chat room is shown from the perspectives of two different users with differing security clearances (in this example Isode's Swift XMPP Client is used).
Client/Server support for XEP-0258 is provided, in particular for the discovery mechanism that enables an XMPP client to determine which Security Labels can be used for a specific destination. Default (per server or per domain) catalogs can be configured and personal catalogs, stored in the directory, are also supported 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 products support a number of features designed to provide interoperability, to the extent feasible, between the XEP-0258 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 Label Support
To support deployments in mixed environments, where some servers and clients do not support security labels, M-Link products support:
- 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.
XMPP Client/Server authentication uses SASL, enabling a number of authentication mechanisms. Password based mechanisms, which should always be used over TLS, are PLAIN and SCRAM (Salted Challenge Response Authentication Mechanism) with SCRAM being the recommended password based mechanism. For more on SCRAM see the Isode whitepaper [SCRAM: A protocol for Password Authentication].
Kerberos authentication is supported following XEP-0233 which includes support for clustered access and multi-domain. See the Isode whitepaper [Isode Support for Kerberos, Active directory and Single Sign On] for more information.
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 is a US Government specification relating to the use of cryptography in computer software. M-Link products provide a FIPS 140-2 compliant mode of operation which ensures that only certified implementations of approved cryptographic algorithms are used.
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.