Assured: The Isode Blog

R14.4 now available for download

After a long run of 28 blog posts about 'forthcoming' R14.4 features, we've now shipped the software. R14.4v0 is now available for download by customers and existing/new evaluators.

The blog posts that related to R14.4 can be seen by clicking on this link. Alternatively there's a run-down of the new features on the R14.4 product page on our website.

R14.4 is a significant update to our complete product set with new features for our XMPP Server M-Link, LDAP/X.500 Directory Server M-Vault, POP/IMAP Message Store & Gateway M-Box , both the SMTP and X.400 versions of our M-Switch message switch and our X.400/Internet mail conversion server, M-Switch MIXER.

We've also made considerable improvements and additions to our management tools.

Over the next few weeks we'll be publishing and blogging about the changes we're making to our evaluation guides to take these new features into account.

Isode R14.4: XUXA (Test & Demo X.400 User Agent) Features

This is the final message describing new features in Isode R14.4, scheduled to ship this week. You can see all of the messages on this blog relating to R14.4 by clicking on this link.

Isode provides XUXA as a test and demonstration X.400 client. This gives access via X.400 P3 or P7 to the capabilities of Isode's servers and APIs.  R14.4 contains a number of improvements including:

1. Demonstration of the new X.400 features, in particular message sequence integrity (needed for AMHS Security).

2. Ability to send and receive X.411 security labels.  A specific goal of this is to help test out M-Switch MIXER security label handling.
3. Probe improvements, to set message length and content type.
4. New logging tab to give easy access to log and error information.
5. Improved handling of messages with multiple body parts. Body parts can now be saved directly from the Body parts list.

We've also made a general improvement in support of Directory Names. X.400 OR Names comprise an OR Address and a Directory Name.   Older X.400 deployments primarily work on the basis of OR Address, and XUXA has used OR Addresses only. Use of OR Addresses is pragmatic, but has the disadvantage of containing the rather awkward ADMD and PRMD components.  Directory lookup is supported, but addresses are primarily handled as OR Addresses.   R14.4 adds a mode so that Directory Names can be used (or both, which looks rather ugly). This will help test out Directory Name based deployments.  Use of Directory Names allows a more natural naming structure and hiding the OR Addresses (as IP addresses are hidden by Internet email addresses), and also means that information on users, including capabilities can always be looked up.

In addition P772/STANAG 4406 Military Header "Message Type" is now correctly set and Displayed (previously this was GUI only), so there is now a working P772 header in addition to STANAG 4406 Priority (MTS). We may add UI support for other P772 capabilities (now fully supported in the underlying C and Java client APIs) in a future release and would welcome feedback on this.

Isode R14.4: STANAG 5066 Console Improvements

This is the penultimate message describing new features in Isode R14.4, scheduled to ship this week. You can see all of the messages on this blog relating to R14.4 by clicking on this link.

STANAG 5066 Console is a GUI tool provided by Isode to help set up and test STANAG 5066 Networks over HF, VHF and UHF Radio. It also provides service discovery and operator chat.

We've made a number of improvements to the STANAG 5066 Console in R14.4, which make it easier to use and more flexible:

• Better information on STANAG 5066 activity

• Improved performance analysis
• More configuration options (e.g., enabling use of multiple SAPs)
• Support for operation where STANAG 5066 servers only support ARQ (or to perform ARQ only tests)

The screenshot below shows reporting of traffic between multiple nodes and the throughput summary.

Isode R14.4: Audit Database - switch to full JDBC operation

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

Isode's audit database is used to hold message audit information, derived from M-Switch audit logs on one or more servers.

The audit database supports Isode management tools that provide statistics, message tracking, and quarantine management. Although some tools use JDBC, others are specific to the Postgres database.

R14.4 contains a significant upgrade to our audit database integration and tools, so that all of our tools and components access the audit database using JDBC. We continue to support Postgres, but the Isode products are now essentially independent of Postgres.

In a future release, we plan to support an additional simple SQL database that we will bundle with the Isode release. This will be ideal for demonstrations and evaluations.

We may support additional SQL databases. Because of minor variations of JDBC between database implementations, careful testing with any databases that we choose to support is vital, and we will need to run copies at Isode for effective support. Because of this, we will need to consider carefully which of the many available databases we support. Our choice of databases will primarily be driven by the requirements of Isode customers.  

Isode R14.4: Sodium, Sodium Sync, LDAPS and Strong Authentication

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 adds considerable flexibility in strong authentication configuration for Sodium and Sodium Sync. This is of particular importance for Sodium Sync, which may need to connect with strong authentication (e.g., using LDAPS) to a server with a strong authentication configuration that is quite different to the local one.

