1 00:00:01,881 --> 00:00:03,380 OK, so today we're going to continue 2 00:00:03,380 --> 00:00:04,588 our discussion of protection. 3 00:00:07,290 --> 00:00:11,310 Remember, we have our three protection primitives 4 00:00:11,310 --> 00:00:25,633 that we've been talking about, authentication, authorization 5 00:00:25,633 --> 00:00:26,466 and confidentiality. 6 00:00:32,940 --> 00:00:35,163 Today we're mostly going to focus on authorization 7 00:00:35,163 --> 00:00:35,996 and confidentiality. 8 00:00:39,144 --> 00:00:40,560 Remember, we have seen, and we are 9 00:00:40,560 --> 00:00:42,264 going to continue to rely on this set 10 00:00:42,264 --> 00:00:43,430 of cryptographic primitives. 11 00:00:45,624 --> 00:00:47,790 So the cryptographic primitives that we talked about 12 00:00:47,790 --> 00:00:51,160 are sign and verify. 13 00:00:51,160 --> 00:01:00,990 And we said that sign accepts a message and some key. 14 00:01:00,990 --> 00:01:05,319 And verify accepts the message and some k. 15 00:01:09,770 --> 00:01:14,390 Sign accepts a message and a key and outputs some signature. 16 00:01:18,760 --> 00:01:21,810 Verify accepts the message and the signature 17 00:01:21,810 --> 00:01:27,760 and some other key k2 and tells us whether or not 18 00:01:27,760 --> 00:01:30,350 it believes that the message that this m actually 19 00:01:30,350 --> 00:01:31,760 corresponds to this signature. 20 00:01:31,760 --> 00:01:34,190 And we talked about how if k1 is equal to k2 21 00:01:34,190 --> 00:01:36,040 this is a shared key system. 22 00:01:36,040 --> 00:01:38,190 And if k1 is not equal to k2 we typically 23 00:01:38,190 --> 00:01:40,450 call this a public key system. 24 00:01:40,450 --> 00:01:45,920 We also talked about our encrypt and decrypt primitives. 25 00:01:45,920 --> 00:01:55,980 And we said that encrypt accepts some message m and some key k1 26 00:01:55,980 --> 00:02:01,300 and outputs some encoded message C. 27 00:02:01,300 --> 00:02:08,560 And decrypt takes C and some k2 and gives back m. 28 00:02:08,560 --> 00:02:11,260 Again, we have the same separation between shared key 29 00:02:11,260 --> 00:02:14,620 and public key, private key. 30 00:02:14,620 --> 00:02:17,510 So, if you remember last time, we 31 00:02:17,510 --> 00:02:20,010 were talking about this protocol that 32 00:02:20,010 --> 00:02:25,190 was a protocol for establishing a secure communication channel. 33 00:02:25,190 --> 00:02:27,750 We got as far as talking about how we would actually 34 00:02:27,750 --> 00:02:28,660 authenticate a user. 35 00:02:28,660 --> 00:02:30,699 We talked about the process for authentication. 36 00:02:30,699 --> 00:02:32,740 And then we were using our authentication process 37 00:02:32,740 --> 00:02:36,110 to build up a protocol for setting up 38 00:02:36,110 --> 00:02:37,470 a secure communication channel. 39 00:02:48,570 --> 00:02:50,930 The way this is going to work is that we 40 00:02:50,930 --> 00:02:58,440 are going to use a public key cryptography. 41 00:02:58,440 --> 00:03:04,310 We are going to use our encryption with a public key 42 00:03:04,310 --> 00:03:08,870 to exchange a shared key. 43 00:03:11,980 --> 00:03:18,787 And then we are going to use the shared key 44 00:03:18,787 --> 00:03:19,995 to encrypt our communication. 45 00:03:26,050 --> 00:03:29,310 We went through this example with the Denning-Sacco Protocol 46 00:03:29,310 --> 00:03:30,477 which I will quickly review. 47 00:03:30,477 --> 00:03:32,768 And, remember, I told you that this protocol is broken. 48 00:03:32,768 --> 00:03:35,440 And we got as far as not quite figuring out how it was broken. 49 00:03:35,440 --> 00:03:39,420 So let's see if we can figure out how it was broken. 50 00:03:39,420 --> 00:03:41,320 Again, we said the idea is Alice first 51 00:03:41,320 --> 00:03:42,930 sends a message to Charles. 52 00:03:42,930 --> 00:03:44,530 And, remember in our model, Charles 53 00:03:44,530 --> 00:03:49,530 is this certificate authority, the guy who both Alice 54 00:03:49,530 --> 00:03:51,620 and Bob know and trust. 55 00:03:51,620 --> 00:03:54,960 So Alice sends a message to Charles saying hey, 56 00:03:54,960 --> 00:03:59,450 I would like to get these certificates for Alice and Bob 57 00:03:59,450 --> 00:04:02,220 so that I can establish this clear communication channel. 58 00:04:02,220 --> 00:04:04,830 Charles goes ahead and agrees with this 59 00:04:04,830 --> 00:04:07,550 and sends a message back which consists of these two 60 00:04:07,550 --> 00:04:10,140 certificates, one certificate for Alice 61 00:04:10,140 --> 00:04:11,400 and one certificate for Bob. 62 00:04:11,400 --> 00:04:13,480 Both of these certificates have been signed 63 00:04:13,480 --> 00:04:14,941 with Charles' private key. 64 00:04:14,941 --> 00:04:17,149 And because they are signed with Charles' private key 65 00:04:17,149 --> 00:04:20,329 that presumably means that only Charles could have possibly 66 00:04:20,329 --> 00:04:24,125 generated these certificates. 67 00:04:26,790 --> 00:04:29,860 And there are two certificates, and each certificate 68 00:04:29,860 --> 00:04:35,800 contains the name of the principle that the certificate 69 00:04:35,800 --> 00:04:37,784 belongs to, the public key of that principle 70 00:04:37,784 --> 00:04:39,450 and then some timestamp which, remember, 71 00:04:39,450 --> 00:04:40,908 we said we want to use to make sure 72 00:04:40,908 --> 00:04:45,640 that these certificates are fresh. 73 00:04:45,640 --> 00:04:48,990 And now what happens is that Alice, in order 74 00:04:48,990 --> 00:04:53,620 to establish this communication with Bob, needs to exchange 75 00:04:53,620 --> 00:04:57,490 or needs to propose a shared key that she 76 00:04:57,490 --> 00:04:59,230 can go ahead and use with Bob. 77 00:04:59,230 --> 00:05:02,410 What she does is she sends her certificate, 78 00:05:02,410 --> 00:05:04,660 which is something that Bob should 79 00:05:04,660 --> 00:05:08,840 be able to use to validate that she is, in fact, who 80 00:05:08,840 --> 00:05:10,330 she said she is. 81 00:05:10,330 --> 00:05:12,980 And, remember, she cannot forget this because it's signed with 82 00:05:12,980 --> 00:05:16,610 Charles' private key. 83 00:05:16,610 --> 00:05:20,230 And she also goes ahead and sends this proposed key. 84 00:05:20,230 --> 00:05:22,520 And the way she encodes the proposed key 85 00:05:22,520 --> 00:05:27,000 is to sign it with her private key 86 00:05:27,000 --> 00:05:30,030 so that Bob knows that it actually came from her. 87 00:05:30,030 --> 00:05:36,190 And then she encrypts it with Bob's public key 88 00:05:36,190 --> 00:05:42,369 so that only Bob can actually go ahead and decode this message. 89 00:05:42,369 --> 00:05:43,410 Let's think for a minute. 90 00:05:43,410 --> 00:05:45,610 We started to get towards figuring out what's 91 00:05:45,610 --> 00:05:47,600 wrong with this protocol. 92 00:05:47,600 --> 00:05:53,050 And the way that we started to talk about it 93 00:05:53,050 --> 00:05:55,720 was, well, what properties would we like a protocol 94 00:05:55,720 --> 00:05:56,970 like this to have? 95 00:05:56,970 --> 00:05:58,530 We said one property we would like 96 00:05:58,530 --> 00:06:01,310 is for it to have freshness. 97 00:06:01,310 --> 00:06:04,320 What freshness means is that the protocol shouldn't be 98 00:06:04,320 --> 00:06:06,000 susceptible to replay attacks. 99 00:06:06,000 --> 00:06:09,710 That is somebody shouldn't be able to overhear a message 100 00:06:09,710 --> 00:06:13,650 and then replay it sometime much later in order to sort of cause 101 00:06:13,650 --> 00:06:15,030 that message to happen again. 102 00:06:15,030 --> 00:06:17,155 So, even if that person cannot actually look inside 103 00:06:17,155 --> 00:06:19,321 the contents of the message, they may be able to get 104 00:06:19,321 --> 00:06:21,690 something to happen simply by replaying the message. 105 00:06:21,690 --> 00:06:25,620 So freshness is something we want our protocols to have. 106 00:06:25,620 --> 00:06:28,260 And, in this case, we are achieving freshness hopefully 107 00:06:28,260 --> 00:06:31,010 by including this T which is a timestamp in the message. 108 00:06:31,010 --> 00:06:32,760 As I said last time, getting the timestamp 109 00:06:32,760 --> 00:06:34,640 to actually work correctly is something 110 00:06:34,640 --> 00:06:37,350 that you have to be careful about. 111 00:06:37,350 --> 00:06:42,690 And this is described in Section E of the notes. 112 00:06:42,690 --> 00:06:44,294 The first property is freshness. 113 00:06:44,294 --> 00:06:45,710 The second one is appropriateness. 114 00:06:50,010 --> 00:06:52,520 That just means that this message is, in fact, 115 00:06:52,520 --> 00:06:56,850 for the particular sender, it applies 116 00:06:56,850 --> 00:06:59,740 for the particular sort of context in which 117 00:06:59,740 --> 00:07:01,790 the message is being used. 118 00:07:01,790 --> 00:07:05,680 So the people who are receiving the message, for example, 119 00:07:05,680 --> 00:07:08,952 are actually the intended recipients of the message. 120 00:07:08,952 --> 00:07:10,410 And then the third property we said 121 00:07:10,410 --> 00:07:13,070 we want is forward secrecy. 122 00:07:13,070 --> 00:07:15,300 And this just means that it will be 123 00:07:15,300 --> 00:07:19,810 possible to switch to a new set of keys at some later time 124 00:07:19,810 --> 00:07:23,209 if, for example, the keys get breached so we have 125 00:07:23,209 --> 00:07:24,500 a way of changing the protocol. 126 00:07:24,500 --> 00:07:25,110 This protocol that we have also achieves forward secrecy. 127 00:07:25,110 --> 00:07:26,901 The problem it has is with appropriateness. 128 00:07:26,901 --> 00:07:30,294 Let me show you what I mean by this protocol being 129 00:07:30,294 --> 00:07:30,877 inappropriate. 130 00:07:34,990 --> 00:07:41,680 Once we've exchanged this kAB now we can go ahead 131 00:07:41,680 --> 00:07:44,790 and Bob and Alice can presumably communicate with each other 132 00:07:44,790 --> 00:07:48,532 by encrypting messages to one another with this kAB key 133 00:07:48,532 --> 00:07:49,490 that they've exchanged. 134 00:07:53,530 --> 00:07:55,970 Let's see what the problem with this is. 135 00:07:55,970 --> 00:07:59,030 Remember, Alice sends this message three to Bob. 136 00:07:59,030 --> 00:08:00,780 Now here is what the issue is. 137 00:08:00,780 --> 00:08:04,151 The issue has to do with this piece of information 138 00:08:04,151 --> 00:08:05,650 that Alice has encrypted and signed. 139 00:08:05,650 --> 00:08:08,490 And the problem is that this message does not satisfy 140 00:08:08,490 --> 00:08:10,860 the appropriateness constraint. 141 00:08:10,860 --> 00:08:13,050 In particular, it doesn't have any context 142 00:08:13,050 --> 00:08:19,450 about which conversation this key is meant to apply to. 143 00:08:19,450 --> 00:08:23,130 So let me show you a way in which Bob might exploit this. 144 00:08:23,130 --> 00:08:25,560 Suppose Bob sends a message to Charles. 145 00:08:25,560 --> 00:08:30,620 And what he sends in this message is I am Alice 146 00:08:30,620 --> 00:08:34,100 and I would like to set up a conversation with you 147 00:08:34,100 --> 00:08:38,470 and here is my public key and here is a bit of information 148 00:08:38,470 --> 00:08:41,610 that I've signed using my private key that 149 00:08:41,610 --> 00:08:45,320 is a key I would like to use for our conversation. 150 00:08:45,320 --> 00:08:47,976 So Charles sees this thing and says oh, yes, Alice signed this 151 00:08:47,976 --> 00:08:48,850 with her private key. 152 00:08:48,850 --> 00:08:50,660 He can check with the certificate authority 153 00:08:50,660 --> 00:08:54,290 and see that, in fact, this message 154 00:08:54,290 --> 00:08:59,650 appears to be authentic. 155 00:08:59,650 --> 00:09:01,640 And now he may go ahead and send a message 156 00:09:01,640 --> 00:09:05,070 back to Bob that is signed with this kAB. 157 00:09:05,070 --> 00:09:09,280 So Charles has been fooled into thinking 158 00:09:09,280 --> 00:09:12,560 that Bob is, in fact, Alice and goes ahead 159 00:09:12,560 --> 00:09:16,560 and starts to establish some communication with him. 160 00:09:16,560 --> 00:09:20,240 Again, the issue is because this encrypted and signed thing 161 00:09:20,240 --> 00:09:23,400 doesn't have any information about what conversation 162 00:09:23,400 --> 00:09:25,430 this key is meant to apply to. 163 00:09:25,430 --> 00:09:27,340 Alice hasn't said that this is only 164 00:09:27,340 --> 00:09:29,440 a key that applies to a conversation between Alice 165 00:09:29,440 --> 00:09:30,220 and Bob. 166 00:09:30,220 --> 00:09:32,220 Now, anybody who overhears this can use this key 167 00:09:32,220 --> 00:09:35,520 to establish a conversation that appears 168 00:09:35,520 --> 00:09:38,560 to be originating with Alice that, in fact, is not. 169 00:09:38,560 --> 00:09:41,886 Let me show you how we go ahead and fix this. 170 00:09:41,886 --> 00:09:43,260 This is just exactly the protocol 171 00:09:43,260 --> 00:09:44,610 that I showed you before. 172 00:09:44,610 --> 00:09:46,276 And the way that we're going to fix this 173 00:09:46,276 --> 00:09:48,780 is really pretty much as I've just described. 174 00:09:48,780 --> 00:09:51,970 We are going to take this big nasty statement that we 175 00:09:51,970 --> 00:10:01,880 had here, and we're going to basically sign and encrypt 176 00:10:01,880 --> 00:10:04,720 the whole message instead of simply signing and encrypting 177 00:10:04,720 --> 00:10:08,180 the one little piece of this message which was the proposed 178 00:10:08,180 --> 00:10:08,680 key. 179 00:10:08,680 --> 00:10:11,096 We are going to sign and encrypt the whole thing together, 180 00:10:11,096 --> 00:10:14,440 including Alice's public key and Alice's certificate. 181 00:10:14,440 --> 00:10:16,900 And we are also going to include a sender and receiver 182 00:10:16,900 --> 00:10:18,390 in this entire message. 183 00:10:18,390 --> 00:10:22,410 Now we said we add A and B as two 184 00:10:22,410 --> 00:10:23,770 members of this entire message. 185 00:10:23,770 --> 00:10:25,710 And what this allows us to do is to guaranty 186 00:10:25,710 --> 00:10:30,120 that because Alice has signed this entire thing, 187 00:10:30,120 --> 00:10:34,010 Bob isn't able to generate a new version of this thing, 188 00:10:34,010 --> 00:10:36,690 or Bob isn't able to use this thing 189 00:10:36,690 --> 00:10:42,410 to spoof a conversation with Charles. 190 00:10:42,410 --> 00:10:47,381 Bob can go ahead and try and send this message for Charles, 191 00:10:47,381 --> 00:10:48,880 but Charles could look at this thing 192 00:10:48,880 --> 00:10:52,870 and obviously tell that this key was not 193 00:10:52,870 --> 00:10:54,380 for a conversation between himself 194 00:10:54,380 --> 00:10:57,270 and Alice but instead was for a conversation between Bob 195 00:10:57,270 --> 00:10:58,694 and Alice. 196 00:10:58,694 --> 00:11:00,110 And there is no way that Bob could 197 00:11:00,110 --> 00:11:01,974 spoof the generation of this whole thing 198 00:11:01,974 --> 00:11:04,390 because he doesn't have Alice's private key so he couldn't 199 00:11:04,390 --> 00:11:12,750 sign this message. 200 00:11:12,750 --> 00:11:15,250 That wraps up most of our discussion, 201 00:11:15,250 --> 00:11:18,040 the extent of the discussion from last time. 202 00:11:18,040 --> 00:11:22,100 What we saw last time basically is a way to do authentication, 203 00:11:22,100 --> 00:11:23,850 and then at the very end we talk about how 204 00:11:23,850 --> 00:11:25,590 we can use authentication to establish 205 00:11:25,590 --> 00:11:28,240 the secure communications channel. 206 00:11:28,240 --> 00:11:30,440 Establishing a secure communications channel 207 00:11:30,440 --> 00:11:33,460 relies on sort of the confidentiality 208 00:11:33,460 --> 00:11:34,960 piece of this story, and I just want 209 00:11:34,960 --> 00:11:39,062 to spend a few minutes talking about what confidentiality is 210 00:11:39,062 --> 00:11:39,770 and how it works. 211 00:11:46,230 --> 00:11:50,510 Confidentiality, obviously, is the protection 212 00:11:50,510 --> 00:11:54,070 of information exchange between two people or two principles, 213 00:11:54,070 --> 00:11:55,009 say Alice and Bob. 214 00:11:55,009 --> 00:11:56,800 And the idea is to make it so that somebody 215 00:11:56,800 --> 00:11:58,406 who is overhearing this communication 216 00:11:58,406 --> 00:11:59,780 wouldn't actually be able to tell 217 00:11:59,780 --> 00:12:03,750 what the contents of the message that was overheard were. 218 00:12:03,750 --> 00:12:10,260 The idea is suppose Alice generates some message m, 219 00:12:10,260 --> 00:12:14,820 puts it into an encryption box, encrypts it with some key k1 220 00:12:14,820 --> 00:12:17,300 and generates a new message C which gets 221 00:12:17,300 --> 00:12:18,860 sent over the Internet to Bob. 222 00:12:21,940 --> 00:12:23,740 On the other side, Bob feeds this thing 223 00:12:23,740 --> 00:12:28,390 into a decryption box, decrypts it with k2 and gets m out. 224 00:12:28,390 --> 00:12:33,790 And this has the properties that simply knowing C 225 00:12:33,790 --> 00:12:35,830 makes it very hard to drive m. 226 00:12:35,830 --> 00:12:38,260 Given C, driving m is very hard to do. 227 00:12:38,260 --> 00:12:41,080 That is because of the difficulty of sort 228 00:12:41,080 --> 00:12:44,210 of breaking these cryptographic protocols that we talked about 229 00:12:44,210 --> 00:12:50,650 the first couple times, but given k2 and C 230 00:12:50,650 --> 00:12:54,505 it is possible to drive m. 231 00:12:54,505 --> 00:12:55,880 The only way that you can do this 232 00:12:55,880 --> 00:12:57,890 is by applying some sort of attack 233 00:12:57,890 --> 00:13:01,200 on the cryptographic mechanism hopefully. 234 00:13:01,200 --> 00:13:03,647 But this property, given k2 you can derive C, 235 00:13:03,647 --> 00:13:05,230 it is relatively easy for the receiver 236 00:13:05,230 --> 00:13:07,880 to go ahead and figure out what the message is. 237 00:13:07,880 --> 00:13:11,470 And since we are using these encrypt and decrypt boxes, 238 00:13:11,470 --> 00:13:13,880 obviously, k1 could be equal to k2, in which case 239 00:13:13,880 --> 00:13:16,220 we would be using a shared key approach. 240 00:13:16,220 --> 00:13:18,410 And k1 and k2 can be different, in which case 241 00:13:18,410 --> 00:13:26,600 we are using public key like we talked about. 242 00:13:26,600 --> 00:13:33,690 What we did in the secure communication channel protocol 243 00:13:33,690 --> 00:13:49,370 that we just talked about was to both authenticate and establish 244 00:13:49,370 --> 00:13:50,170 confidentiality. 245 00:13:50,170 --> 00:13:52,490 We had both confidentiality and authentication, 246 00:13:52,490 --> 00:13:54,840 so at the end of this protocol Alice and Bob 247 00:13:54,840 --> 00:13:56,466 have authenticated with each other 248 00:13:56,466 --> 00:13:58,340 and they have confidentiality because they've 249 00:13:58,340 --> 00:14:00,264 exchanged this key kAB that they can 250 00:14:00,264 --> 00:14:02,430 use to have a private conversation with one another. 251 00:14:06,760 --> 00:14:08,209 This is going to be a common thing 252 00:14:08,209 --> 00:14:10,000 that we are going to want to be able to do, 253 00:14:10,000 --> 00:14:13,525 confidentiality plus authentication. 254 00:14:20,390 --> 00:14:23,830 And we see the way that we do that is 255 00:14:23,830 --> 00:14:26,720 exactly the pattern that we have going on here in this example. 256 00:14:26,720 --> 00:14:34,800 You take a message and you sign it and then you encrypt it. 257 00:14:34,800 --> 00:14:37,380 So you have your message m. 258 00:14:37,380 --> 00:14:40,320 It is signed with some key which we will call kconf 259 00:14:40,320 --> 00:14:42,020 for confidentiality. 260 00:14:42,020 --> 00:14:42,520 Sorry. 261 00:14:42,520 --> 00:14:43,840 It is encrypted with kconf. 262 00:14:43,840 --> 00:14:45,840 And then you're going to sign this whole thing 263 00:14:45,840 --> 00:14:51,660 with some key kauth which is your key for authorization. 264 00:14:51,660 --> 00:14:54,844 And it is OK, in this case, for these two things, this sign 265 00:14:54,844 --> 00:14:56,510 and encrypt can be done in either order. 266 00:14:56,510 --> 00:14:58,520 I can sign the message and then encrypt it or encrypt it 267 00:14:58,520 --> 00:14:59,260 and then sign it. 268 00:14:59,260 --> 00:15:00,218 It works out just fine. 269 00:15:02,740 --> 00:15:04,892 This pattern is going to be a common one. 270 00:15:04,892 --> 00:15:06,350 Often times, when we're building up 271 00:15:06,350 --> 00:15:09,060 a secure system, what you want to do is first authenticate. 272 00:15:09,060 --> 00:15:11,800 You want to both guaranty that the person you are talking to, 273 00:15:11,800 --> 00:15:14,610 you want to know who the person you are talking to is, 274 00:15:14,610 --> 00:15:17,410 and you also want the communication with that person 275 00:15:17,410 --> 00:15:18,322 to be secure. 276 00:15:18,322 --> 00:15:20,030 We talked at the beginning, when we first 277 00:15:20,030 --> 00:15:21,500 starting talking about authentication 278 00:15:21,500 --> 00:15:22,874 we talked about a simpler example 279 00:15:22,874 --> 00:15:25,750 where you might just want to authenticate. 280 00:15:25,750 --> 00:15:30,104 I had the example, suppose you're purchasing something 281 00:15:30,104 --> 00:15:32,520 and you don't care if somebody knows that you purchase it, 282 00:15:32,520 --> 00:15:34,840 like giving money to Save the Whales. 283 00:15:34,840 --> 00:15:37,640 That example, you're giving money to save the whales. 284 00:15:37,640 --> 00:15:39,994 All you care about is that Save the Whales can actually 285 00:15:39,994 --> 00:15:41,910 authenticate your message, that the message is 286 00:15:41,910 --> 00:15:43,870 well-formed from the point of view 287 00:15:43,870 --> 00:15:47,660 that Save the Whales doesn't believe that you're giving them 288 00:15:47,660 --> 00:15:50,842 $10,000 instead of a $100 and that Save the Whales knows 289 00:15:50,842 --> 00:15:53,050 who you are so get credit for giving them that money, 290 00:15:53,050 --> 00:15:54,350 but you don't actually maybe care 291 00:15:54,350 --> 00:15:55,630 whether that message is encrypted. 292 00:15:55,630 --> 00:15:57,296 Another common thing you are going to do 293 00:15:57,296 --> 00:16:01,240 is just sign a message with kauth. 294 00:16:05,650 --> 00:16:08,390 It is less common to see, well, the other thing you 295 00:16:08,390 --> 00:16:10,980 might wonder is how often do people just 296 00:16:10,980 --> 00:16:12,560 want confidentiality? 297 00:16:12,560 --> 00:16:13,960 Just establishing confidentiality 298 00:16:13,960 --> 00:16:14,930 is sort of less common. 299 00:16:14,930 --> 00:16:16,388 You would see that less frequently. 300 00:16:16,388 --> 00:16:18,220 Typically, people want to either do 301 00:16:18,220 --> 00:16:20,160 confidentiality and authentication 302 00:16:20,160 --> 00:16:21,277 or just authentication. 303 00:16:21,277 --> 00:16:23,610 But just confidentiality is a little bit of a weird case 304 00:16:23,610 --> 00:16:27,100 because having a private conversation with somebody 305 00:16:27,100 --> 00:16:30,010 who you don't know there aren't that many cases where 306 00:16:30,010 --> 00:16:30,510 you want it. 307 00:16:30,510 --> 00:16:32,676 You could imagine an anonymous communication system, 308 00:16:32,676 --> 00:16:35,180 for example, where you don't actually 309 00:16:35,180 --> 00:16:38,530 want the other person to know anything about who you are. 310 00:16:38,530 --> 00:16:41,550 But that's a little bit of an unusual situation. 311 00:16:45,710 --> 00:16:49,160 These are kind of the two major forms of private communication 312 00:16:49,160 --> 00:16:51,920 that we have talked about so far. 313 00:16:51,920 --> 00:16:54,900 And we talked about a few little other details. 314 00:16:54,900 --> 00:16:57,460 This example illustrated a few other little details 315 00:16:57,460 --> 00:17:02,300 that we need to make sure we take care of. 316 00:17:02,300 --> 00:17:05,730 One of them was this freshness constraint. 317 00:17:05,730 --> 00:17:11,670 In this example, we said this is e.g., the addition 318 00:17:11,670 --> 00:17:13,660 of T to this example up here. 319 00:17:13,660 --> 00:17:15,450 So, when we add the timestamps, that 320 00:17:15,450 --> 00:17:18,780 makes it difficult for somebody to apply a replay attack 321 00:17:18,780 --> 00:17:19,859 against us. 322 00:17:19,859 --> 00:17:29,860 The other thing that we might want to do is add T to m. 323 00:17:29,860 --> 00:17:31,460 This is freshness. 324 00:17:31,460 --> 00:17:38,574 This is going to add timestamp to m. 325 00:17:38,574 --> 00:17:39,990 Now, the other thing we might want 326 00:17:39,990 --> 00:17:44,900 is some way to guaranty appropriateness. 327 00:17:44,900 --> 00:17:51,417 And, what we're going to do for appropriateness, what 328 00:17:51,417 --> 00:17:53,000 we need to do to make sure the message 329 00:17:53,000 --> 00:17:55,170 is appropriate is we need to add context to the message 330 00:17:55,170 --> 00:17:56,795 so we need to add some information that 331 00:17:56,795 --> 00:18:00,310 specifies who is originally involved in the message. 332 00:18:07,160 --> 00:18:09,400 These are sort of the two major kinds of protection 333 00:18:09,400 --> 00:18:12,000 that we have, and we need to make sure 334 00:18:12,000 --> 00:18:14,990 that our protocols we use sort of 335 00:18:14,990 --> 00:18:16,723 provide these kinds of guarantees. 336 00:18:21,860 --> 00:18:26,040 Now what I want to do is talk a little bit about authorization. 337 00:18:26,040 --> 00:18:28,760 We've seen authentication and a bit of confidentiality 338 00:18:28,760 --> 00:18:30,370 and we've talked about authorization, 339 00:18:30,370 --> 00:18:34,050 but I want to talk about it in the context of an example. 340 00:18:34,050 --> 00:18:36,870 Because you guys know something about authorization techniques. 341 00:18:36,870 --> 00:18:39,607 You guys have all seen, for example, passwords for logging 342 00:18:39,607 --> 00:18:40,190 into a system. 343 00:18:40,190 --> 00:18:45,990 There is no big surprise about how passwords work. 344 00:18:45,990 --> 00:18:47,450 There is some list of passwords. 345 00:18:47,450 --> 00:18:49,390 And, when a user tries to log in, 346 00:18:49,390 --> 00:18:53,379 the system checks to see if the person is in the list. 347 00:18:53,379 --> 00:18:55,920 They typically take the hash of the password that is typed in 348 00:18:55,920 --> 00:18:58,230 and check to see if the hash of the password 349 00:18:58,230 --> 00:19:00,070 is in the password list. 350 00:19:00,070 --> 00:19:01,900 This is described in detail in the text 351 00:19:01,900 --> 00:19:04,220 and we will go over it a little bit today, 352 00:19:04,220 --> 00:19:08,754 but what I want to do is sort of talk about how we fit all three 353 00:19:08,754 --> 00:19:10,670 of these things, authentication, authorization 354 00:19:10,670 --> 00:19:12,720 and confidentiality together into one system 355 00:19:12,720 --> 00:19:14,810 as we talk about authentication. 356 00:19:14,810 --> 00:19:16,625 We are going to use an example. 357 00:19:23,990 --> 00:19:25,230 Which is the Web. 358 00:19:30,200 --> 00:19:31,720 Suppose that we were in a situation 359 00:19:31,720 --> 00:19:35,120 where we have some browser B communicating 360 00:19:35,120 --> 00:19:42,770 with some Web server W over a secure communication channel. 361 00:19:45,500 --> 00:19:50,280 And, if you like, you can think of the secure communication 362 00:19:50,280 --> 00:19:52,150 channel as having been established 363 00:19:52,150 --> 00:19:54,280 by a protocol like the one I've shown here. 364 00:19:54,280 --> 00:19:56,834 In practice on the Web, there is a common protocol 365 00:19:56,834 --> 00:19:59,250 that is used to establish the secure communication channel 366 00:19:59,250 --> 00:20:01,510 called SSL, secure sockets layer. 367 00:20:05,370 --> 00:20:12,577 This channel has been authenticated 368 00:20:12,577 --> 00:20:13,410 and is confidential. 369 00:20:19,720 --> 00:20:26,490 It is typically the case, for example, 370 00:20:26,490 --> 00:20:29,890 that there may be some certificate authority, 371 00:20:29,890 --> 00:20:34,320 for example, which B has used to discover keys for W, 372 00:20:34,320 --> 00:20:39,785 to discover a private key to use to talk to the Web server, W. 373 00:20:39,785 --> 00:20:41,910 There is a question, though, that we haven't really 374 00:20:41,910 --> 00:20:59,970 got at which is how does W know that B is authorized to access? 375 00:20:59,970 --> 00:21:11,917 And we hinted at this on the first lecture about security, 376 00:21:11,917 --> 00:21:14,250 but this is the question that we want to try and address 377 00:21:14,250 --> 00:21:15,510 today in a little more detail. 378 00:21:20,560 --> 00:21:23,430 The issue is that once this protocol is established, 379 00:21:23,430 --> 00:21:26,350 these two guys have exchanged a key with each other, this kAB 380 00:21:26,350 --> 00:21:28,110 or kBW. 381 00:21:28,110 --> 00:21:33,494 And this is a shared key that these guys can 382 00:21:33,494 --> 00:21:34,660 communicate with each other. 383 00:21:34,660 --> 00:21:37,440 But basically all that W knows about B 384 00:21:37,440 --> 00:21:42,110 is that this is somebody who has this key. 385 00:21:42,110 --> 00:21:46,200 This is the same B who initiated this connection with me. 386 00:21:46,200 --> 00:21:49,870 W may not have actually checked to go ahead and see 387 00:21:49,870 --> 00:21:55,520 what it is on the server, what services on WB has access to. 388 00:21:55,520 --> 00:21:58,100 So W needs to go ahead and figure out 389 00:21:58,100 --> 00:22:00,400 what it is that B can access. 390 00:22:00,400 --> 00:22:02,910 And these two sort of check all the accesses 391 00:22:02,910 --> 00:22:04,630 that B tries to make on W to make sure 392 00:22:04,630 --> 00:22:09,523 that it is authorized to do so. 393 00:22:14,960 --> 00:22:17,150 If you remember back to the very first lecture, 394 00:22:17,150 --> 00:22:19,580 we talked about how authentication 395 00:22:19,580 --> 00:22:23,020 and authorization work. 396 00:22:23,020 --> 00:22:24,520 We sort of said there are two steps. 397 00:22:24,520 --> 00:22:26,478 Or, in this case, we are going to actually talk 398 00:22:26,478 --> 00:22:31,560 about three steps. 399 00:22:31,560 --> 00:22:42,160 We have three steps or let's call it three authorization 400 00:22:42,160 --> 00:22:43,800 functions. 401 00:22:43,800 --> 00:22:46,150 And these functions actually sort 402 00:22:46,150 --> 00:22:49,030 of share something in common with authentication 403 00:22:49,030 --> 00:22:51,980 because authenticating and authorizing 404 00:22:51,980 --> 00:22:53,740 are sort of intertwined together. 405 00:22:53,740 --> 00:22:55,050 You will see what I mean. 406 00:22:55,050 --> 00:22:57,475 The first step is we need some rendezvous. 407 00:23:00,780 --> 00:23:02,660 When we talk about this, this is the way 408 00:23:02,660 --> 00:23:12,090 that two principles initially set up the access rights 409 00:23:12,090 --> 00:23:13,500 to the particular server. 410 00:23:13,500 --> 00:23:15,999 For example, this is you going to your system administrator 411 00:23:15,999 --> 00:23:17,540 and telling your system administrator 412 00:23:17,540 --> 00:23:18,831 that you would like an account. 413 00:23:18,831 --> 00:23:21,560 He creates an account, he creates a home directly for you 414 00:23:21,560 --> 00:23:24,650 and then you have the rights to access any of the files that 415 00:23:24,650 --> 00:23:26,360 are in your home directly. 416 00:23:26,360 --> 00:23:28,630 So think of rendezvous as setup. 417 00:23:28,630 --> 00:23:31,940 Account creation, you can log onto Amazon dot com 418 00:23:31,940 --> 00:23:34,890 and create an account, for example. 419 00:23:34,890 --> 00:23:38,770 Then there is some other step which 420 00:23:38,770 --> 00:23:40,190 is this verification step. 421 00:23:43,030 --> 00:23:45,700 And verification is simply making sure 422 00:23:45,700 --> 00:23:48,114 that when you reconnect to the system 423 00:23:48,114 --> 00:23:49,780 you are allowed to connect to the things 424 00:23:49,780 --> 00:23:51,900 that you want to connect to. 425 00:23:51,900 --> 00:23:53,700 Typically, in an authorization system, 426 00:23:53,700 --> 00:23:59,580 we talk about this thing mediating your communication 427 00:23:59,580 --> 00:24:02,420 with the Web server. 428 00:24:02,420 --> 00:24:04,120 If I log onto Amazon dot com and say 429 00:24:04,120 --> 00:24:07,557 that I would like to log in as a particular user, 430 00:24:07,557 --> 00:24:09,390 this verification step is going to make sure 431 00:24:09,390 --> 00:24:11,300 that I have the appropriate credentials 432 00:24:11,300 --> 00:24:14,920 to log on as that user. 433 00:24:14,920 --> 00:24:20,710 The final thing I might want to do is to revoke. 434 00:24:20,710 --> 00:24:23,130 I might want to simply remove a user from the system 435 00:24:23,130 --> 00:24:25,713 or make it so that the user is no longer a part of the system. 436 00:24:36,360 --> 00:24:44,090 There are two widely sort of used approaches 437 00:24:44,090 --> 00:24:48,780 for authentication that sort of do different things 438 00:24:48,780 --> 00:24:50,280 at these different steps. 439 00:24:50,280 --> 00:24:52,800 The two approaches are called lists and tickets. 440 00:24:59,060 --> 00:25:01,030 Authorization. 441 00:25:01,030 --> 00:25:02,260 We have these two approaches. 442 00:25:02,260 --> 00:25:05,250 The first one we are going to call lists and the second one 443 00:25:05,250 --> 00:25:06,060 is called tickets. 444 00:25:12,250 --> 00:25:13,680 And we have these three steps. 445 00:25:13,680 --> 00:25:21,820 We have our setup step, we have our mediation step 446 00:25:21,820 --> 00:25:23,730 and we have our revocation step. 447 00:25:26,780 --> 00:25:31,910 Lists are something you may be familiar with. 448 00:25:31,910 --> 00:25:34,030 One way that we might authorize whether or not 449 00:25:34,030 --> 00:25:36,300 a user is allowed to access a system 450 00:25:36,300 --> 00:25:40,010 is to check some list of all the users who are allowed access, 451 00:25:40,010 --> 00:25:43,350 and we may check that user's credentials. 452 00:25:43,350 --> 00:25:45,320 For example, if you go to a party 453 00:25:45,320 --> 00:25:48,950 and that party is invite only and requires 454 00:25:48,950 --> 00:25:53,570 you to show your MIT ID at the door, you show up at the door, 455 00:25:53,570 --> 00:25:56,420 you show them your MIT ID and then that lets you in. 456 00:25:56,420 --> 00:26:02,854 And now you've been sort of authorized to access the party. 457 00:26:02,854 --> 00:26:04,770 The other approach is a ticket-based approach. 458 00:26:04,770 --> 00:26:07,160 This is an approach where instead 459 00:26:07,160 --> 00:26:10,090 of having a list of people and checking credentials 460 00:26:10,090 --> 00:26:13,280 whenever the person wants access, instead 461 00:26:13,280 --> 00:26:15,330 you have some ticket which lets anybody who 462 00:26:15,330 --> 00:26:17,210 has that ticket have access. 463 00:26:17,210 --> 00:26:19,130 This is a party is invitation only. 464 00:26:19,130 --> 00:26:20,700 You get an invitation in the mail. 465 00:26:20,700 --> 00:26:22,670 And now anybody who has that invitation 466 00:26:22,670 --> 00:26:24,090 can go ahead and go to the party. 467 00:26:24,090 --> 00:26:25,673 You guys are all familiar with systems 468 00:26:25,673 --> 00:26:28,460 that work like that, baseball games, 469 00:26:28,460 --> 00:26:30,722 carnival games or whatever it is. 470 00:26:30,722 --> 00:26:32,430 You get tickets and you use those tickets 471 00:26:32,430 --> 00:26:33,554 to get access to something. 472 00:26:33,554 --> 00:26:35,910 And anybody who has those tickets can use them. 473 00:26:35,910 --> 00:26:38,430 There is no checking of your sort of credentials every time 474 00:26:38,430 --> 00:26:41,054 you try to use them. 475 00:26:41,054 --> 00:26:42,470 As we're going to see, and we will 476 00:26:42,470 --> 00:26:44,011 talk about how this works on the Web, 477 00:26:44,011 --> 00:26:45,770 it is often the case that you use 478 00:26:45,770 --> 00:26:48,150 one of these list-based authentication systems 479 00:26:48,150 --> 00:26:50,859 to decide who we should issue tickets to. 480 00:26:50,859 --> 00:26:52,650 And then you give a bunch of people tickets 481 00:26:52,650 --> 00:26:55,139 and anybody can do whatever they want with those tickets. 482 00:26:55,139 --> 00:26:57,430 Let's talk about sort of the properties of these things 483 00:26:57,430 --> 00:26:58,930 and a little bit about how they work 484 00:26:58,930 --> 00:27:02,430 in the context of a computer system. 485 00:27:02,430 --> 00:27:04,710 The setup process and list is obviously 486 00:27:04,710 --> 00:27:09,330 you add someone to a list. 487 00:27:09,330 --> 00:27:11,690 Passwords typically are done with list-based systems. 488 00:27:11,690 --> 00:27:13,950 The idea is when you add somebody to a password list 489 00:27:13,950 --> 00:27:17,420 you input their name or their account name 490 00:27:17,420 --> 00:27:20,870 and a cryptographic hash of the password that they typed in. 491 00:27:20,870 --> 00:27:22,840 Usually, you want them to type the password in, 492 00:27:22,840 --> 00:27:24,120 in some secure fashion. 493 00:27:24,120 --> 00:27:26,370 You put the cryptographic hash of that password there. 494 00:27:28,880 --> 00:27:31,530 And then, in order to mediate, in order to actually verify, 495 00:27:31,530 --> 00:27:34,090 for example, that the password is going to be correct, 496 00:27:34,090 --> 00:27:39,370 you are going to search the list and you 497 00:27:39,370 --> 00:27:43,940 are going to verify that the password that they present, 498 00:27:43,940 --> 00:27:47,690 in fact, hashes to the stored hash in the password file. 499 00:27:47,690 --> 00:27:49,870 You are going to search the list and you're 500 00:27:49,870 --> 00:27:53,350 going to also do this sort of check credentials step 501 00:27:53,350 --> 00:27:57,390 and make sure the password is what it was supposed to be. 502 00:27:57,390 --> 00:27:59,510 It is relatively easy then, in this environment, 503 00:27:59,510 --> 00:28:01,060 to revoke somebody's access. 504 00:28:01,060 --> 00:28:02,520 You can remove them from list. 505 00:28:02,520 --> 00:28:06,724 And then, in that case, well, they 506 00:28:06,724 --> 00:28:08,390 won't be able to use the system anymore. 507 00:28:12,855 --> 00:28:13,355 Tickets. 508 00:28:17,750 --> 00:28:19,950 The idea in a ticket-based system 509 00:28:19,950 --> 00:28:23,430 is that you are going to generate a ticket. 510 00:28:28,389 --> 00:28:30,430 And usually what that means in a computer system, 511 00:28:30,430 --> 00:28:32,990 or the simplest way to generate a ticket in a computer system 512 00:28:32,990 --> 00:28:40,420 is to make a sort of hard to guess number. 513 00:28:40,420 --> 00:28:46,444 For example, this might be a hash of something 514 00:28:46,444 --> 00:28:48,110 or it might just be a big random number. 515 00:28:48,110 --> 00:28:50,209 You want it to be something that if somebody picks 516 00:28:50,209 --> 00:28:51,750 another random number out of thin air 517 00:28:51,750 --> 00:28:53,570 they don't have a very high probability of guessing 518 00:28:53,570 --> 00:28:56,050 a number that actually allows them to access the system, 519 00:28:56,050 --> 00:28:58,472 but anybody who has this ticket should 520 00:28:58,472 --> 00:29:00,430 be able to access the system relatively easily. 521 00:29:04,940 --> 00:29:07,880 Because these tickets are just, for example, 522 00:29:07,880 --> 00:29:10,480 a big random number, users typically 523 00:29:10,480 --> 00:29:12,210 should feel free to share these, might 524 00:29:12,210 --> 00:29:14,130 be able to exchange these tickets with each other. 525 00:29:14,130 --> 00:29:16,255 They should be able to share them with other people 526 00:29:16,255 --> 00:29:17,410 and use them for access. 527 00:29:17,410 --> 00:29:20,034 Whereas, users typically are not going to share their passwords 528 00:29:20,034 --> 00:29:20,850 with other people. 529 00:29:20,850 --> 00:29:23,190 Tickets are a way that a user can handoff 530 00:29:23,190 --> 00:29:26,300 sort of the authority, the right to access 531 00:29:26,300 --> 00:29:30,260 a system to some other user, they can delegate. 532 00:29:30,260 --> 00:29:34,040 Now, to mediate we are just going to look up, 533 00:29:34,040 --> 00:29:37,110 this is just going to be a table lookup. 534 00:29:37,110 --> 00:29:41,570 We just need to make sure that this is a valid number that 535 00:29:41,570 --> 00:29:42,870 was, in fact, given to us. 536 00:29:42,870 --> 00:29:45,660 And, typically, we don't have to go and check credentials. 537 00:29:45,660 --> 00:29:49,320 The user doesn't have to supply a password when they supply us 538 00:29:49,320 --> 00:29:51,040 with a ticket. 539 00:29:51,040 --> 00:29:55,600 And then, finally, in order to revoke, 540 00:29:55,600 --> 00:30:01,999 well, we might be able to invalidate a ticket. 541 00:30:01,999 --> 00:30:04,040 You might be able to say, for example, remove her 542 00:30:04,040 --> 00:30:06,010 from the table. 543 00:30:06,010 --> 00:30:08,070 That works fine if we're OK with getting rid 544 00:30:08,070 --> 00:30:09,560 of an entire ticket. 545 00:30:09,560 --> 00:30:11,890 But suppose, for example, that I want 546 00:30:11,890 --> 00:30:15,690 to revoke the right of a single user to access the system. 547 00:30:15,690 --> 00:30:18,460 That is very hard to do in a ticket-based system. 548 00:30:18,460 --> 00:30:21,180 Suppose that you guys decide that you no longer want 549 00:30:21,180 --> 00:30:24,520 me looking at some discussion board about 6.033 550 00:30:24,520 --> 00:30:25,770 that you've set up. 551 00:30:25,770 --> 00:30:27,450 And suppose because you're writing bad things about me 552 00:30:27,450 --> 00:30:28,710 and you say, well, we don't want the professor 553 00:30:28,710 --> 00:30:30,126 to be able to access this anymore. 554 00:30:30,126 --> 00:30:31,870 So you try and revoke my access. 555 00:30:31,870 --> 00:30:33,620 If you've been using a ticket-based system 556 00:30:33,620 --> 00:30:35,440 that is going to be very hard unless you 557 00:30:35,440 --> 00:30:36,824 invalidate that ticket. 558 00:30:36,824 --> 00:30:39,240 And there are many people who are sharing the same ticket. 559 00:30:39,240 --> 00:30:41,377 That's going to be hard to deny me access 560 00:30:41,377 --> 00:30:43,460 because you're going to have to revoke that ticket 561 00:30:43,460 --> 00:30:45,084 and then go to everybody else who might 562 00:30:45,084 --> 00:30:47,910 be sharing that ticket and issue them a new one. 563 00:30:47,910 --> 00:30:51,070 Whereas, in this sort of list-based system 564 00:30:51,070 --> 00:30:53,280 you could have just removed my account. 565 00:30:53,280 --> 00:30:57,280 This has an analogy in the real world. 566 00:30:57,280 --> 00:31:04,350 For example, door locks are sort of like a ticket-based system. 567 00:31:04,350 --> 00:31:06,215 You generate a physical key for something. 568 00:31:06,215 --> 00:31:07,840 You could give that out to many people, 569 00:31:07,840 --> 00:31:09,980 and then many people can have access to your house. 570 00:31:09,980 --> 00:31:11,771 The problem is if you want to revoke access 571 00:31:11,771 --> 00:31:15,292 to a single person then you have to sort of go and either 572 00:31:15,292 --> 00:31:17,750 collect the keys from everybody, which may not be feasible, 573 00:31:17,750 --> 00:31:20,760 or change the door locks which denies everybody 574 00:31:20,760 --> 00:31:25,386 access until you reissue keys to the people who need them. 575 00:31:25,386 --> 00:31:27,510 If you like, you can think of a ticket-based system 576 00:31:27,510 --> 00:31:38,750 sort of like being door locks in a house. 577 00:31:38,750 --> 00:31:42,820 Oftentimes lists are more formally called 578 00:31:42,820 --> 00:31:45,500 ACLs or access control lists. 579 00:31:45,500 --> 00:31:52,280 You will see this term used in the text, in fact, as well. 580 00:31:52,280 --> 00:31:54,750 And tickets are sometimes called capabilities. 581 00:31:58,420 --> 00:32:00,650 Capabilities are sort of the right 582 00:32:00,650 --> 00:32:02,560 to access some resource on the computer that 583 00:32:02,560 --> 00:32:05,600 can be delegated from one user to the other or one principle 584 00:32:05,600 --> 00:32:08,030 to the other. 585 00:32:08,030 --> 00:32:10,070 And, in practice, what we see both, as I said, 586 00:32:10,070 --> 00:32:11,980 in the real world and in computer systems 587 00:32:11,980 --> 00:32:13,355 is that we are often going to use 588 00:32:13,355 --> 00:32:18,990 this list-based mechanisms to decide who to hand tickets out 589 00:32:18,990 --> 00:32:21,600 to. 590 00:32:21,600 --> 00:32:23,320 In the case of, OK, who are we going 591 00:32:23,320 --> 00:32:24,450 to invite to our party, who are we 592 00:32:24,450 --> 00:32:26,200 going to send invitations to in the mail, 593 00:32:26,200 --> 00:32:28,560 well, you might have some list that you go ahead 594 00:32:28,560 --> 00:32:31,270 and assemble based on either people 595 00:32:31,270 --> 00:32:34,190 who you know to be MIT students or people who 596 00:32:34,190 --> 00:32:36,740 meet some particular set of eligibility criteria. 597 00:32:36,740 --> 00:32:38,900 That is the sort of process of checking a list. 598 00:32:38,900 --> 00:32:40,700 And then, once you've assembled the list, 599 00:32:40,700 --> 00:32:42,360 you are going to generate these tickets and send them out, 600 00:32:42,360 --> 00:32:43,984 and then anybody can use those tickets. 601 00:32:47,910 --> 00:32:51,660 This same analogy sort of holds true in the Internet, 602 00:32:51,660 --> 00:32:55,220 so let's look at how we might build up an authorization 603 00:32:55,220 --> 00:32:59,380 system on top of our secure channel between our browser 604 00:32:59,380 --> 00:33:01,330 and our Web server. 605 00:33:01,330 --> 00:33:05,030 We have our B talking over our secure channel of our Web 606 00:33:05,030 --> 00:33:07,540 server. 607 00:33:07,540 --> 00:33:09,950 And the idea is going to be as follows. 608 00:33:09,950 --> 00:33:16,080 This Web server has some service that the user wants 609 00:33:16,080 --> 00:33:18,667 to try and access, and we are going to have this guard. 610 00:33:18,667 --> 00:33:20,750 Remember, we talked about this guard model before. 611 00:33:20,750 --> 00:33:22,270 There is going to be some guard that 612 00:33:22,270 --> 00:33:24,380 sits in front of this service that 613 00:33:24,380 --> 00:33:30,040 is in charge of authorizing B to access this service. 614 00:33:30,040 --> 00:33:34,980 And then there is some authorization module 615 00:33:34,980 --> 00:33:37,170 that runs on B. 616 00:33:37,170 --> 00:33:41,380 The idea is that B is going to initiate a connection 617 00:33:41,380 --> 00:33:44,110 and then guard is going to send a message to the authorization 618 00:33:44,110 --> 00:33:49,700 module on B saying who are you, what are your credentials 619 00:33:49,700 --> 00:33:50,900 to access this system? 620 00:33:50,900 --> 00:33:53,925 This is going to be a form of list-based access. 621 00:34:00,770 --> 00:34:05,660 Now, this module on B is going to go ahead and send 622 00:34:05,660 --> 00:34:12,139 a message back that says my name is, whatever my name is, 623 00:34:12,139 --> 00:34:16,900 as well as some key, some credential like, for example, 624 00:34:16,900 --> 00:34:20,630 a password that is their password for accessing 625 00:34:20,630 --> 00:34:22,150 this system. 626 00:34:22,150 --> 00:34:28,030 Notice that these two guys do not 627 00:34:28,030 --> 00:34:31,431 need to worry about sort of protecting this channel, as 628 00:34:31,431 --> 00:34:33,639 far as the rest of the Internet is already concerned, 629 00:34:33,639 --> 00:34:36,360 because they have already established this secure channel 630 00:34:36,360 --> 00:34:38,630 upon which they can do this exchange of information. 631 00:34:38,630 --> 00:34:41,769 So they are hopefully not worried about other people 632 00:34:41,769 --> 00:34:42,810 overhearing this message. 633 00:34:42,810 --> 00:34:45,310 They may not need to protect this information that 634 00:34:45,310 --> 00:34:46,810 is being transmitted in the same way 635 00:34:46,810 --> 00:34:49,909 because they have already got the secure communication 636 00:34:49,909 --> 00:34:51,960 channel that they have established at the lower 637 00:34:51,960 --> 00:34:52,900 levels of this thing. 638 00:34:52,900 --> 00:34:54,570 All of this communication is going 639 00:34:54,570 --> 00:34:57,330 over this secure communication channel between these two guys. 640 00:34:57,330 --> 00:34:59,330 This is a layer that is built on top 641 00:34:59,330 --> 00:35:03,350 of this secure communication layer. 642 00:35:03,350 --> 00:35:06,820 Now what happens is that what the guard is going to do 643 00:35:06,820 --> 00:35:10,270 is look up this name and password, for example, 644 00:35:10,270 --> 00:35:12,020 in some access control list and use 645 00:35:12,020 --> 00:35:14,264 that to determine whether or not this person has 646 00:35:14,264 --> 00:35:15,680 the rights to access and what they 647 00:35:15,680 --> 00:35:17,389 have the rights to access to. 648 00:35:17,389 --> 00:35:19,180 And he is going to generate for this person 649 00:35:19,180 --> 00:35:22,180 a set of tickets that represent the sort of services 650 00:35:22,180 --> 00:35:24,550 that this person can access on this system. 651 00:35:24,550 --> 00:35:27,380 He is going to have some table of tickets, 652 00:35:27,380 --> 00:35:31,480 and this table is going to have the ticket 653 00:35:31,480 --> 00:35:36,630 number and the resource, for example, that the user is 654 00:35:36,630 --> 00:35:38,630 allowed to access. 655 00:35:38,630 --> 00:35:44,591 So he is going to send back some ticket number authNo back 656 00:35:44,591 --> 00:35:45,090 to the user. 657 00:35:45,090 --> 00:35:48,220 So we are going to add authNo. 658 00:35:48,220 --> 00:35:52,410 And then maybe this gives him the right 659 00:35:52,410 --> 00:35:58,050 to access some account, B's account information. 660 00:35:58,050 --> 00:35:59,840 Now, with this authorization information, 661 00:35:59,840 --> 00:36:00,631 this is the ticket. 662 00:36:03,680 --> 00:36:06,760 Now every time that B wants to go ahead and access 663 00:36:06,760 --> 00:36:15,970 his account, for example, he can read account B 664 00:36:15,970 --> 00:36:17,934 and then he just passes the ticket. 665 00:36:17,934 --> 00:36:19,600 And he can use this ticket over and over 666 00:36:19,600 --> 00:36:22,050 and over again to access the account for as long 667 00:36:22,050 --> 00:36:23,870 as the ticket is valid. 668 00:36:23,870 --> 00:36:28,280 Often times there will be a timeout 669 00:36:28,280 --> 00:36:30,394 associated with tickets. 670 00:36:30,394 --> 00:36:31,810 But as long as the ticket is valid 671 00:36:31,810 --> 00:36:33,930 he can go ahead and supply this ticket in order 672 00:36:33,930 --> 00:36:36,590 to be able to access the resource that the ticket gives 673 00:36:36,590 --> 00:36:37,250 him access to. 674 00:36:37,250 --> 00:36:40,830 And he doesn't have to sort of re-authenticate himself. 675 00:36:40,830 --> 00:36:43,530 He doesn't have to represent his credentials every time 676 00:36:43,530 --> 00:36:53,220 he wants to access this resource on his account on the Web 677 00:36:53,220 --> 00:36:54,300 server. 678 00:36:54,300 --> 00:36:56,701 Are the HKN people here? 679 00:36:56,701 --> 00:36:57,200 Yes. 680 00:36:57,200 --> 00:36:57,700 OK. 681 00:36:57,700 --> 00:36:58,620 We need to do HKN. 682 00:36:58,620 --> 00:37:01,290 Why don't you just give me one more minute to wrap up and then 683 00:37:01,290 --> 00:37:03,930 we can go ahead and do the HKN review. 684 00:37:07,900 --> 00:37:13,640 This protocol, I mentioned that this is sort of like SSL, 685 00:37:13,640 --> 00:37:15,450 or the SSL works in sort of this way. 686 00:37:18,790 --> 00:37:20,990 On the Internet you may have heard about cookies. 687 00:37:20,990 --> 00:37:26,460 Cookies on the Web are essentially a kind of ticket. 688 00:37:26,460 --> 00:37:28,120 The idea with most cookie-based systems 689 00:37:28,120 --> 00:37:29,370 is you log in with a password. 690 00:37:29,370 --> 00:37:31,244 And then, when you log in with that password, 691 00:37:31,244 --> 00:37:32,670 the system issues you a cookie. 692 00:37:32,670 --> 00:37:34,586 And then when you want to re-access the system 693 00:37:34,586 --> 00:37:36,922 you simply supply the cookie. 694 00:37:36,922 --> 00:37:38,380 If you were to look at the contents 695 00:37:38,380 --> 00:37:40,590 of a prototypical cookie, it would typically 696 00:37:40,590 --> 00:37:44,110 have something like, for example, 697 00:37:44,110 --> 00:37:46,980 the user's name and some timeout, 698 00:37:46,980 --> 00:37:49,720 a valid period for the cookie, as well as 699 00:37:49,720 --> 00:37:58,210 a hash of the user's name, that timeout and some, 700 00:37:58,210 --> 00:38:03,900 for example, random number which is only known over here 701 00:38:03,900 --> 00:38:04,960 at the service. 702 00:38:04,960 --> 00:38:07,180 The service is going to protect this random number 703 00:38:07,180 --> 00:38:09,180 and is going to hash it together with the user's 704 00:38:09,180 --> 00:38:10,832 ID and this timeout. 705 00:38:10,832 --> 00:38:12,540 And so now, when this cookie is supplied, 706 00:38:12,540 --> 00:38:16,400 it is going to be hard for users to generate fake cookies, 707 00:38:16,400 --> 00:38:19,150 but these cookies are going to allow the user 708 00:38:19,150 --> 00:38:21,910 to go ahead and access the services on W without having 709 00:38:21,910 --> 00:38:23,490 to re-authenticate every time. 710 00:38:23,490 --> 00:38:25,910 And you can, in fact, in some cookie systems 711 00:38:25,910 --> 00:38:26,744 share those cookies. 712 00:38:26,744 --> 00:38:28,993 You could copy the cookie from one browser to another, 713 00:38:28,993 --> 00:38:30,770 and you might be able to reuse that cookie 714 00:38:30,770 --> 00:38:33,510 to access the system for as long as the cookie is valid. 715 00:38:33,510 --> 00:38:35,540 Cookies typically timeout after an hour or two, 716 00:38:35,540 --> 00:38:37,414 and so then you would have to re-authenticate 717 00:38:37,414 --> 00:38:39,810 with the system. 718 00:38:39,810 --> 00:38:44,242 That is all I wanted to really say about authentication. 719 00:38:44,242 --> 00:38:46,200 What we are going to do is talk about some sort 720 00:38:46,200 --> 00:38:48,890 of advanced protocols next time. 721 00:38:48,890 --> 00:38:51,900 I want to remind you guys that there 722 00:38:51,900 --> 00:38:55,130 is no class on this Wednesday so don't come here. 723 00:38:55,130 --> 00:38:57,890 The next class is next Monday. 724 00:38:57,890 --> 00:39:00,390 And that is it. 725 00:39:00,390 --> 00:39:04,330 Good luck finishing your DP2 and have fun doing HKN reviews.