Security pointers about Kerberos5 realms open to a WAN

[Christopher D. Clausen]

Daniel Kahn Gillmor <dkg-mit.edu at fifthhorseman.net> wrote:
> I think i understand the basic K5 protocol, but i don't have my head
> wrapped around the different possible attack vectors well enough to
> know if opening up a KDC to the internet is really asking for trouble
> (e.g. how much krb5 traffic needs to be sniffed for an attacker to
> compromise a ticket within the ticket's expiration window?).
>
> Has anyone on this list run KDCs that are globally accessible?

Yes.  I would imagine that nearly all sites running globally accessible 
OpenAFS cells would need globally accessible Kerberos realms to actually 
allow users to authenticate.

> did you use IP-based blocking on IPs with too many failed
> auth requests?

No.  The KDC just issues tickets.  There is no way to tell if 
authentication was successful or not (unless you enable pre-auth, which 
you probably should.)  And even if pre-auth is turned on, there isn't 
much point in trying to block certain IPs, as you'll probably just end 
up blocking valid users, as you mention below.

> if so, did you experience problems with NAT'ed
> users locking each other out?

I don't know of an easy way to actually lock out users with standard MIT 
Kerberos.  As mentioned, there is no way to tell if authentication was 
successful or not.  I supose you could read through the KDC logs and 
disable IPs where preauthentication has failed.  But as you mention, 
this will probably just lock out legit users who share the same external 
IPs.

Its more likely that someone is going to attempt attacks SSH or some 
other service that checks Kerberos on the server-side rather than 
Kerberos directly.  The SSH attack will work against nearly all UNIX 
hosts, and the Kerberos attack would need to be specific as well as 
generate lots and lots of logs on the KDC.

Without pre-auth, one could just request a single ticket for any 
principal and then crack it offline.  (I belive john the ripper has 
Kerberos TGT cracking support now, at least for DES tickets.)

> did you tunnel your krb5 traffic inside some other encrypted layer
> (e.g. ssl or ssh) to avoid sniffing?  Is this even necessary?

This is not necessary.  Kerberos was designed to run on top of a 
untrusted network.  That being said, it certainly wouldn't hurt to have 
the Kerberos traffic additionally encrypted, as offline attacks against 
un-preauthenticated TGTs (or even properly preauthenticated TGTs that 
are sent over the network and passively gathered) are more and more 
feasable.

Kerberos does depend upon properly functioning DNS as well.  Its 
possible that a compromised DNS service could do evil things to your 
Kerberos infrastructure.

> Is there some documentation i've missed?

Yes, there would appear so, as some of these questions are answered in 
various online sources in much more detail.

> Am i crazy for even considering krb5 on a WAN?

No, that is the exact situation that Kerberos was designed for.

-----

I'd suggest having a minimum password length of at least 8 and requiring 
at least 2 different character classes in Kerberos passwords.  Using 
longer passwords and more characters classes would of course be better, 
but might annoy some users.  This should make offline cracking harder.

<<CDC
-- 
Christopher D. Clausen
ACM at UIUC SysAdmin