[xmppwg] Summary of s2s issues
justin-keyword-jabber.093179 at affinix.com
Mon Feb 2 18:40:54 CST 2004
On Monday 02 February 2004 03:04 pm, Robert Norris wrote:
> It follows that if dialback or a SASL mechanism that does not allow
> for "mutual authentication" (ie both ends are authenticated to each
> other as part of the SASL handshake) is used, the resultant stream
> can only be used in a single direction; ie the originator of the
> stream may send, but the receiver may not send back on the same
> stream - they must establish a new stream seperately for this.
From our earlier discussion with Dave Smith, we concluded that dialback's
"one-way" behavior was not for security purposes, but rather it is an
implementation/deployment detail. For instance, a server might want to
provision two separate channels for input and output. This was one of the
key 'selling points' for keeping dialback in xmpp-core. The fact that this
feature is confined to Section 8 emphasizes that TLS/SASL s2s does not share
this one-way behavior.
'Mutual Authentication' is a different issue. If you don't have mutual auth,
then the whole channel, both directions of it, is insecure. If the target
has validated the initiator, but not the reverse, then not only should the
initiator not trust incoming data *from* the target, it should also not be
sending data *to* the target! Choosing whether or not to use 'mutual auth'
is simply a High Security provision and should not affect the protocol.
Personally, I consider a standard dialback scenario (A connects to B, and then
B connects to A for validation) to be 'mutually authed' in dialback terms,
which is basically just auth-by-DNS. The limitation of the final channel to
one-way is simply an artifact of dialback. Security/trust-wise, it makes no
I suggest that we confine any draft changes on this subject to only Section 8
(Dialback). The -core draft has recently been approved, and at this point I
think we should focus on simply clarifying Section 8 to reflect the real
world. I don't see a strong reason to change TLS/SASL s2s behavior.
> - Existing implementations of dialback implement an optimisation
> commonly referred to as "piggybacking". I will try to illustrate this
> scenario with an example from the real world.
> This method is used widely, and it really is necessary for
> backwards-compatibility that new implementations support it. I'm
> aware that it sounds complex, and its really difficult to describe
> without a diagram, but its not much extra to implement - it sort of
> falls out of a "standard" dialback implementation.
+1, this definitely needs to be documented for interoperability reasons.
> - The dialback examples don't have a 'version' attribute in the stream
> headers. Not important, just a slight omission.
And it would be version="1.0" ? I've wondered about this also. In the past
I've referred to the two types of s2s as "1.0" and "dialback". However, if
both are supposed to be considered "1.0", what is the proper terminology to
use for the newer s2s?
More information about the xmppwg