What is Kerberos?

What is Kerberos?

I first encountered Kerberos the summer before going off to Carnegie Mellon University. I received an email with instructions on getting access to the campus network that included setting up Kerberos. Despite being one of the few students taking programming courses at my high school, and being part of the team that went to a state wide programming competition, this was a new to me. Later in an informal discussion on what not to do on the campus network the name Kerberos came up again. When I decided to look into what it was the explanation was enough to make me decided to leave it at ‘it lets me authenticate’ Since then I have become a lot more knowledgeable when it comes to IT and networking, and even have played around with ways of bypassing it on sites like Tryhackme.com and hackthebox.eu When it comes to explaining what is going on in a ‘simple’ way though… I am reminded of those logic puzzles where you need to figure out how to get 3 things across a river in a boat that only holds 1 without while a wolf makes coleslaw as a side-dish… except instead of a wolf there is a 3 headed dog that is handing out different types of tickets.

I came across my notes for an assignment from a Windows server administration course explaining how Kerberos works and thought putting them up might be useful (at least to me next time I need to explain AD security)

Description of the problem

Wouldn’t it be nice if resources could be kept on multiple servers and accessed from client workstations instead of having a large computer with dumb terminals? Much like once you have signed into your Gmail you can access your Google Drive, Docs, and other sites, IT staff needed a way to centralize the authentication process on an organization’s internal network. This way a user could access resources on multiple servers and access their files from multiple workstations, without needing to have an account with proper permissions set up on every single computer, and without needing to log in to every single machine individually.
The basic goals of the system are:

• Scalability: having account data on each server (file, application, mail, etc) does not scale
• Security: how do we keep user’s files safe? How do we ensure we know who accessed a resource at what time? How do we make sure that network resources are available to the right people?
• Convenience: If the user finds it too burdensome to use than the software won’t be adopted or will be circumvented through ‘shadow IT’ creating a less secure alternative
  • the user should not need to enter their credentials for each service. This will also help keep them from choosing easy to type and easy to guess passwords.
  • similarly the user should be able to stay logged in for most, if not all of their workday. If they need to re-enter their credentials constantly they will make local copies of as much as possible as well as use weak credentials that are easy to type.

Solution: Users AND services have passwords

• only Kerberos in the form of the Key Distribution Center has all the passwords
• to prevent the user from learning the service’s password and bypassing proper authentication (logging in to the service as a different user, etc) when you have authenticated with Kerberos you are sent a Ticket that contains a version of your username encrypted using the services password (which you don’t know)

Kerberos provides a way for a user to authenticate with multiple networked servers without needing to create and maintain passwords (a shared secret) with each server (some of which might be running multiple software services that require authentication to use) The basic idea is the same as sending someone a locked box to give to someone, though in this case you could say there is an outer box locked with a key the intermediate recipient has a copy of. The basic idea is not that complicated once the jargon and acronyms are put to the side.

The Devil is in the Details

While convenience is mostly a matter of keeping the user from needing to think about authentication, security requires trying to think of the ways an attacker might try to attack the service. The primary issue is “How to set up a system that allows a user to have a shared secret with a server they have not previously interacted with over an open (anyone can see the data being sent by anyone else) network?”

Another less obvious requirement of keeping the system secure is that you can’t just give the end user a token to a service that they can use at any time or from any location. Besides the fact that this would mean that if an attacker compromised a workstation once they would persistent access every single service that the user(s) on the workstation had accessed. It would also make it impossible to manage changes to user’s authorization.

Some more of the requirements:

• no sending plaintext passwords over the network (to the service or to the KDC)
• a way of logging (auditing) who requested access to what when
• the user needs to authenticate himself to the service AND the service needs to authenticate itself to the user
• protection against replay attacks - an attacker can’t just resend the same data that a user sent to get access to the server

Outline of the steps involved

Key terms:

• Key Distribution Center (KDC) the service that provides Kerberos authentication Made up of:
  • Authentication service (AS): This authenticates users when the initially access a service
  • Ticket granting service (TGS): Allows you to authenticate yourself with a ticket rather than a password.
  • Kerberos database: This can be LDAP or AD, a place to store credentials
• Authenticator:
  • encrypted with the user’s session key (sent by the Authentication service to the user at the initial login)
  • consists of: User ID and timestamp network address?
  • needed to prevent REPLAY ATTACKS
  • only valid for a short period of time
• Ticket-Granting-Ticket: used instead of a password to get a service specific ticket from the TGS.
• Session Key: Serves as a shared secret between the service and the user.
  • ticket owner gets a copy as part of the reply from Kerberos
  • the service gets the session key from the encrypted (with the password shared between Kerberos and the service) ticket

Steps involved

1. the local workstation prompts the user for the username and password and sends:
   • Security Identifier (SID)
   • name of requested service
   • IP address
   • desired lifetime of the Ticket granting ticket (TGT) defaults to 10 hours (used to be 8 maybe?)
   • Note that you are not sending the password of the user.
2. If the server finds a match for the user it sends back
   • Security identifier (SID) /whose?/
   • TGS ID
   • Timestamp
   • User’s IP address
   • TGT lifetime
   • TGT
   • Session key
3. Then a second msg is sent:
   • TGS ID
   • Timestamp
   • Session key
   • Note that these msgs are encrypted using the user’s password
4. The user then sends the TGT to the TGS with the Kerberos ID of the service they are requesting access to
5. Another message is sent from the user to the service containing the Authenticator
6. The service decrypts the ticket and has the following information
   • ticket’s lifespan and timestamp
   • the username the ticket was issued to
   • the network address the user the ticket was granted to
   • the session key
7. The service than uses the session key to decrypt the authenticator

An attempt at explaining this in a (very) short narrative

In effect to make shared secrets possible with symmetric encryption and no pre-share between the client and servers are setting up a service that sends the client a box locked with the clients key that has a key and a second locked box (that the client can’t unlock but the service can) that has a session key for the service The client then forwards along the second locked box as well as well as the authenticator that is locked in a box with the key that was sent to the client The service than opens the box the client could not and retrieves the copy of the clients key that could not have been tampered with or copied in transit - thus establishing a shared secret with the client. The clients key is used to open the authenticator that the client created and locked up and makes sure that the info in the authenticator (such as user ID and IP) match the data in msg from kerberos that was locked up with a key that the user did not have. The authenticator also has a timestamp that prevents it from being re-used by some other computer with the same IP later

• this id protection against so called replay attacks. The system checks the timestamp of the packet and any timestamp earlier or the same as a previous packet is rejected as well as any timestamp out of sync with the server ny over 5 minutes (so you cant just reset the system time on the client to change the timestamp…) To authenticate the server to the client the server will send a msg encrypted with the user’s session key with the timestamp from the authenticator

Conclusion

Hopefully this brief overview will be useful to someone. As I have been getting more into Active Directory/Windows Server as well as starting to do more security related work at the very least it can be a start to some more detailed posts on Windows network security.