"Turn" Athena to the dialogue with Zeus. (Kerberos principle)

1 August 2010 22:07:51
The conversation about Kerberos (MIT)
Athena and Zeus

Athena and Zeus ' dialogue on the keeper of the Gates of Hell

Kerberos:network Authentication Protocol

The term Kerberos is derived from the Greek mythology "three-head dog-the gate Keeper of Hell" Kerberos is a network authentication protocol designed to provide a powerful authentication service for client/server applications through a key system. The implementation of the authentication process does not depend on the authentication of the host operating system, no host address-based trust, no physical security of all hosts on the network, and assumes that packets sent over the network can be arbitrarily read, modified, and inserted into the data.　　In these cases, Kerberos acts as a trusted third-party authentication service through the use of traditional cryptography (e.g. shared secret keys) to perform authentication services. The authentication process is as follows: The client sends a request to the authentication server (as), requires a certificate from the server, and the as response contains these certificates that are encrypted with the client key. The composition of the certificate is: 1) the server "Ticket"; 2) a Temporary encryption key (also known as session key). The client transmits the ticket (including the client identity encrypted with the server key and a copy of the session key) to the server.　　A session key can be used to authenticate a client or authentication server (now shared via client and server), or to provide cryptographic services for subsequent communications between the two parties, or to provide further communication encryption services for both parties by exchanging a separate sub-session key. The authentication exchange process above requires a read-only access to the Kerberos database. Sometimes, however, records in a database must be modified, such as when a new rule is added or a rule key is changed. The modification process is done through the protocol between the client and the third-party Kerberos server (Kerberos manager kadm). The management agreement is not covered here. There is also a protocol for maintaining copies of multiple Kerberos databases, which can be considered a matter of detail in the execution process and is constantly changing to accommodate various database technologies.

This is a set of conversations written by MIT (Massachusetts Institute of Technology) to help people understand the principles of Kerberos. There are two fictional characters: Athena and Euripides, through Athena constantly thinking and Euripides constantly looking for loopholes, so that we understand the principle of the Kerberos protocol.
Athena: Athena, Goddess of wisdom and skill.
Euripides: The tragic poet of Greece, in the European House of Kota Kinabalu.

The translation is as follows:

First act

In a small workshop. Athena and Euripides are working on adjacent terminals.
Athena: Hey, this time-sharing OS is too slow. I can't work at all because everyone is on board.
Euripides: Don't complain to me. I'm just working here.
Athena: Do you know what we need? We need to give everyone a job so they don't worry about the speed of the computer. And we need a network to link all the computers together.
Euripides: OK. So we're going to need 1000 workstations?
Athena: Pretty much.
Euripides: Do you know how big the hard drive of a normal workstation is? There's no software to put in there.
Athena: I already have an idea. We can put the system software on the server. When you log on to a workstation, the workstation contacts the system software on one of the servers over the network. Such a setup allows a group of workstations to use the same system software and facilitates the upgrade of the system software. Just make a change to the server.
Euripides: OK. How do you get your personal documents done? On the time-sharing operating system, I can log in and take my files from the terminal. Can I fetch my files on the workstation? Do I have to put my files on disk like a PC user? I hope not.
Athena: I think we can save the files from other machines. You can log on to any machine to fetch your files.
Euripides: What about printing? Do you want to have your own printer for each workstation? Who's going to pay the money? What about e-mails? How do you send the mail to all the workstations?
Athena: Ah ..... Obviously we don't have the money to have a printer for everyone, but we have a special machine to do the printing service. You send the request to the server and it prints for you. Mail can also do this. There is a dedicated mail server. If you want your email, contact the mail server and take your email.
Euripides: Your workstation system sounds pretty good. If I had one, do you know what I'm going to do? I want to find out your username and let my workstation think I am you. Then I'll go to the mail server and fetch your mail. I'll be on your file server, remove your files, and then--
Athena: Can you do it?
Euripides: Of course! How do these Web servers know I'm not you?
Athena: Well, I don't know. I think I need to think seriously.
Euripides: All right. Tell me when you want to come out.

