Bidders Library Interoperability Test and Evaluation - UC XMPP 2013.pdf

Department of Defense Unified Capabilities (UC) Extensible Messaging and

Presence Protocol (XMPP) 2013 (UC XMPP 2013) Change 1

June 2015

June 2015

The Office of the DoD Chief Information Officer

DEPARTMENT OF DEFENSE

UNIFIED CAPABILITIES EXTENSIBLE MESSAGING AND PRESENCE PROTOCOL 2013

(UC XMPP 2013) CHANGE 1

DoD UC XMPP 2013 Change 1 Changes Table i

XMPP 2013, Changes Table

VERSION REQ-ID CHANGE EFFECTIVE

DATE

Errata 1 Table 2.16-2. The following clarifications were added to Table 2.16-2:

Note: The XMPP MUC service SHALL permit authenticated users (both local and remote) to be appropriately granted the role of visitor, participate, and moderator.

Note: The XMPP MUC service SHALL permit authenticated users (both local and remote) to be appropriately granted privileges associated with the following affiliations: Owner, Admin, Member, and Outcast.

Immediate

Change 1 Section 2.4.2 Added a reference to GIG Technical Profile (GTP) 043 – XMPP IM/Chat Federation.

Immediate

Change 1 Section 2.6.1.1

Added text and Figure 2.2-2, XMPP Hostname Resolution Process.

Immediate

Change 1 IM-000012 New Requirement 18-month rule Change 1 IM-000014 New Requirement 18-month rule Change 1 IM-000016 New Requirement 18-month rule Change 1 IM-000715 New Requirement clarifying SASL behavior Immediate Change 1 IM-000720 Removed Immediate Change 1 IM-000730 Removed Immediate Change 1 IM-001320 Made “JID not found” error response optional Immediate Change 1 IM-001500 Made parting unavailable presence stanza optional Immediate Change 1 IM-001540 Made parting unavailable presence stanza optional Immediate Change 1 IM-001855 New Requirement to implement XEP-0106 to support

CAC-enabled XMPP clients.

Immediate

Change 1 Table 2.16-1 Added XEP-0106 to the list of mandatory XMPP Extensions to support CAC-enabled clients.

Added RFCs 6020, 6021 and 6022 for completeness.

Immediate

Change 1 The term “Information Assurance” has been changed to “cybersecurity” in accordance with DoD Instruction

8500.01 (March 2014).

Immediate

Table of Contents ii

TABLE OF CONTENTS

SECTION PAGE

Section 1 Near-Real-Time, Text-Based Messaging Products ...................................................... 1-1

1.1 Introduction ................................................................................................................ 1-1

1.2 UCR 2013 Document suite ........................................................................................ 1-1

Section 2 XMPP Requirements ................................................................................................... 2-1

2.1 Acknowledgement ..................................................................................................... 2-1

2.2 XMPP Solution Framework ....................................................................................... 2-1

2.3 Terminology ............................................................................................................... 2-3

2.4 Functional Summary .................................................................................................. 2-4

2.4.1 Client-to-Server Connections............................................................................ 2-4

2.4.2 Server-to-Server Connections ........................................................................... 2-5

2.5 XMPP Addressing ..................................................................................................... 2-5

2.6 XML Streams ............................................................................................................. 2-6

2.6.1 TCP Binding ..................................................................................................... 2-6

2.6.1.1 Hostname Resolution ............................................................................... 2-6

2.6.1.2 Standard, Default Port Values .................................................................. 2-9

2.6.1.3 Fallback Process ....................................................................................... 2-9

2.6.2 Stream Negotiation Overview ........................................................................... 2-9

2.6.3 Stream Features ............................................................................................... 2-10

2.6.4 Stream Restarts ............................................................................................... 2-11

2.6.5 Continuation and Completion of Stream Negotiation .................................... 2-11

2.6.6 Directionality .................................................................................................. 2-12

2.6.7 Closing a Stream ............................................................................................. 2-13

2.6.7.1 Closing a Stream Without a Stream Error ............................................. 2-13

2.6.8 Stream Attributes ............................................................................................ 2-13

2.6.8.1 Initial Streams ........................................................................................ 2-13

2.6.8.2 Response Streams .................................................................................. 2-14

2.6.9 Namespaces ..................................................................................................... 2-15

2.6.9.1 Streams Namespace ............................................................................... 2-15

2.6.9.2 Content Namespace ............................................................................... 2-15

2.6.10 Stream Errors .................................................................................................. 2-16

2.6.10.1 Stream Error Syntax and Defined Stream Error Conditions .................. 2-16

2.7 TLS and STARTTLS Negotiation ........................................................................... 2-17

2.7.1 STARTTLS Process........................................................................................ 2-17

2.7.2 Initiation of STARTTLS Negotiation ............................................................. 2-17 iii

2.7.3 STARTTLS Negotiation Fails ........................................................................ 2-17

2.7.4 TLS Negotiation.............................................................................................. 2-18

2.7.5 TLS Success .................................................................................................... 2-18

2.7.6 TLS Failure ..................................................................................................... 2-18

2.7.7 Order of TLS and SASL Negotiation ............................................................. 2-18

