XMPP Federation Clearinghouses

by Peter Saint-Andre

2012-01-06

Here's the problem: the traditional model for secure federation of XMPP servers assumes that the only policy decision required is checking of the certificate chain for a peer server. However, in some specialized communities (e.g., military networks, industry-specific networks or supply chains), additional policy concerns come into play (e.g., trust based on clearance levels or authentication methods used at remote domains, verified membership in a particular industry such as finance). Currently, server administrators might need to establish a connection policy and then whitelist peer servers that are within policy. Unfortunately, that approach is time-consuming and potentially error-prone.

One solution would be to establish a trusted "clearinghouse" that would make policy decisions with regard to XMPP federation within a specialized community. Although the details of the policy framework used by such a clearinghouse would be specific to the deployment and security requirements of the organizations involved, in essence there are two possible approaches: (1) the clearinghouse could define policies and push them out to the various server nodes on the network, with each node enforcing the policy on its own, or (2) the clearinghouse could act as a centralized lookup service for server federation, redirecting each server to its desired peer based on a policy engine internal to the clearinghouse.

Let's look a bit more closely at these two options.

  1. "Policy Push"

    In this model, the clearinghouse would define the policies but not enforce them. The policies might involve different levels, and each server administrator would need to configure their XMPP server to, say, allow connections to "Level 3" servers but not "Level 2" servers (where the levels would be defined by the federation authority). Instead of needing to maintain a whitelist, the server administrator would receive from the clearinghouse a lookup table that associates a level with each server on the network. Outbound federation requests would be allowed only with servers that are consistent with that server's local service policy. The benefits of this approach include less reliance on the centralized clearinghouse; the costs include the need for each service administrator to define its local service policy, as well as the need to modify existing XMPP server products to support checking of the lookup table before initiating outbound connections.

  2. "Redirection Service"

    In this model, the clearinghouse itself both defines the table and enforces the policies instantiated in that table. Every server on the network would be configured to perform outbound server connections by contacting the clearinghouse (this can be easily done in DNS by setting the highest-priority host for every server to be the clearinghouse). A server desiring to federate with its peer would connect to the clearinghouse and the clearinghouse would check its internal lookup table to determine if the connection from the server to the peer is allowed. If the connection is not allowed, the clearinghouse would return a standard XMPP "policy-violation" stream error to the server and the server would terminate the federation attempt. If the connection is in fact allowed, the clearinghouse would return a standard XMPP "see-other-host" stream to the server, and the server would continue the federation attempt by connecting to the peer at the IP address and port provided by the clearinghouse. The benefits of this approach include centralized administration, real-time updates to the lookup table, and the need to modify only one XMPP server (the one used to run the clearinghouse); the costs include a single point of failure for server federation (although this could be mitigated by defining the actual hostnames of peer servers as lower-priority hosts in DNS, so that servers would always attempt to contact the clearinghouse first).

I lean toward the second approach, but I'm still thinking about the problem space and the possibility of other solutions...


Peter Saint-Andre > Journal