[Standards] various rfc3920bis feedback

Pavel Simerda 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 :).

> Dave.


-- 

Freelance consultant and trainer
in networking, communications and security.

Web: http://www.pavlix.net/
Jabber, Mail: pavlix(at)pavlix.net
OpenID: pavlix.net



More information about the Standards mailing list