Strong Authentication can be used with X.500 DAP, LDAPS (the deprecated, but widely used direct mapping of LDAP onto TLS), and with LDAP. Strong authentication with LDAP (not using LDAPS) requires use of TLS, using the START-TLS option. LDAP Bind profiles can be configured to use TLS, with either strong authentication or other methods. The signing part of strong authentication simply makes use of a configured Secure Identity to sign the message, which will include client's Directory name as the X.509 certificate's subject name.

Server verification requires checking of the X.509 Certificate associated with the server, which will be supplied by the server in the bind. A trust anchor (Certificate) will be provided as part of the Secure Identity of the client, and for a local server this will usually be appropriate for server verification. Additional verification parameters, such as use of CRL checking can be configured as part of the bind profile.  

Where the configured trust anchor is not appropriate, the certificate provided by the server will be presented to the user. Sodium checks that the server certificate contains information that correctly identifies the server, using the certificate's SubjectName and (for LDAP), DNS Name and IP address

SubjectAltName values. Any inconsistencies are flagged to the user. The user may accept the certificate for one connection only or configure the certificate as "trusted" in the bind profile. This provides a secure and convenient mechanism to configure trust with remote servers.

The following screenshots show:

• What happens if you ask Sodium to do a "Strong" bind to an LDAP URL.  In this case, Sodium uses SASL EXTERNAL, which implies "startTLS" (so the box is checked and can't be turned off), and allows you to choose an identity to use:

• What happens if you ask Sodium to do a "Simple" bind to an LDAP URL.  In this case, the user has requested startTLS.  I.e. it'll connect, startTLS, then do a simple bind.  In this case no identity is used, but any server certificate will be checked against the user's trusted certificates.

• The "trusted certificates" associated with a bind profile.

• The dialog that is displayed if you do a bind over LDAP with TLS (either LDAPS or LDAP+startTLS) and the server sends back  a certificate which isn't trusted and (in this case) has failed the server id check.

Isode R14.4: New Features in Sodium & Sodium Sync

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

We've made a number of improvements to Sodium and Sodium Sync for R14.4, which are described here. New features common to both Sodium and Sodium Sync:

1. Allow locking of the entry view and current tab, to make it more convenient to navigate around a group of entries whilst maintainingthe same information view.
2. Various new templates and template improvements.
3. Enumerations in templates can be set case-insensitive.
4. A manager mode is introduced, giving additional control over availability of advanced features and display.
5. Subentries may be viewed (in manager mode), and subtree specifications may be edited to control administrative areas.
6. Collective attributes may be added and edited within the collective attribute subentry. Collective attributes allow values to be set for entries that are common over an administrative area. 
7. Arbitrary attributes may be added to any entry, both user attributes and operational attributes.  This supports extensible objects.
8. Access control may be viewed and edited in the ACI tab (when enabled). This has been described in more detail in an earlier blog post.
9. Search results may now be refreshed.

New Features in Sodium Sync include:

1. Options to easily integrate with the File Transfer by Email channel in M-Switch for incremental synchronization over email.
2. Synchronization to Microsoft Active Directory (AD).  AD's LDAP access has some interesting special characteristics. A functional goal of the initial Sodium Sync release was synchronization from AD.  R14.4 adds synchronization to AD. Caveats:
   • X.400 Addresses are not synced to the AD format (this could be added). They can be pulled from AD.
   • Passwords are not synced (this could be added).  Note that it is possible to push passwords into AD using a special mechanism but they cannot be pulled out.
   • AD requires that attributes of Directory Name syntax point to local AD entries. Data synced must comply with this, and must not contain loops or forward references.
3. Paged results are supported in the sync, which removes restrictions on DIT fan-out when syncing with AD.
4. Entry filtering may now be done with a true LDAP filter in additional to the hierarchical filter previously supported.
5. Attribute filtering now supports filtering of individual object class values.
6. Dereferencing alias entries is supported as an option.
7. Applying a complete update from a change-LDIF is now optimised to make the minimum possible changes (similar to a sync-from-LDIF).
8. Merge syncs are better supported through a safety check that forbids addition and deletion of entries.
9. GUI changes make it easier to enable/disable scheduled syncs, and to force a complete update on a cached sync.
10. Scheduled sync from a queue now flushes the queue.
11. Now checks for existing entries in the target subtree, to reduce risk of destroying data by configuring a sync in the "wrong place".

We welcome feedback on all of these improvements as well as suggestions for future development.

Isode R14.4: FLOT and other text format Security Label support

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

Modern use of Security Labels will involve a comprehensive structured format such as the ESS format defined in RFC 2634 "Enhanced Security Services for S/MIME". Other techniques are also used for supporting Security Labels in email, such as FLOT (First Line of Text) labels. This is an example FLOT label:

Protective Marking: UNCLASSIFIED

Isode R14.4 adds in support for a variety of messaging Security Label formats, and mapping between them. The following structured label formats are supported:

1. ESS Labels in S/MIME.
2. X.411 Labels in X.400 

Support for these formats is discussed in more detail in the context of M-Switch MIXER.  The following ad hoc label formats are supported:

1. FLOT (First Line of Text) for Internet Email and X.400, as the first line of text in the first text body part.  This is supported for all types of text  body part.
2. Security label included within the Subject:  line of an Internet email.
3. Security Label in a special X- Header of an Internet email. This can be configured for any header.

A primary goal of Isode's mapping of Security Labels in messages is to convert between structured and ad hoc forms.   Ad hoc labels are often surrounded by special (delimiting) text, and M-Switch can parse and generate this.   Ad hoc labels are generated from structured labels by use of capabilities from Isode's Security Policy infrastructure. 

Text labels can be generated from the Security Classification or from the entire Security Label, using a choice of marking data from the Security Policy used.   There is no standardized approach for the reverse mapping. Isode provides a flexible text lookup and conversion mechanism to map from the (ad hoc) text security labels to Isode XML format structured labels. This approach gives a high degree of flexibility to support different ad hoc security label formats.

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: Support for the xmlspif.org open XML SPIF

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 Open XML SPIF from xmlspif.org was recently announced. Isode is an originator and strong supporter of this initiative.

To help understand the importance of SPIFs, Isode has also written a short white paper "Why do I need a SPIF and what format should I choose?" which is useful background material to the announcement.

SPIF support and Isode's format independent approach in the Isode product set is described in the White Paper "Isode Security Policy, Security Label and Security Clearance Infrastructure"

In R14.4 we have aligned our XML SPIF support to the xmlspif.org version 1.0 specification, and we plan to track updates to this specification. R14.4 includes samples following xmlspif.org 1.0, or the examples on the xmlspif.org web site can be used.

Isode R14.4: SubjectAltName Support

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

Support of X.509 SubjectAltName is important for all applications using Digital Signatures and X.509 PKI, apart from Directory Applications. Background information is provided in "Why Strong Authentication? - The Security and Administrative Benefits of using X.509 PKI based Strong Authentication"

An X.509 Certificate identifies the entity being certified by the "Subject Name", which is an (X.500/LDAP) directory name.   This Subject Name can be used directly by directory protocols, as this is how directory entities are identified.   Other protocols names entities in different ways. For example Internet Email identifies users by an email address, so that a digitally signed email needs to have the certificate associated with that email address.  If the email address does not match, the signature is pretty much worthless.

X.509 Certificates support this by use of the "Subject Alternate Name" extension mechanism, which is commonly abbreviated to "SubjectAltName". This mechanism allows different names to be associated with a Certificate. In particular:

• Internet Email Address
• Domain Name  
• IP Address
• URI
• Two X.400 forms:
  • OR Address (for Users, UAs, P7 and P3; defined in X.509)
  • MTA (for P1 and P3; defined in X.402)
  •   
• Two XMPP forms (define in RFC 3920 Section 5.1.1):
  
  • Client (the JID - which is the XMPP User Name)
  • Server (according to the services offered)

R14.4 adds support for these forms of SubjectAltName (apart from X.400 MTA, which will be added in a future release). The rest of this message looks at what support means.

First, support ties back to the various places where digital signatures are used. Isode products using digital signature check validity of the appropriate SubjectAltName. This covers XMPP, Internet Messaging, Web Applications and X.400 messaging. Note that directory products use SubjectName. 

R14.4 also adds support to help generate certificates with the correct SubjectAltName values. The starting point for generating a certificate is to use Sodium's capability to build a PKCS#10 CSR (Certificate Signing Request) that is sent to the Certificate Authority (CA) that generates the Certificate Sodium's starting point for the CSR is a directory entry that holds information on the entity to be certified. The SubjectAltName information will usually be held as attributes in the directory entry, so Sodium makes it straightforward to include SubjectAltName values derived from appropriate attributes in the directory entry. SubjectAltName values can also be manually entered into the CSR.

Finally, there is support for ongoing management.  SubjectAltName values in certificates stored in the directory are displayed by Sodium along with other information in the certificate.  The values of SubjectAltName are checked against values in the entry in the directory.  Similarly, the Subject Name is checked against the name of the entry. Any inconsistencies are clearly flagged.  This enables problems to be easily detected; for example it would show where a user changed email address (as represented in the email attribute) and this change was not correctly reflected in an updated certificate.