On Tue Feb 24 11:05:50 2009, Philipp Hancke wrote:
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.
*nod*
Might be a problem if a server requires EXTERNAL, but this is rare
in
uncontrolled environments anyway.
That would make 0178 c2s-only and it could be merged with 0257
somehow.
That's possible. But then, 0178 should get merged with rfc3920bis.
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.
"You're telling me the key is valid without checking it? Then you
must
be lying."
But it makes no sense. If the remote end doesn't validate the key,
but authorizes you anyway, then you're authorized, and it doesn't
matter whether or not you think they did it right.
I think dialback was not designed to protect from that anyway.
Protect from what?
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?
There are two problems with that approach:
1) you do not know if the remote server is up and listening for
connections. See above.
2) an evil user on the remote system (other than the user who is
running the jabber server) who is able to open connection to
remote servers.
I do not think (2) is a real problem, especially not when
certificates
are used.
If a trustworthy certificate is used, then we don't need to dialback,
certainly. (And trustworthy can mean "we've dialled back before and
we know this one"). Without that, then scenario (2) is possible.
So it's not really worth persuing that one.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
