MIT course "Computer Systems Security". Lecture 13: "Network Protocols", part 2

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: “Introduction: threat models” Part 1 / Part 2 / Part 3
Lecture 2: “Controlling hacker attacks” Part 1 / Part 2 / Part 3
Lecture 3: “Buffer overflow: exploits and protection” Part 1 /Part 2 / Part 3
Lecture 4: “Privilege Separation” Part 1 / Part 2 / Part 3
Lecture 5: “Where Security System Errors Come From” Part 1 / Part 2
Lecture 6: “Capabilities” Part 1 / Part 2 / Part 3
Lecture 7: “Native Client Sandbox” Part 1 / Part 2 / Part 3
Lecture 8: “Network Security Model” Part 1 / Part 2 / Part 3
Lecture 9: “Web Application Security” Part 1 / Part 2/ Part 3
Lecture 10: “Symbolic execution” Part 1 / Part 2 / Part 3
Lecture 11: “Ur / Web programming language” Part 1 / Part 2 / Part 3
Lecture 12: “Network security” Part 1 / Part 2 / Part 3
Lecture 13: “Network Protocols” Part 1 / Part 2 / Part 3

Student: the client cannot decrypt this ticket because it is encrypted using the service key.

Professor: yes, that is really smart, isn't it? We have the key Kc, s which the client can receive, but here, in the ticket Tc, s there is another copy of this key encrypted with Ks.



The reason this is done is that the Kerberos server is actually trying to ensure the security of the client’s communication with the other guy. Therefore, Kerberos creates a random key Kc, s and gives one copy to the client, and another to the server with which the client is going to talk. Imagine that Kerberos would just turn to the service with the words: “hey, service, this guy wants to talk to you, here's the key for this”! This would be regrettable because the Kerberos server would contact the service again and again with every request. So KDS creates 2 copies of the session key: one for the client and the other for the TGS.

Therefore, instead, the developers have come up with a good trick, where they provide the client with this ticket, and he cannot do anything with him except to contact him to the correct service. And if this service has the correct Ks key, it will decrypt it and say: “Yeah, this is the key that I have to use to talk to this client.” Thus, both parties to the connection, the client and the service, will establish a common key to protect their connection.

Student: so what is TGS?

Professor: There are two views of what constitutes a TGS. From the client’s point of view, this is just another service for which you can get a ticket. The more features this service provides, the more tickets it provides. In fact, this is a service for issuing tickets.

Student: sorry, I meant that we have a ticket called TGS.

Professor: Oh, yes, I'm sorry, the tgs under the arrow on this diagram is just an abbreviation for the entire recording block, except for the index s in the parameter Tc, s, which means the actual name of this service - TGS. You can imagine that we have a Kerberos server, there is this TGS service and there is a real service that you want to reach. So first you have to ask Kerberos to provide you with a ticket to gain access to a particular service.



You could ask Kerberos to give you a ticket directly to the file server, and this might work. But for this you would need your Kc to decrypt and use the server for the rest of the time. Instead, you get a ticket for a special TGS service. It looks the same as other services, except that it is located in a separate box. And he will be happy to give you more tickets later without re-providing your original client key Kc.

Student: his idea is that once you get a TGS ticket, can you just get rid of your Kc key?

Professor:Yes, the great thing about this is that as soon as you get this ticket Tc, s from the TGS service, you get rid of the password and key Kc. Thus, as soon as you log in to the Athena workstation and after a couple of seconds get a ticket Tc, s, your password is deleted from the memory. So even if someone grabs you, takes the computer and runs away with it, all he has is your ticket. It is good if he can get access to your information for 10 hours, or for the period of the ticket validity, but not longer, because the password has not been saved and the next time you log in to Athena, you will need to enter it again.

The only time a password is needed is when you send a request to the Kerberos server, you receive this reply with a ticket and decrypt it. After that, you can forget about the password. But of course, you cannot drop the password before using it for decryption.
Thus, the first, upper interface C on our scheme is used to obtain a ticket with the initial key Kc, and the second, lower interface S - to access the services, but without the need to obtain the initial key Kc.



