Peter Saint-Andre wrote:
[snip]
How does the initiator discover that without running into the error?
DNS does not work even in the same domain.
I don't follow.
See the other part of the thread.
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.
It is merely a different way of describing it. The protocol already
contains this split:
db:result (authorization part)
db:verify (key verification).
Sure, if it helps to describe things that way, then let's update the
description. :)
Already in your inbox. Unfortunately, I am unable to judge if it really
helps... and getting feedback on s2s topics is quite hard.
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 is piggybacking :-p
Dialback is not an authentication protocol.
Shortening "authorization" to "auth" was a bad idea (-:
Let's wait for Dave to write up the dwd xep.
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.
SASL EXTERNAL is a non-starter in the public network.
That's an assertion not necessarily backed up by evidence. I am not
http://mail.jabber.org/pipermail/standards/2007-July/016086.html
Those figures have not changed much since 2007.
convinced that TLS + EXTERNAL is a non-starter on the public XMPP
network, but then again I help to run a CA that issues free domain
certificates for that network (visit http://xmpp.org/ca/ to get yours
today). I think we can say that TLS + EXTERNAL has not been widely
adopted, but that doesn't mean it never will be widely adopted. It all
depends on what threats people perceive. If the costs of getting a
domain cert start to be less than the costs of unsecured federation,
then people will start to use certificates.
We are talking about different problems. Imo the main problem with
s2s x509 is that servers continue connecting when they get a
mismatch of expected identity (see RFC 3920, 14.2 case #1).
philipp
