[Standards] various rfc3920bis feedback

Philipp Hancke fippo at goodadvice.pages.de
Tue Feb 24 10:10:38 UTC 2009


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.

>> * 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.

> 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)
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/>



More information about the Standards mailing list