From 34c01d93009a80cc59bf4a3867425669fe7398cc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?= =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= Date: Fri, 24 Jun 2016 07:59:41 +0000 Subject: [PATCH] Add DBUS_WINDOWS_SSPI_NTLM spec section https://bugs.freedesktop.org/show_bug.cgi?id=96577 --- doc/dbus-specification.xml | 80 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 0500220..78b4726 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -2996,6 +2996,86 @@ because servers are required to save the file atomically. + + DBUS_WINDOWS_SSPI_NTLM + + The DBUS_WINDOWS_SSPI_NTLM mechanism is designed to establish that a client + is a user on the local NT system. The Client proves this by successfully + negotiating an SSPI security context, using NTLM security provider. + As long as authentication is not happening over unencrypted network + connection, this method is secure, as credentials are checked by the OS. + + + Throughout this description, it is implied that security provider name + given to SSPI is "NTLM". + + + Authentication proceeds as follows: + + + + The client uses AcquireCredentialsHandle() function to get + a credentials object, then passes that to InitializeSecurityContext() + (specifying NULL input and NULL context) to generate an unfinished + security context object and the initial response message. + The initial response is then hex-encoded and sent to the server + as part of the AUTH message. + + + + + The server uses AcquireCredentialsHandle() function to get a + credentials object, then passes it and initial response to + AcceptSecurityContext() (specifying NULL context) to generate + an unfinished security context object and the next challenge. + The next challenge is then hex-encoded and sent to the client + as DATA. + + + + + The client passes the challenge, the unfinished context object + and the credentials object to + InitializeSecurityContext() to generate a response. + The response is then hex-encoded and sent to the server as DATA. + + + + + The server uses passes the response, the unfinished security context + object and the credentials object to + AcceptSecurityContext() to generate the next challenge. + The next challenge is then hex-encoded and sent to the client + as DATA. + + + + + Previous two steps are repeated, until SSPI indicates that the + security context negotiation is finished. Once server-side + security context is finished, the server turns it into + credentials (for example, by querying access token object + from the security context, and then obtaining user SID + from the access token object). If that succeeds, the client + is authenticated. + + + + + + As demanded by SSPI documentation, each party must send every buffer + given by SSPI to the other party, including the last buffer that is + received when SSPI indicates that context negotiation is finished. + However, if buffer has zero length, it should not be sent. If SSPI + gives one of the parties a zero-length buffer and negotiation is not + finished, it is an error. + + + The client should give ISC_REQ_IDENTIFY attribute to InitializeSecurityContext() + to create a context that can only be used for identification purposes, + not for impersonation. + + -- 2.4.0