Over the last few months we've been adding a lot of new functionality to our XMPP server, M-Link, and this has been reflected in an increased tempo of releases. The latest release focuses on improving interworking with XMPP clients and servers which do not support security labels, adding new features of interest mostly to our customers and evaluators in the Govt/Intell/Military markets:
- Default Labels.
- FLOT Labels.
- Improved/simplified support for TransVerse.
- Equivalent label support.
Default Labels
M-Link's support for security label functionality is well documented (see the whitepaper: Using Security Labels to Control Message Flow in XMPP Services). In this new release we add the concept of Default Labels, with the goal of supporting interworking with clients and servers that do not support labels within systems where security label support is required.
A Default Label can be configured for a Server, Peer, MUC room of Service (i.e. applied to one domain within a single server supporitng multiple IM domains).
FLOT (First Line of Text) Labels
This is the ability to insert a FLOT label at the start of any XMPP message. The text from the XEP-0258 display marking is used.
This ensures that clients not capable of XEP-0258 (XEP-0258: Security Labels in XMPP) will see security labels, and will help with deployments in mixed environments.
For local clients, this feature will be used automatically for clients that do not support XEP-0258 (or TransVerse) labels. This capability is enabled by default, but may be disabled. It can also be explicitly configured for peers, which will help supporting systems that are not XEP-0258 capable. Where a message has an HTML part, this is removed, so that only the text option (with the label) is present.
In the screenshots below we show this in operation in a chat between two users, one using the Psi client (which has no label support) and one using a pre-release copy of Swift (which does support XEP-0258 labels).
Improved/simplified support for TransVerse
We have simplified and improved support for the TransVerse Client, which uses IC-ISM labels and its own XMPP encoding. We've tested with Transverse 1.5 and Transverse 2.0 Alpha.
The "TransVerse Map" configuration has gone, and configuration is driven from the SPIF and the server's label catalog. For message delivery to TransVerse, M-Link will insert TransVerse Style labels using the XEP-0258 information, which Transverse will display, and look the same as XEP-0258 labels (colour and display string).
TransVerse supports label catalog discovery for MUC rooms only. M-Link will respond to these discovery requests with a TransVerse compatible catalog, filtered appropriately to the requestor's clearance and other applicable clearances (e.g., the room's clearance). When TransVerse sends a message with one of these labels, it will be treated the same as the corresponding XEP-0258 label and a XEP-0258 label will be inserted by M-Link. In cases where TransVerse does not support label catalog discovery, including chat or through-MUC 1-to-1 chat, TransVerse will offer it's default catalog (e.g., the US labels UNCLASSIFIED and UNCLASSIFIED/FOUO). These labels will not be generally recognized by M-Link.
Here is how Groupchat looks between TransVerse, Swift and Psi:
Equivalent label support
We've done some work on equivalent label support, and provided test data to help those interested in investigating and demonstrating this capability.
Note that this does NOT include label translation (e.g., replacement), which will be provided in a future release.
The key capability is that a policy can specify non-local labels as equivalent to local ones. This means that non-local labels (from peers or local clients) will be validated correctly. The sample data we provide with M-Link includes policy files (including variants with and without equivalents) and catalogs to set up the configuration shown in the diagram below.
The UK Demo policy is the one previously supplied, as is the NATO one. UK-NATO is a new policy, that includes (GENSER style) both UK and NATO labels, so that either can be used on the site (under appropriate clearance control). This can be useful for sites that wish to have users using both labels. Note that this is a new policy with a new policy id. Each of these policies has appropriate equivalents to the other policies.
We're happy to help anyone set up a configuration based on this.