So, we have already talked about two specific problems of the Kerberos protocol that seem to be built into it, which caused some inconvenience. First, the creators assumed that encryption would also provide authentication or message integrity, but this did not happen. This flaw is fixed in Kerberos version 5, where explicit message authentication is performed. Secondly, for arbitrary customers they had the ability to guess the passwords of other people.

How can I fix this? How to prevent attacks by guessing password in protocols of this type? What can we try?

Student: I'm not sure, but you can try to "salt" the password.

Professor:“Salting” simply means that the client may need to hash the password in different ways. But it does not hurt to try to pick it up. So, perhaps, it will be more expensive to build a dictionary.

Student: You can try to complicate the function of calculating the password.

Professor: Yes, another good idea is to make the hashing process very expensive. Perhaps this is reasonable. Therefore, if this hash function takes a second of computational time, as you guys did in the second lab, in this case, the selection of passwords would be very expensive. So it seems like a reasonable plan - to use a combination of salting and complicating the guessing process.

Another way to protect can be complicating the answer. You have heard that in the first versions of the protocol, the Kerberos server did not have the slightest idea whether the correct client accesses it or not. What you could do is provide proof that you are the right client, that is, encrypt the current timestamp with the password hash, or something like that. Then the Kerberos server could just verify the validity of these things, and if they match, provide you with a ticket.

You probably don’t want to add more verification steps, but this may work. For now, suppose you can take a timestamp and hash it along with the Kc key, and in addition, just add a timestamp.



In this case, the server can see that it has your Kc key and it can also hash the current timestamp. If it receives the same value, then the request is probably made by the correct user to whom you can send a ticket. If not, it was the wrong password.

Student: you can simply limit the issuance of tickets, if the servers record too many requests for their provision.

Professor:quite right, we can introduce a restriction. However, there is no reason for a hacker to request a ticket on the server more than once. It simply requests a specific user, receives this encrypted block from it and can try to decrypt it offline as many times as he wants, with different passwords without a second request. Therefore, I think that the whole point of protection is that the server should somehow react to the number of calls if the attacker repeatedly requests the server, trying to log in with different passwords. In this case, the limit of requests can be reached, which will provide better protection against hacking.

Student: how can an attacker send a request to a Kerberos server?

Professor:I think he could reproduce the message of the correct user, that is, see it, copy it, send it and also receive a response from the Kerberos server. If the hacker scans the network, he can intercept the message during the transfer. So limiting the number of requests is a temporary measure, which only slightly increases security. But, of course, if you are viewing a foreign network, you will see how this packet is returned from the server, regardless of what happened during the formation of Tc, s. So the hacker can see the server’s response to the client and try to attack him.

There are probably more complex schemes that you could develop, but I don’t think that Kerberos 5 implements something more complicated than the plan we’ve considered that seems good enough not to allow random people to try to break something or use brute- force to crack the password.

Student: Suppose you can provide authentication or something else to establish a shared key. And then you can encrypt this item and the shared key with Kc.

Professor: yes it is. If you really do it right, then there is a protocol called Password Authenticated Key Exchange, PAKE, which performs password authentication. This is exactly what happens in Kerberos.



You can see in Google what SRP or PAKE protocols are for. These protocols and related elements do much better with your task, in which you must prove to both parties that you have installed a new key. At the same time, both parties must be convinced that each other is correct and that there is no way to guess this password offline and make an attack on the set of network packets that you watch, and so on.

These are protocols that rely heavily on cryptography, so it’s hard to explain on the board why they work.

Student:One of the reasons why developers did this is that they wanted to support the ability to send only a password. And the protocols just allow you to send only one thing as an authenticator.

