[Standards] Dialback, authentication, and authorization

Dave Cridland dave at cridland.net
Wed Nov 13 11:56:48 UTC 2013


I'm having an interesting conversation with Fippo on the nature of dialback
with respect to authorization and authentication - in particular, which
parts of the protocol authenticate, and which authorize, and how. Here's
what we'ev been discussing:

To recap, in authentication, one side asserts an abstract identity, and the
other side proves that identity to its satisfaction - together, we refer to
these two items as a mechanism. Although we normally think of this identity
as a domain, it's very much more abstract than that, and could easily be
"the owner of the private key associated with this certificate", or other
equally odd things - and exactly what it is depends on the mechanism.

In authorization, that identity's right to do something (in our case, act
as a particular domain) is checked.

<db:result/> seems clearly an authentication assertion, and an
authorization request.

<db:verify/> seems like the authentication proof.

The authorization appears to derive from the connection, in classic
dialback.

In "dialback without dialback", we prove the authentication and
authorization against the certificate (via PKIX, POSH, etc). Since the
authorization is therefore done, there's no need to dialback at all - it's
not only redundant, but weaker than not doing it at all.

Then there's the "same-cert" shortcut, where the receiver connects to the
authoritative server and compares certs. This is an interesting case,
because we're deriving identity (and therefore authenticating) from the
certificate, but the certificate isn't sufficient to authorize - so we
dialback to the authoritative server and if the certificate matches, this
is sufficient authorization.

What we're now debating is whether we need a trusted identity in same-cert,
or whether a self-signed certificate is sufficient. We need to be assured
that the identity is unique - that is, that the private key is known only
to the authorized party, basically, and I'm personally concerned that there
could be cases of TLS and/or XMPP implementations shipping with a sample
certificate then used in production.

What do people think?

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131113/5bffe91f/attachment.html>


More information about the Standards mailing list