Kerberos原理-对话版

http://web.mit.edu/Kerberos/dialogue.html

Designing an Authentication System:

a Dialogue in Four Scenes

 

Copyright 1988, 1997 Massachusetts Institute of Technology. All Rights Reserved.

Originally written by Bill Bryant, February 1988.

Cleaned up and converted to HTML by Theodore Ts'o, February, 1997. An afterword describing the changes in Version 5 of the Kerberos protocol was also added.

 

Abstract

This dialogue provides a fictitious account of the design of an open-network authentication system called "Charon." As the dialogue progresses, the characters Athena and Euripides discover the problems of security inherent in an open network environment. Each problem must be addressed in the design of Charon, and the design evolves accordingly. Athena and Euripides don't complete their work until the dialogue's close.

 

When they finish designing the system, Athena changes the system's name to "Kerberos," the name, coincidentally enough, of the authentication system that was designed and implemented at MIT's Project Athena. The dialogue's "Kerberos" system bears a striking resemblence to the system described in Kerberos: An Authentication Service for Open Network Systems presented at the Winter USENIX 1988, at Dallas, Texas.

 

Contents

Dramatis Personae

Scene I

Scene II

Scene III

Scene IV

 

Dramatis Personae

Athena   an up and coming system developer.

Euripides      a seasoned developer and resident crank.

 

Scene I

A cubicle area. Athena and Euripides are working at neighboring terminals.

Athena:  Hey Rip, this timesharing system is a drag. I can't get any work done because everyone else is logged in.

Euripides:     Don't complain to me. I only work here.

Athena:  You know what we need? We need to give everyone their own workstation so they don't have to worry about sharing computer cycles. And we'll use a network to connect all the workstations so folks can communicate with one another.

Euripides:     Fine. So what do we need, about a thousand workstations?

Athena:  More or less.

Euripides:     Have you seen the size of a typical workstation's disk drive? There isn't enough room for all the software that you have on a timesharing machine.

Athena:  I figured that out already. We can keep copies of the system software on various server machines. When you login to a workstation, the workstation accesses the system software by making a network connection with one of the servers. This setup lets a whole bunch of workstations use the same copy of the system software, and it makes software updates convenient. You don't have to trundle around to each workstation. Just modify the system software servers.

Euripides:     All right. What are you going to do about personal files? With a timesharing system I can login and get to my files from any terminal that is connected to the system. Will I be able to walk up to any workstation and automatically get to my files? Or do I have to make like a PC user and keep my files on diskette? I hope not.

Athena:  I think we can use other machines to provide personal file storage. You can login to any workstation and get to your files.

Euripides:   What about printing? Does every workstation have its own printer? Whose money are you spending anyway? And what about electronic mail? How are you going to distribute mail to all these workstations?

Athena:  Ah . . . Well obviously we don't have the cash to give everyone a printer, but we could have machines dedicated to print service. You send a job to a print server, and it prints it for you. You could do sort of the same thing with mail. Have a machine dedicated to mail service. You want your mail, you contact the mail server and pick up your mail.

Euripides:     Your workstation system sounds really good Tina. When I get mine, you know what I'm going to do? I'm going to find out your username, and get my workstation to think that I am you. Then I'm going to contact the mail server and pick up your mail. I'm going to contact your file server and remove your files, and--

Athena:  Can you do that?

Euripides:     Sure! How are these network servers going to know that I'm not you?

Athena:  Gee, I don't know. I guess I need to do some thinking.

Euripides:     Sounds like it. Let me know when you figure it out.

 

Scene II

Euripides' office, the next morning. Euripides sits at his desk, reading his mail. Athena knocks on the door.

Athena:  Well I've figured out how to secure an open network environment so that unscrupulous folks like you cannot use network services in other people's names.

Euripides:     Is that so? Have a seat.

She does.

Athena:  Before I describe it, can I lay down one ground rule about this discussion?

Euripides:     What's your rule?

Athena: 

Well suppose I say something like the following: "I want my electronic mail, so I contact the mail server and ask it to send the mail to my workstation." In reality I'm not the entity that contacts the mail server. I'm using a program to contact the mail server and retrieve my mail, a program that is a CLIENT of the mail service program.

 

But I don't want to say "the client does such-and-such" every time I refer to a transaction between the user and a network server. I'd just as soon say "I do such-and-such," keeping in mind of course that a client program is doing things on my behalf. Is that okay with you?

Euripides:     Sure. No problem.

Athena:  Good. All right, I'll begin by stating the problem I have solved. In an open network environment, machines that provide services must be able to confirm the identities of people who request service. If I contact the mail server and ask for my mail, the service program must be able to verify that I am who I claim to be, right?

Euripides:     Right.

Athena:  You could solve the problem clumsily by requiring the mail server to ask for a password before I could use it. I prove who I am to the server by giving it my password.

Euripides:     That's clumsy all right. In a system like that, every server has to know your password. If the network has one thousand users, each server has to know one thousand passwords. If you want to change your password, you have to contact all servers and notify them of the change. I take it your system isn't this stupid.

Athena:  My system isn't stupid. It works like this: Not only do people have passwords, services have passwords too. Each user knows her or his password, each service program knows its password, and there's an AUTHENTICATION SERVICE that knows ALL passwords--each user's password, and each service's password. The authentication service stores the passwords in a single, centralized database.

Euripides:     Do you have a name for this authentication service?

Athena:  I haven't thought of one yet. Do you have any ideas?

Euripides:     What's the name of that fellow who ferries the dead across the River Styx?

Athena:  Charon?

Euripides:     Yeah, that's him. He won't take you across the river unless you can prove your identity.

Athena:  There you go Rip, trying to rewrite Greek mythology again. Charon doesn't care about your identity. He just wants to make sure that you're dead.

Euripides:     Have you got a better name?

Pause.

Athena:  No, not really.

Euripides:     Then let's call the authentication service "Charon."

Athena: 

Okay. I guess I should describe the system, huh?

Let's say you want to use a service, the mail service. In my system you cannot use a service unless, ah, Charon tells the service that you are who you claim to be. And you can't get the okay to use a service unless you have authenticated yourself to Charon. When you request authentication from Charon, you have to tell Charon the service for which you want the okay. If you want to use the mail server, you've got to tell Charon.

Charon asks you to prove your identity. You do so by providing your secret password. Charon takes your password and compares it to the one that is registered for you in the Charon database. If the two passwords match, Charon considers your identity proven.

 

Charon now has to convince the mail server that you are who you say you are. Since Charon knows all service passwords, it knows the mail service's password. It's conceivable that Charon could give you the password, which you could forward to the mail service as proof that you have authenticated yourself to Charon.

The problem is, Charon cannot give you the password directly, because then you would know it. The next time you wanted mail, you could circumvent Charon and use the mail server without correctly identifying yourself. You could even pretend to be someone else, and use the mail server in that other person's name.

So instead of giving you the mail server's password, Charon gives you a mail service TICKET. This ticket contains a version of your username that has been ENCRYPTED USING the MAIL SERVER'S PASSWORD.

Ticket in hand, you can now ask the mail service for your mail. You make your request by telling the mail server who you are, and furnishing the ticket that proves you are who you say you are.

The server uses its password to decrypt the ticket, and if the ticket decrypts properly, the server ends up with the username that Charon placed in the ticket.

The service compares this name with the name you sent along with the ticket. If the names match, the mail server considers your identity proven and proceeds to give you your mail.

What do you think of those apples?

Euripides:     I've got some questions.

Athena:  I figured. Well go ahead.

Euripides:     When a service program decrypts a ticket, how does it know that it has decrypted the ticket properly?

Athena:  I don't know.

Euripides:     Maybe you should include the service's name in the ticket. That way when a service decrypts a ticket, it can gauge its success on whether or not it can find its name in the decrypted ticket.

Athena: 

That sounds good to me. So the ticket looks something like this:

(She scrawls the following on a pad of paper:)

   TICKET -  {username:servicename}