Act II

Euripides's office, the next morning. Euripides sat beside his desk, reading his mail. Athena to knock at the door.
Athena: I've figured out how to protect an open network system so that unethical people like you can't use other people's names for Web services.
Euripides: Really? Have a seat.
She sat down.
Athena: Before I begin to describe, can I make an appointment for our discussion first?
Euripides: What's the deal?
Athena: Well, suppose I say, "I want my mail, so I contacted the mail server and asked it to send the mail to my workstation." "I didn't actually contact the server. I use a program to contact the server and get my mail, this program is the client of this service. But I don't want to say "How is the client" every time I interact with the server. I just want to say, "How do I," Remember, the client is doing everything on my behalf. Is that OK?
Euripides: Of course. No problem.
Athena: OK. So I'm going to start explaining the problems I've solved. In an open network environment, the machine that provides the service must be able to recognize the identity of the entity requesting the service. If I go to the mail server to request my mail, the service must be able to verify that I am the person I am stating.
Euripides: That's right.
Athena: You can solve this problem in a stupid way: The server lets you enter your password. I can prove who I am by the way I lose my password.
Euripides: That's really awkward. In a system like that, every server must know your password. If the network has 1000 users, then each server needs to know 1000 passwords. If you want to change the password, you must contact all the servers and notify them to change the password. I don't think your system is that stupid.
Athena: My system is not that stupid. It works like this: not only people have passwords, but services also have passwords. Each user knows their own password, and each service knows its own password. There is an authentication service that knows all the passwords, the user's and the service. The Authentication service stores the password in a separate central database.
Euripides: Does this certification service have a name?
Athena: I'm not sure yet. You want one, right?
Euripides: Who is the man who sent the dead to the river?
Athena:charon?
Euripides: Yes, that's him. If he can't prove your identity, he won't send you across the river.
Athena: You're not trying to rewrite Greek mythology. Charon doesn't care about your identity, he's just sure you're dead.
No.
Euripides: Do you have a better name?
Stopped for a moment.
Athena: No, really not.
Euripides: Well, then we'll put this authentication service "Charon".
Athena: Well, I guess I should describe the system, eh?
For example, we want a service: Mail. In my system you cannot use a service unless Charon tells the service that you are indeed the person you are stating. That means you have to get Charon certification to use the service. When you request authentication from Charon, you must tell Charon which service you want to use. If you want to use mail, you have to tell Charon. Charon, please prove your identity. So you give it your password. Charon compares your password to the password in its database. If they are equal, Charon thinks you passed the validation. Charon now let the Mail service know that you passed the verification. Since Charon knows the password for all services, it also knows the password of the mail service. Charon the email service password to you, you can use this password to make the mail service believe that you have passed the verification. The problem is, Charon can't give you the password directly, because you'll know it. The next time you want a mail service, you'll bypass Charon to use the mail service without authentication. You can also pretend that someone is using the mail service. So not directly to your email service password, Charon give you a mail service "ticket". This ticket contains your name, and the name is encrypted with the password of the mail service. With the ticket, you can request your email from the Mail service. You make a request to the mail service and use your ticket to prove your identity. The service uses its own password to decrypt the ticket, and if the ticket can be decrypted correctly, the server will remove the user name from the ticket. The service compares this name with the username sent with the ticket. If it matches, the server thinks you passed the verification and sends your email to you.
What do you think?
Euripides: I have some questions.
Athena: I guessed it. Please speak.
Euripides: When the service decrypts a ticket, how does it know it is being decrypted correctly?
Athena: I don't know.
Euripides: Maybe you should include a service name in the ticket. When the service decrypts the ticket, it can determine whether the decryption is correct by finding its own name in the ticket.
Athena: Very good. That's the way it should be:
(she wrote the following on a piece of paper)
Ticket-{User name: Service Name}
Euripides: The ticket contains only the user name and service name?
Athena: Encrypted with the password of the service.
Euripides: I don't think this information will make the ticket safe.
Athena: What do you mean?
Euripides: Suppose you request a ticket to Charon for a mail service. Charon prepared a picture with your name, "Tina."
's ticket. Suppose I had a copy of the pawn ticket from Charon to you. Suppose I let my workstation believe that my username is "Tina". The mail client thought I was you. Use your name mail client to make a request to the mail server with a stolen ticket. The mail server decrypts the ticket and considers it to be legal. The user name in the ticket is matched to the name of the user who sent the ticket. The mail server will send me your email.
Athena: Oh, that's not good.
Euripides: But I think of a way to solve this problem. or part of the solution. I think Charon should include more information in the ticket. In addition to the user name, the ticket should also contain the IP address of the user requesting the ticket. This will add a layer of security to you. I'll show you. Suppose I stole your ticket now. This ticket has the IP address of your workstation, and this address is not worthy of my
The address of the workstation. With your name I sent the stolen ticket to the mail server. The service program removes the user name and network address from the ticket and attempts to match the user name and network address. User name matching can be network address mismatch. The server rejected the ticket because it was obviously stolen.
Athena: Hero, Hero! How could I not have thought.
Euripides: Well, that's what I'm going to say.
Athena: So the ticket should look like this.
She wrote down the following things on the blackboard.
Ticket-{User name: Address: Service Name}
Athena: Now I'm really excited. Let's build a Charon system to see if it works!
Euripides: Not so fast. I have some problems with your system.
Athena: All right. (Athena out of her chair) said quickly.
Euripides: It sounds like I'm going to fetch a new ticket every time I want to get a service. If I work all day, I may have to take my mail more than once. Do I have to pick up a new ticket every time I take an email? If that's true, I don't like your system.
Athena: Ah ... I don't understand why tickets cannot be reused. If I've got a ticket for a mail service, I can use it again and again. When the mail client requests a service with your name, it passes a copy of the ticket to the service.
Euripides: better. But I still have a problem. You seem to imply that every time I use a service that does not have a ticket, I have to give Charon my password and I log in and want to take my file. I asked Charon for my ticket, which means I had to use my password. Then I want to read my e-mail. Again to Charon a request, I again lose my password. Now suppose I want to send my mail to print. I'm going to send a request to Charon again. You know that, don't you?
Athena: Ah, yes, I see.
Euripides: And if that's not bad enough, think about it: it seems like this, when you want to authenticate to Charon, you need to use clear text to transmit your password on the network. Smart people like you can monitor the network and get someone else's password. If I get your password, I can use any service with your name.
Athena sighed.
Athena: There really is a serious problem. I think I should go back to the design room.

