這就是Kerberos的工作原理, 不知道是誰翻譯的. 基本上就這個意思. 向翻譯者表示感謝.
前提就是要防止公司內部的SNORT, SNIFF之類的探測器截獲用戶名和密碼. E原文在MIT的網站.
下次看有誰去寫出怎樣去建立一個 Kerberos 的服務器過程就全了. 哈哈.
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發
一份口令給服務，同時發一份給用戶。當服務從用戶那裡收到一張票，它可以用這個口令
檢驗用戶的合法性。
Euripides: 等一下。Charon如何同時發兩份口令？
Athena: 票據的擁用者從Charon的回應中得到口令，像這個樣子：
她在黑板上寫下了：
Charon的回應－[口令｜票]
服務從票中獲取口令。票的格式如下：
票－｛口令：用戶名：地址：服務名：有效期：時間戳｝
當你要請求服務時，客戶端程序生成一個‘驗證器’。驗證器包含了你的名字和你工作站的地址。客戶端用口令把這些信息加密，口令是你請求票據時得到的。
驗證器－｛用戶名：地址｝用口令加密。
生成驗證器以後，客戶端把它和票一起送給服務。因為服務沒有口令，所以它不能解密
驗證器。口令在票中，於是服務先解開票。
解開票以後，服務得到以下的東西：
票的有效期和時間戳；
票的擁有者的名字；
票擁有者的網絡地址。
口令。
服務檢查票是否過期。如果一切正常，服務就用口令去解驗證器。如果解密沒有問題，服務將會得到一個用戶名和網絡地址。服務用它們去和票裡的用戶名和網絡地址去匹配，如果正確，那麼服務認為票的發送者確實是票的真實擁有者。
Athena暫停了一下，清了清喉嚨，喝了點咖啡。
我認為口令驗證器的機制解決了盜用的問題。
Euripides: 也許。但我想。。。攻擊這個系統我必須有驗證器。
Athena: 不。你必須同時擁有驗證器和票。沒有票，驗證器是沒有用的。解開驗證器必須要有口令，服務必須解開票才會有口令。
Euripides: 好，我明白了，你是說當客戶程序聯系服務時，它同時送上票和驗證器？
Athena: 是的，我就是這個意思。
Euripides: 如是真是這樣，什麼可以阻止我把票和驗證器都偷走呢？我可以寫一個程序，如果我擁有了票和驗證器，我就可以一直使用它至有效期結束。我只需改變我的用戶名和工作站的地址。不是嗎？
Athena: (咬了咬她的嘴唇）是的。多沮喪啊。
Euripides: 等等，等等，等等！這不難解決。票在有效期內是可重用的，但那並不意味著驗證器是可重用的。假設我們設計了驗證器只可以被用一次。這可以嗎？
Athena: 好，也許。我樣來想一下，客戶端程序生成驗證器，然後把它和票一起送給服務。真的票和驗證器比你拷貝的要先到。如果驗證器只能被用一次，你的拷貝就失效了。 啊，這就對了。我樣現在需要做的就是發明一和方法使得驗證器只能被用一次。
Euripides: 沒問題。我們把有效期和時間戳放在上面。假設每個驗證有兩分鐘的有效期。當你想用一個服務時客戶端生成驗證器，標上當前的時間，把它和票一起送給服務。服務器收到了票和驗證器，服務器解開驗證器，它檢查驗證器的時間戳和有效期。如果驗證器還沒失效，所有其它的檢查都通過了，那麼服務器就認為你通過了認證。假設我通過網絡拷貝了一份驗證器和票，我必須改變我的工作站的網絡地址和我的用戶名，這差不多要用幾分鐘。那是非常苛刻的要求，我不認為是可能的，除非。。。嗯，有一個潛在的問題。假設不是在網絡的轉輸中拷貝到票和驗證器，我拷貝了一份原始的從Charon而來的包，這個包是你向Charon請求時的回應。這個包，有兩個口令在裡面：一個是你的，一個是服務的。服務的口令隱藏在票中，我取不到，但另一個呢？那個你用來生成驗證器的？如果我得到了口令，我就用它來建自已的驗證器，如果我能建自已的驗證器，我就能攻破你的系統。
Athena: 這就是我昨晚所想的，但是當我順著票的處理過程一想，發現那樣偷走驗證器是不可能的。
你在一台工作站坐下，用kinit程序得到你的票據授權票。kinit要求輸入用戶名，你輸入以後，kinit把它送給Charon.Charon用你的名字查找你的口令，然後生成一張票據授權票。作為處理的一部分，Charon生成了一個你與票據授權服務共享的口令。Charon把口令和票據授權票一起送給你，並且在發關之前用你的口令將它加密。
Charon送出了包。某人取得了這個包，但他們無能為力因為它是用你的口令加過密的。特別是，無人可以偷走票據授權服務的口令。 kinit收到了票據包並要求你輸入你的口令。如果你輸入正確的口令，kinit解開包取出了口令。現在你注意kinit的處理，你去取你的郵件。你打開郵件客戶端。這個程序查找一張郵件服務的票但沒有找到（你還沒取過你的郵件）。客戶端用票據授權票去申請一張郵件服務的票。客戶端為票據授權的過程生成了一個驗證器，並用票據授權的口令把驗證器加密。客戶端把驗證器送給了Charon，票據授權票，你的名字，你的工作站的地址，郵件服務的名字。票據授權服務收到了這些東西，並通過了認證檢查。如果一切都通過，票據授權服務將會得到那個與你共享的口令。現在票據授權服務為你生成了一張郵件服務的票，在這個過程中生成了一個你與郵件服務共享的口令。票據授權服務把這些東西打成包送給你的工作站。包裡有票和口令。在送包之前，票據授權服務用票據授權的口令把包加密。做完以後，包被送出去。這樣郵件服務票的包通過網絡被送了出來。假設網絡上的某人將它復制了一份。他不幸的發現包是用票據認證的口令加過密的。既然無法解密，他就不能得到郵件口令。沒有口令，他就不能使用任何在網絡上傳送的郵件服務的票。 現在我覺得我們是安全的。你認為呢？
Euripides: 也許吧。
Athena: 也許！你就只會說這個嗎！
Euripides: (大笑）別在意。你現在應該知道我處理問題的方式了。我猜我和你昨晚都工
作到了半夜。
Athena: 哼！
Euripides: 好的，大半夜。實際上，這個系統似乎是完全可行的。口令的方案解決了我
昨晚想到的一個問題：相互驗證的問題。
稍頓。
我說一下好嗎？
Athena: (有點冷淡）請便。
Euripides: 你真好。(Euripides清了清自已的嗓子）昨晚，當口令和驗證器在我腦子裡轉的時候，我想去找出這個系統新的問題，我想我發現了一個很嚴重的問題。我下面就演示一下。
假設你厭倦了現在的工作，決定換一個。你想用公司的激光打印機打印求職信，把它們送給獵頭和其它的雇主。於是你輸入打印命令，命令去取得服務票，然後把票送到打印機。這是你認為它應該被送到的地方。實際上你並不知道你的請求被送到了正確的打印服務器。假設一些無恥的人－－比如說你的老板－－調整了系統，把你的請求送到了他辦公室的打印機。他的打印服務不關心票的內容。它告訴你的工作站服務已准備好打印你的文件。打印命令被送到了假的打印服務器，你有麻煩了。我從相反的方向表達了相同的問題。用口令和驗證器，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加密。讀者如果對V
4
與V5的變化感興趣的話，可以讀一下"The Evolution of
the Kerberos Authentication System",作者是Cliff Neumann和Theodore Tso. 我希望你能對這篇介紹Kerberos協議的文章感興趣。我祝願你在未來的探索中更進一步
認它送交的服務是合法的服務。這就是程序要做的。我輸入打印命令並給出一個文件名。這時我已經有了打印服務票和口令。客戶程序用密碼生成了一個驗證器，然後把驗證器和票送給了假設的打印服務器。客戶端這時還沒有送打印文件，它在等待從服務的返回。真的服務收到票和驗證器，把票解密並得到口令，然後用口令解開驗證器。這樣服務端做完了所有的認證。測試已經確認了我的身份。現在服務程序要准備一個響應包來證實它自已的身份。它用口令加密了返回包，並把包送給了等待的客戶端。客戶端收到了包並試圖用口令把它解開。如果包被正確的解開得到了正確的服務器響應信息，客戶端程序就知道了這個服務器是合法的服務器。然後這時客戶端向它發出打印命令。假設我的老板改變了一下系統使得他的打印機看起來好像是我想要用的那個。我的客戶端送了票和驗證器給它並等待它的響應。假冒的打印服務無法生成正確的響應因為它無法把票解開並得到口令。這樣的話客戶端就不會送打印命令給它因為客戶端沒有得到正確的
響應。最後客戶端放棄等待並退出。我的打印沒有完成，但至少我的求職信不會放在我的
對頭的桌子上。
好啊，我想我們有了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加密。讀者如果對V
4
與V5的變化感興趣的話，可以讀一下"The Evolution of
the Kerberos Authentication System",作者是Cliff Neumann和Theodore Tso. 我希望你能對這篇介紹Kerberos協議的文章感興趣。我祝願你在未來的探索中更進一步
假設你厭倦了現在的工作，決定換一個。你想用公司的激光打印機打印求職信，把它們送給獵頭和其它的雇主。於是你輸入打印命令，命令去取得服務票，然後把票送到打印機。這是你認為它應該被送到的地方。實際上你並不知道你的請求被送到了正確的打印服務器。假設一些無恥的人－－比如說你的老板－－調整了系統，把你的請求送到了他辦公室的打印機。他的打印服務不關心票的內容。它告訴你的工作站服務已准備好打印你的文件。打印命令被送到了假的打印服務器，你有麻煩了。我從相反的方向表達了相同的問題。用口令和驗證器，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加密。讀者如果對V
4
與V5的變化感興趣的話，可以讀一下"The Evolution of
the Kerberos Authentication System",作者是Cliff Neumann和Theodore Tso. 我希望你能對這篇介紹Kerberos協議的文章感興趣。我祝願你在未來的探索中更進一步
