Bus authentication on Windows v2.0

[Simon McVittie]

On 06/06/16 14:43, LRN wrote:
> The way i understand this is that SASL is a framework, and that any
> authentication mechanism that fits into this framework is a SASL mechanism

Yes. For example, there are mechanisms for NTLM, Kerberos v4 and
Kerberos v5, according to
<https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml>.

IMAP, LDAP, SMTP and XMPP are good examples of protocols that also use SASL.

If we're lucky, someone else might already have defined a generic way to
do arbitrary SSPI authentication over SASL-supporting protocols; or if
not, you could define one with a DBUS_ prefix, perhaps
DBUS_WINDOWS_SSPI, or a family of them, perhaps DBUS_WINDOWS_SSPI_NTLM
and so on. Or you could use NTLM, KERBEROS_5 and/or GSSAPI if you can
work out how to do that (preferably in an interoperable way).

<https://en.wikipedia.org/wiki/Security_Support_Provider_Interface#Comparison>
hints at SSPI being a Microsoft variant of GSSAPI, in fact; so if
DBUS_WINDOWS_SSPI isn't the same as RFC 4752, it should probably be
closely modelled on that RFC.

What we're ideally looking for is the best way for the client to prove
to a trusted server that its SID (Windows equivalent of a uid) takes a
particular claimed value. If we can also determine the process ID, which
would mean the authenticated identity is a (SID, PID) pair analogous to
the (primary UID, PID) pairs we get on many Unix platforms including
Linux, that would be even better.

> (i think D-bus source code refers to such mechanisms as "SASL
> profiles").

If dbus or the D-Bus Specification incorrectly refers to mechanisms as
profiles, please send patches to correct this. A SASL profile is the way
in which a particular application-level protocol like IMAP or D-Bus
represents the abstract SASL operations as messages, together with the
protocol's assumptions about the meaning of an identity.
https://dbus.freedesktop.org/doc/dbus-specification.html#auth-protocol
is the documentation for D-Bus' SASL profile.

(I'm trying to be pedantic about the spelling here: D-Bus is a protocol,
dbus is the reference implementation of D-Bus, and GDBus is another
implementation of D-Bus.)

> Once authentication succeeds, both parties can use the security context
> object (which gets created during the exchange) to do stuff or query
> information from it.

In dbus, you'd store the security context object in the DBusCredentials
object, replacing or accompanying the "char *windows_sid" that we
already have. In GDBus, you'd probably put it in a GCredentials object.

> I'm a bit unsure what kind of information can be queried from a security
> context that is created during Digest or CredSSP exchanges.

Ignore those, then. We don't support SASL DIGEST either.

> In practice this requires
> some forethought, as Kerberos is rather picky (one needs to, for example,
> supply a "principal" name to AcquireCredentialsHandle(); NTLM doesn't
> really care about that). Kerberos supports mutual authentication (server
> must have valid credentials)

What needs to be in a principal name? It would probably be possible to
construct one from the SID, machine name, NT domain and bus GUID?

> NTLM does not (and is thus considered
> insecure when used over the network, as malicious 3rd party can steal real
> NTLM traffic and use it to authenticate to some other server).

That's OK, D-Bus over non-local TCP isn't secure either...

> C: AUTH SSPI_NTLM <U hex-encoded bytes from output_buffer>

Right, this is the "initial response" in SASL terminology.

> * If there's an empty output buffer, and you're server, send OK and proceed.
> * If there's an empty output buffer, and you're client, wait for OK (i guess?)

It should be possible for the client to send "DATA \r\n" to indicate
that it has nothing more to say?

Regards,
    S

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>