Euripides:     So the service ticket contains just your username and the servicename?

Athena:  Encrypted with the service's password.

Euripides:     I don't think that's enough information to make the ticket secure.

Athena:  What do you mean?

Euripides:     Let's suppose you ask Charon for a mail server ticket. Charon prepares that ticket so that it has your username "tina" in it. Suppose I copy that ticket as it wizzes by on its way across the network from Charon to you. Suppose I convince my insecure workstation that my username is "tina." The mail client program on my workstation thinks I am you. In your name, the program forwards the stolen ticket to the mail server. The server decrypts the ticket and sees that it is valid. The username in the ticket matches the name of the user who sent the ticket. The mail server gives me your mail . . .

Athena:  Oh! Well that's not so good.

Euripides:    

But I think I know a way to fix this problem. Or to at least provide a partial fix to it. I think Charon should include more information in the service tickets it produces. In addition to the username, the ticket should also include the NETWORK ADDRESS from which the user asked Charon for the ticket. That gives you an additional level of security.

I'll illustrate. Suppose I steal your mail ticket now. The ticket has your workstation's network address in it, and this address does not match my workstation's address. In your name I forward the purloined ticket to the mail server. The server program extracts the username and network address from the ticket and attempts to match that information against the username and network address of the entity that sent the ticket. The username matches, but the network address does not. The server rejects the ticket because obviously it was stolen.

Athena:  Bravo, bravo! I wish I had thought of that.

Euripides:     Well that's what I'm around for.

Athena: 

So the revised ticket design looks like this:

She scrawls the following on a chalkboard:

  TICKET -   {username:ws_address:servicename}

Athena:  Now I'm really excited. Let's build a Charon system and see if it works!

Euripides:     Not so fast. I have some other questions about your system.

Athena:  All right. (Athena leans forward in her chair) Shoot.

Euripides:     Sounds like I've got to get a new ticket every time I want to use a service. If I'm putting in a full day's work, I'll probably want to get my mail more than once. Do I have to get a new ticket every time I want to get my mail? If that's true, I don't like your system.

Athena:  Ah . . . Well I don't see why tickets can't be reusable. If you get a ticket for the mail server, you ought to be able to use it again and again. For instance, when the mail client program makes a request for service in your name, it forwards a COPY of the ticket to the mail server.

Euripides:     That's better. But I still have problems. You seem to imply that I have to give Charon my password every time I want to use a service for which I don't have a ticket. I login and want to access my files. I fire off a request to Charon for the proper ticket and this means that I've had to use my password. Then I want to read my mail. Another request to Charon, I have to enter my password again. Now suppose I want to send one of my mail messages to the print server. Another Charon request and, well you get the picture.

Athena:  Uh, yeah, I do.

Euripides:     And if that weren't bad enough, consider this: it sounds like when you authenticate yourself to Charon, you send your secret password over the network in cleartext. Clever people like yours truly can monitor the network and steal copies of people's passwords. If I've got your password, I can use any service in your name. Athena sighs.

Athena:  These are serious problems. Guess I need to go back to the drawing board.

 

Scene III

The next morning, Athena catches Euripides at the coffee area. She taps him on the shoulder as he fills his cup.

The two head for the coffee machine.

Athena:  I've got a new version of Charon that solves our problems.

Euripides:     Really? That was quick.

Athena:  Well, you know, problems of this nature keep me up all night.

Euripides:     Must be your guilty conscience. Shall we repair to yon small conference room?

Athena:  Why not?

The two move to the small conference room.

Athena:  I'll begin by stating the problems again, but I'll invert them so that they become requirements of the system.

Athena clears her throat.

Athena:  The first requirement: Users only have to enter their passwords once, at the beginning of their workstation sessions. This requirement implies that you shouldn't have to enter your password every time you need a new service ticket. The second requirement: passwords should not be sent over the network in clear text.

Euripides:     Okay.

Athena: 

I'll start with the first requirement: you should only have to use your password once. I've met this requirement by inventing a new network service. It's called the "ticket-granting" service, a service that issues Charon tickets to users who have already proven their identity to Charon. You can use this ticket-granting service if you have a ticket for it, a ticket-granting ticket.

The ticket-granting service is really just a version of Charon in as much as it has access to the Charon database. It's a part of Charon that lets you authenticate yourself with a ticket instead of a password.

Anyhow, the authentication system now works as follows: you login to a workstation and use a program called kinit to contact the Charon server. You prove your identity to Charon, and the kinit program gets you a ticket-granting ticket.

Now say you want to get your mail from the mail server. You don't have a mail server ticket yet, so you use the "ticket-granting" ticket to get the mail server ticket for you. You don't have to use your password to get the new ticket.

Euripides:     Do I have to get a new "ticket-granting" ticket every time I need to get to another network service?.

Athena:  No. Remember, we agreed last time that tickets can be reused. Once you have acquired a ticket-granting ticket, you don't need to get another. You use the ticket-granting ticket to get the other tickets you need.

Euripides:     Okay, that makes sense. And since you can reuse tickets, once the ticket-granting service has given you a ticket for a particular service, you don't need to get that particular ticket again.

Athena:  Yeah, isn't that elegant?

Euripides:     Okay, I buy it so far . . . As long as you didn't have to send your password in cleartext over the network when you got the ticket-granting ticket.

Athena: 

Like I said, I've solved that problem as well. The thing is, when I say you have to contact Charon to get the ticket-granting ticket, I make it sound as though you have to send your password in cleartext over the network to the Charon Server. But it doesn't have to be that way.

Here's really what happens. When you use the kinit program to get the ticket-granting ticket, kinit doesn't send your password to the Charon server, kinit sends only your username.

Euripides:     Fine.

Athena: 

Charon uses the username to look up your password. Next Charon builds a packet of data that contains the ticket-granting ticket. Before it sends you the packet, Charon uses your password to encrypt the packet's contents.

Your workstation receives the ticket packet. You enter your password. Kinit attempts to decrypt the ticket with the password you entered. If kinit succeeds, you have successfully authenticated yourself to Charon. You now possess a ticket-granting ticket, and that ticket can get you the other tickets you require.

How's that for some fancy thinking?

Euripides:     I don't know . . . I'm trying to think myself. You know, I think the parts of the system that you just described work pretty well. Your system requires me to authenticate myself only once. Thereafter Charon can issue me service tickets without my being aware of it. Seamless, seamless in that regard. But there's something about the design of the service ticket that troubles me somehow. It has to do with the fact that tickets are reusable. Now I agree that they have to be reusable, but reusable tickets are, by their nature, very dangerous.

Athena:  What do you mean?

Euripides:    

Look at it this way. Suppose you are using an insecure workstation. In the course of your login session you acquire a mail service ticket, a printing service ticket, and a file service ticket. Suppose you inadvertantly leave these tickets on the workstation when you logout.

Now suppose I login to the workstation and find those tickets. I'm feeling like causing trouble, so I make the workstation think that I am you. Since the tickets are made out in your name, I can use the mail client program to access your mail, I can use the file service client to access and remove your files, and I can use the printing command to run up huge bills on your account. All because these tickets have been accidentally left lying around.

And nothing can keep me from copying these tickets to a place of my own. I can continue to use them for all eternity.

Athena: 

But that's an easy fix. We just write a program that destroys a user's tickets after each login session. You can't use tickets that have been destroyed.

Euripides:    

Well obviously your system must have a ticket-destroying program, but it's foolish to make users rely on such a thing. You can't count on users to remember to destroy their tickets every time they finish a workstation session. And even if you rely upon your users to destroy their tickets, consider the following scenario.

I've got a program that watches the network and copies service tickets as they zip accross the network. Suppose I feel like victimizing you. I wait for you to begin a workstation session, I turn on my program and copy a bunch of your tickets.

I wait for you to finish your session, and eventually you logout and leave. I fiddle with my workstation's network software and change its address so that it matches the address of the workstation you were using when you acquired the tickets I copied. I make my workstation believe that I am you. I have your tickets, your username, and the correct network address. I can REPLAY these tickets and use services in your name.

