Kerberos

Kerberos 是一種網路認證協議，其設計目標是通過密鑰系統為客戶機 / 伺服器應用程序提供強大的認證服務。該認證過程的實現不依賴於主機操作系統的認證，無需基於主機地址的信任，不要求網路上所有主機的物理安全，並假定網路上傳送的數據包可以被任意地讀取、修改和插入數據。在以上情況下， Kerberos 作為一種可信任的第三方認證服務，是通過傳統的密碼技術（如：共享密鑰）執行認證服務的。

認證過程具體如下：客戶機向認證伺服器（AS）發送請求，要求得到某伺服器的證書，然後 AS 的響應包含這些用客戶端密鑰加密的證書。證書的構成為： 1) 伺服器“ticket” ； 2) 一個臨時加密密鑰（又稱為會話密鑰“session key”） 。客戶機將 ticket （包括用伺服器密鑰加密的客戶機身份和一份會話密鑰的拷貝）傳送到伺服器上。會話密鑰可以（現已經由客戶機和伺服器共享）用來認證客戶機或認證伺服器，也可用來為通信雙方以後的通訊提供加密服務，或通過交換獨立子會話密鑰為通信雙方提供進一步的通信加密服務。

上述認證交換過程需要只讀方式訪問 Kerberos 資料庫。但有時，資料庫中的記錄必須進行修改，如添加新的規則或改變規則密鑰時。修改過程通過客戶機和第三方 Kerberos 伺服器（Kerberos 管理器 KADM）間的協議完成。有關管理協議在此不作介紹。另外也有一種協議用於維護多份 Kerberos 資料庫的拷貝，這可以認為是執行過程中的細節問題，並且會不斷改變以適應各種不同資料庫技術。

Kerberos又指麻省理工學院為這個協議開發的一套計算機網路安全系統。系統設計上採用客戶端/伺服器結構與DES加密技術，並且能夠進行相互認證，即客戶端和伺服器端均可對對方進行身份認證。可以用於防止竊聽、防止replay攻擊、保護數據完整性等場合，是一種應用對稱密鑰體制進行密鑰管理的系統。Kerberos的擴展產品也使用公開密鑰加密方法進行認證。

麻省理工研發了Kerberos協議來保護Project Athena提供的網路伺服器。這個協議以希臘神話中的人物Kerberos（或者Cerberus）命名，他在希臘神話中是Hades的一條兇猛的三頭保衛神犬。目前該協議存在一些版本，版本1-3都只有麻省理工內部發行。

Kerberos版本4的主要設計者Steve Miller和Clifford Neuman，在1980年末發布了這個版本。這個版本主要針對Project Athena。版本5由John Kohl和Clifford Neuman設計，在1993年作為RFC 1510頒布（在2005年由RFC 4120取代），目的在於克服版本4的局限性和安全問題。

麻省理工在版權許可的情況下，製作了一個Kerberos的免費實現工具，這種情況類似於BSD。在2007年，麻省理工組成了一個Kerberos協會，以此推動Kerberos的持續發展。

因為使用了DES加密演演算法（用56比特的密鑰），美國出口管制當局把Kerberos歸類為軍需品，並禁止其出口。一個非美國設計的Kerberos版本4的實現工具KTH-KRB由瑞典皇家理工研製，它使得這套系統在美國更改密碼出口管理條例（2000年）前，在美國境外就可以使用。瑞典的實現工具基於一個叫做eBones的版本，而eBones基於麻省理工對外發行的基於Kerberos版本4的補丁9的Bones（跳過了加密公式和對它們的函數調用）。這些在一定程度上決定了Kerberos為什麼沒有被叫做eBones版。Kerberos版本5的實現工具，Heimdal，基本上也是由發布KTH-KRB的同一組人發布。

Windows2000和後續的操作系統都默認Kerberos為其默認認證方法。RFC 3244記錄整理了微軟的一些對Kerberos協議軟體包的添加。RFC4757"微軟Windows2000Kerberos修改密碼並設定密碼協議"記錄整理了微軟用RC4密碼的使用。雖然微軟使用了Kerberos協議，卻並沒有用麻省理工的軟體。

蘋果的Mac OS X也使用了Kerberos的客戶和伺服器版本。

Red Hat Enterprise Linux4 和後續的操作系統使用了Kerberos的客戶和伺服器版本。

IETF Kerberos的工作小組在2005年更新了說明規範，最近的更新包括：

"加密和校驗和細則"（RFC 3961）

