[Standards] Dialback, authentication, and authorization

Dave Cridland dave at cridland.net
Wed Nov 13 13:38:08 UTC 2013


On Wed, Nov 13, 2013 at 1:27 PM, Thijs Alkemade <thijs at xnyhps.nl> wrote:

>
> On 13 nov. 2013, at 12:56, Dave Cridland <dave at cridland.net> wrote:
>
> > 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.
>
> I’ve added a table to the xmpp.net stats page showing which domains share
> a
> public key:
>
> https://xmpp.net/reports.php#sharesprivatekeys
>
> It checks the SPKI field, so the certificates may be different but the
> public
> key on them is the same.
>
>
Right. There are some interesting cases where you might deliberately and
legitimately have multiple certificates with the same private key, in
particular where hardware crypto is involved.


> Of course many are harmless false positives, there might be good reasons
> why
> two domains share a key. But those of note are:
>
> Prosody's default key:
>
> F7:D9:2E:68:43:43:A9:EA:2E:BE:5F:FA:4B:B7:B9:25:EC:3C:03:5B:85:B5:C4:38:48:0E:8A:9A:71:66:E6:E6
>
> Ejabberd's default key:
>
> C5:78:17:B1:34:90:54:D0:5A:16:A4:C6:71:80:6D:C3:F8:8B:F1:31:3D:64:BD:42:8F:1F:C5:D9:21:EB:99:BE
>
>
Ouch. I think we should recommend strongly somewhere that XMPP
implementations do not ship with a default key.

To state the obvious, this means that any TLS channel not using PFS on
these default keys is decryptable; the private key is, in effect,
compromised.


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


More information about the Standards mailing list