On 2/24/09 3:10 AM, 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.
That was an artifact of dialback. If we have mutual authentication via TLS+SASL then why not have a bidirectional s2s connection? >>> * 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. I'm not so sure about that. <host-unknown/> means you're trying to communicate with a domain that I don't host at my server. >> 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. As long as it's backwards-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 is no subsequent auth anywhere, yet. > 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/> It's still not clear to me what TLS+dialback really means. If you're going to do TLS, use real certs and then you can do authentication via SASL EXTERNAL. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
