基本介紹
- 中文名：網路認證協定
- 外文名：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是如何工作的：
- 假設你要在一台電腦上訪問另一個伺服器（你可以傳送telnet或類似的登錄請求）。你知道伺服器要接受你的請求必須要有一張Kerberos的“入場券”。
- 要得到這張入場券，你首先要向驗證伺服器（AS）請求驗證。驗證伺服器會創建基於你的密碼（從你的用戶名而來）的一個“會話密鑰”（就是一個加密密鑰），並產生一個代表請求的服務的隨機值。這個會話密鑰就是“允許入場的入場券”。
- 然後，你把這張允許入場的入場券發到授權伺服器（TGS）。TGS物理上可以和驗證伺服器是同一個伺服器，只不過它現在執行的是另一個服務。TGS返回一張可以傳送給請求服務的伺服器的票據。
- 伺服器或者拒絕這張票據，或者接受這張票據並執行服務。
- 因為你從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系統，都對它進行支持。
