[24995] in Kerberos
Re: that interop mess: ldap, samba, kerberos
daemon@ATHENA.MIT.EDU (Dennis Davis)
Wed Nov 23 06:04:44 2005
Date: Wed, 23 Nov 2005 11:04:00 +0000 (GMT)
From: Dennis Davis <D.H.Davis@bath.ac.uk>
To: kerberos@mit.edu
In-Reply-To: <87wtj0d4qp.fsf@pumba.bayour.com>
Message-ID: <Pine.GSO.4.64.0511231049570.27218@hinault.bath.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: Dennis Davis <D.H.Davis@bath.ac.uk>
Errors-To: kerberos-bounces@mit.edu
On Tue, 22 Nov 2005, Turbo Fredriksson wrote:
> From: Turbo Fredriksson <turbo@bayour.com>
> To: kerberos@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@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@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@bath.ac.uk Phone: +44 1225 386101
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
