[Standards] various rfc3920bis feedback
pavlix at pavlix.net
Tue Feb 24 18:17:43 UTC 2009
On Tue, 24 Feb 2009 10:20:15 +0000
Dave Cridland <dave at cridland.net> 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 :).
Freelance consultant and trainer
in networking, communications and security.
Jabber, Mail: pavlix(at)pavlix.net
More information about the Standards