From a51b57df7a3771b7ff783efad6f56f50af20263c Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 12 Dec 2017 13:36:24 +0000 Subject: [PATCH 9/9] spec: Describe the EXTERNAL and ANONYMOUS auth mechanisms These are defined by standard RFCs rather than by D-Bus. What separates them from other standard mechanisms like PLAIN (RFC 4616) is that in practice, D-Bus implementations support EXTERNAL, DBUS_COOKIE_SHA1 and sometimes ANONYMOUS, but not PLAIN. Signed-off-by: Simon McVittie --- doc/dbus-specification.xml | 63 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 58 insertions(+), 5 deletions(-) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 90b24db2..1ec07a59 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -3065,18 +3065,59 @@ Authentication mechanisms - This section describes some new authentication mechanisms. - D-Bus also allows any standard SASL mechanism of course. - + This section describes some authentication mechanisms that are + often supported by practical D-Bus implementations. The D-Bus + protocol also allows any other standard SASL mechanism, although + implementations of D-Bus often do not. + + + EXTERNAL + + The EXTERNAL mechanism is defined in RFC 4422 + "Simple Authentication and Security Layer (SASL)", appendix A + "The SASL EXTERNAL Mechanism". This is the recommended + authentication mechanism on platforms where credentials can be + transferred out-of-band, in particular Unix platforms that can + perform credentials-passing over the + unix: transport. + + + On Unix platforms, interoperable clients should prefer to send + the ASCII decimal string form of the integer Unix user ID as + the authorization identity, for example 1000. When encoded in + hex by the authentication protocol, this will typically result + in a line like AUTH EXTERNAL 31303030 followed + by \r\n. + + + On Windows platforms, clients that use the EXTERNAL mechanism + should use the Windows security identifier in its string form + as the authorization identity, for example + S-1-5-21-3623811015-3361044348-30300820-1013 for + a domain or local computer user or S-1-5-18 for + the LOCAL_SYSTEM user. When encoded in hex by the authentication + protocol, this will typically result in a line like + AUTH EXTERNAL 532d312d352d3138 followed by + \r\n. + + DBUS_COOKIE_SHA1 - The DBUS_COOKIE_SHA1 mechanism is designed to establish that a client + DBUS_COOKIE_SHA1 is a D-Bus-specific SASL mechanism. Its + reference implementation is part of the reference implementation + of D-Bus. + + + This mechanism is designed to establish that a client has the ability to read a private file owned by the user being authenticated. If the client can prove that it has access to a secret cookie stored in this file, then the client is authenticated. Thus the security of DBUS_COOKIE_SHA1 depends on a secure home - directory. + directory. This is the recommended authentication mechanism + for platforms and configurations where EXTERNAL cannot be used. Throughout this description, "hex encoding" must output the digits @@ -3212,6 +3253,18 @@ because servers are required to save the file atomically. + + ANONYMOUS + + The ANONYMOUS mechanism is defined in RFC 4505 "Anonymous + Simple Authentication and Security Layer (SASL) + Mechanism". + It does not perform any authentication at all, and should not + be accepted by message buses. However, it might sometimes be + useful for non-message-bus uses of D-Bus. + + -- 2.15.1