On Tue Feb 24 10:10:38 2009, Philipp Hancke wrote:
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.
*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.
* 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.
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.
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.
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.
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?
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
