Kerberos認證流程詳解
阿新 • • 發佈：2019-02-19
Kerberos是誕生於上個世紀90年代的計算機認證協議，被廣泛應用於各大作業系統和Hadoop生態系統中。瞭解Kerberos認證的流程將有助於解決Hadoop叢集中的安全配置過程中的問題。為此，本文根據最近閱讀的一些材料，詳細介紹Kerberos認證流程。歡迎斧正！
因此，在Kerberos系統中至少有三個角色：認證伺服器（AS），客戶端（Client）和普通伺服器（Server）。客戶端和伺服器將在AS的幫助下完成相互認證。
在Kerberos系統中，客戶端和伺服器都有一個唯一的名字，叫做Principal。同時，客戶端和伺服器都有自己的密碼，並且它們的密碼只有自己和認證伺服器AS知道。
1. 你帶好身份證和相應的材料去派出所，向JCSS說明你要辦居住證，需要開據相應的證明。
2. JCSS根據他們的內部系統，核實了你提供的材料並開據了證明，上面蓋有派出所的紅章。
3. 你再拿著這個證明再去社群事務中心，社群事務中心的工作人員看到了JCSS提供的證明，就可以確定你的身份，便開始給你辦理業務。
和上面的例子中的流程非常相似，Kerberos的認證流程分成了以下4個步驟，見下圖。
符號說明
其中主要包括當前時間和Ts,c的校驗碼，並且用SessionKey Kc,s加密。
伺服器段可選擇性地給客戶端回覆一條訊息來完成雙向認證，內容如下：
通過以上4個步驟，客戶端和伺服器就完成了雙向認證。隨後，客戶端和伺服器就可以用session key來加密需要傳輸的內容。
現在客戶端初次和伺服器通訊的認證流程分成了以下6個步驟：
注：雖然上圖中把AS和TGS畫成了兩個框，但實現上它們是可以做到一個服務裡面的。
1. 客戶端向AS發起請求，請求內容是：我是誰（客戶端的principal），我要和票據授權服務通訊（TGS的principal）等
2. AS收到請求後，隨機生成一個密碼Session Key(Kc,tgs)，並生成以下兩個Ticket返回給客戶端： Tc,tgs={Kc,tgs; tgs_principal; ...} Kc - 該票據是給客戶端的，大括號裡面為票據中的內容，後面的Kc為客戶端的密碼，表示該票據用客戶端的密碼加密了。 Ttgs,c={Kc,tgs; client_principal;...} Ktgs - 該票據是給TGS，大括號裡面為票據中的內容，後面的Ktgs為TGS的密碼，表示該票據用TGS的密碼加密了，只有TGS能解開。 上述兩步和上面簡化的認證流程的前兩步是一致的，唯一不一樣的是與客戶端通訊的另一端是票據授權服務(TGS)。該步驟中得到的Tgs,c就類似於例子中的聯票，後面將會通過它來得到一張和其他伺服器通訊認證的票據。
3. 客戶端用自己的密碼解開Tc,tgs，得到Kc,tgs，生成一個Authenticator，並給TGS發起請求，請求內容是包括：
4. TGS收到客戶端傳送的Authenticator和Ttgs,c後，先用自己的密碼解開Ttgs,c，得到SessionKey Kc,tgs，然後解開Authenticator，對客戶端進行認證，這與簡化的認證流程的第4步是一致的。如果客戶端通過了認證，TGS生成一個客戶端和伺服器的SessionKey(Kc,s)，同時將組裝下面兩個票據返回給客戶端：
這是客戶端首次認證的流程，通常客戶端會在第2步的時候把相應的票據儲存下來，在以後客戶端需要認證別的伺服器的時候就不需要前面兩步，直接從第3步開始。
Kerberos解決什麼問題？
簡單地說，Kerberos提供了一種單點登入(SSO)的方法。考慮這樣一個場景，在一個網路中有不同的伺服器，比如，列印伺服器、郵件伺服器和檔案伺服器。這些伺服器都有認證的需求。很自然的，不可能讓每個伺服器自己實現一套認證系統，而是提供一箇中心認證伺服器（AS-Authentication Server）供這些伺服器使用。這樣任何客戶端就只需維護一個密碼就能登入所有伺服器。因此，在Kerberos系統中至少有三個角色：認證伺服器（AS），客戶端（Client）和普通伺服器（Server）。客戶端和伺服器將在AS的幫助下完成相互認證。
在Kerberos系統中，客戶端和伺服器都有一個唯一的名字，叫做Principal。同時，客戶端和伺服器都有自己的密碼，並且它們的密碼只有自己和認證伺服器AS知道。
簡化的Kerberos認證流程
首先來看現實生活中的類似的一個例子。假如你要去社群事務中心去辦理居住證，但是社群事務中心並不能確定你的身份，因此需要你去派出所開據證明，證明你就是你。那麼，通常的流程是這樣的：1. 你帶好身份證和相應的材料去派出所，向JCSS說明你要辦居住證，需要開據相應的證明。
2. JCSS根據他們的內部系統，核實了你提供的材料並開據了證明，上面蓋有派出所的紅章。
3. 你再拿著這個證明再去社群事務中心，社群事務中心的工作人員看到了JCSS提供的證明，就可以確定你的身份，便開始給你辦理業務。
和上面的例子中的流程非常相似，Kerberos的認證流程分成了以下4個步驟，見下圖。
符號說明
- client_principal, server_principal: 分別表示客戶端和伺服器的名字。
- Tc,s: 表示AS發給客戶端c的票據，該票據包含有用於和伺服器s通訊認證的相關資訊。
- {Kc,s; server_principal,...}Kc: 表示票據的內容，{}裡面的為具體內容。Kc為客戶端的密碼，表示該票據由客戶端的密碼加密。其它的類似。
1. 客戶端向伺服器端發起請求，請求的內容是：我是誰（客戶端的principal），我要和誰通訊（伺服器的principal）
2. AS收到請求以後，隨機生成一個密碼Kc,s (Session Key),並且生成了以下兩個票據（Ticket）返回給客戶端：- Tc,s={Kc,s; server_principal,...}Kc - 該票據是給客戶端的，大括號裡面為票據中的內容，後面的Kc為客戶端的密碼，表示該票據用客戶端的密碼加密了。
- Ts,c={Kc,s; client_principal,...}Ks - 大括號裡面為票據中的內容，後面的Ks為伺服器的密碼，表示該票據用伺服器的密碼加密了。該票據是給伺服器的，但是AS並不直接給伺服器，而是交給了客戶端再由客戶端交給伺服器。因為該票據由伺服器的密碼加密了，所以客戶端無法偽造和篡改。
注：Tc,s和Ts,c這兩個符號是本文為了描述方便而引入的，在別的文獻中沒有。
3. 客戶端拿到了第二步中的兩個票據後，首先用自己的密碼解開票據Tc,s得到Kc,s，然後生成一個認證因子(Authenticator),其內容如下：Authenticator: {time_stamp, Ts,c_checksum,...}Kc,s其中主要包括當前時間和Ts,c的校驗碼，並且用SessionKey Kc,s加密。
客戶端將Authenticator和Ts,c同時發給伺服器。
4.伺服器首先用自己的密碼解開Ts,c，拿到SessionKey Kc,s，然後用Kc,s解開Authenticator，並做如下檢查：- 檢查Authenticator中的時間戳是不是在當前時間上下5分鐘以內，並且檢查該時間戳是否首次出現。如果該時間戳不是第一次出現，那說明有人截獲了之前客戶端傳送的內容，進行Replay攻擊。
- 檢查checksum是否正確。
伺服器段可選擇性地給客戶端回覆一條訊息來完成雙向認證，內容如下：
{time_stamp}Kc,s通過以上4個步驟，客戶端和伺服器就完成了雙向認證。隨後，客戶端和伺服器就可以用session key來加密需要傳輸的內容。
完整的Kerberos認證流程
上一節介紹的流程已經能夠完成客戶端和伺服器的相互認證。但是，比較不方便的是每次認證都需要客戶端輸入自己的密碼。如何解決這個問題，我們再來看一個生活中的例子。某些電影院發行聯票，客戶只需在花一次錢買張聯票（在一定期限內可以兌換一定數量的電影票）。在想看電影的時候，只需要出示聯票就可以取一張電影票。這樣的好處一是方便，二是相對安全，因為使用者無需每次買票的時候都出示信用卡，從而減少了暴露密碼的機會。 類似的，在Kerberos系統中，引入了一個新的角色叫做：票據授權服務(TGS - Ticket Granting Service)，它的地位類似於一個普通的伺服器，只是它提供的服務是為客戶端發放用於和其他伺服器認證的票據。 這樣，Kerberos系統中就有四個角色：認證伺服器（AS），客戶端（Client），普通伺服器（Server）和票據授權服務（TGS）。現在客戶端初次和伺服器通訊的認證流程分成了以下6個步驟：
注：雖然上圖中把AS和TGS畫成了兩個框，但實現上它們是可以做到一個服務裡面的。
1. 客戶端向AS發起請求，請求內容是：我是誰（客戶端的principal），我要和票據授權服務通訊（TGS的principal）等
2. AS收到請求後，隨機生成一個密碼Session Key(Kc,tgs)，並生成以下兩個Ticket返回給客戶端： Tc,tgs={Kc,tgs; tgs_principal; ...} Kc - 該票據是給客戶端的，大括號裡面為票據中的內容，後面的Kc為客戶端的密碼，表示該票據用客戶端的密碼加密了。 Ttgs,c={Kc,tgs; client_principal;...} Ktgs - 該票據是給TGS，大括號裡面為票據中的內容，後面的Ktgs為TGS的密碼，表示該票據用TGS的密碼加密了，只有TGS能解開。 上述兩步和上面簡化的認證流程的前兩步是一致的，唯一不一樣的是與客戶端通訊的另一端是票據授權服務(TGS)。該步驟中得到的Tgs,c就類似於例子中的聯票，後面將會通過它來得到一張和其他伺服器通訊認證的票據。
3. 客戶端用自己的密碼解開Tc,tgs，得到Kc,tgs，生成一個Authenticator，並給TGS發起請求，請求內容是包括：
- Authenticator = {time_stamp, checksum, ...}Kc,tgs
- Ttgs,c - 第二步從AS返回的票據
- server_principal, ...
4. TGS收到客戶端傳送的Authenticator和Ttgs,c後，先用自己的密碼解開Ttgs,c，得到SessionKey Kc,tgs，然後解開Authenticator，對客戶端進行認證，這與簡化的認證流程的第4步是一致的。如果客戶端通過了認證，TGS生成一個客戶端和伺服器的SessionKey(Kc,s)，同時將組裝下面兩個票據返回給客戶端：
- Tc,s={Kc,s, server_principal,...}Kc,tgs - 這是給客戶端的票據，Kc,s是客戶端與伺服器之間的SessionKey，用客戶端和TGS之間的SessionKey(Kc,tgs)加密。區別就在這裡了，給客戶端的票據不再用客戶端的密碼加密，而是用客戶端和Tgs之間的SessionKey加密。
- Ts,c={Kc,s, client_principal,...}Ks - 這是給伺服器的票據，用伺服器的密碼加密。
- Authenticator={time_stamp, Ts,c_checksum,...}Kc,s
- Ts,c={Kc,s, client_principal,...}Ks。
{time_stamp}Kc,s這是客戶端首次認證的流程，通常客戶端會在第2步的時候把相應的票據儲存下來，在以後客戶端需要認證別的伺服器的時候就不需要前面兩步，直接從第3步開始。
小結與參考資料
本文詳細介紹了Kerberos的認證流程，瞭解Kerberos的認證流程對配置Hadoop的安全性很有必要。以後有機會再分享Kerberos在Hadoop生態系統中的具體應用。本文主要參考了以下資料：- http://gost.isi.edu/publications/kerberos-neuman-tso.html
- http://blog.sina.com.cn/s/blog_5384e78b0100fhdt.html