It doesn't matter that you destroyed your tickets before you ended your workstation session. The tickets I have stolen are valid for as long as I care to use them, because your current ticket design does not place a limit on the number of times you can reuse a ticket, or on how long a ticket remains valid.

Athena:  Oh I see what you're saying! Tickets can't be valid forever because they would then constitute a huge security risk. We have to restrict the length of time for which a ticket can be used, perhaps give each ticket some kind of expiration date.

Euripides:     Exactly. I think each ticket needs to have two additional pieces of information: a lifespan that indicates the length of time for which the ticket is valid, and a timestamp that indicates the date and time at which Charon issued the ticket. So a ticket would look something like this:

Euripides goes to the chalkboard and scrawls the following:

   TICKET   {username:address:servicename:lifespan:timestamp}

Euripides:     Now when a service decrypts tickets, it checks the ticket's username and address against the name and address of the person sending the ticket, and it uses the timestamp and lifespan information to see if the ticket has expired.

Athena:  All right. What kind of lifetime should the typical service ticket have?

Euripides:     I don't know. Probably the length of a typical workstation session. Say eight hours.

Athena:  So if I sit at my workstation for more than eight hours, all my tickets expire. That includes my ticket-granting ticket. So I have to reauthenticate myself to Charon after eight hours.

Euripides:     That's not unreasonable is it?

Athena:  I guess not. So we're settled -- tickets expire after eight hours. Now I've got a question for you. Suppose I have copied YOUR tickets from the network--

Euripides:     (Eyes twinkling) Aw, Tina! You wouldn't really do that would you?

Athena: 

This is just for the sake of argument. I've copied your tickets. Now I wait for you to logout. Suppose you have a doctor's appointment or a class to attend, so you end your workstation session after a couple of hours. You are a smart boots and have destroyed your copies of the tickets before logging out.

But I've stolen your tickets, and they are good for about six hours. That gives me ample time to pillage your files and print one thousand copies of whatever in your name.

See, the lifetime-timestamp business works fine in the event that a ticket thief chooses to replay the ticket after the ticket has expired. If the thief can replay the ticket before that . . .

Euripides:     Uh, well . . . Of course you are right.

Athena:  I think we have run into a major problem. (She sighs.)

Pause.

Euripides:     I guess that means you'll be busy tonight. Want more coffee?

Athena:  Why not.

 

Scene IV

The next morning in Euripides' office. Athena knocks on the door.

Euripides:     You've got rings under your eyes this morning.

Athena:  Well, you know. Another one of those long nights.

Euripides:     Have you solved the replay problem?

Athena:  I think so.

Euripides:     Have a seat.

She does.

Athena:  As usual, I feel compelled to restate the problem. Tickets are reusable within a limited timespan, say eight hours. If someone steals your tickets and chooses to replay them before they expire, we can't do anything to stop them.

Euripides:     That's the problem.

Athena:  We could beat the problem if we designed the tickets so they couldn't be reusable.

Euripides:     But then you would have to get a new ticket every time you wanted to use a network service.

Athena: 

Right. That is a clumsy solution at best. (Pause.) Ah, how do I proceed with my argument? (She ponders for a moment.)

All right, I'm going to restate the problem again, this time in the form of a requirement. A network service must be able to prove that the person using a ticket is the same person to whom that ticket was issued.

Let me trace the authentication process again and see if I can tease out an appropriate way to illustrate my solution to this problem.

I want to use a certain network service. I access that service by starting a client program on my workstation. The client sends three things to the service machine-- my name, my workstation's network address, and the appropriate service ticket.

The ticket contains the name of the person it was issued to and the address of the workstation that person was using when he or she acquired the ticket. It also contains an expiration date in the form of a lifespan and a timestamp. All this information has been encrypted in the service's Charon password.

Our current authentication scheme relies on the following tests:

Can the service decrypt the ticket?

Has the ticket expired?

Do the name and workstation address specified in the ticket match the name and address of the person who sent the ticket?

What do these tests prove? The first test proves that the ticket either did or did not come from Charon. If the ticket cannot be decrypted, it did not come from the real Charon. The real Charon would have encrypted the ticket with the service's password. Charon and the service are the only two entities that know the service's password. If the ticket decrypts successfully, the service knows that it came from the real Charon. This test prevents folks from building fake Charon tickets.

The second test checks the ticket's lifespan and timestamp. If it has expired, the service rejects the ticket. This test stops people from using old tickets, tickets that perhaps were stolen.

The third test checks the ticket-user's name and address against the name and address of the person specified in the ticket. If the test fails, the ticket-user has obtained (perhaps surreptitiously) another person's ticket. The ticket is of course rejected.

If the names and addresses do match, what has the test proved? Nothing. Scallywags can steal tickets from the network, change their workstation addresses and usernames appropriately, and rifle other folks resources. As I pointed out yesterday, tickets can be replayed as long as they haven't expired. They can be replayed because a service cannot determine that the person sending the ticket is actually the ticket's legitimate owner.

The service cannot make this determination because it does not share a secret with the user. Look at it this way. If I'm on watch at Elsinore, you know, the castle in Hamlet, and you are supposed to relieve me, I'm not supposed to let you take my place unless you can provide the correct password. That's the case where the two of us share a secret. And it's probably a secret that someone else made up for everyone who stands on watch.

So I was thinking last night, why not have Charon make up a password for the legitimate ticket-owner to share with the service? Charon gives a copy of this session key to the service, and a copy to the user. When the service receives a ticket from a user, it can use the session key to test the user's identity.

Euripides:     Wait a second. How is Charon going to give both parties the session key?

Athena:  The ticket-owner gets the session key as part of the reply from Charon. Like this:

She scrawls the following on a chalkboard:

 CHARON REPLY  -  [sessionkey|ticket]

The service's copy of the session key comes inside the ticket, and the service gets the key when it decrypts the ticket. So the ticket looks like this:

 TICKET -  {sessionkey:username:address:servicename:lifespan:timestamp}

When you want to get to a service, the client program you start builds what I call an AUTHENTICATOR. The authenticator contains your name and your workstation's address. The client encrypts this information with the session key, the copy of the session key you received when you requested the ticket.

  AUTHENTICATOR - {username:address} encrypted with session key

After building the authenticator, the client sends it and the ticket to the service. The service cannot decrypt the authenticator yet because it doesn't have the session key. That key is in the ticket, so the service first decrypts the ticket.

After decrypting the ticket, the service ends up with the the following information:

The ticket's lifespan and timestamp;

The ticket-owner's name;

The ticket-owner's network address;

The session key.

The service checks to see if the ticket has expired. If all is well in that regard, the service next uses the session key to decrypt the authenticator. If the decryption proceeds without a hitch, the service ends up with a username and a network address. The service tests this information against the name and address found in the ticket, AND the name and address of the person who sent the ticket and authenticator. If everything matches, the service has determined that the ticket-sender is indeed the ticket's real owner.

Athena pauses, clears her throat, drinks some coffee.

I think the session key-authenticator business takes care of the replay problem.

Euripides:     Maybe. But I wonder . . . To break this version of the system, I must have the proper authenticator for the service.

Athena:  No. You must have the authenticator AND the ticket for the service. The authenticator is worthless without the ticket because the service cannot decrypt the authenticator without first having the appropriate session key, and the service cannnot get the appropriate session key without first decrypting the ticket.

Euripides:     Okay, I understand that, but didn't you say that when a client program contacts the server, it sends the ticket and matching authenticator together?

Athena:  Yes, I guess I said that.

Euripides:   If that's what actually happens, what prevents me from stealing the ticket and authenticator at the same time? I'm sure I could write a program to do the job. If I've got the ticket and its authenticator, I believe I can use the two as long as the ticket has not expired. I just have to change my workstation address and username appropriately. True?

Athena:  (Biting her lip) True. How dispiriting.