Professor: yes, there are a lot of strange requirements that these guys took into account. Of course, in practice, these servers can accept both Kerberos connections and non-Kerberos connections. And for non-Kerberos connections, you get the picture as if someone is connecting to the mail server, but does not use the Athena workstation. He just wants to send his password.



And then the email client here, let's say, is going to take this password and get a ticket on your behalf only to verify it, which will allow you to use this email client. So, probably, you still want Kerberos itself to check Kerberos passwords. I don't think this is excluded, because, of course, Kerberos 5 deploys this time stamp hashes and all that.

I think another thing that you should pay attention to in the lecture materials is that the Kerberos 4 developers chose one encryption scheme - DES, the most popular encryption algorithm of the time. This is a symmetric block cipher, quite fast. At that time, he ensured sufficient security, and they simply incorporated it into the protocol.

Everything in Kerberos should have only used DES, or at least everything in Kerberos version 4. This became problematic because now, 25-30 years later, DES encryption is easily cracked by the brute-force method, since encryption keys have very small size - only 56 bits.

Therefore, you can simply create some kind of user equipment that will calculate 2 to 56 degrees of combinations and find out the real password. This is what you want to avoid in any protocol being developed in our time.

Kerberos version 5 supports several different encryption schemes, including AES and other cryptographic algorithms. So this seems like a much better way to ensure security. On the other hand, MIT continued to support DES 2 years ago, but now it refused, so today your rector is protected, at least, from this type of attack. Now let's look at what happens in the TGS service from which you get a ticket. Interaction with this service looks a bit different.

On the one hand, as a client, you are going to talk to him as if you were talking to any other service with Kerberos support. Consider how you perform your own authentication with a ticket to some machine. But the answer that you are going to return is just a ticket to some other principle, on the basis of which you will communicate, for example, with a file server.

Therefore, protocol level messages will look like this - on the right I will draw the TGS, and on the left - the client. The client already has a ticket for the TGS, obtained using the protocol shown above.



Now the client is going to send certain combinations of messages that prove that he is the right client, and these messages are related to issuing a request on a particular principle through the TGS.

So, the client is going to send the following message to the TGS: S is the service with which he is going to communicate, it can be a mail server or a file server, then the Tc client ticket that he received for tgs, encrypted using the K tgs key, and here an authenticator that is encrypted with the Kc, tgs key common to the client and the TGS service. This is what a message that you are going to send to the TGS looks like - it says: “look at this message, do something with it and reply with a ticket to this new service S”. The answer here is almost the same as in the picture above, and in fact it is the same - this is the ticket between the client and this new service, encrypted with Ks. But now it has become a little different.



Instead of encryption with the Kc key, which the client probably forgot since then, encryption is now performed using the shared key Kc, tgs between the client and the TGS service.

How does the server find out what the client wants and how the server authenticates the client? The TGS server knows its own Ktgs key, so first it is going to decrypt this message Tc, tgs, look inside the ticket and find out what is going on. Why do we need all these fields in the ticket? Why is it so important to have the server name S on the ticket? What would have gone wrong if we didn’t have s?

Student: if it was not, then you could potentially get permission to use any server.

Professor:Yes it is. In general, it is a good idea to do it in network protocols so that you can say exactly what this message means. In case you omit S, you can rely on the fact that if you use a ticket for an incorrect S, then maybe you will have another Ks key and it will not be able to decrypt or something like that. So it seems like a good idea - to include the name of the service in order to make sure that the server that receives these tickets, decrypts them and checks - is this a ticket for me or for someone else?

Student: What does the client do with the Ktgs key obtained?

Professor:good question! The customer has no idea what it is. Because it is a top secret key. If you knew him, you would be able to hack the entire Kerberos. So the client has no idea what Ktgs is.

Student: where does this Ktgs come from?

Professor: the Kerberos server itself generates for you all this message, which already has Tc, tgs and Ktgs, you do not create it yourself, but simply copy it from here.

So why is the name of the client so important? It's easy to figure out. If you don’t put the client’s name on the ticket, then the server receives the message, but has no idea who it is trying to talk to. He does not know for whom he must issue a ticket - for you or for someone else.

