On Tue, 24 Feb 2009 11:10:38 +0100 Philipp Hancke <fi...@goodadvice.pages.de> 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. Aren't we discussing a possible change.... optional stream feature for 3920bis? That bidi feature is not included in 3920/3920bis is not a good reason not to include it there. Note that I don't particularly advocate using it.... but there are people who believe it would help. And it's OPTIONAL, no harm to servers that don't implement 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. Please provide more specific info about how to fix it in bis and if/why it is broken now. > > > 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) This looks lie the best way to me. It allows you to authenticate the server as all virtuals it provides. This seems to be the most natural way of multiplexing. > 2) do 0178 for the first authorization and use piggybacking (with > graceful failure again) for subsequent authorization... err... > verification I don't see how you would use piggybacking/multiplexing for authentication/authorization/verification. > 3) ignore any 0178 offers and do piggybacking for everything. > Might be a problem if servers require 0178 and really mean it. IMO bad idea in current environment... and not sure about the future. It feels better to do no piggybacking/multiplexing at all than requiring it to me. > > 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/> -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
