Dave Cridland wrote:
On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote:
* bidirectional s2s could be announced in <stream:features> sent
right after the opening <stream> tag from the initiator.
Unidirectional S2S has been around for too long, I do not see a real
gain in fixing that now.
This was discussed in Feb 2004 on the XMPPWG list:
http://mail.jabber.org/pipermail/xmppwg/2004-February/002020.html
However, I have not seen bidirectional S2S in the last five years
and 3920bis (4.4) includes the consensus (?) that s2s is
unidirectional.
* connection reuse for multiple s2s links would be a very useful
feature, ask Dave for details
Piggybacking.
Which is subtly broken in RFC 3920 - at least 50% of it.
<host-unknown/> makes 'target piggybacking' (different to)
unusable, as you risk the entire stream.
What I'd like to do here is use the dialback elements as an
authorization request mechanism.
Dialback is 50% authorization request, 50% key verification.
Splitting it up accordingly simplifies the description.
In fact, by specifying how to do this without actually doing dialbacks,
but instead by verifying the identity of the sender based on the X.509
cert, we can actually get rid of SASL EXTERNAL and just use X.509 only,
which eliminates the difference between the "first" authorization and
subsequent ones.
There is no 'subsequent' auth with 0178 yet, is there?
There are three different options:
1) do 0178 and add subsequent auth (including graceful failure)
2) do 0178 for the first authorization and use piggybacking (with
graceful failure again) for subsequent authorization... err...
verification
3) ignore any 0178 offers and do piggybacking for everything.
Might be a problem if servers require 0178 and really mean it.
The dialback flow then becomes:
1) O2R : <db:result/>
2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT
Assumes that the originating server does not check with the
authoritative server that the receiving server has verified
the key.
3) R: Connect to A
4) R2A: Establish TLS.
5) R2A: If A's certificate matches O's, goto ACCEPT
Nice optimization ;-)
6) R2A: <db:verify/>
7) A2R: <db:verify/>, goto ACCEPT
ACCEPT:
8) R2O: Authorize O as requested domain, send <db:result/>