2.7.8 STARTTLS Failure Case ................................................................................ 2-19

2.8 Authentication and SASL Negotiation .................................................................... 2-19

2.8.1 Client-to-Server Streams ................................................................................. 2-19

2.8.2 Server-to-Server Streams ................................................................................ 2-21

2.8.3 SASL Failure .................................................................................................. 2-23

2.8.4 SASL Errors .................................................................................................... 2-23

2.9 Resource Binding ..................................................................................................... 2-23

2.9.1 Overview ......................................................................................................... 2-23

2.9.2 Resource Binding Process............................................................................... 2-24

2.9.2.1 Mandatory-to-Negotiate ......................................................................... 2-24

2.9.2.2 Advertising Support ............................................................................... 2-24

2.9.2.3 Server-Generated Resource Identifier .................................................... 2-24

2.9.3 Error Cases Associated With Server-Generated Resource Identifiers ............ 2-25

2.10 XML Stanzas ........................................................................................................... 2-25

2.10.1 Common Attributes ......................................................................................... 2-25

2.10.1.1 ‘to’ Attribute .......................................................................................... 2-25

2.10.1.2 ‘from’ Attribute ...................................................................................... 2-26

2.10.1.3 ‘id’ Attribute .......................................................................................... 2-27

2.10.1.4 ‘type’ Attribute ....................................................................................... 2-28

2.10.1.5 ‘xml:lang’ Attribute ............................................................................... 2-28

2.10.2 Basic Semantics .............................................................................................. 2-28

2.10.2.1 Message Semantics ................................................................................ 2-28

2.10.2.2 Presence Semantics ................................................................................ 2-29

2.10.2.3 IQ Semantics .......................................................................................... 2-29

2.10.3 Stanza Errors ................................................................................................... 2-30

2.10.4 Server Rules for Processing XML Stanzas ..................................................... 2-30

2.10.4.1 Rules for Processing XML Stanzas to Remote Domains ...................... 2-30

2.10.4.2 Rules for Processing XML Stanzas to Local Domain ........................... 2-31

2.11 Roster Management ................................................................................................. 2-32

2.11.1 Roster-Related Elements and Attributes ......................................................... 2-32

2.11.2 Roster-Related Methods.................................................................................. 2-33

2.11.3 Retrieving the Roster on Login ....................................................................... 2-36

2.11.4 Adding a Roster Item ...................................................................................... 2-37 iv

2.11.5 Updating a Roster Item ................................................................................... 2-38

2.11.6 Deleting a Roster Item .................................................................................... 2-39

2.12 Presence Subscription Management ........................................................................ 2-40

2.12.1 Subscription Requests ..................................................................................... 2-40

2.12.1.1 Rules for Client Generation of Outbound Subscription Requests ......... 2-40

2.12.1.2 Rules for Server Processing of Outbound Subscription Requests ......... 2-40

2.12.1.3 Rules for Server Processing of Inbound Subscription Requests ............ 2-42

2.12.1.4 Rules for Client Processing of Inbound Subscription Requests ............ 2-42

2.12.1.5 Rules for Server Processing of Outbound Subscription Approval ........ 2-43

2.12.1.6 Rules for Server Processing of Inbound Subscription Approval ........... 2-43

2.12.2 Cancelling a Subscription ............................................................................... 2-45

2.12.2.1 Rules for Client Generation of Subscription Cancellation .................... 2-45

2.12.2.2 Rules for Server Processing of Outbound Subscription Cancellation ... 2-45

2.12.2.3 Rules for Server Processing of Inbound Subscription Cancellation ...... 2-46

2.12.3 Unsubscribing ................................................................................................. 2-46

2.12.3.1 Rules for Client Unsubscribing .............................................................. 2-46

2.12.3.2 Rules for Server Processing of Outbound Unsubscribe ......................... 2-46

2.12.3.3 Rules for Server Processing of Inbound Unsubscribe ........................... 2-47

2.13 Exchanging Presence Information ........................................................................... 2-48

2.13.1 Initial Presence ................................................................................................ 2-48

2.13.1.1 Client Generation of Initial Presence ..................................................... 2-48

2.13.1.2 Server Processing of Outbound Initial Presence .................................... 2-48

2.13.1.3 Server Processing of Inbound Initial Presence ...................................... 2-48

2.13.1.4 Client Processing of Inbound Initial Presence ....................................... 2-49

2.13.2 Presence Probes .............................................................................................. 2-49

2.13.2.1 Server Generation of Outbound Presence Probe ................................... 2-49

2.13.2.2 Server Processing of Inbound Presence Probe ....................................... 2-50

2.13.3 Subsequent Presence Broadcasts .................................................................... 2-50

2.13.3.1 Server Processing of Outbound Presence .............................................. 2-51

2.13.3.2 Server Processing of Inbound Presence ................................................. 2-51

2.13.3.3 Client Processing of Inbound Presence .................................................. 2-51

2.13.4 Unavailable Presence ...................................................................................... 2-51

2.13.4.1 Client Generation of Unavailable Presence ........................................... 2-51

2.13.4.2 Server Processing of Outbound Unavailable Presence .......................... 2-52

