Kerberos

Kerberos（/ ˈkərbərəs /）是一種電腦網路授權協定，用來佇非安全網路內底，對個人通信以安全的手段進行身份認證。這个詞閣指麻省理工學院為這个協定開發的一套電腦軟體。軟體的設計採用客戶捀 / 侍服器結構，並且會當進行互相認證，即客戶捀和侍服器捀均會當對方進行身份認證。會當用於防止竊聽、防止重放攻擊、保護資料完整性等場合，是一種應用對稱金鎖體制進行金鎖管理的系統。Kerberos 的擴充產品也使用公開金鎖加密方法進行認證。

當有 N 個人使用這个系統的時陣，為確保在任意兩个人之間進行秘密對話，系統至少儲存有伊佮逐个人的共享金鎖，所需要的上無對談金鎖數為 N 個。

歷史

麻省理工學院研發 Kerberos 協定來保護雅典娜工程（Project Athena）提供的網路侍服器。這个協定以希臘神話中的人物 Kerberos（抑是講 Cerberus）號名，伊咧希臘神話中是 Hades 的一條歹猛的三頭保衛神犬。這馬該協定存在一寡版本，版本一爿三攏干焦麻省理工內部發行。

Kerberos 版本四的主要設計者 Steve Miller 和 Clifford Neuman，佇一九八空年代尾期發佈這个版本。這个版本主要針對雅典娜工程。版本五由 John Kohl 和 Clifford Neuman 設計的，佇咧一九九三年作為 RFC 一千五百十頒布（佇二空空五年由 RFC 四千一百二十取代）， 目的是佇咧克服版本四的局限性佮安全問題。

麻省理工佇咧作權允准的狀況之下，來製造一个 Kerberos 的免錢實現工具，這種情形類似 BSD。佇二空空七年，麻省理工組成一个 Kerberos 協會，以此推動 Kerberos 的繼續發展。

因為使用資料加密標準（DES）加密演算法（用五十六 bit 金鎖）， 美國出口管制當局共 Kerberos 歸類做軍需品，並禁止其出口。一个非美國設計的 Kerberos 版本四的實現工具 KTH-KRB 由瑞典皇家工學院研製，伊予這套系統佇美國更加改密碼出口管理條例進前（大約是佇二空空年）， 佇美國境外就會當使用。瑞典的實現工具是一个叫做 eBones 的版本，而且 eBones 對麻省理工對外發行的所在 Kerberos 版本四的修補程式九的 Bones（跳過加密公式佮對𪜶的函式呼叫）。 遮一定程度決定 Kerberos 是按怎無予人叫做 eBones 版。Kerberos 版本五的實現工具，Heimdal，基本上嘛是由發佈 KTH-KRB 的仝一組人發佈。

佇二空空五年，網際網路工程任務組（IETF）Kerberos 工作小組更新矣規範，更新包括：

• " Kerberos 五加密佮校驗佮規範 "（RFC 三千九百六十一）。
• " Kerberos 五進階加密標準（AES）加密 "（RFC 三千九百六十二）。
• " Kerberos 網路認證服務（版本五）"（RFC 四千二十）— Kerberos 版本的五規範的新版本。這个版本廢棄早前的 RFC 一千五百十，用較幼化佮明確的解說說說明協定的一寡細節佮使用方法。
• " Kerberos 五通用安全服務應用程式介面（GSS-API）機制：版本二 "（RFC 四千一百二十一）— 通用安全服務應用程式介面（GSS-API）規範的新版本。

Windows 兩千和後壁的作業系統使用 Kerberos 為其預設認證方法。RFC 三千兩百四十四 " 微軟 Windows 兩千 Kerberos 變閣較密碼佮設定密碼協定 " 記錄整理一寡軟軟著 Kerberos 協定軟體套件的添加。RFC 四千七百五十七記錄整理微軟著 RC 四密碼的使用。雖然微軟仔使用 Kerberos 協定，煞並無用麻省理工的軟體。

