Security pointers about Kerberos5 realms open to a WAN

[Ken Raeburn]

As Tom says, Kerberos was designed to be used on open networks.  With  
the exception of the old DES-based types (a bad idea to use nowadays,  
but supported for backwards compatibility for places that haven't  
updated yet), the encryption schemes should be reasonably solid, and  
all of the data critical for authentication should be properly  
encrypted.  (If it isn't, we haven't found the problem yet.)  But the  
initial design was done a number of years ago, and the attacks of  
concern today may be different from what people (at least, the people  
working on Kerberos) were thinking about then.

There may be a few places where man-in-the-middle attacks could cause  
failures, even some that may not be immediately obvious, but such an  
attack should not be able to cause authentication to appear to be  
successful when it shouldn't be.  (At least, if the applications are  
written correctly.  Look up "Zanarotti attack" in your favorite  
search engine.)  As I recall, there was one paper describing how a  
MITM could replace the credentials being acquired from the KDC on the  
way to the user with some other blob of data, and intercept the fake  
"credentials" the user tries to send to an application server and  
replace them with the real thing, with the user never noticing.  The  
attacker couldn't *use* the credentials, though, or trick the user  
into authenticating to a different service.  So, is it a problem?   
I'm inclined to say no, but it's open for debate.

There are also probably cases where the user's privacy could be  
better guarded -- e.g., encrypting certain bits of data, like service  
names of credentials being requested from the KDC, rather than just  
doing some integrity checks.  On the other hand, the endpoints of  
your TCP streams may reveal roughly the same information anyways.

An attacker could also use an open KDC to probe for valid account  
names.  Even if the attacker can't guess the password (and without  
any preauthentication schemes enabled, the default mechanism is  
vulnerable to offline attacks), the account names may be of use for  
social-engineering attacks.

For my part, I'm not too worried about these issues, though some  
would be good to address eventually.  And MIT has been running openly- 
accessible Kerberos servers for many years now, without it being a  
problem.

Ken