关于Kerberos协议的一篇Dialog

2008－01－11，广州

＝＝＝＝＝＝＝＝＝＝

 

设计一个认证系统：一部四幕剧（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.

由wanxiangqian@163.com翻译成中文，2008年1月11日。

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.设计工作完成后，雅典娜将系统的名字改为“Kerberos”——麻省理工（MIT）的雅典娜项目中所设计和实现的认证系统的名字。剧中人所设计的“Kerberos”系统，与Kerberos: An Authentication Service for Open Network Systems一文（发表在1988年在德克萨斯达拉斯所召开的USENIX冬季会议上）所描述的系统惊人地相似。 

 

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.那个人的文件呢——分时系统上，我可以用任何一台终端，只需用自己的帐号登录就可以取用自己的个人文件。我可以登录任何一台工作站，自动取用自己的个人文件吗？是不是得象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. 第二天上午，欧利比的司的办公室。欧利比的司坐在办工作前读他的邮件。雅典娜敲门。
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 CLIENTof 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.这个办法确实笨拙。在那样一个系统中，每台服务器都得知道你的口令。如果全网络有1000个用户，那么每台服务器都得记住1000个口令。每当你修改口令，得通知所有的服务器。我相信，你所设想的系统没这么笨。
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 our secret password. Charon takes your password and compares t 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），将你的用户名用邮件服务器的口令加密后放在凭证中。
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 . . .现在假设你向叉龙请求一张邮件服务访问凭证。叉龙做好凭证，把你的大名”Tina”写在里面，然后通过网络传到你手里。这时，我在网络上截获并拷贝一份。然后，我骗我的工作站说
我的名字是“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.但是我有一个办法可以解决这个问题，至少是部分解决这个问题。叉龙可以在凭证中包含更多的信息。除了用户名，还应该包含用户向叉龙请求认证时所用的网络地址。这样，就多了一层安全性。
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.现在的认证系统工作原理如下：用户使用一个叫kinit的程序登录到工作站，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 icket, I make it sound as though you have to send your password n cleartext over the network to the Charon Server. But it oesn't have to be that way.我已经解决了这个问题。想叉龙申请“凭证－授权”凭证时，并不需要把口令以明文形式通过网络传给叉龙服务器。
Here's really what happens. When you use the kinit program o get the ticket-granting ticket, kinit doesn't send your assword to the Charon server, kinit sends only your username.使用kinit程序获取“凭证－授权”凭证时，kinit并不把你的口令传递给叉龙，kinit只把你的用户名传过去。
Euripides: Fine.然后呢？
Athena: Charon uses the username to look up your password. Next Charon uilds a packet of data that contains the ticket-granting icket. Before it sends you the packet, Charon uses your assword to encrypt the packet's contents.叉龙根据用户名取得你的口令，然后以“凭证－授权”凭证为内容建一个数据包。在把这个数据包传递给你之前，叉龙要用你的口令把数据包的内容加密。
Your workstation receives the ticket packet. You enter your assword. Kinit attempts to decrypt the ticket with the
password you entered. If kinit succeeds, you have successfully uthenticated yourself to Charon. You now possess a icket-granting ticket, and that ticket can get you the other ickets you require.你的工作站接收这个数据包之后，提示你输入口令。Kinit试着用你提供的口令解密数据包。解密成功，则取得叉龙颁发的“凭证－授权”凭证；否则请你重新开始。
How's that for some fancy thinking?
Euripides: I don't know . . . I'm trying to think myself. You know, I hink the parts of the system that you just described work retty well. Your system requires me to authenticate myself nly once. Thereafter Charon can issue me service tickets ithout my being aware of it. Seamless, seamless in that egard. But there's something about the design of the service icket that troubles me somehow. It has to do with the fact hat 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 ecurity 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.也就是说，如果我在工作站上连续工作超过8个小时，所有凭证都会作废，包括我的“凭证－授权”凭证？我得再次向叉龙证实自己的身份？
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—也只能如此了。先就这么定了——所有凭证8小时后作废。现在我要问你一个问题了。假设我在网络上拷贝了你的一份凭证……
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.就假设如此吧。我拷贝了你的凭证。等你注销登录的时机，假设你约了医生或要去上一堂课，总之你不到2个小时就注销登录了。
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.你打开工
作站，用kinit程序去获取“凭证－授权”凭证。Kinit提示你输入用户名，把
它发给叉龙。
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.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.为了
成功完成这笔凭证－授权交易，邮件客户程序首先要建立一个认证器，并用你所获
得的凭证－授权会话密钥加密这个认证器。然后将（加密的认证器、凭证－授权凭
证、用户名、地址、邮件服务名）发给叉龙。
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.于是输入打印命
令，指示它将简历发到A打印服务器。首先取得访问凭证，以你的名义发送到A打
印服务器。你认以为发到了A打印服务器上，其实未必。
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."哦，你说的是“塞尔波罗斯”（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.对的，如果你是罗马人的话！我是希腊神，他是希腊的看门狗，他的名字叫做“卡
尔波罗斯”（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.好，好，别来闪电霹雳。我接受这个名字。再见叉龙，你好，卡尔波罗
斯。

 

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”
协议相比，第5版只改动了两个地方。
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.第一处改动，源自5分钟的时间不足以抵挡
用程序来执行的自动攻击（截包－重放）。
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协议，接收访问凭证的服务器接必须建立一个“回放缓冲区”，记录最近接收到
的所有认证器，保存5分钟以上。这样，即使攻击者在时间窗口里发动了攻击，也因为缓冲区
中已有记录而被拒绝。于是，认证器做到了真正的“一次性使用”。
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
服务器给用户的回应包的其它成分，包括凭证会话密钥在内，还是要用用户的口令来加密的。）
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: 对凭证许可服务（TGS）也做了
类似的改动。TGS发回来的凭证也不再用“凭证－许可”凭证的服务密钥来加密了，因为应用
程序凭证已经用应用服务器的密钥加密了。所以，举例来说，Kerberos V4的包是这样子的：
KDC_REPLY = {TICKET, client, server, K_session}K_user
where "{X}K_Y" is read "X encrypted using key K_Y" and 其中“{X}K_Y”就
是“用密钥K_Y来加密X取密文”的意思。
TICKET = {client, server, start_time, lifetime, K_session}K_server
In Kerberos V5, the KDC_REPLY now would look like this: 在Kereros V5
中，KDC_REPLY包变成这个样子了：
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.当然，Kerberos V5还添加
了很多新特征。现在，用户可以安全地传递他们的凭证，从而能被用于另一个网络地址；还有，
用户还可以将他们的一部分认证权委托给某个服务器，让那个服务器担当某种代理的角色。其它
的新特征包括允许用更强的密码算法取代DES，比如triple-DES算法。对Kerberos V4和
V5的区别感兴趣的用户，不妨读读Cliff Neumann和Theodore Ts’o写的“Kerberos
认证系统的演变”一文。
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.
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