2.13.4.3 Server Processing of Inbound Unavailable Presence ............................. 2-52

2.13.4.4 Client Processing of Inbound Unavailable Presence ............................. 2-52

2.13.5 Presence Syntax .............................................................................................. 2-53

2.13.5.1 Show Element ........................................................................................ 2-53 v

2.13.5.2 Status Element ....................................................................................... 2-53

2.13.5.3 Priority Element ..................................................................................... 2-54

2.14 Exchanging Messaging ............................................................................................ 2-54

2.14.1 One-to-One Chat Sessions .............................................................................. 2-54

2.14.2 Message Stanza Syntax ................................................................................... 2-55

2.14.2.1 To Attribute ............................................................................................ 2-55

2.14.2.2 Type Attribute ........................................................................................ 2-55

2.14.2.3 Body Element......................................................................................... 2-56

2.15 Conformance Requirements in RFC 6120 AND RFC 6121 .................................... 2-56

2.16 XMPP Extensions .................................................................................................... 2-56

2.16.1 Elevated/Clarified Requirements .................................................................... 2-57

2.17 XML Usage .............................................................................................................. 2-59

2.18 DIFFSERV Code Point (DSCP) Requirements ....................................................... 2-60

Section 3 Glossary of Abbreviations and Acronyms ................................................................... 3-1

List of Figures vi

LIST OF FIGURES

FIGURE PAGE

Figure 1.2-1 UCR 2013 Document Suite ............................................................................. 1-2 Figure 2.2-1. High-Level XMPP Solution Framework ........................................................ 2-2 Figure 2.2-2. XMPP Hostname Resolution Process ............................................................. 2-7

LIST OF TABLES

TABLE PAGE

Table 2.5-1. XMPP Addressing Examples .......................................................................... 2-6 Table 2.16-1. DoD XMPP Protocol Suite ........................................................................... 2-57 Table 2.16-2. Elevated/Clarified Requirements .................................................................. 2-58

Section 1

1-1

SECTION 1

NEAR-REAL-TIME, TEXT-BASED MESSAGING PRODUCTS

1.1 INTRODUCTION

The Unified Capabilities (UC) Extensible Messaging and Presence Protocol (XMPP) 2013 (UC XMPP 2013) defines functional requirements for XMPP for both client and server implementations. The primary objective of the UC XMPP 2013 is to create a well-defined and unambiguous set of requirements that facilitates multivendor interoperability and UC Approved Products List (APL) certification testing. In accordance with Department of Defense (DoD) Information Technology (IT) Standards Registry (DISR), this specification mandates the use of the XMPP in support of the following near-real-time, text-based messaging applications:

• Presence.

• One-to-one Chat.

• Multi-user Chat.

The term “near-real time” underscores the point that XMPP applications and services are generally used to enable the immediate interchange of information. The term “text-based” refers to the exchange of relatively brief text messages with individual contacts or services.

1.2 UCR 2013 DOCUMENT SUITE

This specification is one of several DoD documents that specify requirements for Assured Services networks and requirements for products to achieve DoD UC Approved Products List (APL) certification. The UC requirements documents that are included in the UCR scope are shown in Figure 1.2-1 and are included the following.

• UCR 2013: specifies the functional requirements, performance objectives and technical specifications.

• AS-SIP 2013: contains the requirements for the IP-based UC Signaling system.

• UC XMPP 2013: contains the requirements for multivendor interoperability as required to exploit the full potential of Instant Messaging (IM), Chat, and Presence across DoD.

• UC Framework 2013: specifies the descriptive text and design associated with each of the UCR 2013 sections.

The reference documents used are cited in UC Framework 2013, Appendix C, Definitions, Abbreviations and Acronyms, and References.

Section 1

1-2

Figure 1.2-1 UCR 2013 Document Suite

Section 2

2-1

SECTION 2

XMPP REQUIREMENTS

2.1 ACKNOWLEDGEMENT

The UC XMPP 2013 Specification is based on the following commercial standards:

• Request for Comments (RFC) 6120: Extensible Messaging and Presence Protocol (XMPP):

Core.

• RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence.

• RFC 6122: Extensible Messaging and Presence Protocol (XMPP): Address Format.

The UC XMPP 2013 Specification assumes that the reader is familiar with the general concepts and requirements defined in RFCs 6120, 6121, and 6122. For that reason, this specification does not attempt to cover all normative requirements addressed in these XMPP baseline documents.

Compliant solutions are expected to implement all requirements defined as “MUST,” “SHALL,” “REQUIRED,” “MUST NOT,” and “SHALL NOT” in RFCs 6120, 6121, and 6122. It is also expected that vendors will likewise implement requirements defined as “SHOULD” or “SHOULD NOT” except where there may exist valid reasons in particular circumstances to ignore a particular requirement. To better enable multivendor interoperability, some of the content defined as “SHOULD,” “RECOMMENDED,” “SHOULD NOT,” “NOT RECOMMENDED,” “MAY,” or “OPTIONAL” in RFCs 6120, 6121, and 6122 has been redefined by this specification to reflect requirement levels associated with the following terminology: “MUST,” “SHALL,” “REQUIRED,” “MUST NOT,” or “SHALL NOT.” In the event of a discrepancy between the commercial XMPP standards and the UC XMPP 2013 Specification, the explicit requirements defined in this specification take precedence.

