不知道哪位仁兄翻譯的,全世界無產階級感謝他! 本次轉載修改了一些文字上的小錯誤 :-)
這是MIT爲幫助人們理解Kerberos的原理而寫的一篇對話。通過Athena不斷的構思和Euripides不斷的尋找其中的漏洞，使大家明白了Kerberos協議的原理。
這是MIT(Massachusetts Institute of Technology)爲了幫助人們理解Kerberos的原理而寫的一篇對話集。裏面有兩個虛構的人物:Athena和Euripides，通過Athena不斷的構思和Euripides不斷的尋找其中的漏洞，使大家明白了Kerberos協議的原理。
Athena: 雅典娜，智慧與技藝的女神。
Euripides:歐里庇得斯, 希臘的悲劇詩人。
譯文如下:
第一幕
在一個小工作間裏。Athena和Euripides正在相鄰的終端上工作。
Athena: 嗨，這個分時操作系統實在太慢了。我根本無法工作，因爲每個人都登上去了。
Euripides: 不要對我報怨。我只是在這工作。
Athena: 你知道我們需要什麼嗎?我們需要給每一個人一臺工作，這樣大家就不會擔心計算機的速度了。並且，我們需要一個網絡把所有的計算機都聯起來。
Euripides: 好。那麼我們差不多要一千臺工作站?
Athena: 差不多吧。
Euripides: 你知道一臺普通的工作站的硬盤有多大嗎?那裏放不下所有的軟件。
Athena: 我已經有主意了。我們可以把系統軟件放到服務器上。當你登錄到工作站的時候，工作站會通過網絡與其中一臺服務器上的系統軟件聯繫。這樣的設置讓一組工作站都使用同一份系統軟件，並且利於系統軟件的升級。只需改動服務器就可以了。
Euripides: 好的。個人的文件怎到辦呢?在分時操作系統上，我可以登錄並從終端上取走我的文件。我能到工作站上取我的文件嗎?我要象PC用戶一樣把我的文件放到磁盤上去嗎?我希望不。
Athena: 我想我們可以其它機器來存文件。你可以到任何一臺機器上登錄去取你的文件。
Euripides: 打印怎麼辦呢?每個工作站都要有自已的打印機嗎?誰來付錢?電子郵件呢?你怎麼把郵件送到所有的工作站上去呢?
Athena: 啊.....很明顯我們沒錢爲每個人配一臺打印機，但我們有專門的機器做打印服務。你把請求送到服務器，它就爲你打印。郵件也可以這樣做。專門有一臺郵件服務器。你如果想要你的郵件，就聯繫郵件服務器，取走你的郵件。
Euripides: 你的工作站系統聽起來很不錯。如果我有一臺，你知道我要做什麼嗎?我要找出你的用戶名，讓我的工作站認爲我就是你。然後我就去郵件服務器取走你的郵件。我會聯上你的文件服務器，移走你的文件，然後--
Athena: 你能做得到嗎?
Euripides: 當然!這些網絡服務器怎麼會知道我不是你?
Athena: 嗯，我不知道.我想我需要認真思考一下.
Euripides: 好吧。你想出來後告訴我.
第二幕
Euripides的辦公室，第二天早上。Euripides坐在他的桌子旁邊，讀着他的郵件。Athena來敲門.
Athena: 我已經想出怎樣保護一個開放的網絡系統，使象你那樣不道德的人不能用別人的名字使用網絡服務。
Euripides: 真的嗎?坐吧。
她坐下了。
Athena: 在我開始描述之前，我可以爲我們的討論先做一個約定嗎?
Euripides: 什麼約定?
Athena: 好，假設我這樣說:"我想要我的郵件，於是我與郵件服務器聯繫，請求它把郵件送到我的工作站上來。"實際上我並沒有聯繫服務器。我用一個程序來與服務器聯繫並取得我的郵件，這個程序就是這個服務的客戶端。 但我不想每次與服務器交互的時侯說:"客戶端怎樣怎樣".我只想說:"我怎樣怎樣,"記住，客戶端在代表我做所有的事。這樣可以嗎?
Euripides: 當然。沒問題.
Athena: 好。那麼我要開始闡述我所解決的問題了。在一個開放的網絡環境中，提供服務的機器必須能夠識別請求服務的實體的身份。如果我去郵件服務器申請我的郵件，服務程序必須能夠驗證我就是我所申明的那個人。
Euripides: 沒錯.
Athena: 你可以用一個笨辦法解決這個問題:服務器讓你輸入你的口令。通過輸口令的辦法我可以證明我是誰。
Euripides: 那確實很笨拙。在像那樣的系統裏面，每一個服務器必須知道你的口令。如果網絡有一千個用戶,那每個服務器就要知道一千個口令。如果你想改變口令，你就必須聯繫所有服務器，通知它們修改口令。我想你的系統不會那麼笨。
Athena: 我的系統沒那麼笨。它是象這樣工作的:不光人有口令，服務也有口令。每個用戶知道他們自已的口令，每個服務也知道它自已的口令。有一個認證服務知道所有的口令，用戶的和服務的。認證服務把口令保存在一個單獨的中央數據庫中。
Euripides: 這個認證服務有一個名字嗎?
Athena: 我還沒想好。你想一個吧?
Euripides: 把死人送過冥河的人是誰?
Athena: Charon?
Euripides: 對，就是他。如果他不能證實你的身份的話，他就不會把你送過河。
Athena: 你瞎編，是不是想重寫希臘神話。Charon不關心你的身份，他只是確定你死了
沒有。
Euripides: 你有更好的名字嗎?
停了一下。
Athena: 沒有，真的沒有。
Euripides: 好，那我們就把這個認證服務“Charon”。
Athena: 好，我猜我該描述一下這個系統了吧，嗯?
比如說我們想要一種服務:郵件。在我的系統裏面你無法使用一種服務，除非Charon告訴服務你確實是你所申明的人。也就是說你必須得到Charon的認證才能使用服務。當你向Charon請求認證的時候，你必須告訴Charon你要使用哪一個服務。如果你想用郵件，你要告訴Charon。 Charon請你證明你的身份。於是你送給它你的密碼。Charon把你的密碼和它數據庫中的密碼相比較。如果相等，Charon就認爲你通過了驗證。 Charon現在就要讓郵件服務知道你通過了驗證。既然Charon知道所有服務的密碼，它也知道郵件服務的密碼。Charon把郵件服務的密碼給你，你就可以使用這個密碼使郵件服務相信你已通過驗證。 問題是，Charon不能直接給你密碼，因爲你會知道它。下次你想要郵件服務的時候，你就會繞過Charon使用郵件服務而不需要認證。你也可以假裝某人來使用郵件服務。 所以不是直接給你郵件服務的密碼，Charon給你一張郵件服務的“票”。這張票含有你的名字，並且名字是用郵件服務的密碼加密的。 拿到票，你就可以向郵件服務請求你的郵件。你向郵件服務提出請求，並用你的票來證明你的身份。 服務用它自已的密碼來把票解密，如果票能被正確的解密，服務器將票裏的用戶名取出。服務把這個名字和隨票一起送上的用戶名進行比較。如果相符，服務器就認爲你通過了驗證，就把你的郵件發給你。
你認爲怎麼樣?
Euripides: 我有些問題。
Athena: 我猜到了。請講。
Euripides: 當服務解密一張票的時候，它如何知道它是被正確的解密的?
Athena: 我不知道。
Euripides: 也許你應該在票裏包含有服務的名字。這樣當服務解密票的時候，它就可以通過能否在票中找到自已的名字來判斷解密是否正確。
Athena: 很好。那票就應該是這個樣子:
(她把下面的東西寫在了一張紙上)
票-{用戶名:服務名}
Euripides: 那票就只包含用戶名和服務名?
Athena: 用服務的口令加密。
Euripides: 我不認爲這些信息就可以讓票安全。
Athena: 什麼意思?
Euripides: 假設你向Charon請求一張郵件服務的票。Charon準備了一張有你名字“tina”的票。假設在當票從Charon傳給你的過程中我拷了一份。假設我讓我的工作站相信我的用戶名是”tina“。郵件客戶程序認爲我就是你。用你的名字郵件客戶程序用偷來的票向郵件服務器提出請求。郵件服務器把票解密，認爲它是合法的。票裏的用戶名和發送該票的用戶名是匹配的。郵件服務器就會發給 我你的郵件。
Athena: 喔!那可不太好。
Euripides: 但是我想到了一個辦法來解決這個問題。或者說部分解決。我想Charon應該在票中包含更多的信息。除了用戶名，票還應包含請求票的用戶的IP地址。這將給你增加一層安全性。 我來演示。假設現在我偷了你的票。這票有你工作站的IP地址，並且這地址配不上我的工作站的地址。用你的名字我把偷來的票送給郵件服務器。服務程序把用戶名和網絡地址從票中解出，並試圖匹配用戶名和網絡地址。用戶名匹配可網絡地址不匹配。服務器拒絕了這張票，因爲它明顯是偷來的。
Athena: 英雄，英雄!我怎麼會沒想到。
Euripides: 好了，這就是我要表述的。
Athena: 那麼票應該是這個樣子的。
她把下面的東西寫在了黑板上。
票-{用戶名:地址:服務名}
Athena: 現在我真的很激動。讓我們來建一個Charon系統看看它是否工作!
Euripides: 沒那麼快。對於你的系統我還有些問題。
Athena: 好吧。(Athena從她的椅子上探出了身子)快說。
Euripides: 聽起來好像每次我想要得到服務我都要去取一張新票。如果我整天的工作，我可能不只一次的要取我的郵件。我每次取郵件都要去取一張新票嗎?如果真是這樣，我不喜歡你的系統。
Athena: 啊。。。我不明白爲什麼票不能被重用。如果我已經得到了一張郵件服務的票，我可以一次又一次使用它。當郵件客戶程序用你的名字請求了服務，它就傳了一份票的拷貝給服務。
Euripides: 好一些。但我仍有問題。你似乎暗示我每次使用還沒有票的服務時，我都必須給Charon我的密碼我登錄後想取我的文件。我向Charon請求我的票，這意味着我不得不使用我的密碼。然後我想讀我的郵件。又向Charon發一次請求，我又要輸一次我的密碼。現在假設我想把我的郵件送去打印。我又要向Charon發一次請求。你知道了吧?
Athena: 啊，是的，我明白了。
Euripides: 並且如果這還不夠糟的話，想想看:它好像是這樣，當每次你要向Charon認證的時候，你就要用明文在網絡上傳輸你的口令。像你這樣的聰明人可以監視網絡並且得到別人的口令。如果我得到你的口令，我就可以用你的名字來使用任何服務。
Athena嘆了口氣。
Athena: 確實有嚴重的問題。我想我該回設計室去了。
第三幕
第二天一早，Athena在咖啡間遇上了Euripides。在Euripides倒咖啡的時候，Athena拍了拍Euripides.
Athena: 我有了一個新的Charon的版本來解決我們的問題。
Euripides: 真的嗎?好快呀。
Athena: 好，你看，這些問題困擾了我一夜。
Euripides: 一定是你良心發現了。我們去那邊的小會議室吧?
Athena: 好的。
兩人去了小會議室。
Athena: 我要重新描述問題，但我要根據我們的需要進行適當的轉換。
Athena清了清嗓子。
Athena: 第一個限制:用戶只輸一次口令，在他們工作站啓動的時候，這意味着當你需要申請新的服務的票時，不需輸入你的口令。第二個限制:口令不能在網絡上進行明文傳輸。
Euripides: 好的。
Athena: 我以第一項限制開始:你只需要輸入你的口令一次。我創造了一個新的網絡服務來解決這個問題。 它叫做“票據授權”服務，這個服務把Charon的票給用戶。使用它必須要有票:票據授權的票。 票據授權服務其實只是Charon的一個版本，它可以存取Charon的數據庫。它是Charon的一部分，可以讓你通過票而不是口令來進行認證。 總之，認證系統現在是象這樣工作的:你登錄到一個工作站，用一個叫kinit的程序與Charon 服務器通訊。你向Charon證明你的身份，kinit程序取得一張票據授權票。 現在你想從郵件服務器上取你的郵件。你還沒有郵件服務器的票，所以你用“票據授權”票去取郵件服務的票。你不需要使用口令去取新的服務票。
Euripides: 每次我想要另一種網絡服務的時候，我都要去取一張“票據授權”票嗎?
Athena: 不。記住，上次我們已經同意票是能被重用的。一旦你要用到票據授權票，直接用就可以了。
Euripides: 好，有道理。既然你能重用票，一旦你得到了某個服務的票，你就無需再去取了。
Athena: 對啊，那不好嗎?
Euripides: 好的，我沒話說，只要你在取得票據授權票的時候沒有用明文在網上傳輸你的口令。
Athena: 如我所說，我已解決了這個問題。聽起來好像是，當我說我要和Charon聯繫取得票據授權票的時候，你就要在網絡上傳輸明文密碼。但其實不是這樣的。 實際上是，當你用kinit程序取得票據授權票的時候，kinit沒有把你的口令送給Charon服務器，kinit只送你的用戶名。
Euripides: 很好。
Athena: Charon用用戶名去查找你的口令。然後Charon就會組一個包含票據授權票的包。在送給你之前，Charon用你的口令去把這個包加密。 你的工作站收到了包。你輸入你的口令。kinit用你的口令對這個包進行解密。如果成功你就向Charon成功的進行了認證。你現在有了票據授權票，你可以用這張票來取得其它的票。
這些奇思妙想怎麼樣?
Euripides: 我不知道...我正在思考。你知道你的系統一部分工作得很好。你的系統只需要我認證一次。以後，Charon會給我服務的票而我需要關心。天衣無縫，天衣無縫。但服務票的設計還是有一些困擾我。服務票是可重用的。我同意它們應該能被重用，但重用的服務票，由於它們自身的性質，是非常危險的。
Athena: 什麼意思?
Euripides: 這樣看。假設你正在用一個不安全的工作站。在你登入後，你需要郵件服務票，打印票，和文件服務票。假設你無意中在你退出後留下了那些票。 現在假設我登錄到那個工作站並且發現了那些票。我想製造一些麻煩，於是我就用你的名字登錄了。既然那些票上是你的名字，那我就可以取你的郵件，打大量的文件。這些完全是因爲這些票被偶然的放在了那裏。 並且我還可以把這些票拷走，永遠的使用它們。
Athena: 但是這很好解決。我們可以寫一個程序，在用戶退出的時候把票銷燬掉，這些票也主不能再用了。
Euripides: 那麼很明顯你的統應該有一個票據銷燬程序，讓用戶依賴這樣的機制是非常愚蠢的。你不能指望用戶在他們退出的時候會銷燬票據。並且甚至不能依賴銷燬票據本身，看下面的情況。 我有一個程序可以監視網絡並且拷內別人的服務票據。假設我想犧牲你。我等你登到工作站的時候，打開我的程序並拷貝一份你的票。 我等你退出並離開。我把我的工作站的地址調整爲你登錄時用的地址。我讓工作站認爲我是你。我有你的票，你的用戶名，你的地址。我可以用這些票來使用你的服務。
你離開工作站時銷燬你的票已沒並系。這些我偷來的票可以一直使用下去，因爲你現在的票並沒有可以使用多少次的期限，或可以使用多長的時間。
Athena: 哦，我明白你所說的了!票不能是永遠合法的，因爲它可能是一個非常大的安全隱患。我們應該限制每一張票可以用多長的時間，也許可以給每張票設一個有效期。
Euripides: 非常正確。我想票需要增加兩項信息:生存期表示票多長時間內是合法的，和一個時間標記來說明Charon是什麼時候發出這張票的。
Euripides走到了黑板寫下了如下的內容:
票{用戶名:地址:服務名:有效期:時間戳｝
Euripides: 現在當服務解開票時，它檢查票的用戶名，地址是否與發送者匹配，然後它用有效期和時間戳來檢查票是否有效。
Athena: 很好。典型的票使用哪長的有效期呢?
Euripides: 我不知道。也許是一個典型工作站的工作週期。就八小時吧。
Athena: 那如果我在工作站呆的時間超過八小時，所有的票將會失效。包括票據授權票。那我就要重新向Charon作認證，在八小時以後。
Euripides: 是不是不合理?
Athena: 我想不是。好我們就定下來吧--票在八小時後失效。現在我有一個問題問你。假設我從網絡上拷了 你的票--。
Euripides: (眨了眨眼睛)啊，Tina!你不會真的這樣做吧?
Athena: 這只是爲了討論。我拷了你的票。現在我等你退出並離開。假設你有一個醫生的約會或聚會要參加，你在兩個小時後退出，並且你在退出之前銷燬了你的票。
但我已經偷了你的票，它們還可以使用六小時。這給了我足夠的時間用你的名義去取你的文件並打印一千份什麼東西。 你看，時間戳工作的很好如果小偷選擇在它失效以後來用的話。如果小偷能在它失效之前用...。
啊，好...當然，你是對的。
Athena: 我想我們遇上了一個大問題了。(她嘆了口氣)
停了一下。
Euripides: 我想這意味着你今晚要忙了。再來點咖啡?
Athena: 爲什麼不。
第四幕
第二天早上在Euripides的辦公室。Athena來敲門。
Euripides: 你今早有黑眼圈了。
Athena: 好了，你知道的。又是一個漫漫長夜。
Euripides: 你解決了重演的問題了嗎?
Athena: 我想是的。
Euripides: 請坐。
她坐下了。
Athena: 照舊，我重申一下問題。票是可重用的，在一個限定的時間內(八小時)。如果誰偷了你的票並在它失效之前使用，我們毫無辦法。
Euripides: 確實如此。
Athena: 我們可以把這個問題理解爲設計一種別人無法重用的票。
Euripides: 但這樣的話你每次用新服務時都要取一張新票。
Athena: 對。但那是很笨的解決辦法。(稍頓。)啊，我怎樣繼續我的討論呢?(她沉思了一會兒)。
好的，我要重述一個問題，看有什麼必須條件。網絡服務必須能夠證明使用票的人就是票上所申明的人。 我來順着認證的過程再走一遍，這樣我就可以梳理出我的解決方案。
我現在想用一個網絡服務。我通過啓動工作站上的客戶端來使用它。客戶端送三樣東西給服務器:我的名字，我的工作站的網絡地址，適當的服務票據。
這張票包含了申請這張票的人的名字和他(她)申請時所使用的工作站的地址。它也包含了票的有效時間長度和時間戳。所有這些信息都被服務的Charon 密碼加密了
我們現在的認證模式基於以下的測試:
服務能對票解密嗎?
票在有效期以內嗎?
票中的名字和地址與申請者的名字和地址匹配嗎?
這些測試證明了什麼?
第一個測試證明了票是不是來自Charon.如果票不能被適當的解密，說明票不是來自真正的Charon.真正的Charon會用服務的密碼來加密票。Charon和服務是唯一知道服務密碼的兩個實體。如果票被成功的解密，服務知道它來自於真的Charon.這個測試防止了有人僞造假票。
第二項測試檢查票是否在有效期以內。如果過期，服務拒絕。這項測試阻止使用舊票，因爲票可能是偷來的。
第三項測試檢查票的用戶名和地址是否匹配請求者的用戶名和地址。如果測試失敗，說明使用者使用了別人的票。這張票當然被拒絕。如果名字和地址匹配，這個測試證明了什麼?什麼也沒有。票可以被偷走，用戶名和網絡地址都可以被改變，如果需要的話。正如我昨天指出的那樣，票可以在有效期內被盜用。因爲服務不能確定票的發送者是不是合法用戶。
服務之所以無法判斷是因爲它沒有與用戶共享一個祕密。這樣看。假如我正在埃爾斯諾爾(哈姆雷特中的城堡)值勤，你打算來和我換班。但除非你說出正確的口令，否則我不會與你換班的。我們共享了一個祕密。它可能是某人爲所有值勤的人所設的。
於是昨晚我就在想，爲什麼Charon不能爲合法用戶與服務之間設一個session key 呢?Charon發一份session key 給服務，同時發一份給用戶。當服務從用戶那裏收到一張票，它可以用這個session key 檢驗用戶的合法性。
Euripides: 等一下。Charon如何同時發兩份session key ?
Athena: 票據的擁用者從Charon的迴應中得到session key ，像這個樣子:
她在黑板上寫下了:
Charon的迴應- [sessionkey|ticket]
服務從票中獲取口令。票的格式如下:
票-{口令:用戶名:地址:服務名:有效期:時間戳｝
當你要請求服務時，客戶端程序生成一個‘驗證器’。驗證器包含了你的名字和你工作站的地址。客戶端用口令把這些信息加密，口令是你請求票據時得到的。
驗證器-{用戶名:地址｝用口令加密
生成驗證器以後，客戶端把它和票一起送給服務。因爲服務沒有口令，所以它不能解密驗證器。口令在票中，於是服務先解開票。
解開票以後，服務得到以下的東西:
票的有效期和時間戳;
票的擁有者的名字;
票擁有者的網絡地址
口令
服務檢查票是否過期。如果一切正常，服務就用口令去解驗證器。如果解密沒有問題，服務將會得到一個用戶名和網絡地址。服務用它們去和票裏的用戶名和網絡地址去匹配，如果正確，那麼服務認爲票的發送者確實是票的真實擁有者。
Athena暫停了一下，清了清喉嚨，喝了點咖啡。
我認爲口令驗證器的機制解決了盜用的問題。
Euripides: 也許。但我想。。。攻擊這個系統我必須有驗證器。
Athena: 不。你必須同時擁有驗證器和票。沒有票，驗證器是沒有用的。解開驗證器必須要有口令，服務必須解開票纔會有口令。
Euripides: 好，我明白了，你是說當客戶程序聯繫服務時，它同時送上票和驗證器?
Athena: 是的，我就是這個意思。
Euripides: 如是真是這樣，什麼可以阻止我把票和驗證器都偷走呢?我可以寫一個程序，如果我擁有了票和驗證器，我就可以一直使用它至有效期結束。我只需改變我的用戶名和工作站的地址。不是嗎?
Athena: (咬了咬她的嘴脣)是的。多沮喪啊。
Euripides: 等等，等等，等等!這不難解決。票在有效期內是可重用的，但那並不意味着驗證器是可重用的。假設我們設計了驗證器只可以被用一次。這可以嗎?
Athena: 好，也許。我樣來想一下，客戶端程序生成驗證器，然後把它和票一起送給服務。真的票和驗證器比你拷貝的要先到。如果驗證器只能被用一次，你的拷貝就失效了。 啊，這就對了。我樣現在需要做的就是發明一和方法使得驗證器只能被用一次。
Euripides: 沒問題。我們把有效期和時間戳放在上面。假設每個驗證有兩分鐘的有效期。當你想用一個服務時客戶端生成驗證器，標上當前的時間，把它和票一起送給服務。 服務器收到了票和驗證器，服務器解開驗證器，它檢查驗證器的時間戳和有效期。如果驗證器還沒失效，所有其它的檢查都通過了，那麼服務器就認爲你通過了認證。 假設我通過網絡拷貝了一份驗證器和票，我必須改變我的工作站的網絡地址和我的用戶名，這差不多要用幾分鐘。那是非常苛刻的要求，我不認爲是可能的，除非。。。 嗯，有一個潛在的問題。假設不是在網絡的轉輸中拷貝到票和驗證器，我拷貝了一份原始的從Charon而來的包，這個包是你向Charon請求時的迴應。 這個包，有兩個口令在裏面:一個是你的，一個是服務的。服務的口令隱藏在票中，我取不到，但另一個呢?那個你用來生成驗證器的? 如果我得到了口令，我就用它來建自已的驗證器，如果我能建自已的驗證器，我就能攻破你的系統。
Athena: 這就是我昨晚所想的，但是當我順着票的處理過程一想，發現那樣偷走驗證器是不可能的。
你在一臺工作站坐下，用kinit程序得到你的票據授權票。kinit要求輸入用戶名，你輸入以後，kinit把它送給Charon.Charon用你的名字查找你的口令，然後生成一張票據授權票。作爲處理的一部分，Charon生成了一個你與票據授權服務共享的口令。Charon把口令和票據授權票一起送給你，並且在發送之前用你的口令將它加密。
Charon送出了包。某人取得了這個包，但他們無能爲力因爲它是用你的口令加過密的。特別是，無人可以偷走票據授權服務的口令。 kinit收到了票據包並要求你輸入你的口令。如果你輸入正確的口令，kinit解開包取出了票據授權服務的口令。
現在你注意kinit的處理，你去取你的郵件。你打開郵件客戶端。這個程序查找一張郵件服務的票但沒有找到(你還沒取過你的郵件)。客戶端用票據授權票去申請一張郵件服務的票。
客戶端爲票據授權的過程生成了一個驗證器，並用票據授權的口令把驗證器加密。客戶端把驗證器，票據授權票，你的名字，你的工作站的地址，郵件服務的名字送給了Charon。
票據授權服務收到了這些東西，並通過了認證檢查。如果一切都通過，票據授權服務將會得到那個與你共享的口令。現在票據授權服務爲你生成了一張郵件服務的票，在這個過程中生成了一個你與郵件服務共享的口令。票據授權服務把這些東西打成包送給你的工作站。包裏有票和口令。在送包之前，票據授權服務用票據授權的口令把包加密。做完以後，包被送出去。 這樣郵件服務票的包通過網絡被送了出來。假設網絡上的某人將它複製了一份。他不幸的發現包是用票據認證的口令加過密的。既然無法解密，他就不能得到郵件口令。沒有口令，他就不能使用任何在網絡上傳送的郵件服務的票。 現在我覺得我們是安全的。你認爲呢?
Euripides: 也許吧。
Athena: 也許!你就只會說這個嗎!
Euripides: (大笑)別在意。你現在應該知道我處理問題的方式了。我猜我和你昨晚都工作到了半夜。
Athena: 哼!
Euripides: 好的，大半夜。實際上，這個系統似乎是完全可行的。口令的方案解決了我昨晚想到的一個問題:相互驗證的問題。
稍頓。
我說一下好嗎?
Athena: (有點冷淡)請便。
Euripides: 你真好。(Euripides清了清自已的嗓子)昨晚，當口令和驗證器在我腦子裏轉的時候，我想去找出這個系統新的問題，我想我發現了一個很嚴重的問題。我下面就演示一下。
假設你厭倦了現在的工作，決定換一個。你想用公司的激光打印機打印求職信，把它們送給獵頭和其它的僱主。於是你輸入打印命令，命令去取得服務票，然後把票送到打印機。這是你認爲它應該被送到的地方。實際上你並不知道你的請求被送到了正確的打印服務器。 假設一些無恥的人--比如說你的老闆--調整了系統，把你的請求送到了他辦公室的打印機。他的打印服務不關心票的內容。它告訴你的工作站服務已準備好打印你的文件。打印命令被送到了假的打印服務器，你有麻煩了。 我從相反的方向表達了相同的問題。用口令和驗證器，Charon能夠保護的它的服務器防止錯誤的用戶使用，但它不能保護它的用戶使用錯誤的服務器。系統需要爲客戶端程序提供一種驗證服務器的方法，在它向服務器發送敏感信息之前。系統必須允許交互驗證。 但口令的方案解決了這個問題。
讓我們回到打印服務器的場景。我想要打印客戶程序確認它送交的服務是合法的服務。 這就是程序要做的。
我輸入打印命令並給出一個文件名。這時我已經有了打印服務票和口令。客戶程序用密碼生成了一個驗證器，然後把驗證器和票送給了假設的打印服務器。客戶端這時還沒有送打印文件，它在等待從服務的返回。 真的服務收到票和驗證器，把票解密並得到口令，然後用口令解開驗證器。這樣服務端做完了所有的認證。 測試已經確認了我的身份。現在服務程序要準備一個響應包來證實它自已的身份。它用口令加密了返回包，並把包送給了等待的客戶端。 客戶端收到了包並試圖用口令把它解開。如果包被正確的解開得到了正確的服務器響應信息，客戶端程序就知道了這個服務器是合法的服務器。然後這時客戶端向它發出打印命令。 假設我的老闆改變了一下系統使得他的打印機看起來好像是我想要用的那個。我的客戶端送了票和驗證器給它並等待它的響應。假冒的打印服務無法生成正確的響應因爲它無法把票解開並得到口令。這樣的話客戶端就不會送打印命令給它因爲客戶端沒有得到正確的響應。最後客戶端放棄等待並退出。我的打印沒有完成，但至少我的求職信不會放在我的對頭的桌子上。
好啊，我想我們有了Charon認證系統的堅實的基礎。
Athena: 也許。不管怎麼說，我不喜歡Charon這個名字。
Euripides: 你不喜歡嗎?什麼時候?
Athena: 我從來都不喜歡，因爲它的名字聽起來沒意義。有一天我和我荷迪斯(冥王)叔叔談到了這個，他推薦了另一個名字:冥王的三個頭的看門狗。
Euripides: 啊，你是說“Cerberus".
Athena: 你說什麼語言啊!"Cerberus"實際上是。。。
Euripides: 哦，不叫這個嗎?
Athena: 當然，誰讓你是羅馬人!而我是希臘人，它是一條希臘的看門狗，它的名字是“Kerberos”，“Kerberos”是‘K’打頭的。
Euripides: 好吧，好吧，別發火。我同意這個名字。實際上，它有一個好的脖環。再見吧，Charon,歡迎你，Kerberos.
後記
這篇對話是於1988年寫的，是爲了幫助讀者理解Kerberos V4的運行方式。經過了這麼多年，它仍然非常好的服務於此。當我把這篇文章轉換成HTML的時候，我驚訝的發現這個文檔對Kerberos V5仍然非常有用。雖然很多東西改變了，但核心概念並沒有變。實際上，Kerberos V5對Kerberos只做了兩處改變。
第一處改變是因爲意識到驗證器用少於五分鐘的有效期不足以防止攻擊者進行重演，如果攻擊者是用一個程序自動的截取票和驗證器並進行重演的話。 在Kerberos V5中，驗證器真正的只能用一次因爲服務器用‘重演緩衝區’保存了最近一次提交的驗證器的信息。如果攻擊者試圖截取驗證器並重用它，‘重演緩衝區’會發現驗證器已經被提交了。
第二個主要改變是Kerberos送給kinit服務票的時候，票不再是用用戶的口令加密。它已經用票據授權服務的口令加過密了。票據授權服務的票被用來獲取其它票的時候，它直接就被傳輸了。因此票不需要再用用戶的口令加密一次。(服務器響應的其它部分，如口令，仍然是用用戶的口令加密的。) 一個類似的改變也應用到票據授權服務協議;從票據授權服務返回的票也不再用票據授權服務的口令來加密了，因爲它所包含的票已經被對應的服務的口令加過密了。舉例來說，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來加密了)
當然，Kerberos V5中還有許多新特性。用戶可以在另一個網絡中安全的提交他們的票;並且，用戶可以把他們的一部分認證權轉給服務器，這樣服務器就可以作爲用戶的代理。其它的新特性包括:用更好的加密算法替換了DES加密算法，如三重DES加密。讀者如果對V4與V5的變化感興趣的話，可以讀一下"The Evolution of the Kerberos Authentication System",作者是Cliff Neumann和Theodore Tso. 我希望你能對這篇介紹Kerberos協議的文章感興趣。我祝願你在未來的探索中更進一步。
