Assured: The Isode Blog

Vendor Independent XML Security Policy Information File format announced

Isode are pleased to announce their participation in a collaborative effort to bring to market a vendor independent XML SPIF (security policy information file) format. 

Together with Cadmidium, Clearswift, CommPower, eB2Bcom, JSC, Nexor and SMHS, Isode hope to facilitate multi-vendor support of information exchange using Security Labels. 

The use of a single SPIF within an organization and across applications enables the consistent handling and display of Security Labels and also supports the central management of the security policy by administrators.

There are currently two standardized SPIF formats: 

• SDN.801c - specified by the US National Security Agency in 1999; and 
• X.841- an ITU-T format specified in 2000 

Both are encoded in ASN.1 (a standardized binary format) and consequently can only be managed using special purpose tools. 

Vendors have generally either adopted one or other of these standard formats, or defined their own proprietary SPIF format for specifying a security policy. 

8 organizations have now come together to develop an openly available XML schema that allows the generic specification of a security policy and encompasses both X.841 and SDN.801c functionality.

Isode CEO Steve Kille:

"We adopted SMHS's XML schema for use in our products' security policy infrastructure as one of the SPIF formats supported by the Isode product set. The extensible nature of XML enabled us to extend the schema to include colour support for security classifications and enables other organizations to contribute extensions that can be easily removed by systems that do not support them. We’re delighted to be working with these organizations to build a common SPIF format and hope to see others join in the development and maintenance work."

Version 1.0 of this SPIF format definition is available from the Schema page on the www.xmlspif.org website. This page also links to sample SPIFs representing a range of policies, including US GENSER, Australian AGIMO and UK JSP 457. We expect supporters of this format to contribute other samples. 

We'd encourage other organizations to join this initiative as equal partners, anyone interested in doing so should contact will......

The full text of the press release is available from the isode website.

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.

Isode R14.4: Strong Authentication Verification Infrastructure & use in M-Vault

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

R14.4 contains a number of related new capabilities in support of strong authentication and other uses of digital signatures. One aspect of digital signatures is the digital signing, and this is handled as a part of Isode "secure identity" infrastructure and management. This message looks at new capabilities in support of checking digital signatures. 

The mechanics of checking a digital signature is reasonably straightforward, and Isode provides flexible software library support for this. Associated with a verified digital signature will be an X.509 Certificate, which needs to be checked according to the rules of X.509 PKI. Isode's target mechanisms to achieve this are defined in RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". In order to follow these procedures, two things are needed. 

1. One or more "trust anchors" that define Certification Authorities (CAs) that are trusted. Open Internet environments will often use a large number of public CAs as trust anchors. Secure environments will typically use a single trust anchor, using cross certification to manage (on server side) what is trusted. 
2. Access to a directory service. This is needed for CRL validation and for "path discovery", which means identification of additional X.509 certificates needed to build the trust chain for the full certificate validation relative to a trust anchor. 

This information, along with additional information (e.g., whether or not to perform CRL checking) needs to be configured for any entity doing certificate validation. This is currently configured in a per-application tailor file, which is not always convenient. R14.4 extends the verification infrastructure to enable configuration options to be provided by the application doing the checking. This enables configuration information to be stored in a natural location for the application and support GUI configuration. A simple example of this can be seen in the Sodium bind profiles, that enable direct setting of options for the certificate verification. 

M-Vault handles configuration in two ways. First a PKCS#12 secure identity used by M-Vault for signing, may have a number of certificates stored in the PKCS#12 file. If any of these are self signed, M-Vault treats them as trust anchors. This reflects the common PKCS#12 approach of storing a certificate chain, ending in a trusted CA. Additional trust anchors may be configured as files on a file-store accessible by the directory server. This requirement for local access reflects the security sensitivity of this information. The location of the additional trust anchors are configured as directory attributes. The values of the certificates are made available to directory clients by use of a DSE (DSA Specific Entry) so that they appear as values associated with the root of the directory information tree. This allows remote inspection of the trust anchor values. 

Directory access and other certificate verification parameters for M-Vault are configured as attributes and can be managed using Sodium. This configuration is illustrated in the screenshot below, and display of the trust anchors is in the following screen shot.