Assured: The Isode Blog

Requirements for XMPP Digital Signatures (XEP-0274)

Digital signatures for XMPP messages are a desirable addition to the currently standardized peer to peer digital signatures (strong authentication based on PKI). Digital signatures on XMPP messages can enable:

• Message Origin Authentication
• End to end Content Integrity checks
• Binding of Security Labels to messages by Clients, MUC Rooms, and Gateways 

Previous attempts to standardize have not gained general acceptance, and have a number of problems. Ad hoc implementation efforts that we are aware of also have problems. 

Isode is working to enable a standard. XEP-0274 "Design Considerations for Digital Signatures in XMPP" has been developed primarily by Isode staff and has just been published. It looks at requirements and possible approaches to meeting these requirement. It looks particularly at approaches using the XMLDSIG XML digital signature standard, which we believe is the most promising direction.

Both requirements and technical solution to address these requirements are complex. We believe that wide participation will be crucial to develop a workable and widely adopted standard in this space.

Isode Partners with Zion Software to provide XMPP connectivity to legacy IM Networks

In Release R14.5 of Isode's M-Link XMPP Server, support has been added for XEP-0114 Jabber Component Protocol, which among other things can be used to provide a mechanism for connection of External Legacy IM Services. The JBuddy XMPP Gateway from Zion Software supports XEP-0114 and provides connectivity to AIM, ICQ, Windows Live/MSN and Yahoo Instant Messenger services. Isode's  M-Link XMPP server has been certified by Zion Software as a tested compatible XMPP server for use with their JBuddy XMPP Gateway.

Isode R14.4: New Multi User Chat (MUC) Features in M-Link

This one of a series of a messages describing new features in Isode R14.4, scheduled to ship in April 2009. You can see all of the messages on this blog relating to R14.4 by clicking on this link

The current version of M-Link has core support for Multi-User Chat (MUC). R14.4 builds on this substantially, and provides a pretty much complete implementation of the comprehensive range of capabilities defined in XEP-0045 "Multi-User Chat".

The current release provides only temporary chat rooms, which are created on demand and will be destroyed when the last member leaves the room. R14.4 adds permanent rooms. A key design decision is that the room configuration is held in the directory as described in "XMPP, M-Link and Directory". 

Room administration can be done with XMPP, using standard XMPP client capabilities. In this mode of operation, the directory simply acts as a back end database. Alternatively, permanent rooms can be preconfigured directly in the directory, supporting a model where rooms are controlled by administration that is independent of XMPP client access.

New capabilities provided for MUC include:

• Specification of Group Members
• Option for Member Only groups
• Invitation only groups
• Administrator and Moderator roles
• Ban Lists
• Password control (secured rooms)
• Security Label control
• Moderation of Floor
• Kicking out Participants

The Security Label Capabilities are discussed in "Using Security Labels to Control Message Flow in XMPP Services".

The following screen shots show two views of the same group, showing many of the above options.  One screenshot is taken use the PSI XMPP Client and one is taken using Isode's Sodium directory administration tool.

Isode R14.4: M-Link Clustering

This is one in a series of messages describing new features in Isode R14.4, scheduled to ship in April 2009. You can see all of the messages on this blog relating to R14.4 by clicking on this link

The core XMPP model is one server per domain. A single M-Link Server can support multiple domains, with delegated administration of users within each supported domain.  XMPP Clustering is a technique to enable a single domain to be supported by multiple servers. XMPP clustering is provided by some XMPP servers, using vendor-specific techniques. The capabilities provided varies widely between products, and so features provided should be reviewed with care. Isode is adding XMPP Clustering to M-Link in R14.4.  

XMPP Clustering needs to synchronize "state" between servers to ensure that messages are routed to correct destinations and the presence information is correct.  

It is also important that information from various services (Presence, Multi User Chat (MUC), and Publish Subscribe (PubSub)) are sent on the local server where possible. For example, where MUC subscribers are on multiple servers, participant groups should be managed locally on each server, and messages sent directly to other local users without having to go to another server first. A related characteristic is the MUC and Pubsub will continue operation in the event of any cluster node failing.

One goal of XMPP Clustering is to support "LAN Clustering", where there are multiple clustered XMPP servers operating on a common fast highly reliable local network. Clustering in this environment is important for large deployments, as it enables servers to be added to support load levels greater than can be handled by a single server. This horizontal scaling is important for service providers and large enterprises. It also provides reliability, so that service can continue in the event of failure (accidental or planned) of a server.

A second and harder goal is to support "Wide Area Clustering", where the XMPP servers are interconnected by links that may be slower and less reliable than a LAN. There are various scenarios where this is important:

• Off site operation of a server, so that service can continue in event of site failure (disaster recovery)
• Support of organizations with multiple sites, so that a server can be run at each site.
• Support of a distributed military deployment, for example with one server at HQ and another in the field.

Supporting Wide Area Clustering requires protocols and algorithms that will deal with wide area network throughput/latency and periods where connectivity is lost. Servers need to be kept in sync, but

operations should continue as well as possible when there are network failures. Having a server close to a client with good connectivity will give a fast and robust client experience. It is important that local traffic is optimized, and not switch between servers except where needed. Handling traffic locally to a server without unnecessary switching is particularly important for Wide Area Clustering.

Isode's XMPP Clustering implementation is designed to work well for both LAN Clustering and Wide Area Clustering environments.