A significant portion of the text of this specification has been derived from RFCs 6120, 6121, and 6122. For the sake of traceability, individual requirements are linked to a reference source by a bracketed section number and associated reference source identifier.

In addition to the core functionality specified in RFCs 6120 and 6121, the UC XMPP 2013 Specification also defines a minimum XMPP feature set that incorporates requirements from XMPP Extension Protocol (XEP) series documents plus a few additional Internet Engineering Task Force (IETF) RFCs. For further details, see Section 2.16, XMPP Extensions.

2.2 XMPP SOLUTION FRAMEWORK

XMPP is implemented using a client-server design. Commonly, the XMPP network consists of a number of interconnected servers. Each server operates as the “home” server for some number of locally connected clients (see Figure 2.2-1, XMPP Requirements).

2-2

Figure 2.2-1. High-Level XMPP Solution Framework

• An XMPP client must connect to its “home” server in order to be granted access to the network and subsequently to be permitted to exchange instant messaging (IM) and presence information with other users/services. After the client successfully negotiates and establishes a connection with its home server, the client then uses XMPP to communicate with its server, other clients, and any other entities (e.g., a multiuser chat service) on the network. More than one client can connect concurrently to the same home server on behalf of the same local or user account (Section 2.5, RFC 6120).

• An XMPP server manages eXtensible Markup Language (XML) streams with locally hosted clients and delivers XML stanzas to those clients over the negotiated streams. The server also manages XML streams with peer servers and routes XML stanzas to those servers over the negotiated streams. A server is responsible for the enforcement of security policies (e.g., user authentication and channel encryption), storing a user’s roster, and maintaining presence information for all of its hosted users. A server may also host local services that use XMPP communication primitives (e.g., multiuser chat service) (Section 2.5, RFC 6120).

For APL certification purposes, an XMPP System Under Test (SUT) shall consist of both an XMPP server and XMPP client. The one exception is XMPP gateway implementations (see the note below for further clarification).

NOTE: Proprietary client-to-server protocols are permitted within the context of a DoD Component enclave. However, these proprietary implementations must be able to federate with native XMPP servers by means of an XMPP server-to-server stream enabled through the use of an XMPP gateway implementation. Likewise, an XMPP

2-3 gateway must be able to federate with other XMPP gateways by means of an XMPP server-to-server stream. The XMPP gateway implementations are expected to comply with server-to-server stream-related requirements as defined in this specification. From an applications perspective, XMPP gateways must support Presence and one-to-one chat. However, it is understood that the majority of XMPP Gateway implementations will not be compliant with the following XMPP Extension: XEP-0045: Multi-User Chat.

2.3 TERMINOLOGY

• XML Stanza. An XML stanza is a discrete XML fragment that is sent over the transport provided by the negotiated XML stream. As defined in the XMPP baseline specification, an XML stanza is “the basic unit of meaning in XMPP” (Section 4.1, RFC 6120).

• Initiating Entity and Receiving Entity. When a client initiates a session with its home server, the client is designated as the “initiating entity” and the server is labeled the “receiving entity.” Likewise, when a server initiates a session with a peer server, the server originating the connection is designated as the initiating entity and the targeted peer server is labeled as the receiving entity (Section 1.4, RFC 6120).

• XML Stream. An XML stream provides the essential transport needed for all client-to-server and server-to-server communications. An XML stream acts as a logical envelope (i.e., container) for all the XML elements and XML stanzas exchanged between a client and server or between server peers. As discussed in RFC 6121, Section 4.3, an XML stream is always unidirectional, which means that XML stanzas can be sent in only one direction over the stream (either from the initiating entity to the receiving entity or from the receiving entity to the initiating entity). To enable communication between an initiating entity (i.e., a client or server) and a receiving entity (i.e., a server), the initiating entity will negotiate an XML stream to the receiving entity (the Initial Stream), and, in response, the receiving entity will negotiate an XML stream to the initiating entity (the Response Stream) (Section 4.1, RFC 6120).

• Contact. A contact is an entity that has a subscription to a user’s presence or to which a user has a presence subscription. In this specification, the term “contact” is also used in a less strict sense to refer to a potential contact, an item in a user’s roster, or the target of a particular message stanza or presence subscription request (Section 3, RFC 6121).

• Entity. In the context of this specification, an entity typically refers to a client or server implementation. However, in XMPP, an entity also could be a reference to a gateway, a service, or a chat room.

• Originating Entity. The entity (e.g., a client or server) that generates a stanza is referred to as the originating entity.

• Mandatory-to-Negotiate Stream Features. Mandatory-to-negotiate stream features refer to a set of particular protocol interactions that are mandatory for the initiating entity to complete

2-4 before the receiving entity will accept XML stanzas from the initiating entity (e.g., authentication and channel encryption) (Section 4.2.1, RFC 6120).

• Connected Resource. After successfully binding a resource to the XML stream, the client is referred to as a Connected Resource.

