Assured: The Isode Blog

3 more LEMONADE RFCs published

We've been interested in and involved with the LEMONADE standards for mobile email for quite some time. Optimising for low (and intermittent) bandwidth links and resource constrained devices is a running theme in our messaging products.

Three more Lemonade RFCs have now been published, all authored in whole or in part by Isode employees (adding to our already impressive list we maintain of Internet Drafts and RFCs by Isode Staff).

• RFC 5465 The IMAP Notify Extension - C. King (Isode), A. Melnikov (Isode), A. Gulbrandsen (Oryx Mail Systems GmbH)
• RFC 5259 Internet Message Access Protocol - CONVERT Extension  - P. Coates (Sun Microsystems), A. Melnikov (Isode)
• RFC 5466 IMAP4 Extension for Named Searches (Filters) - C. King (Isode), A. Melnikov (Isode)

Isode R14.4: M-Box POP/IMAP Gateway support for multiple backends

This is the eighth 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

Isode's M-Box POP/IMAP Gateway enables IMAP mail clients to access POP mailboxes using IMAP, allowing mobile clients (for instance) to use IMAP capabilities against that mailbox.

Isode R14.4 extends this capability so that an IMAP client can access multiple back-end email servers. This will enable an email client with a single IMAP account access to retrieve messages in multiple accounts (e.g., Yahoo!, AOL and Gmail). 

Two modes of access are supported:

1. Consolidation of all messages into a single mailbox, so that the accessing client sees just one mailbox containing all messages.
2. Presentation of an IMAP mailbox (folder) for each of the back-end email accounts, so that the user can see messages for each account independently.

This capability is available both in M-Box Gateway and in M-Box.  In M-Box, the user has a real local mailbox in addition to the back end mailboxes. This is useful to provide a real primary mailbox, while also giving access to the back ends.

A key benefit of this solution is that synchronization with back end mailboxes only happens when the client is connected. This gives much better overall performance for the service provider, relative to a solution that synchronizes the whole time. This is due to two common cases:

• In the first scenario, the user only accesses the mailbox with a mobile client, and so when the user is accessing mail on the backend from the desktop, synchronization simply isn't needed.
• In the second, the user has either become inactive, or simply never checks that particular mailbox - again, synchronization is a waste of resource.

For both of these common scenarios, synchronization on demand gives much more efficient resource utilization.

Isode R14.4: Support for TransVerse (JFCOM XMPP Client with Security Label support)

This is the seventh 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

Isode R14.4 adds support for Security Labels in M-Link.

Isode's strategic direction for Security Label support is to follow (and help to set) open standards, and to this end we are supporting XEP-0258.  A short term drawback of this approach is that there are no generally available XMPP clients that support XEP-0258, although we expect this situation to change in the near future.

TransVerse is an XMPP Client developed by the US Joint Forces Command (JFCOM) for use in the Cross Domain Collaborative Information Exchange (CDCIE) project that does boundary checking based on Security Labels. TransVerse and CDCIE use the IC-ISM XML format of Security Labels. While IC-ISM is a valid choice for CDCIE, it is designed for use in a particular environment. It's applicability in other environments may be limited.

The Transverse client is openly available and free. Isode thanks the developers and sponsors for this.  We have extended M-Link to support TransVerse Security Labels and Discovery.  This will enable those wishing to look at Security Label use with XMPP to deploy a system using Transverse clients with M-Link R14.4.

Information on TransVerse, including download, can be found at:  https://xmpp.je.jfcom.mil/

Isode R14.4: Secure Identity Management

This is the sixth 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

Use of X.509 Digital Signatures for peer authentication and other security services such as signed operations and message origin authentication is an important part of Isode's product set.  

A "Secure Identity" is an entity that is making use of digital signatures, and thus has an associated private key. This can be a server (M-Vault; M-Link; or M-Switch) or a client (Sodium; XUXA; X.400 Client Library; or Directory Client Library). The primary feature of a secure identity is holding a private key, and the availability of an associated Certificate for verification.

