簡言
Kerberos協議是一個專注於驗證通信雙方身份的網絡協議，不同於其他網絡安全協議的保證整個通信過程的傳輸安全，kerberos側重於通信前雙方身份的認定工作，幫助客戶端和服務端解決“證明我自己是我自己”的
什麼是Kerberos協議
kerberos是一種計算機網絡認證協議，他能夠爲網絡中通信的雙方提供嚴格的身份驗證服務，確保通信雙方身份的真實性和安全性。不同於其他網絡服務，kerberos協議中不是所有的客戶端向想要訪問的網絡服務
發起請求，他就能夠建立連接然後進行加密通信。而是在發起服務請求後必須先進行一系列的身份認證，包括客戶端和服務端兩方的雙向認證，只有當通信雙方都認證通過對方身份之後，纔可以互相建立起連接，
進行網絡通信。即kerberos協議的側重在於認證通信雙方的身份，客戶端需要確認即將訪問的網絡服務就是自己所想要訪問的服務而不是一個僞造的服務器，而服務端需要確認這個客戶端是一個身份真實，安全可
靠的客戶端，而不是一個想要進行惡意網絡攻擊的用戶。本文將詳細概述kerberos認證原理，講述通信雙方是如何一步步確認對方身份完成認證的。
Kerberos協議的組成角色
在古希臘神話故事中，kerberos是一隻具有三顆頭顱的地獄惡犬，他守護在地獄之外，能夠識別所有經此路過的亡靈，防止活着的入侵者闖入地獄。而真正的kerberos協議中也存在三個角色，分別是
客戶端（client）：發送請求的一方
服務端（Server）：接收請求的一方
密鑰分發中心（Key Distribution Center，KDC），而密鑰分發中心一般又分爲兩部分，分別是：
AS（Authentication Server）：認證服務器，專門用來認證客戶端的身份併發放客戶用於訪問TGS的TGT（票據授予票據）
TGS（Ticket Granting Ticket）：票據授予服務器，用來發放整個認證過程以及客戶端訪問服務端時所需的服務授予票據（Ticket）
在整個kerberos認證過程中，三個角色缺一不可，下面便來介紹一下整個kerberos的認證原理~
Kerberos認證解決”如何證明我就是我的問題“
上面說到了kerberos協議當中總共有三個不同的角色，客戶端和服務端就不用多說了，一個是請求的發起者一個是請求的接收者，那麼KDC是做什麼的呢？答案是這樣的~
在kerberos協議中，通信的雙方在通信之前必須相互證明自己的身份是可靠並且具有訪問權限的（後面會說爲什麼是要具有訪問權限的），那麼雙方都要如何證明自己呢？口說無憑，客戶端的請求中攜帶自己的身份
信息直接給服務端，服務端是沒有理由直接信任這段信息就是真實的信息的，同理，服務端返回自己的身份信息給客戶端，客戶端也同樣是無法辨別該服務器是否是自己想要訪問的服務器。
舉個例子，A現在想要去訪問B完成一個任務。但是AB兩人之間是從來沒有見過面的，他們只知道對方的名字叫A，B。此時如果A直接去找B告訴B我就是A，那麼B是有理由不相信A的，因爲即使A是一個冒充的他也分辨不
清，B同理也得不到A的認可，他們陷入了一個無
法證明我就是我的困境。於是他們就想到了一個辦法，AB找到了一個他倆共同信任的人C，且這個C既認識A又認識B，所以只要C告訴B，這個A確實就是真正的A那麼B就會
信任這個A，同理B經過C的認可後，A也會相信B的身份。
此後，A在訪問B之前會先去找C，C會交給A一個憑證，代表此時的A已經得到了C的認證，這時A拿着憑證再去找C，便可以得到C的確認了。
在上面的例子中，A，B分別是客戶端和服務端，C擔任的角色便是KDC，全稱Key Distribution Center，中文名叫做密鑰分發中心。KDC中包含一個叫做TGS（票據授予中心）的組件，我們便可以理解爲他就是一個發放
身份認證票據的服務中心，在KDC認證了（其實是KDC中的AS認證的）客戶端的身份後，他會給客戶端發放用於訪問網絡服務的服務授予票據（Ticket）。由於整個kerberos通信過程都採用對稱加密的方式，密鑰的獲取也是從KDC中得
到，所以KDC叫做密鑰分發中心。
所以整個kerberos認證流程可以簡化描述如下：
客戶端在訪問每個想要訪問的網絡服務時，他需要攜帶一個專門用於訪問該服務並且能夠證明自己身份的票據，當服務端收到了該票據他才能認定客戶端身份正確，向客戶端提供服務。所以整個認證流程可簡化爲兩大步：
客戶端向KDC請求獲取想要訪問的目標服務的服務授予票據（Ticket）；
客戶端拿着從KDC獲取的服務授予票據（Ticket）訪問相應的網絡服務；
簡化認證流程圖：
Kerberos認證流程
上面說到了簡化版的Kerberos認證流程，基本上分爲兩步。第一步，客戶端向KDC請求獲得他想要訪問的服務的服務授予票據（可以想象成去動物園，想去買一張能夠進入動物園的門票）。第二步，拿着這張服務授予票據（Ticket）去訪問服務端的服務。
大致的過程確實可以看作這兩步，但其中還存在一些問題：
問題1. KDC怎麼知道你（客戶端）就是真正的客戶端？憑什麼給你發放服務授予票據（Ticket）呢？
問題2. 服務端怎麼知道你帶來的服務授予票據（Ticket）就是一張真正的票據呢？
這就需要開始細節的描述一下整個Kerberos認證的過程了~
上面提到整個流程可以簡化爲兩大步，但其實在第一步中共做了兩件事，這兩件事解決了上述問題中的問題1；然後第二步解決了問題2，最終結束認證過程建立通信。所以整個Kerberos認證流程可以細化爲三個階段也可以
理解爲三次通信!接下來從三個階段三次通信的角度細說認證過程。
在具體描述整個認證流程之前，我們需要知道幾個Kerberos認證的前提條件：
kerberos協議他是一個“限權”的認證協議，kerberos中會自帶一個數據庫，這個數據庫會由創建kerberos的運維人員提前在庫中添加好整個系統中擁有使用kerberos認證權限的用戶和網絡服務。在後續的認證中也是根據數據庫中是否存在該用戶和服務來判斷該對象是否能夠通過認證服務的。（拿上面的例子來說就是上帝先讓C在AB相識之前同時認識A和B，以便後面幫助AB互相認證）
所有使用kerberos協議的用戶和網絡服務，在他們添加進kerberos系統中時，都會根據自己當前的密碼（用戶密碼，人爲對網絡服務隨機生成的密碼）生成一把密鑰存儲在kerberos數據庫中，且kerberos數據庫也會同時保存用戶的基本信息（例如用戶名，用戶IP地址等）和網絡服務的基本信息（IP，Server Name）
kerberos中存在的三個角色，只要是發生了兩兩之間的通信，那麼都需要先進行身份的認證
第一次通信
爲了獲得能夠用來訪問服務端服務的票據，客戶端首先需要來到KDC獲得服務授予票據（Ticket）。由於客戶端是第一次訪問KDC，此時KDC也不確定該客戶端的身份，所以第一次通信的目的爲KDC認證客戶端身份，確認客戶端是一個可靠且擁有訪問KDC權限的客戶端，過程如下：
① 客戶端用戶向KDC以明文的方式發起請求。該次請求中攜帶了自己的用戶名，主機IP，和當前時間戳；
② KDC當中的AS（Authentication Server）接收請求（AS是KDC中專門用來認證客戶端身份的認證服務器）後去kerberos認證數據庫中根據用戶名查找是否存在該用戶，此時只會查找是否有相同用戶名的用戶，並不會判斷身份的可靠性；
③ 如果沒有該用戶名，認證失敗，服務結束；如果存在該用戶名，則AS認證中心便認爲用戶存在，此時便會返回響應給客戶端，其中包含兩部分內容：
第一部分內容稱爲TGT，他叫做票據授予票據，客戶端需要使用TGT去KDC中的TGS（票據授予中心）獲取訪問網絡服務所需的Ticket（服務授予票據），TGT中包含的內容有kerberos數據庫中存在的該客戶端的Name，IP，當前時間戳，客戶端
即將訪問的TGS的Name，TGT的有效時間以及一把用於客戶端和TGS間進行通信的Session_key(CT_SK)。整個TGT使用TGS密鑰加密，客戶端是解密不了的，由於密鑰從沒有在網絡中傳輸過，所以也不存在密鑰被劫持破解的情況。
第二部分內容是使用客戶端密鑰加密的一段內容，其中包括用於客戶端和TGS間通信的Session_key(CT_SK),客戶端即將訪問的TGS的Name以及TGT的有效時間，和一個當前時間戳。該部分內容使用客戶端密鑰加密，所以客戶端在拿到該部分內容時可以通過自己的密鑰解密。如果是一個假的客戶端，那麼他是不會擁有真正客戶端的密鑰的，因爲該密鑰也從沒在網絡中進行傳輸過。這也同時認證了客戶端的身份，如果是假客戶端會由於解密失敗從而終端認證流程。
至此，第一次通信完成。
第二次通信
此時的客戶端收到了來自KDC（其實是AS）的響應，並獲取到了其中的兩部分內容。此時客戶端會用自己的密鑰將第二部分內容進行解密，分別獲得時間戳，自己將要訪問的TGS的信息，和用於與TGS通信時的密鑰CT_SK。首先他會根據時間戳判斷該時間戳與自己發送請求時的時間之間的差值是否大於5分鐘，如果大於五分鐘則認爲該AS是僞造的，認證至此失敗。如果時間戳合理，客戶端便準備向TGS發起請求，
其次請求的主要目的是爲了獲取能夠訪問目標網絡服務的服務授予票據Ticket（進入動物園需要的門票）。 在第二次通信請求中，客戶端將攜帶三部分內容交給KDc中的TGS，第二次通信過程具體如下所述：
客戶端行爲：
① 客戶端使用CT_SK加密將自己的客戶端信息發送給KDC，其中包括客戶端名，IP，時間戳；
② 客戶端將自己想要訪問的Server服務以明文的方式發送給KDC；
③ 客戶端將使用TGS密鑰加密的TGT也原封不動的也攜帶給KDC；
TGS行爲：
① 此時KDC中的TGS（票據授予服務器）收到了來自客戶端的請求。他首先根據客戶端明文傳輸過來的Server服務IP查看當前kerberos系統中是否存在可以被用戶訪問的該服務。如果不存在，認證失敗結束，。如果存在，繼續接下來的認證。
② TGS使用自己的密鑰將TGT中的內容進行解密，此時他看到了經過AS認證過後並記錄的用戶信息，一把Session_KEY即CT_SK，還有時間戳信息，他會現根據時間戳判斷此次通信是否真是可靠有無超出時延。
③ 如果時延正常，則TGS會使用CK_SK對客戶端的第一部分內容進行解密（使用CT_SK加密的客戶端信息），取出其中的用戶信息和TGT中的用戶信息進行比對，如果全部相同則認爲客戶端身份正確，方可繼續進行下一步。
④ 此時KDC將返回響應給客戶端，響應內容包括：
第一部分：用於客戶端訪問網絡服務的使用Server密碼加密的ST（Servre Ticket），其中包括客戶端的Name，IP，需要訪問的網絡服務的地址Server IP，ST的有效時間，時間戳以及用於客戶端和服務端之間通信的CS_SK（Session Key）。
第二部分：使用CT_SK加密的內容，其中包括CS_SK和時間戳，還有ST的有效時間。由於在第一次通信的過程中，AS已將CT_SK通過客戶端密碼加密交給了客戶端，且客戶端解密並緩存了CT_SK，所以該部分內容在客戶端接收到時是可以自己解密的。
至此，第二次通信完成。
第三次通信
此時的客戶端收到了來自KDC（TGS）的響應，並使用緩存在本地的CT_SK解密了第二部分內容（第一部分內容中的ST是由Server密碼加密的，客戶端無法解密），檢查時間戳無誤後取出其中的CS_SK準備向服務端發起最後的請求。
客戶端：
① 客戶端使用CK_SK將自己的主機信息和時間戳進行加密作爲交給服務端的第一部分內容，然後將ST（服務授予票據）作爲第二部分內容都發送給服務端。
服務端：
① 服務器此時收到了來自客戶端的請求，他會使用自己的密鑰，即Server密鑰將客戶端第二部分內容進行解密，覈對時間戳之後將其中的CS_SK取出，使用CS_SK將客戶端發來的第一部分內容進行解密，從而獲得經過TGS認證過後的客戶端信息，此時他將這部分信息和客戶端第二部分內容帶來的自己的信息進行比對，最終確認該客戶端就是經過了KDC認證的具有真實身份的客戶端，是他可以提供服務的客戶端。此時服務端返回一段使用CT_SK加密的表示接收請求的響應給客戶端，在客戶端收到請求之後，使用緩存在本地的CS_ST解密之後也確定了服務端的身份（其實服務端在通信的過程中還會使用數字證書證明自己身份）。
至此，第三次通信完成。此時也代表着整個kerberos認證的完成，通信的雙方都確認了對方的身份，此時便可以放心的進行整個網絡通信了。
總結
整個kerberos認證的過程較爲複雜，三次通信中都使用了密鑰，且密鑰的種類一直在變化，並且爲了防止網絡攔截密鑰，這些密鑰都是臨時生成的Session Key，即他們只在一次Session會話中起作用，即使密鑰被劫持，等到密鑰被破解可能這次會話都早已結束。
這爲整個kerberos認證過程保證了較高的安全性。以下補充兩個kerberos認證的整體流圖，一個是kerberos認證的時序圖，一個是kerberos認證的示意圖，望能加深kerberos認證印象~~
示意圖：
————————————————
原文鏈接：https://blog.csdn.net/weixin_38233104/article/details/122963237