1 00:00:00,080 --> 00:00:02,430 The following content is provided under a Creative 2 00:00:02,430 --> 00:00:03,820 Commons license. 3 00:00:03,820 --> 00:00:06,060 Your support will help MIT OpenCourseWare 4 00:00:06,060 --> 00:00:10,150 continue to offer high quality educational resources for free. 5 00:00:10,150 --> 00:00:12,690 To make a donation or to view additional materials 6 00:00:12,690 --> 00:00:16,600 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:16,600 --> 00:00:17,260 at ocw.mit.edu. 8 00:00:26,340 --> 00:00:29,150 PROFESSOR: So today, we're going to talk about Kerberos, which 9 00:00:29,150 --> 00:00:32,750 is a cryptographically secure, in some ways, 10 00:00:32,750 --> 00:00:36,210 protocol for authenticating computers 11 00:00:36,210 --> 00:00:38,671 and applications to one another over the network. 12 00:00:38,671 --> 00:00:40,670 So this is now finally going to use cryptography 13 00:00:40,670 --> 00:00:42,490 whereas last lecture, we looked at just 14 00:00:42,490 --> 00:00:46,242 using these TCP sequence numbers to provide security. 15 00:00:46,242 --> 00:00:47,700 So before we dive into the details, 16 00:00:47,700 --> 00:00:49,825 I want to mention there's two bits of administrivia 17 00:00:49,825 --> 00:00:51,970 that you might want to know. 18 00:00:51,970 --> 00:00:55,020 There's a quiz review today 7 to 9 o'clock in some room, 19 00:00:55,020 --> 00:00:56,570 I think 32 or 23. 20 00:00:56,570 --> 00:00:59,910 It's on schedule page and the quiz is next Wednesday. 21 00:00:59,910 --> 00:01:01,760 And also, we want you guys to post 22 00:01:01,760 --> 00:01:03,900 some idea for your final project on Piazza 23 00:01:03,900 --> 00:01:07,800 by tomorrow just so that your classmates can 24 00:01:07,800 --> 00:01:12,435 know what you're thinking and help you form groups. 25 00:01:12,435 --> 00:01:14,560 All right, so let's talk about Kerberos, all right? 26 00:01:14,560 --> 00:01:16,580 So what is the setting that Kerberos 27 00:01:16,580 --> 00:01:19,360 is trying to support, here? 28 00:01:19,360 --> 00:01:21,900 So the model for Kerberos, what these guys 29 00:01:21,900 --> 00:01:23,680 had in mind when they were designing 30 00:01:23,680 --> 00:01:26,600 Athena guess 25 or 30 years ago now, 31 00:01:26,600 --> 00:01:28,360 is that they were imagining they were 32 00:01:28,360 --> 00:01:30,680 going to have a network with many server machines 33 00:01:30,680 --> 00:01:33,790 and many client machines interacting with one another. 34 00:01:33,790 --> 00:01:36,290 So you could imagine, well, you have a file server somewhere 35 00:01:36,290 --> 00:01:37,150 out there. 36 00:01:37,150 --> 00:01:41,140 You probably have a mail server connected to the network, maybe 37 00:01:41,140 --> 00:01:45,130 other services-- printer. 38 00:01:45,130 --> 00:01:50,510 And all these are just connected to some sort of a network 39 00:01:50,510 --> 00:01:54,500 rather than being processes on a single machine. 40 00:01:54,500 --> 00:01:57,497 So the prelude to Athena and Kerberos 41 00:01:57,497 --> 00:01:59,580 is that you just have a time sharing machine where 42 00:01:59,580 --> 00:02:02,050 everything was a single process and everyone would just 43 00:02:02,050 --> 00:02:05,760 log into the same system and store their files there. 44 00:02:05,760 --> 00:02:08,830 So these guys wanted a more distributed system. 45 00:02:08,830 --> 00:02:12,360 So this meant that you'd have these servers on one side 46 00:02:12,360 --> 00:02:14,730 and you'd also have a bunch of workstations 47 00:02:14,730 --> 00:02:18,207 that users would use themselves which 48 00:02:18,207 --> 00:02:19,790 would run applications and potentially 49 00:02:19,790 --> 00:02:22,360 connect to these servers and store the user's files, 50 00:02:22,360 --> 00:02:24,560 get their mail et cetera. 51 00:02:24,560 --> 00:02:26,800 And the problem that they wanted to solve 52 00:02:26,800 --> 00:02:28,520 was how to authenticate the users that 53 00:02:28,520 --> 00:02:31,590 are using these workstations to all these different servers 54 00:02:31,590 --> 00:02:34,270 in the back end without having to trust the network 55 00:02:34,270 --> 00:02:36,890 to be correct, which seems like a sensible design 56 00:02:36,890 --> 00:02:40,010 requirement in many ways. 57 00:02:40,010 --> 00:02:42,890 And I should mention that I guess 58 00:02:42,890 --> 00:02:44,580 the alternative to Kerberos at the time 59 00:02:44,580 --> 00:02:46,187 was these R login commands that we're 60 00:02:46,187 --> 00:02:48,520 looking at in last lecture, which seems like a bad plan. 61 00:02:48,520 --> 00:02:51,860 They just use IP addresses to authenticate the users. 62 00:02:51,860 --> 00:02:54,330 And Kerberos was reasonably successful. 63 00:02:54,330 --> 00:02:56,160 It actually still is used at MIT. 64 00:02:56,160 --> 00:02:59,280 And actually, it's the basis of Microsoft's Active Directory 65 00:02:59,280 --> 00:02:59,780 server. 66 00:02:59,780 --> 00:03:03,450 So pretty much every Microsoft based sort of Windows Server 67 00:03:03,450 --> 00:03:05,921 uses Kerberos in some form or another. 68 00:03:05,921 --> 00:03:07,420 But of course, because this protocol 69 00:03:07,420 --> 00:03:11,720 was designed 25 or 30 years ago, requirements change. 70 00:03:11,720 --> 00:03:14,352 What people assume change. 71 00:03:14,352 --> 00:03:16,310 People now understand much more about security. 72 00:03:16,310 --> 00:03:19,050 So their version of Kerberos that's in use today 73 00:03:19,050 --> 00:03:21,770 is noticeably different in many ways 74 00:03:21,770 --> 00:03:23,860 from the version in the paper. 75 00:03:23,860 --> 00:03:27,520 And we'll look at exactly what assumptions aren't good enough 76 00:03:27,520 --> 00:03:30,432 anymore today and what did they get wrong. 77 00:03:30,432 --> 00:03:32,390 It's sort of inevitable for any protocol that 78 00:03:32,390 --> 00:03:34,650 was the first protocol to really use cryptography 79 00:03:34,650 --> 00:03:37,460 to authenticate parties over the network in this sort 80 00:03:37,460 --> 00:03:40,810 of full system scale. 81 00:03:40,810 --> 00:03:43,422 Anyway, so that's the sort of setting for Kerberos. 82 00:03:43,422 --> 00:03:45,130 And it might be interesting to figure out 83 00:03:45,130 --> 00:03:46,379 what's the trust model, right? 84 00:03:46,379 --> 00:03:49,910 So Kerberos is going to introduce this extra Kerberos 85 00:03:49,910 --> 00:03:51,450 server sitting on the side. 86 00:03:55,240 --> 00:03:58,040 So our third model at some level is 87 00:03:58,040 --> 00:04:00,710 that the network is untrusted like we were 88 00:04:00,710 --> 00:04:03,420 thinking about in last lecture. 89 00:04:03,420 --> 00:04:06,745 But who do we have to trust in this Kerberos setting? 90 00:04:09,700 --> 00:04:14,650 So of course, one thing is everyone-- all parties have 91 00:04:14,650 --> 00:04:16,230 to trust the Kerberos server. 92 00:04:18,574 --> 00:04:20,199 So that's an assumption these guys were 93 00:04:20,199 --> 00:04:22,657 willing to make at the time that this Kerberos server would 94 00:04:22,657 --> 00:04:24,915 be in charge of all network authentication 95 00:04:24,915 --> 00:04:27,435 in some form or another. 96 00:04:27,435 --> 00:04:29,930 Do we have anyone else that has to trust anything 97 00:04:29,930 --> 00:04:30,670 in the setting? 98 00:04:33,210 --> 00:04:33,960 For example, yeah. 99 00:04:33,960 --> 00:04:36,304 STUDENT: Well users should trust their own machines. 100 00:04:36,304 --> 00:04:38,220 PROFESSOR: Yes, so that's a good point, right? 101 00:04:38,220 --> 00:04:41,030 There's the users that I didn't draw here. 102 00:04:41,030 --> 00:04:43,780 But these guys are using some workstation. 103 00:04:43,780 --> 00:04:46,150 And it's actually pretty important in Kerberos 104 00:04:46,150 --> 00:04:50,199 that the user trusts their workstation. 105 00:04:50,199 --> 00:04:52,490 So what goes wrong if you don't trust your workstation? 106 00:04:52,490 --> 00:04:54,406 Or presumably, it can just sniff your password 107 00:04:54,406 --> 00:04:59,405 and do whatever you type-- you know, LS, it tries-- runs RMX. 108 00:04:59,405 --> 00:05:01,950 That seems kind of unfortunate. 109 00:05:01,950 --> 00:05:02,664 Yeah. 110 00:05:02,664 --> 00:05:04,330 STUDENT: But it's more than that though, 111 00:05:04,330 --> 00:05:07,020 because they could even, like, sniff your Kerberos ticket. 112 00:05:07,020 --> 00:05:07,590 PROFESSOR: Yeah, exactly. 113 00:05:07,590 --> 00:05:09,710 Or when you log in, you type in your password, which 114 00:05:09,710 --> 00:05:10,960 is even worse than the ticket. 115 00:05:10,960 --> 00:05:12,240 Yeah, absolutely, yeah. 116 00:05:12,240 --> 00:05:15,490 So this is actually a bit of a problem with Kerberos 117 00:05:15,490 --> 00:05:19,050 in the sense that if you don't trust the workstation, then 118 00:05:19,050 --> 00:05:21,050 you're in a bit of trouble. 119 00:05:21,050 --> 00:05:23,200 So if you have your own laptop, this 120 00:05:23,200 --> 00:05:25,030 seems like a sensible assumption to make. 121 00:05:25,030 --> 00:05:27,140 If you're using a public computer, 122 00:05:27,140 --> 00:05:28,485 this is a bit more questionable. 123 00:05:28,485 --> 00:05:30,860 And we'll see exactly what could go wrong. 124 00:05:30,860 --> 00:05:31,683 Yeah. 125 00:05:31,683 --> 00:05:34,641 STUDENT: You have to trust the people administrating aren't 126 00:05:34,641 --> 00:05:37,106 doing anything bad with [INAUDIBLE] servers 127 00:05:37,106 --> 00:05:39,972 and giving them privilege access to one another. 128 00:05:39,972 --> 00:05:41,180 STUDENT: So what do you mean? 129 00:05:41,180 --> 00:05:43,220 So of course, like, ISNT is going 130 00:05:43,220 --> 00:05:46,010 to run these machines down here. 131 00:05:46,010 --> 00:05:48,300 But I think the machines themselves don't necessarily 132 00:05:48,300 --> 00:05:49,850 have to trust one another. 133 00:05:49,850 --> 00:05:53,010 So the mail server doesn't trust the print server or the file 134 00:05:53,010 --> 00:05:54,908 server necessarily. 135 00:05:54,908 --> 00:05:56,366 STUDENT: Not to trust, but he might 136 00:05:56,366 --> 00:05:58,294 be able to access a server you're not 137 00:05:58,294 --> 00:06:01,497 supposed to have access to by going through another server. 138 00:06:01,497 --> 00:06:03,080 PROFESSOR: Yeah, that's true, I guess. 139 00:06:03,080 --> 00:06:05,040 Yeah, so if you set up any trust relationship 140 00:06:05,040 --> 00:06:07,360 between these guys-- like, if you give the mail server 141 00:06:07,360 --> 00:06:11,530 some back end to go access your files just for convenience, 142 00:06:11,530 --> 00:06:13,140 then this could be abused, yeah. 143 00:06:13,140 --> 00:06:16,400 So you have to be careful about not introducing 144 00:06:16,400 --> 00:06:20,990 additional sort of levels of trust or trust relations here. 145 00:06:20,990 --> 00:06:25,100 All right, anything else that matters here? 146 00:06:25,100 --> 00:06:27,090 Do the servers have to trust the users 147 00:06:27,090 --> 00:06:29,210 in any way or the workstations? 148 00:06:31,776 --> 00:06:32,900 No, I guess presumably not. 149 00:06:32,900 --> 00:06:35,920 So this was the whole goal that the server 150 00:06:35,920 --> 00:06:38,160 doesn't have to a priori even know necessarily 151 00:06:38,160 --> 00:06:40,320 what all these users or how to authenticate them 152 00:06:40,320 --> 00:06:43,220 or what this workstation is doing until it can 153 00:06:43,220 --> 00:06:47,100 cryptographically prove that this is a legitimate user 154 00:06:47,100 --> 00:06:51,460 and they should have access to their data or whatnot. 155 00:06:51,460 --> 00:06:53,600 All right, so let's look at how does Kerberos work 156 00:06:53,600 --> 00:06:57,340 or what's the overall architecture, at least. 157 00:06:57,340 --> 00:07:01,200 So the plan that these guys had in mind 158 00:07:01,200 --> 00:07:03,500 is that there would be this Kerberos server. 159 00:07:03,500 --> 00:07:05,470 We have drawn it up there but let's draw it 160 00:07:05,470 --> 00:07:07,300 in a slightly bigger scale. 161 00:07:07,300 --> 00:07:10,540 So this is the Kerberos server. 162 00:07:10,540 --> 00:07:16,650 And today, it's typically called KDC-- Key Distribution Center. 163 00:07:16,650 --> 00:07:22,430 And there's all these users out here somewhere and also 164 00:07:22,430 --> 00:07:26,840 services that you might want to connect to. 165 00:07:26,840 --> 00:07:30,860 And the plan is that the Kerberos server 166 00:07:30,860 --> 00:07:34,650 is going to be responsible for storing a shared 167 00:07:34,650 --> 00:07:39,070 key between the Kerberos server and every entity in the world, 168 00:07:39,070 --> 00:07:41,080 or in this realm at least. 169 00:07:41,080 --> 00:07:45,885 So if the user has some sort of a key KC for client, 170 00:07:45,885 --> 00:07:47,260 than the Kerberos server is going 171 00:07:47,260 --> 00:07:49,720 to remember this key somewhere here. 172 00:07:49,720 --> 00:07:53,680 And similarly for the server, the key KS 173 00:07:53,680 --> 00:07:56,080 is going to be known to the service itself 174 00:07:56,080 --> 00:07:59,300 and to the Kerberos server but hopefully no one else. 175 00:07:59,300 --> 00:08:02,020 So you can think of it as like a generalization of passwords, 176 00:08:02,020 --> 00:08:02,520 right? 177 00:08:02,520 --> 00:08:04,440 So you know a password and the Kerberos server 178 00:08:04,440 --> 00:08:05,940 knows your password but no one else. 179 00:08:05,940 --> 00:08:08,790 And this is how you guys are going to prove to each other, 180 00:08:08,790 --> 00:08:10,130 yeah, I'm the right guy. 181 00:08:10,130 --> 00:08:13,000 I know this password and no one else does. 182 00:08:13,000 --> 00:08:14,150 Makes sense? 183 00:08:14,150 --> 00:08:17,982 And the other thing the Kerberos server is going to have to do 184 00:08:17,982 --> 00:08:20,070 is, of course, keep track of who is 185 00:08:20,070 --> 00:08:22,370 it that owns this key, right? 186 00:08:22,370 --> 00:08:27,080 So it's going to have this table mapping some sort of a name. 187 00:08:27,080 --> 00:08:29,080 So this is some sort of a user. 188 00:08:29,080 --> 00:08:35,630 This is maybe service maybe AFS or something like this. 189 00:08:35,630 --> 00:08:38,530 And the KDC is responsible for storing the gigantic table-- 190 00:08:38,530 --> 00:08:41,659 well, not very large in terms of the number of bytes, 191 00:08:41,659 --> 00:08:45,640 necessarily, but one entry per entity 192 00:08:45,640 --> 00:08:50,310 at MIT that the Kerberos server knows about. 193 00:08:50,310 --> 00:08:52,510 Makes sense? 194 00:08:52,510 --> 00:08:56,634 All right, and then we're going to have sort of provide 195 00:08:56,634 --> 00:08:57,550 two interfaces, right? 196 00:08:57,550 --> 00:09:00,200 The paper is a little fuzzy above this 197 00:09:00,200 --> 00:09:02,200 or it pretends like there's really two services. 198 00:09:02,200 --> 00:09:05,260 But really, what's going on is that there's two interfaces 199 00:09:05,260 --> 00:09:06,660 to the same machine. 200 00:09:06,660 --> 00:09:11,560 One of them is called Kerberos in the paper and one of them 201 00:09:11,560 --> 00:09:15,460 is called TGS for Ticket Granting Service. 202 00:09:15,460 --> 00:09:16,980 And really, these are just two ways 203 00:09:16,980 --> 00:09:20,130 of talking to the same thing in the back end. 204 00:09:20,130 --> 00:09:24,340 And the protocol is a little different for these things. 205 00:09:24,340 --> 00:09:26,570 So initially, when the user logs in, 206 00:09:26,570 --> 00:09:28,680 they're going to talk to this guy over here. 207 00:09:28,680 --> 00:09:32,110 And they're going to send their client name, 208 00:09:32,110 --> 00:09:35,160 C. So this might be your Athena username. 209 00:09:35,160 --> 00:09:36,810 And the server is going to respond 210 00:09:36,810 --> 00:09:43,804 to back with a ticket, a TGS or-- well, 211 00:09:43,804 --> 00:09:44,720 some sort of a ticket. 212 00:09:44,720 --> 00:09:46,540 We'll look at the details in a bit. 213 00:09:46,540 --> 00:09:51,130 And then when you want to talk to some server down here, 214 00:09:51,130 --> 00:09:54,040 KS, then you're going to talk to this TGS first 215 00:09:54,040 --> 00:09:56,530 and say, oh, hey, I already logged in 216 00:09:56,530 --> 00:09:58,560 through the Kerberos interface. 217 00:09:58,560 --> 00:10:00,770 Now, I want to talk to the server S. 218 00:10:00,770 --> 00:10:03,560 So you'd tell the TGS about the server you want to talk to. 219 00:10:03,560 --> 00:10:08,330 And then it returns you back some sort of a ticket 220 00:10:08,330 --> 00:10:12,780 for talking to the server S. And then you can finally 221 00:10:12,780 --> 00:10:15,600 start talking to the server over here 222 00:10:15,600 --> 00:10:22,230 by initially passing it this ticket for S. 223 00:10:22,230 --> 00:10:23,902 Does this all make sense? 224 00:10:23,902 --> 00:10:27,270 This is the sort of high level plan. 225 00:10:27,270 --> 00:10:30,335 So why do these guys have two interfaces? 226 00:10:32,967 --> 00:10:34,550 Well, I guess I wanted to actually ask 227 00:10:34,550 --> 00:10:35,425 a bunch of questions. 228 00:10:35,425 --> 00:10:38,080 Like, in the case of a service, this service 229 00:10:38,080 --> 00:10:39,770 is probably going to be stored on disk. 230 00:10:39,770 --> 00:10:42,330 What's going on with this KC on the user side? 231 00:10:42,330 --> 00:10:46,240 Where does KC come from in Kerberos? 232 00:10:46,240 --> 00:10:47,574 Yeah. 233 00:10:47,574 --> 00:10:50,740 STUDENT: KDMS [INAUDIBLE] the database. 234 00:10:50,740 --> 00:10:52,736 PROFESSOR: Yeah, well, the key C sits here. 235 00:10:52,736 --> 00:10:53,860 And that's absolutely true. 236 00:10:53,860 --> 00:10:55,420 It's sits on this giant database. 237 00:10:55,420 --> 00:10:57,280 But it also has to be known to the user 238 00:10:57,280 --> 00:10:59,610 because the user has to prove that they are the user. 239 00:10:59,610 --> 00:11:00,326 Yeah. 240 00:11:00,326 --> 00:11:02,030 STUDENT: Is that a one way function and then the password? 241 00:11:02,030 --> 00:11:03,405 PROFESSOR: Yeah, so they actually 242 00:11:03,405 --> 00:11:05,930 have this sort of cute plan where the KC is actually 243 00:11:05,930 --> 00:11:09,100 going to be derived by hashing the user's password 244 00:11:09,100 --> 00:11:11,320 or really some sort of key duration function. 245 00:11:11,320 --> 00:11:14,444 And there's several different ones of perverse uses. 246 00:11:14,444 --> 00:11:16,360 But you're basically going to take a password, 247 00:11:16,360 --> 00:11:20,676 transform it in some way, and get this key KC. 248 00:11:20,676 --> 00:11:25,180 All right, so that seems good. 249 00:11:25,180 --> 00:11:27,010 Why do we need two protocols, right? 250 00:11:27,010 --> 00:11:32,020 You could imagine that you just always ask the Kerberos server 251 00:11:32,020 --> 00:11:33,292 for tickets directly this way. 252 00:11:33,292 --> 00:11:34,750 You say, well, hey, I want a ticket 253 00:11:34,750 --> 00:11:36,730 for this particular principle name. 254 00:11:36,730 --> 00:11:39,070 And it'll send you back a ticket and you can decrypt it 255 00:11:39,070 --> 00:11:41,440 with your KC afterwards. 256 00:11:41,440 --> 00:11:41,940 Yeah. 257 00:11:41,940 --> 00:11:44,861 STUDENT: Can you [INAUDIBLE] or ask the user 258 00:11:44,861 --> 00:11:46,527 to reenter their password each time they 259 00:11:46,527 --> 00:11:47,740 want to [INAUDIBLE] service? 260 00:11:47,740 --> 00:11:49,823 PROFESSOR: Right, so the reason for the difference 261 00:11:49,823 --> 00:11:52,440 between these two interfaces is that on this interface, 262 00:11:52,440 --> 00:11:56,170 all the responses come back encrypted with your key KC. 263 00:11:56,170 --> 00:11:59,500 And the Kerberos designers are a little worried 264 00:11:59,500 --> 00:12:03,070 about keeping this KC around for a long time. 265 00:12:03,070 --> 00:12:05,260 Because either you have to ask the user to enter it, 266 00:12:05,260 --> 00:12:07,730 which is just annoying for the user, 267 00:12:07,730 --> 00:12:09,330 or it sits around in memory. 268 00:12:09,330 --> 00:12:12,400 And this is basically as good as the user's password. 269 00:12:12,400 --> 00:12:17,730 So if this gets disclosed, then someone with access to KC 270 00:12:17,730 --> 00:12:20,675 can keep accessing the user's files until the user maybe 271 00:12:20,675 --> 00:12:22,800 changes their password and potentially even longer. 272 00:12:22,800 --> 00:12:25,300 We'll see about that. 273 00:12:25,300 --> 00:12:28,570 So this KC is a really dangerous thing to leak. 274 00:12:28,570 --> 00:12:31,580 So the whole point of using this interface first and using 275 00:12:31,580 --> 00:12:34,270 this interface later for all subsequent requests 276 00:12:34,270 --> 00:12:36,790 is that you can actually forget KC 277 00:12:36,790 --> 00:12:40,430 as soon as you decrypt this TGS response from the Kerberos 278 00:12:40,430 --> 00:12:41,980 interface. 279 00:12:41,980 --> 00:12:44,600 And from that point on, even if you leak it, 280 00:12:44,600 --> 00:12:46,994 there is a lifetime associated with this ticket. 281 00:12:46,994 --> 00:12:48,410 So worst case, someone gets access 282 00:12:48,410 --> 00:12:50,160 to your account for a couple of hours, 283 00:12:50,160 --> 00:12:53,359 not for an unbounded amount of time. 284 00:12:53,359 --> 00:12:54,900 So that's the sort of main difference 285 00:12:54,900 --> 00:12:59,020 why you guys have this slightly more complicated picture 286 00:12:59,020 --> 00:13:03,190 with two ways of accessing the same thing. 287 00:13:03,190 --> 00:13:06,360 All right, so before we dive into the mechanics of how 288 00:13:06,360 --> 00:13:08,900 these protocols actually look like on the wire, 289 00:13:08,900 --> 00:13:13,060 let's talk a little bit about this naming aspect in Kerberos, 290 00:13:13,060 --> 00:13:13,560 right? 291 00:13:13,560 --> 00:13:16,100 So at some level, you could think of Kerberos 292 00:13:16,100 --> 00:13:18,530 as being a name registry, right? 293 00:13:18,530 --> 00:13:20,680 So it's really responsible for mapping 294 00:13:20,680 --> 00:13:24,090 these cryptographic keys onto string names. 295 00:13:24,090 --> 00:13:27,459 And this is the fundamental sort of operation 296 00:13:27,459 --> 00:13:28,750 that Kerberos needs to provide. 297 00:13:28,750 --> 00:13:31,467 In fact, you'll see in the next lecture even on the web, 298 00:13:31,467 --> 00:13:32,800 we need some function like this. 299 00:13:32,800 --> 00:13:34,550 It's implemented differently from Kerberos 300 00:13:34,550 --> 00:13:36,570 but this is a fundamentally very important thing 301 00:13:36,570 --> 00:13:39,060 to have in almost any distributed system 302 00:13:39,060 --> 00:13:40,510 for security. 303 00:13:40,510 --> 00:13:45,080 So let's look at how Kerberos actually deals with names. 304 00:13:45,080 --> 00:13:49,440 So in Kerberos, the sort of system 305 00:13:49,440 --> 00:13:53,560 calls every entity in this database a principal 306 00:13:53,560 --> 00:13:56,920 And a principal in Kerberos is actually just a string, right? 307 00:13:56,920 --> 00:13:59,780 So you can actually have some principal like, I don't know, 308 00:13:59,780 --> 00:14:00,885 nickolei. 309 00:14:00,885 --> 00:14:01,720 So that's a string. 310 00:14:01,720 --> 00:14:05,170 And that could be a principal in some Kerberos realm. 311 00:14:05,170 --> 00:14:06,850 So it would literally be the thing 312 00:14:06,850 --> 00:14:12,000 that sits in this left column of the KDC's table. 313 00:14:12,000 --> 00:14:16,007 And there's also some extra instances 314 00:14:16,007 --> 00:14:17,090 that the protocl supports. 315 00:14:17,090 --> 00:14:20,200 I could say, you know, nikolai.extra secure 316 00:14:20,200 --> 00:14:22,740 or something. 317 00:14:22,740 --> 00:14:25,930 And I might use this as a different entity 318 00:14:25,930 --> 00:14:27,960 for machines I really care about. 319 00:14:27,960 --> 00:14:29,810 So maybe I will have a different password 320 00:14:29,810 --> 00:14:31,940 for really secure things and a different password 321 00:14:31,940 --> 00:14:34,120 for my regular account. 322 00:14:34,120 --> 00:14:37,110 So this is just sort of how Kerberos-- 323 00:14:37,110 --> 00:14:40,690 this is what the paper talks about with instances. 324 00:14:40,690 --> 00:14:42,190 So one might actually wonder-- where 325 00:14:42,190 --> 00:14:43,440 do you actually see instances? 326 00:14:43,440 --> 00:14:45,440 Where do influences come from? 327 00:14:45,440 --> 00:14:49,930 So the Kerberos service maps names to keys for you, 328 00:14:49,930 --> 00:14:51,940 but how do you know which name to ask for 329 00:14:51,940 --> 00:14:56,600 or which name to expect when you are talking to some machine? 330 00:14:56,600 --> 00:15:00,720 So I guess what I'm asking is, what are names appear outside 331 00:15:00,720 --> 00:15:03,050 of the Kerberos machine. 332 00:15:03,050 --> 00:15:06,256 So I guess we could ask, OK, where do user names appear? 333 00:15:06,256 --> 00:15:07,701 Any ideas? 334 00:15:07,701 --> 00:15:08,200 Yeah. 335 00:15:08,200 --> 00:15:10,525 STUDENT: You can ask the MIT server for usernames 336 00:15:10,525 --> 00:15:11,812 presumably. 337 00:15:11,812 --> 00:15:12,770 PROFESSOR: Right, yeah. 338 00:15:12,770 --> 00:15:13,900 So you could enumerate these things. 339 00:15:13,900 --> 00:15:15,350 Also, the users just type them in when 340 00:15:15,350 --> 00:15:16,349 they log into a machine. 341 00:15:16,349 --> 00:15:18,480 So that's where it initially comes from. 342 00:15:18,480 --> 00:15:21,020 Do usernames appear anywhere else? 343 00:15:21,020 --> 00:15:23,652 Should they appear anywhere else? 344 00:15:23,652 --> 00:15:24,152 Yeah. 345 00:15:24,152 --> 00:15:26,084 STUDENT: Possibly access the [INAUDIBLE] 346 00:15:26,084 --> 00:15:27,494 lists on the various services. 347 00:15:27,494 --> 00:15:29,910 PROFESSOR: Yes, that's actually an important point, right? 348 00:15:29,910 --> 00:15:33,850 The goal of Kerberos is just to map keys to names. 349 00:15:33,850 --> 00:15:36,440 But it doesn't tell you what that name should have access 350 00:15:36,440 --> 00:15:37,020 to. 351 00:15:37,020 --> 00:15:38,950 In fact, the way the applications typically 352 00:15:38,950 --> 00:15:42,900 use Kerberos is that one of these servers 353 00:15:42,900 --> 00:15:45,730 uses Kerberos to figure out, OK, what string name am I 354 00:15:45,730 --> 00:15:46,290 talking to? 355 00:15:46,290 --> 00:15:48,290 So when the mail server gets a connection 356 00:15:48,290 --> 00:15:50,920 from some workstation and it get the Kerberos ticket that 357 00:15:50,920 --> 00:15:54,220 prove that maybe this user is called Nikolai, 358 00:15:54,220 --> 00:15:56,110 then the mail server internally now 359 00:15:56,110 --> 00:15:57,630 has to figure out, OK, well, what 360 00:15:57,630 --> 00:15:59,280 should that guy have access to? 361 00:15:59,280 --> 00:16:00,960 And same for a file server. 362 00:16:00,960 --> 00:16:03,150 So inside of all these servers, there's 363 00:16:03,150 --> 00:16:07,900 probably things like access control lists, maybe groups, 364 00:16:07,900 --> 00:16:11,770 maybe other things that actually do the authorization step. 365 00:16:11,770 --> 00:16:14,770 So Kerberos provides authentication 366 00:16:14,770 --> 00:16:17,690 which tells you who is this person I'm talking to. 367 00:16:17,690 --> 00:16:20,580 And the service itself is responsible for implementing 368 00:16:20,580 --> 00:16:23,870 the authorization part where they decide what access 369 00:16:23,870 --> 00:16:28,180 you should have based on your username here. 370 00:16:28,180 --> 00:16:30,440 Makes sense? 371 00:16:30,440 --> 00:16:33,500 All right, so that's where the user names appear. 372 00:16:33,500 --> 00:16:35,100 There's also other principal names 373 00:16:35,100 --> 00:16:37,400 the Kerberos supports for services, right? 374 00:16:37,400 --> 00:16:39,890 So services, I guess the paper suggests, 375 00:16:39,890 --> 00:16:41,380 look something like this. 376 00:16:41,380 --> 00:16:42,270 That's rcmd.hostname. 377 00:16:47,910 --> 00:16:53,589 And the reason that you need a name for one of these services 378 00:16:53,589 --> 00:16:55,380 is that you want to know, for example, when 379 00:16:55,380 --> 00:16:58,980 I connect to a file server, I actually 380 00:16:58,980 --> 00:17:01,500 want mutual authentication. 381 00:17:01,500 --> 00:17:04,160 It's not just the final server learns who I am, 382 00:17:04,160 --> 00:17:06,288 but I, the user or the workstation, 383 00:17:06,288 --> 00:17:08,579 want to be convinced that I'm talking to the right file 384 00:17:08,579 --> 00:17:10,599 server and not some fake file server that's 385 00:17:10,599 --> 00:17:11,880 impersonating my files. 386 00:17:11,880 --> 00:17:14,109 Because maybe I'll look at the grades 387 00:17:14,109 --> 00:17:15,690 file and submit it to the registrar. 388 00:17:15,690 --> 00:17:17,964 It would be too bad if some file server 389 00:17:17,964 --> 00:17:21,319 can impersonate the response and give me the wrong grades file 390 00:17:21,319 --> 00:17:23,020 all of a sudden. 391 00:17:23,020 --> 00:17:25,500 So this is why the service principles also 392 00:17:25,500 --> 00:17:29,770 need their own name and the workstations need to figure out 393 00:17:29,770 --> 00:17:34,120 what name should I expect to see when I connect to the service. 394 00:17:34,120 --> 00:17:36,500 And typically, this comes from the user at some level. 395 00:17:36,500 --> 00:17:41,010 So for example, if I type SSH some machine foo, 396 00:17:41,010 --> 00:17:44,150 then this means that I should be expecting 397 00:17:44,150 --> 00:17:47,100 a Kerberos principal called rcmd.foo 398 00:17:47,100 --> 00:17:49,000 on the other end of this connection. 399 00:17:49,000 --> 00:17:51,210 And if it turns out to be someone else, 400 00:17:51,210 --> 00:17:53,240 this SSH client should abort and not 401 00:17:53,240 --> 00:17:56,040 let me connect because then I will be misled into talking 402 00:17:56,040 --> 00:17:57,936 to some other machine. 403 00:17:57,936 --> 00:18:00,392 That make sense? 404 00:18:00,392 --> 00:18:01,850 So here's one interesting question. 405 00:18:01,850 --> 00:18:04,365 When can we reuse names in Kerberos? 406 00:18:04,365 --> 00:18:06,940 It's like, all of you guys have Athena accounts. 407 00:18:06,940 --> 00:18:08,960 And when you graduate, could MIT, 408 00:18:08,960 --> 00:18:11,480 like, wipe out your database entry 409 00:18:11,480 --> 00:18:14,130 and allow someone else to register that same username? 410 00:18:14,130 --> 00:18:16,600 Would that be a good idea? 411 00:18:16,600 --> 00:18:19,290 Well, aside from the fact that you guys want accounts. 412 00:18:19,290 --> 00:18:19,790 Yeah. 413 00:18:19,790 --> 00:18:23,205 STUDENT: Updated services as well so that they would, 414 00:18:23,205 --> 00:18:25,593 like map that username to [INAUDIBLE] permission 415 00:18:25,593 --> 00:18:26,176 theoretically? 416 00:18:26,176 --> 00:18:28,470 PROFESSOR: Yeah, because these guys are actually 417 00:18:28,470 --> 00:18:32,580 just string entries somewhere in some ACL on a file 418 00:18:32,580 --> 00:18:33,950 server on a mail server. 419 00:18:33,950 --> 00:18:37,340 And just because you wipe out this entry in the Kerberos 420 00:18:37,340 --> 00:18:40,075 database doesn't mean that this entry is gone. 421 00:18:40,075 --> 00:18:41,950 And they're not versioning in any way, right? 422 00:18:41,950 --> 00:18:43,658 This entry could literally say, you know, 423 00:18:43,658 --> 00:18:47,270 Alice has access to some Athena locker. 424 00:18:47,270 --> 00:18:50,999 And if this Alice graduates and her entry gets removed, 425 00:18:50,999 --> 00:18:52,790 then some new Alice comes along, registers, 426 00:18:52,790 --> 00:18:54,770 in the Kerberos database. 427 00:18:54,770 --> 00:18:56,570 But she gets a principal that looks 428 00:18:56,570 --> 00:18:57,895 identical to the old Alice. 429 00:18:57,895 --> 00:18:58,770 It's the same string. 430 00:18:58,770 --> 00:19:00,370 So all of a sudden, the file server 431 00:19:00,370 --> 00:19:04,740 will give access to the new Alice to old Alice's data. 432 00:19:04,740 --> 00:19:06,620 So there's a bit of a complicated process 433 00:19:06,620 --> 00:19:09,650 for reclaiming principal names in Kerberos 434 00:19:09,650 --> 00:19:11,160 because there's no real connection 435 00:19:11,160 --> 00:19:12,869 or versioning between these guys. 436 00:19:12,869 --> 00:19:14,410 So as a result, it's actually kind of 437 00:19:14,410 --> 00:19:16,749 hard to reuse principal names. 438 00:19:16,749 --> 00:19:18,540 Once you register a principal, you probably 439 00:19:18,540 --> 00:19:22,160 don't want to reuse it very often. 440 00:19:22,160 --> 00:19:25,930 And same for, in some sense, these principal names 441 00:19:25,930 --> 00:19:27,020 for service as well. 442 00:19:27,020 --> 00:19:30,910 As long as this hostname remain some well-known service 443 00:19:30,910 --> 00:19:33,040 that people expect to function in a certain way, 444 00:19:33,040 --> 00:19:34,920 you probably don't want to get rid of its key 445 00:19:34,920 --> 00:19:35,940 even if the service goes on. 446 00:19:35,940 --> 00:19:38,398 Because maybe a year later, some guy tries to connect to it 447 00:19:38,398 --> 00:19:39,581 and expects certain things. 448 00:19:39,581 --> 00:19:41,580 And if it's been reused for a different service, 449 00:19:41,580 --> 00:19:44,130 that guy can impersonate things. 450 00:19:44,130 --> 00:19:47,620 Probably not as dramatic or as bad, but still, 451 00:19:47,620 --> 00:19:50,420 you have to be careful with reusing principal names 452 00:19:50,420 --> 00:19:52,910 in this kind of protocol. 453 00:19:52,910 --> 00:19:53,940 Makes sense? 454 00:19:53,940 --> 00:19:56,140 Any questions? 455 00:19:56,140 --> 00:19:59,590 All right, so let's look at how the protocol itself now works. 456 00:19:59,590 --> 00:20:02,780 So we'll look first and this step of the protocol 457 00:20:02,780 --> 00:20:06,160 where you initially get your ticket with your password. 458 00:20:06,160 --> 00:20:09,170 And then we'll look at how this TGS interface works 459 00:20:09,170 --> 00:20:12,660 and how it differs then a little bit. 460 00:20:12,660 --> 00:20:15,280 All right, so I guess there's this main data 461 00:20:15,280 --> 00:20:17,790 structure that Kerberos uses called a ticket. 462 00:20:17,790 --> 00:20:21,660 And this ticket looks like this. 463 00:20:21,660 --> 00:20:25,270 So there's a ticket to between a client and a server. 464 00:20:25,270 --> 00:20:28,510 And this guy is basically the names 465 00:20:28,510 --> 00:20:30,550 of the server and the client that we're 466 00:20:30,550 --> 00:20:36,190 talking about-- the IP address of the client, 467 00:20:36,190 --> 00:20:43,050 some kind of timestamp, and an expiration time for how long 468 00:20:43,050 --> 00:20:44,260 the stick is valid. 469 00:20:44,260 --> 00:20:48,400 And there's also a key, KCS, that's 470 00:20:48,400 --> 00:20:51,860 going to be shared between the client and the server. 471 00:20:51,860 --> 00:20:53,790 So that's what's in a ticket. 472 00:20:53,790 --> 00:20:56,610 And there's also this other weird data structure 473 00:20:56,610 --> 00:20:59,380 that Kerberos introduces called an authenticator. 474 00:20:59,380 --> 00:21:03,590 And an authenticator goes with a particular client C. 475 00:21:03,590 --> 00:21:06,530 And this thing is just the client's name, 476 00:21:06,530 --> 00:21:11,640 the IP address of the client, and the time stamp 477 00:21:11,640 --> 00:21:15,210 when the client generated this authenticator. 478 00:21:15,210 --> 00:21:18,270 And typically, both of these things are encrypted. 479 00:21:18,270 --> 00:21:20,520 And authenticator is typically scripted 480 00:21:20,520 --> 00:21:23,760 with the key between the client on the server. 481 00:21:23,760 --> 00:21:25,670 So the authenticator sort of has to do 482 00:21:25,670 --> 00:21:29,110 with a particular connection between a client and a server. 483 00:21:29,110 --> 00:21:31,550 And the Kerberos ticket itself here 484 00:21:31,550 --> 00:21:38,140 is typically encrypted with the key for the service KS. 485 00:21:38,140 --> 00:21:41,010 So the subscript notation denotes here 486 00:21:41,010 --> 00:21:45,050 encryption with a particular key. 487 00:21:45,050 --> 00:21:48,470 All right, so what does this-- so using this sort of notation 488 00:21:48,470 --> 00:21:50,670 here, let's try to figure out what is the protocol. 489 00:21:50,670 --> 00:21:53,650 By which the user initially logs into this Kerberos 490 00:21:53,650 --> 00:21:56,010 and gets their TGS ticket. 491 00:21:56,010 --> 00:21:59,240 So as we saw here before, right, the plan 492 00:21:59,240 --> 00:22:06,030 is the client is going to send their username over 493 00:22:06,030 --> 00:22:10,130 to the Kerberos server or that interface. 494 00:22:10,130 --> 00:22:12,140 And the response is going to be a ticket. 495 00:22:12,140 --> 00:22:13,760 And what precisely the client actually 496 00:22:13,760 --> 00:22:17,710 sends over-- both the username C of the client that's 497 00:22:17,710 --> 00:22:22,150 issuing the request as well as the principal name-- well, 498 00:22:22,150 --> 00:22:23,760 the client is also a principal name. 499 00:22:23,760 --> 00:22:25,840 But the client also sends the principal name 500 00:22:25,840 --> 00:22:29,720 of the service for which it would like to get a ticket. 501 00:22:29,720 --> 00:22:32,880 And typically, the service name is actually the service name 502 00:22:32,880 --> 00:22:34,700 of this TGS guy over here. 503 00:22:34,700 --> 00:22:36,150 So you get a ticket for them. 504 00:22:36,150 --> 00:22:38,191 But you could get a ticket for almost any service 505 00:22:38,191 --> 00:22:39,700 you want in this way. 506 00:22:39,700 --> 00:22:42,430 And their response is going to be 507 00:22:42,430 --> 00:22:44,380 this sort of interesting tuple. 508 00:22:44,380 --> 00:22:47,030 It's going to be your ticket between the client 509 00:22:47,030 --> 00:22:50,930 and the server encrypted just with that key KS 510 00:22:50,930 --> 00:22:53,560 as shown above. 511 00:22:53,560 --> 00:22:56,170 I guess we should write that down with KS 512 00:22:56,170 --> 00:23:01,140 And also, you get to this shared key-- key CS. 513 00:23:01,140 --> 00:23:06,180 And this whole thing is encrypted with KC. 514 00:23:06,180 --> 00:23:08,690 So that's the wire protocol. 515 00:23:08,690 --> 00:23:11,190 So I guess let's try to figure out a couple things. 516 00:23:11,190 --> 00:23:17,770 So first of all, how does the Kerberos server 517 00:23:17,770 --> 00:23:19,020 authenticate the client here? 518 00:23:19,020 --> 00:23:20,910 How does it know that this is the right user making 519 00:23:20,910 --> 00:23:21,451 this request? 520 00:23:24,395 --> 00:23:24,895 Yeah. 521 00:23:24,895 --> 00:23:27,128 STUDENT: It can make sure that the ticket 522 00:23:27,128 --> 00:23:29,100 that it sent because it has KC. 523 00:23:29,100 --> 00:23:31,020 PROFESSOR: Yes, I think that's what's going on 524 00:23:31,020 --> 00:23:32,960 is that the Kerberos server again on some level actually 525 00:23:32,960 --> 00:23:35,540 doesn't know whether this is the right client or not. 526 00:23:35,540 --> 00:23:37,500 But it thinks oh, well, sure, it doesn't matter 527 00:23:37,500 --> 00:23:38,930 who is making this request. 528 00:23:38,930 --> 00:23:41,780 I'll just send this blob out and the only person 529 00:23:41,780 --> 00:23:44,010 who should be able to make any use of this blob 530 00:23:44,010 --> 00:23:48,170 is the person that knows this key KC over here. 531 00:23:48,170 --> 00:23:50,432 So that's actually kind of cool because the client 532 00:23:50,432 --> 00:23:51,890 doesn't have to send their password 533 00:23:51,890 --> 00:23:53,790 over the network at all. 534 00:23:53,790 --> 00:23:56,650 So in some ways, this is actually better than the client 535 00:23:56,650 --> 00:23:58,800 sending a password to the Kerberos server 536 00:23:58,800 --> 00:24:01,710 because even if the Kerberos server here 537 00:24:01,710 --> 00:24:03,960 was listening for these passwords 538 00:24:03,960 --> 00:24:06,710 and trying to record them, it would never get your password. 539 00:24:06,710 --> 00:24:08,900 Or maybe if someone was impersonating the Kerberos 540 00:24:08,900 --> 00:24:13,000 server, they wouldn't get a copy of your password. 541 00:24:13,000 --> 00:24:14,090 All right, yeah. 542 00:24:14,090 --> 00:24:17,380 STUDENT: [INAUDIBLE] adversary wants to [INAUDIBLE] 543 00:24:17,380 --> 00:24:20,200 your password offline without-- 544 00:24:20,200 --> 00:24:23,020 PROFESSOR: Yeah, so this is actually not a great aspect 545 00:24:23,020 --> 00:24:24,322 of Kerberos, in fact, right? 546 00:24:24,322 --> 00:24:26,030 So does everyone see what the problem is? 547 00:24:26,030 --> 00:24:28,430 The problem is that the way the client could 548 00:24:28,430 --> 00:24:30,180 tell if they got the right password or not 549 00:24:30,180 --> 00:24:32,520 or the workstation tells if the client supplied 550 00:24:32,520 --> 00:24:35,320 the right password is they try to decrypt this ticket 551 00:24:35,320 --> 00:24:37,760 and they see if it works or not. 552 00:24:37,760 --> 00:24:41,080 And decryption is fairly cheap. 553 00:24:41,080 --> 00:24:42,700 This is symmetric encryption and you 554 00:24:42,700 --> 00:24:45,060 can do probably millions of decryptions 555 00:24:45,060 --> 00:24:49,460 a second if you try hard on modern machines. 556 00:24:49,460 --> 00:24:52,300 And this means that you can try millions 557 00:24:52,300 --> 00:24:54,020 of potential passwords per second 558 00:24:54,020 --> 00:24:56,497 to guess what the person's password is. 559 00:24:56,497 --> 00:24:58,330 And you could do this for any person at all. 560 00:24:58,330 --> 00:25:00,372 You could just send their principal 561 00:25:00,372 --> 00:25:01,330 to the Kerberos server. 562 00:25:01,330 --> 00:25:03,999 It'll very happily give you back this response encrypted 563 00:25:03,999 --> 00:25:05,040 with the user's password. 564 00:25:05,040 --> 00:25:07,590 Then you can just try different passwords and just see what 565 00:25:07,590 --> 00:25:08,740 works or what doesn't. 566 00:25:08,740 --> 00:25:09,798 Yeah. 567 00:25:09,798 --> 00:25:12,786 STUDENT: But won't the content [INAUDIBLE] 568 00:25:12,786 --> 00:25:14,778 decrypted [INAUDIBLE] advantage? 569 00:25:14,778 --> 00:25:16,752 How can we be sure that you directly-- 570 00:25:16,752 --> 00:25:19,210 PROFESSOR: Yes, this is actually another interesting aspect 571 00:25:19,210 --> 00:25:21,360 where the Kerberos 4 developers didn't quite 572 00:25:21,360 --> 00:25:24,300 realize that the time they were building this that they really 573 00:25:24,300 --> 00:25:27,270 should have been very careful about separating encryption 574 00:25:27,270 --> 00:25:29,110 from authentication. 575 00:25:29,110 --> 00:25:33,150 So in the paper, there's this implicit assumption 576 00:25:33,150 --> 00:25:37,442 that-- hopefully, that's not us. 577 00:25:37,442 --> 00:25:38,150 All right, sorry. 578 00:25:38,150 --> 00:25:40,191 So in the paper, there's this implicit assumption 579 00:25:40,191 --> 00:25:43,220 that whenever you encrypt a piece of data 580 00:25:43,220 --> 00:25:46,210 and you send it to someone else, if that person can decrypt 581 00:25:46,210 --> 00:25:48,350 the data and it sort of looks OK, 582 00:25:48,350 --> 00:25:50,210 then no, they must have gotten the right key 583 00:25:50,210 --> 00:25:52,520 and the data wasn't tampered with in flight. 584 00:25:52,520 --> 00:25:54,430 But it seems like a totally bad plan now 585 00:25:54,430 --> 00:25:56,590 that we think of it 30 years later. 586 00:25:56,590 --> 00:25:58,230 But at the time, it wasn't so clear. 587 00:25:58,230 --> 00:25:59,610 So in order to do Kerberos right, 588 00:25:59,610 --> 00:26:01,730 and in fact, what Kerberos 5 does now, 589 00:26:01,730 --> 00:26:04,277 is they both encrypt all the pieces of data 590 00:26:04,277 --> 00:26:05,860 and they also authenticate the message 591 00:26:05,860 --> 00:26:09,350 by basically computing a hash with a key. 592 00:26:09,350 --> 00:26:11,320 And then the result actually tells you 593 00:26:11,320 --> 00:26:13,960 that, oh, that piece of data just wasn't tampered with. 594 00:26:13,960 --> 00:26:16,389 It was correctly signed with this key, et cetera. 595 00:26:16,389 --> 00:26:17,930 And what actually happens in Kerberos 596 00:26:17,930 --> 00:26:20,030 version 4 is there are some extra bits 597 00:26:20,030 --> 00:26:23,110 in this thing that was encrypted that should all 598 00:26:23,110 --> 00:26:25,350 be some pattern like zeros. 599 00:26:25,350 --> 00:26:28,150 And typically, if you get the key wrong, 600 00:26:28,150 --> 00:26:31,510 that pattern will not look like all zeros just by chance. 601 00:26:31,510 --> 00:26:34,210 It's not cryptographically guaranteed to be that. 602 00:26:34,210 --> 00:26:36,690 But most times, it will not look like zeros 603 00:26:36,690 --> 00:26:40,030 and you will be able to decide whether you got the correct key 604 00:26:40,030 --> 00:26:42,490 or not. 605 00:26:42,490 --> 00:26:45,400 All right, so that's sort of the plan 606 00:26:45,400 --> 00:26:47,744 for how the clients tells, I guess, 607 00:26:47,744 --> 00:26:48,910 whether the ticket is valid. 608 00:26:48,910 --> 00:26:52,384 They just try to decrypt it and see how it works. 609 00:26:52,384 --> 00:26:53,800 So another interesting question is 610 00:26:53,800 --> 00:26:57,214 why is this key KCS included twice 611 00:26:57,214 --> 00:26:58,630 in the ticket in some form, right? 612 00:26:58,630 --> 00:27:02,520 So it's included once here and another time actually sort 613 00:27:02,520 --> 00:27:06,060 of implicitly in this ticket T. Why 614 00:27:06,060 --> 00:27:10,274 do we have two copies of the same key KCS? 615 00:27:10,274 --> 00:27:10,774 Yeah. 616 00:27:10,774 --> 00:27:12,658 STUDENT: The client can't decrypt that ticket 617 00:27:12,658 --> 00:27:14,681 because it's encrypted with a service key. 618 00:27:14,681 --> 00:27:16,930 PROFESSOR: Yeah, so it's actually kind of cute, right? 619 00:27:16,930 --> 00:27:19,067 Like, there's this key that the client can get to. 620 00:27:19,067 --> 00:27:20,900 But then there's another copy of it in here. 621 00:27:20,900 --> 00:27:23,300 It's encrypted with KS. 622 00:27:23,300 --> 00:27:27,400 And the reason for this is that the Kerberos server is actually 623 00:27:27,400 --> 00:27:29,670 trying to set up the client and this other guy 624 00:27:29,670 --> 00:27:31,350 to talk to each other securely. 625 00:27:31,350 --> 00:27:35,650 So the Kerberos generates this hopefully random key KCS 626 00:27:35,650 --> 00:27:38,180 and wants to give one copy to the client and one copy 627 00:27:38,180 --> 00:27:40,640 to the write other server that you want to talk to. 628 00:27:40,640 --> 00:27:42,840 And one thing you could imagine doing naively 629 00:27:42,840 --> 00:27:45,600 is maybe the Kerberos will just go and say, hey service, 630 00:27:45,600 --> 00:27:46,850 this guy wants to talk to you. 631 00:27:46,850 --> 00:27:47,767 Here's the key for it. 632 00:27:47,767 --> 00:27:49,349 But that would be kind of unfortunate. 633 00:27:49,349 --> 00:27:52,380 You'd have to have the Kerberos server call back to the service 634 00:27:52,380 --> 00:27:53,380 and so on. 635 00:27:53,380 --> 00:27:56,610 So instead, these guys have this nice trick where they just 636 00:27:56,610 --> 00:27:58,899 to give the client does blob that the client 637 00:27:58,899 --> 00:28:00,440 can't actually do anything with other 638 00:28:00,440 --> 00:28:02,290 than give to the right service. 639 00:28:02,290 --> 00:28:04,470 And if the service has the right key KS, 640 00:28:04,470 --> 00:28:06,260 they'll decrypt it and say, aha. 641 00:28:06,260 --> 00:28:10,420 Well, here's the key I should be using to speak to this client. 642 00:28:10,420 --> 00:28:13,970 And that's how these two guys, the client and the service, 643 00:28:13,970 --> 00:28:16,320 are going to establish a shared key for protecting 644 00:28:16,320 --> 00:28:17,200 their communication. 645 00:28:17,200 --> 00:28:17,700 Yeah. 646 00:28:17,700 --> 00:28:19,670 STUDENT: So what exactly is TGS? 647 00:28:19,670 --> 00:28:24,160 PROFESSOR: So TGS is-- OK, so there's 648 00:28:24,160 --> 00:28:25,820 sort of two sides to it. 649 00:28:25,820 --> 00:28:28,620 From the client's point of view, it's just another service 650 00:28:28,620 --> 00:28:30,290 that you can get a ticket for. 651 00:28:30,290 --> 00:28:32,540 And the kinds of operations it supports 652 00:28:32,540 --> 00:28:33,690 is getting more tickets. 653 00:28:33,690 --> 00:28:35,010 It's a Ticket Granting Service. 654 00:28:35,010 --> 00:28:37,310 STUDENT: Sorry, I meant what is the ticket called TGS. 655 00:28:37,310 --> 00:28:38,520 PROFESSOR: Oh, yeah, sorry. 656 00:28:38,520 --> 00:28:41,760 This TGS is just shorthand for this whole blob 657 00:28:41,760 --> 00:28:45,565 except where S is actually the principal name of this TGS 658 00:28:45,565 --> 00:28:46,065 service. 659 00:28:48,527 --> 00:28:50,860 So you can think of it as like, well, there's a Kerberos 660 00:28:50,860 --> 00:28:52,770 server, there's this TGS service out there, 661 00:28:52,770 --> 00:28:54,230 and then there's the real thing I want to get to. 662 00:28:54,230 --> 00:28:56,170 So you first ask this guy to give me 663 00:28:56,170 --> 00:28:57,950 a ticket for some service. 664 00:28:57,950 --> 00:29:00,530 You could ask it to give you directly a ticket for the file 665 00:29:00,530 --> 00:29:01,550 server. 666 00:29:01,550 --> 00:29:02,400 And this would work. 667 00:29:02,400 --> 00:29:04,040 But you'd need your KC to decrypt it 668 00:29:04,040 --> 00:29:06,044 and then you'd need your KC around all the time. 669 00:29:06,044 --> 00:29:07,460 So instead, what you do is you get 670 00:29:07,460 --> 00:29:10,595 a ticket for this special service over here. 671 00:29:10,595 --> 00:29:12,720 It looks just like a service except that it happens 672 00:29:12,720 --> 00:29:15,630 to be provided by the same box. 673 00:29:15,630 --> 00:29:18,310 And then this guy will happily give you more tickets 674 00:29:18,310 --> 00:29:23,210 later without having to present your initial KC again. 675 00:29:23,210 --> 00:29:24,143 Makes sense? 676 00:29:24,143 --> 00:29:26,830 All right, other questions? 677 00:29:26,830 --> 00:29:27,662 Yeah. 678 00:29:27,662 --> 00:29:32,482 STUDENT: So [INAUDIBLE] the idea is once you get the TGS ticket, 679 00:29:32,482 --> 00:29:33,940 you can just get rid of your KC? 680 00:29:33,940 --> 00:29:34,840 PROFESSOR: Yes, so that's actually 681 00:29:34,840 --> 00:29:36,660 the cool thing about it is that once 682 00:29:36,660 --> 00:29:40,250 you get this ticket-- well, this ticket with the S being TGS, 683 00:29:40,250 --> 00:29:43,450 then you're going to get rid of the password and KC. 684 00:29:43,450 --> 00:29:46,836 So you log into Athena workstation and a couple 685 00:29:46,836 --> 00:29:48,210 of seconds into the boot process, 686 00:29:48,210 --> 00:29:49,584 you already get your ticket here. 687 00:29:49,584 --> 00:29:51,280 It scrubs the password from memory. 688 00:29:51,280 --> 00:29:54,240 So even if someone, like, grabs you and grab the machine 689 00:29:54,240 --> 00:29:56,870 and runs off, all they got was your ticket. 690 00:29:56,870 --> 00:29:59,830 And OK, well, maybe they can access your stuff for 10 hours 691 00:29:59,830 --> 00:30:01,410 or whatever the ticket lifetime was, 692 00:30:01,410 --> 00:30:02,760 but not for longer than that. 693 00:30:02,760 --> 00:30:05,580 The password is gone. 694 00:30:05,580 --> 00:30:06,080 Yeah. 695 00:30:06,080 --> 00:30:08,912 So if the password's gone, then on that picture 696 00:30:08,912 --> 00:30:11,000 there when Kerberos sends a reply 697 00:30:11,000 --> 00:30:14,220 encrypted with KC, how does the client-- 698 00:30:14,220 --> 00:30:16,680 Oh yeah, so this is the one place you need your password. 699 00:30:16,680 --> 00:30:19,650 So you send this message, you get this reply, 700 00:30:19,650 --> 00:30:22,603 you decrypt this, and then you forget the password. 701 00:30:22,603 --> 00:30:24,186 So you can't forget about the password 702 00:30:24,186 --> 00:30:26,220 before you use it for decryption of course. 703 00:30:26,220 --> 00:30:28,150 STUDENT: [INAUDIBLE] 704 00:30:28,150 --> 00:30:30,590 PROFESSOR: Ah, no, so this is just this interface, right? 705 00:30:30,590 --> 00:30:33,470 So this is the thing you do initially. 706 00:30:33,470 --> 00:30:36,220 And we'll talk in a second about how you basically also 707 00:30:36,220 --> 00:30:38,840 can get any ticket you want from the second interface 708 00:30:38,840 --> 00:30:43,924 without needing the initial key KC. 709 00:30:43,924 --> 00:30:46,760 Right, make sense? 710 00:30:46,760 --> 00:30:49,530 All right, so I guess we already talked 711 00:30:49,530 --> 00:30:53,920 about two particular problems that the Kerberos protocol had 712 00:30:53,920 --> 00:30:56,830 sort of baked into it, which is a little unfortunate. 713 00:30:56,830 --> 00:30:59,520 One is that they assumed that encryption also 714 00:30:59,520 --> 00:31:02,440 provides authentication or integrity of messages. 715 00:31:02,440 --> 00:31:03,270 So don't do that. 716 00:31:03,270 --> 00:31:05,040 And Kerberos version 5 fixes this 717 00:31:05,040 --> 00:31:07,770 by explicitly authenticating messages. 718 00:31:07,770 --> 00:31:11,940 Another thing they sort of had a problem with 719 00:31:11,940 --> 00:31:14,820 is the ability for arbitrary clients 720 00:31:14,820 --> 00:31:17,220 to guess people's passwords. 721 00:31:17,220 --> 00:31:21,102 So any suggestions of how we could fix this? 722 00:31:21,102 --> 00:31:22,560 How do you prevent guessing attacks 723 00:31:22,560 --> 00:31:24,826 in a protocol like this? 724 00:31:24,826 --> 00:31:26,242 What could we try? 725 00:31:26,242 --> 00:31:26,775 Yeah. 726 00:31:26,775 --> 00:31:28,024 STUDENT: Some sort of salting? 727 00:31:28,024 --> 00:31:29,400 I'm not sure. 728 00:31:29,400 --> 00:31:31,540 PROFESSOR: Well, so salting would just 729 00:31:31,540 --> 00:31:33,900 means that the client has to hash the password 730 00:31:33,900 --> 00:31:35,066 in different ways, maybe. 731 00:31:35,066 --> 00:31:36,440 But it still doesn't prevent them 732 00:31:36,440 --> 00:31:37,659 from trying lots of things. 733 00:31:37,659 --> 00:31:39,950 So maybe it'll be more expensive to build a dictionary. 734 00:31:39,950 --> 00:31:40,449 Yeah. 735 00:31:40,449 --> 00:31:43,109 STUDENT: You could [INAUDIBLE] derivation function? 736 00:31:43,109 --> 00:31:44,650 PROFESSOR: Yeah, so another good idea 737 00:31:44,650 --> 00:31:47,949 is to make this hashing process super expensive. 738 00:31:47,949 --> 00:31:49,490 So that might be kind of nice, right? 739 00:31:49,490 --> 00:31:52,650 So if this hash function took a second to compute like you 740 00:31:52,650 --> 00:31:54,404 guys did in lab two, then OK, wow, this 741 00:31:54,404 --> 00:31:55,820 would be actually really expensive 742 00:31:55,820 --> 00:31:56,810 to try different passwords. 743 00:31:56,810 --> 00:31:58,351 So that seems like a reasonable plan. 744 00:31:58,351 --> 00:32:00,500 So in combination with salting, those 745 00:32:00,500 --> 00:32:02,880 would be make it pretty expensive to do password 746 00:32:02,880 --> 00:32:03,987 guessing attacks. 747 00:32:03,987 --> 00:32:04,570 Anything else? 748 00:32:07,035 --> 00:32:08,910 So another thing is, yeah, challenge respond. 749 00:32:08,910 --> 00:32:11,620 So you could actually hear in the initial protocol, 750 00:32:11,620 --> 00:32:13,790 the Kerberos server doesn't have any idea 751 00:32:13,790 --> 00:32:15,720 if this was the right client or not. 752 00:32:15,720 --> 00:32:18,202 But in fact, what you could do is maybe 753 00:32:18,202 --> 00:32:20,160 give a little bit of a proof that, well, you're 754 00:32:20,160 --> 00:32:22,010 probably the right client. 755 00:32:22,010 --> 00:32:24,980 So maybe you could encrypt the current time stamp 756 00:32:24,980 --> 00:32:27,890 with your hash password or something 757 00:32:27,890 --> 00:32:29,455 like this-- has them together. 758 00:32:29,455 --> 00:32:31,080 And then the Kerberos server could just 759 00:32:31,080 --> 00:32:34,250 check if that's the right-- if that matches, and if so, return 760 00:32:34,250 --> 00:32:35,330 you back a ticket. 761 00:32:35,330 --> 00:32:37,580 You probably don't want to necessarily add more rounds 762 00:32:37,580 --> 00:32:38,450 but this could work. 763 00:32:38,450 --> 00:32:40,760 So just to precise about what I'm sort of suggesting. 764 00:32:40,760 --> 00:32:44,460 OK, well, maybe you take the current time stamp 765 00:32:44,460 --> 00:32:51,550 and maybe you hash the current time stamp and the KC together. 766 00:32:51,550 --> 00:32:53,570 And maybe you include the timestamp as well. 767 00:32:53,570 --> 00:32:55,957 And then the server could see, well, it has your KC. 768 00:32:55,957 --> 00:32:57,790 It could hash the current timestamp as well. 769 00:32:57,790 --> 00:32:59,490 If it gets the same value, then yeah, 770 00:32:59,490 --> 00:33:01,281 it's probably the right user requesting it. 771 00:33:01,281 --> 00:33:02,870 And I can send back the ticket. 772 00:33:02,870 --> 00:33:06,420 If not, then it wasn't the right password at all. 773 00:33:06,420 --> 00:33:06,970 Question? 774 00:33:06,970 --> 00:33:13,041 STUDENT: [INAUDIBLE] you just do [INAUDIBLE] if the servers see 775 00:33:13,041 --> 00:33:14,545 too many requests [INAUDIBLE] 776 00:33:14,545 --> 00:33:15,545 PROFESSOR: That's right. 777 00:33:15,545 --> 00:33:17,570 So the problem is that we could write limit. 778 00:33:17,570 --> 00:33:19,070 But there's no reason for the hacker 779 00:33:19,070 --> 00:33:21,120 to request this more than once. 780 00:33:21,120 --> 00:33:23,980 That hacker requests a particular user more than once 781 00:33:23,980 --> 00:33:26,240 and then it gets this encrypted blob. 782 00:33:26,240 --> 00:33:28,980 And then it can try decrypting it offline as many times 783 00:33:28,980 --> 00:33:31,000 as it wants with different passwords 784 00:33:31,000 --> 00:33:33,080 without having to re request it. 785 00:33:33,080 --> 00:33:34,950 So I think the whole point of including 786 00:33:34,950 --> 00:33:36,840 some sort of a challenge response thing 787 00:33:36,840 --> 00:33:41,057 like this in the particle is so that the server will-- 788 00:33:41,057 --> 00:33:42,890 you'll have to actually ask the server again 789 00:33:42,890 --> 00:33:46,809 and again to try to log in with different passwords. 790 00:33:46,809 --> 00:33:48,600 And then you could rate limit of the server 791 00:33:48,600 --> 00:33:50,700 and get a much better defense. 792 00:33:50,700 --> 00:33:51,640 Yeah. 793 00:33:51,640 --> 00:33:54,930 STUDENT: [INAUDIBLE] Kerberos? 794 00:33:54,930 --> 00:34:00,210 PROFESSOR: So I think you could certainly replay this message 795 00:34:00,210 --> 00:34:03,330 so if I sent this message now, you could probably 796 00:34:03,330 --> 00:34:05,420 look at that message and send it as well 797 00:34:05,420 --> 00:34:07,535 and get a response back from the Kerberos server. 798 00:34:07,535 --> 00:34:09,159 I guess if you're watching the network, 799 00:34:09,159 --> 00:34:12,429 you could observe this thing on the wire as well. 800 00:34:12,429 --> 00:34:16,780 So I think this is sort of a bit of a stopgap measure-- improves 801 00:34:16,780 --> 00:34:17,420 security a bit. 802 00:34:17,420 --> 00:34:21,002 But certainly if you're watching someone else's network, 803 00:34:21,002 --> 00:34:23,460 then you're going to see this packet coming back regardless 804 00:34:23,460 --> 00:34:25,546 of what happened in this step. 805 00:34:25,546 --> 00:34:27,004 So coming back, you'll see this guy 806 00:34:27,004 --> 00:34:28,817 and you can then try to attack it. 807 00:34:28,817 --> 00:34:30,650 There's probably some more elaborate schemes 808 00:34:30,650 --> 00:34:32,500 you could design but I didn't think 809 00:34:32,500 --> 00:34:34,469 Kerberos 5 even implements anything more 810 00:34:34,469 --> 00:34:37,590 elaborate than roughly this plan, which seems good enough 811 00:34:37,590 --> 00:34:39,460 to prevent arbitrary people from trying 812 00:34:39,460 --> 00:34:43,130 to break anyone's or brute force anyone's password. 813 00:34:43,130 --> 00:34:44,326 Make sense? 814 00:34:44,326 --> 00:34:44,826 Yeah. 815 00:34:44,826 --> 00:34:46,513 STUDENT: So presume that you could 816 00:34:46,513 --> 00:34:50,528 do authenticated [INAUDIBLE] or something here 817 00:34:50,528 --> 00:34:51,694 to establish the shared key. 818 00:34:51,694 --> 00:34:53,235 And then you could encrypt this thing 819 00:34:53,235 --> 00:34:54,474 with KC and the shared key. 820 00:34:54,474 --> 00:34:55,300 PROFESSOR: That's right, yeah. 821 00:34:55,300 --> 00:34:56,841 So if you're really doing this right, 822 00:34:56,841 --> 00:34:59,630 there's all these nice particles out there 823 00:34:59,630 --> 00:35:02,080 that are basically called password authenticated key 824 00:35:02,080 --> 00:35:04,170 exchange particles, which is exactly what's going on here. 825 00:35:04,170 --> 00:35:05,836 So if you're actually building a system, 826 00:35:05,836 --> 00:35:08,800 you should basically Google for SRP or PAKE. 827 00:35:08,800 --> 00:35:12,680 And these protocols and related particles 828 00:35:12,680 --> 00:35:15,480 will actually do this in a much better way where 829 00:35:15,480 --> 00:35:18,760 you can prove to both parties that you established 830 00:35:18,760 --> 00:35:20,850 a new key and both parties are convinced that it's 831 00:35:20,850 --> 00:35:23,610 the right other party and there's no way 832 00:35:23,610 --> 00:35:26,240 to mount these offline password guessing attacks 833 00:35:26,240 --> 00:35:29,682 on the set of network packets that you observe and so on. 834 00:35:29,682 --> 00:35:31,140 So these are the sort of protocols. 835 00:35:31,140 --> 00:35:33,220 And they're much more elaborate in terms 836 00:35:33,220 --> 00:35:34,310 of crypto they rely on. 837 00:35:34,310 --> 00:35:36,690 So it's hard to explain on a board exactly why they work. 838 00:35:36,690 --> 00:35:37,190 Yeah. 839 00:35:37,190 --> 00:35:39,050 STUDENT: [INAUDIBLE] part of the reason 840 00:35:39,050 --> 00:35:40,938 they did it this way is because they 841 00:35:40,938 --> 00:35:44,714 wanted to maintain the ability of just sending the password. 842 00:35:44,714 --> 00:35:48,365 And protocols just allow you to send a single thing 843 00:35:48,365 --> 00:35:50,840 as your authentication [INAUDIBLE]. 844 00:35:50,840 --> 00:35:52,820 PROFESSOR: Well, yeah, there's lots 845 00:35:52,820 --> 00:35:56,950 of sort of weird requirements that these guys had in mind. 846 00:35:56,950 --> 00:36:01,540 I think they-- well, certainly in practice, 847 00:36:01,540 --> 00:36:06,340 these servers could accept both Kerberos and non Kerberos 848 00:36:06,340 --> 00:36:06,866 connections. 849 00:36:06,866 --> 00:36:08,240 And for non Kerberos connections, 850 00:36:08,240 --> 00:36:10,030 you get-- like someone connects to the mail server 851 00:36:10,030 --> 00:36:11,520 but they're not using an Athena workstation. 852 00:36:11,520 --> 00:36:13,180 They just want to send their password. 853 00:36:13,180 --> 00:36:14,889 And then the mail client here, let's say, 854 00:36:14,889 --> 00:36:16,430 is going to take your password and is 855 00:36:16,430 --> 00:36:18,770 going to get a ticket on your behalf just to check it. 856 00:36:18,770 --> 00:36:19,990 And then it's going to allow you to use it. 857 00:36:19,990 --> 00:36:22,531 So you certainly want conversion from Kerberos from passwords 858 00:36:22,531 --> 00:36:25,119 into checking against Kerberos. 859 00:36:25,119 --> 00:36:27,160 I don't think this precludes it because certainly 860 00:36:27,160 --> 00:36:30,833 Kerberos 5 deploys although this hashes of timestamps, 861 00:36:30,833 --> 00:36:31,332 et cetera. 862 00:36:31,332 --> 00:36:33,165 STUDENT: Yeah but it's because they wouldn't 863 00:36:33,165 --> 00:36:35,028 want multiple [INAUDIBLE]. 864 00:36:35,028 --> 00:36:37,620 PROFESSOR: Yeah, well, I think that probably 865 00:36:37,620 --> 00:36:38,967 doesn't matter quite as much. 866 00:36:38,967 --> 00:36:41,300 You could certainly have multiple rounds in the back end 867 00:36:41,300 --> 00:36:43,380 behind your library. 868 00:36:43,380 --> 00:36:46,670 But there's some downsides to these particles-- 869 00:36:46,670 --> 00:36:50,180 probably not significant enough to stop you from using them. 870 00:36:50,180 --> 00:36:53,040 Other questions? 871 00:36:53,040 --> 00:36:54,880 All right, I guess the other thing 872 00:36:54,880 --> 00:36:57,040 I want to mention that you should watch out 873 00:36:57,040 --> 00:37:01,080 for in the paper is that these guys, in designing Kerberos 4, 874 00:37:01,080 --> 00:37:03,550 they picked a single encryption scheme. 875 00:37:03,550 --> 00:37:05,740 And at the time, they basically picked 876 00:37:05,740 --> 00:37:09,260 DES, which was a popular encryption scheme of the time. 877 00:37:09,260 --> 00:37:11,590 It's a symmetric block cypher. 878 00:37:11,590 --> 00:37:12,820 It goes pretty fast. 879 00:37:12,820 --> 00:37:16,090 It was reasonably secure, not necessarily the best, 880 00:37:16,090 --> 00:37:18,392 but certainly good enough at the time. 881 00:37:18,392 --> 00:37:20,100 And they just baked it into the protocol. 882 00:37:20,100 --> 00:37:22,880 Everything in Kerberos has to use single DES or at least 883 00:37:22,880 --> 00:37:24,890 everything in Kerberos version 4. 884 00:37:24,890 --> 00:37:27,935 And this was a bit problematic because 25 years later, 885 00:37:27,935 --> 00:37:29,310 30 years later now, it's actually 886 00:37:29,310 --> 00:37:32,820 very cheap to brute force DES encryption 887 00:37:32,820 --> 00:37:34,690 because the keys are actually very small. 888 00:37:34,690 --> 00:37:36,570 They're 56 bits. 889 00:37:36,570 --> 00:37:39,140 So you could just search build some custom hardware that 890 00:37:39,140 --> 00:37:42,090 iterates over all the possible 2 to the 56 combinations 891 00:37:42,090 --> 00:37:46,379 and tries them all and figures out what someone's password is. 892 00:37:46,379 --> 00:37:48,170 So this is something also you want to avoid 893 00:37:48,170 --> 00:37:49,710 in any protocol you design now. 894 00:37:49,710 --> 00:37:51,550 Kerberos version 5 actually supports 895 00:37:51,550 --> 00:37:54,730 multiple different encryption schemes including 896 00:37:54,730 --> 00:37:56,885 AES and other things as well. 897 00:37:56,885 --> 00:37:59,350 So that seems like a much better way to do it. 898 00:37:59,350 --> 00:38:02,320 On the other hand, MIT actually kept supporting DES up 899 00:38:02,320 --> 00:38:06,540 until two years ago, which is a little unfortunate. 900 00:38:06,540 --> 00:38:07,560 But now they don't. 901 00:38:07,560 --> 00:38:08,530 So that's good. 902 00:38:08,530 --> 00:38:12,860 Your principal is secure at least from this kind of attack. 903 00:38:12,860 --> 00:38:14,680 All right, so does that make sense? 904 00:38:14,680 --> 00:38:16,350 This is the initial way you'd get 905 00:38:16,350 --> 00:38:18,210 any ticket at all in Kerberos. 906 00:38:18,210 --> 00:38:20,810 And typically, you'd get this ticket from this TGS service. 907 00:38:20,810 --> 00:38:24,090 So now let's look at what's going on in this TGS service. 908 00:38:24,090 --> 00:38:27,700 So here, the interaction with the TGS service 909 00:38:27,700 --> 00:38:29,350 is going to be a little different. 910 00:38:29,350 --> 00:38:32,150 On one hand, you're going to-- as a client, 911 00:38:32,150 --> 00:38:33,900 you're going to have to speak to it as 912 00:38:33,900 --> 00:38:37,910 if you're speaking to any other Kerberos enabled service. 913 00:38:37,910 --> 00:38:39,660 So we'll see how you authenticate yourself 914 00:38:39,660 --> 00:38:41,714 with a ticket to some machine. 915 00:38:41,714 --> 00:38:43,630 But then the response you're going to get back 916 00:38:43,630 --> 00:38:46,071 is just a ticket for some other principle 917 00:38:46,071 --> 00:38:48,570 that you're going to want to communicate with like your file 918 00:38:48,570 --> 00:38:50,230 server. 919 00:38:50,230 --> 00:38:54,210 So the protocol level messages that show up here kind of 920 00:38:54,210 --> 00:38:54,910 look like this. 921 00:38:54,910 --> 00:38:57,050 So here's your TGS service. 922 00:38:57,050 --> 00:38:59,230 And here's a client. 923 00:38:59,230 --> 00:39:02,750 The client already got a ticket for TGS 924 00:39:02,750 --> 00:39:04,090 using this protocol above. 925 00:39:04,090 --> 00:39:06,580 So what the client is actually going to send over 926 00:39:06,580 --> 00:39:10,190 is some combination of messages that 927 00:39:10,190 --> 00:39:12,690 prove that this is the right client 928 00:39:12,690 --> 00:39:16,900 and they're issuing a request for some particular principle 929 00:39:16,900 --> 00:39:17,490 through TGS. 930 00:39:17,490 --> 00:39:20,414 So what the client is going to send to TGS is this tuple. 931 00:39:20,414 --> 00:39:21,830 So first, it's going to say, well, 932 00:39:21,830 --> 00:39:24,000 here's the service that I want to talk to next. 933 00:39:24,000 --> 00:39:27,130 So this might be your mail server or your file server. 934 00:39:27,130 --> 00:39:29,440 Then is going to include the ticket. 935 00:39:29,440 --> 00:39:30,970 It already got 4TGS. 936 00:39:30,970 --> 00:39:38,100 So this is going to be TC of TGS encrypted with KTGS. 937 00:39:38,100 --> 00:39:41,430 So this is just this thing where S is TGS. 938 00:39:41,430 --> 00:39:43,890 And then you're going to have to include this authenticator 939 00:39:43,890 --> 00:39:44,890 blob. 940 00:39:44,890 --> 00:39:48,155 This is this AC thing from up there. 941 00:39:48,155 --> 00:39:49,780 And this thing is going to be encrypted 942 00:39:49,780 --> 00:39:54,892 with a shared key between the client and the TGS service. 943 00:39:54,892 --> 00:39:58,360 So this is the message that you're going to send to TGS. 944 00:39:58,360 --> 00:40:00,399 It's going to look at this message, 945 00:40:00,399 --> 00:40:02,690 do something with it that we'll talk about in a second, 946 00:40:02,690 --> 00:40:07,770 and respond back with a ticket for this new service S. 947 00:40:07,770 --> 00:40:10,700 So the response here looks almost exactly like here. 948 00:40:10,700 --> 00:40:12,490 In fact, it is exactly the same thing. 949 00:40:12,490 --> 00:40:14,610 It's going to be a ticket between the client 950 00:40:14,610 --> 00:40:18,310 and this new service S encrypted with KS 951 00:40:18,310 --> 00:40:21,320 and the shared key between the client and this new service 952 00:40:21,320 --> 00:40:25,040 S encrypted-- well, now, here's a little bit different. 953 00:40:25,040 --> 00:40:27,550 Instead of encrypting with KC, which the client has probably 954 00:40:27,550 --> 00:40:29,280 forgotten since then, now we're going 955 00:40:29,280 --> 00:40:31,800 to encrypt it with this shared key between the client 956 00:40:31,800 --> 00:40:35,510 and the TGS service. 957 00:40:35,510 --> 00:40:38,030 Makes sense? 958 00:40:38,030 --> 00:40:44,850 All right, so in this-- how does the server actually figure out 959 00:40:44,850 --> 00:40:46,590 what the client wants to do? 960 00:40:46,590 --> 00:40:49,120 Or, how does server authenticate the client? 961 00:40:49,120 --> 00:40:52,650 Well, in this case, it's going to-- TGS server actually 962 00:40:52,650 --> 00:40:54,840 knows its own key, KTGS. 963 00:40:54,840 --> 00:40:57,390 So it's going to first decrypt this blob 964 00:40:57,390 --> 00:41:00,090 and look inside the ticket and figure out what's going on. 965 00:41:00,090 --> 00:41:03,190 And there's all those nice fields in the ticket. 966 00:41:03,190 --> 00:41:04,400 So let's just double check. 967 00:41:04,400 --> 00:41:07,100 Why do we need all those fields in the ticket? 968 00:41:07,100 --> 00:41:12,687 So is it important to have the server name S in the ticket? 969 00:41:12,687 --> 00:41:14,770 What would go wrong if you didn't have S in there? 970 00:41:17,722 --> 00:41:19,682 Anything? 971 00:41:19,682 --> 00:41:20,182 Yeah. 972 00:41:20,182 --> 00:41:21,640 STUDENT: They could potentially get 973 00:41:21,640 --> 00:41:24,610 authorized to use any server. 974 00:41:24,610 --> 00:41:27,370 PROFESSOR: Yeah, so it's in general a good idea 975 00:41:27,370 --> 00:41:29,300 to be very explicit in network protocols 976 00:41:29,300 --> 00:41:31,580 and to say exactly what a message means. 977 00:41:31,580 --> 00:41:33,910 So in this case, if you omit an S, 978 00:41:33,910 --> 00:41:37,189 you might be relying on the fact that, well, 979 00:41:37,189 --> 00:41:39,730 if it's the wrong S that you're trying to use the ticket for, 980 00:41:39,730 --> 00:41:42,320 then maybe you'll have a different key over here 981 00:41:42,320 --> 00:41:44,490 and then it wouldn't decrypt or something like this. 982 00:41:44,490 --> 00:41:46,823 But it seems like a good idea to include it to make sure 983 00:41:46,823 --> 00:41:48,630 that the server that receives this tickets 984 00:41:48,630 --> 00:41:49,960 decrypts and checks. 985 00:41:49,960 --> 00:41:52,470 Is that a ticket for me or for someone else? 986 00:41:52,470 --> 00:41:52,970 Yeah. 987 00:41:52,970 --> 00:41:55,522 STUDENT: What does the client get KTGS on? 988 00:41:55,522 --> 00:41:56,730 PROFESSOR: Ah, good question. 989 00:41:56,730 --> 00:41:58,230 The client has no idea what this is. 990 00:41:58,230 --> 00:42:00,060 Because this is like a super secret key. 991 00:42:00,060 --> 00:42:01,770 If you knew this, you'd probably be 992 00:42:01,770 --> 00:42:03,480 able to break all of Kerberos. 993 00:42:03,480 --> 00:42:06,461 So the client has no idea what KTGS is. 994 00:42:06,461 --> 00:42:07,294 STUDENT: [INAUDIBLE] 995 00:42:07,294 --> 00:42:08,110 PROFESSOR: Ah, yeah, yeah. 996 00:42:08,110 --> 00:42:09,335 And then the where you get it from 997 00:42:09,335 --> 00:42:11,209 is actually-- it's the Kerberos server itself 998 00:42:11,209 --> 00:42:14,830 that generates this whole blob for you where this is actually 999 00:42:14,830 --> 00:42:18,780 TGS and this is KTGS over here. 1000 00:42:18,780 --> 00:42:20,450 So you don't construct this yourself. 1001 00:42:20,450 --> 00:42:22,830 You just copy it over. 1002 00:42:22,830 --> 00:42:23,660 OK 1003 00:42:23,660 --> 00:42:27,154 So what is the client name there important for? 1004 00:42:27,154 --> 00:42:28,570 That should be fairly easy, right? 1005 00:42:28,570 --> 00:42:30,020 If you don't put the client name in the ticket, 1006 00:42:30,020 --> 00:42:31,830 then the server gets this nice blob 1007 00:42:31,830 --> 00:42:34,382 but it has no idea who it's trying to talk to. 1008 00:42:34,382 --> 00:42:35,840 So it has no idea whether it should 1009 00:42:35,840 --> 00:42:38,890 issue a ticket for my principal or for someone else's 1010 00:42:38,890 --> 00:42:41,250 principle, et cetera. 1011 00:42:41,250 --> 00:42:44,470 So what's the deal with the other fields? 1012 00:42:44,470 --> 00:42:46,625 Why do these guys stick an address in the ticket? 1013 00:42:49,190 --> 00:42:51,475 This is the client's IP address. 1014 00:42:51,475 --> 00:42:53,741 Does it matter? 1015 00:42:53,741 --> 00:42:54,240 Yeah. 1016 00:42:54,240 --> 00:42:56,632 STUDENT: Can they use that address 1017 00:42:56,632 --> 00:42:59,899 with the ticket to verify against the [INAUDIBLE]? 1018 00:42:59,899 --> 00:43:00,690 PROFESSOR: Sort of. 1019 00:43:00,690 --> 00:43:02,322 Well, so I think the general plan 1020 00:43:02,322 --> 00:43:03,780 for why there's addresses appearing 1021 00:43:03,780 --> 00:43:05,290 everywhere here, these IP addresses, 1022 00:43:05,290 --> 00:43:08,220 is that these guys at the time were still slightly 1023 00:43:08,220 --> 00:43:11,402 confused and-- well, in some ways-- 1024 00:43:11,402 --> 00:43:12,860 they were still thinking, OK, well, 1025 00:43:12,860 --> 00:43:14,318 we're going to rely on IP addresses 1026 00:43:14,318 --> 00:43:15,800 for a little bit of security. 1027 00:43:15,800 --> 00:43:19,350 So they wanted to make sure that if the client logged in 1028 00:43:19,350 --> 00:43:21,830 from some IP address, then everything else going on 1029 00:43:21,830 --> 00:43:24,300 with that ticket happen from that same IP address. 1030 00:43:24,300 --> 00:43:27,070 So if you logged in from some IP address 1031 00:43:27,070 --> 00:43:31,066 on 18.26.4.9 or something, then every connection 1032 00:43:31,066 --> 00:43:32,940 you make to a file server or to a mail server 1033 00:43:32,940 --> 00:43:34,280 has to be from the same IP address. 1034 00:43:34,280 --> 00:43:36,405 Otherwise, the server should reject your connection 1035 00:43:36,405 --> 00:43:39,570 as being stolen by-- or someone stole your ticket. 1036 00:43:39,570 --> 00:43:41,500 So we're thinking, OK, well, maybe we'll 1037 00:43:41,500 --> 00:43:43,350 defend against ticket theft this way. 1038 00:43:43,350 --> 00:43:45,010 If you still a ticket, well, but you're 1039 00:43:45,010 --> 00:43:46,260 not using the same IP address. 1040 00:43:46,260 --> 00:43:47,685 So it won't work. 1041 00:43:47,685 --> 00:43:49,830 It's probably a little bit misguided at this point 1042 00:43:49,830 --> 00:43:52,980 but-- that sort of gets in the way And Kerberos 5 still has it 1043 00:43:52,980 --> 00:43:54,350 but it's largely optional. 1044 00:43:54,350 --> 00:43:58,410 Really, you should just rely on cryptography instead of any IP 1045 00:43:58,410 --> 00:44:00,430 address security. 1046 00:44:00,430 --> 00:44:02,890 So what's the point of the time stamp and lifetime things 1047 00:44:02,890 --> 00:44:04,760 in the ticket up there? 1048 00:44:04,760 --> 00:44:06,445 One are those guys good for? 1049 00:44:06,445 --> 00:44:08,595 Are they useful? 1050 00:44:08,595 --> 00:44:09,095 Yeah. 1051 00:44:09,095 --> 00:44:11,270 STUDENT: Preventing replay attacks. 1052 00:44:11,270 --> 00:44:12,687 PROFESSOR: Well, so the syndicator 1053 00:44:12,687 --> 00:44:14,520 is the thing that's going to help us prevent 1054 00:44:14,520 --> 00:44:16,080 replay attacks in a second. 1055 00:44:16,080 --> 00:44:18,470 Because that thing gets generated every time 1056 00:44:18,470 --> 00:44:20,370 you do a new request. 1057 00:44:20,370 --> 00:44:22,490 On the other hand, the ticket just stays the same. 1058 00:44:22,490 --> 00:44:24,739 So it's certainly not preventing replay attacks there. 1059 00:44:24,739 --> 00:44:25,304 Yeah. 1060 00:44:25,304 --> 00:44:27,804 STUDENT: It prevents somebody from stealing your ticket then 1061 00:44:27,804 --> 00:44:28,638 using it [INAUDIBLE] 1062 00:44:28,638 --> 00:44:29,720 PROFESSOR: Oh, sorry, yes. 1063 00:44:29,720 --> 00:44:32,050 This just bounds the time for which a ticket is valid, 1064 00:44:32,050 --> 00:44:34,630 meaning that the damage from disclosing it 1065 00:44:34,630 --> 00:44:37,110 is hopefully reduced. 1066 00:44:37,110 --> 00:44:39,900 So the plan is the timestamp is roughly the time when 1067 00:44:39,900 --> 00:44:41,370 you initially got the ticket. 1068 00:44:41,370 --> 00:44:44,070 And a lifetime in the ticket represents 1069 00:44:44,070 --> 00:44:47,030 how many hours, let's say, it's valid 1070 00:44:47,030 --> 00:44:48,900 from that initial timestamp. 1071 00:44:48,900 --> 00:44:51,050 So if you try to use it too early or too late, 1072 00:44:51,050 --> 00:44:54,100 then every server should reject such a ticket 1073 00:44:54,100 --> 00:44:56,040 in the Kerberos protocol. 1074 00:44:56,040 --> 00:44:58,180 So this kind of means that every server 1075 00:44:58,180 --> 00:45:02,859 has to have a loosely synchronized, clock which 1076 00:45:02,859 --> 00:45:04,900 is a bit of a-- well, maybe you've run into this. 1077 00:45:04,900 --> 00:45:07,483 Like, your laptop clock is off and you can't log into Kerberos 1078 00:45:07,483 --> 00:45:08,121 anymore. 1079 00:45:08,121 --> 00:45:08,620 Question? 1080 00:45:08,620 --> 00:45:09,190 Yeah. 1081 00:45:09,190 --> 00:45:11,980 STUDENT: You said before that the client discards KC 1082 00:45:11,980 --> 00:45:14,780 but they're still keeping KCS [INAUDIBLE] 1083 00:45:14,780 --> 00:45:16,305 the TGS. [INAUDIBLE] 1084 00:45:16,305 --> 00:45:17,555 PROFESSOR: That's right, yeah. 1085 00:45:17,555 --> 00:45:20,310 So the client discards KC after logging in. 1086 00:45:20,310 --> 00:45:21,600 But it still keeps KCS. 1087 00:45:21,600 --> 00:45:22,997 You're exactly right. 1088 00:45:22,997 --> 00:45:24,580 STUDENT: So if someone steals the KCS, 1089 00:45:24,580 --> 00:45:27,487 then they have access to [INAUDIBLE]. 1090 00:45:27,487 --> 00:45:28,320 PROFESSOR: Yeah, OK. 1091 00:45:28,320 --> 00:45:29,111 So how bad is that? 1092 00:45:29,111 --> 00:45:32,892 Like, why is it better to disclose this KCS 1093 00:45:32,892 --> 00:45:34,600 fof-- actually, well, this is TGS, right? 1094 00:45:34,600 --> 00:45:37,235 Why is it better to disclose KCTGS than KC? 1095 00:45:39,980 --> 00:45:40,918 Yeah. 1096 00:45:40,918 --> 00:45:43,205 STUDENT: Someone [INAUDIBLE] somewhere [INAUDIBLE]. 1097 00:45:43,205 --> 00:45:44,580 PROFESSOR: It's the kind of thing 1098 00:45:44,580 --> 00:45:45,390 that they're both keys, though. 1099 00:45:45,390 --> 00:45:47,181 So neither of them are really hashed, yeah. 1100 00:45:47,181 --> 00:45:49,533 STUDENT: You would take KCS and you'd just steal 1101 00:45:49,533 --> 00:45:51,238 that session between those two. 1102 00:45:51,238 --> 00:45:53,740 But if you steal KC, you can impersonate the client. 1103 00:45:53,740 --> 00:45:54,740 PROFESSOR: That's right. 1104 00:45:54,740 --> 00:45:55,240 Yeah. 1105 00:45:55,240 --> 00:45:56,730 So I guess one way to answer this 1106 00:45:56,730 --> 00:46:00,820 is that KCTGS, this is actually a new key generated every time 1107 00:46:00,820 --> 00:46:02,820 you log in initially. 1108 00:46:02,820 --> 00:46:06,550 And this thing is only good because you have this ticket 1109 00:46:06,550 --> 00:46:08,620 that goes along with it. 1110 00:46:08,620 --> 00:46:11,550 If you lose this ticket or if this ticket is no longer valid, 1111 00:46:11,550 --> 00:46:14,500 then yeah, you have these 56 bits in this key. 1112 00:46:14,500 --> 00:46:18,880 But no one is going to assume anything from those bits. 1113 00:46:18,880 --> 00:46:20,760 The only reason these bits are interesting 1114 00:46:20,760 --> 00:46:24,200 is because this ticket talks about this KCS being valid 1115 00:46:24,200 --> 00:46:25,160 right now. 1116 00:46:25,160 --> 00:46:26,886 And there's a bound on it. 1117 00:46:26,886 --> 00:46:28,790 STUDENT: Yeah, so if they stole both of those 1118 00:46:28,790 --> 00:46:30,579 [INAUDIBLE] be bounded. 1119 00:46:30,579 --> 00:46:32,870 PROFESSOR: Yeah, if someone steals both of these blogs, 1120 00:46:32,870 --> 00:46:36,040 than they can impersonate you or, like, log into your file 1121 00:46:36,040 --> 00:46:39,450 server, mail server for the lifetime of that ticket, which 1122 00:46:39,450 --> 00:46:41,990 is a couple of hours or 10 hours. 1123 00:46:41,990 --> 00:46:44,760 Stealing this, there's no time bound on that until you change 1124 00:46:44,760 --> 00:46:47,355 your password and maybe worse. 1125 00:46:47,355 --> 00:46:49,720 Make sense? 1126 00:46:49,720 --> 00:46:53,050 All right, so it seems like, yeah, 1127 00:46:53,050 --> 00:46:54,840 all those fields are kind of important, 1128 00:46:54,840 --> 00:46:57,810 IP address maybe less so. 1129 00:46:57,810 --> 00:47:02,220 And now in response, right, we can get this ticket finally. 1130 00:47:02,220 --> 00:47:05,950 And because we know KCTGS, we can decrypt the response 1131 00:47:05,950 --> 00:47:07,120 from this TGS server. 1132 00:47:07,120 --> 00:47:09,790 And now we have a ticket for any server 1133 00:47:09,790 --> 00:47:12,350 we want-- a file server, mail server, whatever 1134 00:47:12,350 --> 00:47:15,840 it is that we finally care about connecting to. 1135 00:47:15,840 --> 00:47:18,470 Make sense? 1136 00:47:18,470 --> 00:47:23,050 All right, so let's look at how you might sort of finally 1137 00:47:23,050 --> 00:47:26,510 use this in some application level protocol. 1138 00:47:26,510 --> 00:47:30,090 So suppose that maybe I'm talking to a mail server 1139 00:47:30,090 --> 00:47:31,610 to fetch my messages. 1140 00:47:31,610 --> 00:47:34,850 So presumably, what my client workstation is going to do 1141 00:47:34,850 --> 00:47:37,245 is going to send a tickets requesting for, I don't know, 1142 00:47:37,245 --> 00:47:39,770 mail.po12. 1143 00:47:39,770 --> 00:47:43,380 And it'll get back a ticket for the principal mail.po12 1144 00:47:43,380 --> 00:47:44,850 or something like this. 1145 00:47:44,850 --> 00:47:49,340 And then inside of this ticket or inside of this response, 1146 00:47:49,340 --> 00:47:51,930 now I have a shared key between me 1147 00:47:51,930 --> 00:47:55,080 and the mail server-- S is the male server over here-- 1148 00:47:55,080 --> 00:47:57,720 and this ticket a blob that I can to the mail 1149 00:47:57,720 --> 00:47:59,870 server to convince it that I'm the right guy 1150 00:47:59,870 --> 00:48:04,679 or anyone with this key is the right principle. 1151 00:48:04,679 --> 00:48:06,970 And then we can actually have an encrypted conversation 1152 00:48:06,970 --> 00:48:12,220 with the mail server using this new key KCS. 1153 00:48:12,220 --> 00:48:16,990 So what I might do as a client is-- well, 1154 00:48:16,990 --> 00:48:20,200 initially, I send some message to the mail server 1155 00:48:20,200 --> 00:48:25,980 that includes this ticket TC mail encrypted 1156 00:48:25,980 --> 00:48:28,880 with the key of the mail server. 1157 00:48:28,880 --> 00:48:31,510 And then I can actually send some message along 1158 00:48:31,510 --> 00:48:36,180 with this request that maybe says something like, well, 1159 00:48:36,180 --> 00:48:40,640 delete some message-- delete 5. 1160 00:48:40,640 --> 00:48:46,360 And I can encrypt this with KC mail. 1161 00:48:46,360 --> 00:48:49,049 Does that make sense? 1162 00:48:49,049 --> 00:48:51,340 OK, so what happens in this protocol on the mail server 1163 00:48:51,340 --> 00:48:52,060 side? 1164 00:48:52,060 --> 00:48:55,540 The mail server is going to use its secret key K mail 1165 00:48:55,540 --> 00:48:57,474 to decrypt this ticket first. 1166 00:48:57,474 --> 00:48:59,140 And then it looks inside there and finds 1167 00:48:59,140 --> 00:49:02,800 two important things-- the principal name C of who 1168 00:49:02,800 --> 00:49:07,014 is it that's talking to it in the first place and the key KCS 1169 00:49:07,014 --> 00:49:08,430 that it should be using to decrypt 1170 00:49:08,430 --> 00:49:11,155 all the subsequent traffic and authenticate it ideally 1171 00:49:11,155 --> 00:49:12,609 in Kerberos 5, at least. 1172 00:49:12,609 --> 00:49:15,150 And then you can decrypt this message and say oh, well, yeah. 1173 00:49:15,150 --> 00:49:17,370 User C is trying to delete message five. 1174 00:49:17,370 --> 00:49:19,485 So I'll run this command. 1175 00:49:19,485 --> 00:49:19,985 Make sense? 1176 00:49:19,985 --> 00:49:21,316 You had a question? 1177 00:49:21,316 --> 00:49:24,500 STUDENT: Yeah, so Kerberos initially 1178 00:49:24,500 --> 00:49:30,370 sends the TGS ticket in KCTGS. 1179 00:49:30,370 --> 00:49:32,620 Where's [INAUDIBLE]? 1180 00:49:32,620 --> 00:49:35,500 PROFESSOR: So AC, those authenticators are actually 1181 00:49:35,500 --> 00:49:37,110 generated by the client. 1182 00:49:37,110 --> 00:49:40,280 Note that the client only needs KCS 1183 00:49:40,280 --> 00:49:42,390 to generate an authenticator. 1184 00:49:42,390 --> 00:49:45,340 So the client can make these up any time it wants. 1185 00:49:45,340 --> 00:49:48,250 So the general plan for indicators or the reason 1186 00:49:48,250 --> 00:49:51,970 to use authenticators is roughly to prevent replay attack. 1187 00:49:51,970 --> 00:49:55,470 So the client, or at least in the way that the Kerberos 4 1188 00:49:55,470 --> 00:49:57,840 developers were intending it, the client, 1189 00:49:57,840 --> 00:49:59,920 every time it sends a new request , 1190 00:49:59,920 --> 00:50:02,980 it would generate a new authenticator to say OK, well, 1191 00:50:02,980 --> 00:50:03,999 this is a new request. 1192 00:50:03,999 --> 00:50:04,790 I'm issuing it now. 1193 00:50:04,790 --> 00:50:06,706 It's different from all the previous requests. 1194 00:50:06,706 --> 00:50:07,740 Go do it. 1195 00:50:07,740 --> 00:50:11,110 And the general plan was that the server 1196 00:50:11,110 --> 00:50:15,550 would keep a cache of these authenticators that 1197 00:50:15,550 --> 00:50:18,830 were sent within the last five minutes or so. 1198 00:50:18,830 --> 00:50:20,710 So if it ever sees a duplicate authenticator, 1199 00:50:20,710 --> 00:50:22,310 it says oh, that's a replay request. 1200 00:50:22,310 --> 00:50:24,130 I'm going to reject it. 1201 00:50:24,130 --> 00:50:26,350 And if it sees an authenticator that's 1202 00:50:26,350 --> 00:50:28,380 outside of a five minute boundary, 1203 00:50:28,380 --> 00:50:29,970 it doesn't have it in the cache. 1204 00:50:29,970 --> 00:50:33,220 But it will look at the time stamp in the authenticator 1205 00:50:33,220 --> 00:50:35,220 and say, well, this is a very old authenticator. 1206 00:50:35,220 --> 00:50:37,700 I'll just reject your request because it's too old. 1207 00:50:37,700 --> 00:50:39,700 Send it again if you really care. 1208 00:50:39,700 --> 00:50:42,170 So that's the general plan for indicators. 1209 00:50:42,170 --> 00:50:44,410 As with many things in Kerberos, they 1210 00:50:44,410 --> 00:50:47,160 were slightly broken-- in Kerberos 4, at least. 1211 00:50:47,160 --> 00:50:48,890 Because this authenticator actually 1212 00:50:48,890 --> 00:50:51,098 says nothing about the message you're sending, right? 1213 00:50:51,098 --> 00:50:52,022 It's some blob. 1214 00:50:52,022 --> 00:50:53,730 So the way you would use it, for example, 1215 00:50:53,730 --> 00:50:57,610 in this mail server protocol is-- or at least in Kerberos 1216 00:50:57,610 --> 00:51:00,050 4-- well, you would generate some authenticator 1217 00:51:00,050 --> 00:51:02,380 and you would be to take the authenticator 1218 00:51:02,380 --> 00:51:06,572 and you would encrypt it with also KC mail. 1219 00:51:06,572 --> 00:51:09,190 And the mail server would keep track of, well, yeah, 1220 00:51:09,190 --> 00:51:11,106 you've sent this [INAUDIBLE] indicator before. 1221 00:51:11,106 --> 00:51:12,007 No, you haven't. 1222 00:51:12,007 --> 00:51:14,340 But there's nothing here that connects the authenticator 1223 00:51:14,340 --> 00:51:15,770 to the message you are sending. 1224 00:51:15,770 --> 00:51:17,912 So for the first message, this was great. 1225 00:51:17,912 --> 00:51:19,370 But when you send a second message, 1226 00:51:19,370 --> 00:51:21,440 you're going to generate a second authenticator. 1227 00:51:21,440 --> 00:51:22,980 And someone on the network can say, oh, yeah, 1228 00:51:22,980 --> 00:51:24,310 I got your new authenticator. 1229 00:51:24,310 --> 00:51:25,740 I can take your new authenticator 1230 00:51:25,740 --> 00:51:28,130 and splice in the old delete message. 1231 00:51:28,130 --> 00:51:31,180 So I'll force you to delete the fifth message twice, 1232 00:51:31,180 --> 00:51:32,950 even though the second command meant 1233 00:51:32,950 --> 00:51:35,960 to send some other operation. 1234 00:51:35,960 --> 00:51:40,819 So Kerberos 5 gets this right where you actually 1235 00:51:40,819 --> 00:51:42,860 stick something in the authenticator that relates 1236 00:51:42,860 --> 00:51:45,100 to the command you're issuing. 1237 00:51:45,100 --> 00:51:47,724 You could do this, of course, but sort of took a while 1238 00:51:47,724 --> 00:51:49,390 for people to realize that, well, here's 1239 00:51:49,390 --> 00:51:52,800 how you should design a protocol correctly. 1240 00:51:52,800 --> 00:51:53,540 Make sense? 1241 00:51:53,540 --> 00:51:54,714 Yeah, other question. 1242 00:51:54,714 --> 00:51:55,547 STUDENT: [INAUDIBLE] 1243 00:51:58,158 --> 00:52:01,050 PROFESSOR: Ah, so the client gets case email 1244 00:52:01,050 --> 00:52:02,340 from this response. 1245 00:52:02,340 --> 00:52:05,180 So the client, when it wants to talk to the mail server, 1246 00:52:05,180 --> 00:52:08,240 it's going to ask the TGS for a ticket for the mail server. 1247 00:52:08,240 --> 00:52:12,500 And here, S is basically this mail server's principal name. 1248 00:52:12,500 --> 00:52:16,370 So when it comes back, this says S equals mail 1249 00:52:16,370 --> 00:52:19,660 and this server key S is equal to mail. 1250 00:52:19,660 --> 00:52:22,470 And this KCS is actually KC mail. 1251 00:52:25,920 --> 00:52:28,830 So this is how the client learns of the shared key 1252 00:52:28,830 --> 00:52:32,870 that it has between it and the files and the mail server here. 1253 00:52:32,870 --> 00:52:34,850 And there's a copy of it inside the ticket. 1254 00:52:34,850 --> 00:52:35,690 Question back there? 1255 00:52:35,690 --> 00:52:38,059 STUDENT: How does the mail server get KC mail? 1256 00:52:38,059 --> 00:52:38,850 PROFESSOR: Ah, yes. 1257 00:52:38,850 --> 00:52:40,980 So how does the mail server get this shared key? 1258 00:52:40,980 --> 00:52:43,010 Like, the mail server might have never heard 1259 00:52:43,010 --> 00:52:44,926 of your connection before, never heard of you. 1260 00:52:44,926 --> 00:52:47,760 Where does KC mail come from on the mail server side? 1261 00:52:47,760 --> 00:52:48,889 Yeah. 1262 00:52:48,889 --> 00:52:50,430 STUDENT: Isn't it part of the ticket? 1263 00:52:50,430 --> 00:52:51,440 PROFESSOR: Yeah, yeah, so this is the cool thing. 1264 00:52:51,440 --> 00:52:54,106 You send this ticket over to the mail server and the mail server 1265 00:52:54,106 --> 00:52:56,180 knows its own secret key K mail. 1266 00:52:56,180 --> 00:53:00,980 And it uses that to decrypt the ticket TC mail and the shared 1267 00:53:00,980 --> 00:53:03,430 key is in there along with the name of whoever 1268 00:53:03,430 --> 00:53:05,656 it is that you're sharing this key with. 1269 00:53:05,656 --> 00:53:07,780 That's how it finds out, oh, I'm talking to the guy 1270 00:53:07,780 --> 00:53:11,010 and that's the shared key we should use. 1271 00:53:11,010 --> 00:53:12,930 Makes sense? 1272 00:53:12,930 --> 00:53:15,970 All right, so that's the sort of basic plan 1273 00:53:15,970 --> 00:53:20,950 for how you use this protocol in some actual application. 1274 00:53:20,950 --> 00:53:27,490 There's-- well, there's a bunch of problems with this. 1275 00:53:27,490 --> 00:53:30,350 So Kerberos is-- it's a nice paper to read 1276 00:53:30,350 --> 00:53:32,570 but then there's all these problems these guys didn't 1277 00:53:32,570 --> 00:53:33,620 know about 30 years ago. 1278 00:53:33,620 --> 00:53:36,810 So it's sort of inevitable that there's problems 1279 00:53:36,810 --> 00:53:38,240 you have to go through. 1280 00:53:38,240 --> 00:53:41,180 So one interesting problem in the way 1281 00:53:41,180 --> 00:53:45,820 Kerberos 4 encrypted and authenticated messages 1282 00:53:45,820 --> 00:53:49,140 for applications is that they use the same key 1283 00:53:49,140 --> 00:53:52,960 for encrypting messages from the client to the server 1284 00:53:52,960 --> 00:53:56,580 as well as messages from the server back to the client. 1285 00:53:56,580 --> 00:54:01,300 So suppose that the client issues, I don't know, 1286 00:54:01,300 --> 00:54:04,110 a request to fetch a particular message. 1287 00:54:04,110 --> 00:54:08,720 So then I say, you know, fetch the message 7. 1288 00:54:08,720 --> 00:54:13,720 And I encrypt this thing with KC mail. 1289 00:54:13,720 --> 00:54:15,170 That seems all great. 1290 00:54:15,170 --> 00:54:17,590 The mail server has the shared key that's 1291 00:54:17,590 --> 00:54:19,040 going to decrypt this message. 1292 00:54:19,040 --> 00:54:23,690 And it's going to send me back the body of this email message 1293 00:54:23,690 --> 00:54:26,910 also encrypted with KC mail. 1294 00:54:26,910 --> 00:54:29,500 Does anyone see a problem with this? 1295 00:54:29,500 --> 00:54:33,180 Why is this is potentially a bad thing to do? 1296 00:54:33,180 --> 00:54:34,870 Anyone else? 1297 00:54:34,870 --> 00:54:36,421 Sure. 1298 00:54:36,421 --> 00:54:39,530 STUDENT: So there's a chapter [INAUDIBLE] 1299 00:54:39,530 --> 00:54:42,104 they can make [INAUDIBLE] look like some other things they 1300 00:54:42,104 --> 00:54:42,806 want [INAUDIBLE] 1301 00:54:42,806 --> 00:54:43,750 PROFESSOR: Yes, so those are actually 1302 00:54:43,750 --> 00:54:46,444 worrisome because I could send you any email message I want. 1303 00:54:46,444 --> 00:54:48,610 So suppose I really want to delete some message that 1304 00:54:48,610 --> 00:54:50,068 is sitting here in your inbox and I 1305 00:54:50,068 --> 00:54:51,250 don't want you to read it. 1306 00:54:51,250 --> 00:54:53,640 I know it's maybe message, I don't know, 23. 1307 00:54:53,640 --> 00:54:55,932 So I'm going to send you an email that says, delete 23. 1308 00:54:55,932 --> 00:54:56,931 You're going to read it. 1309 00:54:56,931 --> 00:54:58,800 You're going to fetch it and a response 1310 00:54:58,800 --> 00:55:00,675 is going to come from the mail server saying, 1311 00:55:00,675 --> 00:55:03,086 delete 23 encrypted with this key. 1312 00:55:03,086 --> 00:55:05,210 And so far, it's not being sent to the mail server. 1313 00:55:05,210 --> 00:55:07,126 But if I look at the network at the right time 1314 00:55:07,126 --> 00:55:09,540 and capture this packet, I can send the packet back 1315 00:55:09,540 --> 00:55:10,690 to the mail server. 1316 00:55:10,690 --> 00:55:13,900 It would look like a message saying delete 23 encrypted 1317 00:55:13,900 --> 00:55:15,067 with the right key. 1318 00:55:15,067 --> 00:55:16,900 And the mail server will say, oh yeah, sure. 1319 00:55:16,900 --> 00:55:18,441 You're trying to delete this message. 1320 00:55:18,441 --> 00:55:19,190 I'll do it. 1321 00:55:19,190 --> 00:55:21,970 So this is a bit of a problem because we 1322 00:55:21,970 --> 00:55:25,070 are allowing an adversary to confuse the mail 1323 00:55:25,070 --> 00:55:27,860 server into whether our message was generated by it 1324 00:55:27,860 --> 00:55:30,592 or was sent to it in the first place. 1325 00:55:30,592 --> 00:55:32,021 So this is quite troublesome. 1326 00:55:32,021 --> 00:55:33,520 So these are what's typically called 1327 00:55:33,520 --> 00:55:35,144 in cryptography and protocol literature 1328 00:55:35,144 --> 00:55:37,677 as reflection attacks. 1329 00:55:37,677 --> 00:55:40,260 So you have any suggestions for how we can avoid this problem? 1330 00:55:40,260 --> 00:55:40,660 Yeah. 1331 00:55:40,660 --> 00:55:42,985 STUDENT: Can't you just include a header saying its origins? 1332 00:55:42,985 --> 00:55:44,440 PROFESSOR: Yeah, so typically, you 1333 00:55:44,440 --> 00:55:46,950 want to have some very unambiguous way to state what's 1334 00:55:46,950 --> 00:55:47,900 going on. 1335 00:55:47,900 --> 00:55:50,364 One way is to have a header in every message that says, 1336 00:55:50,364 --> 00:55:52,780 this is going from the client to the server or from server 1337 00:55:52,780 --> 00:55:53,720 to the client. 1338 00:55:53,720 --> 00:55:55,860 And even better plan in practice turns out 1339 00:55:55,860 --> 00:55:57,520 to be just use two separate keys. 1340 00:55:57,520 --> 00:56:00,170 Because you might want to have a long stream of data 1341 00:56:00,170 --> 00:56:02,860 where you don't really have space for this header bit. 1342 00:56:02,860 --> 00:56:06,380 So instead, what Kerberos 5 does is every time you establish 1343 00:56:06,380 --> 00:56:09,230 a connection with some service , you actually negotiate two keys 1344 00:56:09,230 --> 00:56:10,690 instead of just one key. 1345 00:56:10,690 --> 00:56:13,530 And the first key is going to be used for encrypting stuff 1346 00:56:13,530 --> 00:56:16,780 from client to server and other from server back to the client. 1347 00:56:16,780 --> 00:56:21,010 So that seems like a much better way to do it in practice. 1348 00:56:21,010 --> 00:56:24,220 Make sense? 1349 00:56:24,220 --> 00:56:30,750 All right, so I guess let's now talk a little bit 1350 00:56:30,750 --> 00:56:33,780 about what happens with KDC. 1351 00:56:33,780 --> 00:56:38,870 So the Kerberos server is pretty important to the system. 1352 00:56:38,870 --> 00:56:42,000 But what happens if this KDC goes down? 1353 00:56:42,000 --> 00:56:44,360 So how bad is it to our system. 1354 00:56:44,360 --> 00:56:47,730 Like, in Athena, suppose if KDC crashes, 1355 00:56:47,730 --> 00:56:49,330 does this affect your life? 1356 00:56:49,330 --> 00:56:50,514 Well, if you use Athena. 1357 00:56:50,514 --> 00:56:52,097 STUDENT: Is that why you can't log in? 1358 00:56:52,097 --> 00:56:53,822 PROFESSOR: Yeah, so you can't log in. 1359 00:56:53,822 --> 00:56:56,030 I guess the other thing is you also can't get tickets 1360 00:56:56,030 --> 00:56:58,010 to new things as well. 1361 00:56:58,010 --> 00:57:00,780 But kind of the cool thing is that the KDC is largely 1362 00:57:00,780 --> 00:57:02,820 off the critical path for existing connection. 1363 00:57:02,820 --> 00:57:04,312 So no data passes through the KDC. 1364 00:57:04,312 --> 00:57:06,270 And if you already have a ticket for something, 1365 00:57:06,270 --> 00:57:07,853 you can keep using it and keep logging 1366 00:57:07,853 --> 00:57:10,220 into some service over the network. 1367 00:57:10,220 --> 00:57:13,056 So in that way, it's actually quite nicely cacheable. 1368 00:57:13,056 --> 00:57:14,680 I guess the other nice thing these guys 1369 00:57:14,680 --> 00:57:17,430 do is they actually have a way of replicating 1370 00:57:17,430 --> 00:57:18,880 the KDC potentially. 1371 00:57:18,880 --> 00:57:21,140 So they have one master Kerberos server 1372 00:57:21,140 --> 00:57:25,800 that stores the sort of primary copy of this whole database. 1373 00:57:25,800 --> 00:57:29,220 And then they can have read only replicas that 1374 00:57:29,220 --> 00:57:30,560 hold a copy of this database. 1375 00:57:30,560 --> 00:57:32,080 They don't allow any updates to this 1376 00:57:32,080 --> 00:57:35,270 like registering users or updating keys. 1377 00:57:35,270 --> 00:57:39,600 But they do allow responding to login and TJS requests. 1378 00:57:39,600 --> 00:57:43,030 So this way, these backup clones of this Kerberos database 1379 00:57:43,030 --> 00:57:45,860 allow you to keep logging in and keep talking to services 1380 00:57:45,860 --> 00:57:49,850 even if the master crashed and hopefully 1381 00:57:49,850 --> 00:57:53,590 make it possible to upgrade to master without breaking 1382 00:57:53,590 --> 00:57:56,060 everything at the same time. 1383 00:57:56,060 --> 00:57:56,640 Makes sense? 1384 00:57:56,640 --> 00:57:56,900 Any questions? 1385 00:57:56,900 --> 00:57:57,200 Yeah. 1386 00:57:57,200 --> 00:57:58,741 STUDENT: How hard is it to compromise 1387 00:57:58,741 --> 00:58:01,292 the KDC server and [INAUDIBLE]? 1388 00:58:01,292 --> 00:58:03,560 PROFESSOR: Well, yes, this is a huge sort 1389 00:58:03,560 --> 00:58:05,852 of target for any system that runs Kerberos. 1390 00:58:05,852 --> 00:58:07,310 Because if you compromise this guy, 1391 00:58:07,310 --> 00:58:09,350 you're in complete control of the system. 1392 00:58:09,350 --> 00:58:12,620 You can mint tickets for any service you want, 1393 00:58:12,620 --> 00:58:15,100 pretending to be client you want. 1394 00:58:15,100 --> 00:58:16,600 So this is pretty bad. 1395 00:58:16,600 --> 00:58:18,654 So you really want to keep this guy secure. 1396 00:58:18,654 --> 00:58:20,070 Now, how hard is it to compromise? 1397 00:58:20,070 --> 00:58:21,600 Well, ideally, it's hard. 1398 00:58:21,600 --> 00:58:25,450 And I don't know of any instances 1399 00:58:25,450 --> 00:58:29,890 where the MIT KDC has actually been compromised in, I guess, 1400 00:58:29,890 --> 00:58:31,700 20 years or so. 1401 00:58:31,700 --> 00:58:34,910 So it's , I think, possible to run this reasonably security. 1402 00:58:34,910 --> 00:58:37,070 But presumably, the things you would worry about 1403 00:58:37,070 --> 00:58:40,440 are just software implementation security 1404 00:58:40,440 --> 00:58:43,010 of the things that's listening on these two services, right? 1405 00:58:43,010 --> 00:58:44,990 So if there's buffer overflows on this guys 1406 00:58:44,990 --> 00:58:48,850 or some other vulnerability like that, that's really bad. 1407 00:58:48,850 --> 00:58:52,270 Or if there's an SSH server running on the Kerberos KDC 1408 00:58:52,270 --> 00:58:55,430 and someone guesses the root password on that SSH server, 1409 00:58:55,430 --> 00:58:57,860 they'll just log in and copy the database over. 1410 00:58:57,860 --> 00:59:00,110 So I think you really want to be careful in minimizing 1411 00:59:00,110 --> 00:59:01,151 the attack surface there. 1412 00:59:01,151 --> 00:59:04,040 Maybe be very careful writing the KDC code. 1413 00:59:04,040 --> 00:59:06,300 Don't allow you to log into it directly. 1414 00:59:06,300 --> 00:59:11,060 Maybe you even worry about physical security, et cetera. 1415 00:59:11,060 --> 00:59:11,690 Absolutely. 1416 00:59:11,690 --> 00:59:14,180 Luckily, this is actually one of the few places 1417 00:59:14,180 --> 00:59:16,210 where you have to be super paranoid, though. 1418 00:59:16,210 --> 00:59:19,020 Right, so the servers, unlike in some other systems 1419 00:59:19,020 --> 00:59:20,940 that do trust all the machines, the servers 1420 00:59:20,940 --> 00:59:22,770 are actually not that important. 1421 00:59:22,770 --> 00:59:24,410 They of course store some data. 1422 00:59:24,410 --> 00:59:28,540 But if someone compromises a mail server or a print server, 1423 00:59:28,540 --> 00:59:30,337 you can probably recover reasonably well. 1424 00:59:30,337 --> 00:59:32,170 So actually, here's an interesting question. 1425 00:59:32,170 --> 00:59:34,253 Like, suppose someone compromised the mail server. 1426 00:59:34,253 --> 00:59:37,156 What should you do to recover from this attack? 1427 00:59:37,156 --> 00:59:38,530 Like, if someone stole your mail, 1428 00:59:38,530 --> 00:59:39,988 I guess that's kind of unfortunate. 1429 00:59:39,988 --> 00:59:42,710 But what do you do so that the attacker doesn't keep accessing 1430 00:59:42,710 --> 00:59:44,150 your mail in the future? 1431 00:59:44,150 --> 00:59:44,660 Yeah. 1432 00:59:44,660 --> 00:59:45,844 STUDENT: [INAUDIBLE] 1433 00:59:45,844 --> 00:59:47,510 PROFESSOR: Yeah, so in Kerberos, there's 1434 00:59:47,510 --> 00:59:49,830 no sort of revoke operation. 1435 00:59:49,830 --> 00:59:51,350 But what you could do is you could 1436 00:59:51,350 --> 00:59:53,690 change generate a new key for the mail server 1437 00:59:53,690 --> 00:59:56,000 and stick it in this database over here. 1438 00:59:56,000 --> 00:59:59,490 And then you install a new mail server, give it the new key, 1439 00:59:59,490 --> 01:00:02,880 and then some attacker that has the mail server's old key 1440 01:00:02,880 --> 01:00:06,200 has no way of-- like, no influence at all on this mail 1441 01:00:06,200 --> 01:00:08,167 server now, right? 1442 01:00:08,167 --> 01:00:10,750 On the other hand, suppose you didn't change the mail server's 1443 01:00:10,750 --> 01:00:13,220 key, K mail. 1444 01:00:13,220 --> 01:00:14,726 How that is that? 1445 01:00:14,726 --> 01:00:17,292 STUDENT: [INAUDIBLE] fine. 1446 01:00:17,292 --> 01:00:19,500 PROFESSOR: OK, so suppose you didn't change the mail. 1447 01:00:19,500 --> 01:00:21,125 You, like, install the new mail server. 1448 01:00:21,125 --> 01:00:23,200 You patch whatever bug that hacker exploited. 1449 01:00:23,200 --> 01:00:25,130 But it still has the same key K mail. 1450 01:00:25,130 --> 01:00:28,172 And maybe it's taken a day so all the tickets are expired. 1451 01:00:28,172 --> 01:00:30,380 Can that hacker do anything interesting in the system 1452 01:00:30,380 --> 01:00:30,610 anymore? 1453 01:00:30,610 --> 01:00:31,110 Yeah. 1454 01:00:31,110 --> 01:00:33,662 STUDENT: [INAUDIBLE] 1455 01:00:33,662 --> 01:00:36,245 PROFESSOR: Yeah, OK, so you give the new mail server the old K 1456 01:00:36,245 --> 01:00:37,960 mail. 1457 01:00:37,960 --> 01:00:39,711 Is that bad? 1458 01:00:39,711 --> 01:00:40,210 Yeah. 1459 01:00:40,210 --> 01:00:41,536 STUDENT: This is-- 1460 01:00:43,594 --> 01:00:44,260 PROFESSOR: Sure. 1461 01:00:44,260 --> 01:00:48,571 STUDENT: [INAUDIBLE] mail server. 1462 01:00:48,571 --> 01:00:51,566 And [INAUDIBLE] mail server because you can 1463 01:00:51,566 --> 01:00:52,840 encrypt that initial ticket. 1464 01:00:52,840 --> 01:00:53,130 PROFESSOR: Right. 1465 01:00:53,130 --> 01:00:54,780 So K mail is actually super important. 1466 01:00:54,780 --> 01:00:57,240 And, OK, so you're saying you can decrypt all the things 1467 01:00:57,240 --> 01:00:58,462 going on to the mail server. 1468 01:00:58,462 --> 01:01:00,670 So suppose the client now connects to the mail server 1469 01:01:00,670 --> 01:01:02,060 after it's been fixed up. 1470 01:01:02,060 --> 01:01:03,890 But the attacker still knows K mail 1471 01:01:03,890 --> 01:01:05,850 from the last time they compromised the system. 1472 01:01:05,850 --> 01:01:08,070 They can now decrypt this ticket k mail 1473 01:01:08,070 --> 01:01:11,382 and they can now look inside the ticket to get the session key 1474 01:01:11,382 --> 01:01:13,590 and they can use that to decrypt all the messages you 1475 01:01:13,590 --> 01:01:15,930 send, all the responses you get back, and so on. 1476 01:01:15,930 --> 01:01:18,950 So it's pretty important to change this key K mail. 1477 01:01:18,950 --> 01:01:21,170 And in many ways, it's actually even worse 1478 01:01:21,170 --> 01:01:22,700 than just looking at the traffic. 1479 01:01:22,700 --> 01:01:26,440 Because if the attacker know this key K mail, 1480 01:01:26,440 --> 01:01:29,180 they can synthesize new tickets for the mail server 1481 01:01:29,180 --> 01:01:31,100 without talking to the key DC. 1482 01:01:31,100 --> 01:01:32,710 So suppose that I know K mail and I 1483 01:01:32,710 --> 01:01:35,100 want to read your mail from the mail server. 1484 01:01:35,100 --> 01:01:36,430 I'll just make up this ticket. 1485 01:01:36,430 --> 01:01:39,030 I'll plop down all those five fields in the right order. 1486 01:01:39,030 --> 01:01:40,950 I'll generate a new key. 1487 01:01:40,950 --> 01:01:42,280 I'll encrypt it with K mail. 1488 01:01:42,280 --> 01:01:45,072 It'll look like the real thing generated by the KDC. 1489 01:01:45,072 --> 01:01:46,780 And I'll just connect to the mail server. 1490 01:01:46,780 --> 01:01:47,450 And it'll decrypt it. 1491 01:01:47,450 --> 01:01:49,890 It'll decrypt correctly and then it'll think, oh, yeah, 1492 01:01:49,890 --> 01:01:52,980 this is some particular user. 1493 01:01:52,980 --> 01:01:55,480 And you can read all their mail and you know the shared key 1494 01:01:55,480 --> 01:01:56,590 and so on. 1495 01:01:56,590 --> 01:01:59,870 So it's critically important too that no one knows 1496 01:01:59,870 --> 01:02:01,770 the secret key of a service. 1497 01:02:01,770 --> 01:02:04,120 Because otherwise, not only is the traffic 1498 01:02:04,120 --> 01:02:06,330 to the service decryptable and observable, 1499 01:02:06,330 --> 01:02:10,410 but also you could impersonate anyone to that service. 1500 01:02:10,410 --> 01:02:13,730 So this is actually all pretty important in Kerberos. 1501 01:02:13,730 --> 01:02:15,320 Makes sense? 1502 01:02:15,320 --> 01:02:17,146 Any questions? 1503 01:02:17,146 --> 01:02:18,118 Yeah. 1504 01:02:18,118 --> 01:02:20,548 STUDENT: So if the attacker has to [INAUDIBLE], 1505 01:02:20,548 --> 01:02:24,436 what's stopping him from changing the [INAUDIBLE] key 1506 01:02:24,436 --> 01:02:25,785 [INAUDIBLE]? 1507 01:02:25,785 --> 01:02:28,160 PROFESSOR: Yeah, so presumably, how you'd recover-- like, 1508 01:02:28,160 --> 01:02:30,380 ISNT would, like, call up the guy that runs this KDC 1509 01:02:30,380 --> 01:02:32,570 and say, oh man, our mail server got compromised. 1510 01:02:32,570 --> 01:02:34,820 Why don't you go and, like, delete this key from there 1511 01:02:34,820 --> 01:02:36,289 and put in this new key instead? 1512 01:02:36,289 --> 01:02:38,330 So you'd probably want to have some out of bounds 1513 01:02:38,330 --> 01:02:41,570 mechanism for proving that you're really the mail server. 1514 01:02:41,570 --> 01:02:43,434 Because we'll look at a second on how do 1515 01:02:43,434 --> 01:02:45,600 you change keys-- like a password changing protocol, 1516 01:02:45,600 --> 01:02:46,410 for example. 1517 01:02:46,410 --> 01:02:49,410 And you can in general change passwords in Kerberos. 1518 01:02:49,410 --> 01:02:51,020 So if you know the old password, you 1519 01:02:51,020 --> 01:02:53,920 can change the user's password to a new password here. 1520 01:02:53,920 --> 01:02:56,702 So in order to recover, you probably-- like the attacker, 1521 01:02:56,702 --> 01:02:58,910 might get your key mail, change it to something else. 1522 01:02:58,910 --> 01:03:01,750 Someone with ISNT basically has to go to the Accounts office 1523 01:03:01,750 --> 01:03:04,129 and say, hey, we're hear at ISNT. 1524 01:03:04,129 --> 01:03:06,420 Could you please change the password of the mail server 1525 01:03:06,420 --> 01:03:06,920 for us? 1526 01:03:06,920 --> 01:03:08,878 And they're going to generate some new password 1527 01:03:08,878 --> 01:03:10,320 the attacker doesn't know. 1528 01:03:10,320 --> 01:03:14,230 So yeah, otherwise, if the attacker knows this key K mail, 1529 01:03:14,230 --> 01:03:16,480 there's nothing differentiating the attacker from you, 1530 01:03:16,480 --> 01:03:18,240 from the real mail server operator. 1531 01:03:18,240 --> 01:03:20,976 In fact, the attacker probably changed the key so now they 1532 01:03:20,976 --> 01:03:22,350 know the new thing and you don't. 1533 01:03:22,350 --> 01:03:24,440 It's like you're not on the mail server anymore. 1534 01:03:24,440 --> 01:03:27,210 So absolutely, you need some out of band protocol 1535 01:03:27,210 --> 01:03:31,460 for initially registering principles in the database 1536 01:03:31,460 --> 01:03:34,360 and for changing keys if you forget your password or someone 1537 01:03:34,360 --> 01:03:37,400 changes for you and you lose it as well. 1538 01:03:37,400 --> 01:03:40,020 So there's someone at MIT or there's 1539 01:03:40,020 --> 01:03:42,950 a group of people at MIT that help users 1540 01:03:42,950 --> 01:03:45,000 register for accounts and change their passwords 1541 01:03:45,000 --> 01:03:48,440 by, you know, you present your MIT ID and say, oh, well, OK. 1542 01:03:48,440 --> 01:03:49,840 Well, whatever happened, we'll be 1543 01:03:49,840 --> 01:03:51,740 able to change your key for you then. 1544 01:03:51,740 --> 01:03:53,890 Make sense? 1545 01:03:53,890 --> 01:03:55,390 So it's pretty important, of course, 1546 01:03:55,390 --> 01:03:57,990 to do that right so if the person that 1547 01:03:57,990 --> 01:04:01,310 is allowing password resets does the wrong thing when checking 1548 01:04:01,310 --> 01:04:04,140 your MIT ID, you'll be able to compromise the system as well, 1549 01:04:04,140 --> 01:04:04,280 right? 1550 01:04:04,280 --> 01:04:06,321 So they are sort of part of the trusted computing 1551 01:04:06,321 --> 01:04:07,405 base in Kerberos, right? 1552 01:04:07,405 --> 01:04:09,530 Like, anyone that can go and muck with the database 1553 01:04:09,530 --> 01:04:13,990 is pretty important for security here. 1554 01:04:13,990 --> 01:04:17,149 All right, so let's look at another sort of interesting use 1555 01:04:17,149 --> 01:04:17,940 of Kerberos, right? 1556 01:04:17,940 --> 01:04:22,750 So you could use Kerberos to try to log into some remote machine 1557 01:04:22,750 --> 01:04:24,329 over SSH. 1558 01:04:24,329 --> 01:04:26,620 And the way this would work is, of course, very similar 1559 01:04:26,620 --> 01:04:27,340 to a mail server. 1560 01:04:27,340 --> 01:04:28,881 You'd get a ticket for the SSH server 1561 01:04:28,881 --> 01:04:32,080 and you'd send the ticket along with your SSH connection. 1562 01:04:32,080 --> 01:04:34,860 But what if you're SSHing into Athena dot dial-up 1563 01:04:34,860 --> 01:04:37,210 and you don't have a Kerberos client on your machine? 1564 01:04:37,210 --> 01:04:39,270 You just want to log into Athena dot dial-up 1565 01:04:39,270 --> 01:04:42,360 with your regular password. 1566 01:04:42,360 --> 01:04:44,840 So how would Athena dial-up authenticate you, then, 1567 01:04:44,840 --> 01:04:48,060 if you're just plugging into this machine with a password? 1568 01:04:48,060 --> 01:04:50,120 But you have no password for Athena dot dial-up. 1569 01:04:50,120 --> 01:04:51,772 It's on a Kerberos server. 1570 01:04:51,772 --> 01:04:53,230 So which should the dial-up machine 1571 01:04:53,230 --> 01:04:54,880 do when you log into it with a password? 1572 01:04:54,880 --> 01:04:55,250 Yeah. 1573 01:04:55,250 --> 01:04:56,990 STUDENT: You can access the [INAUDIBLE]. 1574 01:04:56,990 --> 01:04:58,770 PROFESSOR: Yeah, so the dial-up is then 1575 01:04:58,770 --> 01:05:01,200 going to basically play the same protocol logging you in. 1576 01:05:01,200 --> 01:05:03,850 So it's going to send a request. 1577 01:05:03,850 --> 01:05:04,600 This thing, right? 1578 01:05:04,600 --> 01:05:07,960 It's going to send a request to the Kerberos service asking, 1579 01:05:07,960 --> 01:05:11,550 give me a ticket for, I don't know, this user Alice. 1580 01:05:11,550 --> 01:05:15,050 And in response, it's going to get back this reply encrypted 1581 01:05:15,050 --> 01:05:16,280 with Alice's password. 1582 01:05:16,280 --> 01:05:19,250 And then it's going to try the password you just applied 1583 01:05:19,250 --> 01:05:21,050 and see if it decrypts correctly. 1584 01:05:21,050 --> 01:05:22,650 And if it decrypts correctly, it's 1585 01:05:22,650 --> 01:05:25,270 going to let you log in, right? 1586 01:05:25,270 --> 01:05:25,770 Yeah. 1587 01:05:25,770 --> 01:05:27,228 STUDENT: You don't even really have 1588 01:05:27,228 --> 01:05:30,370 to send your key to the SSH server. 1589 01:05:30,370 --> 01:05:32,840 Because it could relay this back-- 1590 01:05:32,840 --> 01:05:35,230 the dot encrypted thing with KC. 1591 01:05:35,230 --> 01:05:38,948 It could relay that back to the user over the SSH connection. 1592 01:05:38,948 --> 01:05:40,380 PROFESSOR: Potentially, yeah. 1593 01:05:40,380 --> 01:05:42,560 Right, so this requires some fancy SSH client 1594 01:05:42,560 --> 01:05:43,810 that you might not have. 1595 01:05:43,810 --> 01:05:45,400 But-- so yeah, absolutely right. 1596 01:05:45,400 --> 01:05:46,790 If you want to do this right, you 1597 01:05:46,790 --> 01:05:49,081 probably want to have a Kerberos client on your machine 1598 01:05:49,081 --> 01:05:51,370 and get a ticket yourself or maybe 1599 01:05:51,370 --> 01:05:53,460 proxy it somehow through the SSH server 1600 01:05:53,460 --> 01:05:56,104 but not allow the SSH server to have your key. 1601 01:05:56,104 --> 01:05:57,270 That's probably a good plan. 1602 01:05:57,270 --> 01:06:01,518 STUDENT: [INAUDIBLE] just, the server could get 1603 01:06:01,518 --> 01:06:02,940 through this wall [INAUDIBLE] 1604 01:06:02,940 --> 01:06:03,108 PROFESSOR: That's right. 1605 01:06:03,108 --> 01:06:05,165 Then you might decrypt it and send back. 1606 01:06:05,165 --> 01:06:07,290 OK, but in either case, right, all we're doing here 1607 01:06:07,290 --> 01:06:11,279 is someone is going to try to decrypt this blob with KC. 1608 01:06:11,279 --> 01:06:13,320 And then the server is going to get this resolved 1609 01:06:13,320 --> 01:06:14,403 and see if it looks right. 1610 01:06:14,403 --> 01:06:16,476 It's going to allow you in. 1611 01:06:16,476 --> 01:06:19,219 Seem like a good plan? 1612 01:06:19,219 --> 01:06:21,760 So, turns out this is actually a fairly dangerous thing to do 1613 01:06:21,760 --> 01:06:24,315 and allows you to potentially log into the SSH server 1614 01:06:24,315 --> 01:06:26,020 as anyone. 1615 01:06:26,020 --> 01:06:28,650 And the reason is that previously, 1616 01:06:28,650 --> 01:06:31,930 when we were talking about a client trying to log in, 1617 01:06:31,930 --> 01:06:33,549 the client basically knew that it 1618 01:06:33,549 --> 01:06:35,340 was trying to supply a legitimate password, 1619 01:06:35,340 --> 01:06:37,780 it was getting a reply from the right Kerberos server, 1620 01:06:37,780 --> 01:06:40,870 and if it can decrypt it, then probably the password works out 1621 01:06:40,870 --> 01:06:42,010 correctly. 1622 01:06:42,010 --> 01:06:44,650 However, there's nothing here in this protocol that 1623 01:06:44,650 --> 01:06:47,500 authenticates the fact that this reply is coming 1624 01:06:47,500 --> 01:06:50,670 from the right Kerberos server. 1625 01:06:50,670 --> 01:06:57,470 So if I try to log into a machine by typing in a password 1626 01:06:57,470 --> 01:07:00,080 and the machine sends out this request 1627 01:07:00,080 --> 01:07:02,700 and some response comes back that seems 1628 01:07:02,700 --> 01:07:06,170 to be encrypted with the password I typed in, 1629 01:07:06,170 --> 01:07:09,750 this response might not be from the Kerberos server. 1630 01:07:09,750 --> 01:07:12,090 So suppose I have some machine I want to log into. 1631 01:07:12,090 --> 01:07:14,510 I type a password X into it. 1632 01:07:14,510 --> 01:07:16,960 And then the machine sends out this response. 1633 01:07:16,960 --> 01:07:19,280 And before the Kerberos server can respond back 1634 01:07:19,280 --> 01:07:23,210 with the real reply, I'll send my own reply that 1635 01:07:23,210 --> 01:07:27,640 looks like this real response encrypted with my password X. 1636 01:07:27,640 --> 01:07:31,540 And the workstation to which I try to log in or the SSH server 1637 01:07:31,540 --> 01:07:33,780 is going to decrypt it with my fake password. 1638 01:07:33,780 --> 01:07:36,180 It's going to look OK because this response was 1639 01:07:36,180 --> 01:07:39,880 generated by me rather than the real Kerberos server. 1640 01:07:39,880 --> 01:07:45,395 And you'll be able to log in This make sense? 1641 01:07:45,395 --> 01:07:46,270 Why does this happen? 1642 01:07:51,704 --> 01:07:52,692 Yeah. 1643 01:07:52,692 --> 01:07:54,668 STUDENT: [INAUDIBLE] there's no authentication 1644 01:07:54,668 --> 01:07:56,660 from the Kerberos server [INAUDIBLE] 1645 01:07:56,660 --> 01:07:57,550 PROFESSOR: Right, yeah, so there's 1646 01:07:57,550 --> 01:07:59,940 nothing really here that's tying this to the real Kerberos 1647 01:07:59,940 --> 01:08:00,440 server. 1648 01:08:00,440 --> 01:08:04,850 So the way that Kerberos fixes this 1649 01:08:04,850 --> 01:08:08,300 for remotely accessible machines like Athena 1650 01:08:08,300 --> 01:08:11,100 dot dial-up is that the dial-ups themselves 1651 01:08:11,100 --> 01:08:14,700 have some sort of a secret key that they share with the KDC. 1652 01:08:14,700 --> 01:08:16,720 So in order to log you in into a dial-up 1653 01:08:16,720 --> 01:08:19,210 or to any workstation that really cares about checking 1654 01:08:19,210 --> 01:08:21,159 whether you are really the right user, 1655 01:08:21,159 --> 01:08:22,700 it's actually going to do two things. 1656 01:08:22,700 --> 01:08:26,229 It's going to first log you into Kerberos like this. 1657 01:08:26,229 --> 01:08:28,880 But then just because this reply decrypts correctly, 1658 01:08:28,880 --> 01:08:30,439 it's not going to trust that. 1659 01:08:30,439 --> 01:08:33,090 It's going to try to get a service 1660 01:08:33,090 --> 01:08:35,910 ticket for itself using TGS. 1661 01:08:35,910 --> 01:08:39,899 So the dial-up machine here has its own secret key. 1662 01:08:39,899 --> 01:08:42,229 And it logs you in with this round one. 1663 01:08:42,229 --> 01:08:45,569 Then it talks to TGS saying, oh, please give me 1664 01:08:45,569 --> 01:08:48,740 a service ticket for my own principle, 1665 01:08:48,740 --> 01:08:51,359 from the dial-up principle, for this client. 1666 01:08:51,359 --> 01:08:52,880 Then it gets the response back. 1667 01:08:52,880 --> 01:08:55,479 And then it checks if it can decrypt the response correctly. 1668 01:08:55,479 --> 01:08:59,220 Because it knows the dial-up key for this KS. 1669 01:08:59,220 --> 01:09:01,390 And if this decrpyts, that it knows, oh yeah, 1670 01:09:01,390 --> 01:09:03,390 I must have talked to the right Kerberos server. 1671 01:09:03,390 --> 01:09:04,973 Because only the right Kerberos server 1672 01:09:04,973 --> 01:09:07,200 would have sent me this second round ticket encrypted 1673 01:09:07,200 --> 01:09:10,665 with my secret key K dial-up. 1674 01:09:10,665 --> 01:09:12,779 So this is actually pretty important. 1675 01:09:12,779 --> 01:09:14,744 And typically, Athena workstations 1676 01:09:14,744 --> 01:09:17,160 don't do this extra step because Athena workstations don't 1677 01:09:17,160 --> 01:09:19,100 have any secret key stored on them 1678 01:09:19,100 --> 01:09:21,494 that's shared with the KDC. 1679 01:09:21,494 --> 01:09:23,535 Why is this OK for Athena workstations to let you 1680 01:09:23,535 --> 01:09:26,535 log in in this one round trip and not for dial-ups? 1681 01:09:26,535 --> 01:09:27,035 Yeah. 1682 01:09:27,035 --> 01:09:29,076 STUDENT: If you don't have access to any services 1683 01:09:29,076 --> 01:09:31,035 because the attacker couldn't forge the ticket. 1684 01:09:31,035 --> 01:09:32,284 PROFESSOR: That's right, yeah. 1685 01:09:32,284 --> 01:09:35,060 So there's nothing interesting on the dial-up machine itself-- 1686 01:09:35,060 --> 01:09:36,510 sorry, on the workstation itself. 1687 01:09:36,510 --> 01:09:39,660 So workstation, whenever-- you have root access on it anyway. 1688 01:09:39,660 --> 01:09:42,930 So if you log into it with a fake password, who cares? 1689 01:09:42,930 --> 01:09:45,010 It's not like you'll be able to do anything else 1690 01:09:45,010 --> 01:09:46,519 outside of your workstation. 1691 01:09:46,519 --> 01:09:48,810 Whereas on a dial-up, things are much more interesting. 1692 01:09:48,810 --> 01:09:50,851 It might be that you have other processes running 1693 01:09:50,851 --> 01:09:52,920 on the dial-up from other login sessions. 1694 01:09:52,920 --> 01:09:56,440 And there, the fact that you log in with a particular Unix UID 1695 01:09:56,440 --> 01:09:58,070 is actually pretty important. 1696 01:09:58,070 --> 01:10:00,230 And there, they really want to authenticate 1697 01:10:00,230 --> 01:10:02,360 that you are the right entity. 1698 01:10:02,360 --> 01:10:05,780 So that's why they do this sort of 2-step process for logging 1699 01:10:05,780 --> 01:10:09,140 into some shared time-sharing machine. 1700 01:10:09,140 --> 01:10:12,020 Make sense? 1701 01:10:12,020 --> 01:10:15,230 All right, so the last thing I want to talk about 1702 01:10:15,230 --> 01:10:16,840 is how do we change keys. 1703 01:10:16,840 --> 01:10:19,230 So we sort of talked about it briefly here with the idea 1704 01:10:19,230 --> 01:10:22,029 that the mail server's key might get compromised. 1705 01:10:22,029 --> 01:10:23,570 But as a user, you probably also want 1706 01:10:23,570 --> 01:10:26,080 to change passwords as well. 1707 01:10:26,080 --> 01:10:28,861 Like, maybe you're thinking, oh, that password is not so great 1708 01:10:28,861 --> 01:10:29,360 anymore. 1709 01:10:29,360 --> 01:10:31,390 Maybe I accidentally wrote it on a piece of paper and someone 1710 01:10:31,390 --> 01:10:32,280 looked at it. 1711 01:10:32,280 --> 01:10:34,100 So you probably want to change it. 1712 01:10:34,100 --> 01:10:36,120 So the way this works is actually 1713 01:10:36,120 --> 01:10:38,150 at some level fairly straightforward. 1714 01:10:38,150 --> 01:10:41,440 So there's an extra interface to this Kerberos server. 1715 01:10:41,440 --> 01:10:43,570 In addition to Kerberos and TGS, there's 1716 01:10:43,570 --> 01:10:45,280 this extra service called kpassword. 1717 01:10:48,720 --> 01:10:52,690 And the service lets you change your password. 1718 01:10:52,690 --> 01:10:55,744 And the way it works is you get a ticket for this service 1719 01:10:55,744 --> 01:10:57,660 very much like you'd get a ticket for the mail 1720 01:10:57,660 --> 01:10:59,750 server or any other service. 1721 01:10:59,750 --> 01:11:01,592 And then you send your new password 1722 01:11:01,592 --> 01:11:03,800 to this kpassword service encrypted with your session 1723 01:11:03,800 --> 01:11:04,910 key. 1724 01:11:04,910 --> 01:11:08,900 And then if everything checks out, your key in the database 1725 01:11:08,900 --> 01:11:12,330 is going to be updated to the new key. 1726 01:11:12,330 --> 01:11:13,070 Question. 1727 01:11:13,070 --> 01:11:14,736 STUDENT: [INAUDIBLE] if there was, like, 1728 01:11:14,736 --> 01:11:17,339 no [INAUDIBLE] they wanted to have them use a [INAUDIBLE] had 1729 01:11:17,339 --> 01:11:18,130 to go through this. 1730 01:11:18,130 --> 01:11:18,590 PROFESSOR: That's right. 1731 01:11:18,590 --> 01:11:19,170 OK, yeah, OK. 1732 01:11:19,170 --> 01:11:20,169 So this is a good point. 1733 01:11:20,169 --> 01:11:22,595 So for changing your password, remember 1734 01:11:22,595 --> 01:11:24,720 that we have this whole goal that if someone steals 1735 01:11:24,720 --> 01:11:28,270 your ticket, it shouldn't be good enough to completely take 1736 01:11:28,270 --> 01:11:29,750 over your account. 1737 01:11:29,750 --> 01:11:32,849 So for this reason, the key password service actually 1738 01:11:32,849 --> 01:11:34,140 doesn't accept just any ticket. 1739 01:11:34,140 --> 01:11:36,900 It accepts a ticket that you initially get from the Kerberos 1740 01:11:36,900 --> 01:11:39,740 service with your KC. 1741 01:11:39,740 --> 01:11:42,430 So the way this actually works is that inside of every ticket, 1742 01:11:42,430 --> 01:11:44,763 in addition to all the stuff I showed you there, there's 1743 01:11:44,763 --> 01:11:47,550 an extra bit that tells you which of these two things 1744 01:11:47,550 --> 01:11:48,836 gave you the ticket. 1745 01:11:48,836 --> 01:11:50,960 So if you get the ticket from this Kerberos server, 1746 01:11:50,960 --> 01:11:52,082 the bit has one. 1747 01:11:52,082 --> 01:11:54,540 If you get the ticket from the TGS server, the bit is zero, 1748 01:11:54,540 --> 01:11:55,500 let's say. 1749 01:11:55,500 --> 01:11:58,160 And then the kpassword service, in addition to everything 1750 01:11:58,160 --> 01:12:00,037 that any mail server or file server would do, 1751 01:12:00,037 --> 01:12:01,620 it also looks at the bit on the ticket 1752 01:12:01,620 --> 01:12:04,210 and says, well, if you got it from Kerberos, that's good. 1753 01:12:04,210 --> 01:12:05,700 If you got it from TGS, that means 1754 01:12:05,700 --> 01:12:08,020 that maybe you stole someone's ticket 1755 01:12:08,020 --> 01:12:10,000 and you didn't know their password right away. 1756 01:12:10,000 --> 01:12:11,880 So I'm not going to accept this. 1757 01:12:11,880 --> 01:12:14,540 So this is how a key password ensures that you can only 1758 01:12:14,540 --> 01:12:17,637 change the password if you just knew the password immediately 1759 01:12:17,637 --> 01:12:18,220 prior to this. 1760 01:12:18,220 --> 01:12:21,980 So you never actually supply the old password to kpassword. 1761 01:12:21,980 --> 01:12:24,172 You supply that to-- well, you supply that in order 1762 01:12:24,172 --> 01:12:25,880 to decrypt the response from the Kerberos 1763 01:12:25,880 --> 01:12:28,940 server for the kpassword password principal. 1764 01:12:28,940 --> 01:12:31,390 Makes sense? 1765 01:12:31,390 --> 01:12:36,670 All right, so let's just actually spell out 1766 01:12:36,670 --> 01:12:40,350 the interactions with the key password service 1767 01:12:40,350 --> 01:12:43,320 because there'll be something a little bit interesting there. 1768 01:12:43,320 --> 01:12:48,480 So when you're going to change your password, what 1769 01:12:48,480 --> 01:12:51,400 the client is going to do is, of course, 1770 01:12:51,400 --> 01:12:54,990 obtain this initial ticket from Kerberos. 1771 01:12:54,990 --> 01:12:58,890 So it sends a message to the Kerberos service saying here 1772 01:12:58,890 --> 01:13:03,760 is my client ID and I want to talk to the kpassword service. 1773 01:13:03,760 --> 01:13:07,220 And the Kerberos server is going to send a response back 1774 01:13:07,220 --> 01:13:09,690 including the ticket between the client 1775 01:13:09,690 --> 01:13:16,370 and the kpassword service encrypted with a key of kpass 1776 01:13:16,370 --> 01:13:21,801 and the shared key between KC and kpass. 1777 01:13:21,801 --> 01:13:22,300 Makes sense? 1778 01:13:22,300 --> 01:13:25,995 This is exactly this thing up here encrypted with KC. 1779 01:13:25,995 --> 01:13:26,560 Makes sense? 1780 01:13:26,560 --> 01:13:28,050 Everyone's runs on board? 1781 01:13:28,050 --> 01:13:30,962 And then very much like you talk to a mail server, you take this 1782 01:13:30,962 --> 01:13:32,170 and you send it to kpassword. 1783 01:13:32,170 --> 01:13:37,420 You say, well, here's my ticket-- tckpass encrypted 1784 01:13:37,420 --> 01:13:39,500 with kpass. 1785 01:13:39,500 --> 01:13:45,370 And in addition, you send your new password 1786 01:13:45,370 --> 01:13:50,240 and you encrypt this with the key kcpass 1787 01:13:50,240 --> 01:13:52,340 with shared key for your interaction. 1788 01:13:52,340 --> 01:13:55,561 I just separated these two things out here. 1789 01:13:55,561 --> 01:13:56,060 Make sense? 1790 01:13:56,060 --> 01:13:57,650 So this is the thing you send to the kpassword service 1791 01:13:57,650 --> 01:14:00,140 with a new password encrypted with the session key. 1792 01:14:00,140 --> 01:14:00,640 Yeah. 1793 01:14:00,640 --> 01:14:02,116 STUDENT: But in the [INAUDIBLE] 1794 01:14:06,367 --> 01:14:08,450 PROFESSOR: So if the attacker knows your password, 1795 01:14:08,450 --> 01:14:11,420 they can change your password-- absolutely. 1796 01:14:11,420 --> 01:14:12,670 So it seems reasonable, right? 1797 01:14:12,670 --> 01:14:15,110 Like, there's no other way to tell whether it's you or not. 1798 01:14:15,110 --> 01:14:17,060 If someone walks up to an Athena workstation, types 1799 01:14:17,060 --> 01:14:19,047 in your username and password, runs password, 1800 01:14:19,047 --> 01:14:21,630 change my password to this new thing, they know your password? 1801 01:14:21,630 --> 01:14:23,340 They're going to be able to change it. 1802 01:14:23,340 --> 01:14:25,010 So that's totally the same in almost any system 1803 01:14:25,010 --> 01:14:25,760 you could imagine. 1804 01:14:25,760 --> 01:14:27,150 This is true for Gmail probably. 1805 01:14:27,150 --> 01:14:31,240 This is true for any system that uses passwords in general. 1806 01:14:31,240 --> 01:14:33,840 The reason that we had to talk to the Kerberos server instead 1807 01:14:33,840 --> 01:14:39,610 of the TGS server here is that if someone steals your ticket, 1808 01:14:39,610 --> 01:14:42,700 then we don't want them to be able to change your password. 1809 01:14:42,700 --> 01:14:46,170 So if someone corrupts an Athena workstation after you log in, 1810 01:14:46,170 --> 01:14:49,420 your password is gone from memory, the ticket remains. 1811 01:14:49,420 --> 01:14:51,370 You could, in principle, use the ticket 1812 01:14:51,370 --> 01:14:54,916 to obtain more tickets for the password changing service. 1813 01:14:54,916 --> 01:14:56,290 But the password changing service 1814 01:14:56,290 --> 01:14:57,270 says that's not going to be good enough. 1815 01:14:57,270 --> 01:14:58,645 It's going to look at this ticket 1816 01:14:58,645 --> 01:15:01,950 here-- ticket between the client and the password service. 1817 01:15:01,950 --> 01:15:04,764 And if that was updated through TGS, 1818 01:15:04,764 --> 01:15:06,180 it's going to reject your request. 1819 01:15:06,180 --> 01:15:08,513 It's only going to accept it if it was obtained directly 1820 01:15:08,513 --> 01:15:11,260 from the Kerberos service using KC. 1821 01:15:11,260 --> 01:15:11,761 Makes sense? 1822 01:15:11,761 --> 01:15:12,260 Question. 1823 01:15:12,260 --> 01:15:14,794 STUDENT: So if you [INAUDIBLE] password with the [INAUDIBLE] 1824 01:15:14,794 --> 01:15:15,454 Athena, right? 1825 01:15:15,454 --> 01:15:16,120 PROFESSOR: Yeah. 1826 01:15:16,120 --> 01:15:18,375 STUDENT: So if I would steal your private key-- 1827 01:15:18,375 --> 01:15:20,590 PROFESSOR: Yeah, so actually, KC is 1828 01:15:20,590 --> 01:15:22,896 basically equivalent to your password here. 1829 01:15:22,896 --> 01:15:24,770 As far as the Kerberos protocol is concerned, 1830 01:15:24,770 --> 01:15:26,728 that don't even think that you have a password. 1831 01:15:26,728 --> 01:15:28,510 It thinks you have a private key KC. 1832 01:15:28,510 --> 01:15:31,000 If someone knows KC, that's basically your password. 1833 01:15:31,000 --> 01:15:32,678 So you can change your key from KC 1834 01:15:32,678 --> 01:15:34,886 to something else so you don't lose this thing, yeah. 1835 01:15:34,886 --> 01:15:36,690 Uh, yeah, question? 1836 01:15:36,690 --> 01:15:41,926 STUDENT: [INAUDIBLE] initial message [INAUDIBLE] 1837 01:15:41,926 --> 01:15:44,410 from changing the [INAUDIBLE] 1838 01:15:44,410 --> 01:15:45,910 PROFESSOR: Oh, you can certainly get 1839 01:15:45,910 --> 01:15:48,725 a ticket for some other service or an attacker 1840 01:15:48,725 --> 01:15:50,600 could drop this message altogether or corrupt 1841 01:15:50,600 --> 01:15:51,480 this exchange. 1842 01:15:51,480 --> 01:15:52,790 And then you're not going to successfully change 1843 01:15:52,790 --> 01:15:53,255 your password. 1844 01:15:53,255 --> 01:15:54,088 STUDENT: [INAUDIBLE] 1845 01:15:56,456 --> 01:15:58,080 PROFESSOR: Yeah, so the client actually 1846 01:15:58,080 --> 01:16:00,350 knows exactly what service it wants to talk to. 1847 01:16:00,350 --> 01:16:07,120 So if it-- it's going to make sure, well, 1848 01:16:07,120 --> 01:16:09,620 there are some messages, some parts of this protocol I'm not 1849 01:16:09,620 --> 01:16:11,810 showing that allow the client to make sure 1850 01:16:11,810 --> 01:16:14,330 they actually got the ticket for the right thing. 1851 01:16:14,330 --> 01:16:17,200 But yeah, so the-- sorry. 1852 01:16:17,200 --> 01:16:17,700 Question? 1853 01:16:17,700 --> 01:16:20,941 STUDENT: [INAUDIBLE] very easy to denial of service attack 1854 01:16:20,941 --> 01:16:25,207 when an attacker [INAUDIBLE] modifying the encrypted version 1855 01:16:25,207 --> 01:16:26,926 of the new password. 1856 01:16:26,926 --> 01:16:29,340 PROFESSOR: Yeah, so there's actually lot of things. 1857 01:16:29,340 --> 01:16:34,392 Because, for example, Kerberos doesn't do authentication 1858 01:16:34,392 --> 01:16:35,850 properly of messages-- it just does 1859 01:16:35,850 --> 01:16:38,270 encryption-- you could totally corrupt this blob. 1860 01:16:38,270 --> 01:16:38,770 And-- 1861 01:16:38,770 --> 01:16:39,870 STUDENT: [INAUDIBLE] 1862 01:16:39,870 --> 01:16:40,924 PROFESSOR: Yeah, you could flip it around 1863 01:16:40,924 --> 01:16:42,770 and it'll decrypt to something else. 1864 01:16:42,770 --> 01:16:44,260 The service was like, oh yeah, that's the new password, 1865 01:16:44,260 --> 01:16:44,882 and set it. 1866 01:16:44,882 --> 01:16:46,340 And then you're sort of locked out. 1867 01:16:46,340 --> 01:16:47,631 So it seems really unfortunate. 1868 01:16:47,631 --> 01:16:49,130 And this is yet another reason why 1869 01:16:49,130 --> 01:16:52,325 you want separate encryption and authentication in the protocol. 1870 01:16:52,325 --> 01:16:54,200 There's actually an even bigger problem here. 1871 01:16:54,200 --> 01:16:55,080 But actually, yeah, question? 1872 01:16:55,080 --> 01:16:56,947 STUDENT: What's the point of having a one way 1873 01:16:56,947 --> 01:16:59,196 function to [INAUDIBLE] your password in KC if they're 1874 01:16:59,196 --> 01:17:01,350 essentially [INAUDIBLE]? 1875 01:17:01,350 --> 01:17:05,060 PROFESSOR: Basically because KC is a 56-bit ds key 1876 01:17:05,060 --> 01:17:07,060 and your password might be of different lengths. 1877 01:17:07,060 --> 01:17:09,430 And even if it's longer than 56 bits, which 1878 01:17:09,430 --> 01:17:11,360 is seven bites or seven characters, 1879 01:17:11,360 --> 01:17:13,630 you want to use all those extra bytes too. 1880 01:17:13,630 --> 01:17:17,900 So it's mostly just to condense it down to a fixed width blob, 1881 01:17:17,900 --> 01:17:18,996 yeah. 1882 01:17:18,996 --> 01:17:21,412 But there's actually a much more interesting problem here, 1883 01:17:21,412 --> 01:17:23,990 which is that suppose that I change my password 1884 01:17:23,990 --> 01:17:27,820 and then I decide, OK, well, I change my password. 1885 01:17:27,820 --> 01:17:29,930 A day goes by and I'm thinking, oh yeah, sure. 1886 01:17:29,930 --> 01:17:32,370 I'll tell everyone what my stupid old password was. 1887 01:17:32,370 --> 01:17:35,200 Is this a good idea in Kerberos? 1888 01:17:35,200 --> 01:17:35,700 Yeah. 1889 01:17:35,700 --> 01:17:38,346 STUDENT: [INAUDIBLE] immediately expire until the-- 1890 01:17:38,346 --> 01:17:39,230 PROFESSOR: Yeah, OK. 1891 01:17:39,230 --> 01:17:40,470 But someone's got to wait for all my tickets to expire. 1892 01:17:40,470 --> 01:17:42,380 I wait for, like, a week. 1893 01:17:42,380 --> 01:17:44,020 And then no tickets are good anymore. 1894 01:17:44,020 --> 01:17:45,611 Can I give out my old password now? 1895 01:17:45,611 --> 01:17:46,110 Yeah. 1896 01:17:46,110 --> 01:17:48,389 STUDENT: It might take a while to replicate. 1897 01:17:48,389 --> 01:17:49,930 PROFESSOR: Yeah, suppose the replicas 1898 01:17:49,930 --> 01:17:51,661 are all updated, yeah, all the stuff. 1899 01:17:51,661 --> 01:17:52,160 Yeah. 1900 01:17:52,160 --> 01:17:54,701 STUDENT: [INAUDIBLE] if someone saves the initial transaction 1901 01:17:54,701 --> 01:17:56,579 [INAUDIBLE] to get, like, your old password 1902 01:17:56,579 --> 01:17:57,570 now that they have your new password. 1903 01:17:57,570 --> 01:17:58,310 PROFESSOR: Yeah, so this is actually 1904 01:17:58,310 --> 01:17:59,850 super worrisome in Kerberos, which 1905 01:17:59,850 --> 01:18:01,560 is that-- suppose some attacker was 1906 01:18:01,560 --> 01:18:04,240 watching all of my previous password changes. 1907 01:18:04,240 --> 01:18:07,690 They didn't know what my password was or is or anything. 1908 01:18:07,690 --> 01:18:10,460 But they're just saving these packets very diligently. 1909 01:18:10,460 --> 01:18:13,360 And then a month later, I go and say, oh, my password 1910 01:18:13,360 --> 01:18:15,820 was poodle or something silly like this. 1911 01:18:15,820 --> 01:18:17,520 And then they go say ah, ha, ha. 1912 01:18:17,520 --> 01:18:19,630 I can now decrypt this initial thing 1913 01:18:19,630 --> 01:18:21,550 because it was encrypted with your old KC. 1914 01:18:21,550 --> 01:18:25,230 And I can get this KC with pass that you shared. 1915 01:18:25,230 --> 01:18:27,270 Then I can use this to decrypt the new password 1916 01:18:27,270 --> 01:18:28,160 you sent to the KDC. 1917 01:18:28,160 --> 01:18:29,910 And even if you change the password again, 1918 01:18:29,910 --> 01:18:31,500 I can decrypt the next round as well. 1919 01:18:31,500 --> 01:18:33,833 And you can just keep going and get the newest password. 1920 01:18:33,833 --> 01:18:38,000 So in this particular password, changing protocol, if you ever 1921 01:18:38,000 --> 01:18:40,040 disclose an old password, then someone 1922 01:18:40,040 --> 01:18:43,330 could sort of unzip this whole chain of encrypted messages 1923 01:18:43,330 --> 01:18:45,860 and get your newest password as well. 1924 01:18:45,860 --> 01:18:47,860 This is actually very troublesome in the design. 1925 01:18:47,860 --> 01:18:48,360 Yeah. 1926 01:18:48,360 --> 01:18:51,115 STUDENT: Doesn't the later version of Kerberos [INAUDIBLE] 1927 01:18:51,115 --> 01:18:52,240 PROFESSOR: Absolutely, yes. 1928 01:18:52,240 --> 01:18:53,380 So there's actually a solution to this 1929 01:18:53,380 --> 01:18:54,490 that's not sort of fundamental. 1930 01:18:54,490 --> 01:18:55,865 And this is something they didn't 1931 01:18:55,865 --> 01:18:57,160 realize in Kerberos version 4. 1932 01:18:57,160 --> 01:19:00,610 There's actually this nice mechanism called Diffie-Hellman 1933 01:19:00,610 --> 01:19:03,800 that I'll just sketch out in like one minute 1934 01:19:03,800 --> 01:19:06,420 just so that you guys know when to use it or et cetera. 1935 01:19:06,420 --> 01:19:08,920 But it's basically a solution for this kind of a problem 1936 01:19:08,920 --> 01:19:11,630 where you want to stop this unzipping from happening. 1937 01:19:11,630 --> 01:19:13,730 So what happens in the Kerberos version 1938 01:19:13,730 --> 01:19:16,910 5 password changing protocol is that actually you 1939 01:19:16,910 --> 01:19:20,370 want to establish a new secret that will not be apparent 1940 01:19:20,370 --> 01:19:23,360 if you happen to decrypt all the messages on the wire. 1941 01:19:23,360 --> 01:19:25,620 And the way this works is-- this is like some math 1942 01:19:25,620 --> 01:19:27,286 that you don't have to fully understand. 1943 01:19:27,286 --> 01:19:33,590 But the client some random value X. And the kpassword server is 1944 01:19:33,590 --> 01:19:35,630 going to pick some other random value Y. 1945 01:19:35,630 --> 01:19:37,820 And what they send to each other are exponentiations 1946 01:19:37,820 --> 01:19:39,050 of these values. 1947 01:19:39,050 --> 01:19:41,500 So the client sends G to the power X 1948 01:19:41,500 --> 01:19:45,810 to the server and the server sends G to the power Y 1949 01:19:45,810 --> 01:19:47,260 back to the client. 1950 01:19:47,260 --> 01:19:48,890 And it turns out that mathematically, 1951 01:19:48,890 --> 01:19:52,110 what we can do now is the client can take G to the Y, 1952 01:19:52,110 --> 01:19:55,270 raise it to X, and get this value G to the XY. 1953 01:19:55,270 --> 01:19:58,680 The server can take G to the X, raise it to the power Y, 1954 01:19:58,680 --> 01:20:00,650 and get G to the XY as well. 1955 01:20:00,650 --> 01:20:03,670 They can now use this secret value G to the XY 1956 01:20:03,670 --> 01:20:05,440 to encrypt their subsequent messages, 1957 01:20:05,440 --> 01:20:07,710 including the new password. 1958 01:20:07,710 --> 01:20:11,263 So you send the new password encrypted with this value G 1959 01:20:11,263 --> 01:20:13,400 to the XY, roughly speaking. 1960 01:20:13,400 --> 01:20:14,830 But for some mathematical reasons 1961 01:20:14,830 --> 01:20:16,600 that we're not going to cover right now, 1962 01:20:16,600 --> 01:20:19,350 it turns out to be super difficult for someone that just 1963 01:20:19,350 --> 01:20:23,350 gets G to the X and G to the Y by examining your packets later 1964 01:20:23,350 --> 01:20:26,200 from figuring out what was G to the XY. 1965 01:20:26,200 --> 01:20:28,560 So this is something called the discrete log problem. 1966 01:20:28,560 --> 01:20:29,350 Yeah, question? 1967 01:20:29,350 --> 01:20:31,140 STUDENT: But they have to [INAUDIBLE] G at some point. 1968 01:20:31,140 --> 01:20:31,570 PROFESSOR: Yeah, yeah. 1969 01:20:31,570 --> 01:20:33,535 So G is some parameter you could sort of send 1970 01:20:33,535 --> 01:20:35,910 at the beginning of a protocol or it could be just cooked 1971 01:20:35,910 --> 01:20:36,640 into Kerberos. 1972 01:20:36,640 --> 01:20:42,030 It turns out to be relatively less important. 1973 01:20:42,030 --> 01:20:44,410 All right, so anyway, use Diffie-Hellman because this 1974 01:20:44,410 --> 01:20:46,660 is called-- well, what you should Google for if you're 1975 01:20:46,660 --> 01:20:50,920 building a protocol like this is this Diffie-Hellman key 1976 01:20:50,920 --> 01:20:51,950 exchange protocol. 1977 01:20:51,950 --> 01:20:54,302 And Kerberos 5 actually does this correctly. 1978 01:20:54,302 --> 01:20:56,010 But this is something to really watch out 1979 01:20:56,010 --> 01:20:59,169 for if you're designing any kind of new protocol yourself. 1980 01:20:59,169 --> 01:21:00,710 All right, so that's it for Kerberos. 1981 01:21:00,710 --> 01:21:03,160 Let's talk about SSL on Monday.