Kerberos 入門實戰(1)--Kerberos 基本原理


Kerberos 是一種由 MIT(麻省理工大學)提出的網絡身份驗證協議,它旨在通過使用密鑰加密技術為客戶端和服務器應用程序提供強身份驗證,本文主要介紹 Kerberos 的基本原理。

1、Kerberos 是什么

Kerberos 一詞取自於古希臘神話中的 Cerberus(刻耳柏洛斯),它是 Hades(哈迪斯)的一條凶猛的三頭保衛神犬:

Kerberos 是一種基於加密 Ticket 的身份認證協議,主要由三個部分組成:Key Distribution Center (即KDC)、Client 和 Service:

客戶端會先訪問兩次 KDC,然后再訪問目標服務,如:HTTP 服務、Zookeeper 服務、Kafka 服務等。

2、Kerberos 基本概念

2.1、Principal

Principal 可以認為是 Kerberos 世界的用戶名,用於標識身份。principal 主要由三部分構成:primary,instance(可選) 和 realm。包含 instance 的 principal,一般會作為 server 端的 principal,如:Zookeeper,NameNode,HiverServer 等;不含有 instance 的 principal,一般會作為客戶端的 principal,用於身份認證。例子如下圖所示: 

2.2、Keytab

相當於“密碼本”,包含了多個 principal 與密碼的文件,用戶可以利用該文件進行身份認證。

2.3、Ticket Cache

客戶端與 KDC 交互完成后,包含身份認證信息的文件,短期有效,需要不斷renew。

2.4、Realm

Kerberos 中的一個 namespace,不同 Kerberos 環境,可以通過 realm 進行區分。

2.5、KDC

Key Distribution Center,是 Kerberos 的核心組件,主要由三個部分組成:

Kerberos Database: 包含了一個 Realm 中所有的 principal、密碼與其他信息;默認是 Berkeley DB。
Authentication Server(AS): 進行用戶信息認證,為客戶端提供 Ticket Granting Tickets(TGT)。
Ticket Granting Server(TGS): 驗證 TGT 與 Authenticator,為客戶端提供 Service Tickets。

3、Kerberos 基本原理

1.客戶端與 AS 或 TGS 交互,都將獲取到兩條信息,其中一條可以解密,另外一條無法解密。
2.客戶端想要訪問目標服務不會直接與 KDC 交互。
3.KDC Database 包含有所有客戶端和服務的密碼。
4.密鑰是密碼加 salt 后經過哈希處理后得到的。密鑰是由管理員生成的,並分發到客戶端和服務。
5.KDC 本身使用主密鑰進行加密,以增加從數據庫中竊取密鑰的難度。
6.Kerberos 中信息加密方式一般是對稱加密,也可使用成非對稱加密。

4、Kerberos 認證過程

這里以客戶端訪問 HTTP 服務為例,解釋整個認證過程。

4.1、客戶端與 Authentication Server

客戶端發送包含自身信息的明文消息給 AS,消息包含如下信息:

  • your name/ID
  • the name/ID of the requested service (in this case, service is the Ticket Granting Server)
  • your network address (may be a list of IP addresses for multiple machines, or may be null if wanting to use on any machine)
  • requested lifetime for the validity of the TGT

AS 檢查客戶端 ID 是否在 KDC 數據庫中。

如果 AS 檢查沒有異常(用戶不存在會報異常),那么 KDC 將隨機生成一個 Session Key,用於客戶端與 Ticket Granting Server(TGS) 通信。隨后 AS 將發送兩條信息給客戶端。一條消息是由客戶端密鑰加密,包含如下信息:

  • the HTTP service name/ID
  • timestamp
  • lifetime (same as above)
  • TGS Session Key

另一條消息是 TGT,由 TGS 的密鑰加密,包含如下信息:

  • your name/ID
  • the HTTP service name/ID
  • timestamp
  • your network address (may be a list of IP addresses for multiple machines, or may be null if wanting to use on any machine)
  • lifetime of the TGT (could be what you initially requested, lower if you or the TGS’s secret keys are about to expire, or another limit that was implemented during the Kerberos setup)
  • TGS Session Key

客戶端收到 AS 發來的消息后,利用本地的密鑰解密第一條信息,並獲得 TGS Session Key;如果本地密鑰無法解密消息,那么認證失敗。

 

