Kerberos协议的介绍

因为要研究单点登录(Single Sign-On SSO)的原理，Kerberos是必然会涉及的一项技术。在研究这个问题时，发现网上一致推荐麻省理工学院的一篇文章，这是用四幕话剧形式来解释Kerberos的一篇有趣轻松的文章。我尝试着把中英文对照都放在这里，我个人倾向于直接看 英文 。

Designing an Authentication System:
a Dialogue in Four Scenes

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和Euripides正在相邻的终端上工作。

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. 好的。个人的文件怎么办呢?在分时操作系统上，我可以从任意一台终端登录并存取我的文件。我能到任意一台工作站上取我的文件吗?或者，我要象PC用户一样把我的文件放到磁盘上去吗?我希望不。
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.

Euripides的办公室，第二天早上。Euripides坐在桌子边，看他的邮件。Athena来敲门。

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. 你瞎编，是不是想重写希腊神话。Charon不关心你的身份，他只想确定你死了。
Euripides:	Have you got a better name? 你有更好的名字吗？
	Pause. 停了一下。
Athena:	No, not really. 没有，真的没有。
Euripides:	Then let's call the authentication service "Charon." 好，那我们就管这个认证服务叫“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告诉这个服务你确实是你所声称的人。也就是说你必须得到Charon的认证才能使用服务。当你向Charon请求认证的时候，你必须告诉Charon你要用的服务。如果你想用邮件服务，你必须告诉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要求你证明你的身份。于是你提供你的密码。Charon拿你的密码和它数据库中登记的你的密码相比较。如果这两个密码匹配，Charon就认为你通过了验证。 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. 现在，Charon就必须要让邮件服务确信你是你所说的那个人。既然Charon知道所有服务的密码，它也知道邮件服务的密码。可以想到，Charon把邮件服务的密码给你，你就可以向邮件服务转发这个密码，证明你已通过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. 问题是，Charon不能直接给你密码，因为那样你会知道它。下次你想收邮件的时候，你就可以绕过Charon使用邮件服务而不需要认证。你甚至可以假装别人来使用邮件服务。 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. 所以不是直接给你邮件服务的密码，Charon给你一张邮件服务的“票”。这张票包含你的用户名，并且用户名是用邮件服务的密码加密的。 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. 服务用它自已的密码把票解密，如果票能被正确解密，服务器将Charon放在票里的用户名取出。 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 . . . 假设你向Charon请求一张邮件服务的票。Charon准备了一张票，里面有你的用户名“tina”。假设在票通过网络从Charon传给你的过程中我拷了一份。假设我让我的工作站相信我的用户名是“tina”。我工作站上的邮件客户端程序认为我就是你。用你的名字，邮件客户程序把偷来的票传给邮件服务器。邮件服务器把票解密，认为它是有效的。票里的用户名和发送该票的用户名是匹配的。邮件服务器就会把你的邮件给我。
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. 但是我想到了一个办法来解决这个问题。或者说部分解决。我想Charon应该在票中包含更多的信息。除了用户名，票还应包含请求票的用户的网络地址。这将给你增加一层安全性。 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! 现在我真的很激动。让我们来建一个Charon系统看看它是否工作!
Euripides:	Not so fast. I have some other questions about your system. 没那么快。对于你的系统我还有些问题。
Athena:	All right. (Athena leans forward in her chair) Shoot. 好吧。(Athena在她的椅子上向前探了探了身子)快说。
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. 好一些。但我仍有问题。你似乎暗示我每次使用还没有票的服务时，我都必须给Charon我的密码我登录后想取我的文件。我向Charon请求我的票，这意味着我不得不使用我的密码。然后我想读我的邮件。又向Charon发一次请求，我又要输一次我的密码。现在假设我想把我的邮件送去打印。我又要向Charon发一次请求。你知道了吧?
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. 并且如果这还不够糟的话，想想看：它好像是这样，当每次你要向Charon认证的时候，你就要用明文在网络上传输你的口令。像你这样的聪明人可以监视网络并且得到别人的口令。如果我得到你的口令，我就可以用你的名字来使用任何服务。Athena叹了口气。
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.

