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

[David Woodhouse <dwmw2 infradead org>]

On Thu, 2011-04-28 at 14:55 +0200, Stef Walter wrote:
> > 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.
> 
> Interesting. Obviously I need to look at this closer.

For slightly more readable client code showing how it's used, perhaps
see
http://git.gnome.org/browse/evolution-data-server/commit/?id=a601df8fd5

NTLM authentication is a three-stage process. We send a 'Type 1' message
to the server which is basically a probe, saying what kind of NTLM
exchange we support. It responds with a 'Type 2' challenge that it
thinks we'll understand, and we send it back a final 'Type 3' response.

The ntlm_auth helper has very simple interaction over its stdin/stdout.

We start by telling it 'YR\n' and it responds with the base64-encoded
Type 1 message, prefixed with 'YR '.

Then we give that Type 1 message to the IMAP/HTTP/etc server, and get
back the Type 2 challenge. We give that challenge to ntlm_auth, on a
line prefixed with 'TT '. And get back the final Type 3 response from
ntlm_auth, on a line prefixed with 'KK '. Don't ask me what the letters
mean; that's just the way Samba's tool does it.

So if I do that manually with 'openssl s_client' to talk to the IMAP
server and cut/paste the NTLM bits, for example, I end up with one
terminal which looks like this...

[dwoodhou@macbook ~]$ ntlm_auth --helper-protocol ntlmssp-client-1 --use-cached-creds --username dwoodhou  
YR
YR TlRMTVNTUAABAAAABYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1NT0JMMw==
TT TlRMTVNTUAACAAAABgAGADgAAAAFgolizrXqDB0qwEcAAAAAAAAAAKgAqAA+AAAABQLODgAAAA9HAEUAUgACAAYARwBFAFIAAQASAEkAUgBTAE0AUwBYADUAMAAxAAQAJABnAGUAcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQADADgAaQByAHMAbQBzAHgANQAwADEALgBnAGUAcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQAFABwAYwBvAHIAcAAuAGkAbgB0AGUAbAAuAGMAbwBtAAAAAAA=
KK TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAAAYABgBwAAAAEAAQAHYAAAAcABwAhgAAABAAEACiAAAABYIIYA2r+1PZOIIkAAAAAAAAAAAAAAAAAAAAAGKa4NfpUWguSi3uNd6kYw+I+LybUIkL50cARQBSAGQAdwBvAG8AZABoAG8AdQBEAFcATwBPAEQASABPAFUALQBNAE8AQgBMADMAAzRBV/Jk/9dRSjtubr2Vew==

... and another terminal which looks like this ...

* OK The Microsoft Exchange IMAP4 service is ready.
00 authenticate ntlm
+
TlRMTVNTUAABAAAABYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1NT0JMMw==
+ TlRMTVNTUAACAAAABgAGADgAAAAFgolizrXqDB0qwEcAAAAAAAAAAKgAqAA+AAAABQLODgAAAA9HAEUAUgACAAYARwBFAFIAAQASAEkAUgBTAE0AUwBYADUAMAAxAAQAJABnAGUAcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQADADgAaQByAHMAbQBzAHgANQAwADEALgBnAGUAcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQAFABwAYwBvAHIAcAAuAGkAbgB0AGUAbAAuAGMAbwBtAAAAAAA=
TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAAAYABgBwAAAAEAAQAHYAAAAcABwAhgAAABAAEACiAAAABYIIYA2r+1PZOIIkAAAAAAAAAAAAAAAAAAAAAGKa4NfpUWguSi3uNd6kYw+I+LybUIkL50cARQBSAGQAdwBvAG8AZABoAG8AdQBEAFcATwBPAEQASABPAFUALQBNAE8AQgBMADMAAzRBV/Jk/9dRSjtubr2Vew==
00 OK AUTHENTICATE completed.

The point is that the IMAP client has never known the password; it's
just asked the ntlm_auth helper to *do* the NTLM challenge/response
protocol for it, and passed the messages back and forth.

>  Couldn't gkr just [obtain the Kerberos TGT] for itself?
> 
> It certainly could. I'd be more in favor of an approach where
> gnome-keyring launches a process so that the network communication
> doesn't happen in the same process that does password and key storage.
> But perhaps gnome-keyring-daemon could launch such a process as needed,
> so no biggie there.

Yes, that would make sense.

> The thing that bothers me (and I'm not saying this is necessarily a show
> stopper) is that Gnome Keyring is a key and password store. It provides
> access to those secrets in various ways. But it hasn't really done any
> actual interacting with the user's off machine accounts (whether
> Kerberos, Google or what have you).
> 
> So before adding this into the daemon, I'd like to see whether the
> configuration and ticket renewal parts of it fit better into the new
> online accounts system David is working on.

OK. So let's concentrate on the NTLM part first, since that really is
just about providing access to the secret in a new way.

> > 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.
> 
> In order to this I guess we would need ACLs (again) in gnome-keyring.
> I've been giving this some thought. It's tough to get it 'perfect', but
> this time around (following the example of things like policy-kit) we
> may be able to do it well enough.

Well, if it's only handled *inside* gkr itself, then ACLs aren't so much
of an issue. It keeps it nice and simple.

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