• Available Resource. After a connected resource sends initial presence, it is referred to as an Available Resource.

• Interested Resource. If a connected resource or available resource requests the roster, it is referred to as an Interested Resource.

• User. The term “user” commonly refers to the owner of an XMPP account. It is worth noting that a user may not necessarily be a natural person (e.g., it could be an automated process).

• Related Abbreviations:

– C = client.

– CC = contact’s client.

– CS = contact’s server.

– I = an initiating entity.

– R = a receiving entity.

– S = server.

– UC = user’s client.

– US = user’s server.

2.4 FUNCTIONAL SUMMARY

2.4.1 Client-to-Server Connections

As discussed previously, a client needs to connect to a server in order to be granted access to the network. The process used by a client to open, secure, and close an XML stream is as follows [Section 1.3, RFC 6120]:

1. Determine the hostname and port at which to connect.

2. Open a Transmission Control Protocol (TCP) connection.

3. Open an XML stream over TCP.

4. Negotiate Transport Layer Security (TLS) for channel encryption.

5. Authenticate using a Simple Authentication and Security Layer (SASL) mechanism.

6. Bind a resource to the stream (see Section 2.9, Resource Binding).

7. Exchange an unbounded number of XML stanzas with other entities on the network.

8. Close the XML stream.

9. Close the TCP connection.

2-5

2.4.2 Server-to-Server Connections

For server-to-server communications (also known as “federation”), an XMPP server must establish an XML stream with a peer server. This type of connection is also commonly abbreviated as (s2s). The process for establishing and terminating server-to-server connections is as follows (Section 1.3, RFC 6120):

1. Determine the hostname and port at which to connect.

2. Open a TCP connection.

3. Open an XML stream over TCP.

4. Negotiate TLS for channel encryption.

5. Authenticate using a SASL mechanism.

6. Exchange an unbounded number of XML stanzas both directly for the servers and indirectly on behalf of entities associated with each server (e.g., connected clients).

7. Close the XML stream.

8. Close the TCP connection.

For detailed guidance on XMPP federation reference GIG Technical Profile (GTP) 043 – XMPP IM/Chat Federation located on the GIG Technical Guidance portal at https://www.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development _List

2.5 XMPP ADDRESSING

All the basic elements (i.e., XMPP clients, servers, and associated services) of XMPP are addressable using a globally unique address. Generally, XMPP addresses are referred to as Jabber IDs (JIDs). Typically, a JID is made up of three parts within the following structure:

[localpart@domainpart/resourcepart].

• Domainpart. The domainpart of a JID is that portion after the “@” character (if any) and before the “/” character (if any); it is the primary identifier and is the only required element of a JID (a mere domainpart is a valid JID). Typically, a domainpart identifies the “home” server to which clients connect for XML routing and data management functionality.

However, it is not necessary for an XMPP domainpart to identify an entity that provides core XMPP server functionality (e.g., a domainpart can identify an entity such as a multiuser chat service or a user directory) (Section 2.2, RFC 6122).

• Localpart. The localpart of a JID is an optional identifier placed before the domainpart and separated from the latter by the “@” character. Typically, a localpart uniquely identifies the entity requesting and using network access provided by a server (i.e., a local account).

However, the localpart of a JID can also represent other kinds of entities (e.g., a chat room

2-6 associated with a multiuser chat service). The entity represented by an XMPP localpart is addressed within the context of a specific domain (Section 2.3, RFC 6122).

• Resourcepart. The resourcepart of a JID is an optional identifier placed after the domainpart and separated from the latter by the “/” character. A resourcepart can modify either a <localpart@domainpart> address or a mere <domainpart> address. Typically a resourcepart uniquely identifies a specific connection (e.g., a device or location) or object (e.g., an occupant in a multiuser chat room) belonging to the entity associated with an XMPP localpart at a local domain (Section 2.4, RFC 6122).

An address of the form [localpart@domainpart] is referred to as a bare JID. An address of the form [localpart@domainpart/resourcepart] is referred to as a full JID. Table 2.5-1, XMPP Addressing Examples, provides a few examples.

Table 2.5-1. XMPP Addressing Examples

XMPP

ENTITY

FORMAT EXAMPLE

Server Consisting of a single domainpart identifier. “chat.dco.dod.mil”

User Account Consisting of a localpart and domainpart separated by the “@” character.

“john.smith@chat.dco.dod.mil”

Specific Client Connection

Consisting of a localpart, domainpart and resourcepart, where the localpart is separated from the domainpart by the “@” character and the domainpart is separated from the resourcepart by the “/” character.

“john.smith@conference.chat.dco.dod.mil/XMPP Desktop Client”

2.6 XML STREAMS

As mentioned previously, an XML stream provides the fundamental transport needed for all client-to-server and server-to-server communications. The ability to establish and maintain an XML stream is an essential capability of XMPP.

2.6.1 TCP Binding

IM-000010 [Required] As XMPP is defined in this specification, an initiating entity SHALL open a TCP connection to the receiving entity before it negotiates XML streams with the receiving entity. The parties then maintain that TCP connection for as long as the XML streams are in use (Section 3.1, RFC 6120).

