Kerberos - 網路身分驗證協定

Posted on

在現今複雜的網路環境中，如何安全地驗證使用者身分並授權其存取網路資源，是一項至關重要的課題。Kerberos 協定，作為一個成熟且強大的解決方案，被廣泛應用於各種分散式系統中，提供了強固的身分驗證機制。

本文將探討 Kerberos 的起源、核心元件、驗證流程以及其在現代網路安全中的重要性。

Kerberos 的起源與標準

Kerberos 最初由麻省理工學院 (MIT) 於1983年至1991年間的「雅典娜計畫」(Project Athena) 中研發成功。其設計目標是在一個不安全的網路上，為客戶端/伺服器架構的應用程式提供可靠的身分驗證。該協定經過多年的發展，其第五版 (v5) 最初被定義在 RFC 1510 文件中，後續並由 RFC 4120 和 RFC 4121 等文件進行了更新與完善。微軟公司也將 Kerberos 作為其 Windows 作業系統預設的身分驗證方法。image size

Kerberos 的核心元件

Kerberos 系統主要由三個部分組成：

  • 用戶端 (Client): 即需要存取網路服務的使用者或裝置。
  • 伺服器 (Server): 提供特定服務的伺服器。
  • 金鑰分發中心 (Key Distribution Center, KDC): KDC 是 Kerberos 的核心，扮演著可信賴的第三方仲裁角色。它又包含兩個邏輯部分：
    • 驗證伺服器 (Authentication Server, AS): 負責驗證用戶端的初始身分。
    • 票據授權伺服器 (Ticket-Granting Server, TGS): 負責發放存取特定服務的票據。

關鍵術語

在 Kerberos 運作流程中，有幾個重要的憑證與金鑰：

  • 票據授權票據 (Ticket-Granting Ticket, TGT): 用戶端在通過 AS 的初始驗證後取得的憑證，用於向 TGS 證明自己的身分。
  • 服務票據 (Service Ticket): TGS 在驗證 TGT 後，發給用戶端用以存取特定應用程式伺服器的憑證。
  • 對話金鑰 (Session Key): 一個臨時性的對稱金鑰，用於保障用戶端與 TGS 或應用程式伺服器之間的通訊安全。
  • 憑證 (Credential): 指的是 TGT 與對話金鑰的組合。

Kerberos 驗證流程

Kerberos 的驗證流程猶如一連串的「票務」交換，確保每一步驟的安全性。整個過程可以簡化為以下幾個階段：

  1. 初始驗證請求 (KRB_AS_REQ): 用戶端 (Alice) 向 KDC 的驗證伺服器 (AS) 發送請求，表明自己的身分 ([email protected])，希望獲得一張 TGT。
  2. AS 回應 (KRB_AS_REP): AS 在資料庫中確認用戶端身分後，會發回兩項重要資訊：一個是用 TGS 祕密金鑰加密的 TGT；另一個則是用戶端密碼所衍生的金鑰加密過的「TGS 對話金鑰」。用戶端使用自己的密碼解開後者，從而獲得 TGT 與 TGS 對話金鑰。
  3. 服務票據請求 (KRB_TGS_REQ): 當用戶端需要存取某個特定服務 (MyService) 時，它會將先前取得的 TGT，連同一個使用「TGS 對話金鑰」加密的驗證器 (Authenticator)，一併發送給 TGS。
  4. TGS 回應 (KRB_TGS_REP): TGS 收到請求後，會用自己的祕密金鑰解開 TGT，並用其中的 TGS 對話金鑰解開驗證器。驗證無誤後，TGS 會發放一張「服務票據」以及一個新的「用戶端-伺服器對話金鑰」給用戶端。
  5. 服務請求 (KRB_AP_REQ): 用戶端將 TGS 發放的「服務票據」與一個使用新的「用戶端-伺服器對話金鑰」加密的驗證器，發送給目標應用程式伺服器 (MyService)。
  6. 服務存取授權 (KRB_AP_REP): 應用程式伺服器用自己的祕密金鑰解開服務票據，再用其中的「用戶端-伺服器對話金鑰」解開驗證器。一旦所有資訊都正確無誤，伺服器便確認了用戶端的身分，並允許其存取服務。
graph LR
    subgraph "第一步：向認證伺服器 (AS) 請求 TGT"
        Client(用戶端) -- 1. 請求 TGT (包含使用者 ID) --> AS(認證伺服器 AS)
        AS -- 2. 回傳加密的 TGT 和 Session Key --> Client
    end

    subgraph "第二步：向票證授予伺服器 (TGS) 請求服務票證"
        Client -- 3. 攜帶 TGT 和 Authenticator 請求服務票證 --> TGS(票證授予伺服器 TGS)
        TGS -- 4. 回傳加密的服務票證 (Service Ticket) --> Client
    end

    subgraph "第三步：向應用程式伺服器請求服務"
        Client -- 5. 攜帶服務票證和新的 Authenticator 請求服務 --> AppServer(應用程式伺服器)
        AppServer -- 6. (可選) 相互驗證 --> Client
    end

    style Client fill:#D5F5E3,stroke:#2ECC71,stroke-width:2px
    style AS fill:#EBF5FB,stroke:#3498DB,stroke-width:2px
    style TGS fill:#FEF9E7,stroke:#F1C40F,stroke-width:2px
    style AppServer fill:#FADBD8,stroke:#E74C3C,stroke-width:2px

安全考量與延伸功能

儘管 Kerberos 設計嚴謹，但在部署時仍需注意一些安全問題：

  • 時鐘同步 (Clock Synchronization): 系統中所有主機的時鐘必須保持同步。Kerberos 使用時間戳記來防止重送攻擊 (Replay Attack)，若時鐘歪斜過大，驗證將會失敗。
  • 離線攻擊 (Off-line Attack): 在初始驗證階段，如果攻擊者攔截了 AS 的回應，他們可以嘗試使用字典檔對加密的對話金鑰進行離線暴力破解，以猜測使用者的密碼。
  • 伺服器密碼儲存: AS 必須儲存所有使用者的金鑰資訊，這使得 AS 成為一個極具吸引力的攻擊目標。

此外，Kerberos 還定義了更進階的訊息交換協定，以提供額外的安全保障：

  • KRB_SAFE: 透過簽章 (Sign) 的方式，確保訊息的完整性與來源可靠性。
  • KRB_PRIV: 透過加密 (Encrypt) 的方式，確保訊息在傳輸過程中的機密性。
  • KRB_CRED: 用於在不同主機間安全地轉發或代理使用者的憑證。

總結來說，Kerberos 透過一個可信賴的第三方 KDC 和票據機制，成功地解決了在分散式環境中進行安全身分驗證的難題，是當代網路安全基礎設施中不可或缺的一環。

參考資料

  • RFC 4120 - The Kerberos Network Authentication Service (V5)
  • RFC 4121 - The Kerberos Version 5 GSS-API Mechanism

也許你也會想看看