WEBVTT 00:00:00.080 --> 00:00:02.430 The following content is provided under a Creative 00:00:02.430 --> 00:00:03.820 Commons license. 00:00:03.820 --> 00:00:06.060 Your support will help MIT OpenCourseWare 00:00:06.060 --> 00:00:10.150 continue to offer high quality educational resources for free. 00:00:10.150 --> 00:00:12.690 To make a donation or to view additional materials 00:00:12.690 --> 00:00:16.600 from hundreds of MIT courses, visit MIT OpenCourseWare 00:00:16.600 --> 00:00:17.260 at ocw.mit.edu. 00:00:26.340 --> 00:00:29.150 PROFESSOR: So today, we're going to talk about Kerberos, which 00:00:29.150 --> 00:00:32.750 is a cryptographically secure, in some ways, 00:00:32.750 --> 00:00:36.210 protocol for authenticating computers 00:00:36.210 --> 00:00:38.671 and applications to one another over the network. 00:00:38.671 --> 00:00:40.670 So this is now finally going to use cryptography 00:00:40.670 --> 00:00:42.490 whereas last lecture, we looked at just 00:00:42.490 --> 00:00:46.242 using these TCP sequence numbers to provide security. 00:00:46.242 --> 00:00:47.700 So before we dive into the details, 00:00:47.700 --> 00:00:49.825 I want to mention there's two bits of administrivia 00:00:49.825 --> 00:00:51.970 that you might want to know. 00:00:51.970 --> 00:00:55.020 There's a quiz review today 7 to 9 o'clock in some room, 00:00:55.020 --> 00:00:56.570 I think 32 or 23. 00:00:56.570 --> 00:00:59.910 It's on schedule page and the quiz is next Wednesday. 00:00:59.910 --> 00:01:01.760 And also, we want you guys to post 00:01:01.760 --> 00:01:03.900 some idea for your final project on Piazza 00:01:03.900 --> 00:01:07.800 by tomorrow just so that your classmates can 00:01:07.800 --> 00:01:12.435 know what you're thinking and help you form groups. 00:01:12.435 --> 00:01:14.560 All right, so let's talk about Kerberos, all right? 00:01:14.560 --> 00:01:16.580 So what is the setting that Kerberos 00:01:16.580 --> 00:01:19.360 is trying to support, here? 00:01:19.360 --> 00:01:21.900 So the model for Kerberos, what these guys 00:01:21.900 --> 00:01:23.680 had in mind when they were designing 00:01:23.680 --> 00:01:26.600 Athena guess 25 or 30 years ago now, 00:01:26.600 --> 00:01:28.360 is that they were imagining they were 00:01:28.360 --> 00:01:30.680 going to have a network with many server machines 00:01:30.680 --> 00:01:33.790 and many client machines interacting with one another. 00:01:33.790 --> 00:01:36.290 So you could imagine, well, you have a file server somewhere 00:01:36.290 --> 00:01:37.150 out there. 00:01:37.150 --> 00:01:41.140 You probably have a mail server connected to the network, maybe 00:01:41.140 --> 00:01:45.130 other services-- printer. 00:01:45.130 --> 00:01:50.510 And all these are just connected to some sort of a network 00:01:50.510 --> 00:01:54.500 rather than being processes on a single machine. 00:01:54.500 --> 00:01:57.497 So the prelude to Athena and Kerberos 00:01:57.497 --> 00:01:59.580 is that you just have a time sharing machine where 00:01:59.580 --> 00:02:02.050 everything was a single process and everyone would just 00:02:02.050 --> 00:02:05.760 log into the same system and store their files there. 00:02:05.760 --> 00:02:08.830 So these guys wanted a more distributed system. 00:02:08.830 --> 00:02:12.360 So this meant that you'd have these servers on one side 00:02:12.360 --> 00:02:14.730 and you'd also have a bunch of workstations 00:02:14.730 --> 00:02:18.207 that users would use themselves which 00:02:18.207 --> 00:02:19.790 would run applications and potentially 00:02:19.790 --> 00:02:22.360 connect to these servers and store the user's files, 00:02:22.360 --> 00:02:24.560 get their mail et cetera. 00:02:24.560 --> 00:02:26.800 And the problem that they wanted to solve 00:02:26.800 --> 00:02:28.520 was how to authenticate the users that 00:02:28.520 --> 00:02:31.590 are using these workstations to all these different servers 00:02:31.590 --> 00:02:34.270 in the back end without having to trust the network 00:02:34.270 --> 00:02:36.890 to be correct, which seems like a sensible design 00:02:36.890 --> 00:02:40.010 requirement in many ways. 00:02:40.010 --> 00:02:42.890 And I should mention that I guess 00:02:42.890 --> 00:02:44.580 the alternative to Kerberos at the time 00:02:44.580 --> 00:02:46.187 was these R login commands that we're 00:02:46.187 --> 00:02:48.520 looking at in last lecture, which seems like a bad plan. 00:02:48.520 --> 00:02:51.860 They just use IP addresses to authenticate the users. 00:02:51.860 --> 00:02:54.330 And Kerberos was reasonably successful. 00:02:54.330 --> 00:02:56.160 It actually still is used at MIT. 00:02:56.160 --> 00:02:59.280 And actually, it's the basis of Microsoft's Active Directory 00:02:59.280 --> 00:02:59.780 server. 00:02:59.780 --> 00:03:03.450 So pretty much every Microsoft based sort of Windows Server 00:03:03.450 --> 00:03:05.921 uses Kerberos in some form or another. 00:03:05.921 --> 00:03:07.420 But of course, because this protocol 00:03:07.420 --> 00:03:11.720 was designed 25 or 30 years ago, requirements change. 00:03:11.720 --> 00:03:14.352 What people assume change. 00:03:14.352 --> 00:03:16.310 People now understand much more about security. 00:03:16.310 --> 00:03:19.050 So their version of Kerberos that's in use today 00:03:19.050 --> 00:03:21.770 is noticeably different in many ways 00:03:21.770 --> 00:03:23.860 from the version in the paper. 00:03:23.860 --> 00:03:27.520 And we'll look at exactly what assumptions aren't good enough 00:03:27.520 --> 00:03:30.432 anymore today and what did they get wrong. 00:03:30.432 --> 00:03:32.390 It's sort of inevitable for any protocol that 00:03:32.390 --> 00:03:34.650 was the first protocol to really use cryptography 00:03:34.650 --> 00:03:37.460 to authenticate parties over the network in this sort 00:03:37.460 --> 00:03:40.810 of full system scale. 00:03:40.810 --> 00:03:43.422 Anyway, so that's the sort of setting for Kerberos. 00:03:43.422 --> 00:03:45.130 And it might be interesting to figure out 00:03:45.130 --> 00:03:46.379 what's the trust model, right? 00:03:46.379 --> 00:03:49.910 So Kerberos is going to introduce this extra Kerberos 00:03:49.910 --> 00:03:51.450 server sitting on the side. 00:03:55.240 --> 00:03:58.040 So our third model at some level is 00:03:58.040 --> 00:04:00.710 that the network is untrusted like we were 00:04:00.710 --> 00:04:03.420 thinking about in last lecture. 00:04:03.420 --> 00:04:06.745 But who do we have to trust in this Kerberos setting? 00:04:09.700 --> 00:04:14.650 So of course, one thing is everyone-- all parties have 00:04:14.650 --> 00:04:16.230 to trust the Kerberos server. 00:04:18.574 --> 00:04:20.199 So that's an assumption these guys were 00:04:20.199 --> 00:04:22.657 willing to make at the time that this Kerberos server would 00:04:22.657 --> 00:04:24.915 be in charge of all network authentication 00:04:24.915 --> 00:04:27.435 in some form or another. 00:04:27.435 --> 00:04:29.930 Do we have anyone else that has to trust anything 00:04:29.930 --> 00:04:30.670 in the setting? 00:04:33.210 --> 00:04:33.960 For example, yeah. 00:04:33.960 --> 00:04:36.304 STUDENT: Well users should trust their own machines. 00:04:36.304 --> 00:04:38.220 PROFESSOR: Yes, so that's a good point, right? 00:04:38.220 --> 00:04:41.030 There's the users that I didn't draw here. 00:04:41.030 --> 00:04:43.780 But these guys are using some workstation. 00:04:43.780 --> 00:04:46.150 And it's actually pretty important in Kerberos 00:04:46.150 --> 00:04:50.199 that the user trusts their workstation. 00:04:50.199 --> 00:04:52.490 So what goes wrong if you don't trust your workstation? 00:04:52.490 --> 00:04:54.406 Or presumably, it can just sniff your password 00:04:54.406 --> 00:04:59.405 and do whatever you type-- you know, LS, it tries-- runs RMX. 00:04:59.405 --> 00:05:01.950 That seems kind of unfortunate. 00:05:01.950 --> 00:05:02.664 Yeah. 00:05:02.664 --> 00:05:04.330 STUDENT: But it's more than that though, 00:05:04.330 --> 00:05:07.020 because they could even, like, sniff your Kerberos ticket. 00:05:07.020 --> 00:05:07.590 PROFESSOR: Yeah, exactly. 00:05:07.590 --> 00:05:09.710 Or when you log in, you type in your password, which 00:05:09.710 --> 00:05:10.960 is even worse than the ticket. 00:05:10.960 --> 00:05:12.240 Yeah, absolutely, yeah. 00:05:12.240 --> 00:05:15.490 So this is actually a bit of a problem with Kerberos 00:05:15.490 --> 00:05:19.050 in the sense that if you don't trust the workstation, then 00:05:19.050 --> 00:05:21.050 you're in a bit of trouble. 00:05:21.050 --> 00:05:23.200 So if you have your own laptop, this 00:05:23.200 --> 00:05:25.030 seems like a sensible assumption to make. 00:05:25.030 --> 00:05:27.140 If you're using a public computer, 00:05:27.140 --> 00:05:28.485 this is a bit more questionable. 00:05:28.485 --> 00:05:30.860 And we'll see exactly what could go wrong. 00:05:30.860 --> 00:05:31.683 Yeah. 00:05:31.683 --> 00:05:34.641 STUDENT: You have to trust the people administrating aren't 00:05:34.641 --> 00:05:37.106 doing anything bad with [INAUDIBLE] servers 00:05:37.106 --> 00:05:39.972 and giving them privilege access to one another. 00:05:39.972 --> 00:05:41.180 STUDENT: So what do you mean? 00:05:41.180 --> 00:05:43.220 So of course, like, ISNT is going 00:05:43.220 --> 00:05:46.010 to run these machines down here. 00:05:46.010 --> 00:05:48.300 But I think the machines themselves don't necessarily 00:05:48.300 --> 00:05:49.850 have to trust one another. 00:05:49.850 --> 00:05:53.010 So the mail server doesn't trust the print server or the file 00:05:53.010 --> 00:05:54.908 server necessarily. 00:05:54.908 --> 00:05:56.366 STUDENT: Not to trust, but he might 00:05:56.366 --> 00:05:58.294 be able to access a server you're not 00:05:58.294 --> 00:06:01.497 supposed to have access to by going through another server. 00:06:01.497 --> 00:06:03.080 PROFESSOR: Yeah, that's true, I guess. 00:06:03.080 --> 00:06:05.040 Yeah, so if you set up any trust relationship 00:06:05.040 --> 00:06:07.360 between these guys-- like, if you give the mail server 00:06:07.360 --> 00:06:11.530 some back end to go access your files just for convenience, 00:06:11.530 --> 00:06:13.140 then this could be abused, yeah. 00:06:13.140 --> 00:06:16.400 So you have to be careful about not introducing 00:06:16.400 --> 00:06:20.990 additional sort of levels of trust or trust relations here. 00:06:20.990 --> 00:06:25.100 All right, anything else that matters here? 00:06:25.100 --> 00:06:27.090 Do the servers have to trust the users 00:06:27.090 --> 00:06:29.210 in any way or the workstations? 00:06:31.776 --> 00:06:32.900 No, I guess presumably not. 00:06:32.900 --> 00:06:35.920 So this was the whole goal that the server 00:06:35.920 --> 00:06:38.160 doesn't have to a priori even know necessarily 00:06:38.160 --> 00:06:40.320 what all these users or how to authenticate them 00:06:40.320 --> 00:06:43.220 or what this workstation is doing until it can 00:06:43.220 --> 00:06:47.100 cryptographically prove that this is a legitimate user 00:06:47.100 --> 00:06:51.460 and they should have access to their data or whatnot. 00:06:51.460 --> 00:06:53.600 All right, so let's look at how does Kerberos work 00:06:53.600 --> 00:06:57.340 or what's the overall architecture, at least. 00:06:57.340 --> 00:07:01.200 So the plan that these guys had in mind 00:07:01.200 --> 00:07:03.500 is that there would be this Kerberos server. 00:07:03.500 --> 00:07:05.470 We have drawn it up there but let's draw it 00:07:05.470 --> 00:07:07.300 in a slightly bigger scale. 00:07:07.300 --> 00:07:10.540 So this is the Kerberos server. 00:07:10.540 --> 00:07:16.650 And today, it's typically called KDC-- Key Distribution Center. 00:07:16.650 --> 00:07:22.430 And there's all these users out here somewhere and also 00:07:22.430 --> 00:07:26.840 services that you might want to connect to. 00:07:26.840 --> 00:07:30.860 And the plan is that the Kerberos server 00:07:30.860 --> 00:07:34.650 is going to be responsible for storing a shared 00:07:34.650 --> 00:07:39.070 key between the Kerberos server and every entity in the world, 00:07:39.070 --> 00:07:41.080 or in this realm at least. 00:07:41.080 --> 00:07:45.885 So if the user has some sort of a key KC for client, 00:07:45.885 --> 00:07:47.260 than the Kerberos server is going 00:07:47.260 --> 00:07:49.720 to remember this key somewhere here. 00:07:49.720 --> 00:07:53.680 And similarly for the server, the key KS 00:07:53.680 --> 00:07:56.080 is going to be known to the service itself 00:07:56.080 --> 00:07:59.300 and to the Kerberos server but hopefully no one else. 00:07:59.300 --> 00:08:02.020 So you can think of it as like a generalization of passwords, 00:08:02.020 --> 00:08:02.520 right? 00:08:02.520 --> 00:08:04.440 So you know a password and the Kerberos server 00:08:04.440 --> 00:08:05.940 knows your password but no one else. 00:08:05.940 --> 00:08:08.790 And this is how you guys are going to prove to each other, 00:08:08.790 --> 00:08:10.130 yeah, I'm the right guy. 00:08:10.130 --> 00:08:13.000 I know this password and no one else does. 00:08:13.000 --> 00:08:14.150 Makes sense? 00:08:14.150 --> 00:08:17.982 And the other thing the Kerberos server is going to have to do 00:08:17.982 --> 00:08:20.070 is, of course, keep track of who is 00:08:20.070 --> 00:08:22.370 it that owns this key, right? 00:08:22.370 --> 00:08:27.080 So it's going to have this table mapping some sort of a name. 00:08:27.080 --> 00:08:29.080 So this is some sort of a user. 00:08:29.080 --> 00:08:35.630 This is maybe service maybe AFS or something like this. 00:08:35.630 --> 00:08:38.530 And the KDC is responsible for storing the gigantic table-- 00:08:38.530 --> 00:08:41.659 well, not very large in terms of the number of bytes, 00:08:41.659 --> 00:08:45.640 necessarily, but one entry per entity 00:08:45.640 --> 00:08:50.310 at MIT that the Kerberos server knows about. 00:08:50.310 --> 00:08:52.510 Makes sense? 00:08:52.510 --> 00:08:56.634 All right, and then we're going to have sort of provide 00:08:56.634 --> 00:08:57.550 two interfaces, right? 00:08:57.550 --> 00:09:00.200 The paper is a little fuzzy above this 00:09:00.200 --> 00:09:02.200 or it pretends like there's really two services. 00:09:02.200 --> 00:09:05.260 But really, what's going on is that there's two interfaces 00:09:05.260 --> 00:09:06.660 to the same machine. 00:09:06.660 --> 00:09:11.560 One of them is called Kerberos in the paper and one of them 00:09:11.560 --> 00:09:15.460 is called TGS for Ticket Granting Service. 00:09:15.460 --> 00:09:16.980 And really, these are just two ways 00:09:16.980 --> 00:09:20.130 of talking to the same thing in the back end. 00:09:20.130 --> 00:09:24.340 And the protocol is a little different for these things. 00:09:24.340 --> 00:09:26.570 So initially, when the user logs in, 00:09:26.570 --> 00:09:28.680 they're going to talk to this guy over here. 00:09:28.680 --> 00:09:32.110 And they're going to send their client name, 00:09:32.110 --> 00:09:35.160 C. So this might be your Athena username. 00:09:35.160 --> 00:09:36.810 And the server is going to respond 00:09:36.810 --> 00:09:43.804 to back with a ticket, a TGS or-- well, 00:09:43.804 --> 00:09:44.720 some sort of a ticket. 00:09:44.720 --> 00:09:46.540 We'll look at the details in a bit. 00:09:46.540 --> 00:09:51.130 And then when you want to talk to some server down here, 00:09:51.130 --> 00:09:54.040 KS, then you're going to talk to this TGS first 00:09:54.040 --> 00:09:56.530 and say, oh, hey, I already logged in 00:09:56.530 --> 00:09:58.560 through the Kerberos interface. 00:09:58.560 --> 00:10:00.770 Now, I want to talk to the server S. 00:10:00.770 --> 00:10:03.560 So you'd tell the TGS about the server you want to talk to. 00:10:03.560 --> 00:10:08.330 And then it returns you back some sort of a ticket 00:10:08.330 --> 00:10:12.780 for talking to the server S. And then you can finally 00:10:12.780 --> 00:10:15.600 start talking to the server over here 00:10:15.600 --> 00:10:22.230 by initially passing it this ticket for S. 00:10:22.230 --> 00:10:23.902 Does this all make sense? 00:10:23.902 --> 00:10:27.270 This is the sort of high level plan. 00:10:27.270 --> 00:10:30.335 So why do these guys have two interfaces? 00:10:32.967 --> 00:10:34.550 Well, I guess I wanted to actually ask 00:10:34.550 --> 00:10:35.425 a bunch of questions. 00:10:35.425 --> 00:10:38.080 Like, in the case of a service, this service 00:10:38.080 --> 00:10:39.770 is probably going to be stored on disk. 00:10:39.770 --> 00:10:42.330 What's going on with this KC on the user side? 00:10:42.330 --> 00:10:46.240 Where does KC come from in Kerberos? 00:10:46.240 --> 00:10:47.574 Yeah. 00:10:47.574 --> 00:10:50.740 STUDENT: KDMS [INAUDIBLE] the database. 00:10:50.740 --> 00:10:52.736 PROFESSOR: Yeah, well, the key C sits here. 00:10:52.736 --> 00:10:53.860 And that's absolutely true. 00:10:53.860 --> 00:10:55.420 It's sits on this giant database. 00:10:55.420 --> 00:10:57.280 But it also has to be known to the user 00:10:57.280 --> 00:10:59.610 because the user has to prove that they are the user. 00:10:59.610 --> 00:11:00.326 Yeah. 00:11:00.326 --> 00:11:02.030 STUDENT: Is that a one way function and then the password? 00:11:02.030 --> 00:11:03.405 PROFESSOR: Yeah, so they actually 00:11:03.405 --> 00:11:05.930 have this sort of cute plan where the KC is actually 00:11:05.930 --> 00:11:09.100 going to be derived by hashing the user's password 00:11:09.100 --> 00:11:11.320 or really some sort of key duration function. 00:11:11.320 --> 00:11:14.444 And there's several different ones of perverse uses. 00:11:14.444 --> 00:11:16.360 But you're basically going to take a password, 00:11:16.360 --> 00:11:20.676 transform it in some way, and get this key KC. 00:11:20.676 --> 00:11:25.180 All right, so that seems good. 00:11:25.180 --> 00:11:27.010 Why do we need two protocols, right? 00:11:27.010 --> 00:11:32.020 You could imagine that you just always ask the Kerberos server 00:11:32.020 --> 00:11:33.292 for tickets directly this way. 00:11:33.292 --> 00:11:34.750 You say, well, hey, I want a ticket 00:11:34.750 --> 00:11:36.730 for this particular principle name. 00:11:36.730 --> 00:11:39.070 And it'll send you back a ticket and you can decrypt it 00:11:39.070 --> 00:11:41.440 with your KC afterwards. 00:11:41.440 --> 00:11:41.940 Yeah. 00:11:41.940 --> 00:11:44.861 STUDENT: Can you [INAUDIBLE] or ask the user 00:11:44.861 --> 00:11:46.527 to reenter their password each time they 00:11:46.527 --> 00:11:47.740 want to [INAUDIBLE] service? 00:11:47.740 --> 00:11:49.823 PROFESSOR: Right, so the reason for the difference 00:11:49.823 --> 00:11:52.440 between these two interfaces is that on this interface, 00:11:52.440 --> 00:11:56.170 all the responses come back encrypted with your key KC. 00:11:56.170 --> 00:11:59.500 And the Kerberos designers are a little worried 00:11:59.500 --> 00:12:03.070 about keeping this KC around for a long time. 00:12:03.070 --> 00:12:05.260 Because either you have to ask the user to enter it, 00:12:05.260 --> 00:12:07.730 which is just annoying for the user, 00:12:07.730 --> 00:12:09.330 or it sits around in memory. 00:12:09.330 --> 00:12:12.400 And this is basically as good as the user's password. 00:12:12.400 --> 00:12:17.730 So if this gets disclosed, then someone with access to KC 00:12:17.730 --> 00:12:20.675 can keep accessing the user's files until the user maybe 00:12:20.675 --> 00:12:22.800 changes their password and potentially even longer. 00:12:22.800 --> 00:12:25.300 We'll see about that. 00:12:25.300 --> 00:12:28.570 So this KC is a really dangerous thing to leak. 00:12:28.570 --> 00:12:31.580 So the whole point of using this interface first and using 00:12:31.580 --> 00:12:34.270 this interface later for all subsequent requests 00:12:34.270 --> 00:12:36.790 is that you can actually forget KC 00:12:36.790 --> 00:12:40.430 as soon as you decrypt this TGS response from the Kerberos 00:12:40.430 --> 00:12:41.980 interface. 00:12:41.980 --> 00:12:44.600 And from that point on, even if you leak it, 00:12:44.600 --> 00:12:46.994 there is a lifetime associated with this ticket. 00:12:46.994 --> 00:12:48.410 So worst case, someone gets access 00:12:48.410 --> 00:12:50.160 to your account for a couple of hours, 00:12:50.160 --> 00:12:53.359 not for an unbounded amount of time. 00:12:53.359 --> 00:12:54.900 So that's the sort of main difference 00:12:54.900 --> 00:12:59.020 why you guys have this slightly more complicated picture 00:12:59.020 --> 00:13:03.190 with two ways of accessing the same thing. 00:13:03.190 --> 00:13:06.360 All right, so before we dive into the mechanics of how 00:13:06.360 --> 00:13:08.900 these protocols actually look like on the wire, 00:13:08.900 --> 00:13:13.060 let's talk a little bit about this naming aspect in Kerberos, 00:13:13.060 --> 00:13:13.560 right? 00:13:13.560 --> 00:13:16.100 So at some level, you could think of Kerberos 00:13:16.100 --> 00:13:18.530 as being a name registry, right? 00:13:18.530 --> 00:13:20.680 So it's really responsible for mapping 00:13:20.680 --> 00:13:24.090 these cryptographic keys onto string names. 00:13:24.090 --> 00:13:27.459 And this is the fundamental sort of operation 00:13:27.459 --> 00:13:28.750 that Kerberos needs to provide. 00:13:28.750 --> 00:13:31.467 In fact, you'll see in the next lecture even on the web, 00:13:31.467 --> 00:13:32.800 we need some function like this. 00:13:32.800 --> 00:13:34.550 It's implemented differently from Kerberos 00:13:34.550 --> 00:13:36.570 but this is a fundamentally very important thing 00:13:36.570 --> 00:13:39.060 to have in almost any distributed system 00:13:39.060 --> 00:13:40.510 for security. 00:13:40.510 --> 00:13:45.080 So let's look at how Kerberos actually deals with names. 00:13:45.080 --> 00:13:49.440 So in Kerberos, the sort of system 00:13:49.440 --> 00:13:53.560 calls every entity in this database a principal 00:13:53.560 --> 00:13:56.920 And a principal in Kerberos is actually just a string, right? 00:13:56.920 --> 00:13:59.780 So you can actually have some principal like, I don't know, 00:13:59.780 --> 00:14:00.885 nickolei. 00:14:00.885 --> 00:14:01.720 So that's a string. 00:14:01.720 --> 00:14:05.170 And that could be a principal in some Kerberos realm. 00:14:05.170 --> 00:14:06.850 So it would literally be the thing 00:14:06.850 --> 00:14:12.000 that sits in this left column of the KDC's table. 00:14:12.000 --> 00:14:16.007 And there's also some extra instances 00:14:16.007 --> 00:14:17.090 that the protocl supports. 00:14:17.090 --> 00:14:20.200 I could say, you know, nikolai.extra secure 00:14:20.200 --> 00:14:22.740 or something. 00:14:22.740 --> 00:14:25.930 And I might use this as a different entity 00:14:25.930 --> 00:14:27.960 for machines I really care about. 00:14:27.960 --> 00:14:29.810 So maybe I will have a different password 00:14:29.810 --> 00:14:31.940 for really secure things and a different password 00:14:31.940 --> 00:14:34.120 for my regular account. 00:14:34.120 --> 00:14:37.110 So this is just sort of how Kerberos-- 00:14:37.110 --> 00:14:40.690 this is what the paper talks about with instances. 00:14:40.690 --> 00:14:42.190 So one might actually wonder-- where 00:14:42.190 --> 00:14:43.440 do you actually see instances? 00:14:43.440 --> 00:14:45.440 Where do influences come from? 00:14:45.440 --> 00:14:49.930 So the Kerberos service maps names to keys for you, 00:14:49.930 --> 00:14:51.940 but how do you know which name to ask for 00:14:51.940 --> 00:14:56.600 or which name to expect when you are talking to some machine? 00:14:56.600 --> 00:15:00.720 So I guess what I'm asking is, what are names appear outside 00:15:00.720 --> 00:15:03.050 of the Kerberos machine. 00:15:03.050 --> 00:15:06.256 So I guess we could ask, OK, where do user names appear? 00:15:06.256 --> 00:15:07.701 Any ideas? 00:15:07.701 --> 00:15:08.200 Yeah. 00:15:08.200 --> 00:15:10.525 STUDENT: You can ask the MIT server for usernames 00:15:10.525 --> 00:15:11.812 presumably. 00:15:11.812 --> 00:15:12.770 PROFESSOR: Right, yeah. 00:15:12.770 --> 00:15:13.900 So you could enumerate these things. 00:15:13.900 --> 00:15:15.350 Also, the users just type them in when 00:15:15.350 --> 00:15:16.349 they log into a machine. 00:15:16.349 --> 00:15:18.480 So that's where it initially comes from. 00:15:18.480 --> 00:15:21.020 Do usernames appear anywhere else? 00:15:21.020 --> 00:15:23.652 Should they appear anywhere else? 00:15:23.652 --> 00:15:24.152 Yeah. 00:15:24.152 --> 00:15:26.084 STUDENT: Possibly access the [INAUDIBLE] 00:15:26.084 --> 00:15:27.494 lists on the various services. 00:15:27.494 --> 00:15:29.910 PROFESSOR: Yes, that's actually an important point, right? 00:15:29.910 --> 00:15:33.850 The goal of Kerberos is just to map keys to names. 00:15:33.850 --> 00:15:36.440 But it doesn't tell you what that name should have access 00:15:36.440 --> 00:15:37.020 to. 00:15:37.020 --> 00:15:38.950 In fact, the way the applications typically 00:15:38.950 --> 00:15:42.900 use Kerberos is that one of these servers 00:15:42.900 --> 00:15:45.730 uses Kerberos to figure out, OK, what string name am I 00:15:45.730 --> 00:15:46.290 talking to? 00:15:46.290 --> 00:15:48.290 So when the mail server gets a connection 00:15:48.290 --> 00:15:50.920 from some workstation and it get the Kerberos ticket that 00:15:50.920 --> 00:15:54.220 prove that maybe this user is called Nikolai, 00:15:54.220 --> 00:15:56.110 then the mail server internally now 00:15:56.110 --> 00:15:57.630 has to figure out, OK, well, what 00:15:57.630 --> 00:15:59.280 should that guy have access to? 00:15:59.280 --> 00:16:00.960 And same for a file server. 00:16:00.960 --> 00:16:03.150 So inside of all these servers, there's 00:16:03.150 --> 00:16:07.900 probably things like access control lists, maybe groups, 00:16:07.900 --> 00:16:11.770 maybe other things that actually do the authorization step. 00:16:11.770 --> 00:16:14.770 So Kerberos provides authentication 00:16:14.770 --> 00:16:17.690 which tells you who is this person I'm talking to. 00:16:17.690 --> 00:16:20.580 And the service itself is responsible for implementing 00:16:20.580 --> 00:16:23.870 the authorization part where they decide what access 00:16:23.870 --> 00:16:28.180 you should have based on your username here. 00:16:28.180 --> 00:16:30.440 Makes sense? 00:16:30.440 --> 00:16:33.500 All right, so that's where the user names appear. 00:16:33.500 --> 00:16:35.100 There's also other principal names 00:16:35.100 --> 00:16:37.400 the Kerberos supports for services, right? 00:16:37.400 --> 00:16:39.890 So services, I guess the paper suggests, 00:16:39.890 --> 00:16:41.380 look something like this. 00:16:41.380 --> 00:16:42.270 That's rcmd.hostname. 00:16:47.910 --> 00:16:53.589 And the reason that you need a name for one of these services 00:16:53.589 --> 00:16:55.380 is that you want to know, for example, when 00:16:55.380 --> 00:16:58.980 I connect to a file server, I actually 00:16:58.980 --> 00:17:01.500 want mutual authentication. 00:17:01.500 --> 00:17:04.160 It's not just the final server learns who I am, 00:17:04.160 --> 00:17:06.288 but I, the user or the workstation, 00:17:06.288 --> 00:17:08.579 want to be convinced that I'm talking to the right file 00:17:08.579 --> 00:17:10.599 server and not some fake file server that's 00:17:10.599 --> 00:17:11.880 impersonating my files. 00:17:11.880 --> 00:17:14.109 Because maybe I'll look at the grades 00:17:14.109 --> 00:17:15.690 file and submit it to the registrar. 00:17:15.690 --> 00:17:17.964 It would be too bad if some file server 00:17:17.964 --> 00:17:21.319 can impersonate the response and give me the wrong grades file 00:17:21.319 --> 00:17:23.020 all of a sudden. 00:17:23.020 --> 00:17:25.500 So this is why the service principles also 00:17:25.500 --> 00:17:29.770 need their own name and the workstations need to figure out 00:17:29.770 --> 00:17:34.120 what name should I expect to see when I connect to the service. 00:17:34.120 --> 00:17:36.500 And typically, this comes from the user at some level. 00:17:36.500 --> 00:17:41.010 So for example, if I type SSH some machine foo, 00:17:41.010 --> 00:17:44.150 then this means that I should be expecting 00:17:44.150 --> 00:17:47.100 a Kerberos principal called rcmd.foo 00:17:47.100 --> 00:17:49.000 on the other end of this connection. 00:17:49.000 --> 00:17:51.210 And if it turns out to be someone else, 00:17:51.210 --> 00:17:53.240 this SSH client should abort and not 00:17:53.240 --> 00:17:56.040 let me connect because then I will be misled into talking 00:17:56.040 --> 00:17:57.936 to some other machine. 00:17:57.936 --> 00:18:00.392 That make sense? 00:18:00.392 --> 00:18:01.850 So here's one interesting question. 00:18:01.850 --> 00:18:04.365 When can we reuse names in Kerberos? 00:18:04.365 --> 00:18:06.940 It's like, all of you guys have Athena accounts. 00:18:06.940 --> 00:18:08.960 And when you graduate, could MIT, 00:18:08.960 --> 00:18:11.480 like, wipe out your database entry 00:18:11.480 --> 00:18:14.130 and allow someone else to register that same username? 00:18:14.130 --> 00:18:16.600 Would that be a good idea? 00:18:16.600 --> 00:18:19.290 Well, aside from the fact that you guys want accounts. 00:18:19.290 --> 00:18:19.790 Yeah. 00:18:19.790 --> 00:18:23.205 STUDENT: Updated services as well so that they would, 00:18:23.205 --> 00:18:25.593 like map that username to [INAUDIBLE] permission 00:18:25.593 --> 00:18:26.176 theoretically? 00:18:26.176 --> 00:18:28.470 PROFESSOR: Yeah, because these guys are actually 00:18:28.470 --> 00:18:32.580 just string entries somewhere in some ACL on a file 00:18:32.580 --> 00:18:33.950 server on a mail server. 00:18:33.950 --> 00:18:37.340 And just because you wipe out this entry in the Kerberos 00:18:37.340 --> 00:18:40.075 database doesn't mean that this entry is gone. 00:18:40.075 --> 00:18:41.950 And they're not versioning in any way, right? 00:18:41.950 --> 00:18:43.658 This entry could literally say, you know, 00:18:43.658 --> 00:18:47.270 Alice has access to some Athena locker. 00:18:47.270 --> 00:18:50.999 And if this Alice graduates and her entry gets removed, 00:18:50.999 --> 00:18:52.790 then some new Alice comes along, registers, 00:18:52.790 --> 00:18:54.770 in the Kerberos database. 00:18:54.770 --> 00:18:56.570 But she gets a principal that looks 00:18:56.570 --> 00:18:57.895 identical to the old Alice. 00:18:57.895 --> 00:18:58.770 It's the same string. 00:18:58.770 --> 00:19:00.370 So all of a sudden, the file server 00:19:00.370 --> 00:19:04.740 will give access to the new Alice to old Alice's data. 00:19:04.740 --> 00:19:06.620 So there's a bit of a complicated process 00:19:06.620 --> 00:19:09.650 for reclaiming principal names in Kerberos 00:19:09.650 --> 00:19:11.160 because there's no real connection 00:19:11.160 --> 00:19:12.869 or versioning between these guys. 00:19:12.869 --> 00:19:14.410 So as a result, it's actually kind of 00:19:14.410 --> 00:19:16.749 hard to reuse principal names. 00:19:16.749 --> 00:19:18.540 Once you register a principal, you probably 00:19:18.540 --> 00:19:22.160 don't want to reuse it very often. 00:19:22.160 --> 00:19:25.930 And same for, in some sense, these principal names 00:19:25.930 --> 00:19:27.020 for service as well. 00:19:27.020 --> 00:19:30.910 As long as this hostname remain some well-known service 00:19:30.910 --> 00:19:33.040 that people expect to function in a certain way, 00:19:33.040 --> 00:19:34.920 you probably don't want to get rid of its key 00:19:34.920 --> 00:19:35.940 even if the service goes on. 00:19:35.940 --> 00:19:38.398 Because maybe a year later, some guy tries to connect to it 00:19:38.398 --> 00:19:39.581 and expects certain things. 00:19:39.581 --> 00:19:41.580 And if it's been reused for a different service, 00:19:41.580 --> 00:19:44.130 that guy can impersonate things. 00:19:44.130 --> 00:19:47.620 Probably not as dramatic or as bad, but still, 00:19:47.620 --> 00:19:50.420 you have to be careful with reusing principal names 00:19:50.420 --> 00:19:52.910 in this kind of protocol. 00:19:52.910 --> 00:19:53.940 Makes sense? 00:19:53.940 --> 00:19:56.140 Any questions? 00:19:56.140 --> 00:19:59.590 All right, so let's look at how the protocol itself now works. 00:19:59.590 --> 00:20:02.780 So we'll look first and this step of the protocol 00:20:02.780 --> 00:20:06.160 where you initially get your ticket with your password. 00:20:06.160 --> 00:20:09.170 And then we'll look at how this TGS interface works 00:20:09.170 --> 00:20:12.660 and how it differs then a little bit. 00:20:12.660 --> 00:20:15.280 All right, so I guess there's this main data 00:20:15.280 --> 00:20:17.790 structure that Kerberos uses called a ticket. 00:20:17.790 --> 00:20:21.660 And this ticket looks like this. 00:20:21.660 --> 00:20:25.270 So there's a ticket to between a client and a server. 00:20:25.270 --> 00:20:28.510 And this guy is basically the names 00:20:28.510 --> 00:20:30.550 of the server and the client that we're 00:20:30.550 --> 00:20:36.190 talking about-- the IP address of the client, 00:20:36.190 --> 00:20:43.050 some kind of timestamp, and an expiration time for how long 00:20:43.050 --> 00:20:44.260 the stick is valid. 00:20:44.260 --> 00:20:48.400 And there's also a key, KCS, that's 00:20:48.400 --> 00:20:51.860 going to be shared between the client and the server. 00:20:51.860 --> 00:20:53.790 So that's what's in a ticket. 00:20:53.790 --> 00:20:56.610 And there's also this other weird data structure 00:20:56.610 --> 00:20:59.380 that Kerberos introduces called an authenticator. 00:20:59.380 --> 00:21:03.590 And an authenticator goes with a particular client C. 00:21:03.590 --> 00:21:06.530 And this thing is just the client's name, 00:21:06.530 --> 00:21:11.640 the IP address of the client, and the time stamp 00:21:11.640 --> 00:21:15.210 when the client generated this authenticator. 00:21:15.210 --> 00:21:18.270 And typically, both of these things are encrypted. 00:21:18.270 --> 00:21:20.520 And authenticator is typically scripted 00:21:20.520 --> 00:21:23.760 with the key between the client on the server. 00:21:23.760 --> 00:21:25.670 So the authenticator sort of has to do 00:21:25.670 --> 00:21:29.110 with a particular connection between a client and a server. 00:21:29.110 --> 00:21:31.550 And the Kerberos ticket itself here 00:21:31.550 --> 00:21:38.140 is typically encrypted with the key for the service KS. 00:21:38.140 --> 00:21:41.010 So the subscript notation denotes here 00:21:41.010 --> 00:21:45.050 encryption with a particular key. 00:21:45.050 --> 00:21:48.470 All right, so what does this-- so using this sort of notation 00:21:48.470 --> 00:21:50.670 here, let's try to figure out what is the protocol. 00:21:50.670 --> 00:21:53.650 By which the user initially logs into this Kerberos 00:21:53.650 --> 00:21:56.010 and gets their TGS ticket. 00:21:56.010 --> 00:21:59.240 So as we saw here before, right, the plan 00:21:59.240 --> 00:22:06.030 is the client is going to send their username over 00:22:06.030 --> 00:22:10.130 to the Kerberos server or that interface. 00:22:10.130 --> 00:22:12.140 And the response is going to be a ticket. 00:22:12.140 --> 00:22:13.760 And what precisely the client actually 00:22:13.760 --> 00:22:17.710 sends over-- both the username C of the client that's 00:22:17.710 --> 00:22:22.150 issuing the request as well as the principal name-- well, 00:22:22.150 --> 00:22:23.760 the client is also a principal name. 00:22:23.760 --> 00:22:25.840 But the client also sends the principal name 00:22:25.840 --> 00:22:29.720 of the service for which it would like to get a ticket. 00:22:29.720 --> 00:22:32.880 And typically, the service name is actually the service name 00:22:32.880 --> 00:22:34.700 of this TGS guy over here. 00:22:34.700 --> 00:22:36.150 So you get a ticket for them. 00:22:36.150 --> 00:22:38.191 But you could get a ticket for almost any service 00:22:38.191 --> 00:22:39.700 you want in this way. 00:22:39.700 --> 00:22:42.430 And their response is going to be 00:22:42.430 --> 00:22:44.380 this sort of interesting tuple. 00:22:44.380 --> 00:22:47.030 It's going to be your ticket between the client 00:22:47.030 --> 00:22:50.930 and the server encrypted just with that key KS 00:22:50.930 --> 00:22:53.560 as shown above. 00:22:53.560 --> 00:22:56.170 I guess we should write that down with KS 00:22:56.170 --> 00:23:01.140 And also, you get to this shared key-- key CS. 00:23:01.140 --> 00:23:06.180 And this whole thing is encrypted with KC. 00:23:06.180 --> 00:23:08.690 So that's the wire protocol. 00:23:08.690 --> 00:23:11.190 So I guess let's try to figure out a couple things. 00:23:11.190 --> 00:23:17.770 So first of all, how does the Kerberos server 00:23:17.770 --> 00:23:19.020 authenticate the client here? 00:23:19.020 --> 00:23:20.910 How does it know that this is the right user making 00:23:20.910 --> 00:23:21.451 this request? 00:23:24.395 --> 00:23:24.895 Yeah. 00:23:24.895 --> 00:23:27.128 STUDENT: It can make sure that the ticket 00:23:27.128 --> 00:23:29.100 that it sent because it has KC. 00:23:29.100 --> 00:23:31.020 PROFESSOR: Yes, I think that's what's going on 00:23:31.020 --> 00:23:32.960 is that the Kerberos server again on some level actually 00:23:32.960 --> 00:23:35.540 doesn't know whether this is the right client or not. 00:23:35.540 --> 00:23:37.500 But it thinks oh, well, sure, it doesn't matter 00:23:37.500 --> 00:23:38.930 who is making this request. 00:23:38.930 --> 00:23:41.780 I'll just send this blob out and the only person 00:23:41.780 --> 00:23:44.010 who should be able to make any use of this blob 00:23:44.010 --> 00:23:48.170 is the person that knows this key KC over here. 00:23:48.170 --> 00:23:50.432 So that's actually kind of cool because the client 00:23:50.432 --> 00:23:51.890 doesn't have to send their password 00:23:51.890 --> 00:23:53.790 over the network at all. 00:23:53.790 --> 00:23:56.650 So in some ways, this is actually better than the client 00:23:56.650 --> 00:23:58.800 sending a password to the Kerberos server 00:23:58.800 --> 00:24:01.710 because even if the Kerberos server here 00:24:01.710 --> 00:24:03.960 was listening for these passwords 00:24:03.960 --> 00:24:06.710 and trying to record them, it would never get your password. 00:24:06.710 --> 00:24:08.900 Or maybe if someone was impersonating the Kerberos 00:24:08.900 --> 00:24:13.000 server, they wouldn't get a copy of your password. 00:24:13.000 --> 00:24:14.090 All right, yeah. 00:24:14.090 --> 00:24:17.380 STUDENT: [INAUDIBLE] adversary wants to [INAUDIBLE] 00:24:17.380 --> 00:24:20.200 your password offline without-- 00:24:20.200 --> 00:24:23.020 PROFESSOR: Yeah, so this is actually not a great aspect 00:24:23.020 --> 00:24:24.322 of Kerberos, in fact, right? 00:24:24.322 --> 00:24:26.030 So does everyone see what the problem is? 00:24:26.030 --> 00:24:28.430 The problem is that the way the client could 00:24:28.430 --> 00:24:30.180 tell if they got the right password or not 00:24:30.180 --> 00:24:32.520 or the workstation tells if the client supplied 00:24:32.520 --> 00:24:35.320 the right password is they try to decrypt this ticket 00:24:35.320 --> 00:24:37.760 and they see if it works or not. 00:24:37.760 --> 00:24:41.080 And decryption is fairly cheap. 00:24:41.080 --> 00:24:42.700 This is symmetric encryption and you 00:24:42.700 --> 00:24:45.060 can do probably millions of decryptions 00:24:45.060 --> 00:24:49.460 a second if you try hard on modern machines. 00:24:49.460 --> 00:24:52.300 And this means that you can try millions 00:24:52.300 --> 00:24:54.020 of potential passwords per second 00:24:54.020 --> 00:24:56.497 to guess what the person's password is. 00:24:56.497 --> 00:24:58.330 And you could do this for any person at all. 00:24:58.330 --> 00:25:00.372 You could just send their principal 00:25:00.372 --> 00:25:01.330 to the Kerberos server. 00:25:01.330 --> 00:25:03.999 It'll very happily give you back this response encrypted 00:25:03.999 --> 00:25:05.040 with the user's password. 00:25:05.040 --> 00:25:07.590 Then you can just try different passwords and just see what 00:25:07.590 --> 00:25:08.740 works or what doesn't. 00:25:08.740 --> 00:25:09.798 Yeah. 00:25:09.798 --> 00:25:12.786 STUDENT: But won't the content [INAUDIBLE] 00:25:12.786 --> 00:25:14.778 decrypted [INAUDIBLE] advantage? 00:25:14.778 --> 00:25:16.752 How can we be sure that you directly-- 00:25:16.752 --> 00:25:19.210 PROFESSOR: Yes, this is actually another interesting aspect 00:25:19.210 --> 00:25:21.360 where the Kerberos 4 developers didn't quite 00:25:21.360 --> 00:25:24.300 realize that the time they were building this that they really 00:25:24.300 --> 00:25:27.270 should have been very careful about separating encryption 00:25:27.270 --> 00:25:29.110 from authentication. 00:25:29.110 --> 00:25:33.150 So in the paper, there's this implicit assumption 00:25:33.150 --> 00:25:37.442 that-- hopefully, that's not us. 00:25:37.442 --> 00:25:38.150 All right, sorry. 00:25:38.150 --> 00:25:40.191 So in the paper, there's this implicit assumption 00:25:40.191 --> 00:25:43.220 that whenever you encrypt a piece of data 00:25:43.220 --> 00:25:46.210 and you send it to someone else, if that person can decrypt 00:25:46.210 --> 00:25:48.350 the data and it sort of looks OK, 00:25:48.350 --> 00:25:50.210 then no, they must have gotten the right key 00:25:50.210 --> 00:25:52.520 and the data wasn't tampered with in flight. 00:25:52.520 --> 00:25:54.430 But it seems like a totally bad plan now 00:25:54.430 --> 00:25:56.590 that we think of it 30 years later. 00:25:56.590 --> 00:25:58.230 But at the time, it wasn't so clear. 00:25:58.230 --> 00:25:59.610 So in order to do Kerberos right, 00:25:59.610 --> 00:26:01.730 and in fact, what Kerberos 5 does now, 00:26:01.730 --> 00:26:04.277 is they both encrypt all the pieces of data 00:26:04.277 --> 00:26:05.860 and they also authenticate the message 00:26:05.860 --> 00:26:09.350 by basically computing a hash with a key. 00:26:09.350 --> 00:26:11.320 And then the result actually tells you 00:26:11.320 --> 00:26:13.960 that, oh, that piece of data just wasn't tampered with. 00:26:13.960 --> 00:26:16.389 It was correctly signed with this key, et cetera. 00:26:16.389 --> 00:26:17.930 And what actually happens in Kerberos 00:26:17.930 --> 00:26:20.030 version 4 is there are some extra bits 00:26:20.030 --> 00:26:23.110 in this thing that was encrypted that should all 00:26:23.110 --> 00:26:25.350 be some pattern like zeros. 00:26:25.350 --> 00:26:28.150 And typically, if you get the key wrong, 00:26:28.150 --> 00:26:31.510 that pattern will not look like all zeros just by chance. 00:26:31.510 --> 00:26:34.210 It's not cryptographically guaranteed to be that. 00:26:34.210 --> 00:26:36.690 But most times, it will not look like zeros 00:26:36.690 --> 00:26:40.030 and you will be able to decide whether you got the correct key 00:26:40.030 --> 00:26:42.490 or not. 00:26:42.490 --> 00:26:45.400 All right, so that's sort of the plan 00:26:45.400 --> 00:26:47.744 for how the clients tells, I guess, 00:26:47.744 --> 00:26:48.910 whether the ticket is valid. 00:26:48.910 --> 00:26:52.384 They just try to decrypt it and see how it works. 00:26:52.384 --> 00:26:53.800 So another interesting question is 00:26:53.800 --> 00:26:57.214 why is this key KCS included twice 00:26:57.214 --> 00:26:58.630 in the ticket in some form, right? 00:26:58.630 --> 00:27:02.520 So it's included once here and another time actually sort 00:27:02.520 --> 00:27:06.060 of implicitly in this ticket T. Why 00:27:06.060 --> 00:27:10.274 do we have two copies of the same key KCS? 00:27:10.274 --> 00:27:10.774 Yeah. 00:27:10.774 --> 00:27:12.658 STUDENT: The client can't decrypt that ticket 00:27:12.658 --> 00:27:14.681 because it's encrypted with a service key. 00:27:14.681 --> 00:27:16.930 PROFESSOR: Yeah, so it's actually kind of cute, right? 00:27:16.930 --> 00:27:19.067 Like, there's this key that the client can get to. 00:27:19.067 --> 00:27:20.900 But then there's another copy of it in here. 00:27:20.900 --> 00:27:23.300 It's encrypted with KS. 00:27:23.300 --> 00:27:27.400 And the reason for this is that the Kerberos server is actually 00:27:27.400 --> 00:27:29.670 trying to set up the client and this other guy 00:27:29.670 --> 00:27:31.350 to talk to each other securely. 00:27:31.350 --> 00:27:35.650 So the Kerberos generates this hopefully random key KCS 00:27:35.650 --> 00:27:38.180 and wants to give one copy to the client and one copy 00:27:38.180 --> 00:27:40.640 to the write other server that you want to talk to. 00:27:40.640 --> 00:27:42.840 And one thing you could imagine doing naively 00:27:42.840 --> 00:27:45.600 is maybe the Kerberos will just go and say, hey service, 00:27:45.600 --> 00:27:46.850 this guy wants to talk to you. 00:27:46.850 --> 00:27:47.767 Here's the key for it. 00:27:47.767 --> 00:27:49.349 But that would be kind of unfortunate. 00:27:49.349 --> 00:27:52.380 You'd have to have the Kerberos server call back to the service 00:27:52.380 --> 00:27:53.380 and so on. 00:27:53.380 --> 00:27:56.610 So instead, these guys have this nice trick where they just 00:27:56.610 --> 00:27:58.899 to give the client does blob that the client 00:27:58.899 --> 00:28:00.440 can't actually do anything with other 00:28:00.440 --> 00:28:02.290 than give to the right service. 00:28:02.290 --> 00:28:04.470 And if the service has the right key KS, 00:28:04.470 --> 00:28:06.260 they'll decrypt it and say, aha. 00:28:06.260 --> 00:28:10.420 Well, here's the key I should be using to speak to this client. 00:28:10.420 --> 00:28:13.970 And that's how these two guys, the client and the service, 00:28:13.970 --> 00:28:16.320 are going to establish a shared key for protecting 00:28:16.320 --> 00:28:17.200 their communication. 00:28:17.200 --> 00:28:17.700 Yeah. 00:28:17.700 --> 00:28:19.670 STUDENT: So what exactly is TGS? 00:28:19.670 --> 00:28:24.160 PROFESSOR: So TGS is-- OK, so there's 00:28:24.160 --> 00:28:25.820 sort of two sides to it. 00:28:25.820 --> 00:28:28.620 From the client's point of view, it's just another service 00:28:28.620 --> 00:28:30.290 that you can get a ticket for. 00:28:30.290 --> 00:28:32.540 And the kinds of operations it supports 00:28:32.540 --> 00:28:33.690 is getting more tickets. 00:28:33.690 --> 00:28:35.010 It's a Ticket Granting Service. 00:28:35.010 --> 00:28:37.310 STUDENT: Sorry, I meant what is the ticket called TGS. 00:28:37.310 --> 00:28:38.520 PROFESSOR: Oh, yeah, sorry. 00:28:38.520 --> 00:28:41.760 This TGS is just shorthand for this whole blob 00:28:41.760 --> 00:28:45.565 except where S is actually the principal name of this TGS 00:28:45.565 --> 00:28:46.065 service. 00:28:48.527 --> 00:28:50.860 So you can think of it as like, well, there's a Kerberos 00:28:50.860 --> 00:28:52.770 server, there's this TGS service out there, 00:28:52.770 --> 00:28:54.230 and then there's the real thing I want to get to. 00:28:54.230 --> 00:28:56.170 So you first ask this guy to give me 00:28:56.170 --> 00:28:57.950 a ticket for some service. 00:28:57.950 --> 00:29:00.530 You could ask it to give you directly a ticket for the file 00:29:00.530 --> 00:29:01.550 server. 00:29:01.550 --> 00:29:02.400 And this would work. 00:29:02.400 --> 00:29:04.040 But you'd need your KC to decrypt it 00:29:04.040 --> 00:29:06.044 and then you'd need your KC around all the time. 00:29:06.044 --> 00:29:07.460 So instead, what you do is you get 00:29:07.460 --> 00:29:10.595 a ticket for this special service over here. 00:29:10.595 --> 00:29:12.720 It looks just like a service except that it happens 00:29:12.720 --> 00:29:15.630 to be provided by the same box. 00:29:15.630 --> 00:29:18.310 And then this guy will happily give you more tickets 00:29:18.310 --> 00:29:23.210 later without having to present your initial KC again. 00:29:23.210 --> 00:29:24.143 Makes sense? 00:29:24.143 --> 00:29:26.830 All right, other questions? 00:29:26.830 --> 00:29:27.662 Yeah. 00:29:27.662 --> 00:29:32.482 STUDENT: So [INAUDIBLE] the idea is once you get the TGS ticket, 00:29:32.482 --> 00:29:33.940 you can just get rid of your KC? 00:29:33.940 --> 00:29:34.840 PROFESSOR: Yes, so that's actually 00:29:34.840 --> 00:29:36.660 the cool thing about it is that once 00:29:36.660 --> 00:29:40.250 you get this ticket-- well, this ticket with the S being TGS, 00:29:40.250 --> 00:29:43.450 then you're going to get rid of the password and KC. 00:29:43.450 --> 00:29:46.836 So you log into Athena workstation and a couple 00:29:46.836 --> 00:29:48.210 of seconds into the boot process, 00:29:48.210 --> 00:29:49.584 you already get your ticket here. 00:29:49.584 --> 00:29:51.280 It scrubs the password from memory. 00:29:51.280 --> 00:29:54.240 So even if someone, like, grabs you and grab the machine 00:29:54.240 --> 00:29:56.870 and runs off, all they got was your ticket. 00:29:56.870 --> 00:29:59.830 And OK, well, maybe they can access your stuff for 10 hours 00:29:59.830 --> 00:30:01.410 or whatever the ticket lifetime was, 00:30:01.410 --> 00:30:02.760 but not for longer than that. 00:30:02.760 --> 00:30:05.580 The password is gone. 00:30:05.580 --> 00:30:06.080 Yeah. 00:30:06.080 --> 00:30:08.912 So if the password's gone, then on that picture 00:30:08.912 --> 00:30:11.000 there when Kerberos sends a reply 00:30:11.000 --> 00:30:14.220 encrypted with KC, how does the client-- 00:30:14.220 --> 00:30:16.680 Oh yeah, so this is the one place you need your password. 00:30:16.680 --> 00:30:19.650 So you send this message, you get this reply, 00:30:19.650 --> 00:30:22.603 you decrypt this, and then you forget the password. 00:30:22.603 --> 00:30:24.186 So you can't forget about the password 00:30:24.186 --> 00:30:26.220 before you use it for decryption of course. 00:30:26.220 --> 00:30:28.150 STUDENT: [INAUDIBLE] 00:30:28.150 --> 00:30:30.590 PROFESSOR: Ah, no, so this is just this interface, right? 00:30:30.590 --> 00:30:33.470 So this is the thing you do initially. 00:30:33.470 --> 00:30:36.220 And we'll talk in a second about how you basically also 00:30:36.220 --> 00:30:38.840 can get any ticket you want from the second interface 00:30:38.840 --> 00:30:43.924 without needing the initial key KC. 00:30:43.924 --> 00:30:46.760 Right, make sense? 00:30:46.760 --> 00:30:49.530 All right, so I guess we already talked 00:30:49.530 --> 00:30:53.920 about two particular problems that the Kerberos protocol had 00:30:53.920 --> 00:30:56.830 sort of baked into it, which is a little unfortunate. 00:30:56.830 --> 00:30:59.520 One is that they assumed that encryption also 00:30:59.520 --> 00:31:02.440 provides authentication or integrity of messages. 00:31:02.440 --> 00:31:03.270 So don't do that. 00:31:03.270 --> 00:31:05.040 And Kerberos version 5 fixes this 00:31:05.040 --> 00:31:07.770 by explicitly authenticating messages. 00:31:07.770 --> 00:31:11.940 Another thing they sort of had a problem with 00:31:11.940 --> 00:31:14.820 is the ability for arbitrary clients 00:31:14.820 --> 00:31:17.220 to guess people's passwords. 00:31:17.220 --> 00:31:21.102 So any suggestions of how we could fix this? 00:31:21.102 --> 00:31:22.560 How do you prevent guessing attacks 00:31:22.560 --> 00:31:24.826 in a protocol like this? 00:31:24.826 --> 00:31:26.242 What could we try? 00:31:26.242 --> 00:31:26.775 Yeah. 00:31:26.775 --> 00:31:28.024 STUDENT: Some sort of salting? 00:31:28.024 --> 00:31:29.400 I'm not sure. 00:31:29.400 --> 00:31:31.540 PROFESSOR: Well, so salting would just 00:31:31.540 --> 00:31:33.900 means that the client has to hash the password 00:31:33.900 --> 00:31:35.066 in different ways, maybe. 00:31:35.066 --> 00:31:36.440 But it still doesn't prevent them 00:31:36.440 --> 00:31:37.659 from trying lots of things. 00:31:37.659 --> 00:31:39.950 So maybe it'll be more expensive to build a dictionary. 00:31:39.950 --> 00:31:40.449 Yeah. 00:31:40.449 --> 00:31:43.109 STUDENT: You could [INAUDIBLE] derivation function? 00:31:43.109 --> 00:31:44.650 PROFESSOR: Yeah, so another good idea 00:31:44.650 --> 00:31:47.949 is to make this hashing process super expensive. 00:31:47.949 --> 00:31:49.490 So that might be kind of nice, right? 00:31:49.490 --> 00:31:52.650 So if this hash function took a second to compute like you 00:31:52.650 --> 00:31:54.404 guys did in lab two, then OK, wow, this 00:31:54.404 --> 00:31:55.820 would be actually really expensive 00:31:55.820 --> 00:31:56.810 to try different passwords. 00:31:56.810 --> 00:31:58.351 So that seems like a reasonable plan. 00:31:58.351 --> 00:32:00.500 So in combination with salting, those 00:32:00.500 --> 00:32:02.880 would be make it pretty expensive to do password 00:32:02.880 --> 00:32:03.987 guessing attacks. 00:32:03.987 --> 00:32:04.570 Anything else? 00:32:07.035 --> 00:32:08.910 So another thing is, yeah, challenge respond. 00:32:08.910 --> 00:32:11.620 So you could actually hear in the initial protocol, 00:32:11.620 --> 00:32:13.790 the Kerberos server doesn't have any idea 00:32:13.790 --> 00:32:15.720 if this was the right client or not. 00:32:15.720 --> 00:32:18.202 But in fact, what you could do is maybe 00:32:18.202 --> 00:32:20.160 give a little bit of a proof that, well, you're 00:32:20.160 --> 00:32:22.010 probably the right client. 00:32:22.010 --> 00:32:24.980 So maybe you could encrypt the current time stamp 00:32:24.980 --> 00:32:27.890 with your hash password or something 00:32:27.890 --> 00:32:29.455 like this-- has them together. 00:32:29.455 --> 00:32:31.080 And then the Kerberos server could just 00:32:31.080 --> 00:32:34.250 check if that's the right-- if that matches, and if so, return 00:32:34.250 --> 00:32:35.330 you back a ticket. 00:32:35.330 --> 00:32:37.580 You probably don't want to necessarily add more rounds 00:32:37.580 --> 00:32:38.450 but this could work. 00:32:38.450 --> 00:32:40.760 So just to precise about what I'm sort of suggesting. 00:32:40.760 --> 00:32:44.460 OK, well, maybe you take the current time stamp 00:32:44.460 --> 00:32:51.550 and maybe you hash the current time stamp and the KC together. 00:32:51.550 --> 00:32:53.570 And maybe you include the timestamp as well. 00:32:53.570 --> 00:32:55.957 And then the server could see, well, it has your KC. 00:32:55.957 --> 00:32:57.790 It could hash the current timestamp as well. 00:32:57.790 --> 00:32:59.490 If it gets the same value, then yeah, 00:32:59.490 --> 00:33:01.281 it's probably the right user requesting it. 00:33:01.281 --> 00:33:02.870 And I can send back the ticket. 00:33:02.870 --> 00:33:06.420 If not, then it wasn't the right password at all. 00:33:06.420 --> 00:33:06.970 Question? 00:33:06.970 --> 00:33:13.041 STUDENT: [INAUDIBLE] you just do [INAUDIBLE] if the servers see 00:33:13.041 --> 00:33:14.545 too many requests [INAUDIBLE] 00:33:14.545 --> 00:33:15.545 PROFESSOR: That's right. 00:33:15.545 --> 00:33:17.570 So the problem is that we could write limit. 00:33:17.570 --> 00:33:19.070 But there's no reason for the hacker 00:33:19.070 --> 00:33:21.120 to request this more than once. 00:33:21.120 --> 00:33:23.980 That hacker requests a particular user more than once 00:33:23.980 --> 00:33:26.240 and then it gets this encrypted blob. 00:33:26.240 --> 00:33:28.980 And then it can try decrypting it offline as many times 00:33:28.980 --> 00:33:31.000 as it wants with different passwords 00:33:31.000 --> 00:33:33.080 without having to re request it. 00:33:33.080 --> 00:33:34.950 So I think the whole point of including 00:33:34.950 --> 00:33:36.840 some sort of a challenge response thing 00:33:36.840 --> 00:33:41.057 like this in the particle is so that the server will-- 00:33:41.057 --> 00:33:42.890 you'll have to actually ask the server again 00:33:42.890 --> 00:33:46.809 and again to try to log in with different passwords. 00:33:46.809 --> 00:33:48.600 And then you could rate limit of the server 00:33:48.600 --> 00:33:50.700 and get a much better defense. 00:33:50.700 --> 00:33:51.640 Yeah. 00:33:51.640 --> 00:33:54.930 STUDENT: [INAUDIBLE] Kerberos? 00:33:54.930 --> 00:34:00.210 PROFESSOR: So I think you could certainly replay this message 00:34:00.210 --> 00:34:03.330 so if I sent this message now, you could probably 00:34:03.330 --> 00:34:05.420 look at that message and send it as well 00:34:05.420 --> 00:34:07.535 and get a response back from the Kerberos server. 00:34:07.535 --> 00:34:09.159 I guess if you're watching the network, 00:34:09.159 --> 00:34:12.429 you could observe this thing on the wire as well. 00:34:12.429 --> 00:34:16.780 So I think this is sort of a bit of a stopgap measure-- improves 00:34:16.780 --> 00:34:17.420 security a bit. 00:34:17.420 --> 00:34:21.002 But certainly if you're watching someone else's network, 00:34:21.002 --> 00:34:23.460 then you're going to see this packet coming back regardless 00:34:23.460 --> 00:34:25.546 of what happened in this step. 00:34:25.546 --> 00:34:27.004 So coming back, you'll see this guy 00:34:27.004 --> 00:34:28.817 and you can then try to attack it. 00:34:28.817 --> 00:34:30.650 There's probably some more elaborate schemes 00:34:30.650 --> 00:34:32.500 you could design but I didn't think 00:34:32.500 --> 00:34:34.469 Kerberos 5 even implements anything more 00:34:34.469 --> 00:34:37.590 elaborate than roughly this plan, which seems good enough 00:34:37.590 --> 00:34:39.460 to prevent arbitrary people from trying 00:34:39.460 --> 00:34:43.130 to break anyone's or brute force anyone's password. 00:34:43.130 --> 00:34:44.326 Make sense? 00:34:44.326 --> 00:34:44.826 Yeah. 00:34:44.826 --> 00:34:46.513 STUDENT: So presume that you could 00:34:46.513 --> 00:34:50.528 do authenticated [INAUDIBLE] or something here 00:34:50.528 --> 00:34:51.694 to establish the shared key. 00:34:51.694 --> 00:34:53.235 And then you could encrypt this thing 00:34:53.235 --> 00:34:54.474 with KC and the shared key. 00:34:54.474 --> 00:34:55.300 PROFESSOR: That's right, yeah. 00:34:55.300 --> 00:34:56.841 So if you're really doing this right, 00:34:56.841 --> 00:34:59.630 there's all these nice particles out there 00:34:59.630 --> 00:35:02.080 that are basically called password authenticated key 00:35:02.080 --> 00:35:04.170 exchange particles, which is exactly what's going on here. 00:35:04.170 --> 00:35:05.836 So if you're actually building a system, 00:35:05.836 --> 00:35:08.800 you should basically Google for SRP or PAKE. 00:35:08.800 --> 00:35:12.680 And these protocols and related particles 00:35:12.680 --> 00:35:15.480 will actually do this in a much better way where 00:35:15.480 --> 00:35:18.760 you can prove to both parties that you established 00:35:18.760 --> 00:35:20.850 a new key and both parties are convinced that it's 00:35:20.850 --> 00:35:23.610 the right other party and there's no way 00:35:23.610 --> 00:35:26.240 to mount these offline password guessing attacks 00:35:26.240 --> 00:35:29.682 on the set of network packets that you observe and so on. 00:35:29.682 --> 00:35:31.140 So these are the sort of protocols. 00:35:31.140 --> 00:35:33.220 And they're much more elaborate in terms 00:35:33.220 --> 00:35:34.310 of crypto they rely on. 00:35:34.310 --> 00:35:36.690 So it's hard to explain on a board exactly why they work. 00:35:36.690 --> 00:35:37.190 Yeah. 00:35:37.190 --> 00:35:39.050 STUDENT: [INAUDIBLE] part of the reason 00:35:39.050 --> 00:35:40.938 they did it this way is because they 00:35:40.938 --> 00:35:44.714 wanted to maintain the ability of just sending the password. 00:35:44.714 --> 00:35:48.365 And protocols just allow you to send a single thing 00:35:48.365 --> 00:35:50.840 as your authentication [INAUDIBLE]. 00:35:50.840 --> 00:35:52.820 PROFESSOR: Well, yeah, there's lots 00:35:52.820 --> 00:35:56.950 of sort of weird requirements that these guys had in mind. 00:35:56.950 --> 00:36:01.540 I think they-- well, certainly in practice, 00:36:01.540 --> 00:36:06.340 these servers could accept both Kerberos and non Kerberos 00:36:06.340 --> 00:36:06.866 connections. 00:36:06.866 --> 00:36:08.240 And for non Kerberos connections, 00:36:08.240 --> 00:36:10.030 you get-- like someone connects to the mail server 00:36:10.030 --> 00:36:11.520 but they're not using an Athena workstation. 00:36:11.520 --> 00:36:13.180 They just want to send their password. 00:36:13.180 --> 00:36:14.889 And then the mail client here, let's say, 00:36:14.889 --> 00:36:16.430 is going to take your password and is 00:36:16.430 --> 00:36:18.770 going to get a ticket on your behalf just to check it. 00:36:18.770 --> 00:36:19.990 And then it's going to allow you to use it. 00:36:19.990 --> 00:36:22.531 So you certainly want conversion from Kerberos from passwords 00:36:22.531 --> 00:36:25.119 into checking against Kerberos. 00:36:25.119 --> 00:36:27.160 I don't think this precludes it because certainly 00:36:27.160 --> 00:36:30.833 Kerberos 5 deploys although this hashes of timestamps, 00:36:30.833 --> 00:36:31.332 et cetera. 00:36:31.332 --> 00:36:33.165 STUDENT: Yeah but it's because they wouldn't 00:36:33.165 --> 00:36:35.028 want multiple [INAUDIBLE]. 00:36:35.028 --> 00:36:37.620 PROFESSOR: Yeah, well, I think that probably 00:36:37.620 --> 00:36:38.967 doesn't matter quite as much. 00:36:38.967 --> 00:36:41.300 You could certainly have multiple rounds in the back end 00:36:41.300 --> 00:36:43.380 behind your library. 00:36:43.380 --> 00:36:46.670 But there's some downsides to these particles-- 00:36:46.670 --> 00:36:50.180 probably not significant enough to stop you from using them. 00:36:50.180 --> 00:36:53.040 Other questions? 00:36:53.040 --> 00:36:54.880 All right, I guess the other thing 00:36:54.880 --> 00:36:57.040 I want to mention that you should watch out 00:36:57.040 --> 00:37:01.080 for in the paper is that these guys, in designing Kerberos 4, 00:37:01.080 --> 00:37:03.550 they picked a single encryption scheme. 00:37:03.550 --> 00:37:05.740 And at the time, they basically picked 00:37:05.740 --> 00:37:09.260 DES, which was a popular encryption scheme of the time. 00:37:09.260 --> 00:37:11.590 It's a symmetric block cypher. 00:37:11.590 --> 00:37:12.820 It goes pretty fast. 00:37:12.820 --> 00:37:16.090 It was reasonably secure, not necessarily the best, 00:37:16.090 --> 00:37:18.392 but certainly good enough at the time. 00:37:18.392 --> 00:37:20.100 And they just baked it into the protocol. 00:37:20.100 --> 00:37:22.880 Everything in Kerberos has to use single DES or at least 00:37:22.880 --> 00:37:24.890 everything in Kerberos version 4. 00:37:24.890 --> 00:37:27.935 And this was a bit problematic because 25 years later, 00:37:27.935 --> 00:37:29.310 30 years later now, it's actually 00:37:29.310 --> 00:37:32.820 very cheap to brute force DES encryption 00:37:32.820 --> 00:37:34.690 because the keys are actually very small. 00:37:34.690 --> 00:37:36.570 They're 56 bits. 00:37:36.570 --> 00:37:39.140 So you could just search build some custom hardware that 00:37:39.140 --> 00:37:42.090 iterates over all the possible 2 to the 56 combinations 00:37:42.090 --> 00:37:46.379 and tries them all and figures out what someone's password is. 00:37:46.379 --> 00:37:48.170 So this is something also you want to avoid 00:37:48.170 --> 00:37:49.710 in any protocol you design now. 00:37:49.710 --> 00:37:51.550 Kerberos version 5 actually supports 00:37:51.550 --> 00:37:54.730 multiple different encryption schemes including 00:37:54.730 --> 00:37:56.885 AES and other things as well. 00:37:56.885 --> 00:37:59.350 So that seems like a much better way to do it. 00:37:59.350 --> 00:38:02.320 On the other hand, MIT actually kept supporting DES up 00:38:02.320 --> 00:38:06.540 until two years ago, which is a little unfortunate. 00:38:06.540 --> 00:38:07.560 But now they don't. 00:38:07.560 --> 00:38:08.530 So that's good. 00:38:08.530 --> 00:38:12.860 Your principal is secure at least from this kind of attack. 00:38:12.860 --> 00:38:14.680 All right, so does that make sense? 00:38:14.680 --> 00:38:16.350 This is the initial way you'd get 00:38:16.350 --> 00:38:18.210 any ticket at all in Kerberos. 00:38:18.210 --> 00:38:20.810 And typically, you'd get this ticket from this TGS service. 00:38:20.810 --> 00:38:24.090 So now let's look at what's going on in this TGS service. 00:38:24.090 --> 00:38:27.700 So here, the interaction with the TGS service 00:38:27.700 --> 00:38:29.350 is going to be a little different. 00:38:29.350 --> 00:38:32.150 On one hand, you're going to-- as a client, 00:38:32.150 --> 00:38:33.900 you're going to have to speak to it as 00:38:33.900 --> 00:38:37.910 if you're speaking to any other Kerberos enabled service. 00:38:37.910 --> 00:38:39.660 So we'll see how you authenticate yourself 00:38:39.660 --> 00:38:41.714 with a ticket to some machine. 00:38:41.714 --> 00:38:43.630 But then the response you're going to get back 00:38:43.630 --> 00:38:46.071 is just a ticket for some other principle 00:38:46.071 --> 00:38:48.570 that you're going to want to communicate with like your file 00:38:48.570 --> 00:38:50.230 server. 00:38:50.230 --> 00:38:54.210 So the protocol level messages that show up here kind of 00:38:54.210 --> 00:38:54.910 look like this. 00:38:54.910 --> 00:38:57.050 So here's your TGS service. 00:38:57.050 --> 00:38:59.230 And here's a client. 00:38:59.230 --> 00:39:02.750 The client already got a ticket for TGS 00:39:02.750 --> 00:39:04.090 using this protocol above. 00:39:04.090 --> 00:39:06.580 So what the client is actually going to send over 00:39:06.580 --> 00:39:10.190 is some combination of messages that 00:39:10.190 --> 00:39:12.690 prove that this is the right client 00:39:12.690 --> 00:39:16.900 and they're issuing a request for some particular principle 00:39:16.900 --> 00:39:17.490 through TGS. 00:39:17.490 --> 00:39:20.414 So what the client is going to send to TGS is this tuple. 00:39:20.414 --> 00:39:21.830 So first, it's going to say, well, 00:39:21.830 --> 00:39:24.000 here's the service that I want to talk to next. 00:39:24.000 --> 00:39:27.130 So this might be your mail server or your file server. 00:39:27.130 --> 00:39:29.440 Then is going to include the ticket. 00:39:29.440 --> 00:39:30.970 It already got 4TGS. 00:39:30.970 --> 00:39:38.100 So this is going to be TC of TGS encrypted with KTGS. 00:39:38.100 --> 00:39:41.430 So this is just this thing where S is TGS. 00:39:41.430 --> 00:39:43.890 And then you're going to have to include this authenticator 00:39:43.890 --> 00:39:44.890 blob. 00:39:44.890 --> 00:39:48.155 This is this AC thing from up there. 00:39:48.155 --> 00:39:49.780 And this thing is going to be encrypted 00:39:49.780 --> 00:39:54.892 with a shared key between the client and the TGS service. 00:39:54.892 --> 00:39:58.360 So this is the message that you're going to send to TGS. 00:39:58.360 --> 00:40:00.399 It's going to look at this message, 00:40:00.399 --> 00:40:02.690 do something with it that we'll talk about in a second, 00:40:02.690 --> 00:40:07.770 and respond back with a ticket for this new service S. 00:40:07.770 --> 00:40:10.700 So the response here looks almost exactly like here. 00:40:10.700 --> 00:40:12.490 In fact, it is exactly the same thing. 00:40:12.490 --> 00:40:14.610 It's going to be a ticket between the client 00:40:14.610 --> 00:40:18.310 and this new service S encrypted with KS 00:40:18.310 --> 00:40:21.320 and the shared key between the client and this new service 00:40:21.320 --> 00:40:25.040 S encrypted-- well, now, here's a little bit different. 00:40:25.040 --> 00:40:27.550 Instead of encrypting with KC, which the client has probably 00:40:27.550 --> 00:40:29.280 forgotten since then, now we're going 00:40:29.280 --> 00:40:31.800 to encrypt it with this shared key between the client 00:40:31.800 --> 00:40:35.510 and the TGS service. 00:40:35.510 --> 00:40:38.030 Makes sense? 00:40:38.030 --> 00:40:44.850 All right, so in this-- how does the server actually figure out 00:40:44.850 --> 00:40:46.590 what the client wants to do? 00:40:46.590 --> 00:40:49.120 Or, how does server authenticate the client? 00:40:49.120 --> 00:40:52.650 Well, in this case, it's going to-- TGS server actually 00:40:52.650 --> 00:40:54.840 knows its own key, KTGS. 00:40:54.840 --> 00:40:57.390 So it's going to first decrypt this blob 00:40:57.390 --> 00:41:00.090 and look inside the ticket and figure out what's going on. 00:41:00.090 --> 00:41:03.190 And there's all those nice fields in the ticket. 00:41:03.190 --> 00:41:04.400 So let's just double check. 00:41:04.400 --> 00:41:07.100 Why do we need all those fields in the ticket? 00:41:07.100 --> 00:41:12.687 So is it important to have the server name S in the ticket? 00:41:12.687 --> 00:41:14.770 What would go wrong if you didn't have S in there? 00:41:17.722 --> 00:41:19.682 Anything? 00:41:19.682 --> 00:41:20.182 Yeah. 00:41:20.182 --> 00:41:21.640 STUDENT: They could potentially get 00:41:21.640 --> 00:41:24.610 authorized to use any server. 00:41:24.610 --> 00:41:27.370 PROFESSOR: Yeah, so it's in general a good idea 00:41:27.370 --> 00:41:29.300 to be very explicit in network protocols 00:41:29.300 --> 00:41:31.580 and to say exactly what a message means. 00:41:31.580 --> 00:41:33.910 So in this case, if you omit an S, 00:41:33.910 --> 00:41:37.189 you might be relying on the fact that, well, 00:41:37.189 --> 00:41:39.730 if it's the wrong S that you're trying to use the ticket for, 00:41:39.730 --> 00:41:42.320 then maybe you'll have a different key over here 00:41:42.320 --> 00:41:44.490 and then it wouldn't decrypt or something like this. 00:41:44.490 --> 00:41:46.823 But it seems like a good idea to include it to make sure 00:41:46.823 --> 00:41:48.630 that the server that receives this tickets 00:41:48.630 --> 00:41:49.960 decrypts and checks. 00:41:49.960 --> 00:41:52.470 Is that a ticket for me or for someone else? 00:41:52.470 --> 00:41:52.970 Yeah. 00:41:52.970 --> 00:41:55.522 STUDENT: What does the client get KTGS on? 00:41:55.522 --> 00:41:56.730 PROFESSOR: Ah, good question. 00:41:56.730 --> 00:41:58.230 The client has no idea what this is. 00:41:58.230 --> 00:42:00.060 Because this is like a super secret key. 00:42:00.060 --> 00:42:01.770 If you knew this, you'd probably be 00:42:01.770 --> 00:42:03.480 able to break all of Kerberos. 00:42:03.480 --> 00:42:06.461 So the client has no idea what KTGS is. 00:42:06.461 --> 00:42:07.294 STUDENT: [INAUDIBLE] 00:42:07.294 --> 00:42:08.110 PROFESSOR: Ah, yeah, yeah. 00:42:08.110 --> 00:42:09.335 And then the where you get it from 00:42:09.335 --> 00:42:11.209 is actually-- it's the Kerberos server itself 00:42:11.209 --> 00:42:14.830 that generates this whole blob for you where this is actually 00:42:14.830 --> 00:42:18.780 TGS and this is KTGS over here. 00:42:18.780 --> 00:42:20.450 So you don't construct this yourself. 00:42:20.450 --> 00:42:22.830 You just copy it over. 00:42:22.830 --> 00:42:23.660 OK 00:42:23.660 --> 00:42:27.154 So what is the client name there important for? 00:42:27.154 --> 00:42:28.570 That should be fairly easy, right? 00:42:28.570 --> 00:42:30.020 If you don't put the client name in the ticket, 00:42:30.020 --> 00:42:31.830 then the server gets this nice blob 00:42:31.830 --> 00:42:34.382 but it has no idea who it's trying to talk to. 00:42:34.382 --> 00:42:35.840 So it has no idea whether it should 00:42:35.840 --> 00:42:38.890 issue a ticket for my principal or for someone else's 00:42:38.890 --> 00:42:41.250 principle, et cetera. 00:42:41.250 --> 00:42:44.470 So what's the deal with the other fields? 00:42:44.470 --> 00:42:46.625 Why do these guys stick an address in the ticket? 00:42:49.190 --> 00:42:51.475 This is the client's IP address. 00:42:51.475 --> 00:42:53.741 Does it matter? 00:42:53.741 --> 00:42:54.240 Yeah. 00:42:54.240 --> 00:42:56.632 STUDENT: Can they use that address 00:42:56.632 --> 00:42:59.899 with the ticket to verify against the [INAUDIBLE]? 00:42:59.899 --> 00:43:00.690 PROFESSOR: Sort of. 00:43:00.690 --> 00:43:02.322 Well, so I think the general plan 00:43:02.322 --> 00:43:03.780 for why there's addresses appearing 00:43:03.780 --> 00:43:05.290 everywhere here, these IP addresses, 00:43:05.290 --> 00:43:08.220 is that these guys at the time were still slightly 00:43:08.220 --> 00:43:11.402 confused and-- well, in some ways-- 00:43:11.402 --> 00:43:12.860 they were still thinking, OK, well, 00:43:12.860 --> 00:43:14.318 we're going to rely on IP addresses 00:43:14.318 --> 00:43:15.800 for a little bit of security. 00:43:15.800 --> 00:43:19.350 So they wanted to make sure that if the client logged in 00:43:19.350 --> 00:43:21.830 from some IP address, then everything else going on 00:43:21.830 --> 00:43:24.300 with that ticket happen from that same IP address. 00:43:24.300 --> 00:43:27.070 So if you logged in from some IP address 00:43:27.070 --> 00:43:31.066 on 18.26.4.9 or something, then every connection 00:43:31.066 --> 00:43:32.940 you make to a file server or to a mail server 00:43:32.940 --> 00:43:34.280 has to be from the same IP address. 00:43:34.280 --> 00:43:36.405 Otherwise, the server should reject your connection 00:43:36.405 --> 00:43:39.570 as being stolen by-- or someone stole your ticket. 00:43:39.570 --> 00:43:41.500 So we're thinking, OK, well, maybe we'll 00:43:41.500 --> 00:43:43.350 defend against ticket theft this way. 00:43:43.350 --> 00:43:45.010 If you still a ticket, well, but you're 00:43:45.010 --> 00:43:46.260 not using the same IP address. 00:43:46.260 --> 00:43:47.685 So it won't work. 00:43:47.685 --> 00:43:49.830 It's probably a little bit misguided at this point 00:43:49.830 --> 00:43:52.980 but-- that sort of gets in the way And Kerberos 5 still has it 00:43:52.980 --> 00:43:54.350 but it's largely optional. 00:43:54.350 --> 00:43:58.410 Really, you should just rely on cryptography instead of any IP 00:43:58.410 --> 00:44:00.430 address security. 00:44:00.430 --> 00:44:02.890 So what's the point of the time stamp and lifetime things 00:44:02.890 --> 00:44:04.760 in the ticket up there? 00:44:04.760 --> 00:44:06.445 One are those guys good for? 00:44:06.445 --> 00:44:08.595 Are they useful? 00:44:08.595 --> 00:44:09.095 Yeah. 00:44:09.095 --> 00:44:11.270 STUDENT: Preventing replay attacks. 00:44:11.270 --> 00:44:12.687 PROFESSOR: Well, so the syndicator 00:44:12.687 --> 00:44:14.520 is the thing that's going to help us prevent 00:44:14.520 --> 00:44:16.080 replay attacks in a second. 00:44:16.080 --> 00:44:18.470 Because that thing gets generated every time 00:44:18.470 --> 00:44:20.370 you do a new request. 00:44:20.370 --> 00:44:22.490 On the other hand, the ticket just stays the same. 00:44:22.490 --> 00:44:24.739 So it's certainly not preventing replay attacks there. 00:44:24.739 --> 00:44:25.304 Yeah. 00:44:25.304 --> 00:44:27.804 STUDENT: It prevents somebody from stealing your ticket then 00:44:27.804 --> 00:44:28.638 using it [INAUDIBLE] 00:44:28.638 --> 00:44:29.720 PROFESSOR: Oh, sorry, yes. 00:44:29.720 --> 00:44:32.050 This just bounds the time for which a ticket is valid, 00:44:32.050 --> 00:44:34.630 meaning that the damage from disclosing it 00:44:34.630 --> 00:44:37.110 is hopefully reduced. 00:44:37.110 --> 00:44:39.900 So the plan is the timestamp is roughly the time when 00:44:39.900 --> 00:44:41.370 you initially got the ticket. 00:44:41.370 --> 00:44:44.070 And a lifetime in the ticket represents 00:44:44.070 --> 00:44:47.030 how many hours, let's say, it's valid 00:44:47.030 --> 00:44:48.900 from that initial timestamp. 00:44:48.900 --> 00:44:51.050 So if you try to use it too early or too late, 00:44:51.050 --> 00:44:54.100 then every server should reject such a ticket 00:44:54.100 --> 00:44:56.040 in the Kerberos protocol. 00:44:56.040 --> 00:44:58.180 So this kind of means that every server 00:44:58.180 --> 00:45:02.859 has to have a loosely synchronized, clock which 00:45:02.859 --> 00:45:04.900 is a bit of a-- well, maybe you've run into this. 00:45:04.900 --> 00:45:07.483 Like, your laptop clock is off and you can't log into Kerberos 00:45:07.483 --> 00:45:08.121 anymore. 00:45:08.121 --> 00:45:08.620 Question? 00:45:08.620 --> 00:45:09.190 Yeah. 00:45:09.190 --> 00:45:11.980 STUDENT: You said before that the client discards KC 00:45:11.980 --> 00:45:14.780 but they're still keeping KCS [INAUDIBLE] 00:45:14.780 --> 00:45:16.305 the TGS. [INAUDIBLE] 00:45:16.305 --> 00:45:17.555 PROFESSOR: That's right, yeah. 00:45:17.555 --> 00:45:20.310 So the client discards KC after logging in. 00:45:20.310 --> 00:45:21.600 But it still keeps KCS. 00:45:21.600 --> 00:45:22.997 You're exactly right. 00:45:22.997 --> 00:45:24.580 STUDENT: So if someone steals the KCS, 00:45:24.580 --> 00:45:27.487 then they have access to [INAUDIBLE]. 00:45:27.487 --> 00:45:28.320 PROFESSOR: Yeah, OK. 00:45:28.320 --> 00:45:29.111 So how bad is that? 00:45:29.111 --> 00:45:32.892 Like, why is it better to disclose this KCS 00:45:32.892 --> 00:45:34.600 fof-- actually, well, this is TGS, right? 00:45:34.600 --> 00:45:37.235 Why is it better to disclose KCTGS than KC? 00:45:39.980 --> 00:45:40.918 Yeah. 00:45:40.918 --> 00:45:43.205 STUDENT: Someone [INAUDIBLE] somewhere [INAUDIBLE]. 00:45:43.205 --> 00:45:44.580 PROFESSOR: It's the kind of thing 00:45:44.580 --> 00:45:45.390 that they're both keys, though. 00:45:45.390 --> 00:45:47.181 So neither of them are really hashed, yeah. 00:45:47.181 --> 00:45:49.533 STUDENT: You would take KCS and you'd just steal 00:45:49.533 --> 00:45:51.238 that session between those two. 00:45:51.238 --> 00:45:53.740 But if you steal KC, you can impersonate the client. 00:45:53.740 --> 00:45:54.740 PROFESSOR: That's right. 00:45:54.740 --> 00:45:55.240 Yeah. 00:45:55.240 --> 00:45:56.730 So I guess one way to answer this 00:45:56.730 --> 00:46:00.820 is that KCTGS, this is actually a new key generated every time 00:46:00.820 --> 00:46:02.820 you log in initially. 00:46:02.820 --> 00:46:06.550 And this thing is only good because you have this ticket 00:46:06.550 --> 00:46:08.620 that goes along with it. 00:46:08.620 --> 00:46:11.550 If you lose this ticket or if this ticket is no longer valid, 00:46:11.550 --> 00:46:14.500 then yeah, you have these 56 bits in this key. 00:46:14.500 --> 00:46:18.880 But no one is going to assume anything from those bits. 00:46:18.880 --> 00:46:20.760 The only reason these bits are interesting 00:46:20.760 --> 00:46:24.200 is because this ticket talks about this KCS being valid 00:46:24.200 --> 00:46:25.160 right now. 00:46:25.160 --> 00:46:26.886 And there's a bound on it. 00:46:26.886 --> 00:46:28.790 STUDENT: Yeah, so if they stole both of those 00:46:28.790 --> 00:46:30.579 [INAUDIBLE] be bounded. 00:46:30.579 --> 00:46:32.870 PROFESSOR: Yeah, if someone steals both of these blogs, 00:46:32.870 --> 00:46:36.040 than they can impersonate you or, like, log into your file 00:46:36.040 --> 00:46:39.450 server, mail server for the lifetime of that ticket, which 00:46:39.450 --> 00:46:41.990 is a couple of hours or 10 hours. 00:46:41.990 --> 00:46:44.760 Stealing this, there's no time bound on that until you change 00:46:44.760 --> 00:46:47.355 your password and maybe worse. 00:46:47.355 --> 00:46:49.720 Make sense? 00:46:49.720 --> 00:46:53.050 All right, so it seems like, yeah, 00:46:53.050 --> 00:46:54.840 all those fields are kind of important, 00:46:54.840 --> 00:46:57.810 IP address maybe less so. 00:46:57.810 --> 00:47:02.220 And now in response, right, we can get this ticket finally. 00:47:02.220 --> 00:47:05.950 And because we know KCTGS, we can decrypt the response 00:47:05.950 --> 00:47:07.120 from this TGS server. 00:47:07.120 --> 00:47:09.790 And now we have a ticket for any server 00:47:09.790 --> 00:47:12.350 we want-- a file server, mail server, whatever 00:47:12.350 --> 00:47:15.840 it is that we finally care about connecting to. 00:47:15.840 --> 00:47:18.470 Make sense? 00:47:18.470 --> 00:47:23.050 All right, so let's look at how you might sort of finally 00:47:23.050 --> 00:47:26.510 use this in some application level protocol. 00:47:26.510 --> 00:47:30.090 So suppose that maybe I'm talking to a mail server 00:47:30.090 --> 00:47:31.610 to fetch my messages. 00:47:31.610 --> 00:47:34.850 So presumably, what my client workstation is going to do 00:47:34.850 --> 00:47:37.245 is going to send a tickets requesting for, I don't know, 00:47:37.245 --> 00:47:39.770 mail.po12. 00:47:39.770 --> 00:47:43.380 And it'll get back a ticket for the principal mail.po12 00:47:43.380 --> 00:47:44.850 or something like this. 00:47:44.850 --> 00:47:49.340 And then inside of this ticket or inside of this response, 00:47:49.340 --> 00:47:51.930 now I have a shared key between me 00:47:51.930 --> 00:47:55.080 and the mail server-- S is the male server over here-- 00:47:55.080 --> 00:47:57.720 and this ticket a blob that I can to the mail 00:47:57.720 --> 00:47:59.870 server to convince it that I'm the right guy 00:47:59.870 --> 00:48:04.679 or anyone with this key is the right principle. 00:48:04.679 --> 00:48:06.970 And then we can actually have an encrypted conversation 00:48:06.970 --> 00:48:12.220 with the mail server using this new key KCS. 00:48:12.220 --> 00:48:16.990 So what I might do as a client is-- well, 00:48:16.990 --> 00:48:20.200 initially, I send some message to the mail server 00:48:20.200 --> 00:48:25.980 that includes this ticket TC mail encrypted 00:48:25.980 --> 00:48:28.880 with the key of the mail server. 00:48:28.880 --> 00:48:31.510 And then I can actually send some message along 00:48:31.510 --> 00:48:36.180 with this request that maybe says something like, well, 00:48:36.180 --> 00:48:40.640 delete some message-- delete 5. 00:48:40.640 --> 00:48:46.360 And I can encrypt this with KC mail. 00:48:46.360 --> 00:48:49.049 Does that make sense? 00:48:49.049 --> 00:48:51.340 OK, so what happens in this protocol on the mail server 00:48:51.340 --> 00:48:52.060 side? 00:48:52.060 --> 00:48:55.540 The mail server is going to use its secret key K mail 00:48:55.540 --> 00:48:57.474 to decrypt this ticket first. 00:48:57.474 --> 00:48:59.140 And then it looks inside there and finds 00:48:59.140 --> 00:49:02.800 two important things-- the principal name C of who 00:49:02.800 --> 00:49:07.014 is it that's talking to it in the first place and the key KCS 00:49:07.014 --> 00:49:08.430 that it should be using to decrypt 00:49:08.430 --> 00:49:11.155 all the subsequent traffic and authenticate it ideally 00:49:11.155 --> 00:49:12.609 in Kerberos 5, at least. 00:49:12.609 --> 00:49:15.150 And then you can decrypt this message and say oh, well, yeah. 00:49:15.150 --> 00:49:17.370 User C is trying to delete message five. 00:49:17.370 --> 00:49:19.485 So I'll run this command. 00:49:19.485 --> 00:49:19.985 Make sense? 00:49:19.985 --> 00:49:21.316 You had a question? 00:49:21.316 --> 00:49:24.500 STUDENT: Yeah, so Kerberos initially 00:49:24.500 --> 00:49:30.370 sends the TGS ticket in KCTGS. 00:49:30.370 --> 00:49:32.620 Where's [INAUDIBLE]? 00:49:32.620 --> 00:49:35.500 PROFESSOR: So AC, those authenticators are actually 00:49:35.500 --> 00:49:37.110 generated by the client. 00:49:37.110 --> 00:49:40.280 Note that the client only needs KCS 00:49:40.280 --> 00:49:42.390 to generate an authenticator. 00:49:42.390 --> 00:49:45.340 So the client can make these up any time it wants. 00:49:45.340 --> 00:49:48.250 So the general plan for indicators or the reason 00:49:48.250 --> 00:49:51.970 to use authenticators is roughly to prevent replay attack. 00:49:51.970 --> 00:49:55.470 So the client, or at least in the way that the Kerberos 4 00:49:55.470 --> 00:49:57.840 developers were intending it, the client, 00:49:57.840 --> 00:49:59.920 every time it sends a new request , 00:49:59.920 --> 00:50:02.980 it would generate a new authenticator to say OK, well, 00:50:02.980 --> 00:50:03.999 this is a new request. 00:50:03.999 --> 00:50:04.790 I'm issuing it now. 00:50:04.790 --> 00:50:06.706 It's different from all the previous requests. 00:50:06.706 --> 00:50:07.740 Go do it. 00:50:07.740 --> 00:50:11.110 And the general plan was that the server 00:50:11.110 --> 00:50:15.550 would keep a cache of these authenticators that 00:50:15.550 --> 00:50:18.830 were sent within the last five minutes or so. 00:50:18.830 --> 00:50:20.710 So if it ever sees a duplicate authenticator, 00:50:20.710 --> 00:50:22.310 it says oh, that's a replay request. 00:50:22.310 --> 00:50:24.130 I'm going to reject it. 00:50:24.130 --> 00:50:26.350 And if it sees an authenticator that's 00:50:26.350 --> 00:50:28.380 outside of a five minute boundary, 00:50:28.380 --> 00:50:29.970 it doesn't have it in the cache. 00:50:29.970 --> 00:50:33.220 But it will look at the time stamp in the authenticator 00:50:33.220 --> 00:50:35.220 and say, well, this is a very old authenticator. 00:50:35.220 --> 00:50:37.700 I'll just reject your request because it's too old. 00:50:37.700 --> 00:50:39.700 Send it again if you really care. 00:50:39.700 --> 00:50:42.170 So that's the general plan for indicators. 00:50:42.170 --> 00:50:44.410 As with many things in Kerberos, they 00:50:44.410 --> 00:50:47.160 were slightly broken-- in Kerberos 4, at least. 00:50:47.160 --> 00:50:48.890 Because this authenticator actually 00:50:48.890 --> 00:50:51.098 says nothing about the message you're sending, right? 00:50:51.098 --> 00:50:52.022 It's some blob. 00:50:52.022 --> 00:50:53.730 So the way you would use it, for example, 00:50:53.730 --> 00:50:57.610 in this mail server protocol is-- or at least in Kerberos 00:50:57.610 --> 00:51:00.050 4-- well, you would generate some authenticator 00:51:00.050 --> 00:51:02.380 and you would be to take the authenticator 00:51:02.380 --> 00:51:06.572 and you would encrypt it with also KC mail. 00:51:06.572 --> 00:51:09.190 And the mail server would keep track of, well, yeah, 00:51:09.190 --> 00:51:11.106 you've sent this [INAUDIBLE] indicator before. 00:51:11.106 --> 00:51:12.007 No, you haven't. 00:51:12.007 --> 00:51:14.340 But there's nothing here that connects the authenticator 00:51:14.340 --> 00:51:15.770 to the message you are sending. 00:51:15.770 --> 00:51:17.912 So for the first message, this was great. 00:51:17.912 --> 00:51:19.370 But when you send a second message, 00:51:19.370 --> 00:51:21.440 you're going to generate a second authenticator. 00:51:21.440 --> 00:51:22.980 And someone on the network can say, oh, yeah, 00:51:22.980 --> 00:51:24.310 I got your new authenticator. 00:51:24.310 --> 00:51:25.740 I can take your new authenticator 00:51:25.740 --> 00:51:28.130 and splice in the old delete message. 00:51:28.130 --> 00:51:31.180 So I'll force you to delete the fifth message twice, 00:51:31.180 --> 00:51:32.950 even though the second command meant 00:51:32.950 --> 00:51:35.960 to send some other operation. 00:51:35.960 --> 00:51:40.819 So Kerberos 5 gets this right where you actually 00:51:40.819 --> 00:51:42.860 stick something in the authenticator that relates 00:51:42.860 --> 00:51:45.100 to the command you're issuing. 00:51:45.100 --> 00:51:47.724 You could do this, of course, but sort of took a while 00:51:47.724 --> 00:51:49.390 for people to realize that, well, here's 00:51:49.390 --> 00:51:52.800 how you should design a protocol correctly. 00:51:52.800 --> 00:51:53.540 Make sense? 00:51:53.540 --> 00:51:54.714 Yeah, other question. 00:51:54.714 --> 00:51:55.547 STUDENT: [INAUDIBLE] 00:51:58.158 --> 00:52:01.050 PROFESSOR: Ah, so the client gets case email 00:52:01.050 --> 00:52:02.340 from this response. 00:52:02.340 --> 00:52:05.180 So the client, when it wants to talk to the mail server, 00:52:05.180 --> 00:52:08.240 it's going to ask the TGS for a ticket for the mail server. 00:52:08.240 --> 00:52:12.500 And here, S is basically this mail server's principal name. 00:52:12.500 --> 00:52:16.370 So when it comes back, this says S equals mail 00:52:16.370 --> 00:52:19.660 and this server key S is equal to mail. 00:52:19.660 --> 00:52:22.470 And this KCS is actually KC mail. 00:52:25.920 --> 00:52:28.830 So this is how the client learns of the shared key 00:52:28.830 --> 00:52:32.870 that it has between it and the files and the mail server here. 00:52:32.870 --> 00:52:34.850 And there's a copy of it inside the ticket. 00:52:34.850 --> 00:52:35.690 Question back there? 00:52:35.690 --> 00:52:38.059 STUDENT: How does the mail server get KC mail? 00:52:38.059 --> 00:52:38.850 PROFESSOR: Ah, yes. 00:52:38.850 --> 00:52:40.980 So how does the mail server get this shared key? 00:52:40.980 --> 00:52:43.010 Like, the mail server might have never heard 00:52:43.010 --> 00:52:44.926 of your connection before, never heard of you. 00:52:44.926 --> 00:52:47.760 Where does KC mail come from on the mail server side? 00:52:47.760 --> 00:52:48.889 Yeah. 00:52:48.889 --> 00:52:50.430 STUDENT: Isn't it part of the ticket? 00:52:50.430 --> 00:52:51.440 PROFESSOR: Yeah, yeah, so this is the cool thing. 00:52:51.440 --> 00:52:54.106 You send this ticket over to the mail server and the mail server 00:52:54.106 --> 00:52:56.180 knows its own secret key K mail. 00:52:56.180 --> 00:53:00.980 And it uses that to decrypt the ticket TC mail and the shared 00:53:00.980 --> 00:53:03.430 key is in there along with the name of whoever 00:53:03.430 --> 00:53:05.656 it is that you're sharing this key with. 00:53:05.656 --> 00:53:07.780 That's how it finds out, oh, I'm talking to the guy 00:53:07.780 --> 00:53:11.010 and that's the shared key we should use. 00:53:11.010 --> 00:53:12.930 Makes sense? 00:53:12.930 --> 00:53:15.970 All right, so that's the sort of basic plan 00:53:15.970 --> 00:53:20.950 for how you use this protocol in some actual application. 00:53:20.950 --> 00:53:27.490 There's-- well, there's a bunch of problems with this. 00:53:27.490 --> 00:53:30.350 So Kerberos is-- it's a nice paper to read 00:53:30.350 --> 00:53:32.570 but then there's all these problems these guys didn't 00:53:32.570 --> 00:53:33.620 know about 30 years ago. 00:53:33.620 --> 00:53:36.810 So it's sort of inevitable that there's problems 00:53:36.810 --> 00:53:38.240 you have to go through. 00:53:38.240 --> 00:53:41.180 So one interesting problem in the way 00:53:41.180 --> 00:53:45.820 Kerberos 4 encrypted and authenticated messages 00:53:45.820 --> 00:53:49.140 for applications is that they use the same key 00:53:49.140 --> 00:53:52.960 for encrypting messages from the client to the server 00:53:52.960 --> 00:53:56.580 as well as messages from the server back to the client. 00:53:56.580 --> 00:54:01.300 So suppose that the client issues, I don't know, 00:54:01.300 --> 00:54:04.110 a request to fetch a particular message. 00:54:04.110 --> 00:54:08.720 So then I say, you know, fetch the message 7. 00:54:08.720 --> 00:54:13.720 And I encrypt this thing with KC mail. 00:54:13.720 --> 00:54:15.170 That seems all great. 00:54:15.170 --> 00:54:17.590 The mail server has the shared key that's 00:54:17.590 --> 00:54:19.040 going to decrypt this message. 00:54:19.040 --> 00:54:23.690 And it's going to send me back the body of this email message 00:54:23.690 --> 00:54:26.910 also encrypted with KC mail. 00:54:26.910 --> 00:54:29.500 Does anyone see a problem with this? 00:54:29.500 --> 00:54:33.180 Why is this is potentially a bad thing to do? 00:54:33.180 --> 00:54:34.870 Anyone else? 00:54:34.870 --> 00:54:36.421 Sure. 00:54:36.421 --> 00:54:39.530 STUDENT: So there's a chapter [INAUDIBLE] 00:54:39.530 --> 00:54:42.104 they can make [INAUDIBLE] look like some other things they 00:54:42.104 --> 00:54:42.806 want [INAUDIBLE] 00:54:42.806 --> 00:54:43.750 PROFESSOR: Yes, so those are actually 00:54:43.750 --> 00:54:46.444 worrisome because I could send you any email message I want. 00:54:46.444 --> 00:54:48.610 So suppose I really want to delete some message that 00:54:48.610 --> 00:54:50.068 is sitting here in your inbox and I 00:54:50.068 --> 00:54:51.250 don't want you to read it. 00:54:51.250 --> 00:54:53.640 I know it's maybe message, I don't know, 23. 00:54:53.640 --> 00:54:55.932 So I'm going to send you an email that says, delete 23. 00:54:55.932 --> 00:54:56.931 You're going to read it. 00:54:56.931 --> 00:54:58.800 You're going to fetch it and a response 00:54:58.800 --> 00:55:00.675 is going to come from the mail server saying, 00:55:00.675 --> 00:55:03.086 delete 23 encrypted with this key. 00:55:03.086 --> 00:55:05.210 And so far, it's not being sent to the mail server. 00:55:05.210 --> 00:55:07.126 But if I look at the network at the right time 00:55:07.126 --> 00:55:09.540 and capture this packet, I can send the packet back 00:55:09.540 --> 00:55:10.690 to the mail server. 00:55:10.690 --> 00:55:13.900 It would look like a message saying delete 23 encrypted 00:55:13.900 --> 00:55:15.067 with the right key. 00:55:15.067 --> 00:55:16.900 And the mail server will say, oh yeah, sure. 00:55:16.900 --> 00:55:18.441 You're trying to delete this message. 00:55:18.441 --> 00:55:19.190 I'll do it. 00:55:19.190 --> 00:55:21.970 So this is a bit of a problem because we 00:55:21.970 --> 00:55:25.070 are allowing an adversary to confuse the mail 00:55:25.070 --> 00:55:27.860 server into whether our message was generated by it 00:55:27.860 --> 00:55:30.592 or was sent to it in the first place. 00:55:30.592 --> 00:55:32.021 So this is quite troublesome. 00:55:32.021 --> 00:55:33.520 So these are what's typically called 00:55:33.520 --> 00:55:35.144 in cryptography and protocol literature 00:55:35.144 --> 00:55:37.677 as reflection attacks. 00:55:37.677 --> 00:55:40.260 So you have any suggestions for how we can avoid this problem? 00:55:40.260 --> 00:55:40.660 Yeah. 00:55:40.660 --> 00:55:42.985 STUDENT: Can't you just include a header saying its origins? 00:55:42.985 --> 00:55:44.440 PROFESSOR: Yeah, so typically, you 00:55:44.440 --> 00:55:46.950 want to have some very unambiguous way to state what's 00:55:46.950 --> 00:55:47.900 going on. 00:55:47.900 --> 00:55:50.364 One way is to have a header in every message that says, 00:55:50.364 --> 00:55:52.780 this is going from the client to the server or from server 00:55:52.780 --> 00:55:53.720 to the client. 00:55:53.720 --> 00:55:55.860 And even better plan in practice turns out 00:55:55.860 --> 00:55:57.520 to be just use two separate keys. 00:55:57.520 --> 00:56:00.170 Because you might want to have a long stream of data 00:56:00.170 --> 00:56:02.860 where you don't really have space for this header bit. 00:56:02.860 --> 00:56:06.380 So instead, what Kerberos 5 does is every time you establish 00:56:06.380 --> 00:56:09.230 a connection with some service , you actually negotiate two keys 00:56:09.230 --> 00:56:10.690 instead of just one key. 00:56:10.690 --> 00:56:13.530 And the first key is going to be used for encrypting stuff 00:56:13.530 --> 00:56:16.780 from client to server and other from server back to the client. 00:56:16.780 --> 00:56:21.010 So that seems like a much better way to do it in practice. 00:56:21.010 --> 00:56:24.220 Make sense? 00:56:24.220 --> 00:56:30.750 All right, so I guess let's now talk a little bit 00:56:30.750 --> 00:56:33.780 about what happens with KDC. 00:56:33.780 --> 00:56:38.870 So the Kerberos server is pretty important to the system. 00:56:38.870 --> 00:56:42.000 But what happens if this KDC goes down? 00:56:42.000 --> 00:56:44.360 So how bad is it to our system. 00:56:44.360 --> 00:56:47.730 Like, in Athena, suppose if KDC crashes, 00:56:47.730 --> 00:56:49.330 does this affect your life? 00:56:49.330 --> 00:56:50.514 Well, if you use Athena. 00:56:50.514 --> 00:56:52.097 STUDENT: Is that why you can't log in? 00:56:52.097 --> 00:56:53.822 PROFESSOR: Yeah, so you can't log in. 00:56:53.822 --> 00:56:56.030 I guess the other thing is you also can't get tickets 00:56:56.030 --> 00:56:58.010 to new things as well. 00:56:58.010 --> 00:57:00.780 But kind of the cool thing is that the KDC is largely 00:57:00.780 --> 00:57:02.820 off the critical path for existing connection. 00:57:02.820 --> 00:57:04.312 So no data passes through the KDC. 00:57:04.312 --> 00:57:06.270 And if you already have a ticket for something, 00:57:06.270 --> 00:57:07.853 you can keep using it and keep logging 00:57:07.853 --> 00:57:10.220 into some service over the network. 00:57:10.220 --> 00:57:13.056 So in that way, it's actually quite nicely cacheable. 00:57:13.056 --> 00:57:14.680 I guess the other nice thing these guys 00:57:14.680 --> 00:57:17.430 do is they actually have a way of replicating 00:57:17.430 --> 00:57:18.880 the KDC potentially. 00:57:18.880 --> 00:57:21.140 So they have one master Kerberos server 00:57:21.140 --> 00:57:25.800 that stores the sort of primary copy of this whole database. 00:57:25.800 --> 00:57:29.220 And then they can have read only replicas that 00:57:29.220 --> 00:57:30.560 hold a copy of this database. 00:57:30.560 --> 00:57:32.080 They don't allow any updates to this 00:57:32.080 --> 00:57:35.270 like registering users or updating keys. 00:57:35.270 --> 00:57:39.600 But they do allow responding to login and TJS requests. 00:57:39.600 --> 00:57:43.030 So this way, these backup clones of this Kerberos database 00:57:43.030 --> 00:57:45.860 allow you to keep logging in and keep talking to services 00:57:45.860 --> 00:57:49.850 even if the master crashed and hopefully 00:57:49.850 --> 00:57:53.590 make it possible to upgrade to master without breaking 00:57:53.590 --> 00:57:56.060 everything at the same time. 00:57:56.060 --> 00:57:56.640 Makes sense? 00:57:56.640 --> 00:57:56.900 Any questions? 00:57:56.900 --> 00:57:57.200 Yeah. 00:57:57.200 --> 00:57:58.741 STUDENT: How hard is it to compromise 00:57:58.741 --> 00:58:01.292 the KDC server and [INAUDIBLE]? 00:58:01.292 --> 00:58:03.560 PROFESSOR: Well, yes, this is a huge sort 00:58:03.560 --> 00:58:05.852 of target for any system that runs Kerberos. 00:58:05.852 --> 00:58:07.310 Because if you compromise this guy, 00:58:07.310 --> 00:58:09.350 you're in complete control of the system. 00:58:09.350 --> 00:58:12.620 You can mint tickets for any service you want, 00:58:12.620 --> 00:58:15.100 pretending to be client you want. 00:58:15.100 --> 00:58:16.600 So this is pretty bad. 00:58:16.600 --> 00:58:18.654 So you really want to keep this guy secure. 00:58:18.654 --> 00:58:20.070 Now, how hard is it to compromise? 00:58:20.070 --> 00:58:21.600 Well, ideally, it's hard. 00:58:21.600 --> 00:58:25.450 And I don't know of any instances 00:58:25.450 --> 00:58:29.890 where the MIT KDC has actually been compromised in, I guess, 00:58:29.890 --> 00:58:31.700 20 years or so. 00:58:31.700 --> 00:58:34.910 So it's , I think, possible to run this reasonably security. 00:58:34.910 --> 00:58:37.070 But presumably, the things you would worry about 00:58:37.070 --> 00:58:40.440 are just software implementation security 00:58:40.440 --> 00:58:43.010 of the things that's listening on these two services, right? 00:58:43.010 --> 00:58:44.990 So if there's buffer overflows on this guys 00:58:44.990 --> 00:58:48.850 or some other vulnerability like that, that's really bad. 00:58:48.850 --> 00:58:52.270 Or if there's an SSH server running on the Kerberos KDC 00:58:52.270 --> 00:58:55.430 and someone guesses the root password on that SSH server, 00:58:55.430 --> 00:58:57.860 they'll just log in and copy the database over. 00:58:57.860 --> 00:59:00.110 So I think you really want to be careful in minimizing 00:59:00.110 --> 00:59:01.151 the attack surface there. 00:59:01.151 --> 00:59:04.040 Maybe be very careful writing the KDC code. 00:59:04.040 --> 00:59:06.300 Don't allow you to log into it directly. 00:59:06.300 --> 00:59:11.060 Maybe you even worry about physical security, et cetera. 00:59:11.060 --> 00:59:11.690 Absolutely. 00:59:11.690 --> 00:59:14.180 Luckily, this is actually one of the few places 00:59:14.180 --> 00:59:16.210 where you have to be super paranoid, though. 00:59:16.210 --> 00:59:19.020 Right, so the servers, unlike in some other systems 00:59:19.020 --> 00:59:20.940 that do trust all the machines, the servers 00:59:20.940 --> 00:59:22.770 are actually not that important. 00:59:22.770 --> 00:59:24.410 They of course store some data. 00:59:24.410 --> 00:59:28.540 But if someone compromises a mail server or a print server, 00:59:28.540 --> 00:59:30.337 you can probably recover reasonably well. 00:59:30.337 --> 00:59:32.170 So actually, here's an interesting question. 00:59:32.170 --> 00:59:34.253 Like, suppose someone compromised the mail server. 00:59:34.253 --> 00:59:37.156 What should you do to recover from this attack? 00:59:37.156 --> 00:59:38.530 Like, if someone stole your mail, 00:59:38.530 --> 00:59:39.988 I guess that's kind of unfortunate. 00:59:39.988 --> 00:59:42.710 But what do you do so that the attacker doesn't keep accessing 00:59:42.710 --> 00:59:44.150 your mail in the future? 00:59:44.150 --> 00:59:44.660 Yeah. 00:59:44.660 --> 00:59:45.844 STUDENT: [INAUDIBLE] 00:59:45.844 --> 00:59:47.510 PROFESSOR: Yeah, so in Kerberos, there's 00:59:47.510 --> 00:59:49.830 no sort of revoke operation. 00:59:49.830 --> 00:59:51.350 But what you could do is you could 00:59:51.350 --> 00:59:53.690 change generate a new key for the mail server 00:59:53.690 --> 00:59:56.000 and stick it in this database over here. 00:59:56.000 --> 00:59:59.490 And then you install a new mail server, give it the new key, 00:59:59.490 --> 01:00:02.880 and then some attacker that has the mail server's old key 01:00:02.880 --> 01:00:06.200 has no way of-- like, no influence at all on this mail 01:00:06.200 --> 01:00:08.167 server now, right? 01:00:08.167 --> 01:00:10.750 On the other hand, suppose you didn't change the mail server's 01:00:10.750 --> 01:00:13.220 key, K mail. 01:00:13.220 --> 01:00:14.726 How that is that? 01:00:14.726 --> 01:00:17.292 STUDENT: [INAUDIBLE] fine. 01:00:17.292 --> 01:00:19.500 PROFESSOR: OK, so suppose you didn't change the mail. 01:00:19.500 --> 01:00:21.125 You, like, install the new mail server. 01:00:21.125 --> 01:00:23.200 You patch whatever bug that hacker exploited. 01:00:23.200 --> 01:00:25.130 But it still has the same key K mail. 01:00:25.130 --> 01:00:28.172 And maybe it's taken a day so all the tickets are expired. 01:00:28.172 --> 01:00:30.380 Can that hacker do anything interesting in the system 01:00:30.380 --> 01:00:30.610 anymore? 01:00:30.610 --> 01:00:31.110 Yeah. 01:00:31.110 --> 01:00:33.662 STUDENT: [INAUDIBLE] 01:00:33.662 --> 01:00:36.245 PROFESSOR: Yeah, OK, so you give the new mail server the old K 01:00:36.245 --> 01:00:37.960 mail. 01:00:37.960 --> 01:00:39.711 Is that bad? 01:00:39.711 --> 01:00:40.210 Yeah. 01:00:40.210 --> 01:00:41.536 STUDENT: This is-- 01:00:43.594 --> 01:00:44.260 PROFESSOR: Sure. 01:00:44.260 --> 01:00:48.571 STUDENT: [INAUDIBLE] mail server. 01:00:48.571 --> 01:00:51.566 And [INAUDIBLE] mail server because you can 01:00:51.566 --> 01:00:52.840 encrypt that initial ticket. 01:00:52.840 --> 01:00:53.130 PROFESSOR: Right. 01:00:53.130 --> 01:00:54.780 So K mail is actually super important. 01:00:54.780 --> 01:00:57.240 And, OK, so you're saying you can decrypt all the things 01:00:57.240 --> 01:00:58.462 going on to the mail server. 01:00:58.462 --> 01:01:00.670 So suppose the client now connects to the mail server 01:01:00.670 --> 01:01:02.060 after it's been fixed up. 01:01:02.060 --> 01:01:03.890 But the attacker still knows K mail 01:01:03.890 --> 01:01:05.850 from the last time they compromised the system. 01:01:05.850 --> 01:01:08.070 They can now decrypt this ticket k mail 01:01:08.070 --> 01:01:11.382 and they can now look inside the ticket to get the session key 01:01:11.382 --> 01:01:13.590 and they can use that to decrypt all the messages you 01:01:13.590 --> 01:01:15.930 send, all the responses you get back, and so on. 01:01:15.930 --> 01:01:18.950 So it's pretty important to change this key K mail. 01:01:18.950 --> 01:01:21.170 And in many ways, it's actually even worse 01:01:21.170 --> 01:01:22.700 than just looking at the traffic. 01:01:22.700 --> 01:01:26.440 Because if the attacker know this key K mail, 01:01:26.440 --> 01:01:29.180 they can synthesize new tickets for the mail server 01:01:29.180 --> 01:01:31.100 without talking to the key DC. 01:01:31.100 --> 01:01:32.710 So suppose that I know K mail and I 01:01:32.710 --> 01:01:35.100 want to read your mail from the mail server. 01:01:35.100 --> 01:01:36.430 I'll just make up this ticket. 01:01:36.430 --> 01:01:39.030 I'll plop down all those five fields in the right order. 01:01:39.030 --> 01:01:40.950 I'll generate a new key. 01:01:40.950 --> 01:01:42.280 I'll encrypt it with K mail. 01:01:42.280 --> 01:01:45.072 It'll look like the real thing generated by the KDC. 01:01:45.072 --> 01:01:46.780 And I'll just connect to the mail server. 01:01:46.780 --> 01:01:47.450 And it'll decrypt it. 01:01:47.450 --> 01:01:49.890 It'll decrypt correctly and then it'll think, oh, yeah, 01:01:49.890 --> 01:01:52.980 this is some particular user. 01:01:52.980 --> 01:01:55.480 And you can read all their mail and you know the shared key 01:01:55.480 --> 01:01:56.590 and so on. 01:01:56.590 --> 01:01:59.870 So it's critically important too that no one knows 01:01:59.870 --> 01:02:01.770 the secret key of a service. 01:02:01.770 --> 01:02:04.120 Because otherwise, not only is the traffic 01:02:04.120 --> 01:02:06.330 to the service decryptable and observable, 01:02:06.330 --> 01:02:10.410 but also you could impersonate anyone to that service. 01:02:10.410 --> 01:02:13.730 So this is actually all pretty important in Kerberos. 01:02:13.730 --> 01:02:15.320 Makes sense? 01:02:15.320 --> 01:02:17.146 Any questions? 01:02:17.146 --> 01:02:18.118 Yeah. 01:02:18.118 --> 01:02:20.548 STUDENT: So if the attacker has to [INAUDIBLE], 01:02:20.548 --> 01:02:24.436 what's stopping him from changing the [INAUDIBLE] key 01:02:24.436 --> 01:02:25.785 [INAUDIBLE]? 01:02:25.785 --> 01:02:28.160 PROFESSOR: Yeah, so presumably, how you'd recover-- like, 01:02:28.160 --> 01:02:30.380 ISNT would, like, call up the guy that runs this KDC 01:02:30.380 --> 01:02:32.570 and say, oh man, our mail server got compromised. 01:02:32.570 --> 01:02:34.820 Why don't you go and, like, delete this key from there 01:02:34.820 --> 01:02:36.289 and put in this new key instead? 01:02:36.289 --> 01:02:38.330 So you'd probably want to have some out of bounds 01:02:38.330 --> 01:02:41.570 mechanism for proving that you're really the mail server. 01:02:41.570 --> 01:02:43.434 Because we'll look at a second on how do 01:02:43.434 --> 01:02:45.600 you change keys-- like a password changing protocol, 01:02:45.600 --> 01:02:46.410 for example. 01:02:46.410 --> 01:02:49.410 And you can in general change passwords in Kerberos. 01:02:49.410 --> 01:02:51.020 So if you know the old password, you 01:02:51.020 --> 01:02:53.920 can change the user's password to a new password here. 01:02:53.920 --> 01:02:56.702 So in order to recover, you probably-- like the attacker, 01:02:56.702 --> 01:02:58.910 might get your key mail, change it to something else. 01:02:58.910 --> 01:03:01.750 Someone with ISNT basically has to go to the Accounts office 01:03:01.750 --> 01:03:04.129 and say, hey, we're hear at ISNT. 01:03:04.129 --> 01:03:06.420 Could you please change the password of the mail server 01:03:06.420 --> 01:03:06.920 for us? 01:03:06.920 --> 01:03:08.878 And they're going to generate some new password 01:03:08.878 --> 01:03:10.320 the attacker doesn't know. 01:03:10.320 --> 01:03:14.230 So yeah, otherwise, if the attacker knows this key K mail, 01:03:14.230 --> 01:03:16.480 there's nothing differentiating the attacker from you, 01:03:16.480 --> 01:03:18.240 from the real mail server operator. 01:03:18.240 --> 01:03:20.976 In fact, the attacker probably changed the key so now they 01:03:20.976 --> 01:03:22.350 know the new thing and you don't. 01:03:22.350 --> 01:03:24.440 It's like you're not on the mail server anymore. 01:03:24.440 --> 01:03:27.210 So absolutely, you need some out of band protocol 01:03:27.210 --> 01:03:31.460 for initially registering principles in the database 01:03:31.460 --> 01:03:34.360 and for changing keys if you forget your password or someone 01:03:34.360 --> 01:03:37.400 changes for you and you lose it as well. 01:03:37.400 --> 01:03:40.020 So there's someone at MIT or there's 01:03:40.020 --> 01:03:42.950 a group of people at MIT that help users 01:03:42.950 --> 01:03:45.000 register for accounts and change their passwords 01:03:45.000 --> 01:03:48.440 by, you know, you present your MIT ID and say, oh, well, OK. 01:03:48.440 --> 01:03:49.840 Well, whatever happened, we'll be 01:03:49.840 --> 01:03:51.740 able to change your key for you then. 01:03:51.740 --> 01:03:53.890 Make sense? 01:03:53.890 --> 01:03:55.390 So it's pretty important, of course, 01:03:55.390 --> 01:03:57.990 to do that right so if the person that 01:03:57.990 --> 01:04:01.310 is allowing password resets does the wrong thing when checking 01:04:01.310 --> 01:04:04.140 your MIT ID, you'll be able to compromise the system as well, 01:04:04.140 --> 01:04:04.280 right? 01:04:04.280 --> 01:04:06.321 So they are sort of part of the trusted computing 01:04:06.321 --> 01:04:07.405 base in Kerberos, right? 01:04:07.405 --> 01:04:09.530 Like, anyone that can go and muck with the database 01:04:09.530 --> 01:04:13.990 is pretty important for security here. 01:04:13.990 --> 01:04:17.149 All right, so let's look at another sort of interesting use 01:04:17.149 --> 01:04:17.940 of Kerberos, right? 01:04:17.940 --> 01:04:22.750 So you could use Kerberos to try to log into some remote machine 01:04:22.750 --> 01:04:24.329 over SSH. 01:04:24.329 --> 01:04:26.620 And the way this would work is, of course, very similar 01:04:26.620 --> 01:04:27.340 to a mail server. 01:04:27.340 --> 01:04:28.881 You'd get a ticket for the SSH server 01:04:28.881 --> 01:04:32.080 and you'd send the ticket along with your SSH connection. 01:04:32.080 --> 01:04:34.860 But what if you're SSHing into Athena dot dial-up 01:04:34.860 --> 01:04:37.210 and you don't have a Kerberos client on your machine? 01:04:37.210 --> 01:04:39.270 You just want to log into Athena dot dial-up 01:04:39.270 --> 01:04:42.360 with your regular password. 01:04:42.360 --> 01:04:44.840 So how would Athena dial-up authenticate you, then, 01:04:44.840 --> 01:04:48.060 if you're just plugging into this machine with a password? 01:04:48.060 --> 01:04:50.120 But you have no password for Athena dot dial-up. 01:04:50.120 --> 01:04:51.772 It's on a Kerberos server. 01:04:51.772 --> 01:04:53.230 So which should the dial-up machine 01:04:53.230 --> 01:04:54.880 do when you log into it with a password? 01:04:54.880 --> 01:04:55.250 Yeah. 01:04:55.250 --> 01:04:56.990 STUDENT: You can access the [INAUDIBLE]. 01:04:56.990 --> 01:04:58.770 PROFESSOR: Yeah, so the dial-up is then 01:04:58.770 --> 01:05:01.200 going to basically play the same protocol logging you in. 01:05:01.200 --> 01:05:03.850 So it's going to send a request. 01:05:03.850 --> 01:05:04.600 This thing, right? 01:05:04.600 --> 01:05:07.960 It's going to send a request to the Kerberos service asking, 01:05:07.960 --> 01:05:11.550 give me a ticket for, I don't know, this user Alice. 01:05:11.550 --> 01:05:15.050 And in response, it's going to get back this reply encrypted 01:05:15.050 --> 01:05:16.280 with Alice's password. 01:05:16.280 --> 01:05:19.250 And then it's going to try the password you just applied 01:05:19.250 --> 01:05:21.050 and see if it decrypts correctly. 01:05:21.050 --> 01:05:22.650 And if it decrypts correctly, it's 01:05:22.650 --> 01:05:25.270 going to let you log in, right? 01:05:25.270 --> 01:05:25.770 Yeah. 01:05:25.770 --> 01:05:27.228 STUDENT: You don't even really have 01:05:27.228 --> 01:05:30.370 to send your key to the SSH server. 01:05:30.370 --> 01:05:32.840 Because it could relay this back-- 01:05:32.840 --> 01:05:35.230 the dot encrypted thing with KC. 01:05:35.230 --> 01:05:38.948 It could relay that back to the user over the SSH connection. 01:05:38.948 --> 01:05:40.380 PROFESSOR: Potentially, yeah. 01:05:40.380 --> 01:05:42.560 Right, so this requires some fancy SSH client 01:05:42.560 --> 01:05:43.810 that you might not have. 01:05:43.810 --> 01:05:45.400 But-- so yeah, absolutely right. 01:05:45.400 --> 01:05:46.790 If you want to do this right, you 01:05:46.790 --> 01:05:49.081 probably want to have a Kerberos client on your machine 01:05:49.081 --> 01:05:51.370 and get a ticket yourself or maybe 01:05:51.370 --> 01:05:53.460 proxy it somehow through the SSH server 01:05:53.460 --> 01:05:56.104 but not allow the SSH server to have your key. 01:05:56.104 --> 01:05:57.270 That's probably a good plan. 01:05:57.270 --> 01:06:01.518 STUDENT: [INAUDIBLE] just, the server could get 01:06:01.518 --> 01:06:02.940 through this wall [INAUDIBLE] 01:06:02.940 --> 01:06:03.108 PROFESSOR: That's right. 01:06:03.108 --> 01:06:05.165 Then you might decrypt it and send back. 01:06:05.165 --> 01:06:07.290 OK, but in either case, right, all we're doing here 01:06:07.290 --> 01:06:11.279 is someone is going to try to decrypt this blob with KC. 01:06:11.279 --> 01:06:13.320 And then the server is going to get this resolved 01:06:13.320 --> 01:06:14.403 and see if it looks right. 01:06:14.403 --> 01:06:16.476 It's going to allow you in. 01:06:16.476 --> 01:06:19.219 Seem like a good plan? 01:06:19.219 --> 01:06:21.760 So, turns out this is actually a fairly dangerous thing to do 01:06:21.760 --> 01:06:24.315 and allows you to potentially log into the SSH server 01:06:24.315 --> 01:06:26.020 as anyone. 01:06:26.020 --> 01:06:28.650 And the reason is that previously, 01:06:28.650 --> 01:06:31.930 when we were talking about a client trying to log in, 01:06:31.930 --> 01:06:33.549 the client basically knew that it 01:06:33.549 --> 01:06:35.340 was trying to supply a legitimate password, 01:06:35.340 --> 01:06:37.780 it was getting a reply from the right Kerberos server, 01:06:37.780 --> 01:06:40.870 and if it can decrypt it, then probably the password works out 01:06:40.870 --> 01:06:42.010 correctly. 01:06:42.010 --> 01:06:44.650 However, there's nothing here in this protocol that 01:06:44.650 --> 01:06:47.500 authenticates the fact that this reply is coming 01:06:47.500 --> 01:06:50.670 from the right Kerberos server. 01:06:50.670 --> 01:06:57.470 So if I try to log into a machine by typing in a password 01:06:57.470 --> 01:07:00.080 and the machine sends out this request 01:07:00.080 --> 01:07:02.700 and some response comes back that seems 01:07:02.700 --> 01:07:06.170 to be encrypted with the password I typed in, 01:07:06.170 --> 01:07:09.750 this response might not be from the Kerberos server. 01:07:09.750 --> 01:07:12.090 So suppose I have some machine I want to log into. 01:07:12.090 --> 01:07:14.510 I type a password X into it. 01:07:14.510 --> 01:07:16.960 And then the machine sends out this response. 01:07:16.960 --> 01:07:19.280 And before the Kerberos server can respond back 01:07:19.280 --> 01:07:23.210 with the real reply, I'll send my own reply that 01:07:23.210 --> 01:07:27.640 looks like this real response encrypted with my password X. 01:07:27.640 --> 01:07:31.540 And the workstation to which I try to log in or the SSH server 01:07:31.540 --> 01:07:33.780 is going to decrypt it with my fake password. 01:07:33.780 --> 01:07:36.180 It's going to look OK because this response was 01:07:36.180 --> 01:07:39.880 generated by me rather than the real Kerberos server. 01:07:39.880 --> 01:07:45.395 And you'll be able to log in This make sense? 01:07:45.395 --> 01:07:46.270 Why does this happen? 01:07:51.704 --> 01:07:52.692 Yeah. 01:07:52.692 --> 01:07:54.668 STUDENT: [INAUDIBLE] there's no authentication 01:07:54.668 --> 01:07:56.660 from the Kerberos server [INAUDIBLE] 01:07:56.660 --> 01:07:57.550 PROFESSOR: Right, yeah, so there's 01:07:57.550 --> 01:07:59.940 nothing really here that's tying this to the real Kerberos 01:07:59.940 --> 01:08:00.440 server. 01:08:00.440 --> 01:08:04.850 So the way that Kerberos fixes this 01:08:04.850 --> 01:08:08.300 for remotely accessible machines like Athena 01:08:08.300 --> 01:08:11.100 dot dial-up is that the dial-ups themselves 01:08:11.100 --> 01:08:14.700 have some sort of a secret key that they share with the KDC. 01:08:14.700 --> 01:08:16.720 So in order to log you in into a dial-up 01:08:16.720 --> 01:08:19.210 or to any workstation that really cares about checking 01:08:19.210 --> 01:08:21.159 whether you are really the right user, 01:08:21.159 --> 01:08:22.700 it's actually going to do two things. 01:08:22.700 --> 01:08:26.229 It's going to first log you into Kerberos like this. 01:08:26.229 --> 01:08:28.880 But then just because this reply decrypts correctly, 01:08:28.880 --> 01:08:30.439 it's not going to trust that. 01:08:30.439 --> 01:08:33.090 It's going to try to get a service 01:08:33.090 --> 01:08:35.910 ticket for itself using TGS. 01:08:35.910 --> 01:08:39.899 So the dial-up machine here has its own secret key. 01:08:39.899 --> 01:08:42.229 And it logs you in with this round one. 01:08:42.229 --> 01:08:45.569 Then it talks to TGS saying, oh, please give me 01:08:45.569 --> 01:08:48.740 a service ticket for my own principle, 01:08:48.740 --> 01:08:51.359 from the dial-up principle, for this client. 01:08:51.359 --> 01:08:52.880 Then it gets the response back. 01:08:52.880 --> 01:08:55.479 And then it checks if it can decrypt the response correctly. 01:08:55.479 --> 01:08:59.220 Because it knows the dial-up key for this KS. 01:08:59.220 --> 01:09:01.390 And if this decrpyts, that it knows, oh yeah, 01:09:01.390 --> 01:09:03.390 I must have talked to the right Kerberos server. 01:09:03.390 --> 01:09:04.973 Because only the right Kerberos server 01:09:04.973 --> 01:09:07.200 would have sent me this second round ticket encrypted 01:09:07.200 --> 01:09:10.665 with my secret key K dial-up. 01:09:10.665 --> 01:09:12.779 So this is actually pretty important. 01:09:12.779 --> 01:09:14.744 And typically, Athena workstations 01:09:14.744 --> 01:09:17.160 don't do this extra step because Athena workstations don't 01:09:17.160 --> 01:09:19.100 have any secret key stored on them 01:09:19.100 --> 01:09:21.494 that's shared with the KDC. 01:09:21.494 --> 01:09:23.535 Why is this OK for Athena workstations to let you 01:09:23.535 --> 01:09:26.535 log in in this one round trip and not for dial-ups? 01:09:26.535 --> 01:09:27.035 Yeah. 01:09:27.035 --> 01:09:29.076 STUDENT: If you don't have access to any services 01:09:29.076 --> 01:09:31.035 because the attacker couldn't forge the ticket. 01:09:31.035 --> 01:09:32.284 PROFESSOR: That's right, yeah. 01:09:32.284 --> 01:09:35.060 So there's nothing interesting on the dial-up machine itself-- 01:09:35.060 --> 01:09:36.510 sorry, on the workstation itself. 01:09:36.510 --> 01:09:39.660 So workstation, whenever-- you have root access on it anyway. 01:09:39.660 --> 01:09:42.930 So if you log into it with a fake password, who cares? 01:09:42.930 --> 01:09:45.010 It's not like you'll be able to do anything else 01:09:45.010 --> 01:09:46.519 outside of your workstation. 01:09:46.519 --> 01:09:48.810 Whereas on a dial-up, things are much more interesting. 01:09:48.810 --> 01:09:50.851 It might be that you have other processes running 01:09:50.851 --> 01:09:52.920 on the dial-up from other login sessions. 01:09:52.920 --> 01:09:56.440 And there, the fact that you log in with a particular Unix UID 01:09:56.440 --> 01:09:58.070 is actually pretty important. 01:09:58.070 --> 01:10:00.230 And there, they really want to authenticate 01:10:00.230 --> 01:10:02.360 that you are the right entity. 01:10:02.360 --> 01:10:05.780 So that's why they do this sort of 2-step process for logging 01:10:05.780 --> 01:10:09.140 into some shared time-sharing machine. 01:10:09.140 --> 01:10:12.020 Make sense? 01:10:12.020 --> 01:10:15.230 All right, so the last thing I want to talk about 01:10:15.230 --> 01:10:16.840 is how do we change keys. 01:10:16.840 --> 01:10:19.230 So we sort of talked about it briefly here with the idea 01:10:19.230 --> 01:10:22.029 that the mail server's key might get compromised. 01:10:22.029 --> 01:10:23.570 But as a user, you probably also want 01:10:23.570 --> 01:10:26.080 to change passwords as well. 01:10:26.080 --> 01:10:28.861 Like, maybe you're thinking, oh, that password is not so great 01:10:28.861 --> 01:10:29.360 anymore. 01:10:29.360 --> 01:10:31.390 Maybe I accidentally wrote it on a piece of paper and someone 01:10:31.390 --> 01:10:32.280 looked at it. 01:10:32.280 --> 01:10:34.100 So you probably want to change it. 01:10:34.100 --> 01:10:36.120 So the way this works is actually 01:10:36.120 --> 01:10:38.150 at some level fairly straightforward. 01:10:38.150 --> 01:10:41.440 So there's an extra interface to this Kerberos server. 01:10:41.440 --> 01:10:43.570 In addition to Kerberos and TGS, there's 01:10:43.570 --> 01:10:45.280 this extra service called kpassword. 01:10:48.720 --> 01:10:52.690 And the service lets you change your password. 01:10:52.690 --> 01:10:55.744 And the way it works is you get a ticket for this service 01:10:55.744 --> 01:10:57.660 very much like you'd get a ticket for the mail 01:10:57.660 --> 01:10:59.750 server or any other service. 01:10:59.750 --> 01:11:01.592 And then you send your new password 01:11:01.592 --> 01:11:03.800 to this kpassword service encrypted with your session 01:11:03.800 --> 01:11:04.910 key. 01:11:04.910 --> 01:11:08.900 And then if everything checks out, your key in the database 01:11:08.900 --> 01:11:12.330 is going to be updated to the new key. 01:11:12.330 --> 01:11:13.070 Question. 01:11:13.070 --> 01:11:14.736 STUDENT: [INAUDIBLE] if there was, like, 01:11:14.736 --> 01:11:17.339 no [INAUDIBLE] they wanted to have them use a [INAUDIBLE] had 01:11:17.339 --> 01:11:18.130 to go through this. 01:11:18.130 --> 01:11:18.590 PROFESSOR: That's right. 01:11:18.590 --> 01:11:19.170 OK, yeah, OK. 01:11:19.170 --> 01:11:20.169 So this is a good point. 01:11:20.169 --> 01:11:22.595 So for changing your password, remember 01:11:22.595 --> 01:11:24.720 that we have this whole goal that if someone steals 01:11:24.720 --> 01:11:28.270 your ticket, it shouldn't be good enough to completely take 01:11:28.270 --> 01:11:29.750 over your account. 01:11:29.750 --> 01:11:32.849 So for this reason, the key password service actually 01:11:32.849 --> 01:11:34.140 doesn't accept just any ticket. 01:11:34.140 --> 01:11:36.900 It accepts a ticket that you initially get from the Kerberos 01:11:36.900 --> 01:11:39.740 service with your KC. 01:11:39.740 --> 01:11:42.430 So the way this actually works is that inside of every ticket, 01:11:42.430 --> 01:11:44.763 in addition to all the stuff I showed you there, there's 01:11:44.763 --> 01:11:47.550 an extra bit that tells you which of these two things 01:11:47.550 --> 01:11:48.836 gave you the ticket. 01:11:48.836 --> 01:11:50.960 So if you get the ticket from this Kerberos server, 01:11:50.960 --> 01:11:52.082 the bit has one. 01:11:52.082 --> 01:11:54.540 If you get the ticket from the TGS server, the bit is zero, 01:11:54.540 --> 01:11:55.500 let's say. 01:11:55.500 --> 01:11:58.160 And then the kpassword service, in addition to everything 01:11:58.160 --> 01:12:00.037 that any mail server or file server would do, 01:12:00.037 --> 01:12:01.620 it also looks at the bit on the ticket 01:12:01.620 --> 01:12:04.210 and says, well, if you got it from Kerberos, that's good. 01:12:04.210 --> 01:12:05.700 If you got it from TGS, that means 01:12:05.700 --> 01:12:08.020 that maybe you stole someone's ticket 01:12:08.020 --> 01:12:10.000 and you didn't know their password right away. 01:12:10.000 --> 01:12:11.880 So I'm not going to accept this. 01:12:11.880 --> 01:12:14.540 So this is how a key password ensures that you can only 01:12:14.540 --> 01:12:17.637 change the password if you just knew the password immediately 01:12:17.637 --> 01:12:18.220 prior to this. 01:12:18.220 --> 01:12:21.980 So you never actually supply the old password to kpassword. 01:12:21.980 --> 01:12:24.172 You supply that to-- well, you supply that in order 01:12:24.172 --> 01:12:25.880 to decrypt the response from the Kerberos 01:12:25.880 --> 01:12:28.940 server for the kpassword password principal. 01:12:28.940 --> 01:12:31.390 Makes sense? 01:12:31.390 --> 01:12:36.670 All right, so let's just actually spell out 01:12:36.670 --> 01:12:40.350 the interactions with the key password service 01:12:40.350 --> 01:12:43.320 because there'll be something a little bit interesting there. 01:12:43.320 --> 01:12:48.480 So when you're going to change your password, what 01:12:48.480 --> 01:12:51.400 the client is going to do is, of course, 01:12:51.400 --> 01:12:54.990 obtain this initial ticket from Kerberos. 01:12:54.990 --> 01:12:58.890 So it sends a message to the Kerberos service saying here 01:12:58.890 --> 01:13:03.760 is my client ID and I want to talk to the kpassword service. 01:13:03.760 --> 01:13:07.220 And the Kerberos server is going to send a response back 01:13:07.220 --> 01:13:09.690 including the ticket between the client 01:13:09.690 --> 01:13:16.370 and the kpassword service encrypted with a key of kpass 01:13:16.370 --> 01:13:21.801 and the shared key between KC and kpass. 01:13:21.801 --> 01:13:22.300 Makes sense? 01:13:22.300 --> 01:13:25.995 This is exactly this thing up here encrypted with KC. 01:13:25.995 --> 01:13:26.560 Makes sense? 01:13:26.560 --> 01:13:28.050 Everyone's runs on board? 01:13:28.050 --> 01:13:30.962 And then very much like you talk to a mail server, you take this 01:13:30.962 --> 01:13:32.170 and you send it to kpassword. 01:13:32.170 --> 01:13:37.420 You say, well, here's my ticket-- tckpass encrypted 01:13:37.420 --> 01:13:39.500 with kpass. 01:13:39.500 --> 01:13:45.370 And in addition, you send your new password 01:13:45.370 --> 01:13:50.240 and you encrypt this with the key kcpass 01:13:50.240 --> 01:13:52.340 with shared key for your interaction. 01:13:52.340 --> 01:13:55.561 I just separated these two things out here. 01:13:55.561 --> 01:13:56.060 Make sense? 01:13:56.060 --> 01:13:57.650 So this is the thing you send to the kpassword service 01:13:57.650 --> 01:14:00.140 with a new password encrypted with the session key. 01:14:00.140 --> 01:14:00.640 Yeah. 01:14:00.640 --> 01:14:02.116 STUDENT: But in the [INAUDIBLE] 01:14:06.367 --> 01:14:08.450 PROFESSOR: So if the attacker knows your password, 01:14:08.450 --> 01:14:11.420 they can change your password-- absolutely. 01:14:11.420 --> 01:14:12.670 So it seems reasonable, right? 01:14:12.670 --> 01:14:15.110 Like, there's no other way to tell whether it's you or not. 01:14:15.110 --> 01:14:17.060 If someone walks up to an Athena workstation, types 01:14:17.060 --> 01:14:19.047 in your username and password, runs password, 01:14:19.047 --> 01:14:21.630 change my password to this new thing, they know your password? 01:14:21.630 --> 01:14:23.340 They're going to be able to change it. 01:14:23.340 --> 01:14:25.010 So that's totally the same in almost any system 01:14:25.010 --> 01:14:25.760 you could imagine. 01:14:25.760 --> 01:14:27.150 This is true for Gmail probably. 01:14:27.150 --> 01:14:31.240 This is true for any system that uses passwords in general. 01:14:31.240 --> 01:14:33.840 The reason that we had to talk to the Kerberos server instead 01:14:33.840 --> 01:14:39.610 of the TGS server here is that if someone steals your ticket, 01:14:39.610 --> 01:14:42.700 then we don't want them to be able to change your password. 01:14:42.700 --> 01:14:46.170 So if someone corrupts an Athena workstation after you log in, 01:14:46.170 --> 01:14:49.420 your password is gone from memory, the ticket remains. 01:14:49.420 --> 01:14:51.370 You could, in principle, use the ticket 01:14:51.370 --> 01:14:54.916 to obtain more tickets for the password changing service. 01:14:54.916 --> 01:14:56.290 But the password changing service 01:14:56.290 --> 01:14:57.270 says that's not going to be good enough. 01:14:57.270 --> 01:14:58.645 It's going to look at this ticket 01:14:58.645 --> 01:15:01.950 here-- ticket between the client and the password service. 01:15:01.950 --> 01:15:04.764 And if that was updated through TGS, 01:15:04.764 --> 01:15:06.180 it's going to reject your request. 01:15:06.180 --> 01:15:08.513 It's only going to accept it if it was obtained directly 01:15:08.513 --> 01:15:11.260 from the Kerberos service using KC. 01:15:11.260 --> 01:15:11.761 Makes sense? 01:15:11.761 --> 01:15:12.260 Question. 01:15:12.260 --> 01:15:14.794 STUDENT: So if you [INAUDIBLE] password with the [INAUDIBLE] 01:15:14.794 --> 01:15:15.454 Athena, right? 01:15:15.454 --> 01:15:16.120 PROFESSOR: Yeah. 01:15:16.120 --> 01:15:18.375 STUDENT: So if I would steal your private key-- 01:15:18.375 --> 01:15:20.590 PROFESSOR: Yeah, so actually, KC is 01:15:20.590 --> 01:15:22.896 basically equivalent to your password here. 01:15:22.896 --> 01:15:24.770 As far as the Kerberos protocol is concerned, 01:15:24.770 --> 01:15:26.728 that don't even think that you have a password. 01:15:26.728 --> 01:15:28.510 It thinks you have a private key KC. 01:15:28.510 --> 01:15:31.000 If someone knows KC, that's basically your password. 01:15:31.000 --> 01:15:32.678 So you can change your key from KC 01:15:32.678 --> 01:15:34.886 to something else so you don't lose this thing, yeah. 01:15:34.886 --> 01:15:36.690 Uh, yeah, question? 01:15:36.690 --> 01:15:41.926 STUDENT: [INAUDIBLE] initial message [INAUDIBLE] 01:15:41.926 --> 01:15:44.410 from changing the [INAUDIBLE] 01:15:44.410 --> 01:15:45.910 PROFESSOR: Oh, you can certainly get 01:15:45.910 --> 01:15:48.725 a ticket for some other service or an attacker 01:15:48.725 --> 01:15:50.600 could drop this message altogether or corrupt 01:15:50.600 --> 01:15:51.480 this exchange. 01:15:51.480 --> 01:15:52.790 And then you're not going to successfully change 01:15:52.790 --> 01:15:53.255 your password. 01:15:53.255 --> 01:15:54.088 STUDENT: [INAUDIBLE] 01:15:56.456 --> 01:15:58.080 PROFESSOR: Yeah, so the client actually 01:15:58.080 --> 01:16:00.350 knows exactly what service it wants to talk to. 01:16:00.350 --> 01:16:07.120 So if it-- it's going to make sure, well, 01:16:07.120 --> 01:16:09.620 there are some messages, some parts of this protocol I'm not 01:16:09.620 --> 01:16:11.810 showing that allow the client to make sure 01:16:11.810 --> 01:16:14.330 they actually got the ticket for the right thing. 01:16:14.330 --> 01:16:17.200 But yeah, so the-- sorry. 01:16:17.200 --> 01:16:17.700 Question? 01:16:17.700 --> 01:16:20.941 STUDENT: [INAUDIBLE] very easy to denial of service attack 01:16:20.941 --> 01:16:25.207 when an attacker [INAUDIBLE] modifying the encrypted version 01:16:25.207 --> 01:16:26.926 of the new password. 01:16:26.926 --> 01:16:29.340 PROFESSOR: Yeah, so there's actually lot of things. 01:16:29.340 --> 01:16:34.392 Because, for example, Kerberos doesn't do authentication 01:16:34.392 --> 01:16:35.850 properly of messages-- it just does 01:16:35.850 --> 01:16:38.270 encryption-- you could totally corrupt this blob. 01:16:38.270 --> 01:16:38.770 And-- 01:16:38.770 --> 01:16:39.870 STUDENT: [INAUDIBLE] 01:16:39.870 --> 01:16:40.924 PROFESSOR: Yeah, you could flip it around 01:16:40.924 --> 01:16:42.770 and it'll decrypt to something else. 01:16:42.770 --> 01:16:44.260 The service was like, oh yeah, that's the new password, 01:16:44.260 --> 01:16:44.882 and set it. 01:16:44.882 --> 01:16:46.340 And then you're sort of locked out. 01:16:46.340 --> 01:16:47.631 So it seems really unfortunate. 01:16:47.631 --> 01:16:49.130 And this is yet another reason why 01:16:49.130 --> 01:16:52.325 you want separate encryption and authentication in the protocol. 01:16:52.325 --> 01:16:54.200 There's actually an even bigger problem here. 01:16:54.200 --> 01:16:55.080 But actually, yeah, question? 01:16:55.080 --> 01:16:56.947 STUDENT: What's the point of having a one way 01:16:56.947 --> 01:16:59.196 function to [INAUDIBLE] your password in KC if they're 01:16:59.196 --> 01:17:01.350 essentially [INAUDIBLE]? 01:17:01.350 --> 01:17:05.060 PROFESSOR: Basically because KC is a 56-bit ds key 01:17:05.060 --> 01:17:07.060 and your password might be of different lengths. 01:17:07.060 --> 01:17:09.430 And even if it's longer than 56 bits, which 01:17:09.430 --> 01:17:11.360 is seven bites or seven characters, 01:17:11.360 --> 01:17:13.630 you want to use all those extra bytes too. 01:17:13.630 --> 01:17:17.900 So it's mostly just to condense it down to a fixed width blob, 01:17:17.900 --> 01:17:18.996 yeah. 01:17:18.996 --> 01:17:21.412 But there's actually a much more interesting problem here, 01:17:21.412 --> 01:17:23.990 which is that suppose that I change my password 01:17:23.990 --> 01:17:27.820 and then I decide, OK, well, I change my password. 01:17:27.820 --> 01:17:29.930 A day goes by and I'm thinking, oh yeah, sure. 01:17:29.930 --> 01:17:32.370 I'll tell everyone what my stupid old password was. 01:17:32.370 --> 01:17:35.200 Is this a good idea in Kerberos? 01:17:35.200 --> 01:17:35.700 Yeah. 01:17:35.700 --> 01:17:38.346 STUDENT: [INAUDIBLE] immediately expire until the-- 01:17:38.346 --> 01:17:39.230 PROFESSOR: Yeah, OK. 01:17:39.230 --> 01:17:40.470 But someone's got to wait for all my tickets to expire. 01:17:40.470 --> 01:17:42.380 I wait for, like, a week. 01:17:42.380 --> 01:17:44.020 And then no tickets are good anymore. 01:17:44.020 --> 01:17:45.611 Can I give out my old password now? 01:17:45.611 --> 01:17:46.110 Yeah. 01:17:46.110 --> 01:17:48.389 STUDENT: It might take a while to replicate. 01:17:48.389 --> 01:17:49.930 PROFESSOR: Yeah, suppose the replicas 01:17:49.930 --> 01:17:51.661 are all updated, yeah, all the stuff. 01:17:51.661 --> 01:17:52.160 Yeah. 01:17:52.160 --> 01:17:54.701 STUDENT: [INAUDIBLE] if someone saves the initial transaction 01:17:54.701 --> 01:17:56.579 [INAUDIBLE] to get, like, your old password 01:17:56.579 --> 01:17:57.570 now that they have your new password. 01:17:57.570 --> 01:17:58.310 PROFESSOR: Yeah, so this is actually 01:17:58.310 --> 01:17:59.850 super worrisome in Kerberos, which 01:17:59.850 --> 01:18:01.560 is that-- suppose some attacker was 01:18:01.560 --> 01:18:04.240 watching all of my previous password changes. 01:18:04.240 --> 01:18:07.690 They didn't know what my password was or is or anything. 01:18:07.690 --> 01:18:10.460 But they're just saving these packets very diligently. 01:18:10.460 --> 01:18:13.360 And then a month later, I go and say, oh, my password 01:18:13.360 --> 01:18:15.820 was poodle or something silly like this. 01:18:15.820 --> 01:18:17.520 And then they go say ah, ha, ha. 01:18:17.520 --> 01:18:19.630 I can now decrypt this initial thing 01:18:19.630 --> 01:18:21.550 because it was encrypted with your old KC. 01:18:21.550 --> 01:18:25.230 And I can get this KC with pass that you shared. 01:18:25.230 --> 01:18:27.270 Then I can use this to decrypt the new password 01:18:27.270 --> 01:18:28.160 you sent to the KDC. 01:18:28.160 --> 01:18:29.910 And even if you change the password again, 01:18:29.910 --> 01:18:31.500 I can decrypt the next round as well. 01:18:31.500 --> 01:18:33.833 And you can just keep going and get the newest password. 01:18:33.833 --> 01:18:38.000 So in this particular password, changing protocol, if you ever 01:18:38.000 --> 01:18:40.040 disclose an old password, then someone 01:18:40.040 --> 01:18:43.330 could sort of unzip this whole chain of encrypted messages 01:18:43.330 --> 01:18:45.860 and get your newest password as well. 01:18:45.860 --> 01:18:47.860 This is actually very troublesome in the design. 01:18:47.860 --> 01:18:48.360 Yeah. 01:18:48.360 --> 01:18:51.115 STUDENT: Doesn't the later version of Kerberos [INAUDIBLE] 01:18:51.115 --> 01:18:52.240 PROFESSOR: Absolutely, yes. 01:18:52.240 --> 01:18:53.380 So there's actually a solution to this 01:18:53.380 --> 01:18:54.490 that's not sort of fundamental. 01:18:54.490 --> 01:18:55.865 And this is something they didn't 01:18:55.865 --> 01:18:57.160 realize in Kerberos version 4. 01:18:57.160 --> 01:19:00.610 There's actually this nice mechanism called Diffie-Hellman 01:19:00.610 --> 01:19:03.800 that I'll just sketch out in like one minute 01:19:03.800 --> 01:19:06.420 just so that you guys know when to use it or et cetera. 01:19:06.420 --> 01:19:08.920 But it's basically a solution for this kind of a problem 01:19:08.920 --> 01:19:11.630 where you want to stop this unzipping from happening. 01:19:11.630 --> 01:19:13.730 So what happens in the Kerberos version 01:19:13.730 --> 01:19:16.910 5 password changing protocol is that actually you 01:19:16.910 --> 01:19:20.370 want to establish a new secret that will not be apparent 01:19:20.370 --> 01:19:23.360 if you happen to decrypt all the messages on the wire. 01:19:23.360 --> 01:19:25.620 And the way this works is-- this is like some math 01:19:25.620 --> 01:19:27.286 that you don't have to fully understand. 01:19:27.286 --> 01:19:33.590 But the client some random value X. And the kpassword server is 01:19:33.590 --> 01:19:35.630 going to pick some other random value Y. 01:19:35.630 --> 01:19:37.820 And what they send to each other are exponentiations 01:19:37.820 --> 01:19:39.050 of these values. 01:19:39.050 --> 01:19:41.500 So the client sends G to the power X 01:19:41.500 --> 01:19:45.810 to the server and the server sends G to the power Y 01:19:45.810 --> 01:19:47.260 back to the client. 01:19:47.260 --> 01:19:48.890 And it turns out that mathematically, 01:19:48.890 --> 01:19:52.110 what we can do now is the client can take G to the Y, 01:19:52.110 --> 01:19:55.270 raise it to X, and get this value G to the XY. 01:19:55.270 --> 01:19:58.680 The server can take G to the X, raise it to the power Y, 01:19:58.680 --> 01:20:00.650 and get G to the XY as well. 01:20:00.650 --> 01:20:03.670 They can now use this secret value G to the XY 01:20:03.670 --> 01:20:05.440 to encrypt their subsequent messages, 01:20:05.440 --> 01:20:07.710 including the new password. 01:20:07.710 --> 01:20:11.263 So you send the new password encrypted with this value G 01:20:11.263 --> 01:20:13.400 to the XY, roughly speaking. 01:20:13.400 --> 01:20:14.830 But for some mathematical reasons 01:20:14.830 --> 01:20:16.600 that we're not going to cover right now, 01:20:16.600 --> 01:20:19.350 it turns out to be super difficult for someone that just 01:20:19.350 --> 01:20:23.350 gets G to the X and G to the Y by examining your packets later 01:20:23.350 --> 01:20:26.200 from figuring out what was G to the XY. 01:20:26.200 --> 01:20:28.560 So this is something called the discrete log problem. 01:20:28.560 --> 01:20:29.350 Yeah, question? 01:20:29.350 --> 01:20:31.140 STUDENT: But they have to [INAUDIBLE] G at some point. 01:20:31.140 --> 01:20:31.570 PROFESSOR: Yeah, yeah. 01:20:31.570 --> 01:20:33.535 So G is some parameter you could sort of send 01:20:33.535 --> 01:20:35.910 at the beginning of a protocol or it could be just cooked 01:20:35.910 --> 01:20:36.640 into Kerberos. 01:20:36.640 --> 01:20:42.030 It turns out to be relatively less important. 01:20:42.030 --> 01:20:44.410 All right, so anyway, use Diffie-Hellman because this 01:20:44.410 --> 01:20:46.660 is called-- well, what you should Google for if you're 01:20:46.660 --> 01:20:50.920 building a protocol like this is this Diffie-Hellman key 01:20:50.920 --> 01:20:51.950 exchange protocol. 01:20:51.950 --> 01:20:54.302 And Kerberos 5 actually does this correctly. 01:20:54.302 --> 01:20:56.010 But this is something to really watch out 01:20:56.010 --> 01:20:59.169 for if you're designing any kind of new protocol yourself. 01:20:59.169 --> 01:21:00.710 All right, so that's it for Kerberos. 01:21:00.710 --> 01:21:03.160 Let's talk about SSL on Monday.