Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

What are the threats to having the KDC accessible via the internet for remote clients?

It's my understanding that the authentication is a challenge/response protocol and that the password is never transmitted. Are brute force attacks the reason this isn't common?

Is this because the kerberos authentication is more valuable than brute forcing an individual ssh or mail account as multiple services on multiple hosts might be compromised at once? Is it because of the attack surface of the KDC itself and that a pinhole firewall is not seen as sufficient barrier to preventing access to this valuable lynchpin for authentication and authorization?

share|improve this question
    
Are you asking about Windows Azure Active Directory or a VPN connection? –  Colyn1337 Sep 12 '13 at 13:07
    
I was actually trying to gauge whether there is any need for a VPN if all my applications were encrypted and used Kerberos for authentication. I would probably use MIT kerberos or Heimdal for my own needs. –  Richard Salts Sep 13 '13 at 0:50

2 Answers 2

up vote 11 down vote accepted
+50

Arguably the reason Kerberos isn't used over the public Internet doesn't have to do with the security of the protocol, or the exposure of the KDC, but rather that it's an authentication model that doesn't fit the needs of most "public Internet" applications.

To quote Wikipedia, Kerberos "provides mutual authentication — both the user and the server verify each other's identity." That means that the client machine needs to have the necessary keys to vouch for its identity before user authentication takes place. Distributing those keys for "public Internet" applications isn't practical for several reasons - consider how many PCs access your banking web site, owned by a wide variety of people whose ability to install Windows patches regularly is strained. It's not like corporate IT will come around and configure Kerberos for them.

Kerberos requires tightly synchronized clocks - not that hard to do in a centrally managed corporate or educational environment, a lot harder when the machines are all owned and managed by completely different people.

One of the advantages of Kerberos is the ability to seamlessly leverage an initial authentication into multiple application accesses. On the public Internet, the multiple applications rarely have anything to do with each other - my bank, my mail, and my /. account have no call to trust each other or the same set of people. (This falls into the area of Federated Identity, and there is work in this area, but it doesn't need the same mix of things Kerberos brings to the table).

In short, Kerberos is a heavyweight solution, and public Internet application access control is a lightweight problem.

To answer your actual question directly, no, I don't believe concerns about brute-force attacks or vulnerability of the KDC keeps Kerberos off the Internet. The protocol has been reasonably well vetted, attacked, fixed, and updated over 20+ years. The client (machine) authentication piece alone provides tremendous protection against a number of attacks that are expected on a large open network like the Internet.

share|improve this answer
2  
MIT Kerberos 1.11 now contains work so that clients do not have to sync their system clocks with that of the KDC. A time offset is discovered during preauth and stored along with the local credentials. This is now available in Fedora 19+ and RHEL 7. –  Michael Hampton Jan 8 at 2:50
    
Clients don't need special key distribution, because the keys for user accounts are derived directly from their passwords. So it should be enough to just kinit fred@FOOBAR.COM, given that most implementations can discover KDCs using DNS. –  grawity Oct 6 at 11:39

Kerberos itself is generally safe to use over the Internet. It was, after all, designed to be secure over one of the world's most hostile public networks: the MIT campus network.

A Kerberos whitepaper, "Why is Kerberos a credible security solution?" addresses all of the points you raised. To quote in part:

A password that is never disclosed or sent over a network is much more difficult for an attacker to purloin. Consequently, Kerberos authentication of users does not require that passwords be presented to the authentication service. Instead, the Kerberos authentication service uses cryptographic protocols whereby the user can prove possession of a password without actually revealing it.

In a distributed environment, it would be awkward in the extreme to maintain shared secrets such as passwords on every client and server that needs to authenticate requests. Furthermore, distributing shared secrets across many systems increases potential vulnerabilities in direct proportion to the number of systems—a problem exacerbated by the “weakest link” phenomenon. Kerberos addresses this requirement by maintaining a centralized database that is distributed across only a few authentication servers. While overall security is critically dependent on protecting this central database, it is much easier to harden a few special-purpose servers against attacks than to protect many general-purpose systems. The central control over authentication secrets also makes it easier to issue new credentials, revoke existing ones, and recover from compromised credentials.

The Kerberos developers assumed that anyone could eavesdrop on network traffic, could claim to be any user, and could set up rogue servers capable of posing as any legitimate service, including the Kerberos services themselves. Encryption was used to prevent eavesdropping attacks, and session keys were introduced along with timestamps to prevent replay attacks. When users (or hosts/services) authenticate to the Kerberos authentication service, the authentication service in turn authenticates itself to the user (or host/service) by proving it knows the previously established shared secret. A by-product of these counter-measures is that Kerberos provides protection against man-in-the-middle attacks, which were generally regarded as infeasible at the time, and for more than a decade after Kerberos was initially deployed. Sadly, man-in-the-middle attacks are no longer mere conjecture, and are all too common in today’s Internet web, which was not designed with a hostile environment in mind.

If you can reasonably join all of the systems to the Kerberos realm, for instance they're all sites within your company, then it should be fine to use. However, it doesn't necessarily encrypt everything; for instance, HTTP would still be unencrypted. Some services such as NFS, though, can encrypt their data flows using Kerberos. Depending on your applications and the data you'll be transmitting, you may still want to use a VPN between sites.

But if your applications are going to be open to the public, then Kerberos probably isn't what you want.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.