It allows a party (A) to prove to another party (B) they are who they say they are by having a third party (C) vouch for them. The client (normally a user) is authenticated to the server and the server is authenticated to the client. program every time you log into a workstation. All users are principals, but not all principals are users. In technical terms this means a principal can prove to another principal who they are by authenticating themselves to an authentication server. Most organizations have Active Directory, which is amongst other things an implementation of the Kerberos AS and TGS. We’re not talking minor nits. This means they can impersonate the user as long as the TGT is valid, and all the services involved really won’t know any better. This is not a bad thing, but it starts placing assumptions on the properties of the authenticated identity. Joking aside, this is a complicated protocol to understand completely. This ticket is called the ticket granting ticket (TGT) — you use it to get other tickets to services. The encrypted ticket is wrapped in a message that is then encrypted using the previously negotiated session key and returned to the user. Both the Kerberos server and the Kerberos client depend on having clocks that are synchronized within a certain margin. Unless you mistype your username, this should not DES was the standard when Kerberos was first published. In technical terms this means a principal can prove to another principal who they are by authenticating themselves to … A specification is a great equalizer. Single sign-on. There is a fairly large gap in the second exchange, where if an attacker can steal the TGT, they can take that TGT and use it on other clients. It should be pointed out that using passwords does have its benefits. Cross-realm trusts can be transitive, meaning if A trusts B and B trusts C, A could trust C. In principle this is simple and has a logic to it, but in practice it’s difficult to fit in your head and reason about. necessary to provide a means of authenticating users: any time a you'll see none of it, which is a nice feature. meanings of a few terms that will be used in this section. However PKI is relatively new technology and there is little that is mature enough to be trusted let alone deployed and distributed as a supported production system. This is done with Kerberos, and this is why you get your It lets the application operate as the user and access further resources on behalf of that user, but it’s not constrained to specific services. Kerberos is showing its age, but it has served us well over the years. Kerberos is far from obsolete and has proven itself an adequate security-access control protocol, despite attackers’ ability to crack it. The server has knowledge of the user’s password and can decrypt the message, proving to each party they are who they say they are respectively (within the limit of how easy it is to guess or steal this password). All of these properties accrue to a confidential, tamper-evident, authenticated, non-repudiated authentication protocol. Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other's identity. The sharing of services by sites across networks not managed directly by us, and support for more intermittently connected and self-managed machines, means there is even more reason to move away from machine and network trust; and we can no longer realistically condone the continued use of weak authentication. Most other major operating systems have an ability to do Kerberos, either natively, or through third party implementations like Heimdal or MIT. The last point suggested PKINIT can be used for authentication, and it can, but this assumes the application knows how it works and supports certificates. A statement on Data Protection and Interception on Informatics Managed Systems. This is mostly just annoying having to flip between formats, but complicates interop. Applications can opt in to Kerberos authentication using SSPI or GSS API’s with relatively little or no effort. Kerberos got delegation wrong though. There are multiple serialization formats in use depending on the type of data structure you’re looking at. Kerberos functions with the least assumption of trust of any system I’ve ever worked with, and can be modified such that no assumption of trust at all exists beyond initial authentication. Kerberos is an authentication protocol. The server identity prevents the spoofing and hijacking of services. Kerberos is a protocol that was built back when asymmetric cryptography was too expensive to use routinely or securely. Fundamental overhauls break everything even if the original protocols were designed to support future changes. In addition, it is Kerberos is pretty clear about how a user authenticates to the authentication service to get tickets. be developed, with a review of the security model. Most other protocols don’t have all these properties and rely on external protocols to provide these guarantees. initial ticket from Kerberos, and then asks for your password. Obviously, it is therefore necessary to prevent anyone from intercepting One-time passwords are too inconvenient for the user to be a realistic internal alternative. The implementor doesn’t need to design their own system. Kerberos has two purposes: security and authentication. As we build new protocols we should remember all the things we got right with it, and account for all the things we got wrong. You are often forced to explicitly set rules within the resource realm instead of implicitly trusting the information because the authorization rules are contextually relevant. All the user can do is forward it. A principal’s identity is proved by the secret properties of the password and hardness of the encrypting algorithm; the identity of the server is proven conversely by knowing the password and being able to decrypt the message without having to reveal the password to any party. It’s difficult to parse and more difficult to generate. happen. There’s an old joke: I went to explain Kerberos to someone and we both walked away not understanding it. This means you don’t end up with applications having the highest possible permissions any user will need and instead just rely on the user having the necessary permission. Compromising downstream resources via the application requires having an active user versus having unfettered access. This means you’re left on your own to figure out how to authenticate to the identity provider. This is non-trivial to get right in the best of cases so having it available to you and bound to your authentication service is useful. Now that the service has verified the user and the user has verified the service it’s possible for them to use a key derived from the subsession key to safely continue communications between the user and the service. You can also use kinit, which prompts for a username, requests an The server then generates a new message containing a ticket and a session key, encrypted against the user password, returning it to the user. Once a service has a users identity, it’s useful to forward that identity to another service as proof that the first service is operating on behalf of the user. This message from the user to the ticket granting server contains the ticket-granting-ticket (TGT) from the first exchange. If without a trusted third party. This turns out to be a useful property of an authentication protocol. This has untold utility, because you can isolate resources based on the amount of security required by the resource. The user can decrypt the message and now has a ticket and session key. It turns out this isn’t as common as you’d think, and applications tend to just prompt for passwords. Kerberos has a concept of cross-realm authentication. We learned this with TLS 1.3: protocols don’t like change. The entity receiving the ticket can request you prove ownership by doing work that only you can do and is incredibly difficult for an attacker to forge. identity. In Windows we have things like centralized protection of secrets in the LSA, which moves any dangerous secrets out of a given application (making it hard to steal secrets) as well as Credential Guard, which uses virtualization-based security to move all the important secrets to a seperate virtual machine so compromising LSA won’t get you anything (making it extremely difficult to steal secrets). Why Kerberos is needed. The primary advantage of Kerberos is the ability to use strong encryption algorithms to protect passwords and authentication tickets. The problem is that most people don’t understand how constrained delegation works which tends to lead to falling back to unconstrained delegation. the Athena Accounts Administrator by using olc. Secrets are not transmitted across the network. Cryptographically secure, architecturally sound, and easily integrated as a component in other systems, Kerberos was widely embraced as a way of providing a core set of security services for many distributed systems projects and developments, and is today an integral part of many computing environments. This kind of weak authentication is very common and has been used for many years in most UNIX installations. It’s still supported by all the major implementations in one form or another and most enterprises still have it enabled.