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坐在他的桌子旁邊,讀著撓始thena來敲門.

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: 這只是為了討論。我拷了你的票。現在我等你退出並離開。假設你有一個醫生的約會或聚會要參加,你在兩個小時後退出,並且你在退出之前銷毀了你的票。
但我已經偷了你的票,它們還可以使用六小時。這給了我足夠的時間用你的名義去取你的檔並列印一千份什麼東西。 你看,時間戳記工作的很好如果小偷選擇在它失效以後來用的話。如果小偷能在它失效之前用…。

Euripides: 啊,好…當然,你是對的。

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加密。

相關主題

發佈留言

2014-11-29

Posted In: 其他技術 Others

Leave a Comment