關於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加密。讀者若是對V4與V5的變化感興趣的話，能夠讀一下"The Evolution of the Kerberos Authentication System",做者是Cliff Neumann和Theodore Tso.

 

最新的版本爲Kerberos V5，Microsoft Windows Server 2003上已經實現了Kerberos5身份驗證協議，在Windows 2000, XP, Server 2003, Vista, 以及Longhorn, 還有UNIX系統，都支持Kerberos身份驗證協議。
NT早期版本中使用NTLM來進行網絡認證,在Windows2000/2003中，默認設置使用Kerberos v5(KV5). 在windows2000/2003域環境中，首先考慮使用Kv5認證，若是沒法選擇Kv5,纔會使用NTLM. 即Lv5將用於任何Windows2000/2003到Windows2000/2003的認證。若是認證過程的一方不運行Windows2000/2003,系統會自動降級使用NTLM。