Act III

The next morning, Athena met Euripides in the coffee room. When Euripides poured the coffee, Athena took
Pat Euripides.
Athena: I have a new version of Charon to solve our problem.
Euripides: Really? So fast.
Athena: Well, you see, these questions bothered me all night.
Euripides: It must be your conscience to find out. Shall we go to the small meeting room over there?
Athena: OK.
Two people went to the small meeting room.
Athena: I want to re-describe the problem, but I want to make the appropriate conversion according to our needs.
Athena cleared his throat.
Athena: The first limit: the user only loses the password once, when their workstation starts, this means that when you need to apply for a new service ticket, you do not need to enter your password. Second limit: Passwords cannot be transmitted in plaintext on the network.
Euripides: OK.
Athena: I start with the first restriction: You only need to enter your password once. I created a new Web service to solve this problem. It is called the "Ticket Authorization" service, which Charon the ticket to the user. You must have a ticket to use it: the ticket authorized by the ticket. The Ticket authorization service is actually just a version of Charon, it can access the Charon database. It is part of the Charon that allows you to authenticate with a ticket rather than a password. In short, the authentication system is now working like this: you log on to a workstation and communicate with the Charon server using a program called Kinit. You prove your identity to Charon, the kinit procedure obtains a ticket authorization. Now you want to pick up your mail from the mail server. You do not have the mail server ticket, so you use the "Ticket authorization" ticket to pick up the mail service ticket. You do not need to use a password to fetch a new service ticket.
Euripides: Do I have to pick up a ticket authorization every time I want another Web service?
Athena: No. Remember, last time we agreed that the ticket could be reused. Once you have to use the ticket authorization, you can use it directly.
Euripides: Well, that makes sense. Now that you can reuse the ticket, once you get a ticket for a service, you don't have to.
Athena: Yes, isn't that good?
Euripides: OK, I have nothing to say, as long as you do not use clear text to transmit your password on the Internet when you obtain the ticket authorization.
Athena: As I said, I have solved the problem. Sounds like, when I said I was going to contact Charon.
You must transmit the plaintext password on the network when the ticket is authorized. But that's not true. In fact, when you use the Kinit program to obtain a ticket authorization, kinit did not send your password
To the Charon server, kinit only send you the user name.
Euripides: Very good.
Athena:charon Use the username to find your password. Then Charon will set up a package containing the ticket authorization. Before sending it to you, Charon use your password to encrypt the package. Your workstation received the package. You enter your password. Kinit Use your password to decrypt the packet. If you succeed, you will be certified to Charon successfully. You now have a ticket, you can use this ticket to get the other tickets.
What do you think of these marvelous ideas?
Euripides: I don't know ... I was thinking. You know that part of your system works very well. Your system only needs me to authenticate once. Later, Charon will give me the ticket to serve and I need to care. Flawless and seamless. But the service ticket design still has some troubled me. The service ticket is reusable. I agree that they should be reusable, but the reuse of service tickets, due to their own nature, is very dangerous.
Athena: What do you mean?
Euripides: look like this. Let's say you're using an unsafe workstation. After you log in, you will need a mail service ticket, a print ticket, and a document service ticket. Let's say you accidentally left those tickets after you quit. Now suppose I log on to that workstation and find those tickets. I wanted to make some trouble, so I signed in with your name. Since those tickets are your name, I can pick up your mail and hit a lot of papers. This is entirely because the tickets were accidentally put there. And I can also copy these tickets and use them forever.
Athena: But that's a good solution. We can write a program to destroy the ticket when the user exits, these
The ticket will not be used again.
Euripides: Then it is obvious that your system should have a bill destruction program that makes it very foolish for users to rely on such a mechanism. You can't expect users to destroy bills when they exit. And can't even rely on destroying the bill itself, see below. I have a program that can monitor the network and cuff other people's service tickets. Suppose I wanted to sacrifice you. I will wait for you to log on to the workstation, open my program and copy your ticket. I wait for you to quit and leave. I adjusted the address of my workstation to the address you used when you logged in. I let the station think I was you. I have your ticket, your username, your address. I can use these tickets for your service.
When you leave the station, your ticket has been destroyed and tied. These tickets that I stole can be used all the time, because your current ticket does not have the number of times you can use it, or how long you can use it.
Athena: Oh, I understand what you said! Tickets cannot be forever legal, because it can be a very big security risk. We should limit how long each ticket can take, and perhaps we can set a validity period for each ticket.
Euripides: Very correct. I think the ticket needs to be increased by two items: The lifetime indicates how long the ticket is legal, and a time stamp to indicate when the ticket was issued by Charon.
Euripides went to the blackboard to write down the following content:
Ticket {User name: Address: Service Name: Validity period: timestamp}
Euripides: Now when the service unlocks the ticket, it checks the user name of the ticket, whether the address matches the sender, and then it
Check that the ticket is valid by using the expiration date and timestamp.
Athena: Very good. What is the validity period of a typical ticket?
Euripides: I don't know. May be a typical workstation's work cycle. It's eight hours.
Athena: If I stay on the workstation for more than eight hours, all tickets will expire. Including ticket authorization. Then I'm going to re-certify to Charon, after eight hours.
Euripides: Isn't that unreasonable?
Athena: I guess not. OK, let's settle down--the ticket expires in eight hours. Now I have a question to ask you. Let's say I copied your ticket from the Internet.
Euripides: (blinking) Ah, tina! you don't really do that?
Athena: It's just for discussion. I've cuffed your ticket. Now I wait for you to quit and leave. Suppose you have a doctor's appointment or party to attend, you exit after two hours, and you destroy your ticket before exiting.
But I have stolen your ticket and they can use it for six hours. It gives me plenty of time to get your files and print 1000 copies of what you're doing in your name. You see, the time stamp works well if the thief chooses to expire in it later with the words. If a thief can use ... before it expires.
Ah, good ... Of course, you are right.
Athena: I think we've got a big problem. (She sighed)
Stopped for a moment.
Euripides: I think that means you're going to be busy tonight. You want some more coffee?
Athena: Why not.