The current preferred mechanism is a PKCS#12 file. Future releases will extend this to OS Access Mechanisms (e.g., Windows CAPI) and Smart Cards (using PKC#11). The current release enables easy generation of secure identities from Sodium, by generating a public/private key pair and a PKCS#10 CSR (Certificate Signing Request) that is passed to a CA (Certificate Authority) which will generate the Certificate.  The resulting certificate may be published in the directory, and used to construct a PKCS#12 file with the private key, that is then installed in an appropriate location. 

Isode R14.4 adds capabilities for easy GUI management of secure identities within Sodium. This includes basic capabilities to list, delete, and view secure identity information.  Display of secure identity details facilitates identity selection and validation of configuration.  Editing facilities would be prone to user error, so we recommend creation of new secure identity rather than modification. 

These changes will enable easy configuration and management of secure identities, which will help deployment of security services that rely on secure identity.

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 R14.4: Web Application Enhancements

This is the fourth 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

We provide a growing number of Web Applications as a part of our suite of management tools:

• Directory Services Interface (DSI) provides directory access and phone book interface
• Personal Information Administrator (PIA) provides update of personal directory information and messaging preferences
• Internet Messaging Administrator (IMA) provides administration of internet messaging (and XMPP) users and servers, including delegated administration
• Message Operator Interface (MOI) provides message tracking, archive & quarantine management, and statistics

These applications are currently run as application services under Tomcat, and require independent setup and configuration.

Given the growing importance of these tools, it is highly desirable to have them run "out of the box" and we're achieving this in R14.4 by including a bundled application server, so that the Web Applications are installed with the servers and GUIs, and will run immediately.

DSI, PIA, and IMA are "pure" directory clients, and only depend on access to a directory service. MOI is currently a JDBC client of the Audit Database, and uses the Audit Database for authentication. In effect, this makes MOI an independent application.

In R14.4, MOI moves to use directory based authentication, which enables it to be more closely integrated with the other applications. This brings MOI closer to the other applications, and also enables MOI capabilities to be used in conjunction with PIA and delegated administration.

Isode R14.4: New X.400 Security Features

This is the third 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're extend the available X.400 security capabilities, which will be of particular interest to Aviation (AMHS) customers, in achieving full compliance to the ATS Extended Service.

X.400 has a number of end-to-end security services. Message Origin Authentication and Content Integrity have been provided for some while. The significant new capability provided in R14.4 is Message Sequence Integrity.

Message Sequence Integrity

This ensures that messages are received in order, and allows detection of lost or duplicated messages (either accidental or malicious). This service is important for some applications, such as sending flight plans.

Earlier releases provide Message Origin Authentication and Content Integrity by use of a Message Origin Authentication Check (MOAC) per message envelope field. R14.4 adds support for Message Token, which is a per-recipient field. Message Token can be used to provide Message Sequence Integrity, and it also gives an alternate mechanism for providing Content Integrity and Message Origin Authentication. Message Token securely binds the Recipient OR Name to the message, and so also provides proof that the originator sent the message to the specific recipient.

R14.4 also includes an enhancement to the Message Origin Authentication service, by adding a check of the OR Address SubjectAltName in the X.509 Certificate against the OR Address of the originator, in addition to checking the Certificate Subject Name against the Directory Name component of the OR Name. This is a desirable check, as many environments place trust in the OR Address value and use it directly.

We're providing these security services as a part of our X.400 Client Library (P3 and P7), so that the services can be easily used by X.400 applications. The envelope fields are created and checked by the Isode APIs, making the security services very easy to add to applications.

We've has added Message Sequence Integrity checks to XUXA (Isode's demonstration/test X.400 client) using the X.400 Client Library, so that this service can be demonstrated, along with Content Integrity and Message Origin Authentication. XUXA (and the underlying API) allow use of both MOAC and Message Token. An early development screenshot can be found below:

XUXA Sequence Integrity