蘋果的 Mac OS X 嘛使用 Kerberos 的客戶佮侍服器版本。Red Hat Enterprise Linux 四佮後續的作業系統使用 Kerberos 的客戶佮侍服器版本。

基本是咧講

Kerberos 使用 Needham-Schroeder 協定做伊的基礎。伊使用一个由兩个獨立的邏輯的部份：認證侍服器佮票據授權侍服器組成的 " 可信賴的第三方 "，術語叫金鎖分發中心（KDC）。 Kerberos 工作咧用證明使用者身份的 " 票據 " 的基礎頂面。

KDC 持有一个金鎖資料庫；逐个網路實體—— 無論是客戶猶是侍服器—— 共享一套干焦伊家己佮 KDC 知影的金鎖。金鎖的內容用佇證明實體的身份。對兩个實體間的通批，KDC 產生一个對談金鎖，用來加密𪜶之間的互相資訊。

協定內容

協定的安全主要依賴賴參加者對時間的鬆散仝步佮短周期的號做 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 通批，攏無使用共享金鎖。

具體的流程

（ 注意：現流程使用矣嘿稱加密；此流程發生在某一个Kerberos領域中；小寫字母 c , d , e , g 是客戶捀發出的訊息，大寫字母 A , B , E , F , H 是各个侍服器發轉來的訊息。）

首先，使用者使用客戶捀（使用者家己的機器）上的程式進行登入：