2.6.1.1 Hostname Resolution

When a given XMPP domain is established, the proper DNS records are essential for proper client-to-server and server-to-server operation. An XMPP domain can exist independently from a particular network, server hostname, or Active Directory domain but needs the proper DNS records. For example, an XMPP domain named “xmpp.uc.mil” can be hosted on a server with a

2-7 hostname of “xmppserver1.uc.mil.” Initially a DNS SRV record must be created based on the format established in RFC 6120. This record will identify an XMPP service and if queried with return the hostname of the XMPP server hosting this XMPP domain. The DNS SRV record can result in more than one hostname and records can be weighted to provide the necessary load balancing.

The DNS SRV query for “xmpp.uc.mil” would return the server hostname (FQDN) “xmppserver1.uc.mil” and could then be queried during a common A record DNS lookup. DNS is queried to determine the IP address of the hostname and normal application operation can take place.

For XMPP “add-on” services such as multi-user chat (MUC), typically the MUC service is given a subdomain for example “chat.xmpp.uc.mil.” The MUC conference service must be defined in DNS in a similar manner as the core XMPP service. “chat” must be created as a subdomain and then the appropriate SRV and A records must be created. If the MUC service is located on the same server, the SRV record could be set up with the same hostname result.

Figure 2.2-2 summarizes the two step process for fundamental XMPP name resolution.

Figure 2.2-2. XMPP Hostname Resolution Process

IM-000012 [Required] A DNS Server (Enclave) shall be configured by adding SRV records for C2S and S2S connections in the following format:

Example SRV records:

Format: _service._proto.name. TTL class SRV priority weight port target.

Client: _xmpp-client._tcp.im.example.mil. 18000 IN SRV 0 0 5222 host1.example.mil.

Server: _xmpp-server._tcp.im.example.mil. 18000 IN SRV 0 0 5269 host1.example.mil.

Where im.example.mil is the XMPP domain, 18000 is the time to live, IN is the DNS class (always IN), 0 is the priority of the target host, 0 is the weight relative to other records with the

2-8 same priority, 5222 or 5269 are the ports where the service is found, host1.example.mil is the hostname of the service

IM-000014 [Required] XMPP add-on services such as multi-user chat (MUC) shall have their own DNS records established (SRV and A/AAAA) and should be included as additional entries in the certificate’s SAN.

IM-000016 [Required] XMPP multi-user chat services shall use the service name “chat” as a standard to streamline discovery of an XMPP service’s MUC service.

Because XML streams are sent over TCP, the initiating entity needs to determine the IPv4 or IPv6 address (and port) of the receiving entity’s “origin domain” before it can attempt to connect to the XMPP network (Section 3.2, RFC 6120).

IM-000020 [Required] When a server receives a stanza and the JID contained in the “to” attribute does not match one of the configured hostnames of the server itself, the server SHALL attempt to route the stanza to the remote domain. If no server-to-server stream exists between the two domains, the sender’s server SHALL attempt to resolve the remote hostname using a Domain Name Service (DNS) Service record query (DNS SRV query) of “xmpp-server” (for server-to-server connections) (Section 10.4 of RFC 6120).

IM-000030 [Required] To discover the hostname of the XMPP service in a given domain, XMPP clients SHALL use the same hostname resolution process. However, the Service identified in the DNS SRV query will be “xmpp-client” (for client-to-server connections).

NOTE: It is not necessary to resolve the DNS domain name before each connection attempt, because DNS resolution results can be cached temporarily in accordance with time-to-live values (Section 13.9.2, RFC 6120).

IM-000040 [Required] All server and client implementations SHALL support this hostname resolution process as follows (Section 3.2.1, RFC 6120):

a. The initiating entity SHALL construct a DNS SRV query (see RFC 2782) where inputs are as follows:

i. A service of “xmpp-server” for server-to-server connections (or alternatively, “xmpp-client” for client-to-server connections).

ii. A proto of “tcp.”

iii. A name corresponding to the “origin domain” of the XMPP service to which the initiating entity wishes to connect (e.g., “example.disn.mil”).

b. The result is a query such as “_xmpp-server._tcp.example.disn.mil.” (or alternatively, “_xmpp-client._tcp.exmple.disn.mil.” for client-to-server connections).

c. If a response is received, it will contain one or more combinations of a port and hostname, each of which is weighted and prioritized as described in RFC 2782.

2-9

d. The initiating entity SHALL choose one of the returned hostnames to resolve (following the rules in RFC 2782), which it SHALL do by using a DNS “A” or “AAAA” lookup on the hostname; this will result in an IPv4 or IPv6 address.

e. The initiating entity SHALL use the Internet Protocol (IP) address from the first successfully resolved hostname (with the corresponding port number returned by the SRV lookup) as the connection address for the receiving entity.

f. If the initiating entity fails to connect using that IP address, but the “A” or “AAAA” lookup returned more than one IP address, then the initiating entity SHALL use the next resolved IP address for that hostname as the connection address.

g. If the initiating entity fails to connect using all resolved IP addresses for a given hostname, then it repeats the process of resolution and connection for the next hostname returned by the SRV lookup.

