This is a dialogue that MIT (MASSACHUSETTS Institute of Technology) in order to help people understand the principle of Kerberos. There are two fictitious characters inside: Athena and Euripides, through Athena Constitutional Conception and Euripides constantly looking for vulnerabilities, you understand the principle of the Kerberos protocol. Athena: Goddess of Athena, Wisdom and Skills. EURIPIDES: Tragedy poet in Europe, Greece. The translation is as follows: The first scene is in a small room. Athena and Euripides are working on adjacent terminals. Athena: Hey, this time the operating system is too slow. I can't work at all, because everyone is boarded.
EURIPIDES: Don't complain about me. I am just working here. ATHENA: Do you know what we need? We need to work for everyone, so you will not worry about the speed of your computer. And, we need a network to join all the computers. EURIPIDES: Ok. Then we are almost a thousand workstations? Athena: Almost. EURIPIDES: Do you know how big is the hard drive of an ordinary workstation? Can't put all the software there. ATHENA: I have already got out. We can put the system software on the server. When you log in to the workstation, the workstation will contact the system software on one of the servers through the network. Such settings allow a set of workstations to use the same system software and is conducive to the upgrade of the system software. Just change the server. EURIPIDES: Ok. What is the personal file? On the Timed Operating System, I can log in and take my file from the terminal. Can I take my files on my workstation? Do I want to put my files on the disk like a PC user? I hope not. Athena: I think we can save files in other machines. You can log in to your file on any machine. EURIPIDES: What should I do? Do you have your own printer every workstation? Who will pay? Email? How do you send your email to all workstations? Athena: Ah ..... very obvious that we have no money to match a printer for everyone, but we have a special machine to make print services. You send the request to the server, it prints you. Email can also do this. Specialized there is a mail server. If you want your email, contact your email and take your email. EURIPIDES: Your workstation system sounds very good. If I have one, do you know what I want? I want to find out your username, let my workstation think I am you. Then I will go to the mail server to take your email. I will connect your file server, remove your file, then - Athena: Can you do it? EURIPIDES: Of course! How can these web servers know that I am not you? Athena: Well, I don't know. I think I need to think about it seriously. EURIPIDES: Ok. When you want to come out, tell me. The second year of Euripides, the next morning. EURIPIDES is sitting next to his desk and reading his email. Athena to knock on the door. Athena: I have already thought about how to protect an open network system, so that people who are not moral people cannot use web services with others. EURIPIDES: Really? sit down. She sat down. Athena: Can I make a convention for our discussion before I start describing? EURIPIDES: What is the agreement? ATHENA: Ok, suppose I said this: "I want my email, so I contact the mail server and ask it to send the email to my workstation." I actually didn't contact the server. I use a program to contact the server and get my email, this program is the client of this service. But I don't want to say when I interact with the server: "How is the client?" I just want to say: "How do I," Remember, the client is on behalf of me. Everything. Is this okay? EURIPIDES: Of course. No problem. Athena: Good. Then I have to start elaborating the problem I solved. In an open network environment, the machine that provides services must be able to identify the identity of the entity that requests the service. If I go to the mail server to apply for my email, the service program must be able to verify that I am the person I declared. EURIPIDES: Yes. Athena: You can solve this problem with a stupid approach: The server allows you to enter your password. I can prove who I am through the input order. EURIPIDES: That is really awkward.
Inside the system like that, every server must know your password. If there is a thousand users, then each server must know a thousand passwords. If you want to change your password, you must contact all servers to inform them to modify your password. I think your system is not so stupid. ATHENA: My system is not so stupid. It is like this work: not if there is a password, and the service also has a password. Each user knows their own password, each service also knows its own password. There is a certification service knows all passwords, users and services. The authentication service saves the password in a separate central database. EURIPIDES: Is this certification service a name? Athena: I haven't thought about it yet. Do you want one? EURIPIDES: Who is the person who sent the dead? Athena: Charon? EURIPIPIDES: Yes, it is him. If he can't confirm your identity, he will not send you to the river. Athena: You have a text, is it to rewrite the Myth of Greek. Charon didn't care about your identity, he just sure you didn't die. EURIPIDES: Do you have a better name? Stop. Athena: No, no. EURIPIDES: Ok, then we will "charon". Athena: Ok, I guess I should describe this system, um? For example, we want a service: email. In my system you can't use a service unless Charon tells the service that you are indeed the person you have declared. That is, you must get Charon's certification to use service. When you ask Charon request authentication, you must tell Charon which service you want to use. If you want to use a message, you have to tell Charon. Charon, please prove your identity. So you give it your password. Charon compares your password and the password in its database. If it is equal, Charon thinks you have passed the verification. Charon now wants the email service to know that you have passed the verification. Since Charon knows all the passwords, it also knows the password of the mail service. Charon gives you the password of the mail service, you can use this password to make the mail service believe that you have passed verification. The problem is that Charon can't give you a password directly because you will know it. Next time you want to mail service, you will bypass Charon's mail service without requiring authentication. You can also pretend that someone will use the email service. So not directly give you the password of your mail service, Charon gives you a "ticket" of the mail service. This ticket contains your name and the name is encrypted with the password of the mail service. Get the ticket, you can request your email to the mail service. You ask your mail service and use your vote to prove your identity. The service uses its own password to decrypt the ticket, if the ticket can be decrypted correctly, the server takes out the username in the ticket. The service compares this name and the username of the fare. If you consistently, the server thinks you pass the verification, send you your email. what do you think? Euripides: I have some problems. I guessed. Speaking. EURIPIDES: How do I know that it is correct when a service decrypts a ticket? ATHENA: I don't know. Euripides: Maybe you should include the name of the service in the ticket. This is when the service is a ticket, it can determine whether the decryption is correct by finding the names you can find in the ticket. ATHENA: Very good. That ticket should be this: (she writes the following things on a piece of paper) ticket - {User Name: Service Name} EURIPIPIDES: That ticket only contains the username and service name? Athena: Encrypts the password of the service. EURIPIDES: I don't think this information can make ticket security. Athena: What do you mean? EURIPIDES: Suppose you request a mail service to Charon.
Charon prepared a ticket with your name "Tina". It is assumed that I will copy a copy during the process of passing by Charon from Charon. Suppose I let my workstation believe that my username is "Tina". The mail client thinks that I am you. Use your name mail customer program to make a request to the mail server with a stolen ticket. The mail server decrypts the ticket and think it is legal. The username of the ticket and the username sending the ticket are matched. The mail server will send me your email. Athena: Oh! That is not very good. Euripides: But I thought of a way to solve this problem. Or some resolution. I think Charon should contain more information in the ticket. In addition to the user name, the ticket should also contain the IP address of the user of the requested ticket. This will add a layer of security. I will show it. Suppose now I have stole your ticket. This votes have the IP address of your workstation, and this address can't get the address of my workstation. Use your name, I will send a stolen ticket to the mail server. The service program solves the username and network address from the vote and try to match the username and network address. User name matches the network address does not match. The server refused this ticket because it was obviously stolen. Athena: Heroes, Heroes! How can I not think. EURIPIDES: Ok, this is what I want to express. Athena: The ticket should be like this. She writes the following things on the blackboard. Ticket - {User Name: Address: Service Name} Athena: Now I am really excited. Let us build a charon system to see if it works! Euripides: Not so fast. I have some problems with your system. ATHENA: Ok. (ATHENA explored the body from her chair). EURIPIDES: It sounds like every time I want to get a service, I have to take a new ticket. If I work all day, I may not only take my email again. Do I take a new ticket every time I take the email? If this is this, I don't like your system. Athena: Ah. . . I don't understand why the ticket cannot be reused. If I have got a ticket for a mail service, I can use it again and again. When the mail client is requested by your name, it has passed a copy of a ticket to the service. EURIPIDES: Some. But I still have problems. You seem to hinted that every time I haven't had a ticket, I have to give Charon my password, I want to take my files. I asked Charon asked my ticket, which means I have to use my password. Then I want to read my email. I sent a request to Charon, I have to lose my password again. Now suppose I want to send my email to print. I have to send a request to Charon. Do you know? Athena: Ah, yes, I understand. Euripides: And if this is not bad enough, think about it: it seems to be like this, when you want to CHARON certification, you will use a clear text to transfer your password on the web. Smart people like you can monitor the network and get the password of others. If I get your password, I can use your name to use any service. Athena sighed. Athena: There is really a serious problem. I think I should go back to the design room. On the morning of the third day, Athena met Euripides between the coffee. At Euripides, Athena patted Euripides. Athena: I have a new Charon version to solve our problem. EURIPIDES: Really? It's so fast. ATHENA: Ok, you see, these problems have plagued me overnight. Euripides: must be your conscience and discover. Let's go to the small meeting room over there? ATHENA: Ok. The two went to the small meeting room. Athena: I want to re-describe the problem, but I have to make appropriate conversions according to our needs. ATHENA clears the throat. Athena: The first restriction: The user only lost a password. When the workstation started, this means that you don't need to enter your password when you need to apply for a new service. Second limit: passwords cannot be made in plain text on the network.
EURIPIDES: Ok. Athena: I start with the first restriction: You only need to enter your password once. I created a new network service to solve this problem. It is called "Dicket Authorization" service, this service gives Charon's ticket to the user. Use it must have a ticket: ticket authorized ticket. The license authorization service is actually just a version of Charon, which can access Charon's database. It is part of Charon that allows you to pass the ticket rather than a password. In short, the authentication system is now like this: You log in to a workstation, with a program called Kinit and the Charon server. You prove your identity to Charon, the Kinit program acquires a ticket authority ticket. Now you want to take your email from the mail server. You don't have a ticket for the mail server, so you use the "Bill Authorization" to take a ticket to the mail service. You don't need to use your password to take a new service ticket. EURIPIDES: Every time I want another network service, I have to take a "ticket authority" ticket? Athena: No. Remember, the last time we have agreed to be reused. Once you have to use the ticket authority ticket, you can use it directly. EURIPIDES: Ok, make sense. Since you can use the ticket, once you get a ticket, you don't have to take it again. ATHENA: Yes, isn't that good? Euripides: Ok, I have nothing to say, as long as you get the ticket to transfer your password online when you get the ticket. ATHENA: As I said, I have solved this problem. It sounds like it is, when I said that I want to contact Charon to obtain the ticket authority ticket, you will transfer the plain text password on the network. But it is not true. In fact, when you use the Kinit program to obtain the ticket authorization ticket, Kinit does not give your password to the charon server, Kinit only delivers your username. EURIPIDES: Very good. Athena: Charon uses the username to find your password. Then Charon will group a package that contains ticket authority tickets. Before giving you, Charon uses your password to encrypt this package. Your workstation has received a package. You enter your password. Kinit decrypts this package with your password. If you successfully, you will have a successful CHARON. You now have a ticket authority ticket, you can use this ticket to get another ticket. How do these strange things? EURIPIDES: I don't know ... I am thinking. You know that some of your system is working very well. Your system only needs me to authenticate. In the future, Charon will give me the ticket to me and I need to care. Tiao seamless, lady seamless. But there are still some troublesome designs of the service ticket. Service tickets are reusable. I agree that they should be reused, but reused service tickets, because their own nature is very dangerous. Athena: What do you mean? EURIPIDES: That look at it. Suppose you are using an unsafe workstation. After you log in, you need a mail service ticket, print ticket, and document service ticket. Suppose you have not intended to leave those tickets after you quit. Now suppose I log in to that workstation and discover those tickets. I want to make some trouble, so I use your name to log in. Since those tickets are your name, then I can take your email, play a lot of files. These are completely because these tickets are accidentally placed there. And I can also copy these votes and use them forever. Athena: But this is well resolved. We can write a program that cut off the ticket when the user quits, and these tickets cannot be used again. EURIPIDES: So very obvious that your system should have a bill destroying process, so that users rely on such mechanisms very stupid. You can't expect users to destroy the bill when they exited. And even do not rely on the destroyed bill itself, look at the situation below. I have a program to monitor the network and copy other people's service bills. Suppose I want to sacrifice you.
When I went to the workstation, I opened my program and copy your ticket. I am waiting for you to exit and leave. I put the address of my workstation to the address used when you log in. I let the workstation think I am you. I have your ticket, your username, your address. I can use these votes to use your service. I haven't worry when you destroy your ticket when you leave your workstation. These stolen tickets can always be used, because your current ticket does not use how many time limit, or how long can you use. ATHENA: Oh, I understand what you said! Tickets can't be legitimate because it may be a very large security hazard. We should limit how long each ticket can be used, maybe you can give each ticket a validity period. Euripides: Very correct. I want to increase two information: the survival period is legal for a long time, and a time tag is indicated when Charon issued this ticket. Euripides wrote the following content: Ticket {User Name: Address: Service Name: Validity: Time Stamp} EURIPIPIPIDES: Now when the service is invoiced, it checks the username, whether the address matches the sender, Then it uses the validity period and timestamp to check if the ticket is valid. ATHENA: Very good. What is a typical ticket to use? EURIPIDES: I don't know. Perhaps it is a typical workstation work cycle. It is eight hours. Athena: That if I stayed in the workstation for more than eight hours, all tickets will be invalid. Includes tickets for tickets. Then I will reopeize Charon, after eight hours. EURIPIDES: Is it unreasonable? Athena: I don't think. Well, we will set it down - the ticket is invalid after eight hours. Now I have a question asking you. Suppose I copy your ticket from the Internet. EURIPIDES: (眼), tina! You won't really do this? Athena: This is just to discuss. I copied your ticket. Now I am waiting for you to exit and leave. Suppose you have a doctor's dating or gathering to participate, you quit after two hours, and you destroy your ticket before you withdraw! But I have stole your ticket, they can also use six hours. This gives me enough time to take your file with your name and print one thousand. You see, the timestamp work is very good if the thief chooses after it fails. If the thief can use .... Ah, good ... of course, you are right. Athena: I think we have met a big problem. (She sighed) stopped. Euripides: I think this means you have to be busy tonight. Solifeny? Athena: Why not. The fourth scene is the next morning in the Euripides office. Athena is knocking. EURIPIDES: You have dark circles this morning. ATHENA: Ok, you know. It is another long night. EURIPIDES: Have you solved the problem of repeating? Athena: I think yes. EURIPIDES: Please sit. She sat down. Athena: It's still old, I reiterate the problem. The ticket is reusable, in a limited time (eight hours). If you stole your ticket and use it before it fails, we have no way. EURIPIDES: Indeed. Athena: We can understand this problem to design a ticket that cannot be reused. Euripides: But then you have to take a new ticket every time you use a new service. ATHENA: right. But it is a very stupid solution. (Take a little.), How do I continue my discussion? (She thought for a while). Ok, I have to tell a question to see what must be conditions. Web services must be able to prove that people who use tickets are those stated on the ticket.
I will go through the process of certification, so I can demonstrate my solution. I now want to use a network service. I use it by launching the client on the workstation. The client sent three things to the server: my name, my workstation network address, appropriate service bill. This ticket contains the address of the workstation applying for this ticket and the address used by him (she). It also includes validity and timestamp of the ticket. All of this information is encrypted by the password. Our current authentication mode is based on the following test: Can the service decrypt tickets? Does tickets within the validity? Does the name and address of the ticket match the application and address of the applicant? What did these tests have proven? The first test proves that the ticket is from Charon. If the ticket cannot be decrypted properly, the ticket is not from the real charon. The real Charon will use the service ticket to add a ticket. Charon and service are the only two entities that know the service password. If the ticket is successfully decrypted, the service knows that it comes from true charon. This test prevents some people from fake fake tickets. The second test check ticket is within the validity period. If expired, the service refuses. This test prevents the use of old tickets, because the ticket may be stolen. The third test check the username and address of the ticket match the requester's username and address. If the test fails, it means that the user uses someone else's ticket. This ticket is of course rejected. If the name and address match, what is the test? Nothing. Tickets can be stolen, usernames and network addresses can be changed, if needed. As I pointed out yesterday, the ticket can be stolen during the validity period. Because the service cannot determine the sender of the ticket is not a legitimate user. The reason why the service cannot be judged is because it is not shared with the user a secret. See it this way. If I am in Elster (the castle in Hamlet), you plan to come to work with me. But unless you talk about the correct password, I will not change to you. We share a secret. It may be that someone is set to all of the duty. So I was thinking last night. Why can't Charon set a password between legal users and services? Charon sent a password to the service while sending a copy to the user. When the service receives a ticket from the user, it can use this password to verify the legality of the user. EURIPIDES: Wait. How does Charon send two passwords? Athena: The cost of the bill is given from Charon's response, like this: She wrote on the blackboard: Charon's response - [Password | Ticket] service Get password from the ticket. The format of the ticket is as follows: Ticket - {Password: Username: Address: Service Name: Validity: Time Stamp} When you want to request a service, the client program generates a 'verifier'. The validator contains your name and the address of your workstation. The client encrypts this information with passwords, and the password is obtained when you request a bill. Verifier - {User Name: Address} Encrypted by password. After generating the validator, the client will give it to the service together. Because the service has no password, it cannot decrypt the validator. The password is in the ticket, so the service will first solve the ticket. After the invoice, the service gets the following things: the validity period and timestamp of the ticket; the name of the owner of the ticket; the network address of the ticket owner. Password. Service check tickets have expired. If everything is normal, the service uses the password to decompose the verifier. If there is no problem with decryption, the service will get a username and network address. The service uses them to go and match the username and network address in the ticket. If it is correct, the service that the service thinks that the ticket is really a truly owner of the ticket. Athena suspended, clear the throat, and drank some coffee. I think the mechanism of the password verifier solves the problem of stealing. Euripides: Maybe. But I think. . .
Attack this system, I have to have a verifier. Athena: No. You must have a validator and ticket at the same time. No ticket, the validator is useless. Unlocking the verifier must have a password, and the service must unknap the ticket. Euripides: Ok, I understand, you said when the client contacts the service, it also sent tickets and verifiers at the same time? ATHENA: Yes, I mean this. EURIPIDES: What is true, what can stop me from stealing a ticket and verifier? I can write a program if I have a ticket and verifier, I can always use it until the end of the validity period. I just need to change my username and the address of the workstation. Not? Athena: (biting her lips) Yes. How is I aspiration. EURIPIDES: Wait, etc., etc! This is not difficult to resolve. Tickets are reusable during the validity period, but that doesn't mean that the validator is reusable. Suppose we design the validator can only be used once. Can this? Athena: Ok, maybe. I just want to, the client program generates the validator and then gives it to the service together. Real votes and validates are first arrived by your copy. If the verifier can only be used once, your copy is invalid. Ah, this is right. I do what I need now is that inventive and methods make the validator can only be used once. EURIPIDES: No problem. We put the validity and timestamp on it. Suppose each verification has two minutes of validity. When you want to use a service to generate a verifier, mark the current time, give it to the ticket together. The server receives the ticket and verifier, the server unopened the validator, which checks the verifier's timestamp and validity period. If the validator has not been invalid, all other inspections have passed, then the server thinks you have passed certification. Suppose I copied a verification and ticket through the network, I have to change my workstation network address and my username, this is almost a few minutes. That is a very harsh request, I don't think it is possible, unless. . . Well, there is a potential problem. Suppose is not copied to the ticket and verifier in the transfer of the network, I copied the original package from Charon, this package is the response when you request Charon. This package has two passwords inside: one is yours, one is a service. The password of the service is hidden in the ticket, I can't get it, but the other? What do you use to generate a validator? If I get a password, I use it to build a self-procured verifier. If I can build a certifier, I can break your system. Athena: This is what I thought last night, but when I took the ticket, I was not possible to discover the verifier. You sit down at a workstation and use the Kinit program to get your ticket authority ticket. Kinit requires the username, after you enter, Kinit gives it to Charon.charon with your name to find your password, then generate a ticket authority ticket. As part of the processing, Charon generates a password shared with the ticket authorization service. Charon gives you a password and a ticket authorization ticket, and encrypts it with your password before you have a penalty. Charon sent a package. Someone got this package, but they could be powerful because it was used in your password. In particular, no one can steal the password of the ticket authorization service. Kinit received a ticket package and asked you to enter your password. If you enter the correct password, the Kinit unpack package takes out the password. Now you pay attention to Kinit processing, you will take your email. You open the mail client. This program finds a ticket for a mail service but did not find (you haven't taken your email yet). The client is authorized to apply for a ticket for a mail service. The client generates an authenticator for the process of authorization, and encrypts the validator with the password authorized by the ticket.
The client gives the validator to Charon, the ticket authorization ticket, your name, the address of your workstation, and the name of the mail service. The license license service has received these things and passed the certification check. If everything passes, the payment service will get the password that is shared with you. Now the ticket authorization service generates a ticket for a mail service, which generates a password shared with the mail service during this process. The license service is sent to your workstation to your workstation. There are tickets and passwords in the bag. Before sending a package, the ticket authorized service is encrypted by the ticket authorized password. After doing it, the package was sent out. Such an email service ticket package is sent out through the network. Suppose someone on the network copies it. He unfortunately found that the package was passed with a password of ticket certification. Since he can't decrypt, he can't get the mail code. Without a password, he cannot use any tickets for mail services delivered on the Internet. Now I think we are safe. What do you think? Euripides: maybe. ATHENA: Maybe! Will you only say this! EURIPIDES: (laughed) Don't care. You should now know the way I handle the problem. I guess me and you worked in the middle of the night. ATHENA: Hey! EURIPIDES: Ok, in the middle of the night. In fact, this system seems to be completely feasible. The password solution solves a question I think of last night: Mutual verification. A bit. I said that it is good? ATHENA: (a bit cold) please. EURIPIDES: You are so good. (EURIPIDES clearly clearing the scorpion) Last night, when the password and verifier turned in my mind, I would like to find new problems in this system, I think I found a very serious problem. I will demonstrate it below. Suppose you are tired of the current work, decide to change one. You want to print a job with the company's laser printer, give them a headhunting and other employers. So you enter the print command, command to get the service ticket, and then send the ticket to the printer. This is where you think it should be sent. In fact, you don't know that your request is sent to the correct print server. Assuming some shameless people - For example, your boss - Adjust the system, send your request to his office's printer. His print service does not care about the content of the ticket. It tells your workstation service ready to print your files. The print command is sent to the fake print server, you have trouble. I expressed the same problem from the opposite direction. With passwords and verifiers, Charon enabling its server to prevent errors from being used, but it cannot protect its users to use errors. The system needs to provide a client program to provide a way to verify the server, before it sends sensitive information to the server. The system must allow interaction verification. But the password solution solves this problem. Let's go back to the scene of the print server. I want to print the client to confirm that the service it sent is legal service. This is what the program is going to do. I entered the print command and give a file name. At this time, I already have a print service ticket and password. The client program generates a validator with a password, and then delivers the validator and ticket to the hypothetical print server. The client has not sent a file yet, which is waiting to return from the service. Really a service receives a ticket and verifier, decrypt the ticket and get a password, and then unwave the verifier with a password. This way the server has finished all certifications. The test has confirmed my identity. Now the service program is ready to be a response package to confirm its own identity. It encrypts the return package with a password and gives the package to the waiting client. The client received a package and tried to unlock it with a password. If the package is correctly unopened, the client program knows the server is a legal server. Then, the client issued a print command to it. Suppose my boss has changed the system so that his printer looks like the one I want. My client sent the ticket and the validator to it and waited for its response. The fake print service cannot generate the correct response because it cannot unlock the ticket and get a password. If the client does not send the print command to it because the client does not get the correct response. Finally, the client waits and exits.
My print is not completed, but at least my job is not placed on my head. Ok, I think we have a solid foundation for the charon certification system. Athena: Maybe. Anyway, I don't like Charon this name. EURIPIDES: Do you don't like it? When? Athena: I have never like it because its name is meaningless. One day I talked to this with my Duess (Pluto), he recommended another name: the three heads of the Pluto. Euripides: Ah, you are "Cerberus". Athena: What languages you said! "Cerberus" is actually. . . EURIPIDES: Oh, don't you call this? Athena: Of course, who makes you a Roman! And I am a Greek, it is a Greek watchdog, its name is "kerberos", "kerberos" is 'K' head. EURIPIDES: Ok, ok, don't get angry. I agree with this name. In fact, it has a good neck ring. Goodbye, Charon, welcome you, Kerberos. After the dialogue is written in 1988, it is to help readers understand the operational way of Kerberos V4. After so many years, it is still very good service. When I convert this article into HTML, I am surprised to find that this document is still very useful to Kerberos V5. Although a lot of things have changed, the core concepts have not changed. In fact, Kerberos V5 has only changed two changes to Kerberos. The first change is because the validity is not enough to prevent the attacker from being repeated in a validity period of less than five minutes. If the attacker is using a program automated cut ticket and the verifier and repeats. In Kerberos V5, the validator can only use the server's 'repeat buffer' information for the recently submitted validator because the server 'repeat buffer' is saved. If an attacker tries to intercept the validator and reuse it, 'Re-execute buffer' will find that the validator has been submitted. The second main change is when Kerberos is given to the Kinit service ticket, the ticket is no longer encrypted with the user's password. It has been added to the password of the paper authorization service. The ticket for the paper authorization service is used to get other tickets, it is transferred directly. So the ticket does not need to be encrypted once with the user's password. (Other parts of the server response, such as passwords, is still encrypted with the user's password.) A similar change is also applied to the ticket authorization service protocol; the ticket returned from the payment service is no longer encrypted with the password of the ticket authorization service. Because the tickets it already contains have been added secretly. For example, Kerberos V4 is like this: kdc_reply = {ticket, client, server, k_session} k_usend means: {} is encrypted with k_user. Ticket = {Client, Server, Start_time, Lifetime, K_Session} k_server In Kerberos V5, KDC_Reply looks like this: kdc_reply = ticket, {client, server, k_session} k_user (Note: The ticket is no longer encrypted with k_user Of course, there are many new features in Kerberos V5. Users can securely submit their tickets in another network; and users can transfer their part of the authentication right to the server so that the server can act as a user agent. Other new features include: replacing DES encryption algorithms with a better encryption algorithm, such as triple DES encryption.
Readers If you are interested in v4 and v5, you can read "The Evolution of The Kerberos Authentication System", the author is Cliff Neumann and Theodore TSO. I hope you can interested this article introduction to the Kerberos protocol. I wish you more in the future. Note: Reprinted network
