0

If I have a webapplication in my internal Microsoft Windows network I'm aware that I can use the kerberos protocol to make a Single Sign on (SSO) into this application with the web browser.

Is it a good idea to use kerberos for SSO in an external hosted and run (think SaaS) webapplication when all clients of this application are inside the same MS Windows Network?

Kerberos uses symmetric keys to sign its tickets. Is this key used for the full Realm or only for a service? My fear is that I have to share a symmetric key with the external hosted application and that this key could be malicious used to authenticate as a user to yet another application. Is there any foundation to this fear or could this be safe?

leo
  • 103
  • 3
  • 1
    How would external clients have access to the KDC (e.g. DC)? – phbits Apr 20 '20 at 23:40
  • I would upload the [keytab](https://stackoverflow.com/questions/43863275/what-is-a-keytab-exactly) file to him. Is that a security risk? – leo Apr 21 '20 at 06:02
  • 1
    Kerberos SSO requires network access to the KDC from the authenticating client which is why it's only used on internal networks. Allowing this functionality to external clients requires the KDC be available on the internet. This is a security risk and why nobody does it. – phbits Apr 21 '20 at 14:11

1 Answers1

3

The way Kerberos works is by the client (browser, app, PC, etc.) requesting a ticket from the KDC (domain controller) whenever it needs to log in to the SaaS application. The KDC creates the ticket and encrypts it to a key only the service knows. Therefore this means the client must have line of sight to that KDC whenever it needs to log in. Within a corporate network this is completely reasonable and is how many apps have functioned for the last 20 years.

However, what happens if the client doesn't have line of sight, say working from home because of a pandemic? In that case the client needs VPN or a KDC proxy to fulfill the requirement. Not unreasonable, but more infrastructure to deploy. Comparatively things like cloud identity providers don't really have this issue (though introduce their own).

Regarding the security of the symmetric key... Only the KDC and the service should have knowledge of that key, so therefore only the KDC or the service can generate a ticket representing the user. The KDC is authoritative so it's going to issue a ticket one way or another and the service is the thing requiring the identity so who cares if it impersonates something only it cares about? Repudiation might be important on that one for the sake of auditing, though you could argue that if the KDC didn't log a ticket creation did it really happen? Also, in Windows-land domain controllers sign an internal bit of the ticket with a key only the KDC knows so with enough auditing it's possible to prove one way or another if the KDC issued the ticket.

Since only the service knows that secret, the best it could do is potentially authenticate itself to the KDC and from there request a ticket to another service, but it's going to be the identity of the service so it can't impersonate other users. Unless you enable full unconstrained delegation. Just don't do that. A SaaS should never need that.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • Thank you Steve. I extended my question a bit. All the clients are in the Windows Network (even during a/the pandemic they will have acces to it by VPN), although this is a good point. What I'm not sure: Does the KDC in Windows-land issue a different key for each service? – leo Apr 27 '20 at 07:33
  • Yes, that's what I said in my answer. Only the KDC and service know the key. – Steve Apr 27 '20 at 14:28
  • Thank you! I get that this is not the way to go and it should not be done. But from reading your answer, from a security standpoint alone (at least in Windows-land) nothing speaks against doing Kerberos to an external service provider. – leo May 04 '20 at 10:42
  • _Should not be done_ is not what I said. It's subjective based on infrastructure and access requirements. The security of Kerberos is solid and is comparable to other federated protocols (and has stronger security guarantees in certain ways). – Steve May 04 '20 at 15:28
  • Could you please add a reference for the claims "Only the KDC and the service should have knowledge of that key" and "Windows-land domain controllers sign an internal bit of the ticket with a key only the KDC knows" so that I could read more about it. Thank you very much! – leo May 04 '20 at 17:09
  • The first is Kerberos itself, if you need to protect the contents of a message between two parties using symmetric keys you don't share that key with a third party. This is RFC 4120. The signing bit is called PAC validation. https://docs.microsoft.com/en-us/archive/blogs/openspecification/understanding-microsoft-kerberos-pac-validation – Steve May 04 '20 at 17:42