R14.4: Security Label Support in M-Link (Isode's XMPP Server)

This is the fifth in a series of messages describing new features in Isode R14.4, scheduled to ship in April 2009. You can see all of the messages on this blog relating to R14.4 by clicking on this link

In R14.4 we'll be adding Security Label support to M-Link (our XMPP Server). The overall approach for this is described in our whitepaper "Using Security Labels to Control Message Flow in XMPP Services".

These features extend M-Link so that it will control XMPP messages switched, based on a Security Policy configured for the M-Link server.

M-Link will have Security Enforcing checks to ensure that messages are labelled according to Security Policy (including US GENSER; NATO ACP 322; UK JSP 457), and that they are only sent to destinations (Users, Peer Servers, and MUC (Multi User Chat) Rooms) which have a Security Clearance that matches the Security Label on the message.

Security Labels are handled according to XEP-0258, to provide the following functionality:

• Support of the standard ESS Security labels, as specified in RFC 2634: Enhanced Security Services for S/MIME.
• Display Labelling and Discovery Services enable XMPP clients to support Security Labels without needing complex Security Policy support.

XMPP over HF Radio?

Isode CEO, Steve Kille, gave a presentation yesterday to the High Frequency Industry Association meeting in San Diego (part of the Armed Forces Communication Electronics Association's "AFCEA West" Convention), the subject:

"Running XMPP over HF Radio"

(slides available in PDF format)

Instant Messaging, Presence and Chat are already used in secure environments, and the advantages of using the XMPP Open Standard protocol are well understood.

However running these services over a typical HF Radio connection (say 2400 bits/sec or 300 bytes/sec) presents some unique problems. The talk outlined those problems and proposed solutions.

You can read more about the problems of running XMPP over low bandwidth links in the Isode whitepaper:

"Operating XMPP over Radio and Satellite Networks"

(click for html version)

Isode at FOSDEM 2009 (Brussels)

The XMPP Standards Foundation (XSF), in which a number of Isode staff are actively involved, will be holding its sixth XMPP Summit in Brussels, Belgium at the same time as FOSDEM 2009 (6-9 February).

As part of the summit, the XSF will be hosting talks and demonstrations in a devroom on Saturday, February 7th, with one of the presenters being Isode's Dave Cridland. Full details of the summit can be found at http://xmpp.org/summit/summit6.shtml.

We'll post Dave's slides and a summary of his talk (Presenting Information Flow in Deployed XMPP Clients) on this blog during the week following the event.

Operating XMPP over Radio and Satellite Networks

In the first of two announcements with an XMPP theme today, we've placed a new whitepaper on the Isode website "Operating XMPP over Radio and Satellite Networks" which examines how XMPP services (Instant Messaging, Group Chat, Presence) can be effectively deployed in environments characterized by constrained bandwidth and high latency.

The paper discusses modifications that need to be made (and which we at Isode are making to our M-Link XMPP server) so that XMPP services can be deployed over networks running at 2.4 kbit/sec (300 bytes per second), which is a typical (but not minimum) HF radio speed.

XEP-0258 (Security Labels in XMPP)

XEP-0258 (Security Labels in XMPP), authored by Kurt Zeilenga of Isode, has just been published:

   http://www.xmpp.org/extensions/xep-0258.html

Our product set includes a Security Label infrastructure that is being used by an increasing number of Isode products, as described in the whitepaper "Isode Security Policy, Security Label and Security Clearance Infrastructure" which can be found at http://www.isode.com/whitepapers/isode-security-infrastructure.html.

Our plan to support Security Labels in M-Link (our XMPP server) is described in another whitepaper, "Using Security Labels to Control Message Flow in XMPP Services" (http://www.isode.com/whitepapers/controlling-message-flow.html) 

This plan includes support of future standards and our involvement in such standards, which is now reflected in XEP-0258. We'll be adding XEP-0258 support to M-Link.

XEPs (XMPP Extension Proposals) are the standardization framework used to extend XMPP. Some XEPs are stable standards, and others (including XEP-0258) are experimental, but expected to evolve int standards.

The key capability defined in XEP-0258 is a mechanism to carry Security Labels with XMPP messages. The mechanism is extensible, so that any Security Label format can be used, and a specification is included to use ESS Labels (as used by S/MIME and defined in RFC 2634). This gives a practical mechanism that can be deployed now, while enabling use of future standard label formats.

XEP-0258 is designed so that it can be used by XMPP clients in a very straightforward manner. In particular:

• Display information is carried with labels, so clients can easily display labels without understanding Security Label syntax or semantics (which in general is complex)
• A client can ask (discover) which Security Labels (including display information) can be used for a specific destination. This enables a client to add a valid security label to a message without understanding Security Label syntax or semantics. 

We believe that this approach will enable many XMPP client developers to include Security Label support in their products or open source clients, without the need for extensive specialist code. 

We are keen to work with others in this area, and encourage interested parties to contact Isode.

Security Labels & XMPP

The issue of ensuring that sensitive information is not sent to inappropriate individuals or domains is a critical one to many of Isode's customers. A new whitepaper on the Isode website looks at Using Security Labels to Control Message Flow in XMPP Services.

Isode's approach is to associate a Security Label with each XMPP message. Access to an XMPP message is then controlled by Security Clearance, with access control determined by Security Policy held in a Directory.

The paper looks in detail at how we plan to enhance our M-Link product to provide Security Label based controls for user-to-user messaging and for Multi-User Chat (MUC).