Instant Messaging (IM) and Presence applications are of growing importance in secure environments such as Military and Government. The Internet Standard XMPP (eXtensible Messaging and Presence Protocol) is being widely adopted as the technology of choice.

There are a number of reasons why XMPP is the preferred choice for Military and Government:

• XMPP is the only open standards choice, providing server/server protocols, with client and server implementations from multiple vendors.
• An open standards client/server protocol enables use of different Web and desktop clients, allowing choice of client suitable to the specific application and avoiding vendor lock-in.

• Distributed deployment is important for:
  • Interoperability with partner organizations.
  • User partition for security reasons.
  • Survivability.

An open server/server protocol is essential to achieve this.

• XMPP provides a base for a wide range of capabilities that go beyond basic IM, and the XSF (XMPP Standards Foundation) is an open organization actively developing this functionality, specified in the XEP (XMPP Extension Protocol) series. There is active military and government involvement in XSF to meet future requirements. This includes:
  • Extended presence that provides additional user information and capabilities such as Geo-location.
  • White-boarding.
  • Direct user to user communication, for capabilities such as VOIP and file transfer.
  • Publish/Subscribe (“PubSub”), which gives a flexible information sharing capability.

Government and Military organizations usually use directory servers to hold user information. Benefits of this architecture:

• User information is shared with other applications.
• XMPP clients can use the same user authentication as other applications.
• Location independent user and server configuration is provided.
• Many related tools provide user and server administration.
• XMPP user profile information can be centrally controlled, which avoids duplication.
• XMPP user profile changes can be used to update the directory

Peer Security (Client/Server and Server/Server)

There are a number of security services that may be used for either client/server or server/server XMPP communication.

Use of client server architecture is important for IM security. The IM client will authenticate to the server. This will enable the server to:

1. Control messages and presence information from the client, to ensure this only goes to appropriate recipients.
2. Ensure that the client is only provided with information that the client is entitled to have.

A client/server architecture enables security controls to be managed on the server, and so places the majority of the security requirements onto the server. Given that there are less servers, and that servers can be managed centrally, this is a good thing.

An XMPP Client will bind to its own server, and server/server communication is used for remote users. This builds a trust chain, and so server/server security is critical. The XMPP protocols use common security capabilities for the client/server and server/server protocols.

Data Confidentiality & Integrity

Data confidentiality is important in many government and military environments. The XMPP protocols (server/server and client/server) support data confidentiality using TLS (Transport Layer Security).

Some high security environments specifically choose not to use data confidentiality for applications, for example to enable audit and monitoring. Where this is the case, TLS can be used with a NULL cipher suite (i.e., no data confidentiality), so that TLS can provide data integrity services and support the authentication services described next.

Strong Authentication

Use of Strong Authentication for peer authentication is desirable in high security environments, particularly for server to server authentication.

XMPP authentication is based on the Internet Standard SASL (Simple Authentication and Security Layer). This includes strong authentication based on X.509 using the SASL EXTERNAL mechanism, so that the XMPP application utilizes authentication done at the TLS level.

The XMPP community is strongly promoting use of strong authentication for server to server communication, as this is substantially better than the dial-back mechanism in common operational use.

Use of strong authentication is strongly recommended for server/server use in military and government deployments. It is also recommended for client/server use, where clients support strong authentication.

Password Authentication for Clients

Although strong authentication is desirable, in many situations it may be preferable to use password based authentication. In particular, password based authentication is supported by a large number of clients.  Where passwords are used, control of password quality and general use is important. This can be supported well using a directory back-end.

Multi-User Chat (MUC)

Multi-User Chat is critical to many XMPP deployments, in particular military, where sharing of information in groups (for example decisions on whether to engage) are made using MUC rooms. Support of MUC is a key feature for many XMPP deployments.

 

 

Overview:

 

The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. The technology pages provide more information about the various XMPP “building blocks”. Several books about Jabber/XMPP technologies are available, as well.

 

The core technology behind XMPP was invented by Jeremie Miller in 1998, refined in the Jabber open-source community in 1999 and 2000, and formalized by the IETF in 2002 and 2003, resulting in publication of the XMPP RFCs in 2004 (see the history page for more details).

 

(IETF Definition)  The Extensible Messaging and Presence Protocol (XMPP) is a protocol for streaming XML [XML] elements in order to exchange messages and presence information in close to real time.  The core features of XMPP are defined in Extensible Messaging and Presence Protocol (XMPP): Core [XMPP-CORE].  These features — mainly XML streams, use of TLS and SASL, and the <message/>, <presence/>, and <iq/> children of the stream root — provide the building blocks for many types of near-real-time applications, which may be layered on top of the core by sending application-specific data qualified by particular XML namespaces [XML-NAMES].  This memo describes extensions to and applications of the core features of XMPP that provide the basic functionality expected of an instant messaging (IM) and presence application as defined in RFC 2779 [IMP-REQS]. 

 

