spec: Describe the security properties of nonce-tcp in terms of tcp

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This commit is contained in:
Simon McVittie 2018-04-12 13:59:43 +01:00
parent cf47380641
commit 7fc89fb1f8

View file

@ -3809,6 +3809,32 @@
the higher-level authentication mechanisms described in the
Authentication section.
</para>
<para>
The nonce-tcp transport is conceptually similar to a combination
of the <link linkend="auth-mechanisms-sha">DBUS_COOKIE_SHA1</link>
authentication mechanism and the
<link linkend="transports-tcp-sockets">tcp</link> transport,
and appears to have originally been implemented as a result of
a misunderstanding of the SASL authentication mechanisms.
</para>
<para>
Like the ordinary tcp transport, the nonce-tcp transport has no
integrity or confidentiality protection, so it should normally
only be used across the local loopback interface, for example
using an address like <literal>tcp:host=127.0.0.1</literal> or
<literal>tcp:host=localhost</literal>. Other uses are insecure.
See <xref linkend="transports-tcp-sockets"/> for more
information on situations where these transports have been used,
and alternatives to these transports.
</para>
<para>
Implementations of D-Bus on Windows operating systems normally
use a nonce-tcp transport via the local loopback interface.
This is because the
<link linkend="transports-unix-domain-sockets">unix</link>
transport, which would otherwise be recommended, is not
available on these operating systems.
</para>
<para>
On start, the server generates a random 16 byte nonce and writes it