Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / whitepapers /

Using Security Labels to Control Message Flow in XMPP Services

Published on: 06 November 2008

Introduction

XMPP (the Internet Standard eXtensible Messaging and Presence Protocol) is widely used by military and government organizations with stringent security requirements. It is critical to ensure that sensitive information is not sent to inappropriate individuals or domains. Security Labeling is the mechanism of choice for handling sensitive information in high security environments.

This paper looks at the use of Security Labels in conjunction with XMPP services, and how Isode plans to enhance its M-Link product to provide Security Label based controls for user to user messaging and for Multi-User Chat (MUC).

Security Labels, Security Clearance & Security Policy

This paper assumes some background knowledge of Security Labels, Security Clearances and Security Policy. Background information can be found in three Isode white papers:

• Access Control using Security Labels & Security Clearance gives a summary of how Security Labels and Security Clearances work.
• Managing and Securely Determining Security Clearance explains how Security Clearance is managed in the directory, and how entities performing access control obtain information on Security Clearance.
• Isode Security Policy, Security Label and Security Clearance Infrastructure
  describes the Security Policy, Security Label and Security Clearance infrastructure developed by Isode for use in its products.

Applying Security Labels to XMPP

The core model proposed is to associate a Security Label with each XMPP message, as shown above. Access to an XMPP message is then controlled by Security Clearance, with access control determined by Security Policy. The diagram above shows this model, and two examples of its use to enforce policy:

• A user with an appropriate Security Clearance gaining access to an XMPP message.
• An XMPP message being allowed to pass through a gateway with an associated Security Clearance reflecting what is allowed to pass to a remote domain.

This is a straightforward application of the model that a Security Label is applied to information, and access to that information is then controlled by Security Clearance.

This model is used by the two XMPP systems using Security Labels that Isode is aware of, and in particular by the Transverse system from JFCOM, shown above. Here the UI allows setting a security label for each message to be sent, and displays the security label of each message received. Having a security label on each XMPP message is a clean model that makes enforcement straightforward. It may also be useful to present this to the user in a way which shows security labels related to conversations in the common scenario of the same label being used for each message.

Models for applying Security Enforcing Functionality

In electronic systems, it is desirable to use Security Enforcing Functionality (SEF) to ensure that information is correctly handled. Client systems are usually Security Aware, but are not the place where SEF is applied. SEF is usually applied on managed server systems. Two complementary models for applying SEF to XMPP are now described:

• Applying SEF at a boundary gateway.
• Applying SEF within an XMPP (M-Link) server.

Applying SEF at a Boundary Gateway

The above diagram shows how a boundary gateway with SEF (Security Enforcing Functionality) can be inserted between a pair of XMPP servers. A gateway of this nature would typically be co-located with a firewall, and an organizational or domain boundary. The enforcing model is simple. There is a Security Clearance associated with each direction of traffic across the gateway, which essentially defines what is allowed in and what is allowed out. For each XMPP message reaching the gateway, the Security Label attached to each message is checked against the Security Clearance, and the message is only allowed through if it matches.

This boundary enforcement fits well with the security models of many organizations. It is the model that is being used by JFCOM in the Cross Domain Collaborative Information Environment (CDCIE) project.

There are three important technical benefits of this architecture:

• It is a simple model, which is good for SEF.
• SEF is placed at the ideal location for inter-organization checking.
• Additional check can be made at the same point, such as dirty word checking or whitelisting/blacklisting. Security Label translation could also be done.

However, it has a number of disadvantages:

• XMPP servers talk directly onto each other and this type of gateway is not in the standard XMPP architecture. This can make configuration awkward, particularly for configuring server to server authentication.
• Security Labels are written by XMPP clients that do not connect directly to the gateway. In order to validate the label, one of two approaches must be taken (neither of which is ideal):
• Use a digital signature. This is architecturally good, but there are not standards for this.
• Use a trust chain, and assume that intermediate components have not modified the message or label.
• It does not enable a number of capabilities described in the second model, and provides no intra-organization protection.

Applying SEF in the XMPP Server

