The separation between the S and T servers is the separation between _authentication_ (proving you are who you say you are, done by S) and _authorization_ (what services you are allowed to access, controlled by T). Each one can be updated independently.
In active directory though, neither of them seem to do authorization? Any user can get a ticket for any service. It's the service itself (file server etc) that determines if a user is allowed in, and that's completely independent of Kerberos. The Kerberos ticket just proves the user is who they claim to be
I did reach the same observation, though I'm struggling to get the intuition behind this. Why did the inventor separate the 2 services? My first thought is that having a copy of all identification info in *each* server may increase the chance of it getting compromised. However, storing all passwords in one server also introduces a single point of failure, so my thought about the inventor's intuition could be wrong.
VbScrub that is not true. In AD, Kerberos most certainly does authorisation. It’s the “Allowed to authenticate” right and if you don’t have that, the ticket is not produced, regardless of whether the resource would grant you access otherwise. If the account is “allowed to authenticate” and the ticket is produced, the resource can still perform its own authorisation. There’s more than one place where authorisation decisions are made.
specifically: "I can confirm for a Windows Server 2016 deployment that “Allowed to Authenticate” has no effect on the KDC’s willingness to issue a TGS. I believe this is by design considering [MS-KILE] (3.3.5.7 TGS Exchange) states that the Allowed-to-Authenticate right is only checked if the TGT contains the OTHER_ORGANIZATION SID"
This is HANDS DOWN the BEST description of how Kerberos works. Straight forward, easy to understand. I feel like I truly understand it now, vs just having a general idea of what it does. Thanks so much for this great content!!❤❤❤
I can't say this enough. I LOVE this channel and how well everything is explained! Dr. Pounds videos are my favorite as he's just so likable and amazing at his explanations. Keep up the amazing work everyone!
This is a brilliant explanation! I've been working with KRB (MIT and Heimdal) and OpenAFS for a decade, but recently moved to (samba) AD. Kerberos is my friend! The most common failure of both is clock offsets! If the lifetime doesn't match or the timestamp is in the future, it throws funnies. never had any serious issues in those 10 years. KDCs just keep on working
first heard of Kerberos nearly 30 years ago but never used it, this is the first time I've actually gotten a high-level overview that was super easy to understand - thank you!
It is worth mentioning that in AD, the authorization is split between the ticket granting service and the target resource (in this case the file server). The ticket will also carry information about group membership, which will allow the file server to determine whether the user trying to access it is allowed, or is a member of a group that is allowed to access the server. Also worth mentioning that because of all these timestamps floating around, it is imperative that all these systems have the same time.
This is a decent retro perspective on hard coding server based authority networking. Thank you for your efforts. Back in the early nineties we used this with Norvell for user based authentication for both bridges and simple internal routing via IPX. Cool to see it being reimplimated for wide distribution systems. Our biggest concern back then was Chatterbox, inbound exchanges outside of our secured internal networks with disparate network protocols. IP was not a standard like today.
For those wondering why the timestamp T is necessary throughout most of the video, wait until near the end where Mike explains that it's a way to defend against an imposter. It's perfectly understandable why this was discussed only near the end (13:53). Be patient, it's explained in the video.
Thank you so much Mike for these videos. I'm taking the security + right now and I would be lost without you. Your video's really help to solidify the text.
Great explanation as always. I've also made a few videos about kerberos myself recently, mainly demonstrating some of the ways to circumvent the security of it. Oh and one small correction: in active directory its not the authentication server or KDC that decides if the user is allowed to access the service its requesting a ticket for - its up to the service on the file server etc to decide if the user is allowed in or not. All the KDC does is "guarantee" that the user is who they say they are. So yeah any user can request a ticket for any service that supports kerberos auth, which is a bit of a security issue because now anyone can get hold of some data that was encrypted using the password of the user account running that service, and they can then brute force that offline to get the password.
@@lawrencedoliveiro9104 sounds like it, but its the only version of Kerberos I've ever worked with so hard to say. Regardless, its the most commonly used version of kerberos in the world so its probably worth focusing on that when talking about security
Interesting, but there is one thing that makes no sense: at 12:18, the message that tells B what Kab is is encrypted with Kbt, which you say only T and B know. The problem is that B should not have Kbt, since only the S keys are long term, and A had to go through S to get Kat. Why does B know Kbt already? And if Kbt is another long term key like the S key, why is Kat not long term?
Two possibilities here: either Kbt is automatically genereated when B connect to the network and regularly updated, or Kbt is generated at the initiative of T whenever someone request access to B. I'm not a Kerberos expert so I don't know the correct answer but this bugged me too...
A and B don't have identical roles. B has previously registered as a Service Provider through a different process, usually involving at least some kind of manual approval by a network administrator.
@@lawrencedoliveiro9104 A lot of Romans also called their dogs "Nero" as an insult to the late emperor. The subject of dog names is going down a "rabbit hale"
@@the_hanged_clown Language evolution is a doozy. In ancient Greek it was kerberos, and in modern Greek it still mostly still is though the k and b have softened, but Latin had a bunch of weird sound changes that English inherited and continued that mutated the k and all the vowels.
This video helped in me in understanding kerberos in expert level...thanks for the very clear explanation i was able to finish my assignment because of this
@@riotmakerzify Normilarily IT security consultants aka Penetration Testers/Ethical Hackers most only have the knowledge of how to recognise a currently known vulnerability and use the tools available to exploit that vulnerability in the course of their work they mostly use known exploits and only a small percentage of them can find and use a zero day vulnerability, IT Security researchers are responsible for new encryption and other systems to protect networks and devices but they are also the same people throwing mud on walls to see what sticks aka finding problems in current systems. I myself am a infosec Consultant but the IT Science and IT Security Researchers are a different league of mythical beasts.
Great video, love the intuitive examples! just a quick note, Kerberos doesn't require a password for every client, it does however require a shared key with the KDC as you explained. and in various cases the client doesn't have an actual password, they just have a a shared secret (active directory magic), virtual machines in the cloud for example. and if a third party sends the KDC a request in a valid client's name, the KDC will answer anyway because it doesn't matter, since only the actual user can decrypt and use the answer of the KDC correct me if I'm mistaken, and Thanks for the great video! :)
Someone who knows, correct me if i'm wrong; So basically, per-user unique keys are stored in a central server (created when they first sign up), and this key generates more keys when user wants to talk to peripherals connected to the server. (peripherals as other users etc) If this is correct, my follow up question is, while the user is signing up the first time, how is his 'password' sent over? Public Key system? Then quantum cracking over first step will get the password & decrypt all the tickets the server produces later on.
I'd assume some side channel is used to set up an initial password or in a controlled environment, all users might start out with a default password that they are required to change immediately after the first authentication.
The initial password has to be setup on the authentication server when the user gets created. For example with Active Directory an account cannot be enabled until a password is assigned to it first.
AFAIK in the active directory and kerberos systems you don't sign up per se. An admin user registers a new account and gets given a temporary password which is to be changed upon first login. This way even on first authentication the password is already there which is used tp encrypt the communication.
Just want to make sure I'm understanding the bit at 13:50 correctly. So B sends back Ta+1 to A to prove that it was able to read the message (A,Ta) using Kab that it received?
2:57 - TFW Trying to explain computer stuff but you're actually summoning the devil. Jokes aside, thank you very much for this video. I have learned a lot from this channel in the preparation for my CISSP exam. These videos explain really things that the "official" books really don't (from my perspective).
One thing I don't understand, why does K_at need to be generated but K_bt is long-term? Or would K_at only and immediately be generated when A joins the system and K_bt missing would imply B not being present?
Really the only functional differences I can see is that: Oauth2 has some extra hoops it jumps through to allow user consent inputs Kerberos has some extra hoops it jumps through to avoid asymmetric crypto The TGS acts as a token refresher
An interesting thing that should be mentioned is that the that KaT key contains you list of group memberships so when accessing the file server it can do authorisation without contacting the domain controller.
Very nice explanation, but I had a couple questions if anybody could answer: 1) Why does the authentication and Ticket granting need to be done by two separate servers? Can't they be combined in a single server that authenticates and directly gives the ticket Kab? Why the additional hop to the ticket granting server (even if authentication and ticket granting services are on the same server, I am guessing this hop to the ticket granting service occurs)? This doesn't appear to be a massively expensive operation that the two services need to be separated. 2) How is the initial 'long term password' between the servers/computers exchanged? Surely that is the problem that public key encryption is needed to solve. Once both sides have a shared secret, symmetric key works just fine, but this video doesn't address how that initial password between the servers (or to the user) is exchanged securely. Thanks!
1) The idea is that the authentication and Ticket granting server can be updated independently. Without that, you would have to make the protocol complicated for different cases. 2)The long-term key is shared out of band. We don't care how the long-term key gets there.
Presumably, B has already been preloaded with the K_bt key upon installation/configuration, and does not need to talk to S. Otherwise, it did the same dual-step authentication A did ages ago, but as a trusted server, it was granted a longer-term ticket than client connections would be.
4:31 isn’t it authorization rather than authentication? Authentication only happens on Server S but doesn’t rly have anything to do with the ticket....
What encryption does it use and did this change over the decades? How is the very first key exchanged? Any protocol (that changed over decades?) or just whatever people wanted to use (floppy, pen&paper, ... DH)?
As someone else commented I would like to see a video on JSON Web Tokens. An extra plus would be if it also explained the whole refresh token mechanism which I think is much of the reason for why we are always logged in on different web services like Facebook, TH-cam, etc.
does the authentication server and the ticket server need to be separate services talked to separately? or is it just to optimize resources in some way, and would work _okay_ if they were just one service that did both jobs combined with computer A just talking to the server once?
They can be on the same server, but it is important that they are logically separate. For one thing keeping them modular allows you to have duplicates of either server, for load, and DOS defense purposes.
Initially, the authentication service and TGS were envisioned to be separate machines, but they are usually combined now. That's the reason for the separation in the first place, and the separation remains important now for optimization, as without that second step, the user would have to keep logging in every time they needed a new ticket.
you forget that's its a remote interview, well done! also i love a vid on my field of expertise and still has some new details for me, which causes me to tinker with AD a bit more. thanks! :)
The first time my machine gets a long term key I need to present the 'Server' with my username/password. How does the server then return the long term key to my machine without using asymmetric encryption?
Thank you, this is a great explanation! Can you do a Part 2 for this video explaining a 2-hop scenario? For example an AD user on their laptop requests data from server A, which then impersonates the AD user to request data from server B? I think many of my colleagues would watch it too.
No offence Sean, this is the best I've seen Mike lit and at this point, I've seen most of his videos with him, from pneumonia pale to pneumonia yellow.
B does not have a long term key with T right? B has a long term key with S. A had to contact S to get K_at, shouldn't B also have to connect with S to get K_bt?
And when you register to create your account, what kind of encryption does it use? Because the creation of the account seems to be quite important as well
I’m guessing this is an “out of band” thing. Either that or someone who already has an account connects to the server to create your account? My experience at work is that when they create your account, they assign a temporary password which you use to log in, and then you change your password.
@@eaglevisionboy2 At best very coarse. Very few services would take only the TGS word for authorization. In practice, something like "guest" or "authenticated" doesn't get one very far. AuthN != AuthZ
@@NyanSten Very loosely. TGS might know you have authz to "a file server", but the file server deny you read access to even the root directory listing.
B has to authenticate through S to create a key with T at some point, just like any other device. Difference is that the key it generates will last a lot longer usual before needing to be renewed again.
Well done boss. Just a small question, if you don't mid. How can the server b validate the message comes from server a without contacting the server S?
Just one question to fully understand this: How do encrypt a shared secret like K at symmetric and share it with T so T can decrypt the shared secret? Or is there no need to do this?
The shared secret is encrypted by the Ks,t a long term key that S and T use to communicate. It sends you it aka the ticket granting ticket which you send to T to begin talking to it
Why doesn't 'S' send the ticket granting ticket (first red message) to 't' itself instead of having 'a' send it to 't', similarly why doesn't 't' do that with 'b'?
In the case of Windows: the admin manually enters it into the AD when creating your account and hands it over to you via phone or piece of paper and you exchange it upon first login. Kerberos is for corporate intranets.
Hi, I'm a bit confused about A B and T and have 2 questions. From the video, A received a short-term K_at from S in order to talk to T. Later, T send A a key K_ab encrypted in K_bt. 1. The K_bt was said to be long-term. It is supposed to be short-term, right? 2. Similar to K_at being granted from S, K_bt should have been granted from S at an earlier time when B authenticated with S, right? Or is it some other time?
If "a" sends "b" a ticket encrypted with 'bt', how would "b" gets a ticket 'bt' from ticket granting server as it has 'bs' as long term key.. Will it go for authentication server and gets a ticket to communicate with ticket granting server?
If I followed along right, we start off assuming only a Kas exists and we need to get a Kat and give the t server this Kat. But then to talk to B the t server just talks to B with a Kbt? Where does this Kbt come from, how does the server contact you securely without passing through S first?
1st - Security. You need to hack both independent services to get the Network. (One is for auth, the other for access, you need both). 2nd - They have different performance requirements. T is being used all the time, S only when login. Would be bad your login is slow because the server is busy giving tickets to everyone. That way you can split them.
One of the things this video lacks is showing the previous versions of Kerberos. In previous versions t and s were the same, but the fact that they had to both authenticate and distribute tickets made them very slow, and vulnerable to DOS attacks.
How does S know the symmetric key of A to authenticate or in the first place? I know it's password based but how is the password synced between A and S securely?
I've rescued several townsfolk isolated in their homes by purging that three headed beast from their cache located in their home directory after which they were again, able to go to town and conduct business. On a different note, can you guys please talk about principle component analysis using a compressed representation or subspace neural physics. I want to hear more about it from you guys :)
But when A sends its password (maybe its hash rather than the password itself?) to S, it cannot send it openly and it must check that S is actually S before sending the credentials (the password or its hash). Thus A and S still need to use PKI and TLS in order to execute the first step of the protocol, needn't they?
Nope. The password is created in advance on S and is told to A. Thus A does not need to ever send it to S, instead S encrypts a response to A with A's password and if A can read such an encrypted response it means that A and S both agree on A's password, which authenticates them both: A now knows that the response actually came from S and S does not care who received its response because only A can read (decrypt) it. This means that S must store passwords (which are used as symmetric encryption keys) rather than their salted hashes as "usually" happens in the backends of various Internet services.
@@stIncMale They can be stored as hashes(and I think Active Directory stores as hashes by default, but you can choose to store a password with "reversible encryption" as an option), but that does essentially mean that the hash itself has become the password, since only the hash would be needed to authenticate.
@@Acorn_Anomaly Whatever is stored in S (whether a plain password or its hash, let's call this stored data keyA; we can ignore reversible encryption because if it is used then the decryption key has to be stored somewhere not hashed and not encrypted, which puts us in essentially the same situation as without encryption) is used to encrypt/decrypt messages from S to A, therefore keyA is a private credential on its own, thus it makes no sense to store the hash of the original password as in that case this hash will be the secret key and the password will be useless data from the standpoint of the described Kerberos protocol.
I was a bit worried at the beginning that the nonce isn't encrypted in the ticket request, but AIUI since you don't have Kas it doesn't matter, you can't decrypt Kat and get authorization to other services?
I love how Mike Pound explains cryptography. He's my favorite guy of all Computerphile, next to Tom Scott, that is.
Well said. Both Dr. Pound and Tom are the absolute best in an already extremely high quality pot of speakers.
not crypto, but obviously my third favourite guy is Professor Brailsford 😁
@@Gergely362 Brailsford is my favorite guy.
I agree!!
@@0megaSapphire did he say that in a Computerphile video, and not just in a Tom Scott video?
The separation between the S and T servers is the separation between _authentication_ (proving you are who you say you are, done by S) and _authorization_ (what services you are allowed to access, controlled by T). Each one can be updated independently.
In active directory though, neither of them seem to do authorization? Any user can get a ticket for any service. It's the service itself (file server etc) that determines if a user is allowed in, and that's completely independent of Kerberos. The Kerberos ticket just proves the user is who they claim to be
Thanks, I was confused why they were separated
I did reach the same observation, though I'm struggling to get the intuition behind this. Why did the inventor separate the 2 services?
My first thought is that having a copy of all identification info in *each* server may increase the chance of it getting compromised. However, storing all passwords in one server also introduces a single point of failure, so my thought about the inventor's intuition could be wrong.
VbScrub that is not true. In AD, Kerberos most certainly does authorisation. It’s the “Allowed to authenticate” right and if you don’t have that, the ticket is not produced, regardless of whether the resource would grant you access otherwise. If the account is “allowed to authenticate” and the ticket is produced, the resource can still perform its own authorisation. There’s more than one place where authorisation decisions are made.
specifically:
"I can confirm for a Windows Server 2016 deployment that “Allowed to Authenticate” has no effect on the KDC’s willingness to issue a TGS. I believe this is by design considering [MS-KILE] (3.3.5.7 TGS Exchange) states that the Allowed-to-Authenticate right is only checked if the TGT contains the OTHER_ORGANIZATION SID"
8:08 "My very well drawn curly brackets" -- damn right those are well drawn! That will make it extra secure.
strange how it sounds like he's saying it sarcastically but they actually are well drawn.
3:07 - “It’s an absolute mess”. Actually, it’s a full mesh! ... I will show myself out ...
This is HANDS DOWN the BEST description of how Kerberos works. Straight forward, easy to understand. I feel like I truly understand it now, vs just having a general idea of what it does. Thanks so much for this great content!!❤❤❤
I agree! this guy explains thing very well, and makes it all digestible.
We don’t deserve this guy fr
"B is just sitting on the network waiting for people to talk to it"
Same, B, same.
Acknowledged
I can't say this enough. I LOVE this channel and how well everything is explained! Dr. Pounds videos are my favorite as he's just so likable and amazing at his explanations. Keep up the amazing work everyone!
Hands-down the best explanation I've seen about kerberos auth mechanism on the internet.
This is a brilliant explanation! I've been working with KRB (MIT and Heimdal) and OpenAFS for a decade, but recently moved to (samba) AD. Kerberos is my friend! The most common failure of both is clock offsets! If the lifetime doesn't match or the timestamp is in the future, it throws funnies. never had any serious issues in those 10 years. KDCs just keep on working
Would love to see Dr. Mike Pound do a video on JSON Web Tokens!!
I'd love to see his take on a comparison of the cryptography and advantages of JWTs and its alternatives (PASETO, Branca, Macaroons)
Seconded!
That would be lovely
first heard of Kerberos nearly 30 years ago but never used it, this is the first time I've actually gotten a high-level overview that was super easy to understand - thank you!
It is worth mentioning that in AD, the authorization is split between the ticket granting service and the target resource (in this case the file server). The ticket will also carry information about group membership, which will allow the file server to determine whether the user trying to access it is allowed, or is a member of a group that is allowed to access the server. Also worth mentioning that because of all these timestamps floating around, it is imperative that all these systems have the same time.
12:48 I can just picture a lonely server spinning up disks that have been idle for years, like oh yea someone still wants me 😂
This is a decent retro perspective on hard coding server based authority networking. Thank you for your efforts.
Back in the early nineties we used this with Norvell for user based authentication for both bridges and simple internal routing via IPX.
Cool to see it being reimplimated for wide distribution systems. Our biggest concern back then was Chatterbox, inbound exchanges outside of our secured internal networks with disparate network protocols. IP was not a standard like today.
Woo, finally something I'm close to understanding and actually has something to do with my work.
The best and most in depth explanation of the Kerbaros protocol on TH-cam. Thank you!
For those wondering why the timestamp T is necessary throughout most of the video, wait until near the end where Mike explains that it's a way to defend against an imposter. It's perfectly understandable why this was discussed only near the end (13:53). Be patient, it's explained in the video.
Outstanding video. I have seen so many videos on Kerberos but could not understand them. This video made it crystal clear to me. Thank you very much.
3:01 Kerberos and mike draws a pentagram lol
What an elegant design! And well explained Professor!
One day, after doing a lot of reading and research, I nearly completely understood Kerberos. The next day, I’ve already forgotten most of it again...
this sounds like it could be a temporary key joke.
JNCressey Yeah, I thought that too.
Thank you so much Mike for these videos. I'm taking the security + right now and I would be lost without you. Your video's really help to solidify the text.
Great explanation as always. I've also made a few videos about kerberos myself recently, mainly demonstrating some of the ways to circumvent the security of it.
Oh and one small correction: in active directory its not the authentication server or KDC that decides if the user is allowed to access the service its requesting a ticket for - its up to the service on the file server etc to decide if the user is allowed in or not. All the KDC does is "guarantee" that the user is who they say they are. So yeah any user can request a ticket for any service that supports kerberos auth, which is a bit of a security issue because now anyone can get hold of some data that was encrypted using the password of the user account running that service, and they can then brute force that offline to get the password.
In other words, Active Directory is less secure than true Kerberos?
@@lawrencedoliveiro9104 sounds like it, but its the only version of Kerberos I've ever worked with so hard to say. Regardless, its the most commonly used version of kerberos in the world so its probably worth focusing on that when talking about security
Interesting, but there is one thing that makes no sense: at 12:18, the message that tells B what Kab is is encrypted with Kbt, which you say only T and B know. The problem is that B should not have Kbt, since only the S keys are long term, and A had to go through S to get Kat. Why does B know Kbt already? And if Kbt is another long term key like the S key, why is Kat not long term?
Two possibilities here: either Kbt is automatically genereated when B connect to the network and regularly updated, or Kbt is generated at the initiative of T whenever someone request access to B. I'm not a Kerberos expert so I don't know the correct answer but this bugged me too...
A and B don't have identical roles. B has previously registered as a Service Provider through a different process, usually involving at least some kind of manual approval by a network administrator.
Christian Barnay Sure, I guess it makes sense that B is treated differently than A, but they should have been more specific about it.
PSA: Kerberos means "Spotted One". Even millennia ago the tradition of naming your dog Spot was so strong that even the gods got in on it.
And “Fido” (faithful one) I think was a Latin tradition.
@@lawrencedoliveiro9104 A lot of Romans also called their dogs "Nero" as an insult to the late emperor. The subject of dog names is going down a "rabbit hale"
We all know that the only proper name for a dog is "Dogmeat".
is the original actually pronounced "kerberos"? I've only ever seen it spelt "cerberos" and pronounced "serb" lol have I been wrong for 30 years?
@@the_hanged_clown Language evolution is a doozy. In ancient Greek it was kerberos, and in modern Greek it still mostly still is though the k and b have softened, but Latin had a bunch of weird sound changes that English inherited and continued that mutated the k and all the vowels.
Where is alice, bob, charlie, and debbie these days, anyway? I heard all about their problems in school for computer science.
They have to maintain social distancing.
They're visiting our Dear Aunt Sally, of course!
I usually hear the latter two as Carol and David.
I am so glad I can watch videos made by geniuses. And I admire your modesty as well.
Dr Mike ... please do a similar video for SAML [2.0] and federated identity management! You make everything so clear.
Thank you. This was a great description of Kerberos. I wish I had had it many years ago when I read the original paper.
This video helped in me in understanding kerberos in expert level...thanks for the very clear explanation i was able to finish my assignment because of this
There is one thing I don't get: Why does B have a long term key with T (Kbt) while A does not? Doesn't B have to go through the TGT process as well?
I think that was a mistake, and it's actually supposed to be a session key. But maybe it could be because B is a server and so presumably always on
Got to say your excellent in the way you explain, not that you need it but a big thumbs up from me . 👍🏻
Great video, so well put and easy to understand. I imagine this is how Jared would look if he had decided to go down the tech road and not biz dev.
every time I develop a solution and find myself having to deal with Kerberos, I look the other way because it's so scary.
take a shot everytime he says ticket
The ticket granting ticket is going to kill me
Joshua Rombauer help
Every time he sneaks in an ‘alright’
@@dl8590 That's actually the lethal one I'd wager :D
I'm certified in cybersecurity.... I thought I had this up to the 9:10 mark. Then I realized I had no idea what the hell was going on
Well it really is the researchers that do the heavy lifting in cybersec
@@amb1u5 explain please
@@riotmakerzify Normilarily IT security consultants aka Penetration Testers/Ethical Hackers most only have the knowledge of how to recognise a currently known vulnerability and use the tools available to exploit that vulnerability in the course of their work they mostly use known exploits and only a small percentage of them can find and use a zero day vulnerability, IT Security researchers are responsible for new encryption and other systems to protect networks and devices but they are also the same people throwing mud on walls to see what sticks aka finding problems in current systems. I myself am a infosec Consultant but the IT Science and IT Security Researchers are a different league of mythical beasts.
Amb1u5 "mythical beasts", nice one.
@@riotmakerzify Basically Researchers are like mechanical engineers and IT are like car mechanics.
I like Mikes videos! Keep it up Computerphile!
Great video, love the intuitive examples!
just a quick note, Kerberos doesn't require a password for every client, it does however require a shared key with the KDC as you explained.
and in various cases the client doesn't have an actual password, they just have a a shared secret (active directory magic), virtual machines in the cloud for example.
and if a third party sends the KDC a request in a valid client's name, the KDC will answer anyway because it doesn't matter, since only the actual user can decrypt and use the answer of the KDC
correct me if I'm mistaken, and Thanks for the great video! :)
Such a beautiful topic. Amazingly explained!
Someone who knows, correct me if i'm wrong;
So basically, per-user unique keys are stored in a central server (created when they first sign up), and this key generates more keys when user wants to talk to peripherals connected to the server. (peripherals as other users etc)
If this is correct, my follow up question is, while the user is signing up the first time, how is his 'password' sent over? Public Key system? Then quantum cracking over first step will get the password & decrypt all the tickets the server produces later on.
I was thinking the same question ;o;
I'd assume some side channel is used to set up an initial password or in a controlled environment, all users might start out with a default password that they are required to change immediately after the first authentication.
The initial password has to be setup on the authentication server when the user gets created. For example with Active Directory an account cannot be enabled until a password is assigned to it first.
AFAIK in the active directory and kerberos systems you don't sign up per se. An admin user registers a new account and gets given a temporary password which is to be changed upon first login. This way even on first authentication the password is already there which is used tp encrypt the communication.
So the KDC doesn't actually hold the user’s password, just a set of keys derived from the principles password. Is that right?
Just want to make sure I'm understanding the bit at 13:50 correctly. So B sends back Ta+1 to A to prove that it was able to read the message (A,Ta) using Kab that it received?
Your videos are the reason why I'm subscribed to this channel
2:57 - TFW Trying to explain computer stuff but you're actually summoning the devil.
Jokes aside, thank you very much for this video. I have learned a lot from this channel in the preparation for my CISSP exam. These videos explain really things that the "official" books really don't (from my perspective).
I've been waiting for the video!
One thing I don't understand, why does K_at need to be generated but K_bt is long-term? Or would K_at only and immediately be generated when A joins the system and K_bt missing would imply B not being present?
brilliant mechanism and brilliant explaination , thank you.
I had to implement Kerberos SSO support for the software that my company makes. I had no idea what all the settings did, but now it all makes sense.
Nice quality "at home" video! Quite a rarity at the moment!
This pattern vaguely looks like the Authorization Code Flow for OAuth 2.0. Pretty neat! 👍
Really the only functional differences I can see is that:
Oauth2 has some extra hoops it jumps through to allow user consent inputs
Kerberos has some extra hoops it jumps through to avoid asymmetric crypto
The TGS acts as a token refresher
An interesting thing that should be mentioned is that the that KaT key contains you list of group memberships so when accessing the file server it can do authorisation without contacting the domain controller.
only in AD, groups (and for that matter system users) aren't part of the kerberos protocol
Speaking of Kat, A had to go through S to get that, so how does B know Kbt when A sends it a message encrypted with that?
Very nice explanation, but I had a couple questions if anybody could answer:
1) Why does the authentication and Ticket granting need to be done by two separate servers? Can't they be combined in a single server that authenticates and directly gives the ticket Kab? Why the additional hop to the ticket granting server (even if authentication and ticket granting services are on the same server, I am guessing this hop to the ticket granting service occurs)? This doesn't appear to be a massively expensive operation that the two services need to be separated.
2) How is the initial 'long term password' between the servers/computers exchanged? Surely that is the problem that public key encryption is needed to solve. Once both sides have a shared secret, symmetric key works just fine, but this video doesn't address how that initial password between the servers (or to the user) is exchanged securely.
Thanks!
1) The idea is that the authentication and Ticket granting server can be updated independently. Without that, you would have to make the protocol complicated for different cases.
2)The long-term key is shared out of band. We don't care how the long-term key gets there.
Have I understood correctly: B has a long term ticket from T, but A does not. Why is that? Are they exchanged without involvement from S?
Presumably, B has already been preloaded with the K_bt key upon installation/configuration, and does not need to talk to S. Otherwise, it did the same dual-step authentication A did ages ago, but as a trusted server, it was granted a longer-term ticket than client connections would be.
@@eddievhfan1984 The server doesn’t need any tickets; only the client does.
Kyle Tekaucic But if B can get a long-term key with T, why does A need to go through S to get it?
A never gets that key. It only gets tickets encrypted with that key.
A wonderful video on how Kerberos works!
Mike you should be a Professor at MIT or Harvard ! You are the best !
Really good Kerberos overview! Nice job.
Dr. Pound at home? Checks out. That is almost certainly the home decor of a computer scientist ;)
What is inside that terrarium behind you my dude?
a three-headed dog
4:31 isn’t it authorization rather than authentication? Authentication only happens on Server S but doesn’t rly have anything to do with the ticket....
So clear and helpful, thank you Mike once again.
What encryption does it use and did this change over the decades?
How is the very first key exchanged? Any protocol (that changed over decades?) or just whatever people wanted to use (floppy, pen&paper, ... DH)?
As someone else commented I would like to see a video on JSON Web Tokens. An extra plus would be if it also explained the whole refresh token mechanism which I think is much of the reason for why we are always logged in on different web services like Facebook, TH-cam, etc.
Your best video Mike.
Wonderful video!
I don't get how the long term key Kas is shared between the Kerberos server and computer A.
@1:05; Wait, is Kerberos a different three headed dog than Cerberus?
That pause after he realized he accidentally drew a pentagram has me rolling.
Mikes face in the thumbnail looks like he was just selected as tribute to fight actual Kerobos
does the authentication server and the ticket server need to be separate services talked to separately? or is it just to optimize resources in some way, and would work _okay_ if they were just one service that did both jobs combined with computer A just talking to the server once?
They can be on the same server, but it is important that they are logically separate. For one thing keeping them modular allows you to have duplicates of either server, for load, and DOS defense purposes.
Initially, the authentication service and TGS were envisioned to be separate machines, but they are usually combined now.
That's the reason for the separation in the first place, and the separation remains important now for optimization, as without that second step, the user would have to keep logging in every time they needed a new ticket.
you forget that's its a remote interview, well done!
also i love a vid on my field of expertise and still has some new details for me, which causes me to tinker with AD a bit more. thanks! :)
a week and a half into kerberos delegation bug, prayers appreciated
The first time my machine gets a long term key I need to present the 'Server' with my username/password. How does the server then return the long term key to my machine without using asymmetric encryption?
Your machine generates the Kas key the same way that S did using your account credentials.
The classic sleeve adjustment lives on in the remote world
When I saw him using a tabulation paper with those green lines I subscribed immediately 😊
Thank you, this is a great explanation! Can you do a Part 2 for this video explaining a 2-hop scenario? For example an AD user on their laptop requests data from server A, which then impersonates the AD user to request data from server B? I think many of my colleagues would watch it too.
No offence Sean, this is the best I've seen Mike lit and at this point, I've seen most of his videos with him, from pneumonia pale to pneumonia yellow.
Fair comment, we'll have to get a dining room window installed in the other end of Mike's office :)
B does not have a long term key with T right? B has a long term key with S. A had to contact S to get K_at, shouldn't B also have to connect with S to get K_bt?
How is the very first request from A to S encrypted? I.e. how is the long term key negotiated/shared?
When he started drawing a pentagram I thought he was going to summon kerberos
And when you register to create your account, what kind of encryption does it use? Because the creation of the account seems to be quite important as well
I’m guessing this is an “out of band” thing.
Either that or someone who already has an account connects to the server to create your account?
My experience at work is that when they create your account, they assign a temporary password which you use to log in, and then you change your password.
Compelled to say that Kerberos provides authentication (proof of identity), but little to no implied authorization (access permissions by policy).
At 11 minutes he touched on Authorization.
KDC (S) provides authentication, TGS (T) provides authorisation
@@eaglevisionboy2 At best very coarse. Very few services would take only the TGS word for authorization. In practice, something like "guest" or "authenticated" doesn't get one very far.
AuthN != AuthZ
@@NyanSten Very loosely. TGS might know you have authz to "a file server", but the file server deny you read access to even the root directory listing.
Question: Does B have a permanent Ktb key, or how did it get hold of it??
B has to authenticate through S to create a key with T at some point, just like any other device. Difference is that the key it generates will last a lot longer usual before needing to be renewed again.
Well done boss. Just a small question, if you don't mid. How can the server b validate the message comes from server a without contacting the server S?
Just one question to fully understand this:
How do encrypt a shared secret like K at symmetric and share it with T so T can decrypt the shared secret? Or is there no need to do this?
The shared secret is encrypted by the Ks,t a long term key that S and T use to communicate. It sends you it aka the ticket granting ticket which you send to T to begin talking to it
Why doesn't 'S' send the ticket granting ticket (first red message) to 't' itself instead of having 'a' send it to 't', similarly why doesn't 't' do that with 'b'?
0:56
Kerberos
1:40
Kerberos vs AD.
3:14
No Public Key.
4:32
Communication.
5:24
KDC.
--->
*5:56 1st server
*6:05 2nd server
*7:47 key {encryption}
*8:31 ticket-granting ticket
*9:34 fire and forget
*10:36 2nd server key
*11:23 3rd server key
*12:02 2nd key for 3rd.
*12:58 decryption
*13:29 request.
*14:15 review
*15:00 security.
Kas is for example my hashed password but how does it go securely to the server S in the first place
In the case of Windows: the admin manually enters it into the AD when creating your account and hands it over to you via phone or piece of paper and you exchange it upon first login. Kerberos is for corporate intranets.
Hi, I'm a bit confused about A B and T and have 2 questions. From the video, A received a short-term K_at from S in order to talk to T. Later, T send A a key K_ab encrypted in K_bt.
1. The K_bt was said to be long-term. It is supposed to be short-term, right?
2. Similar to K_at being granted from S, K_bt should have been granted from S at an earlier time when B authenticated with S, right? Or is it some other time?
If "a" sends "b" a ticket encrypted with 'bt', how would "b" gets a ticket 'bt' from ticket granting server as it has 'bs' as long term key.. Will it go for authentication server and gets a ticket to communicate with ticket granting server?
B is a machine, not a user. B will have already established the key Kbt to talk with T before waiting for connections from users such as A.
How do you get SAML to work with Kerberos?
5:06 The way you draw computers has the same problem as the save button: computers don't really look like that any longer.
But save buttons still look like that !
If I followed along right, we start off assuming only a Kas exists and we need to get a Kat and give the t server this Kat. But then to talk to B the t server just talks to B with a Kbt? Where does this Kbt come from, how does the server contact you securely without passing through S first?
this guy is amazing at explaining
I don't understand the benefit of having t and S be separate things.
Two separate simple services is better than one complex multi purpose service. Run parallel better. They can even be on separate computers.
1st - Security. You need to hack both independent services to get the Network. (One is for auth, the other for access, you need both).
2nd - They have different performance requirements. T is being used all the time, S only when login. Would be bad your login is slow because the server is busy giving tickets to everyone. That way you can split them.
One benefit would be minimizing the use of long term key.
One of the things this video lacks is showing the previous versions of Kerberos. In previous versions t and s were the same, but the fact that they had to both authenticate and distribute tickets made them very slow, and vulnerable to DOS attacks.
You can also have different people/departments having access to the two.
I was indeed expecting Mike Pound to have a terrarium. But I do not see the animal inside? What is it?
If "ticket server" sends Kbt{Kab, A, L}, and if A knows Kab, A and L-- A can get Kbt... right?
How does S know the symmetric key of A to authenticate or in the first place? I know it's password based but how is the password synced between A and S securely?
Could you guys do a video on prime order elliptic curves and their applications in commitment schemes, and zero knowledge proofs?
8:30 And you can also verify n[a], to guard against fraudulent responses.
I've rescued several townsfolk isolated in their homes by purging that three headed beast from their cache located in their home directory after which they were again, able to go to town and conduct business.
On a different note, can you guys please talk about principle component analysis using a compressed representation or subspace neural physics. I want to hear more about it from you guys :)
But when A sends its password (maybe its hash rather than the password itself?) to S, it cannot send it openly and it must check that S is actually S before sending the credentials (the password or its hash). Thus A and S still need to use PKI and TLS in order to execute the first step of the protocol, needn't they?
Nope. The password is created in advance on S and is told to A. Thus A does not need to ever send it to S, instead S encrypts a response to A with A's password and if A can read such an encrypted response it means that A and S both agree on A's password, which authenticates them both: A now knows that the response actually came from S and S does not care who received its response because only A can read (decrypt) it. This means that S must store passwords (which are used as symmetric encryption keys) rather than their salted hashes as "usually" happens in the backends of various Internet services.
@@stIncMale They can be stored as hashes(and I think Active Directory stores as hashes by default, but you can choose to store a password with "reversible encryption" as an option), but that does essentially mean that the hash itself has become the password, since only the hash would be needed to authenticate.
@@Acorn_Anomaly Whatever is stored in S (whether a plain password or its hash, let's call this stored data keyA; we can ignore reversible encryption because if it is used then the decryption key has to be stored somewhere not hashed and not encrypted, which puts us in essentially the same situation as without encryption) is used to encrypt/decrypt messages from S to A, therefore keyA is a private credential on its own, thus it makes no sense to store the hash of the original password as in that case this hash will be the secret key and the password will be useless data from the standpoint of the described Kerberos protocol.
I was a bit worried at the beginning that the nonce isn't encrypted in the ticket request, but AIUI since you don't have Kas it doesn't matter, you can't decrypt Kat and get authorization to other services?