On Thursday, December 01, 2005 12:02:49 AM +2500 Martin Rex
<
[hidden email]> wrote:
> 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.
Well, the "right" forum for this is probably comp.protocols.kerberos,
which also goes by the name
[hidden email]. That said, I think the
question is close enough to on-topic for a few messages.
> 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...)
Yup, that's a problem.
> 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...
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
Locked