The second model is to associate SEF with the XMPP Server. This model provides intra-organization checks and a great deal more functionality and options for control than the gateway model. The rest of this paper looks at controls that can be applied with this model. MUC (Multi-User Chat) is tied to an XMPP server, and SEF for MUC is also examined.

Controlling Message Delivery to Users

The basic SEF control to apply is to ensure that a user has a Security Clearance that matches the Security Label of each message that is delivered to the user. This is the core SEF of ensuring that a user only receives information that the user is cleared to access.

The user's Security Clearance will generally be obtained from the directory, as described in the Isode white paper Managing and securely determining Security Clearance. There will be a Security Label associated with each message, and that will be checked against the Security Clearance.

This check is central, and ensures that users do not receive information that they are not entitled to access. This check will be applied as a message arrives in the switch, so the effect of this control will be to ensure that messages arriving at the server are rejected immediately if they may not be sent to the intended recipient.

This check can be always be made for both local and sometimes made for remote recipients, if this data is shared by common directory access. It is desirable to block messages at the earliest possible point.

Controlling Messages Sent by Users

There is a symmetrical control, which is to check the Security Label on each message sent by a user against that user's Security Clearance. This check has two benefits:

1. It prevents the user from sending a message that they are not allowed to see, which could lead to problems.
2. It is unusual for this to be allowed by most security policies.

This control is likely to be used in most deployments. In most situations, the sending client should prevent this from happening.

Server to Server Controls

A very similar approach can be taken for server to sever to server communication. Note that checks can be made in both directions and at both servers – four possible places to check for each server pair. The two checks for one server are shown above, noting that a server should not rely on checks made by the peer server. These checks would be configurable for each server or for each domain (in the XMPP core model there is a 1:1 mapping between servers and domains).

This enables access control checks to be made on messages flowing between servers. This can be used to give the same checking functionality as provided by the gateway SEF model. The difference is that the checks are made at the XMPP server rather than at the organizational boundary.

These checks will be of high importance when connecting XMPP servers across an organizational or security domain boundary in cases where no gateway is used. They may be less important between servers within a single security domain.

Client Location

The location of a client can also have an effect on clearance. For example, a user using an XMPP client on a mobile phone or from a terminal in an unsecured area may not be allowed to access or send secure information, even where encryption is used. From the XMPP server applying SEF, the location of the client must be inferred from the IP address from which it is coming, or from the domain that may be associated with the IP address. Note that precaution against IP address forging must be taken.

Client location based access control can be handled by having the XMPP server associate a Security Clearances with location determined by IP address or IP address range. These checks will be used as additional checks against inbound and outbound messages, so that the Security Label on a message must match the Security Clearances for both user and user location.

Controls on Presence Information

The controls considered so far relate primarily to messages sent and received by users. XMPP also exchanges information about users and presence information, such as location or availability. This presence information may be sensitive, and require controls analogous to user messages. This can be done by associating a Security Label with a user’s presence information. Presence information is exchanged by use of special XMPP messages, and so the Security Label associated with the presence information can be attached to these messages. Then the same controls as for other messages can be applied. It may be desirable to place different controls on parts of the presence information that are more sensitive and should not be shared so widely.

Control of Information in an XMPP Server

It is desirable to ensure that an XMPP server does not contain information which is not appropriate to its security domain, and in particular it should not hold information that is more sensitive than allowed. This can be controlled by associating a Security Clearance with the XMPP Server and obtained in a manner that can be verified (e.g., as part of a Certificate). Messages with Security Labels that do not match this server clearance will be rejected. For example, this will prevent Top Secret messages being sent through a server with clearance up to Secret.

A related control is handling of messages without labels. If the Security Policy defines a default policy, then XMPP messages without Security Labels will be handled as if they had the Security Label defined by this default policy. Otherwise, the XMPP server will require all messages to have Security Labels, and will reject unlabelled messages. Note that this behaviour is defined by the Security Policy used by the XMPP server, rather than by server configuration.

General Control of Server Access

An additional control that may be applied is to associate a Security Label with a server, and require that all users (and user locations) have a Security Clearance that matches this label. This will ensure that all users and (and their connections) have an appropriate Security Clearance.

