Ticket History #5821: REQ: in-registry keytab support

Hello wonderful Kerberos people,

I'd like to request a new format/support for keytabs to be stored in the
Windows Registry. This would enable me to use Group Policy to push
specific registry keys (and therefore keytabs) to groups of machines
that need to share a specific key, either a cluster of machines serving
web pages (HTTP/clustername) or some similar function. It will also
allow me to push a dummy keytab simply to validate that the KDC itself
isn't being spoofed or perhaps for some type of authenticated DNS or
LDAP look-ups that need to be performed by the SYSTEM account.

In some instances, admins may want to use Group Policy to permanently
assign a keytab to a group of machines in this way. If the machine ever
gets reinstalled, the keytab will be automatically re-applied to the
machine via Group Policy once the computer is joined to the domain.
This would completely eliminate the need to keep track of versions and
distribution of actual keytab files in addition to allowing the keytab
for an entire cluster of machines to be changed all at once. No older
versions around messing things up.

I believe that OpenAFS for Windows will soon have support for
authenticated anonymous access to a cell and this same procedure can be
used to distribute a keytab that the OpenAFS client could use for
anonymous authentication. Having all anonymous connections
authenticated allows for encryption and the ability to get rid of
IP-based ACLs. This is very useful for things like software
distribution using GPO or other methods that require the SYSTEM account
to read data out of AFS.

<<CDC
--
Christopher D. Clausen

On Oct 18, 2007, at 17:16, Christopher D. Clausen via RT wrote:

Sam said, and I believe meant, impersonating the cell. More
specifically, impersonating the cell to any of these anonymous users,
while giving the illusion of secure access.

Because Kerberos uses symmetric cryptography, not only can any party
knowing your password pretend to be you when talking to the KDC (and
then other parties), they can also pretend to be the KDC (and then
other parties) when talking to you. There are some preauth systems
and application protocols (e.g., authenticating inside a TLS-
protected stream, where the server certificate is verified and
assumed not to be compromised, as is the CA) that can mitigate this,
but with the basic, password-based Kerberos protocol, the possibility
is there.

So, someone extracting this shared "anonymous-client" key from one
compromised machine can pretend to be the KDC to other anonymous
clients, sending a fake AS-REP encrypted using that key and holding
credentials encrypted using not the real TGS key but a key chosen by
the attacker, and then responding to the following TGS-REQ with
equally fake credentials for talking to the local AFS service. Then
the attacker can pretend to be the AFS server, accepting and sending
encrypted messages.

So now your anonymous user would be talking to the attacker's version
of the AFS cell, with encryption.

It may be safer from passive eavesdroppers who don't have the shared
key, but conservatively, it shouldn't be considered any more secure
than non-encrypted exchanges, unless you have good reason to believe
the key can never be compromised.

(An attacker who records live traffic to the real KDC and AFS servers
and gets access to the key later could go back and decrypt it all,
but if you're really trying to do protected anonymous access, maybe
there aren't secrets revealed that way. But that's not guaranteed; I
could imagine a protocol implemented over the file system that might
work otherwise. Kerberos needs some sort of PFS facility; we know
this.)


A better solution, which unfortunately is still in design, might be
the anonymous-ticket facility for Kerberos, http://www.ietf.org/
internet-drafts/draft-ietf-krb-wg-anon-04.txt .

Ken