From 9a6d14e6c4da0737f863df63d074df6b194de8fd Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Mon, 17 Oct 2016 10:20:09 -0500 Subject: [PATCH] XEP-0288: Fix syntax highlighting Also tweak example formatting --- xep-0288.xml | 227 +++++++++++++++++++++++++++++---------------------- 1 file changed, 129 insertions(+), 98 deletions(-) diff --git a/xep-0288.xml b/xep-0288.xml index c010f4a4..79421dac 100644 --- a/xep-0288.xml +++ b/xep-0288.xml @@ -27,6 +27,12 @@ &fippo; &dcridland; + + 1.0.1 + 2016-10-17 + ssw +

Fix syntax highlighting and tweak example formatting.

 + 1.0 2013-09-26 @@ -106,7 +112,8 @@ http://www.ietf.org/mail-archive/web/xmpp/current/msg00664.html

To enable bidirectional communication, the connecting server sends a <bidi/> element qualified by the 'urn:xmpp:bidi' namespace. This SHOULD be done before either SASL negotiation or Server Dialback.

+ + ]]>

After enabling bidirectionality, the connecting server continues to authenticate via SASL or requests to send stanzas for a domain pair with Server Dialback. The receiving server MUST NOT send stanzas to the peer before it has authenticated via SASL, or the peer's identity has been verified via Server Dialback. Note that the receiving server MUST NOT attempt to verify a dialback key on the same connection where the corresponding request was issued.

Also note that the receiving server MUST only send stanzas for which it has been authenticated - in the case of TLS/SASL based authentication, this is the value of the stream's 'to' attribute, whereas in the case of Server Dialback this is the inverse of any domain pair that has been used in a dialback request.

@@ -116,108 +123,132 @@ C:

This section shows two complete examples of bidirectional streams, the first example uses SASL EXTERNAL, the second uses Server Dialback.

-S: -S: - - - -C: -S: -C: -S: -S: - - EXTERNAL - - - -C: - - Y2FwdWxldC5saXQ= -S: -C: -S: -S: - -C: -S: + + + + + + + + + + + + + + + + + + + + EXTERNAL + + + + + + + Y2FwdWxldC5saXQ= + + + + + + + + + + + + + ]]> -S: -S: - - - -C: -S: -C: -S: -S: - - - - ]]> - - - e3f5cf21f12749ef2cf59269bc0118f35bc46b26 -S: - -C: -S: -S: - 1bac3ef56fed987cfe098c9785c654a5476ed765 - -C: - + + + + + + + + + + + + + + + + + + + + +]]> + + + + e3f5cf21f12749ef2cf59269bc0118f35bc46b26 + + + + + + + + + 1bac3ef56fed987cfe098c9785c654a5476ed765 + + + + ]]> -

This specification introduces no security considerations above and beyond those discussed in RFC 6120 or XEP-0220. +

This specification introduces no security considerations above and beyond those discussed in RFC 6120 or XEP-0220. Note that the impact of the "unsolicited server dialback" attack described in XEP-0220 is considerably larger for bidirectional streams, e.g. a vulnerability which allows spoofing might also route messages to the wrong targets. Additionally, dialback elements with a "type" attribute also need to be handled in incoming connections.