Although the core technology is stable, the XMPP community continues to define various XMPP extensions through an open standards process run by the XMPP Standards Foundation. There is also an active community of open-source and commercial developers, who produce a wide variety of XMPP-based software.

 

More:

 

Extensible Messaging and Presence Protocol (XMPP) is an open, XML-inspired protocol originally aimed at near-real-time, extensible instant messaging (IM) and presence information (e.g. buddy lists), but now expanded into the broader realm of message oriented middleware. It remains the core protocol of the Jabber Instant Messaging and Presence technology. Built to be extensible, the protocol has accumulated features over time such as Voice over IP and file transfer signaling.

 

Unlike most instant messaging protocols, XMPP is an open standard. Like e-mail, it is an open system where anyone who has a domain name and a suitable Internet connection can run his own Jabber server and talk to users on other servers. The standard server implementations and many clients are also free and open source software.

 

Strengths

 

Decentralization: The architecture of the XMPP network is similar to email; anyone can run his/her own XMPP server and there is no central master server.

 

Open standards: The Internet Engineering Task Force has formalized XMPP as an approved instant messaging and presence technology under the name of XMPP, and the XMPP specifications have been published as RFC 3920 and RFC 3921. No royalties are required to implement support of these specifications and their development is not tied to a single vendor.

 

History: XMPP technologies have been in use since 1998. Multiple implementations of the XMPP standards exist for clients, servers, components, and code libraries, with the backing of large companies such as Sun Microsystems and Google.

 

Security: XMPP servers may be isolated from the public Jabber network (e.g., on a company intranet), and robust security (via SASL and TLS) has been built into the core XMPP specifications. To encourage use of channel encryption, the XMPP Standards Foundation also runs an intermediate certification authority at xmpp.net offering free digital certificates to XMPP server administrators under the auspices of the StartCom Certification Authority (which is the root CA for the intermediate CA).

 

Flexibility: Custom functionality can be built on top of XMPP; to maintain interoperability, common extensions are managed by the XMPP Software Foundation.

 

XMPP applications beyond IM include network management, content syndication, collaboration tools, file sharing, gaming, and remote systems monitoring.

 

Weaknesses

 

Presence data overhead: With typically over 70% of XMPP inter-server traffic being presence data and close to 60% of it being redundantly transmitted, XMPP currently has a large overhead in delivering presence data to multiple recipients. New protocols are being researched to alleviate this problem.

Scalability: XMPP currently suffers from essentially the same redundancy problem also concerning multi-user chat and brokered publish/subscribe services such as JMS.  These two are to be addressed by new protocol extensions.[citation needed] Until deployed, large chat rooms produce a very large amount of overhead.

 

No binary data: The way XMPP is encoded as a single long XML document makes it impossible to deliver unmodified binary data. Therefore, file transfers use external protocols like HTTP. If unavoidable, XMPP also provides in-band file transfers by encoding all data using base64. Other binary data like encrypted conversations or graphic icons are embedded using the same method.

 

Connecting to other protocols:

 

Another useful feature of the XMPP system is that of transports, also known as gateways, which allow users to access networks using other protocols. This can be other instant messaging protocols, but also protocols such as SMS or E-mail. Unlike multi-protocol clients, XMPP provides this access at the server level by communicating via special gateway services running on a remote computer. Any user can “register” with one of these gateways by providing the information needed to log on to that network, and can then communicate with users of that network as though they were Jabber users. This means that any client which fully supports XMPP can be used to access any network for which a gateway exists, without the need for any extra code in the client and without the need for the client to have direct access to the Internet. This may violate terms of service on the protocol used; however, such terms of service are not legally enforceable in several countries.

 

XMPP and HTTP

 

Another aspect of XMPP is the HTTP binding for users behind restricted firewalls. In the original specification, XMPP could use HTTP in two ways: polling and binding. Polling is now deprecated, but HTTP polling essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP ‘GET’ and ‘POST’ requests. With binding, the client uses longer-lived HTTP connections to receive messages as soon as they are sent. This push-model of notification is more efficient than polling, where many of the polls return no new data.

 

Because the client uses HTTP, most firewalls allow clients to fetch and post messages without any hindrances. Thus, in scenarios where the TCP port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. There also are various websites which allow people to sign in to Jabber via their browser. Furthermore, there are open public servers, such as www.jabber80.com that listen on standard http (port 80) and https (port 443) ports and hence allow connections from behind most firewalls.