Euripides:     Wait, wait, wait! This isn't such a big deal. Tickets are reusable as long as they haven't expired, but that doesn't mean that authenticators have to be reusable. Suppose we design the system so that authenticators can only be used once. Does that buy us anything?

Athena: 

Well, it might. Let's see, the client program builds the authenticator, then sends it with the ticket to the service. You copy both ticket and authenticator as they move from my workstation to the server. But the ticket and authenticator arrive at the server before you can send your copies. If the authenticator can only be used once, your copy of it is no good, and you lose when you attempt to replay your ticket and authenticator.

Well, that's a relief. So all we have to do is invent a way to make the authenticator a one-time usable thing.

Euripides:    

No problem. Let's just put a lifespan and timestamp on them. Suppose each authenticator has a lifespan of a couple of minutes. When you want to use a service, your client program builds the authenticator, stamps it with the current time, then sends it and the ticket to the server.

The server receives the ticket and authenticator and goes about its business. When the server decrypts the authenticator, it checks the authenticator's lifespan and timestamp. If the authenticator hasn't expired, and everything else checks properly, the server considers you authenticated.

Suppose I copied the athenticator and ticket as they crossed the network. I have to change my workstation's network address and my username, and I have to do this all in a couple of minutes. That's a pretty tall order. In fact I don't think it's possible. Unless . . .

Well, here's a potential problem. Suppose that instead of copying the ticket and authenticator as they travel from your workstation to the server, I copy original ticket packet that comes from Charon, the packet you receive when you ask Charon to give you a ticket.

This packet, as I recall, has two copies of the session key in it: one for you and one for the service. The one for the service is hidden in the ticket and I can't get to it, but what about the other one, the one you use to build authenticators?

If I can get that copy of the session key, I can build my own authenticators, and if I can build my own authenticators, I can break the system.

Athena: 

That's something I thought about last night, but then I traced the process of acquiring tickets and found that it wasn't possible to steal authenticators that way.

You sit down at a workstation and use the kinit program to get your ticket-granting ticket. Kinit asks for your username, and after you enter it, kinit forwards the name to Charon.

Charon uses your name to look up your password, then proceeds to build a ticket-granting ticket for you. As part of this process, Charon creates a session key that you will share with the ticket-granting service. Charon puts a copy of the session key in the ticket-granting ticket, and puts your copy in the the ticket packet that you are about to receive. But before it sends you this packet, Charon encrypts the whole thing with your password.

Charon sends the packet across the network. Someone can copy the packet as it goes by, but they can't do anything with it because it has been encrypted with your password. Specifically, no one can steal the ticket-granting session key.

Kinit receives the ticket packet and prompts you for a password, which you enter. If you enter the correct password, kinit can decrypt the packet and give you your copy of the session key.

Now that you've taken care of the kinit business, you want to get your mail. You start the mail client program. This program looks for a mail service ticket and doesn't find one (after all, you haven't tried to get your mail yet). The client must use the ticket-granting ticket to ask the ticket-granting service for a mail service ticket.

The client builds an authenticator for the ticket-granting transaction and encrypts the authenticator with your copy of the ticket-granting session key. The client then sends Charon the authenticator, the ticket-granting ticket, your name, your workstation's address, and the name of the mail service.

The ticket-granting service receives this stuff and runs through the authentication checks. If everything checks properly, the ticket-granting service ends up with a copy of the session key that it shares with you. Now the ticket-granting service builds you a mail service ticket, and during this process, creates a new session key for you to share with the mail service.

The ticket-granting service now prepares a ticket packet to send back to your workstation. The packet contains the ticket and your copy of the mail service session key. But before it sends the packet, the ticket-granting service encrypts the packet with its copy of the TICKET-GRANTING session key. That done, the packet is sent on its way.

So here comes the mail service ticket packet, loping across the network. Suppose some network ogre copies it as it goes by. The ogre is out of luck because the packet is encrypted with the ticket-granting session key; you and the ticket-granting service are the only entities that know this key. Since the ogre cannot decrypt the mail ticket packet, the ogre cannot discover the MAIL SESSION KEY. Without this session key, the ogre cannot use any of the mail service tickets you might subsequently send across the network.

So I think we're safe. What do you think?

Euripides:     Perhaps.

Athena:  Perhaps! Is that all you can say!

Euripides:     (laughing) Don't get upset. You should know my ways by now. I guess it is mean of me, and you up half the night.

Athena:  Pthhhhh!

Euripides:     All right, three-quarters of the night. Actually, the system is beginning to sound acceptible. This session key business solves a problem that I thought of last night: the problem of mutual authentication.

Pause.

Mind if I talk for a minute?

Athena:  (A trifle coldly) Be my guest.

Euripides:    

You are so kind. (Euripides clears his throat.) Last night, while visions of session keys and authenticators danced in your head, I was trying to find new problems with the system, and I found one that I thought was pretty serious. I'll illustrate it by way of the following scenario.

Suppose you are sick of your current job and have determined that it is in your best interest to move on. You want to print your resume on the company's wizz-bang laser printer so that headhunters and potential employers can take note of your classiness.

So you enter the printing command, and direct it to send the resume to the appropriate print server. The command gets the proper service ticket, if you don't already have it, then sends the ticket in your name to the appropriate print server. At least that's where you think it's headed. You don't in fact know that the request is headed for the right print server.

Suppose that some unscrupulous hacker--say it's your boss--has screwed system around so that he redirects your request and its ticket to the print server in his office. His print service program doesn't care about the ticket or its contents. It throws away the ticket and sends a message to your workstation indicating that the ticket passed muster, and that the server is ready and willing to print your job. The printing command sends the job to the fraudulant print server and the enemy ends up with your resume.

I'll state the problem by way of contrast. Without session keys and authenticators, Charon can protect its servers from false users, but it cannot protect its users from false servers. The system needs a way for client programs to authenticate the server before sending sensitive information to the service. The system must allow for mutual authentication.

But the session key solves this problem as long as you design your client programs properly. Back to the print server scenario. I want a print client program that makes sure the service it's sending jobs to is the legitimate service.

Here's what such a program does. I enter the printing command and give it a filename, the name of my resume. Assume that I have a print service ticket and session key. The client program uses the session key to build an authenticator, then sends the authenticator and ticket to the "supposed" print server. The client DOES NOT send the resume yet; it waits for a response from the service.

The real service receives the ticket and authenticator, decrypts the ticket and extracts the session key, then uses the session key to decrypt the authenticator. This done, the service runs all the appropriate authentication tests.

Assume the tests confirm my identity. Now the server prepares a reply packet so that it can prove its identity to the client program. It uses its copy of the session key to encrypt the reply packet, then sends the packet to the waiting client.

The client receives the packet and attempts to decrypt it with my copy of the session key. If the packet decrypts properly and yields the correct server response message, my client program knows that the server that encrypted the packet is the real server. Now the client sends the resume job to the print service.

Suppose my boss screwed around the system so that his print server poses as the one I want. My client sends the authenticator and ticket to the "print service" and waits for a response. The fake print service cannot generate the correct response because it cannot decrypt the ticket and get the session key. My client will not send the job unless it receives the correct response. Eventually the client gives up waiting and exits. My print job does not get completed, but at least my resume did not end up on the desk of the enemy.

You know, I think we have a solid basis on which to implement the Charon Authentication System.

Athena:  Perhaps. Anyway, I don't like the name "Charon."

Euripides:     You don't? Since when?

Athena:  I've never liked it, because the name doesn't make sense. I was talking to my Uncle Hades about it the other day, and he suggested another name, the name of his three-headed watch dog.

Euripides:     Oh, you mean "Cerberus."

Athena:  Bite your tongue Rip! "Cerberus" indeed . . .

Euripides:     Er, isn't that the name?

Athena:  Yeah, if you happen to be a Roman! I'm a Greek goddess, he's a Greek watch dog, and his name is "Kerberos," "Kerberos" with a K.

Euripides:     Okay, okay, don't throw thunderbolts. I'll buy the name. Actually, it has a nice ring to it. Adios Charon and hello to Kerberos.

 

Afterword

The dialogue was written in 1988 to help its readers understand the fundamental reasons for why the Kerberos V4 protocol was the way it was. Over the years, it has served this job very well.

 

When I converted this document to HTML, I was amazed how much of this document was still applicable for the Kerberos V5 protocol. Although many things were changed, the basic core ideas of the protocol have remained the same. Indeed, there are only two changes where Kerberos V5 differs from description of the "Kerberos" protocol in this dialoge.

 

The first change was born out of the recognition that using a small five minute time skew wasn't necessarily sufficient to prevent replay attacks from an attacker who used a program to automatically grab the ticket and the authenticator as they traversed the network, and then immediately resent them to launch a replay attack.

 

In Kerberos V5, authenticators are made to be truly "once-only" by having servers which accept tickets to have a "replay cache" which keeps note of authenticators have been presented to the server recently. If an attacker tries to snatch an authenticator and reuse it, even during the five-minute acceptance window, the replay cache will be able to determine that the authenticator has already been presented to the server.

 

The second major change to the protocol is that the ticket is no longer encrypted in the user's password when it is sent from the Kerberos server to kinit during the initial ticket exchange. The ticket is already encrypted in the ticket granting server's secret key; furthermore when it is actually used to obtain other tickets, it gets sent in the network in the clear anyway. Hence, there is no reason why the ticket should be encrypted again in the user's password. (The rest of the Kerberos server's reply to the user, containing for example the user's copy of the ticket session key, is still encrypted in the user's password, of course.)

 

