Summary

  • XMPP treated successful TLS and SASL negotiation as boundaries that replaced the current XML stream without normally closing it or terminating the underlying TCP connection.
  • A new stream header, stream ID and feature advertisement described the new state. TCP continuity, encryption, peer authentication, SASL success, resource binding and permission to send stanzas remained separate facts.

A success element with a destructive consequence

Suppose an XMPP client has opened an XML stream to a server. The server advertises STARTTLS, the client asks to proceed and the TLS handshake succeeds. A conventional intuition says that the channel is now the same channel, only encrypted. XMPP gives a stricter answer: the TCP connection is the same, but the XML stream is not.

The initiating entity sends a fresh stream header over the encrypted connection. It does not first send the closing tag that would normally end an XML stream. The receiver generates a new stream ID, replies with a new header and advertises the features appropriate to the protected state. The old stream has been replaced.

Authentication repeats the pattern. When the server emits SASL <success/>, that success terminates the usefulness of the stream in which the exchange occurred. The client opens another stream over the existing TCP connection. Only then does the server advertise what can happen after authentication, including resource binding where applicable.

This is an unusual kind of continuity. The transport remains alive precisely while the application protocol declares that its earlier context must not.

A connection and a stream were different clocks

RFC 6120 describes XMPP as an application profile of XML for near-real-time exchange. Its streams are application-layer objects. Strictly, each stream is unidirectional; two entities normally maintain a stream in each direction even though TCP itself carries traffic both ways.

That distinction matters during restart. The generic rule says that both parties consider the previous stream replaced, send no normal closing </stream> tag and do not terminate the underlying TCP connection. They reuse the connection, which may now have a different state because TLS is active. The initiator supplies a new opening header; the receiver supplies a new stream ID.

Calling this a reconnect loses the mechanism. A TCP reconnect would create a new transport association and encounter its own address, path, congestion and failure conditions. XMPP restart retains the transport while flushing the XML negotiation context. It is also not stream resumption, stanza replay or recovery of application delivery state. Those are different mechanisms with different evidence.

The protocol therefore had at least three clocks on one socket. TCP had a connection lifetime. TLS and SASL changed security or identity state at particular instants. Each XML stream generation had its own header, identifier, feature set and admissible operations. A green “connected” indicator could not accurately summarize all three.

Features were a staged permission surface

XMPP stream features were not a permanent catalogue of everything a server could ever do. They described the interactions available or required at a particular stage. A feature marked mandatory meant negotiation was incomplete; ordinary XML stanzas were not yet generally cleared. An empty feature set, or one containing only voluntary features, indicated that negotiation could be considered complete.

The order carried meaning. RFC 6120 describes the layers as TCP, then TLS, then SASL, then XMPP. The SASL mechanisms a server is willing to offer can depend on whether TLS has already been established. Resource binding is offered only after the client has authenticated. A feature list copied unchanged across transitions would erase these dependencies.

The restart forced a fresh advertisement. After the new header arrived, the receiving entity had to send an updated feature set. This made capability disclosure relative to current state rather than a promise inherited from an earlier, weaker context.

It also made absence bounded. Not seeing a feature in one generation did not prove that the implementation lacked it in every generation. It might not yet be eligible, might no longer be applicable or might be withheld by policy. RFC 7590 adds another caution: an attacker can strip the advertised STARTTLS feature or its required indication. A transcript is evidence of what appeared on that path, not an omniscient inventory of the peer.

TLS made old knowledge inadmissible

The TLS transition did more than encrypt subsequent bytes. RFC 6120 requires both parties, on success, to discard information learned insecurely above TCP before TLS took effect. The examples include an asserted from address, the old stream ID and the old feature list.

That rule gives the restart its deepest purpose. If the protected stream simply inherited everything from the unprotected one, an active intermediary could influence the supposedly secure session by modifying pre-TLS claims. New headers and features are not decorative repetition. They establish which statements survive in the new security context.

Even then, the evidence remains granular. TLS can protect the channel while peer authentication fails, is weak or is absent. RFC 7590 strengthens XMPP's TLS practice, requires clients to authenticate servers and servers to authenticate clients, and strongly prefers authentication between servers. It nevertheless discusses encrypted-but-unauthenticated server-to-server connections as distinct, weaker cases.

Thus “TLS succeeded” is not a complete identity statement. Operators need the version and parameters, certificate or other verification method, target identity, validation outcome and policy decision. The new stream says the protocol crossed a boundary. It does not excuse the observer from recording what the boundary actually established.

SASL success changed identity state, not every permission

RFC 4422 defines SASL as a framework through which connection-oriented protocols can use replaceable authentication mechanisms. The framework separates authentication identity, authorization identity, exchange outcome and any data-security layer a mechanism may negotiate. Mechanisms do not all produce identical properties.

XMPP profiles this framework inside XML. After SASL negotiation, the parties must restart the stream. On <success/>, the client opens a new stream on the existing TCP connection without sending the old closing tag. The receiver assigns a new stream ID and advertises whatever features are now available.

The distinction between authentication and authorization matters. SASL can establish who presented credentials and, where supported, the identity on whose behalf the entity seeks to act. It does not make every stanza permissible, bind a client resource automatically or prove that another endpoint will receive an application message.

For a client-to-server stream, resource binding remains mandatory after authentication. The server presents the binding feature only in the post-SASL stream. Before binding is complete, a client that tries to send a stanza to some other entity is not merely “early”; RFC 6120 requires the server not to process it and to close the stream with a not-authorized error.

Success was therefore deliberately incomplete. It ended one negotiation, changed the facts and exposed the next obligation.

The last mandatory step did not restart again

Resource binding attaches a resource identifier to the authenticated account and stream. It differentiates one connected resource from another. Yet RFC 6120 expressly says that the parties must not restart after binding.

This negative rule prevents a misleading generalization. XMPP did not restart whenever anything succeeded. TLS and SASL crossed boundaries where the security or identity context invalidated earlier stream knowledge. Binding completed a later stage inside the already authenticated stream. Its result changed addressing and stanza admission, but the specification did not require another flush.

The endpoint therefore needed a state machine, not a collection of success booleans. Before TLS, some advertised information was provisional. After TLS, SASL remained mandatory. After SASL, binding remained mandatory for clients. After binding, stanzas could enter the normal application path. Each transition had a different owner, failure surface and consequence.

This sequence also limits what a log can claim. A fresh stream ID is not a user ID. A bound resource is not a delivery receipt. A stanza accepted by the local server is not proof of remote application effect. The protocol makes progress observable without collapsing progress into outcome.

The 2004 design became an explicit replacement model

RFC 3920, published in October 2004, already required a new stream after successful TLS and after SASL <success/>. It specified the order TCP, TLS, SASL and XMPP, and treated the original stream as closed at those success points without requiring its closing tag.

RFC 6120 obsoleted that document in 2011. Its formulation made the general architecture clearer: reuse the existing connection, consider the earlier stream replaced, generate a new stream ID and resend features for the new stage. The change was not from “no restart” to “restart.” It was a more systematic account of why restart existed and what state had to be reconstructed.

RFC 7590 then strengthened the TLS environment in 2015 as the threat model evolved. It did not turn stream restart into proof of secure deployment. Instead, it reinforced the need to distinguish protocol choreography from certificate verification, downgrade resistance and operational policy.

The lasting lesson is modest but powerful. Continuity is not one thing. Keeping a transport connection can preserve efficiency. Replacing an application stream can preserve epistemic hygiene: facts learned under one set of protections do not silently acquire the authority of another.

Sources