第二天早上，Athena在咖啡间撞见了Euripides。在Euripides倒咖啡的时候，Athena拍了拍他的肩。

Athena:	I've got a new version of Charon that solves our problems. 我有了一个新的Charon版本来解决我们的问题。
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清了清嗓子。
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. 我从第一项要求开始：你只需输入你的口令一次。我创造了一个新的网络服务来满足这个要求。它叫做“票据授予”服务，用户向Charon证明身份后，这个服务把Charon的票给用户。如果你有票据授予服务的票就可以使用这个服务，一张票据授予票。 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. 票据授予服务其实只是Charon的一个版本，因为它可以访问Charon的数据库。它是Charon的一部分，可以让你通过票而不是口令来进行认证。 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. 总之，认证系统现在是如下这样工作的：你登录到一个工作站，用一个叫kinit的程序与Charon 服务器通讯。你向Charon证明你的身份，kinit程序取得一张票据授予票。 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. 如我所说，我也解决了那个问题。事情是这样的，当我说你要和Charon联系取得票据授予票的时候，听上去我好像在说你需要在网络上用明文传输密码。但其实不是这样的。 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. 实际发生的是，当你用kinit程序去取票据授予票的时候，kinit没有把你的口令发送给Charon服务器，kinit只发送你的用户名。
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. Charon用用户名去查你的口令。然后Charon就会组一个包含票据授予票的包。在把包发给你之前，Charon用你的口令加密这个包。 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. 你的工作站收到了包。你输入你的口令。kinit尝试用你输入的口令解密这个包。如果成功了，你就向Charon成功的进行了认证。你现在拥有了票据授予票，你可以用这张票来取得其它的票。  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. 我不知道……我自己正在想。我想你刚才描述的系统一部分工作得很好。你的系统只要求我认证一次。以后，不要我操心，Charon就会发给我服务的票。天衣无缝，这方面确实天衣无缝。但服务票的设计还是有一些困扰我。票是可重用的。我同意它们应该能被重用，但重用的票，由于它们自身的性质，是非常危险的。
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: 非常正确。我想每张票需要增加两项信息:生存期表示票多长时间内是有效的，和一个时间戳来说明Charon是什么时候发出这张票的。那么一张票看起来是这样的：
	Euripides goes to the chalkboard and scrawls the following: Euripides走到了黑板前写下了如下的内容： 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. 那如果我在工作站呆的时间超过八小时，我所有的票将会过期。包括票据授予票。那我八小时后就要重新向Charon作认证。
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? (眨了眨眼睛)啊，Tina！你不会真的这样做吧?
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的办公室。Athena来敲门。

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. 这些测试证明了什么?第一个测试证明了票是否来自Charon。如果票不能被解密，说明票不是来自真正的Charon。真正的Charon会用服务的密码来加密票。Charon和服务是唯一知道服务密码的两个实体。如果票被成功的解密，服务就知道它来自于真的Charon。这个测试防止有人伪造假票。 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. 于是昨晚我就在想，为什么不让Charon为合法用户与服务之间设一个口令呢?Charon给服务一个会话密钥，同时发一份给用户。当服务从用户那里收到一张票，它可以用会话密钥验证用户的身份。
Euripides:	Wait a second. How is Charon going to give both parties the session key? 等一下。Charon如何给双方发会话密钥？
Athena:	The ticket-owner gets the session key as part of the reply from Charon. Like this: 票据的拥有者从Charon的回应中得到会话密钥，像这个样子： She scrawls the following on a chalkboard: 她在黑板上写下了： CHARON REPLY - [sessionkey|ticket] Charon的回应-[会话密钥|票] 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. Athena暂停了一下，清了清喉咙，喝了点咖啡。 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. 嗯，有一个潜在的问题。假设不是在票和验证器从你的工作站向服务器传输的过程中拷贝了它们，我拷贝了一份从Charon而来的原始票据包，这个包是你向Charon请求票据时的回应。 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. 你在一台工作站坐下，用kinit程序得到你的票据授予票。kinit要求输入用户名，你输入以后，kinit把名字发送给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用你的名字查找你的口令，然后生成一张票据授予票。作为处理的一部分，Charon生成了一个你与票据授予服务共享的会话密钥。Charon在票据授予票里放了一份会话密钥，把你的那份密钥放在发给你的票据包里。但在把包发给你之前，Charon用你的口令将整个包加密。 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. Charon通过网络送出了包。某人取得了这个包，但他们无能为力，因为它是用你的口令加过密的。特别是，无人可以偷走用于票据授予的会话密钥。 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. kinit收到了票据包，提示你输入口令。如果你输入正确的口令，kinit就能解开包取出会话密钥。 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. 现在你注意到了kinit的处理，你想去取你的邮件。你打开邮件客户端。这个程序查找一张邮件服务的票，但没有找到(毕竟，你还没取过你的邮件)。客户端用票据授予票去向票据授予服务申请一张邮件服务的票。 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. 客户端为票据授予事务生成了一个验证器，并用你的那份用于票据授予的会话密钥给验证器加密。客户端然后把验证器，票据授予票，你的名字，你的工作站的地址，以及邮件服务的名字发送给Charon。 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. 你真好。(Euripides清了清自已的嗓子)昨晚，当会话密钥和验证器在我脑子里转的时候，我尝试着找出这个系统新的问题，我发现了一个我认为很严重的问题。我下面就演示一下。 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. 我从相反的方向表达了相同的问题。没有会话密钥和验证器，Charon能够保护它的服务器不被错误的用户使用，但它不能防止它的用户使用错误的服务器。在客户端程序向服务发送敏感信息之前，系统需要为客户端程序提供一种验证服务器的方法，。系统必须允许交互验证。 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. 好啊，我想我们有了Charon认证系统的坚实的基础。
Athena:	Perhaps. Anyway, I don't like the name "Charon." 也许。不管怎么说，我不喜欢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." 哦，你是说“Cerberus”。
Athena:	Bite your tongue Rip! "Cerberus" indeed . . .闭嘴！实际上念“Kerberus”……
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. 当然，谁让你是罗马人！而我是希腊女神，它是一条希腊的看门狗，它的名字是“Kerberos”，“Kerberos”是‘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. 好吧，好吧，别发火。我接受这个名字。实际上，它有一个好的脖环。再见吧，Charon，欢迎你，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.