ACT Fourth

The next morning at Euripides's office. Athena to knock at the door.
Euripides: You have dark circles this morning.
Athena: Well, you know. It was a long night again.
Euripides: Have you solved the problem of repetition?
Athena: Yes, I think so.
Euripides: Please sit down.
She sat down.
Athena: As usual, I reiterate the question. The ticket is reusable, within a limited time (eight hours). If anyone steals your ticket and uses it before it expires, there is nothing we could do about it.
Euripides: That's true.
Athena: We can think of this problem as designing a ticket that no one else can reuse.
Euripides: But then you have to take a new ticket every time you use a new service.
Athena: Yes. But that's a stupid solution. (a little bit.) Ah, how can I proceed with my discussion? (She meditated for a moment).
OK, I want to restate a question and see what must be the condition. The network service must be able to prove that the person using the ticket is the person stated on the ticket. I'll go through the certification process again, so I can demonstrate my solution. I want to use a Web service now. I use it by starting the client on the workstation. The client sends three things to the server: My name, the network address of my workstation, and the appropriate service ticket. This ticket contains the name of the person applying for the ticket and the address of the workstation to which he or she applied. It also contains the validity and time stamp of the ticket. All this information is encrypted by the password of the service.
Our current authentication mode is based on the following tests:
Can the service decrypt the tickets?
Is the ticket within the validity period?
Does the name and address in the ticket match the applicant's name and address?
What do these tests prove?
The first Test proved that the ticket was from Charon. If the ticket cannot be properly decrypted, the ticket does not come from the real
The Charon.
The real Charon will use the service ticket to encrypt the ticket. Charon and services are the only two entities that know the service password.
If the ticket is decrypted successfully, the service knows it comes from the real Charon. This test prevents someone from forging fake tickets.
The second test checks whether the ticket is within the validity period. If it expires, the service rejects it. This test prevents the use of old tickets,
Because the tickets may have been stolen.
The third test checks whether the user name and address of the ticket match the requestor's user name and address. If the test fails, say
The user is using someone else's ticket. The ticket was, of course, rejected.
If the name and address match, what does this test prove? There's nothing. Tickets can be stolen, usernames and nets
The address can be changed if needed. As I pointed out yesterday, tickets can be stolen within the validity period.
Because the service cannot determine whether the sender of the ticket is a legitimate user.
The service cannot be judged because it does not share a secret with the user. Look like this. If I was Elsno
(Castle in Hamlet) on duty, you are going to come and take my shift. But unless you say the correct password, I don't
It's going to be your shift. We shared a secret. It may be someone who is set up for all the people on duty.
So last night I was wondering why Charon can't set a password for legitimate users and services? Charon Hair
A password to the service, at the same time send a copy to the user. When the service receives a ticket from the user, it can use this password
Verify the legality of the user.
Euripides: Wait a minute. Charon How to send two copies of the password at the same time?
Athena: The bearer of a bill gets a password from Charon's response, like this:
She wrote it on the blackboard:
Charon response-[password | ticket]
The service obtains the password from the ticket. The format of the ticket is as follows:
Ticket-{Password: User name: Address: Service Name: Validity period: timestamp}
When you want to request a service, the client program generates an ' authenticator '. The authenticator contains your name and the address of your workstation. The client encrypts this information with a password that you get when you request a ticket.
Authenticator-{user name: address} encrypted with password.
After the authenticator is generated, the client sends it to the service along with the ticket. Because the service does not have a password, it cannot decrypt
Validator. The password is in the ticket, so the service first untied the ticket.
After the ticket is untied, the service gets the following things:
The validity and time stamp of the ticket;
The name of the owner of the ticket;
The network address of the owner of the ticket.
Password.
Whether the service check ticket has expired. If everything is OK, the service will use the password to solve the authenticator. If decryption is not a problem, the service will get a user name and network address. The service uses them to match the user name and network address in the ticket, if correct, then the service thinks the sender of the ticket is indeed the true owner of the ticket.
Athena paused for a moment, cleared his throat and drank some coffee.
I think the password verifier mechanism solves the problem of misappropriation.
Euripides: Maybe. But I think ... I have to have an authenticator to attack this system.
Athena: No. You must have both a validator and a ticket. There is no ticket, the authenticator is useless. Unlock the authenticator must have a password, the service must untie the ticket to have the password.
Euripides: OK, I get it, you mean when the client program contacts the service, it sends the ticket and authenticator at the same time?
Athena: Yes, that's what I mean.
Euripides: If so, what can stop me from stealing tickets and validators? I can write a program, if I have a ticket and authenticator, I can always use it until the end of the validity period. I just need to change my username and workstation address. Isn't it?
Athena: (biting her lip) yes. How frustrating.
Euripides: Wait, wait, wait! It's not hard to solve. The ticket is reusable within the validity period, but that does not mean that the authenticator is reusable. Suppose we designed the validator to be used only once. Is that OK?
Athena: OK, maybe. Let me think about it, the client program generates the validator and sends it to the service along with the ticket. The real ticket and authenticator are the first to be copied than you. If the authenticator can only be used once, your copy will expire. Ah, that's right. What I need to do now is invent the one and the method so that the authenticator can only be used once.
Euripides: No problem. We put the expiration date and time stamp on it. Assume that each validation has a two-minute validity period. When you want to use a service, the client generates the authenticator, marking the current time, and sending it along with the ticket to the service. The server receives the ticket and authenticator, the server unlocks the authenticator, it checks the validator's timestamp and the validity period. If the authenticator does not expire and all other checks are passed, the server thinks you are certified. Assuming I've copied a validator and ticket over the Internet, I have to change my workstation's network address and my username, which will take a few minutes. That's very demanding, I don't think it's possible, unless ... Well, there's a potential problem. Assuming it wasn't a copy of the ticket and authenticator in the network's transfer, I copied a copy of the original package from Charon, which is your response to Charon's request. This package, there are two passwords inside: one is yours, the other is service. The password of the service is hidden in the ticket, I can't get it, but what about the other one? The one you used to generate the authenticator? If I get a password, I use it to build my own authenticator, and if I can build my own authenticator, I can break your system.
Athena: That's what I thought last night, but when I think about the process of the ticket, it's impossible to find that stealing the authenticator.
You sit down on a workstation and get your ticket authorization with the KINIT program. Kinit required to enter the user name, you enter later, Kinit send it to Charon.charon use your name to find your password, and then generate a ticket authorization. As part of the process, Charon generates a password that you share with the ticket authorization service. Charon sends you the password and the ticket authorization ticket, and encrypts it with your password before sending it off.
Charon sent out the bag. Someone has got the bag, but they can't do it because it's a secret with your password. In particular, no one can steal the password for the ticket authorization service. Kinit received the ticket packet and asked you to enter your password. If you enter the correct password, the kinit unlocks the package and takes out the password. Now you pay attention to the handling of kinit, you go to fetch your mail. You open the mail client. This app looks for a mail service ticket but not found it (you haven't taken your email yet). The client applies for a ticket to the mail service with a ticket authorization. The client generates a validator for the ticket authorization process and encrypts the authenticator with a ticket-authorized password. The client sends the authenticator to Charon, ticket authorization, your name, the address of your workstation, and the name of the Mail service. The Ticket authorization service received these things and passed the certification check. If everything goes through, the ticket authorization service will get the password that you shared. Now that the ticket authorization service generates a ticket for your mail service, you generate a password that you share with the mail service during this process. The ticket authorization service puts these things into a package for your workstation. There is a ticket and a password in the bag. Before sending the packet, the ticket authorization service encrypts the packet with the password authorized by the ticket. When done, the bag is sent out. Such mail service ticket packets are sent out through the network. Suppose someone on the network copies it. His unfortunate discovery that the package was certified with a ticket was too dense. Since it can't be decrypted, he can't get the email password. Without a password, he cannot use any of the mail services sent over the Internet. Now I think we are safe. What do you think?
Euripides: Maybe.
Athena: Maybe! That's all you can say!
Euripides: (laughter) Don't mind. You should know the way I deal with the problem now. I guess I was working with you last night.
In the middle of the night.
Athena: Hum!
Euripides: OK, half the night. In fact, the system seems to be completely workable. The password scheme solves my
A question that came to mind last night: mutual verification.
A little.
Let me just say it, okay?
Athena: (A little cold) go ahead.
Euripides: That's very kind of you. (Euripides clear his own voice) last night, when the password and authenticator were in my head, I wanted to find out a new problem with the system, and I think I found a very serious problem. I'll show you the following.
Suppose you are tired of your present job and decide to change one. You want to use your company's laser printer to print your cover letters and send them to headhunters and other employers. So you enter the Print command, order 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 was sent to the correct print server. Suppose some shameless person--your boss, for example--adjusts the system and sends your request to the printer in his office. His print service does not care about the contents of the ticket. It tells you that the Workstation service is ready to print your files. The print command was sent to the fake print server and you are in trouble. I have expressed the same problem in the opposite direction. With a password and authenticator, Charon can protect its server from the wrong user, but it cannot protect its users from using the wrong server. The system needs to provide a way for the client program to validate the server before it sends sensitive information to the server. The system must allow interactive authentication. But the password scheme solves the problem. Let's go back to the print server scenario. I want to print the client program
The services it sends are legitimate. That's what the program does. I enter the print command and give a file name. I already have a print service ticket and password. The client program generates a validator with a password and then sends the authenticator and the ticket to the hypothetical print server. The client has not yet sent the print file, which is waiting to be returned from the service. The real service receives tickets and validators, decrypts the tickets and gets the password, and then unlocks the authenticator with a password. So the server has done all the certification. The test has confirmed my identity. Now the service program needs to prepare a response packet to verify its identity. It encrypts the return packet with a password and sends the packet to the waiting client. The client received the packet and tried to untie it with a password. If the package is properly unpacked to get the correct server response information, the client program knows that the server is a legitimate server. The client then issues a print command to it. Suppose my boss changes the system so that his printer looks like the one I want to use. My client sent the ticket and authenticator to it and waited for it to respond. The fake print service failed to generate the correct response because it could not unlock the ticket and get the password. This way the client will not send a print command to it because the client does not get the correct
Response. Finally, the client discards the wait and exits. My print is not finished, but at least my cover letter will not be placed on my opponent's desk. Well, I think we have a solid foundation for the Charon certification system.
Athena: Maybe. Anyway, I don't like the name Charon.
Euripides: Don't you like it? What time is it?
Athena: I never liked it because its name sounded meaningless. One day my Uncle Diess and I talked about this, and he recommended another name: The three-head watchdog of Hades.
Euripides: Ah, you mean "Cerberus".
Athena: What language do you speak? "Cerberus" is actually ...
Euripides: Oh, don't you call this?
Athena: Of course, who made you a Roman! And I am Greek, it is a Greek watchdog, its name is "Kerberos", "Kerberos" is ' K '.
Euripides: All right, all right, don't get mad. I agree with the name. In fact, it has a good neck ring. Goodbye, Charon, welcome, Kerberos.

Postscript
This dialogue was written in 1988 to help readers understand how Kerberos V4 works. After all these years, it still serves this very well. When I converted this article into HTML, I was surprised to find that this document was still very useful for Kerberos V5. Although many things have changed, the core concept has not changed. In fact, Kerberos V5 only made two changes to Kerberos.
The first change is due to the realization that the authenticator is not valid for less than five minutes to prevent an attacker from replaying, if the attacker is using a program to automatically intercept tickets and validators and replay them. In Kerberos V5, the validator can really only be used once because the server saved the last committed authenticator with a ' replay buffer '. If an attacker attempts to intercept the authenticator and reuse it, ' replay buffer ' will find that the authenticator has been committed.
The second major change is when Kerberos sends the KINIT service ticket, the ticket is no longer encrypted with the user's password. It has been added with the password of the ticket authorization service. When the ticket of the authorized service is used to obtain other tickets, it is transmitted directly. Therefore, the ticket does not need to be encrypted again with the user's password. (Other parts of the server response, such as passwords, are still encrypted with the user's password.) A similar change is also applied to the ticket authorization service agreement; the tickets returned from the authorized service of the bill are no longer granted
The password for the service is encrypted because it contains tickets that have been added to the password of the corresponding service. For example, the Kerberos V4 package looks like this:

Kdc_reply = {TICKET, client, server, K_session}k_user
This means that the contents of {} are encrypted with K_user.
TICKET = {client, server, Start_time, lifetime, K_session}k_server
In Kerberos V5, kdc_reply now 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 submit their tickets securely on another network, and users can transfer some of their authentication rights to the server so that the server can act as a proxy for the user. Other new features include the substitution of a DES encryption algorithm with a better encryption algorithm, such as triple-Des encryption. If the reader is interested in the changes 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 will be interested in this article about the Kerberos protocol. I wish you a further exploration in the future.

(Last edit:2010 August 1 22:08:35)

Protocol structure:
Kerberos Information
* Client/server Authentication Exchange < Information direction information type client to Kerberos Krb_as_req Kerberos to client krb_as_rep or Krb_error * Client/server Authentication Exchange information Direction information class Client to the application server krb_ap_req [optional] application server to client Krb_ap_rep or Krb_errorr * Ticket Granting Service (TGS) Exchange information Direction information type client to Kerberos krb_tgs_re Q Kerberos to client krb_tgs_rep or Krb_error * Krb_safe Exchange * KRB_PRIV Exchange * krb_cred Exchange Kerberos is the certification system developed by MIT for Athena (Athena) program 。
The composition of Kerberos
Kerberos Application Library: An application interface that includes creating and reading authentication requests, and subroutines that create safe message and private message. 　　Encryption/Jiamiku: des and so on.　　Kerberos database: Information such as the name of each Kerberos user, the private key, the cutoff information (the valid time of the record, usually a few years), is documented.　　Database Manager: Manages the Kerberos database KDBM server (database Management Server): Accepts client requests for operations on the database.　　Authentication Server (AS): A read-only copy of the Kerberos database that is used to complete the authentication of the principle and generate a session key.　　Database replication software: the management database from the machine where the KDBM service resides, to the replication of the machine where the authentication server resides, and in order to maintain the consistency of the database, replication is required every once in a while.　　User programs: Log in to Kerberos, change the Kerberos password, display and destroy Kerberos tags (ticket), and so on. The KERBEROS5 authentication protocol is implemented on the Microsoft Windows Server 2003 operating system. Windows Server2003 always uses the extended public key authentication mechanism. The Kerberos authentication Client acts as an SSP (Security support Provider) by accessing the SSPI (Security Support Provider Interface) for authentication. The user authentication initialization process is integrated in the Winlogon SSO (single sign-on) system.

Vista system common English professional words
An authentication standard that provides a "ticket" for other servers that provide resources on the network by using a central server to identify them. It is supported in Windows $, XP, Server 2003, Vista, and Longhorn, as well as UNIX systems.

(Last edit:2010 August 1 22:17:11)

"Source": http://blog.sina.com.cn/s/blog_5189da570100k6av.html

"Turn" Athena to the dialogue with Zeus. (Kerberos principle)