XML Guard Application Profiles Overview

An application profile may have a set of optional rules associated with it, which specify prohibitions/constraints on messages that may be sent, which allow deployments to limit what is sent to a subset of the base messages allowed.

The XML guard will block any message which does not conform to the Application Profile and associated rules. Error reporting options may be specified as a part of the Application Profile. Two example M-Guard Application Profiles use cases are:

1. Cross Domain XMPP, where an XML Guard pair is used to protect XMPP traffic over a secure boundary.
2. STANAG 5066 modem and ALE control, where an XML Guard pair is used to control data flow across a Red/Black boundary.

Application Profile Overview

Consider an application server communicating through an XML Guard to a peer, as shown above. The Application Profile defines the framework used by the XML Guard to constrain the service provided by the application servers across the boundary. The Application Profile can be looked at in two ways:

1. It defines the mandatory checks that the XML Guard makes on the traffic being sent by the application. The application profile may also define a set of optional checks which can be selected for a specific deployment. This is what the XML Guard is enforcing.
2. It defines behaviour of the application that is using the XML Guard. The model is that the application follows the Application Profile. In normal operation the XML Guard will let everything pass, because it follows the profile.

The Application profile is generic. It can be specified in a manner which is independent of both the XML Guard product and the Application product.

Why XML Guards?

XML Guards are used to constrain information flow across a boundary. This is a commonly used approach to information control for three reasons:

• XML gives a flexible way to express information, which means it can be used for a wide range of communication.
• XML gives fine-grained information structure, so that information can be broken into small well-defined elements.
• XML offers a wide range of options for expressing rules and syntax, so that an XML guard can use standard mechanisms for expressing what is allowed through.

Schema Compliance

An Application Profile defines the complete set of XML messages that are allowed. The core of an Application Profile is the XML Schema of these messages, usually specified as an XML Schema Definition.

Normalization

There are a number of details which are application specific, that usually make sense to specify as part of an Application Profile. These include:

• Prohibition of XML Comments. These do not add value to the application service, and may be used as a covert channel.
• Prohibit XML Processing Instructions. Generally a security risk.
• Use of Canonical XML. Canonical XML Version 1.1 is a typical choice. This simplifies rule specification and improves security, as well as preventing covert channel.
• Use fixed Unicode form, typically Normalized Form Composed (NFC). Same benefits as Canonical XML.

Rules

An Application Profile can also reference a set of rules associated with the Application Profile, that may be specified in conjunction with the Application Profile or elsewhere. These rules can further constrain the set of messages which are allowed, optionally with parameters. Rules might:

• Prohibit certain parts of the schema.
• Constrain certain parts of the schema (e.g., to limit size, number or value)

Rather than define a different Application Profile for each variant, Rules allows a specific deployment of an Application Profile to be configured to the requirements of that deployment.

This will ideally lead to a single Application Profile for a given application.