这篇对话写于1988年，是为了帮助读者理解Kerberos V4的运行方式。经过这么多年，它工作的非常好。

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.

当我把这篇文章转换成HTML的时候，我惊讶的发现这篇文档对Kerberos V5仍然非常有用。虽然很多东西改变了，但基本的核心概念并没有变。实际上，Kerberos V5对这篇对话里描述的Kerberos只做了两处改动。

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.

在Kerberos V5中，验证器真正的只能用一次因为服务器用‘重演缓冲区’保存了最近一次提交的验证器的信息。如果攻击者试图截取验证器并重用它，‘重演缓冲区’会发现验证器已经被提交了。

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.)

第二个主要改变是Kerberos送给kinit服务票的时候，票不再是用用户的口令加密。它已经用票据授予服务的口令加过密了。票据授予服务的票被用来获取其它票的时候，它直接就被传输了。因此票不需要再用用户的口令加密一次。(服务器响应的其它部分，如口令，仍然是用用户的口令加密的。)

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

 一个类似的改变也应用到票据授权服务协议;从票据授权服务返回的票也不再用票据授权服务的口令来加密了，因为它所包含的票已经被对应的服务的口令加过密了。举例来说，Kerberos V4的包像这样:

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

　　意思是:{｝中的内容是用K_user来加密的。

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

　　在Kerberos V5中，KDC_REPLY现在看起来像这样:

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

　　(注意:票已经不再用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.

当然，Kerberos V5中还有许多新特性。用户可以在另一个网络中安全的提交他们的票;并且，用户可以把他们的一部分认证权转给服务器，这样服务器就可以作为用户的代理。其它的新特性包括:用更好的加密算法替换了DES加密算法，如三重DES加密。读者如果对V4与V5的变化感兴趣的话，可以读一下“The Evolution of the Kerberos Authentication System”，作者是Cliff Neumann和Theodore Ts'o。

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

我希望你能对这篇介绍Kerberos协议的文章感兴趣。我祝愿你在未来的探索中更进一步。

Theodore Ts'o, February 1997