Conference Rooms (Multi-User Chat)

The core XMPP model is of messages going from one user to another single user. Multi-User Chat (MUC) is an extension to this core service. MUC is implemented by use of “Rooms”, that may be provided by an XMPP server. A user will send a message to a room in the same way as sending a message to an individual user (i.e., the room has an address just like a user). A room will have members that are managed by users who have appropriate rights. When a message is received at a room, it will be sent on to all of the members. These onward messages will come from the room, and will usually also include the identity of the original sender.

It is useful to note that a room can work securely without any additional controls. Essentially, messages are switched by the conference room, and are passed on to members with the same Security Label as specified by the sender. Delivery of the message will be controlled by that security label. This means that if a conference has members with differing Security Clearances, some messages with Security Labels with low security classifications will get delivered to all members, whereas messages with labels with higher security classifications will get delivered only to some members. In some situations, this could be very helpful behaviour, but it could be confusing. It is also important to see that room controls are secondary to the basic user controls. This basic "no controls" behaviour will be useful for in some situations, and in particular for temporary rooms used to hold short ad hoc discussions. However, two additional controls should generally be used.

The first control is to give the room an associated Security Clearance. The MUC room will ensure that messages are only accepted with Security Labels that is correctly validated against the room’s Security Clearance. This controls which messages go through the room.

The second control is to give the room as an associated Security Label. The Security Clearance of potential room members is matched against this Security Label, and only users with appropriate Security Clearance are allowed to join the room. This controls room membership. An alternate way to achieve this functionality would be to use a Security Label, which would typically be the same as the first control value. This would require that all messages exchanged have exactly this security label.

The values of Security Label and Security Clearance associated with a room could be broadly static. They could also change dynamically, in line with topics being addressed in the room. This latter approach has potential to be confusing and awkward to implement.

Digital Signatures

Digital signatures could also be used to sign individual XML messages. With peer authentication, validation relies on a trust chain and does not protect against messages being modified in transit. Note that use of link encryption provides data integrity, and so signatures are not useful for single hop. The solution to this is to use digital signatures on the XMPP messages. This has been discussed extensively in the XMPP community, but there is not yet a standard. Digital signature of XMPP messages by an XMPP user would provide:

• Origin Authentication
• Message Integrity
• Non-repudiation of origin (dependent on the approach)

The digital signature would also provide the function of binding Security Labels to XMPP messages, which is important when verifying a Security Label on a message that may have passed through a system that is not trusted.

It may also provide value to have an XMPP server sign messages, for example as part of MUC support when messages are sent on.

Use of digital signatures for XMPP messages is analogous to both signing S/MIME messages for end to end transfer over a store and forward message system and to the signed operation capability provided by Isode’s M-Vault product and described in the Isode white paper Directory Signed Operations.

Protocols for Security Labels

In order to support the functionality described above, it will be necessary to carry Security Labels in XMPP messages. There is currently no standard to do this.

It appears reasonably straightforward to extend XMPP to carry security labels, and a standard in this space seems highly desirable, perhaps based in the Internet Standard ESS Security Label format or an a future XML Security Label standard.

The Transverse XMPP client supports security labels using a straightforward mechanism, and Security Labels which is described in Common Information Sharing Standard for Information Security Marking: XML Implementation and the XML schema specified in http://www.niem.gov/IC-ISM-v2.xsd. This syntax is specific to US Government Security Policy, so is not appropriate for international standardization. This format and its use in Transverse is very useful to gain understanding of the issues associated with using Security Labels in XMPP.

Conclusions

This paper has shown how use of Security Label based controls can add significant value to an XMPP service, and enable its use in high security environments. Two models of applying Security Enforcing Functionality (SEF) are described. Isode believes that both models are important and plans to support both in its M-Link product. We will start with the Server model, as this provides more functionality than the Gateway model, including all of the functionality of the Gateway model.

There are currently no standards in this area, and development of agreed standards is an essential pre-requisite for wide inter-organizational deployment.

Isode welcomes feedback on the ideas presented in this paper.