"針對Kerberos版本5的高級加密演演算法（AES）加密"（RFC 3962）

Kerberos版本5說明規範的新版本"Kerberos網路認證服務（版本5）"（RFC 4120）。這個版本廢棄了早先的RFC 1510，用更細化和明確的解釋說明了協議的一些細節和使用方法。

GSS-API的一個新版本"Kerberos版本5 普通的安全服務應用軟體交互機制：版本2"（RFC 4121）

簡要大概地說一下Kerberos是如何工作的：

1.假設你要在一台電腦上訪問另一個伺服器（你可以發送telnet或類似的登錄請求）。你知道伺服器要接受你的請求必須要有一張Kerberos的“入場券”。

2.要得到這張入場券，你首先要向驗證伺服器（AS）請求驗證。驗證伺服器會創建基於你的密碼（從你的用戶名而來）的一個“會話密鑰”（就是一個加密密鑰），併產生一個代表請求的服務的隨機值。這個會話密鑰就是“允許入場的入場券”。

3.然後，你把這張允許入場的入場券發到授權伺服器（TGS）。TGS物理上可以和驗證伺服器是同一個伺服器，只不過它現在執行的是另一個服務。TGS返回一張可以發送給請求服務的伺服器的票據。

4.伺服器或者拒絕這張票據，或者接受這張票據並執行服務。

5.因為你從TGS收到的這張票據是打上時間戳的，所以它允許你在某個特定時期內（一般是八小時）不用再驗證就可以使用同一張票來發出附加的請求。使這張票擁有一個有限的有效期使其以後不太可能被其他人使用。

實際的過程要比剛才描述的複雜得多。用戶過程也會根據具體執行有一些改變。

協議的安全主要依賴於參加者對時間的鬆散同步和短周期的叫做Kerberos票據的認證聲明。下面是對這個協議的一個簡化描述，將使用以下縮寫：

• AS（Authentication Server）= 認證伺服器

• KDC（Key Distribution Center）= 密鑰分發中心

• TGT（Ticket Granting Ticket）= 票據授權票據，票據的票據

• TGS（Ticket Granting Server）= 票據授權伺服器

• SS（Service Server）= 特定服務提供端

客戶端用戶發送自己的用戶名到KDC伺服器以向AS服務進行認證。KDC伺服器會生成相應的TGT票據，打上時間戳，在本地資料庫中查找該用戶的密碼，並用該密碼對TGT進行加密，將結果發還給客戶端用戶。該操作僅在用戶登錄或者kinit申請的時候進行。客戶端收到該信息，並使用自己的密碼進行解密之後，就能得到TGT票據了。這個TGT會在一段時間之後失效，也有一些程序(session manager)能在用戶登陸期間進行自動更新。當客戶端用戶需要使用一些特定服務(Kerberos術語中用"principal"表示)的時候，該客戶端就發送TGT到KDC伺服器中的TGS服務。當該用戶的TGT驗證通過並且其有權訪問所申請的服務時，TGS服務會生成一個該服務所對應的ticket和session key，併發還給客戶端。客戶端將服務請求與該ticket一併發送給相應的服務端即可。具體的流程請看下面的描述。

其在網路通訊協定中屬於顯示層。

簡單地說，用戶先用共享密鑰從某認證伺服器得到一個身份證明。隨後，用戶使用這個身份證明與SS通信，而不使用共享密鑰。

1.失敗於單點：它需要中心伺服器的持續響應。當Kerberos服務宕機時，沒有人可以連接到伺服器。這個缺陷可以通過使用複合Kerberos伺服器和缺陷認證機制彌補。

2.Kerberos要求參與通信的主機的時鐘同步。票據具有一定有效期，因此，如果主機的時鐘與Kerberos伺服器的時鐘不同步，認證會失敗。默認設置要求時鐘的時間相差不超過10分鐘。在實踐中，通常用網路時間協議後台程序來保持主機時鐘同步。

3.管理協議並沒有標準化，在伺服器實現工具中有一些差別。

4.因為所有用戶使用的密鑰都存儲於中心伺服器中，危及伺服器的安全的行為將危及所有用戶的密鑰。

5.一個危險客戶機將危及用戶密碼。

一種認證標準，通過使用一台中央伺服器來提供“票據”，供其他在網路上提供資源的伺服器進行識別。在Windows 2000, XP, Server 2003, Vista, 以及Longhorn, 還有UNIX系統，都對它進行支持。