A similar change was also made to the ticket granting service (TGS) protocol; tickets returned by TGS are also no longer encrypted by the ticket-granting ticket's service key, since application tickets are already encrypted by the application server's secret key. So for example, the packet that in Kerberos V4 which would have looked like this:

 

   KDC_REPLY = {TICKET, client, server, K_session}K_user

where "{X}K_Y" is read "X encrypted using key K_Y" and

   TICKET = {client, server, start_time, lifetime, K_session}K_server

In Kerberos V5, the KDC_REPLY now would look like this:

  KDC_REPLY = TICKET, {client, server, K_session}K_user

Of course, there are many new features in Kerberos V5 as well. Users can now securely forward their tickets so that they can be used at another network location; in addition, users may also delagate a subset of their authorization rights to a server, so that the server can act as a proxy on behalf of a user. Other new features include the ability to replace DES with a more secure cryptographic algorithm, such as triple-DES. Readers who are interested in more of the changes between Kerberos V4 and V5 are invited to read The Evolution of the Kerberos Authentication System, which was authored by Cliff Neumann and Theodore Ts'o.

 

I hope you've enjoyed this quick little introduction to the Kerberos protocol. I wish you well in your futher explorations!

 

Theodore Ts'o, February 1997.

 

Permission to use, copy, modify, and distribute this documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the documentation without specific, written prior permission. M.I.T. makes no representations about the suitability of this documentation for any purpose. It is provided "as is" without express or implied warranty.

 

For comments/suggestions about this page, mail: tytso@mit.edu

 

Kerberos的原理


这是MIT(Massachusetts Institute of Technology)为了帮助人们理解Kerberos的原理而写的一篇对话集。里面有两个虚构的人物:Athena和Euripides,通过 Athena不断的构思和Euripides不断的寻找其中的漏洞,使大家明白了Kerberos协议的原理。
Athena: 雅典娜,智慧与技艺的女神。
Euripides:欧里庇得斯, 希腊的悲剧诗人。

译文如下:
第一幕
在一个小工作间里。Athena和Euripides正在相邻的终端上工作。 
Athena: 嗨,这个分时操作系统实在太慢了。我根本无法工作,因为每个人都登上去了。
Euripides: 不要对我报怨。我只是在这工作。 
Athena: 你知道我们需要什么吗?我们需要给每一个人一台工作,这样大家就不会担心计算机的速度了。并且,我们需要一个网络把所有的计算机都联起来。 
Euripides: 好。那么我们差不多要一千台工作站? 
Athena: 差不多吧。 
Euripides: 你知道一台普通的工作站的硬盘有多大吗?那里放不下所有的软件。 
Athena: 我已经有主意了。我们可以把系统软件放到服务器上。当你登录到工作站的时候,工作站会通过网络与其中一台服务器上的系统软件联系。这样的设置让一组工作站都使用同一份系统软件,并且利于系统软件的升級。只需改动服务器就可以了。 
Euripides: 好的。个人的文件怎到办呢?在分时操作系统上,我可以登录并从终端上取走我的文件。我能到工作站上取我的文件吗?我要象PC用户一样把我的文件放到磁盘上去吗?我希望不。 
Athena: 我想我们可以其它机器来存文件。你可以到任何一台机器上登录去取你的文件。 
Euripides: 打印怎么办呢?每个工作站都要有自已的打印机吗?谁来付钱?电子邮件呢?你怎么把邮件送到所有的工作站上去呢? 
Athena: 啊…..很明显我们没钱为每个人配一台打印机,但我们有专门的机器做打印服务。你把请求送到服务器,它就为你打印。邮件也可以这样做。专门有一台邮件服务器。你如果想要你的邮件,就联系邮件服务器,取走你的邮件。 
Euripides: 你的工作站系统听起来很不错。如果我有一台,你知道我要做什么吗?我要找出你的用户名,让我的工作站认为我就是你。然后我就去邮件服务器取走你的邮件。我会联上你的文件服务器,移走你的文件,然后-- 
Athena: 你能做得到吗? 
Euripides: 当然!这些网络服务器怎么会知道我不是你? 
Athena: 嗯,我不知道.我想我需要认真思考一下. 
Euripides: 好吧。你想出来后告诉我.

