[xmppwg] Summary of s2s issues

Justin Karneges 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 mailing list