Kerberos Authentication Explained | A deep dive

so you want to connect to an application over an insecure Network but your wee bits paranoid someone may be listening in how do you solve this problem one possible solution is a protocol designed to provide secure authentication to services over an unsecure network passwords are never sent across the network encryption keys are never directly exchanged you and the application can mutually authenticate each other many organizations use it as the basis for single sign-on what wonder protocol can do all of this for us Kerberos hey I'm Rob Witcher in today's episode we're going to dig into the details of Kerberos to understand how it works a mildly interesting bit of trivia behind the naming of Kerberos it comes from Greek mythology the Kerberos protocol guards access to applications and so was named after the three-headed dog Cerberus the Hound of Hades who guards the gates to the underworld unsurprisingly I couldn't find any good stock footage of a three-headed dog but these three business dogs are pretty darn adorable let's start our tour of Kerberos with some terminology a Kerberos realm is the domain the group of systems over which Kerberos has the authority to authenticate a user to a service you can have multiple realms and you can interconnect them within a realm you have principles a principle is a unique identity either a user or a service an application a client is a process that accesses a service on behalf of a user you can have multiple clients or users within a realm essentially these are our users that want to access stuff a service is a resource provided to a client for example a file server or an application that a user wants to access you can have multiple services that clients can access the key distribution center the KDC is the heart of Kerberos the KDC supplies tickets and generates temporary session keys that allow a user to securely authenticate to a service the KDC stores all the secret symmetric keys for users and services there are two servers within the KDC the authentication server and the ticket granting server the authentication server confirms that a known user is making an access request and issues ticket granting ticket the ticket granting server confirms that a user is making an access request to a known service and issues service tickets there are a ton of messages passed back and forth between user authentication server take a granting server and the service at least two messages are sent at almost every step some messages are in plaintext and some are encrypted with a symmetric key there are two important types of messages worth highlighting authenticate errs are a record containing information that can be shown to have been recently generated using the session key known only to the client and the server essentially authenticators allow the user to authenticate to the service and the service to authenticate to the user mutual authentication and tickets tickets contain most of the information that needs to be passed the clients identity service ID session keys time stamps time to live etc all encrypted using a servers secret key now let's look at a high-level overview of the communications that occur for a user to gain access to a service we start with the user sending an unencrypted message to the authentication server saying hey I'd like to access some service the authentication service validates the request is coming from a known user and generates a ticket granting ticket the TGT the TGT is sent back to the user along with another message encrypted with the users secret key the user decrypts the message with their secret key and then it creates a couple new messages and sends the new messages along with the TGT on to the ticket granting service the ticket granting service decrypts the ticket granting ticket performs some validation and generates a service ticket the service ticket along with another message is sent back to the user the user decrypts the message creates an Authenticator message and sends the user Authenticator and the service ticket to the service the service does its own decryption validation and creates its own final Authenticator message this final Authenticator message is sent back to the user all of these messages allow the user and the server to mutually authenticate each other and securely distribute a symmetric service session key which allows the user and the service to communicate authentication information securely for the purposes of the CISSP exam that's probably about the right amount of details to know but for fun let's look at each of these steps and message exchanges in excruciating detail we'll start at the very beginning with the first unencrypted message that the user is going to send to authentication server the message contains the users ID will use Rob as the ID the ID of the service that the user wants to access will use a CRM application as an example the users IP address this can be a single IP address multiple IP addresses or even no depending on how Kerberos is being configured and the requested lifetime of the ticket granting ticket users would typically like a ticket that has an infinite lifetime so they never have to authenticate again but that's not a super great idea from a security perspective so Kerberos can just ignore what the user asks for once the user has their first message ready they send it over to the authentication server the first thing the authentication server does is look at the user ID in the message the authentication server being part of the KDC has a list of all the users and their secret keys and so it checks that the user ID and the message is in the list of users in the KDC and if so grabs a copy of that user's secret client key well see where that's used in a moment the authentication server now needs to create some messages to send back to the user the first message it creates contains the ID of the ticket granting server the timestamp the message was created and the message lifetime the second message is the ticket granting ticket it contains the user's ID the ticket granting server x' ID a timestamp the user's IP address and the lifetime of the ticket granting ticket it could be what the user requested or a different value depending on how Kerberos has been configured the final piece that the authentication server adds to each message is a ticket granting server session key this is just a randomly generated symmetric key each message is then encrypted the first message is encrypted with the users secret key and the second message the TGT is encrypted with the ticket granting server x' secret key these two encrypted messages are now sent from the authentication server to the user the user needs to decrypt the first message to do so the user generates their secret key they do so by entering their password Kerberos then adds a salt to the password and key version number the cavea know the salt is usually the user's username at round name the KD know is useful when long lib keys are used the user salted password is run through a hashing algorithm specifically string to key to generate the user's secret key and this key is the use to decrypt the first message this is a step where the user's password is validated because if the user entered the wrong password then the users secret key that was generated would be the wrong key and it wouldn't decrypt the message so presuming the user has entered the correct password and the message is decrypted the user now has access to the ticket granting server x' ID and the TGS session key note that the user cannot decrypt the ticket granting ticket because the user doesn't have the tgs's secret key the user now creates two new messages the first is a simple plaintext message that indicates which service the user wants to access and the requested lifetime for the service ticket the second message is the user Authenticator which contains the user ID and the timestamp of when the message was created the user Authenticator message is encrypted with the TGS session key once the user has these new messages ready they send these new messages along with the still encrypted ticket granting ticket over to the ticket granting server the ticket granting server now has a bunch of work to do it starts by looking at the service ID contained in the unencrypted message and checks to see if the service ID in the message is in the list of services in the KDC if the service is in the list then the TGS grabs a copy of the service secret service hee that's a mouthful and we'll see where that is used in a moment okay back to the messages that the TGS received from the user the TGS decrypts the ticket granting ticket with the tgs's secret key contained within the ticket granting ticket is the TGS session key and the TGS can now use this session key to decrypt the user Authenticator message from the user now that both the TGT and the Authenticator message have been decrypted the TGS starts to validate the data contained in the TGS first make sure that the user ID in the TGT and the Authenticator match compares the timestamps typically Kerberos is configured to tolerate up to two minute difference between timestamps compares the IP address in the TGT to the IP address of the user it received the messages from this assumes an IP address has been set this can be no checks that the ticket granting ticket has not expired if everything is copasetic then the TGS performs one more important step the TGS maintains a cache of a recently received authenticators from users the TGS will check its cache to ensure that the Authenticator it just received is not already in the cache this check provides replay protection if the Authenticator is not already in the cache then the TGS will add it the TGS now moves on to creating its own messages to the user the first message contains the service ID of the service the user wants to access the timestamp of the message and the lifetime of the message the second message is the service ticket it contains the user ID the service ID of the service the user wants to access the timestamp of the message the user's IP address and the lifetime of the service ticket the TGS then generates a random symmetric service session key and adds the symmetric key to both messages and the final step the TGS performs before sending the messages is encrypting them the first message is encrypted with the TGS session key and the service ticket is encrypted with the service secret key these two messages are now sent to the user and as you might expect the user now has some work to do the first message is encrypted with the TGS session key and as you may or may not recall this point we've already gone through a lot of messages the user received the TGS session key from the authentication server so the user decrypts the message with its TGS session key the user can now read the contents of this message and importantly now has a copy of the service session key the user creates a new Authenticator message containing the users ID and a timestamp and encrypts this new Authenticator with the service session key note the user cannot decrypt the service ticket as it was encrypted with the services secret key so the user simply forwards the service ticket along with the newly created Authenticator message to the service it's now finally the services turned to do some work and this is going to look very similar to all the steps the ticket granting service just went through first the service decrypts the service ticket with its secret key this gives the service access to the service session key which the service uses to decrypt the user Authenticator message now that both the service ticket and Authenticator messages have been decrypted the service starts to validate the data contained within the service first makes sure that the user ID in the service ticket and the Authenticator match compares the timestamps and as noted before typically a difference of less than two minutes is tolerated compares the IP address in the service ticket to the IP address of the user it received the messages from and checks to see that the service ticket has not expired if everything looks good then the service checks its cache just like the TGS the service maintains a cache of recently received authenticators from users the service will check its cache to ensure the Authenticator it just received is not already in the cache this check again provides replayer to protection if the user Authenticator is not already in the cache then the service will added the service now needs to create its own Authenticator message which it will send to the user similar to a user Authenticator message the service Authenticator includes the services ID and time stamp this Authenticator is encrypted with the service session key and this service Authenticator message is sent to the user the user now needs to look at this message it was encrypted with the symmetric service session key therefore it will decrypt with the same symmetric key and recall the user was sent this service session key by the TGS the user will now verify that the service name contained within the Authenticator is the service the user was expecting to talk to that's completing the mutual authentication the user will also look at the timestamp to make sure that the Authenticator was created for the last couple of minutes and just like the TGS and the service the user also maintains its own cache since the user has mutually authenticated the service it will cache a copy of the encrypted service ticket for future use and there you have a walkthrough of how a flurry of messages are sent by the Kerberos protocol to securely authenticate a user to a service over an insecure Network before we end this video here are a few more mildly interesting tidbits about Kerberos Kerberos is a pervasively used protocol for enabling single sign-on capabilities and one of the big reasons for this is that Kerberos has been built into Windows for over 20 years since Windows 2000 as the default authentication package Kerberos is also natively integrated or supported by a raft of other major operating systems including many flavors of Linux and Unix AIX and many others there are currently two major versions of Kerberos widely deployed today version 4 was published all the way back in the late 80s and has a major security limitation it only supports des des the data encryption standard as the encryption algorithm it uses DES only supports a 56 bit key which is nowhere near good enough in today's world version 5 is no spring chicken either as it was first published in 1993 with a revision in 2005 one of the significant security enhancements in version 5 is that it now supports many types of encryption and typically the Advanced Encryption standard AES is used as the encryption algorithm AES is an excellent algorithm in today's world another significant limitation of both version 4 and version 5 of Kerberos is that it only supports symmetric cryptography this leads to major key scaling and distribution problems especially in a large realm with hundreds or even thousands of systems the number of keys required grows rapidly and it can be very challenging to securely distribute all these keys to the services and the KDC there are configurations and implementations of Kerberos out there that have been made to work with symmetric or public key cryptography to solve the symmetric key problems I just spoke of but this is not the default standard version of Kerberos that is natively supported in many OSS and applications and that concludes our world wind tour of Kerberos thanks very much for watching I hope you found this episode informative if you like this video you can hit the like button and if you want to be notified when we release future videos you can subscribe and click the bell icon let me know what you think in the comments and let me know what topics you want me to cover in the future Cheers you

Channel: Destination Certification

Views: 92,991

Rating: 4.9750142 out of 5

Keywords: kerberos, how kerberos works, kerberos explained, kerberos authentication, how does kerberos work, authentication protocol, how kerberos authentication works, cissp, cissp certification, cissp 2020, cissp training, cissp domain 5, cissp masterclass, cissp kerberos, kerberos authentication protocol, kerberos authentication process, kerberos explained simply, kerberos explained simpley, cissp training videos, cissp training videos 2020, Cissp training 2020, kerberos tutorial

Id: 5N242XcKAsM

Length: 16min 51sec (1011 seconds)

Published: Fri Apr 10 2020