h. If the initiating entity fails to connect using any hostname returned by the SRV lookup, then it either SHALL abort the connection attempt or SHALL use the fallback process described in the following section.

2.6.1.2 Standard, Default Port Values

The standard default XMPP port for client-to-server connections is 5222. The standard default XMPP port for server-to-server connections is 5269.

2.6.1.3 Fallback Process

IM-000050 [Required] The fallback process SHALL be a normal “A” or “AAAA” address record resolution to determine the IPv4 or IPv6 address of the origin domain, where the port used is the “xmpp-client” port of 5222 for client-to-server connections or the “xmpp-server” port 5269 for server-to-server connections (Section 3.2.2, RFC 6120).

NOTE: If the initiating entity has been explicitly configured to associate a particular hostname (and potentially a port value) with the origin domain of the receiving entity, the initiating entity SHOULD use the configured name instead of performing the DNS SRV resolution process on the origin name. Naturally, if the initiating entity has knowledge (e.g., through the configuration process) of the IP address and port of the receiving entity, then there is no reason to perform hostname resolution (Section 3.2.3, RFC 6120).

2.6.2 Stream Negotiation Overview

To establish an XML stream, the initiating entity (e.g., client or server) and the receiving entity (e.g., a server) shall agree on a set of preconditions for connecting as a client or as a peer server.

The entities involved will begin the process of stream negotiation. In this process, the receiving entity for a stream will impose certain conditions upon the connection. For example, when a

2-10 client attempts to establish an XML stream with its home server, it will first open a persistent TCP connection and then begin the process of stream negotiation. Through an exchange of XML elements with the client, the server will inform the client regarding what stream features it supports. The server will specify whether a particular stream feature is required or optional. As a result, the stream negotiation process permits the server to enforce important preconditions (e.g., user authentication and channel encryption) upon the connection. Stream negotiation is a multistage process (Section 4 of RFC 6120).

2.6.3 Stream Features

IM-000060 [Required] The initiating entity SHALL initiate an XML stream by sending an initial stream header to the receiving entity.

C: <stream:stream from='john@im.example1.dod.mil' to='im.example1.dod.mil' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>

IM-000070 [Required] In response, the receiving entity SHALL send a response stream header to the initiating entity.

S: <stream:stream from='im.example1.dod.mil' id='t7AMCin9zjMNwQKDnplntZPIDEI=' to='john@im.example1.dod.mil' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'

IM-000080 [Required] After the receiving entity has sent a response stream header to the initiating entity, the receiving entity SHALL send a <features/> child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any conditions for continuation of the stream negotiation process. Each condition takes the form of a child element of the <features/> element, qualified by a namespace that is different from the streams namespace and the content namespace. The <features/> element can contain one child, contain multiple children, or be empty [Section 4.2.2, RFC 6120]. The initiating entity SHALL be capable of handling a <features/> element that contains one child or contains multiple children or that is empty.

2-11

IM-000090 [Required] For stream features that are mandatory-to-negotiate, the definition of that feature SHALL declare that the feature is always mandatory-to-negotiate (e.g., this is true of resource binding for XMPP clients) or the receiving entity SHALL explicitly flag the feature as mandatory-to-negotiate (e.g., this is done for TLS by including an empty <required/> element in the advertisement for the STARTTLS feature) (Section 4.2.2, RFC 6120).

R: <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>

<required/> </starttls>

</stream:features>

IM-000100 [Required] If the <features/> element contains at least one mandatory feature, then the initiating entity SHALL continue with the stream negotiation process. An empty <features/> element indicates that the stream negotiation is complete and that the initiating entity is cleared to send XML stanzas (Section 4.2.2, RFC 6120).

R: <stream:features/>

NOTE: A <features/> element that contains only voluntary features indicates that the stream negotiation is complete and that the initiating entity is cleared to send XML stanzas.

However, the initiating entity MAY negotiate further features if desired (Section 4.2.2, RFC 6120).

2.6.4 Stream Restarts

IM-000110 [Required] On successful negotiation of a feature that necessitates a stream restart, both the initiating entity and the receiving entity SHALL consider the previous stream to be replaced, but SHALL NOT terminate the underlying TCP connection; instead, the initiating entity and the receiving entity SHALL reuse the existing connection (Section 4.2.3, RFC 6120).

IM-000120 [Required] The initiating entity then SHALL send a new initial stream header to the receiving entity (Section 4.2.3, RFC 6120).

IM-000130 [Required] When the receiving entity receives the new initial stream header, it SHALL generate a new stream ID (instead of reusing the old stream ID) and SHALL then send a new response stream header to the initiating entity (Section 4.2.3, RFC 6120).

2.6.5 Continuation and Completion of Stream Negotiation

IM-000140 [Required] The receiving entity SHALL send an updated list of stream features to the initiating entity after a stream restart (Section 4.2.4, RFC 6120).

NOTE: The list of updated features MAY be empty if there are no further features to be advertised (Section 4.2.4, RFC 6120).

2-12

IM-000150 [Required] The receiving entity SHALL indicate completion of the stream negotiation process by sending to the initiating entity either an empty <features/> element or a <features/> element that contains only voluntary features. Once stream negotiation is complete, the initiating entity is cleared to send XML stanzas over the stream for as long as the stream is maintained by both parties (Section 4.2.5, RFC 6120).

