1. Kerberos簡介
1.1. 功能
一個安全認證協(xié)議
用tickets驗證
避免本地保存密碼和在互聯(lián)網(wǎng)上傳輸密碼
包含一個可信任的第三方
使用對稱加密
客戶端與服務(wù)器(非KDC)之間能夠相互驗證
Kerberos只提供一種功能——在網(wǎng)絡(luò)上安全的完成用戶的身份驗證。它并不提供授權(quán)功能或者審計功能。
1.2. 概念
首次請求,三次通信方
- the Authentication Server
- the Ticket Granting Server
- the Service or host machine that you’re wanting access to.
圖 1‑1 角色
其他知識點
- 每次通信,消息包含兩部分,一部分可解碼,一部分不可解碼
- 服務(wù)端不會直接有KDC通信
- KDC保存所有機器的賬戶名和密碼
- KDC本身具有一個密碼
2. 3次通信

我們這里已獲取服務(wù)器中的一張表(數(shù)據(jù))的服務(wù)以為,為一個http服務(wù)。
2.1. 你和驗證服務(wù)
如果想要獲取http服務(wù),你首先要向KDC表名你自己的身份。這個過程可以在你的程序啟動時進行。Kerberos可以通過kinit獲取。介紹自己通過未加密的信息發(fā)送至KDC獲取Ticket Granting Ticket (TGT)。
(1)信息包含
Authentication Server收到你的請求后,會去數(shù)據(jù)庫中驗證,你是否存在。注意,僅僅是驗證是否存在,不會驗證對錯。
如果存在,Authentication Server會產(chǎn)生一個隨機的Session key(可以是一個64位的字符串)。這個key用于你和Ticket Granting Server (TGS)之間通信。
(2)回送信息
Authentication Server同樣會發(fā)送兩部分信息給你,一部分信息為TGT,通過KDC自己的密碼進行加密,包含:
- 你的name/ID
- TGS的name/ID
- 時間戳
- 你的IP地址
- TGT的生命周期
- TGS session key
另外一部分通過你的密碼進行加密,包含的信息有
- TGS的name/ID
- 時間戳
- 生命周期
- TGS session key

圖 2‑1 第一次通信
如果你的密碼是正確的,你就能解密第二部分信息,獲取到TGS session key。如果,密碼不正確,無法解密,則認證失敗。第一部分信息TGT,你是無法解密的,但需要展示緩存起來。
2.2. 你和TGS
如果第一部分你已經(jīng)成功,你已經(jīng)擁有無法解密的TGT和一個TGS Session Key。
(1) 請求信息
a) 通過TGS Session Key加密的認證器部分:
b) 明文傳輸部分:
- 請求的Http服務(wù)名(就是請求信息)
- HTTP Service的Ticket生命周期
c) TGT部分
Ticket Granting Server收到信息后,首先檢查數(shù)據(jù)庫中是否包含有你請求的Http服務(wù)名。如果無,直接返回錯誤信息。
如果存在,則通過KDC的密碼解密TGT,這個時候。我們就能獲取到TGS Session key。然后,通過TGS Session key去解密你傳輸?shù)牡谝徊糠终J證器,獲取到你的用戶名和時間戳。
TGS再進行驗證:
- 對比TGT中的用戶名與認證器中的用戶名
- 比較時間戳(網(wǎng)上有說認證器中的時間錯和TGT中的時間錯,個人覺得應(yīng)該是認證器中的時間戳和系統(tǒng)的時間戳),不能超過一定范圍
- 檢查是否過期
- 檢查IP地址是否一致
- 檢查認證器是否已在TGS緩存中(避免應(yīng)答攻擊)
- 可以在這部分添加權(quán)限認證服務(wù)
TGS隨機產(chǎn)生一個Http Service Session Key, 同時準備Http Service Ticket(ST)。
(2) 回答信息
a) 通過Http服務(wù)的密碼進行加密的信息(ST):
- 你的name/ID
- Http服務(wù)name/ID
- 你的IP地址
- 時間戳
- ST的生命周期
- Http Service Session Key
b) 通過TGS Session Key加密的信息
- Http服務(wù)name/ID
- 時間戳
- ST的生命周期
- Http Service Session Key
你收到信息后,通過TGS Session Key解密,獲取到了Http Service Session Key,但是你無法解密ST。

圖 2‑2 第二次通信
2.3. 你和Http服務(wù)
在前面兩步成功后,以后每次獲取Http服務(wù),在Ticket沒有過期,或者無更新的情況下,都可直接進行這一步。省略前面兩個步驟。
(1) 請求信息
a) 通過Http Service Session Key,加密部分
b) ST
Http服務(wù)端通過自己的密碼解壓ST(KDC是用Http服務(wù)的密碼加密的),這樣就能夠獲取到Http Service Session Key,解密第一部分。
服務(wù)端解密好ST后,進行檢查
- 對比ST中的用戶名(KDC給的)與認證器中的用戶名
- 比較時間戳(網(wǎng)上有說認證器中的時間錯和TGT中的時間錯,個人覺得應(yīng)該是認證器中的時間戳和系統(tǒng)的時間戳),不能超過一定范圍
- 檢查是否過期
- 檢查IP地址是否一致
- 檢查認證器是否已在HTTP服務(wù)端的緩存中(避免應(yīng)答攻擊)
(2) 應(yīng)答信息
a) 通過Http Service Session Key加密的信息

圖 2‑3 第三次通信
你在通過緩存的Http Service Session Key解密這部分信息,然后驗證是否是你想要的服務(wù)器發(fā)送給你的信息。完成你的服務(wù)器的驗證。
至此,整個過程全部完成。
posted on 2017-04-25 15:56
xzc 閱讀(256)
評論(2) 編輯 收藏 所屬分類:
Java 、
linux/unix 、
hadoop