On Wed, 13 Nov 2013, Dave Cridland wrote:
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.
Right. XEP-0185 has a cryptographic way to proof that the the originating server and the authoritative server know the same secret.
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.
In my mind, using the same certificate shows they own the same secret, which is the private key.
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.
That would be equivalent to hardcoding a XEP-0185 secret. We don't have such an assurance in 0185 either.
*ponder*