R: <stream:features/>

NOTE: A <features/> element that contains only voluntary features indicates that the stream negotiation is complete and that the initiating entity is cleared to send XML stanzas, but that the initiating entity MAY negotiate further features if desired (Section 4.2.5, RFC 6120).

NOTE: At this point in the stream negotiation process, the initiating entity SHALL be capable of processing either an empty <features/> element or a <features/> element that contains only voluntary features.

2.6.6 Directionality

An XML stream is always unidirectional, by which is meant that XML stanzas can be sent in only one direction over the stream (either from the initiating entity to the receiving entity or from the receiving entity to the initiating entity) (Section 4.3, RFC 6120).

IM-000160 [Required] For client-to-server sessions, a server SHALL allow a client to use “two streams over a single TCP connection.”

IM-000170 [Required] For server-to-server sessions, the two server peers SHALL use two streams over two TCP connections, where one TCP connection is used for the stream in which stanzas are sent from the initiating entity to the receiving entity and the other TCP connection is used for the stream in which stanzas are sent from the receiving entity to the initiating entity (Section 4.3, RFC 6120)

NOTE: This concept of directionality applies only to stanzas and explicitly does not apply to other first-level children of the stream root, such as elements used for TLS negotiation, SASL negotiation. In particular, during establishment of a server-to-server session, while completing STARTTLS negotiation and SASL negotiation, the two servers would use one TCP connection, but after the stream negotiation process is finished, that original TCP connection would be used only for the initiating server to send XML stanzas to the receiving server. In order for the receiving server to send XML stanzas to the initiating server, the receiving server would need to reverse the roles and negotiate an XML stream from the receiving server to the initiating server over a separate TCP connection (Section 4.3, RFC 6120).

2-13

2.6.7 Closing a Stream

2.6.7.1 Closing a Stream Without a Stream Error

IM-000180 [Required] Client and server implementations SHALL be capable of closing an XML stream by sending a closing </stream> tag (Section 4.4, RFC 6120).

S: </stream:stream>

NOTE: The entity that sends the closing stream tag SHOULD behave as follows (Section 4.4, RFC 6120):

a. Wait for the other party to close also its stream before terminating the underlying TCP connection (this gives the other party an opportunity to finish transmitting any data in the opposite direction before the TCP connection is terminated).

b. Refrain from initiating the sending of further data over that stream but continue to process data sent by the other entity (and, if necessary, react to such data).

c. Consider both streams to be void if the other party does not send its closing stream tag within a configurable amount of time.

d. After receiving a reciprocal closing stream tag from the other party or waiting a configurable amount of time with no response, the entity SHALL terminate the underlying TCP connection.

IM-000190 [Required] After the entity that sent the first closing stream tag receives a reciprocal closing stream tag from the other party, it SHALL terminate the underlying TCP connection or connections (Section 4.4, RFC 6120).

2.6.8 Stream Attributes

2.6.8.1 Initial Streams

IM-000200 [Required] For client-to-server connections, it is assumed that the client knows the associated XMPP account name of the form <localpart@domain>. The client SHALL include the “from” attribute in the initial stream header it sends to the server and SHALL set the value to the associated XMPP account name of the form <localpart@domain> (Section 4.6.1, RFC 6120).

IM-000210 [Required] For server-to-server connections, the initiating entity SHALL include the “from” attribute in the initial stream header it sends to the receiving entity and SHALL set its value to a hostname serviced by the initiating entity (Section 4.6.1, RFC 6120).

IM-000220 [Required] For both client-to-server and server-to-server connections, the initiating entity SHALL include the “to” attribute in the initial stream header that it sends to the receiving entity and SHALL set its value to a hostname that the initiating entity knows or expects the receiving entity to service (Section 4.6.2, RFC 6120).

2-14

NOTE: For both client-to-server and server-to-server connections, the initiating entity SHOULD include an “xml:lang” attribute in the initial stream headers that it generates (Section 4.6.4, RFC 6120).

IM-000230 [Required] For both client-to-server and server-to-server connections, the initiating entity SHALL include a “version” attribute whose value is “1.0” (or higher) in the initial stream headers it generates (Section 4.6.5, RFC 6120).

Example:

C: <stream:stream from='john@im.example1.dod.mil' to='im.example1.dod.mil' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>

2.6.8.2 Response Streams

IM-000240 [Required] For both client-to-server and server-to-server connections, the receiving entity SHALL include the “from” attribute in the response stream header that it sends to the initiating entity and SHALL set its value to a hostname serviced by the receiving entity (Section 4.6.1, RFC 6120).

IM-000250 [Required] For response stream headers in client-to-server communication, if the client included a “from” attribute in the initial stream header then the server SHALL include a “to” attribute in the response stream header and SHALL set its value to the bare JID specified in the “from” attribute of the initial stream header. If the client did not include a “from” attribute in the initial stream header then the server SHALL NOT include a “to” attribute in the response stream header (Section 4.6.2, RFC 6120).

IM-00…