Dave Cridland 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.
*nods* Indeed. I think we've reached the point where we need signalling
to enable it. And I defintiely think we need to enable it.
Why need?
There is a potential for problems here, such as servers which are not
reconnectible. But that is a problem with EXTERNAL already, where you
can send messages without being able to receive any.
* 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.
*nods* Agreed.
Luckily the last version of 220 already introduced the way to fix
that - without actually solving the problem :-)
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.
Yes, I think so too. In fact, we can elide the actual key if we know the
receiver won't ever use it.
I think sending the key always is the easier way, being more-or-less
backward compatible.
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.
I'm thinking we aim for (3), with signalling as required.
*nod*
Might be a problem if a server requires EXTERNAL, but this is rare in
uncontrolled environments anyway.
That would make 0178 c2s-only and it could be merged with 0257 somehow.
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.
Right - I don't expect this to be the case - I don't see what the point
would be - but I've not had the time to try this optimization out in the
field, yet.
"You're telling me the key is valid without checking it? Then you must
be lying."
I think dialback was not designed to protect from that anyway.
3) R: Connect to A
4) R2A: Establish TLS.
5) R2A: If A's certificate matches O's, goto ACCEPT
Nice optimization ;-)
It saves a round-trip or two.
6) R2A: <db:verify/>
7) A2R: <db:verify/>, goto ACCEPT
ACCEPT:
8) R2O: Authorize O as requested domain, send <db:result/>
Here's a question - if there is TLS involved (thus IP spoofing is, as I
udnerstand things, impossible), and the SRV records include the
originator, can we also elide the R2A session entirely?
There are two problems with that approach:
1) you do not know if the remote server is up and listening for
connections. See above.
2) an evil user on the remote system (other than the user who is
running the jabber server) who is able to open connection to
remote servers.
I do not think (2) is a real problem, especially not when certificates
are used.
Philipp