一 . 使用者輸入使用者 ID 佮密碼到客戶捀。 二 . 客戶端程式執行一个單向函式（大多數攏是雜鬥）共密碼轉換做金鎖，這就是客戶捀（使用者）的「使用者金鎖」( user's secret key )。

隨後，客戶捀認證（客戶捀 ( Client ) 對認證侍服器 ( AS ) 取得票據授權票據（TGT））：

一 . 客戶捀向 AS 傳送一條明文訊息，申請基於這个使用者所應該有的服務，比如講「使用者 Sunny 欲請求服務」（Sunny 是使用者 ID）。（注意：使用者不向 AS 傳送「使用者金鎖」，也無傳送密碼）該 AS 會當對本地的資料庫內底查詢著愛申請使用者的密碼，並通過相仝途徑轉換做相仝的「使用者金鎖」。 二 . AS 檢查該使用者 ID 敢是佇本地的資料庫內底，若使用者存在倒轉來二條訊息：

• 訊息 A：客戶捀 / TGS 對談金鎖 ( Client / TGS Session Key )（該對講金鎖用佇咧將來客戶捀佮 TGS 的通批（對談）上）， 通過「使用者金鎖」進行加密
• 訊息 B：TGT（TGT 包括講：訊息 A 中的「客戶捀 / TGS 對談金鎖」，使用者 ID，使用者網址，TGT 有效期）， 通過「TGS 金鎖」( TGS's secret key ) 進行加密三 . 一旦客戶捀收著訊息 A 佮訊息 B，客戶捀首先來試看覓家己的「使用者金鎖」解密訊息 A，若使用者輸入的密碼佮 AS 資料庫內底的密碼無符，是袂當成功解密訊息 A。輸入正確的密碼並通過隨之生成的「使用者金鎖」才有法度解密訊息 A，對會到「客戶捀 / TGS 對談金鎖」。（注意：客戶捀袂當解密訊息 B，因為乎 B 是用「TGS 金鎖」加密的）。 有矣「客戶捀 / TGS 對談金鎖」，客戶捀就足好的 TGS 進行認證矣。

然後，服務授權（客戶捀對 TGS 取得票據 ( client-to-server ticket )）：

一 . 當客戶捀需要申請特定的服務的時陣，其向 TGS 傳送以下二條訊息：

• 訊息 c：即訊息 B 的內容（「 TGS 金鎖」加密了後的時陣 TGT）， 閣想欲取得的服務的服務 ID（注意：毋是使用者 ID）
• 訊息 d：認證符 ( Authenticator )（Authenticator 包括講：使用者 ID，時間抽）， 通過「客戶捀 / TGS 對談金鎖」進行加密二 . 收著訊息 c 佮訊息 d 後，TGS 第一呢先檢查 KDC 資料庫內底敢有存在需要的服務，走揣著了後，TGS 用家己的「TGS 金鎖」解密訊息 c 中的訊息 B（也就是講 TGT）， 對進前生的「客戶捀 / TGS 對談金鎖」。 TGS 閣用這个對談金鎖解密訊息 d 得著包含使用者 ID 佮時間咧揬的 Authenticator，並著 TGT 和 Authenticator 進行驗證，驗證通過了後倒轉來二條訊息：
• 訊息 E：客戶捀-侍服器票據 ( client-to-server ticket )（該票據包括：「 客戶捀 / SS 對談金鎖」( Client / Server Session Key）， 使用者 ID，使用者網址，有效期）， 提供該服務的「侍服器金鎖」( service's secret key )進行加密
• 訊息 F：客戶捀 / SS 對談金鎖 ( Client / Server Session Key )（該對講金鎖用佇咧將來客戶捀佮 SS 的通批（對談）上）， 通過「客戶捀 / TGS 對談金鎖」進行加密三 . 客戶捀收著遮的訊息了後，用「客戶捀 / TGS 對談金鎖」解密訊息 F，得著「客戶捀 / SS 對談金鎖」。（注意：客戶捀袂當解密訊息 E，因為乎 E 是用「侍服器金鎖」加密的）。

最後咧，服務請求（客戶捀對 SS 取得服務）：

一 . 得著「客戶捀 / SS 對談金鎖」了後，客戶捀就會使使用侍服器提供的服務矣。客戶捀向指定 SS 發出二條訊息：

• 訊息 e：即上一步內底的訊息 E「客戶捀-侍服器票據」，已經通過「侍服器金鎖」進行加密
• 訊息 g：新的Authenticator（包括講：使用者 ID，時間抽）， 通過「客戶捀 / SS 對談金鎖」進行加密二 . SS 用家己的「侍服器金鎖」解密訊息 e 對會到 TGS 提供的「客戶捀 / SS 對談金鎖」。 閣用這个對談金鎖解密訊息 g 得著 Authenticator，（仝 TGS 仝款）對票據和 Authenticator 進行驗證，驗證通過則倒轉來一條訊息（確認函：確證的身份真實，樂於提供服務）：
• 訊息 H：新時間咧揬（新時間咧揬是：客戶捀傳送的時間內底揬加一，v 已經取消這一做法）， 通過「客戶捀 / SS 對談金鎖」進行加密三 . 客戶捀通過「客戶捀 / SS 對談金鎖」解密訊息 H，得著新時間揬並驗證其敢有正確。驗證通過的話是客戶捀會當信賴 SS，並向 SS 傳送的服務請求。

四 . SS 向客戶捀提供相應的服務。

==缺陷==* 單點故障：伊需要中心侍服器的繼續回應。當 Kerberos 服務延機時，就無人會當連接著侍服器。這缺陷會當通過使用複合 Kerberos 侍服器佮缺失認證的機制彌補。

• Kerberos 要求參與通信的主機的時鐘仝步。票據具有一定有效期，所以，若主機的時鐘佮 Kerberos 侍服器的時鐘無仝步，認證會失敗。預設定要求時鐘的時間相差無超過十分鐘。咱佇實踐中，通常用網路時間協定後台程式來保持主機時鐘仝步。
• 管理協定並無標準化，佇遮侍服器實在工具有一寡差別。RFC 三千兩百四十四描述了密碼更改。
• 因為所有使用者使用的金鎖攏儲存佇咧中心侍服器內底，危及侍服器的安全行為將危及所有使用者的金鎖。
• 一个危險客戶機將危及使用者密碼。

外部連結

• Kerberos Consortium
• Kerberos page at MIT website
• Kerberos Working Group at IETF website
• Kerberos Sequence Diagram