Hi, folks. We're back for part two of our discussion of Kerberos. And I recall, in the first video we got to the point where Alice was able to get this ticket-generating ticket, this TGT. So now, Alice would like to request some way of communicating with Bob. Logging into Bob, and doesn't want to use a password. Interestingly enough, the way the RC's written actually refer to the ticket that you'll get for Bob as a ticket to Bob. Sorry, that's the name. Well, we'll call it TBOB. So Alice, basically, says to the Key Distribution Center, "Hey, I'd like to connect to TBOB. Can you give me something there?" And I'm also going to use the clock to sort of synchronize using the session key they gave me last time. So now, you recall, we got rid of the root key, didn't get rid of it, but we've agreed we're going to use our session key now for communication. So I send off an authenticator to the Key Distribution Center, basically the clock encrypted, with my request to connect to Bob. And by the way, I don't have to encrypt that request because Kerberos is not about traffic analysis prevention, it's about keeping passwords off the network. So bad guys, like Eve, want to watch to see that I'm connecting to Bob. That's not Kerberos' problem. Don't worry about that. So it says, "Hey, it won't connect to Bob." So what does KDC do now? KDC, Key Distribution Center, it now creates a joint session key for me and Bob. It's kind of a cool concept. The KDC is friends with Bob, has a secret with Bob, the KDC is friends with Alice, has secret with Alice. Alice says, "Hey I'd like to connect to Bob" And by the way, she provides the ticket-generating ticket which she could not have gotten if she hadn't had K_sub_B in the previous step. So she's proven, "Look, I'm giving you TGT. I'm really me." So now, the Key Distribution Center can say, "I know you, I know you, here, I'm going to give you a secret to give to him." but the KDC is going to wrap that secret in Bob's key. And if I can provide that to Alice and she presents it to Bob, Bob goes, "Wow, you've got something that was encrypted with my secret. You must have gotten it from the KDC cause you sure didn't get it from me." Isn't that kind of a cool thing? It's called this arbitration. That's how the Key Distribution Center works. So, session key, essentially, S_sub_AB and it wraps that in a signed message. And you can see that on screen, we've got some little shots here of the different protocols going back and forth. You can see that we're setting this up so that Eve can't see what's going on. That's the whole idea. You don't what Eve to get in there and see this. But ultimately, when I get this thing back over to Alice, she then has TBOB. She has the session key as a baby because she can decrypt that, it's sent back with us today. And this TBOB is encrypted with K_sub_B. So now, what do you think? You were just what you would expect when it's time to log into Bob, all she's got to do is take a message, encrypt it with, it's already encrypted K_sub_B, that's the TBOB. But she can encrypt it with S_sub_AB which allows Bob then, when he uses K_sub_B to decrypt TBOB, he gets S_sub_AB which then be used to decrypt the time that's sent over. Wow, is that complicated? You'll probably want to go back and look at the charts here. And we've got some materials that we recommend that you can look at to dig through Kerberos. But I want to give you a little pep talk, and we're at the point now where the Kerberos session is in set up. Alice and Bob have a Session Key. Kerberos is as complicated as it gets. If you're sitting there going, I don't get this. Well, join the crowd. Everybody gets confused by this one. This is hard. If you can go back, re-watch this video a couple of times, do a little bit of analysis on your own and get to where you understand that handshake, that Alice-Bob handshake, using the KDC, I can't think of a protocol, an authentication protocol anyway, that's more complicated than this. And I would ask you, as a sort of additional consideration, do you think that's reasonable? I mean, this really complicated stuff. Now, one other thing I'd like you to ponder is the idea of how this would scale and you can see it doesn't scale well to the Internet. Why? Who's the KDC going to be? Is it going to be the government of a country where you are in? Is it going to be Wal-Mart? Is it going to be Google? Well, that's the problem. Nobody has questioned that. They came up with this concept called the realms, r-e-a-l-m. If English is not your main language, realm is like a group or a circle or a community or a realm. It's a weird word but Kerberos had this concept of realms where one KDC would do its community. Another KDC would do its community. And if you're over here, you're Alice, and you ask your KDC for a connection to a server that's over here. The KDC checks around, "Oh is that one my servers? No." It'll ask another KDC: "Hey, is this your server?" And you can imagine how a hierarchical structure could be used so that you could traverse the tree efficiently to find the server. And, that hasn't really been the way Kerberos has gone. Kerberos has tended to be much more useful for enterprise campus applications than for big, old, internet-type things and why? The reason is public key cryptography, which turns out to be so much more flexible and scalable. And we're going to spend some really fun time going through public key cryptography. So, we'll see on the next video.
