圖解Kerberos原理

整體流程

參與的關鍵角色

整體流程的介紹中，關於用戶身份認證與服務授權都用“系統”這個抽象角色描述的。但實際上，用戶身份認證與服務授權都是不同的服務角色提供的。參與的各方角色包括：

• Client: Application Client 應用客戶端
• AS: Authentication Server 用來認證用戶身份
• TGS: Ticket-Granting Service 用來授權服務訪問
• SS: Service Server 用戶所請求的服務

1. 用戶登錄

• 用戶登錄階段，通常由用戶輸入[用戶名]和[密碼]信息。
• 在客戶端側，用戶輸入的[密碼]信息被通過一個單向Hash函數生成一個[Client密鑰]。

2. 請求身份認證
2.1 客戶端向AS發送認證請求

• 客戶端爲執行登錄操作的用戶向AS發送認證請求
• 請求中帶有[用戶名]信息，用戶名以明文形式發送到客戶端。

Note
Client往AS發送認證請求時並未發送[密碼]或[密鑰]信息

2.2 AS確認Client端登錄者用戶身份

1. AS收到用戶認證請求之後，根據請求中的[用戶名]信息，從數據庫中查找該用戶名是否存在。
2. 如果[用戶名]存在，則對應的[密碼]也可以從數據庫中獲取到。AS利用相同的單向Hash函數爲[密碼]生成一個祕鑰，如果第1步中用戶提供的[密碼]信息正確，該祕鑰與用戶登錄章節中的[Client密鑰]相同。
3. AS爲Client響應如下消息：
   1. Msg A 使用[Client密鑰]加密的[Client/TGS SessionKey]
   2. Msg B 使用[TGS密鑰]加密的TGT(Ticket-Granting-Ticket)，因此該消息Client不可解析。
      TGT中包含如下信息：
      1. [Client/TGS SessionKey]
      2. Client ID
      3. Ticket有效時間
      4. Client網絡地址
4. Client收到AS的響應消息以後，利用自身的[Client密鑰]可以對Msg A進行解密，這樣可以獲取到[Client/TGSSessionKey]。但由於Msg B是使用[TGS密鑰]加密的，Client無法對其解密。

Note

1.AS響應的消息中有一條是屬於Client的，但另外一條卻屬於TGS。 Client/TGS
2.SessionKey出現了兩個Copy，一個給Client端，一個給TGS端。
3. 本文中提及的加密，如無特殊說明，均採用的是對稱加密算法。

3. 請求服務授權
3.1 客戶端向TGS發送請求服務授權請求

客戶端發送的請求中包含如下兩個消息：

• Msg C
  • 要請求的服務ID, 即[Service ID]
  • 上一步2.2中由AS爲Client提供的TGT。
• Msg D
  • 使用[Client/TGS SessionKey]加密的Authenticator 1 {Client ID, Timestamp}。

3.2 TGS爲Client響應服務授權票據

TGS爲Client響應的消息包括

• Msg E 使用[Service密鑰]加密的Client-To-Server Ticket, 該Ticket中包含了如下信息:

  • [Client/Server SessionKey]
  • Client網絡地址
  • Ticket有效時間
  • Client ID

• Msg F

  • 使用[Client/TGS SessionKey]加密的[Client/ServerSessionKey]。

MsgF使用了[Client/TGSSessionKey]加密，因此，該消息對Client可見。Client對其解密以後可獲取到[Client/ServerSessionKey]。

4. 發送服務請求
4.1 Client向SS(Service Server)發送服務請求

發送的消息中包括：

• Msg E 上一步3.2中，TGS爲Client響應的消息Msg E。該消息可以理解爲由Client爲SS攜帶的消息。

• Msg G 由[Client/Server SessionKey]加密的Authenticator 2，包含{Client ID,Timestamp}信息。 這裏的Authenticator 2區別於前面3.1步驟中的Authenticator 1。

Note

1. [Client/Server SessionKey]並未直接透明傳輸，而是被包含在使用[Service密鑰]加密的Msg E中。
2. 既然[Client/Server SessionKey]並不直接透明傳輸，Client需要向SS證明自己擁有正確的[Client/Server SessionKey]，所以，Authenticator 2使用了[Client/Server SessionKey]加密。

4.2 SS響應Client

SS收到客戶端的服務請求之後，先利用自身的[Service密鑰]對Msg E進行解密，提取出Client-To-Server Ticket, 在3.2步驟中，提到了該Ticket中包含了[Client/Server SessionKey]以及Client ID信息。
SS使用[Client/Server SessionKey]解密Msg G，提取Client ID信息，而後將該Client ID與Client-To-Server Ticket中的Client ID進行比對，如果匹配則說明Client擁有正確的[Client/Server SessionKey]。
而後，SS向Client響應Msg H(包含使用[Client/Server SessionKey]加密的Timestamp信息)。
Client收到SS的響應消息Msg H之後，再使用[Client/Server SessionKey]對其解密，提取Timestamp信息，然後確認該信息與Client發送的Authenticator 2中的Timestamp信息一致。
如上信息可以看出來，該交互過程起到了Client與SS之間的“雙向認證”作用