And what about the other fields? Why do developers insert Tc, s address addr into a ticket? This is simply the client's IP address, so why not use it directly?



I think that the meaning of this decision is the desire of developers to increase security. They wanted to make sure that if the client logged in from some IP address, then everything else on the same ticket comes from the same IP address. For example, if you are logged in from some IP address, for example, 18.26.4.9, then each connection to a file or mail server must be from the same IP address. Otherwise, the server should reject your connection, as it may suggest that someone stole your ticket. In this way, we defend ourselves against the use of stolen tickets. If you still have the same ticket - fine, but if you do not use the same IP address, you will fail.

At the moment, this seems like a fallacy, and Kerberos 5 still uses a similar approach, although it is not necessary. Indeed, you should simply rely on cryptography instead of securing the IP address.

And what is the meaning of the timestamp timestamp and life time in the ticket? What are they for and what are they useful for?

Student: they are needed to prevent replay attacks.
Professor: A replay attack helps us prevent the authenticator, because this piece is generated every time you make a new request. But on the other hand, the ticket remains the same, so this, of course, does not interfere with replay attacks.

Student: it prevents someone from stealing your ticket and then using it for their own purposes.
Professor: yes, it simply limits the time during which the ticket is valid, making the damage from his theft reduced. The timestamp is the time when you received the ticket, and the lifetime indicates how many hours this ticket is valid from the initial timestamp. Therefore, if you try to use it too soon or too late, then using the Kerberos protocol, any server must reject such a ticket. This means that each server must synchronize its clock.

Student: Earlier you said that a client can throw away his initial key discards Kc, but must keep Kc, s, received from the TGS.

Professor: yes, this is so, the client drops Kc after logging in, but should keep Kc, s.

Student:so if someone steals Kc, s, then he gets access ...

Professor: yes, let's consider how bad it is? Why is it better for a hacker to reveal this Kc, tgs, than Kc?

Student: if you get to take Ks, s, then you can just steal a session between these two interlocutors, but if you steal Ks, you can impersonate a client.



Professor:quite right. Therefore, the only way to protect is that Kc, s is actually a new key that is created every time you log in. This is good, because you have a Tc, tgs ticket attached to it. If you lose this ticket or it becomes invalid, then you still have these 56 bits in this key Kc, s. But no one is going to use them. The whole point of these bits is that thanks to them the Tc ticket, tgs says that this key is Kc, s is valid at the moment, and there is some kind of restriction in it.

Student: therefore, if someone can steal both of these elements - Tc, tgs, encrypted with the key Kc, tgs, and the key itself Kc, tgs, encrypted with Kc - then it will not be anything limited.

Professor:Yes, if someone steals both of these things, he will be able to impersonate you or, for example, log in to the file or mail server during the lifetime of the ticket, which can be a couple of hours or 10 hours. Stolen Kc can be used without time restrictions, until you change your password.

So, it seems that today all these fields in the ticket seem to be important, except for the representation of the IP address, which does not really affect the security. We finally get this ticket in response, which is shown at the bottom of the diagram, and since we know Kc, tgs, we can decipher the response from the TGS server. Now we have a ticket to any server - a file server, a mail server, whatever server we want to connect to.

Now let's look at how you can finally use all of this in the application-level protocol. Suppose I speak with a mail server to receive my messages. Therefore, my client workstation is going to send the TGS request for a ticket to access the mail, for example, PO12, and the TGS will return the ticket to her with access to the PO12 mail. And inside this ticket, or inside this answer, I now have a shared key Kc, s for the connection between me and the mail server. I will show this ticket to the mail server, and he will make sure that I am the right client and everything in this key corresponds to the right principles. So we will have an encrypted conversation with the mail server using this new key Kc, s.