第二幕 
Euripides的办公室,第二天早上。Euripides坐在他的桌子旁边,读着他的邮件。Athena来敲门. 
Athena: 我已经想出怎样保护一个开放的网络系统,使象你那样不道德的人不能用别人的名字使用网络服务。 
Euripides: 真的吗?坐吧。 她坐下了。 
Athena: 在我开始描述之前,我可以为我们的讨论先做一个约定吗? 
Euripides: 什么约定? 
Athena: 好,假设我这样说:”我想要我的邮件,于是我与邮件服务器联系,请求它把邮件送到我的工作站上来。”实际上我并没有联系服务器。我用一个程序来与服务器联系并取得我的邮件,这个程序就是这个服务的客户端。 但我不想每次与服务器交互的时侯说:”客户端怎样怎样”.我只想说:”我怎样怎样,”记住,客户端在代表我做所有的事。这样可以吗? 
Euripides: 当然。没问题. 
Athena: 好。那么我要开始阐述我所解决的问题了。在一个开放的网络环境中,提供服务的机器必须能够识别请求服务的实体的身份。如果我去邮件服务器申请我的邮件,服务程序必须能够验证我就是我所申明的那个人。 
Euripides: 没错. 
Athena: 你可以用一个笨办法解决这个问题:服务器让你输入你的口令。通过输口令的办法我可以证明我是谁。 
Euripides: 那确实很笨拙。在像那样的系统里面,每一个服务器必须知道你的口令。如果网络有一千个用户,那每个服务器就要知道一千个口令。如果你想改变口令,你就必须联系所有服务器,通知它们修改口令。我想你的系统不会那么笨。 
Athena: 我的系统没那么笨。它是象这样工作的:不光人有口令,服务也有口令。每个用户知道他们自已的口令,每个服务也知道它自已的口令。有一个认证服务知道所有的口令,用户的和服务的。认证服务把口令保存在一个单独的中央数据库中。 
Euripides: 这个认证服务有一个名字吗? 
Athena: 我还没想好。你想一个吧? 
Euripides: 把死人送过冥河的人是谁? 
Athena: Charon? 
Euripides: 对,就是他。如果他不能证实你的身份的话,他就不会把你送过河。 
Athena: 你瞎编,是不是想重写希腊神话。Charon不关心你的身份,他只是确定你死了没有。 
Euripides: 你有更好的名字吗? 停了一下。 
Athena: 没有,真的没有。 
Euripides: 好,那我们就把这个认证服务“Charon”。 
Athena: 好,我猜我该描述一下这个系统了吧,嗯? 比如说我们想要一种服务:邮件。在我的系统里面你无法使用一种服务,除非Charon告诉服务你确实是你所申明的人。也就是说你必须得到Charon的认证才能使用服务。当你向Charon请求认证的时候,你必须告诉Charon你要使用哪一个服务。如果你想用邮件,你要告诉Charon。 Charon请你证明你的身份。于是你送给它你的密码。Charon把你的密码和它数据库中的密码相比较。如果相等,Charon就认为你通过了验证。 Charon现在就要让邮件服务知道你通过了验证。既然Charon知道所有服务的密码,它也知道邮件服务的密码。Charon把邮件服务的密码给你,你就可以使用这个密码使邮件服务相信你已通过验证。 问题是,Charon不能直接给你密码,因为你会知道它。下次你想要邮件服务的时候,你就会绕过Charon使用邮件服务而不需要认证。你也可以假装某人来使用邮件服务。 所以不是直接给你邮件服务的密码,Charon给你一张邮件服务的“票”。这张票含有你的名字,并且名字是用邮件服务的密码加密的。 拿到票,你就可以向邮件服务请求你的邮件。你向邮件服务提出请求,并用你的票来证明你的身份。 服务用它自已的密码来把票解密,如果票能被正确的解密,服务器将票里的用户名取出。服务把这个名字和随票一起送上的用户名进行比较。如果相符,服务器就认为你通过了验证,就把你的邮件发给你。 你认为怎么样? 
Euripides: 我有些问题。 
Athena: 我猜到了。请讲。 
Euripides: 当服务解密一张票的时候,它如何知道它是被正确的解密的? 
Athena: 我不知道。 
Euripides: 也许你应该在票里包含有服务的名字。这样当服务解密票的时候,它就可以通过能否在票中找到自已的名字来判断解密是否正确。 
Athena: 很好。那票就应该是这个样子: (她把下面的东西写在了一张纸上) 票-{用户名:服务名} 
Euripides: 那票就只包含用户名和服务名? 
Athena: 用服务的口令加密。 
Euripides: 我不认为这些信息就可以让票安全。 
Athena: 什么意思? 
Euripides: 假设你向Charon请求一张邮件服务的票。Charon准备了一张有你名字“tina” 的票。假设在当票从Charon传给你的过程中我拷了一份。假设我让我的工作站相信我的用户名是”tina“。邮件客户程序认为我就是你。用你的名字邮件客户程序用偷来的票向邮件服务器提出请求。邮件服务器把票解密,认为它是合法的。票里的用户名和发送该票的用户名是匹配的。邮件服务器就会发给 我你的邮件。 
Athena: 喔!那可不太好。 
Euripides: 但是我想到了一个办法来解决这个问题。或者说部分解决。我想Charon应该在票中包含更多的信息。除了用户名,票还应包含请求票的用户的IP地址。这将给你增加一层安全性。 我来演示。假设现在我偷了你的票。这票有你工作站的IP地址,并且这地址配不上我的工作站的地址。用你的名字我把偷来的票送给邮件服务器。服务程序把用户名和网络地址从票中解出,并试图匹配用户名和网络地址。用户名匹配可网络地址不匹配。服务器拒绝了这张票,因为它明显是偷来的。 
Athena: 英雄,英雄!我怎么会没想到。 
Euripides: 好了,这就是我要表述的。 
Athena: 那么票应该是这个样子的。 她把下面的东西写在了黑板上。 票-{用户名:地址:服务名} 
Athena: 现在我真的很激动。让我们来建一个Charon系统看看它是否工作! 
Euripides: 没那么快。对于你的系统我还有些问题。 
Athena: 好吧。(Athena从她的椅子上探出了身子)快说。 
Euripides: 听起来好像每次我想要得到服务我都要去取一张新票。如果我整天的工作,我可能不只一次的要取我的邮件。我每次取邮件都要去取一张新票吗?如果真是这样,我不喜欢你的系统。 
Athena: 啊。。。我不明白为什么票不能被重用。如果我已经得到了一张邮件服务的票,我可以一次又一次使用它。当邮件客户程序用你的名字请求了服务,它就传了一份票的拷贝给服务。 
Euripides: 好一些。但我仍有问题。你似乎暗示我每次使用还没有票的服务时,我都必须给Charon我的密码我登录后想取我的文件。我向Charon请求我的票,这意味着我不得不使用我的密码。然后我想读我的邮件。又向Charon发一次请求,我又要输一次我的密码。现在假设我想把我的邮件送去打印。我又要向Charon发一次请求。你知道了吧? 
Athena: 啊,是的,我明白了。 
Euripides: 并且如果这还不够糟的话,想想看:它好像是这样,当每次你要向Charon认证的时候,你就要用明文在网络上传输你的口令。像你这样的聪明人可以监视网络并且得到别人的口令。如果我得到你的口令,我就可以用你的名字来使用任何服务。
Athena叹了口气。
Athena: 确实有严重的问题。我想我该回设计室去了。

