第三幕
第二天一早，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: 爲什麼不。
第二天一早，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的迴應-[口令|票]
服務從票中獲取口令。票的格式如下:
票-{口令:用戶名:地址:服務名:有效期:時間戳｝
當你要請求服務時，客戶端程序生成一個‘驗證器’。驗證器包含了你的名字和你工作站的地址。客戶端用口令把這些信息加密，口令是你請求票據時得到的。
驗證器-{用戶名:地址｝用口令加密。
生成驗證器以後，客戶端把它和票一起送給服務。因爲服務沒有口令，所以它不能解密驗證器。口令在票中，於是服務先解開票。
解開票以後，服務得到以下的東西:
票的有效期和時間戳;
票的擁有者的名字;
票擁有者的網絡地址。
口令。
服務檢查票是否過期。如果一切正常，服務就用口令去解驗證器。如果解密沒有問題，服務將會得到一個用戶名和網絡地址。服務用它們去和票裏的用戶名和網絡地址去匹配，如果正確，那麼服務認爲票的發送者確實是票的真實擁有者。
第二天早上在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清了清自已的嗓子)昨晚，當口令和驗證器在我腦子裏轉的時候，我想去找出這個系統新的問題，我想我發現了一個很嚴重的問題。我下面就演示一下。
我認爲口令驗證器的機制解決了盜用的問題。
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協議的文章感興趣。祝願你在未來的探索中更進一步。
好啊，我想我們有了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協議的文章感興趣。祝願你在未來的探索中更進一步。