What I could do as a client is to first send a message to the mail server, which includes a ticket to the mail server Tc, mail, encrypted with the key of the Kmail mail server, and with it send a message about what I need to do with the mail, for example, delete message 5 - DELETE 5, encrypted with the key Kc, mail.



So, what happens in this protocol on the mail server mail? First of all, the mail server uses its Kmail secret key to decrypt this ticket, and then looks inside and finds two important things - the main name of the person who speaks with it, and the Kc key, s, which it must use to decrypt all subsequent traffic and authenticate it to Kerberos 5. After that, it will be able to decrypt your message and say: "Yeah, user C is trying to delete the fifth message, so I will execute this command."

Student: Kerberos server initially sends the ticket Tc, tgs and key Kc, s. Where is the authenticator here?

Professor:Ac identifiers are actually generated by the client. Note that the client only needs the key Kc, s to generate the authenticator, and the client can do this as many times as he wants. Thus, the general plan for authenticators or the reason for using authenticators is to prevent replay attacks.



Thus, in Kerberos 4, every time a client sends a new request, a new authenticator will be created, saying that this is a new request, the client creates it only now and it is different from all previous requests, so you need to do what the client asks.

The overall plan was that the server should have stored the cache of these authenticators that were sent, for example, within the last five minutes. Therefore, if he saw a duplicate authenticator, then he perceived it as an attempt to replay the attack and rejected it. He did the same if he saw an authenticator that is outside the five-minute lifetime and which he did not have in the cache. The server looked at the timestamp in this authenticator, saw that it was out of date, and rejected the request because it was too old. So if the client needs to gain access, let him send a new request.
This is the general plan for the use of authenticators. Like many things from the first version of Kerberos, they were subsequently slightly modified, at least in Kerberos 4. Because this authenticator doesn’t really say anything about your message, it’s just some kind of addition to it.

Thus, the way to use it, for example, in this protocol of the mail server, at least in Kerberos 4, is that you generate an authenticator, take it and also encrypt it with the key Kc, mail. And the mail server will track whether you sent this authenticator in advance or not.



But there is nothing that connects the authenticator with the message you are sending. It was great for the first message, but when you send the next message in a second, you create a second authenticator. In this case, someone on the network can say: “Yeah, I have your new authenticator, I can use it together with the connection with the old DELETE message and thus force the message number 5 to be deleted twice, even if the second command is intended for some another operation. "

Thus, Kerberos 5 grants you the right to insert into the authenticator something related to the command you give. Developers, of course, could initially use such a mechanism, but it took time for them to understand how the protocol should work properly.

Student:Where does the client get Kc, mail?

Professor: the client gets it from this answer.



Because the client, sending a TGS ticket request, means that it is S - the name of the mail service, and the subscript S in the received ticket Tc, s is also mail, and S is in the key Kc, s is also the name of mail . So this Kc, s is actually Kc, mail. This is how the client learns about the key that is common to him and the files on the mail server.

Student: how does the mail server get Kc, mail?

Professor: yes, how does the mail server get this shared key? After all, the mail server may have never heard of you and your connection before. Where does Kc, mail come to the mail server?

Student: Isn't that part of the ticket?

Professor:yeah, right, so this is a cool thing! You send this ticket to the mail server and the mail server recognizes Kmail's own secret key, which it uses to decrypt the ticket Tc, mail, and this shared key is there along with the name of the person with whom it shares the key. This is how the server finds out that it is talking to the guy with whom it should use the shared key.

So, that's what constitutes the main plan for using this protocol when working with applications. But this still has a lot of problems. So it's good to read about Kerberos on paper, but there are problems in it that these guys did not know 30 years ago.
Therefore, it is inevitable that we have problems that you have to solve. So, one interesting problem with Kerberos 4 concerns how messages are encrypted and authenticated for applications. It lies in the fact that it uses the same key to encrypt messages from the client to the server and for response messages from the server to the client.

54:00 min.

The course MIT "Security of computer systems." Lecture 13: "Network Protocols", part 3


Full version of the course is available here .

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only here2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?