Using Security Labels to Control Message Flow in XMPP Services

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 the whitepaper [Access Control using Security Labels & Security Clearance] which gives a summary of how Security Labels and Security Clearances work and on the Isode Security Policy, Security Label and Security Clearance Infrastructure & Management product page, which 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 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 a 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 defining 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 a number of XMPP systems using Security Labels that Isode is aware of, and in particular by the TransVerse system from JFCOM.

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.

This model is standardized in XEP-0258 “Using Security Labels in XMPP”, which defines a mechanism to associate security labels with XMPP messages, including ESS Labels standardized in RFC 2634 “Enhanced Security Services for S/MIME”. XEP-0258 also allows display information to be carried with Security Labels and allows an XMPP client to discover a set of labels that may be used for a specific destination. The following screenshot shows the Swift XMPP client operating according to XEP-0258 against an Isode M-Link User Server multi-user chatroom.

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 can 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. 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

Access to presence information is controlled through presence subscription mechanisms, either by roster mechanisms for individual presence information or by chat room subscriptions for chat room presence information. These subscription mechanisms may be subjected to security label/clearance checks and through these checks limit who can see presence updates. Control based on subscription allows leads to an approach where presence updates stanzas are not expected carry sensitive information. This avoids the significant technical difficulties (finer grain labelling and authorization checks as well as special XMPP processing rules) that would arise from applying access control to presence update.

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

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.

Protocols for Security Labels

Protocols as key for interoperability. A key standard is XEP-0258 “Using Security Labels in XMPP”, which defines a mechanism to associate security labels with XMPP messages, including ESS Labels standardized in RFC 2634 “Enhanced Security Services for S/MIME”. XEP-0258 also allows display information to be carried with Security Labels and allows an XMPP client to discover a set of labels that may be used for a specific destination.

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”. 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. The server model is supported in M-Link products. Isode plans to support the gateway model in a future product. XEP0258 (Security Labels in XMPP) is a key standard in this area, which Isode supports in M-Link.