16

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?

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
Richard Salts
  • 363
  • 1
  • 2
  • 11
  • 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 00:50

2 Answers2

25

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.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 3
    [MIT Kerberos 1.11](http://web.mit.edu/~kerberos/krb5-1.11/README-1.11.txt) 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 08 '14 at 02:50
  • 1
    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. – user1686 Oct 06 '14 at 11:39
  • @grawity They do if you want to use FAST (Flexible Authentication Secure Tunneling), unless there is a way of doing it with public keys. – Demi May 15 '18 at 05:30
  • 1
    @Demi: You can use FAST via [anonymous PKINIT](https://k5wiki.kerberos.org/wiki/Anonymous_kerberos), which only needs certificates for KDCs. (Somewhat unfortunately it needs _configuration_ on clients, but it's generic unlike secrets.) – user1686 May 15 '18 at 05:32
  • @grawity Is there a way to tunnel the exchange over TLS, so that all that is needed is a standard TLS certificate? – Demi May 15 '18 at 05:34
  • @Demi: Well... yes (KKDCP), but it doesn't change the certificate requirements of PKINIT. However, AFAIK, you _can_ use a standard TLS certificate for KDCs, as long as the clients are configured to expect it (instead of requiring the specific PKINIT key usage); it's mentioned somewhere in MIT's `krb5.conf` manual page. – user1686 May 15 '18 at 05:35
  • @grawity Makes sense. I ask because that does come very close to zero configuration. – Demi May 15 '18 at 05:35
  • @grawity It would be nice if PAKE could be used for the key exchange. Then the server is authenticated simply by virtue of the fact that it knows the password. – Demi May 15 '18 at 05:37
  • @Demi: To start with MIT Krb5 clients need `pkinit_anchors` to know which CAs to trust (and `pkinit_pool` because ugh, the protocol doesn't transfer intermediate chains...) And if you want them to accept a standard TLS cert, additionally `pkinit_eku_checking` and perhaps `pkinit_kdc_hostname`. – user1686 May 15 '18 at 05:37
  • 1
    @Demi: They did in fact [add SPAKE](https://web.mit.edu/kerberos/krb5-devel/doc/admin/spake.html) to MIT Kerberos just last month in Git. – user1686 May 15 '18 at 05:37
  • @grawity YAY!!! Now if only Heimdall Kerberos gets it (I prefer Heimdall because it has had far fewer arbitrary code execution exploits). – Demi May 15 '18 at 05:39
  • @Demi: Also just to clarify, MS-KKDCP (tunnelling the entire Kerberos exchange via HTTPS) does not depend on PKINIT (or any other KDC capabilities – a [separate proxy](https://github.com/latchset/kdcproxy) can be used), and it _does_ support standard TLS certificates by default. So it might be an acceptable level of protection as well. – user1686 May 15 '18 at 08:35
9

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.

Community
  • 1
Michael Hampton
  • 3,877
  • 1
  • 22
  • 32