第三幕
第二天一早,Athena在咖啡间遇上了Euripides。在Euripides倒咖啡的时候,Athena拍了拍Euripides. 
Athena: 我有了一个新的Charon的版本来解决我们的问题。 
Euripides: 真的吗?好快呀。 
Athena: 好,你看,这些问题困扰了我一夜。 
Euripides: 一定是你良心发现了。我们去那边的小会议室吧? 
Athena: 好的。 
两人去了小会议室。 
Athena: 我要重新描述问题,但我要根据我们的需要进行适当的转换。 
Athena清了清嗓子。 
Athena: 第一个限制:用户只输一次口令,在他们工作站启动的时候,这意味着当你需要申请新的服务的票时,不需输入你的口令。第二个限制:口令不能在网络上进行明文传输。 
Euripides: 好的。 
Athena: 我以第一项限制开始:你只需要输入你的口令一次。我创造了一个新的网络服务来解决这个问题。 它叫做“票据授权”服务,这个服务把Charon的票给用户。使用它必须要有票:票据授权的票。 票据授权服务其实只是Charon的一个版本,它可以存取Charon的数据库。它是Charon的一部分,可以让你通过票而不是口令来进行认证。 总之,认证系统现在是象这样工作的:你登录到一个工作站,用一个叫kinit的程序与Charon 服务器通讯。你向Charon证明你的身份,kinit程序取得一张票据授权票。 现在你想从邮件服务器上取你的邮件。你还没有邮件服务器的票,所以你用“票据授权”票去取邮件服务的票。你不需要使用口令去取新的服务票。 
Euripides: 每次我想要另一种网络服务的时候,我都要去取一张“票据授权”票吗? 
Athena: 不。记住,上次我们已经同意票是能被重用的。一旦你要用到票据授权票,直接用就可以了。 
Euripides: 好,有道理。既然你能重用票,一旦你得到了某个服务的票,你就无需再去取了。 
Athena: 对啊,那不好吗? 
Euripides: 好的,我没话说,只要你在取得票据授权票的时候没有用明文在网上传输你的口令。 
Athena: 如我所说,我已解决了这个问题。听起来好像是,当我说我要和Charon联系取得票据授权票的时候,你就要在网络上传输明文密码。但其实不是这样的。 实际上是,当你用kinit程序取得票据授权票的时候,kinit没有把你的口令送给Charon服务器,kinit只送你的用户名。 
Euripides: 很好。 
Athena: Charon用用户名去查找你的口令。然后Charon就会组一个包含票据授权票的包。在送给你之前,Charon用你的口令去把这个包加密。 你的工作站收到了包。你输入你的口令。kinit用你的口令对这个包进行解密。如果成功你就向Charon成功的进行了认证。你现在有了票据授权票,你可以用这张票来取得其它的票。 这些奇思妙想怎么样? 
Euripides: 我不知道…我正在思考。你知道你的系统一部分工作得很好。你的系统只需要我认证一次。以后,Charon会给我服务的票而我需要关心。天衣无缝,天衣无缝。但服务票的设计还是有一些困扰我。服务票是可重用的。我同意它们应该能被重用,但重用的服务票,由于它们自身的性质,是非常危险的。 
Athena: 什么意思? 
Euripides: 这样看。假设你正在用一个不安全的工作站。在你登入后,你需要邮件服务票,打印票,和文件服务票。假设你无意中在你退出后留下了那些票。 现在假设我登录到那个工作站并且发现了那些票。我想制造一些麻烦,于是我就用你的名字登录了。既然那些票上是你的名字,那我就可以取你的邮件,打大量的文件。这些完全是因为这些票被偶然的放在了那里。 并且我还可以把这些票拷走,永远的使用它们。 
Athena: 但是这很好解决。我们可以写一个程序,在用户退出的时候把票销毁掉,这些票也主不能再用了。 
Euripides: 那么很明显你的统应该有一个票据销毁程序,让用户依赖这样的机制是非常愚蠢的。你不能指望用户在他们退出的时候会销毁票据。并且甚至不能依赖销毁票据本身,看下面的情况。 我有一个程序可以监视网络并且拷内别人的服务票据。假设我想牺牲你。我等你登到工作站的时候,打开我的程序并拷贝一份你的票。 我等你退出并离开。我把我的工作站的地址调整为你登录时用的地址。我让工作站认为我是你。我有你的票,你的用户名,你的地址。我可以用这些票来使用你的服务。 你离开工作站时销毁你的票已没并系。这些我偷来的票可以一直使用下去,因为你现在的票并没有可以使用多少次的期限,或可以使用多长的时间。 
Athena: 哦,我明白你所说的了!票不能是永远合法的,因为它可能是一个非常大的安全隐患。我们应该限制每一张票可以用多长的时间,也许可以给每张票设一个有效期。 
Euripides: 非常正确。我想票需要增加两项信息:生存期表示票多长时间内是合法的,和一个时间标记来说明Charon是什么时候发出这张票的。
Euripides走到了黑板写下了如下的内容: 票{用户名:地址:服务名:有效期:时间戳}
Euripides: 现在当服务解开票时,它检查票的用户名,地址是否与发送者匹配,然后它用有效期和时间戳来检查票是否有效。 
Athena: 很好。典型的票使用哪长的有效期呢? 
Euripides: 我不知道。也许是一个典型工作站的工作周期。就八小时吧。 
Athena: 那如果我在工作站呆的时间超过八小时,所有的票将会失效。包括票据授权票。那我就要重新向Charon作认证,在八小时以后。 
Euripides: 是不是不合理? 
Athena: 我想不是。好我们就定下来吧--票在八小时后失效。现在我有一个问题问你。假设我从网络上拷了 你的票--。 
Euripides: (眨了眨眼睛)啊,Tina!你不会真的这样做吧? 
Athena: 这只是为了讨论。我拷了你的票。现在我等你退出并离开。假设你有一个医生的约会或聚会要参加,你在两个小时后退出,并且你在退出之前销毁了你的票。 但我已经偷了你的票,它们还可以使用六小时。这给了我足够的时间用你的名义去取你的文件并打印一千份什么东西。 你看,时间戳工作的很好如果小偷选择在它失效以后来用的话。如果小偷能在它失效之前用…。 啊,好…当然,你是对的。 
Athena: 我想我们遇上了一个大问题了。
(她叹了口气) 停了一下。
Euripides: 我想这意味着你今晚要忙了。再来点咖啡? 
Athena: 为什么不。