客戶端無法解密 TGT,它會被保存在認證緩存中。

4.2、客戶端與 Ticket Granting Server

客戶端發送如下信息給 TGS:

1.一條明文消息,包含如下信息:

  • the requested HTTP Service name/ID you want access to
  • lifetime of the Ticket for the HTTP Service

2.使用 TGS Session Key 加密的 Authenticator,包含如下信息:

  • your name/ID, and
  • timestamp.

3.TGT

TGS 檢查 HTTP 服務 ID 是否在 KDC 數據庫中。

TGS 檢查沒問題后,利用自身的密鑰從 TGT 中解密出 TGS Session Key,然后利用 TGS Session Key 從 Authenticator 中解密出客戶端的信息。

然后 TGS 做以下檢查:

  • compare your client ID from the Authenticator to that of the TGT
  • compare the timestamp from the Authenticator to that of the TGT (typical Kerberos-system tolerance of difference is 2 minutes, but can be configured otherwise)
  • check to see if the TGT is expired (the lifetime element)
  • check that the Authenticator is not already in the TGS’s cache (for avoiding replay attacks)
  • if the network address in the original request is not null, compares the source’s IP address to your network address (or within the requested list) within the TGT

所有檢查都通過后,TGS 隨機生成一個 HTTP Service Session Key,用於后續客戶端與 HTTP Service 通信。同樣地,TGS 將發送兩條信息給客戶端,一條消息是由 TGS Session Key 加密,包含如下信息:

  • HTTP Service name/ID
  • timestamp
  • lifetime of the validity of the ticket,
  • HTTP Service Session Key

另一條消息是 HTTP Service Ticket,由 HTTP Service 的密鑰加密,包含如下信息:

  • your name/ID
  • HTTP Service name/ID
  • your network address (may be a list of IP addresses for multiple machines, or may be null if wanting to use on any machine)
  • timestamp
  • lifetime of the validity of the ticket
  • HTTP Service Session Key

 客戶端收到消息后,利用 TGS Session Key 解密出第一條信息獲得 HTTP Service Session Key,另一條信息是由目標 HTTP Service 密鑰加密,無法解密。

4.3 客戶端與 HTTP Service

客戶端發送如下信息給 HTTP Service:

1.HTTP Service Ticket

2.用 HTTP Service Session Key 加密的 Authenticator,包含如下信息:

  • your name/ID
  • timestamp

HTTP Service 利用自身的密鑰從 HTTP Service Ticket 中解密出 HTTP Service Session Key,然后利用 HTTP Service Session Key 從 Authenticator 中解密出客戶端的信息。

 

 然后 HTTP Service 做以下檢查:

  • compares your client ID from the Authenticator to that of the Ticket
  • compares the timestamp from the Authenticator to that of the Ticket (typical Kerberos-system tolerance of difference is 2 minutes, but can be configured otherwise)
  • checks to see if the Ticket is expired (the lifetime element),
  • checks that the Authenticator is not already in the HTTP Server’s cache (for avoiding replay attacks)
  • if the network address in the original request is not null, compares the source’s IP address to your network address (or within the requested list) within the Ticket

檢查沒問題后,HTTP Service 會發送一條由 HTTP Service Session Key 加密的消息給客戶端,包含如下信息

  • HTTP Service ID
  • timestamp

客戶端使用緩存的 HTTP Service Session Key 解密出消息,且消息必須包含 HTTP Service ID 和 timestamp。

客戶端驗證消息沒問題后,至此,客戶端即與HTTP Service完成了身份認證;后續將使用緩存的 HTTP Service Ticket 來通信,直到 Ticket 過期。

5、Kerberos 的優勢

1.密碼無需進行網絡傳輸;基於 Ticket 實現身份認證,保障密鑰安全性。
2.雙向認證;整個認證過程中,不僅需要客戶端進行認證,待訪問的服務也需要進行身份認證。
3.高性能;一旦 Client 獲得訪問某個 Service 所需的 Ticket,該 Service 就能根據這個 Ticket 實現對 Client 的驗證,而無須 KDC 的再次參與。

 

參考:
1.https://zhuanlan.zhihu.com/p/266491528
2.https://www.roguelynn.com/words/explain-like-im-5-kerberos


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM