Re: gnome-keyring Using gkr for Kerberos/NTLM single-sign-on handling

[David Woodhouse <dwmw2 infradead org>]

On Thu, 2011-04-28 at 09:20 +0200, Stef Walter wrote:
> The only piece that hasn't really be considered is the interaction with
> the user's unix login password, more specifically using it as a default
> to log into remote services (like Kerberos).
> 
> I don't think that gnome-keyring-daemon should hand out the user's login
> password like candy to whatever application requests it (eg: this would
> break sudo).

I wouldn't say that wasn't considered. Quite the opposite, in fact —
that consideration is *fundamental* to what we're trying to do.

The whole *point* in my proposal was that we don't *want* gkr just
handing out the password.

If we were prepared to tolerate that, then life would be simple. Modify
krb5-auth-dialog to ask for the password from gkr, and all the random
imap/smtp/http/im/etc applications that want to authenticate with NTLM
can just ask for the password too.

But we don't *want* gkr giving out the password like candy.

That's why I want *gkr* to obtain/refresh the Kerberos TGT for us, and
why I want it to handle the NTLM challenge/response on behalf of
applications — so that we don't *have* to give out the password.

> However we could add a DBus Interface(s) to gnome-keyring-daemon for
> performing various challenges on the user's unix login password (such as
> NTLM, Kerberos).

There is an existing API for both of these, which client applications
should already be using for NTLM or Kerberos authentication.

For NTLM, it is the /usr/bin/ntlm_auth helper application that was
traditionally provided by Samba/winbind. It handles the NTLM
challenge/response, and the application simply proxies the base64
messages back and forth between ntlm_auth and the network server.
http://mxr.mozilla.org/mozilla/source/extensions/auth/nsAuthSambaNTLM.cpp

We'd be providing an implementation of /usr/bin/ntlm_auth which talks to
gkr instead of talking to Samba/winbind. In Chris' repository you'll
find such a tool, which talks to his cut-down dæmon over the UNIX
socket. That could be changed to use DBus, of course.


For Kerberos, the existing API is simply that a valid TGT shall be
present in the file /tmp/krb5cc_$UID. We just need to keep track of when
it expires, and either refresh or renew it as appropriate.

(Strictly speaking, the API that *applications* use is libgssapi, and
the above paragraph is a description of what *that* expects. But unless
we're planning to modify the Kerberos libraries to behave differently, I
suspect that's the interesting part...)

> However we could add a DBus Interface(s) to gnome-keyring-daemon for
> performing various challenges on the user's unix login password (such as
> NTLM, Kerberos). This DBus interface could be used by gnome online
> accounts in order to log into Kerberos or NTLM where necessary. If this
> sounds familiar, it's because it it is. It has some aspects of the Meego
> SSO solution, but is very scaled back).

For NTLM, that's *exactly* the solution I envisage, although the
interface to gkr would actually be an internal implementation detail,
wrapped by the /usr/bin/ntlm_auth helper that applications expect.

For Kerberos, if it is *just* a client-driven "challenge" that triggers
gkr to refresh the Kerberos ticket, that seems somewhat suboptimal.
You're talking about having a *separate* dæmon that runs and does
nothing but sleep until it's time to renew the TGT, then prods gkr to do
so. Couldn't gkr just do it for itself?

On the other hand, perhaps that *does* give us an error handling
capability; if we do it as a request that's just *triggered* by
something like krb5-auth-dialog, then krb5-auth-dialog can handle the
error case where the network password has changed — presumably by
prompting us for a new password and trying again, then changing the
local password to match.

(I suppose that last bit would be "asking gkr to change the local
password to match", given that krb5-auth-dialog doesn't *know* the old
password so can't change it...)

We do also want to optionally support a mode of operation where the
network password is *different* from the local login password, but is
still 'write-only' in gkr and not handed out like candy.

-- 
David Woodhouse                            Open Source Technology Centre
David Woodhouse intel com                              Intel Corporation