第四幕 
第二天早上在Euripides的办公室。Athena来敲门。 
Euripides: 你今早有黑眼圈了。 
Athena: 好了,你知道的。又是一个漫漫长夜。 
Euripides: 你解决了重演的问题了吗? 
Athena: 我想是的。 
Euripides: 请坐。 她坐下了。 
Athena: 照旧,我重申一下问题。票是可重用的,在一个限定的时间内(八小时)。如果谁偷了你的票并在它失效之前使用,我们毫无办法。 
Euripides: 确实如此。 
Athena: 我们可以把这个问题理解为设计一种别人无法重用的票。 
Euripides: 但这样的话你每次用新服务时都要取一张新票。 
Athena: 对。但那是很笨的解决办法。
(稍顿)
Athena: 啊,我怎样继续我的讨论呢?
(她沉思了一会儿)
Athena: 好的,我要重述一个问题,看有什么必须条件。网络服务必须能够证明使用票的人就是票上所申明的人。 我来顺着认证的过程再走一遍,这样我就可以演示我的解决方案。 我现在想用一个网络服务。我通过启动工作站上的客户端来使用它。客户端送三样东西给服务器:我的名字,我的工作站的网络地址,适当的服务票据。 这张票包含了申请这张票的人的名字和他(她)申请时所使用的工作站的地址。它也包含了票的有效期和时间戳。所有这些信息都被服务的密码加密了。 我们现在的认证模式基于以下的测试: 服务能对票解密吗? 票在有效期以内吗? 票中的名字和地址与申请者的名字和地址匹配吗? 这些测试证明了什么? 第一个测试证明了票是不是来自Charon.如果票不能被适当的解密,说明票不是来自真正的Charon. 真正的Charon会用服务的票来加密票。Charon和服务是唯一知道服务密码的两个实体。如果票被成功的解密,服务知道它来自于真的Charon.这个测试防止了有人伪造假票。 第二项测试检查票是否在有效期以内。如果过期,服务拒绝。这项测试阻止使用旧票,因为票可能是偷来的。 第三项测试检查票的用户名和地址是否匹配请求者的用户名和地址。如果测试失败,说明使用者使用了别人的票。这张票当然被拒绝。 如果名字和地址匹配,这个测试证明了什么?什么也没有。票可以被偷走,用户名和网络地址都可以被改变,如果需要的话。正如我昨天指出的那样,票可以在有效期内被盗用。因为服务不能确定票的发送者是不是合法用户。 服务之所以无法判断是因为它没有与用户共享一个秘密。这样看。假如我正在埃尔斯诺尔(哈姆雷特中的城堡)值勤,你打算来和我换班。但除非你说出正确的口令,否则我不会与你换班的。我们共享了一个秘密。它可能是某人为所有值勤的人所设的。 于是昨晚我就在想,为什么Charon不能为合法用户与服务之间设一个口令呢?Charon发一份口令给服务,同时发一份给用户。当服务从用户那里收到一张票,它可以用这个口令检验用户的合法性。 
Euripides: 等一下。Charon如何同时发两份口令? 
Athena: 票据的拥用者从Charon的回应中得到口令,像这个样子: 她在黑板上写下了: Charon的回应-[口令|票] 服务从票中获取口令。票的格式如下: 票-{口令:用户名:地址:服务名:有效期:时间戳} 当你要请求服务时,客户端程序生成一个‘验证器’。验证器包含了你的名字和你工作站的地址。客户端用口令把这些信息加密,口令是你请求票据时得到的。  验证器-{用户名:地址}用口令加密。 生成验证器以后,客户端把它和票一起送给服务。因为服务没有口令,所以它不能解密验证器。口令在票中,于是服务先解开票。 解开票以后,服务得到以下的东西: 票的有效期和时间戳; 票的拥有者的名字; 票拥有者的网络地址。 口令。 服务检查票是否过期。如果一切正常,服务就用口令去解验证器。如果解密没有问题,服务将会得到一个用户名和网络地址。服务用它们去和票里的用户名和网络地址去匹配,如果正确,那么服务认为票的发送者确实是票的真实拥有者。 Athena暂停了一下,清了清喉咙,喝了点咖啡。 我认为口令验证器的机制解决了盗用的问题。 
Euripides: 也许。但我想。。。攻击这个系统我必须有验证器。 
Athena: 不。你必须同时拥有验证器和票。没有票,验证器是没有用的。解开验证器必须要有口令,服务必须解开票才会有口令。 
Euripides: 好,我明白了,你是说当客户程序联系服务时,它同时送上票和验证器? 
Athena: 是的,我就是这个意思。 
Euripides: 如是真是这样,什么可以阻止我把票和验证器都偷走呢?我可以写一个程序,如果我拥有了票和验证器,我就可以一直使用它至有效期结束。我只需改变我的用户名和工作站的地址。不是吗? 
Athena: (咬了咬她的嘴唇)是的。多沮丧啊。 
Euripides: 等等,等等,等等!这不难解决。票在有效期内是可重用的,但那并不意味着验证器是可重用的。假设我们设计了验证器只可以被用一次。这可以吗? 
Athena: 好,也许。我样来想一下,客户端程序生成验证器,然后把它和票一起送给服务。真的票和验证器比你拷贝的要先到。如果验证器只能被用一次,你的拷贝就失效了。 啊,这就对了。我样现在需要做的就是发明一和方法使得验证器只能被用一次。 
Euripides: 没问题。我们把有效期和时间戳放在上面。假设每个验证有两分钟的有效期。当你想用一个服务时客户端生成验证器,标上当前的时间,把它和票一起送给服务。 服务器收到了票和验证器,服务器解开验证器,它检查验证器的时间戳和有效期。如果验证器还没失效,所有其它的检查都通过了,那么服务器就认为你通过了认证。 假设我通过网络拷贝了一份验证器和票,我必须改变我的工作站的网络地址和我的用户名,这差不多要用几分钟。那是非常苛刻的要求,我不认为是可能的,除非。。。 嗯,有一个潜在的问题。假设不是在网络的转输中拷贝到票和验证器,我拷贝了一份原始的从Charon而来的包,这个包是你向Charon请求时的回应。 这个包,有两个口令在里面:一个是你的,一个是服务的。服务的口令隐藏在票中,我取不到,但另一个呢?那个你用来生成验证器的? 如果我得到了口令,我就用它来建自已的验证器,如果我能建自已的验证器,我就能攻破你的系统。 
Athena: 这就是我昨晚所想的,但是当我顺着票的处理过程一想,发现那样偷走验证器是不可能的。 你在一台工作站坐下,用kinit程序得到你的票据授权票。kinit要求输入用户名,你输入以后,kinit把它送给Charon.Charon用你的名字查找你的口令,然后生成一张票据授权票。作为处理的一部分,Charon生成了一个你与票据授权服务共享的口令。Charon把口令和票据授权票一起送给你,并且在发关之前用你的口令将它加密。 Charon送出了包。某人取得了这个包,但他们无能为力因为它是用你的口令加过密的。特别是,无人可以偷走票据授权服务的口令。 kinit收到了票据包并要求你输入你的口令。如果你输入正确的口令,kinit解开包取出了口令。 现在你注意kinit的处理,你去取你的邮件。你打开邮件客户端。这个程序查找一张邮件服务的票但没有找到(你还没取过你的邮件)。客户端用票据授权票去申请一张邮件服务的票。 客户端为票据授权的过程生成了一个验证器,并用票据授权的口令把验证器加密。客户端把验证器送给了Charon,票据授权票,你的名字,你的工作站的地址,邮件服务的名字。票据授权服务收到了这些东西,并通过了认证检查。如果一切都通过,票据授权服务将会得到那个与你共享的口令。现在票据授权服务为你生成了一张邮件服务的票,在这个过程中生成了一个你与邮件服务共享的口令。票据授权服务把这些东西打成包送给你的工作站。包里有票和口令。在送包之前,票据授权服务用票据授权的口令把包加密。做完以后,包被送出去。 这样邮件服务票的包通过网络被送了出来。假设网络上的某人将它复制了一份。他不幸的发现包是用票据认证的口令加过密的。既然无法解密,他就不能得到邮件口令。没有口令,他就不能使用任何在网络上传送的邮件服务的票。 现在我觉得我们是安全的。你认为呢? 
Euripides: 也许吧。 
Athena: 也许!你就只会说这个吗! 
Euripides: (大笑)别在意。你现在应该知道我处理问题的方式了。我猜我和你昨晚都工作到了半夜。 
Athena: 哼! 
Euripides: 好的,大半夜。实际上,这个系统似乎是完全可行的。口令的方案解决了我昨晚想到的一个问题:相互验证的问题。 稍顿。 我说一下好吗? 
Athena: (有点冷淡)请便。 
Euripides: 你真好。
(Euripides清了清自已的嗓子)
Euripides: 昨晚,当口令和验证器在我脑子里转的时候,我想去找出这个系统新的问题,我想我发现了一个很严重的问题。我下面就演示一下。 假设你厌倦了现在的工作,决定换一个。你想用公司的激光打印机打印求职信,把它们送给猎头和其它的雇主。于是你输入打印命令,命令去取得服务票,然后把票送到打印机。这是你认为它应该被送到的地方。实际上你并不知道你的请求被送到了正确的打印服务器。 假设一些无耻的人--比如说你的老板--调整了系统,把你的请求送到了他办公室的打印机。他的打印服务不关心票的内容。它告诉你的工作站服务已准备好打印你的文件。打印命令被送到了假的打印服务器,你有麻烦了。 我从相反的方向表达了相同的问题。用口令和验证器,Charon能够保护的它的服务器防止错误的用户使用,但它不能保护它的用户使用错误的服务器。系统需要为客户端程序提供一种验证服务器的方法,在它向服务器发送敏感信息之前。系统必须允许交互验证。 但口令的方案解决了这个问题。让我们回到打印服务器的场景。我想要打印客户程序确认它送交的服务是合法的服务。 这就是程序要做的。我输入打印命令并给出一个文件名。这时我已经有了打印服务票和口令。客户程序用密码生成了一个验证器,然后把验证器和票送给了假设的打印服务器。客户端这时还没有送打印文件,它在等待从服务的返回。 真的服务收到票和验证器,把票解密并得到口令,然后用口令解开验证器。这样服务端做完了所有的认证。 测试已经确认了我的身份。现在服务程序要准备一个响应包来证实它自已的身份。它用口令加密了返回包,并把包送给了等待的客户端。 客户端收到了包并试图用口令把它解开。如果包被正确的解开得到了正确的服务器响应信息,客户端程序就知道了这个服务器是合法的服务器。然后这时客户端向它发出打印命令。 假设我的老板改变了一下系统使得他的打印机看起来好像是我想要用的那个。我的客户端送了票和验证器给它并等待它的响应。假冒的打印服务无法生成正确的响应因为它无法把票解开并得到口令。这样的话客户端就不会送打印命令给它因为客户端没有得到正确的响应。最后客户端放弃等待并退出。我的打印没有完成,但至少我的求职信不会放在我的对头的桌子上。好啊,我想我们有了Charon认证系统的坚实的基础。 
Athena: 也许。不管怎么说,我不喜欢Charon这个名字。 
Euripides: 你不喜欢吗?什么时候? 
Athena: 我从来都不喜欢,因为它的名字听起来没意义。有一天我和我荷迪斯(冥王)叔叔谈到了这个,他推荐了另一个名字:冥王的三个头的看门狗。 
Euripides: 啊,你是说“Cerberus”. 
Athena: 你说什么语言啊!”Cerberus”实际上是。。。 
Euripides: 哦,不叫这个吗? 
Athena: 当然,谁让你是罗马人!而我是希腊人,它是一条希腊的看门狗,它的名字是 ” Kerberos“,”Kerberos“是‘K’打头的。 
Euripides: 好吧,好吧,别发火。我同意这个名字。实际上,它有一个好的脖环。再见吧,Charon,欢迎你,Kerberos.

发布了5 篇原创文章 · 获赞 0 · 访问量 1万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览