Subject: Kerberos and "account lockout" technology

From: Martin Rex <[email-masked]>
Date: Thu, 1 Dec 2005 00:02:49 +2500 (MET)

Forgive me a question that is not on the charter of this WG,
but I got a customer inquiry on a Kerberos-related issue today and
this is the only Kerberos discussion forum to which I'm subscribed.

The customer is worried, because *our* software visualizes
the servers kerberos principal name -- and as they have
an "account lockout" feature active on their KDC for a small
number of failed authentication attempts.

With the knowledge of the servers kerberos principal name,
an attacker could easily mount a denial-of-service attack
on our (distributed) server by simply performing the necessary
small number of invalid login attempts and lock out the servers
account this way, so that the server will no longer be able
to authenticate to the KDC and acquire TGTs...
(actually, our server will not even start because the os-integrated
 logon fails when the account is locked out...)

IMHO, given an modern encryption type with a decent keysize (AES-256),
account lockout shouldn't be necessary for service acconts with strong
random keys, but, unfortunately, not all Kerberos implementations are
born equal and the customers Kerberos implementation does not offer
strong random keys for service accounts...

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Nov 2005 18:49:19 -0500

> this is the only Kerberos discussion forum to which I'm subscribed.

Well, the "right" forum for this is probably comp.protocols.kerberos,
which also goes by the name [email-masked].  That said, I think the
question is close enough to on-topic for a few messages.

>  logon fails when the account is locked out...)

Yup, that's a problem.

> strong random keys for service accounts...

I agree.  Personally, I prefer using strong randomly-generated keys for all 
principals whenever possible.  The only time a weak "password" should be 
needed is when a human will have to enter it from memory, such as a user's 
login password.  At our site, we use randomly-generated keys not only for 
services but also for daemons and other entities that will act as clients, 
but which always use a stored key rather than one typed from memory by a 
person.

That said, I don't think the "everything has a password" model used by some 
implementations is insurmountable.  For example, my understanding is that 
Windows computer accounts use long, randomly-generated passwords.  I should 
think that using a similar approach for your application, combined with a 
suitably strong enctype, would provide sufficient security to allow 
disabling the password-lockout feature for that account.

-- Jeff