On Tue, 24 Feb 2009 10:20:15 +0000 Dave Cridland <[email protected]> wrote:
> 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? "Impossible" is a very strong word for things that can happen :). > Dave. -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
