Hi folks, Ed Amoroso here. I want to take you through on this and some subsequent videos, protocol called Kerberos. I'll bet you've heard of it. It's a popular protocol. It's built into Windows and a lot of different software that I'm sure you've used. Now let me tell you about the idea. So a group of students at MIT some number of years ago. Who decided that what the wanted to do, they were students and administrators, that what they wanted to do was pull passwords off the network. Meaning, if Alice wants to log into Bob over the MIT network, or any campus or enterprise network, can I set the protocol up so that no clear text passwords are flying around? Seems like that would be simple, but it turns out to be quite a challenge, [LAUGH] build a protocol to make that work. And what they required was something called a key distribution center. Now listen, we haven't really, in our sequence of videos, gotten to pure cryptography, sort of explaining and defining crypto. That's coming. But I like the idea of showing you protocols before we do the definitions. because it makes it more interesting when you get to the definitions, that can be crushingly dull. So I like doing some things first and you seeing it. So bear with me as we go through the notation and kind of the concepts that are embedded in Kerberos. Now, the first thing is, there's this key distribution center, and then there's a bunch of participants and we can, as we usually do, break them up into a bunch of clients or users and a bunch of servers. Are you okay with that? Servers, clients, key distribution center, campus or enterprise network. Not the Internet. This is something that would have some nonsignificant scaling, okay? So here's the way it works, the key distribution center sets up private keys with each participant. So Alice gets some K sub a that the key distribution center gives to Alice. Bob the server gets K sub b that the key distribution center gives to Bob, and so on for everyone. Also, there are clocks. Everybody's got a synchronized clock. [COUGH] That's going to be important, because it'll help us in some sense make sure that we don't have sort of cheating in the protocol. So everybody follow, we've got clocks, everybody's got keys. And the idea is that, Alice, Bob, whomever's using Kerberos, it's okay to type a password into a local machine. But we don't want passwords on the network. That's the goal. Keep passwords off the local area network because as you've learned, anybody with a sniffer, with a computer that just accepts packets or messages, can read your password. So it's not a good idea passwords flying over the network, so here's the way it works. In the first step, Alice typed the password in to Kerberos, logs in, Kerberos checks it. No passwords over networks, but you're kind of quote unquote logging into Kerberos. The next thing that will happen is that Alice's machine will send the standard message defined an by Internet request for comments, RFC, an interesting concept in how you define standards, to the key distribution center, saying Alice needs this thing called the ticket generating ticket. It's like a ticket to get tickets to get to Bob, does that makes sense? So, what'll happen in that TGT generation is that the first thing that key distribution center will do is it will generate something called a session key for Alice. Now here's the idea, Alice's K sub a is called the root key, that's a base secret we don't want anybody to know. But once Alice wants to try logging into something, we're going to use the base secret, K sub a, to generate a more temporary secret called a session secret or session key. The idea being, [SOUND] if somebody breaks the session key, well, it messes up the session, but at least they didn't get our root key. You follow? In cryptography, we want keys to be as short-lived as possible. You want to use longer-lived, or root keys, to generate short-lived session keys, so that's one of the things that gets put in this ticket generating ticket, this TGT. So think of it essentially as a message that's encrypted, signed by the key distribution center. But the way it's going to be signed is a weird sort of way. Rather than signing it the way you might expect using the key distribution center's key, it's going to sign it with Alice's key, okay? And then send it over to Alice. Now if Eve is watching what's going on, she's not going to be able to read the message that goes back to TGT because it's signed with Alice's key, with K sub a. And in there will be this temporary session key. So what happens is, Alice basically visits the key distribution center, says, hey, can I have a ticket-generating ticket? And there's also some authentication that may be going on using the clocks that might be encrypting the clock message to ensure that there's no timing problems. Could be a man in the middle grabbing a message and then passing it along, we'll set that aside. But the idea, the goal here, the first part of Kerberos, is to get a ticket generating ticket, a TGT across to Alice that she can then use to request access to Bob at some point. That make sense? Now it's sort of your additional consideration as you ponder Kerberos, because we're going to go further, that's the first part of kerberos. Subsequent video will pick it up from there, as Alice tries to do something, but do you think that's kind of complicated? I have to go through these steps, getting a session key, and maybe doing some authentication using the synchronized clocks and other types of things. Do you think that's a lot of work, just to get ready to ultimately log into Bob? I mean you're used to just login, password. [LAUGH] Now, I'm going through this setup to get some cryptography in place so that I can then do some other way of logging in. Think about that, because complexity may not be such a bad thing if it's hidden. If the complexity's embedded in some functionality, but to the user it's still pretty simple, that may not be terrible. So think about that as you ponder Kerberos. We'll come back with part two of Kerberos, picking up from the TGT generation from our key distribution center. I'll see you on the next one.
