Peter Saint-Andre
[snip]
* 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.
I'm not so sure about that. <host-unknown/> means you're trying to
communicate with a domain that I don't host at my server.
How does the initiator discover that without running into the error?
DNS does not work even in the same domain.
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).
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
[snip]
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.
