that interop mess: ldap, samba, kerberos

[Dennis Davis]

On Tue, 22 Nov 2005, Turbo Fredriksson wrote:

> From: Turbo Fredriksson <turbo at bayour.com>
> To: kerberos at mit.edu
> Date: Tue, 22 Nov 2005 17:30:54 +0100
> Subject: Re: that interop mess: ldap, samba, kerberos
> 
> Quoting Dennis Davis <D.H.Davis at bath.ac.uk>:

...

> > saslauthd certainly isn't buggy in this way.  The Zanarotti, or
> > screensaver, attack is avoided.  We make extensive use of saslauthd
> > here and the KerberosV logs clearly show a ticket-granting ticket
> > (krbtgt/BATH.AC.UK at BATH.AC.UK) being acquired and then used to
> > acquire host/{hostname}@BATH.AC.UK credentials.  The saslauthd code
> > caters for both the Heimdal and MIT Kerberos libraries.
> 
> That's not a keytab, that's a (service) principal, right!?

Yes...

> Two different but related things... ?

...closely related.  In this case it's a (service) principal that's
been extracted to a file (keytab) on the client machine.

> A '{host,ldap}/<FQDN>@<REALM>' (service) principal IS created and
> explained in my book, so are we talking about the same thing, but
> using different 'language'?

I suspect so.

> Am I missing something obvious here?

Not sure.  Kerberos, like many security mechanisms, is an elaborate
dance of tightly-observed protocols.  Put a foot wrong, and you're
potentially up to your armpits in something that's *really* not
nice.

Going back to the original question, one of the best explanations of
why you need to *use* the ticket-granting ticket can be found in:

http://www.stacken.kth.se/lists/heimdal-discuss/2000-10/msg00011.html

To quote Mark Eichin:

  Basically, getting a TGT and successfully decrypting it *MEANS
  NOTHING* in regard to security.  The essence of the attack is that
  at the same time I send the username to the target machine, I
  flood it with "kdc responses" that are encrypted in a password/key
  I know.  The server then sends off the TGT request, reads an
  answer, gets the one I sent; tries to decrypt it with the password
  I supply, and succeeds. *boom*.

  The fix is straightforward: actually *perform* an authentication
  step (krbtgt fetching isn't one.)  Usually this means turning
  around and getting a ticket for host/(local host name), *and
  validating it* against the keytab/srvtab.  You should find code in
  login to take care of all of these details, in fact it should be
  abstracted out into an API of its own (see Marc Horowitz' work in
  Cygnus V5 Kerbnet, years ago.)
-- 
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis at bath.ac.uk               Phone: +44 1225 386101