Kerberos协议内容详解
這篇幫助文檔是由 Fulvio Ricciardi所寫。原文地址https://kerberos.org/software/tutorial.html，目前翻譯只校對了1-4章
文章目錄
- 1 介紹
- 2 目標
- 3 對象和術語的解釋
- 3.1 Realm
- 3.2 Principal
- 3.3 Ticket
- 3.4 加密 Encryption
- 3.4.1 加密類型 Encryption type
- 3.4.2 加密密鑰 Encryption key
- 3.4.3 Salt
- 3.4.4 密鑰版本號 Key Version Number (kvno)
- 3.5 密鑰分發中心 Key Distribution Center KDC
- 3.5.1 數據庫
- 3.5.2 認證服務器 Authentication Server （AS）
- 3.5.3 ticket授予服務器（TGS）
- 3.6 Session Key
- 3.7 認證者 Authenticator
- 3.8 重放緩存 Replay Cache
- 3.9 憑證緩存 Credential Cache
- 4 Kerberos 的運行方式
- 4.1 Authentication Server Request
- 4.2 Authentication Server Reply
- 4.3 Ticket Granting Server Request (TGS_REQ)
- 4.4 Ticket Granting Server Replay (TGS_REP)
- 4.5 Application Request (AP_REQ)
- 4.6 Pre-Authentication
- 5 詳解Tickets
- 5.1 Initial tickets
- 5.2 Renewable tickets
- 5.3 Forwardable tickets
- 6 交叉認證 Cross Authentication
- 6.1 Direct trust relationships
- 6.2 Transitive trust relationships
- 6.3 Hierarchical trust relationships
1 介紹
Kerberos是一種在不受信任的網絡上給可信任的hosts進行授權認證的協議。
2 目標
在描述構成 Kerberos 身份驗證系統的元素并查看其操作之前，協議希望實現的一些目標如下：
- users的密碼絕不能通過網絡傳播；
- users的密碼絕不能以任何形式存儲在客戶端機器上：使用后必須立即丟棄；
- 即使在認證服務器數據庫中，也不應該以未加密的形式存儲users的密碼；
- 每個工作會話僅要求users輸入一次密碼。因此，users可以透明地訪問他們授權的所有services，而無需在此會話期間重新輸入密碼。此特性稱為單點登錄；
- 認證信息集中管理，存儲在認證服務器上（authentication server）。應用程序服務器不得包含其users的身份驗證信息。這對于獲得以下結果至關重要：
- 管理員可以通過在單個位置操作來禁用任何users的帳戶，而無需在提供各種services的多個應用服務器上操作；
- 當users更改密碼時，所有services同時更改；
- 沒有冗余的認證信息，否則需要在各個地方進行保護；
- 不僅users必須證明他們就是他們所說的人，在被要求時，應用服務器也須向客戶端證明他們的真實性。這個特性被稱為相互認證；
- 身份驗證和授權完成后，如果需要，客戶端和服務器必須能夠建立加密連接。為此，Kerberos 支持生成和交換用于加密數據的加密密鑰。
3 對象和術語的解釋
本節提供對象和術語的定義，這些知識對于 Kerberos 協議的后續描述至關重要。由于許多定義都基于其他定義，因此我盡可能將它們整理好，以便在定義之前不會給出術語的含義。但是，可能需要閱讀本節兩遍才能完全理解所有術語。
3.1 Realm
術語realm表示身份驗證管理域。其目的是建立認證服務器有權認證的users、主機或services的邊界。這并不意味著users和services之間的身份驗證必須屬于同一realm：如果兩個對象屬于不同realm，并且它們之間存在信任關系，則可以進行身份驗證。下面將描述這種稱為交叉認證的特性。
基本上，當且僅當users/services與該realm的認證服務器共享secret（密碼/密鑰）時，該users/services才屬于該realm。
realm的名稱區分大小寫，即大寫和小寫字母之間存在差異，但通常realm總是以大寫字母出現。在組織中，使領域名稱與 DNS 域相同（盡管使用大寫字母）也是一種很好的做法。舉例來說，如果一個組織屬于 DNS 域 example.com，則相關的 Kerberos 領域是EXAMPLE.COM 是合適的。
3.2 Principal
principal是用于指向認證服務器的數據庫中的條目的名稱。principal與給定realm的每個users、主機或services相關聯。Kerberos 5 中的principal具有以下類型：
? component1/component2/…/componentN@REALM
然而，實際上最多使用兩個組件。對于引用users的條目，principal 是以下類型：
? Name[/Instance]@REALM
實例是可選的，通常用于更好地限定users類型。例如，管理員users通常擁有 admin 實例。以下是指代users的principal示例：
? pippo@EXAMPLE.COM admin/admin@EXAMPLE.COM pluto/admin@EXAMPLE.COM
相反，如果條目涉及services，則principal 采用以下形式：
? Service/Hostname@REALM
第一個組件是services的名稱，例如 imap、AFS、ftp。通常用主機host這個詞來表示對機器的一般訪問（telnet、rsh、ssh）。第二個組成部分是提供所請求services的機器的完整主機名 (FQDN)。該組件與應用程序服務器 IP 地址的 DNS 反向解析完全匹配（以小寫字母表示）非常重要。以下是引用services的principal 的有效示例：
? imap/mbox.example.com@EXAMPLE.COM
? host/server.example.com@EXAMPLE.COM
? afs/example.com@EXAMPLE.COM
在 Kerberos 4 中，組件永遠不能超過兩個，并且它們由字符“.”分隔。而不是“/”，而principal 中涉及services的主機名是短的，即不是 FQDN。以下是有效示例：
pippo@EXAMPLE.COM pluto.admin@EXAMPLE.COM imap.mbox@EXAMPLE.COM
3.3 Ticket
Ticket是客戶端提供給應用程序服務器以證明其身份真實性的東西。Ticket由認證服務器頒發，并使用它們所指向的services的密鑰進行加密。由于此密鑰是僅在認證服務器和提供services的服務器之間共享的secret，因此即使是請求ticket的客戶端也無法知道或更改其內容。ticket中包含的主要信息包括：
- 請求users的principal （通常是users名）；
- 它所針對的services的principal ；
- 可以使用ticket的客戶端計算機的 IP 地址。在 Kerberos 5 中，此字段是可選的，也可以是多個字段，以便能夠在 NAT 或多宿主下運行客戶端。
- ticket有效期開始的日期和時間（時間戳格式）；
- ticket的最長有效期
- 會話密鑰 Session Key；
每張ticket都有一個有效期（通常為 10 小時）。這是必不可少的，因為認證服務器不再對已發出的ticket有任何控制權。盡管realm管理員可以隨時阻止為某個users發行ticket，但它不能阻止users使用他們已經擁有的ticket。這就是限制ticket的生命周期以限制任何濫用的原因。
ticket包含許多其他信息和標志來表征他們的行為，但我們不會在這里討論。在看到身份驗證系統的工作原理后，我們將再次討論ticket和標志。
3.4 加密 Encryption
正如您所看到的，Kerberos 通常需要加密和解密在授權過程中的各個參與者之間傳遞的消息（ticket和authenticators）。需要注意的是，Kerberos 僅使用對稱密鑰加密（換句話說，使用相同的密鑰進行加密和解密）。某些項目（例如 pkinit）正在積極引入公鑰系統，以便通過提供與認證公鑰對應的私鑰來獲得初始users身份驗證，但由于沒有標準，我們現在將跳過此討論.
3.4.1 加密類型 Encryption type
Kerberos 4 實現了一種單一類型的加密，即 56 位的DES。The weakness of this encryption plus other protocol vulnerabilities have made Kerberos 4 obsolete. Version 5 of Kerberos, however, does not predetermine the number or type of encryption methodologies supported. It is the task of each specific implementation to support and best negotiate the various types of encryption. However, this flexibility and expandability of the protocol has accentuated interoperability problems between the various implementations of Kerberos 5. In order for clients and application and authentication servers using different implementations to interoperate, they must have at least one encryption type in common. The difficulty related to the interoperability between Unix implementations of Kerberos 5 and the one present in the Active Directory of Windows is a classic example of this. Indeed, Windows Active Directory supports a limited number of encryptions and only had DES at 56 bits in common with Unix. This required keeping the latter enabled, despite the risks being well known, if interoperability had to be guaranteed. The problem was subsequently solved with version 1.3 of MIT Kerberos 5. This version introduced RC4-HMAC support, which is also present in Windows and is more secure than DES. Among the supported encryptions (but not by Windows) the triple DES (3DES) and newer AES128 and AES256 are worth mentioning.
3.4.2 加密密鑰 Encryption key
如上所述，Kerberos 協議的目標之一是防止users的密碼以未加密的形式存儲，即使在認證服務器的數據庫中也是如此。考慮到每種加密算法都使用自己的密鑰長度，很明顯，如果不強制users為每種支持的加密方法使用固定大小的不同密碼，則加密密鑰就不能作為密碼。由于這些原因，引入string2key函數，它將未加密的密碼轉換為適合要使用的加密類型的加密密鑰。每次users更改密碼或輸入密碼進行身份驗證時都會調用此函數。string2key 被稱為散列函數，這意味著它是不可逆的：無法通過給定的encryption得到對應的密碼（除非通過蠻力）。著名的散列算法有MD、5CRC32等。
3.4.3 Salt
在 Kerberos 5 中，與版本 4 不同，引入了密碼鹽的概念。這是一個字符串，在通過 string2key 函數獲取密鑰之前要將其連接到未加的密密碼。Kerberos 5 使用與 salt 相同的usersprincipal ：
? K pippo = string2key ( Ppippo + “pippo@EXAMPLE.COM” )
Kpippo是userspippo的加密密鑰， Ppippo是users未加密的密碼。
這種鹽有以下優點：
- 屬于同一realm并具有相同未加密密碼的兩個principal 仍然具有不同的密鑰。例如，假設管理員有一個負責日常工作的負責人 (pippo@EXAMPLE.COM) 和負責管理工作的負責人 (pippo/admin@EXAMPLE.COM)。為方便起見，該users很可能為兩個principal 設置了相同的密碼。鹽的存在保證了相關的鍵是不同的。
- 如果users在不同realm有兩個帳戶，兩個realm的未加密密碼相同是很常見的，由于存在 salt，一個領域中的帳戶可能遭到入侵，不會自動導致另一個領域也被入侵。
可以配置空鹽以與 Kerberos 4 兼容。反之亦然，為了與 AFS 兼容，可以配置一個鹽，它不是principal 的完整名稱，而只是cell的名稱。
討論了加密類型、string2key 和 salt 的概念后，可以檢查以下觀察結果的準確性：為了在各種 Kerberos 實現之間存在互操作性，協商通用的加密類型是不夠的，但是還需要使用相同類型的 string2key 和 salt。
同樣重要的是要注意，在解釋 string2key 和 salt 的概念時，僅參考了usersprincipal ，從未參考過服務器principal 。原因很明確：services，即使它與認證服務器共享一個secret，也不是一個未加密的密碼（誰會輸入它？），而是一個密鑰，一旦由管理員在 Kerberos 服務器上生成，就會像在提供services的服務器上一樣被記住。
3.4.4 密鑰版本號 Key Version Number (kvno)
當users更改密碼或管理員更新應用程序服務器的密鑰時，此更改會促使計數器來記錄。標識密鑰版本的計數器的當前值被稱為密鑰版本號或更簡單地說kvno。
3.5 密鑰分發中心 Key Distribution Center KDC
我們已經籠統地談到了認證服務器（authentication server）。由于它是涉及users 和services認證的基本對象，我們現在將更深入地研究它，而不深入研究其操作的所有細節，而是側重于協議操作的部分。
Kerberos 環境中的認證服務器，基于其分發services訪問的ticket功能，稱為密鑰分發中心或簡稱為 KDC。由于它完全駐留在單個物理服務器上（通常與單個進程重合），因此在邏輯上可以將其分為三個部分：數據庫、認證服務器 (AS) 和ticket授予服務器 (TGS)。讓我們簡要地看一下它們。
3.5.1 數據庫
數據庫是與users和services相關聯的條目entries 的容器。我們通過使用principal （如條目的名稱）來引用條目，即使術語principal 經常用作條目的同義詞。每個條目都包含以下信息：
- 條目關聯的principal ；
- 加密密鑰和相關的kvno；
- 與principal 關聯的ticket的最長有效期；
- 與principal 關聯的ticket可以續訂的最長時間（僅限 Kerberos 5）；
- 表征ticket行為的屬性或標志；
- 密碼有效期；
- principal 的到期日期，在此之后將不會發出任何ticket。
為了更難以竊取數據庫中存在的密鑰，實現使用與principal K/M@REALM 關聯的主密鑰 master key對數據庫進行加密。甚至任何用作備份或用于從 KDC 主服務器向從服務器傳播的數據庫轉儲都使用此密鑰進行加密，必須知道該密鑰才能重新加載它們。
3.5.2 認證服務器 Authentication Server （AS）
認證服務器是 KDC 的一部分，用于響應來自客戶端的初始身份驗證請求，當users尚未通過身份驗證時，必須輸入密碼。作為對身份驗證請求的響應，AS 發出一個特殊的ticket，稱為Ticket Granting Ticket,，或者更簡單地說 TGT，與其關聯的principal 是 krbtgt/REALM@REALM。如果users確實是他們所說的那樣（我們稍后會看到他們如何證明這一點），他們可以使用 TGT 來獲取其他servicesticket，而無需重新輸入他們的密碼。
3.5.3 ticket授予服務器（TGS）
Ticket Granting Server 是 KDC 組件，它向具有有效 TGT 的客戶端分發servicesticket，保證在應用服務器上獲取請求資源的身份的真實性。TGS 可以被認為是一個應用服務器（假設訪問它需要提供 TGT），它提供services票據作為services的發行。重要的是不要混淆縮寫 TGT 和 TGS：第一個表示ticket，第二個表示services。
3.6 Session Key
正如我們所見，users和services與 KDC 共享一個secret 。對于users來說，這個secret是從他們的密碼中衍生出來的密鑰，而對于services來說，它是他們的密鑰（由管理員設置）。這些鍵稱為長期鍵，因為它們不會在工作會話更改時更改。
但是，users也有必要與services共享一個secret，至少在客戶端在服務器上打開工作會話期間：此密鑰由 KDC 在簽發ticket時生成，稱為會話密鑰 Session Key。發給services的Session Key副本由 KDC 封裝在ticket中（在任何情況下，他們的應用程序服務器都知道長期密鑰，可以對其進行解碼并提取Session Key），而發給users的Session Key 副本則使用users的長期密鑰把其封裝在加密數據包中。會話密鑰在證明users的真實性方面起著基本作用，我們將在下一段中看到這一點。
3.7 認證者 Authenticator
即使users 的principal 存在于ticket中，并且只有應用服務器可以提取并可能管理此類信息（因為ticket是用services的密鑰加密的），這也不足以保證客戶端的真實性。當合法客戶端將ticket發送到應用服務器時，冒名頂替者可以捕獲（記住開放和不安全網絡的假設）ticket，并在適當的時候將其發送以非法獲取services。另一方面，包括可能使用它的機器的 IP 地址的方式也并不是很有用：眾所周知，在開放和不安全的網絡中，地址很容易被偽造。為了解決這個問題，我們必須利用客戶端和服務器，至少在會話期間擁有只有他們知道的共同會話密鑰（KDC 也知道它，因為它生成它）。因此應用以下策略：連同包含ticket的請求，客戶端添加另一個數據包（Authenticator），其中包含users的principal 和時間戳（當時的）并使用session key對其進行加密；必須提供services的服務器在收到此請求后，解開第一張ticket，提取session key；如果users確實是他/她所說的人，則服務器能夠解密authenticator以提取時間戳。如果后者與服務器時間相差小于 2 分鐘（但可以配置容差），則認證成功。
3.8 重放緩存 Replay Cache
冒名頂替者有可能同時竊取ticket和authenticator，并在驗證器有效的 2 分鐘內使用它們。這是非常困難的，但并非不可能。為了解決 Kerberos 5 的這個問題，引入了重放緩存。在應用服務器中（也包括在 TGS 中），有能力記住過去 2 分鐘內到達的身份驗證器，如果它們是副本則拒絕它們。有了這個，只要冒名頂替者不夠聰明，無法復制ticket和身份驗證器，并使它們在合法請求到達之前到達應用服務器，問題就解決了。這真的是一個騙局，因為當冒名頂替者可以訪問該services時，真實users將被拒絕
3.9 憑證緩存 Credential Cache
客戶端從不保留users的密碼，也不記住通過應用 string2key 獲得的密鑰：它們用于解密來自 KDC 的回復并立即丟棄。然而，另一方面，要實現單點登錄 (SSO) 特性，即要求users在每個工作會話中只輸入一次密碼，就必須記住ticket和相關的會話密鑰。存儲此數據的地方稱為“憑據緩存”。此緩存需要位于何處不取決于協議，而是因一種實現而異。通常出于可移植性的目的，它們位于文件系統（MIT 和 Heimdal）中。在其他實現（AFS 和 Active Directory）中，為了在出現易受攻擊的客戶端時提高安全性，
4 Kerberos 的運行方式
最后，在掌握了前面段落中描述的概念之后，可以討論 Kerberos 的運行方式。我們將通過列出和描述在身份驗證期間,在客戶端和 KDC 之間以及客戶端和應用程序服務器之間傳遞的每個數據包來討論說明。基于此，強調應用服務器從不直接與密鑰分發中心KDC通信是重要的：即使是由 TGS 打包的服務票據the service tickets，也只能通過希望訪問它們的客戶端到達服務器。下面列出了我們將討論的消息（另請參見下圖）：
-
AS_REQ是初始的用戶身份驗證請求（即使用 kinit 發出）此消息被定向到KDC的 組件“認證服務器(AS) ” 中；
-
AS_REP是認證服務器對前一個請求的回復。基本上它包含 TGT（使用 TGS 密鑰加密）和session key（使用請求用戶的密鑰加密）；
-
TGS_REQ是客戶端向ticket授予服務器 (TGS) 發出的某服務的ticket請求。該數據包包括從前面的消息中獲得的 TGT 和由客戶端生成并使用會話密鑰session key加密的身份驗證符；
-
TGS_REP是ticket授予服務器對前一個請求的回復。里面的內容是請求的服務的ticket（用服務的秘密密鑰加密）和服務session key，session key由TGS生成并使用AS先前生成的會話密鑰加密的；
-
AP_REQ是客戶端發送到應用服務器訪問某個服務的請求。它由從 TGS 獲得的服務的ticket和和客戶端再次生成的驗證器組成，但這次使用服務的session key（由 TGS 生成）進行加密；
-
AP_REP是應用服務器給客戶端的回復，以證明它確實是客戶端期望的服務器。這個數據并不總是被請求。客戶端僅在雙向驗證時才向服務器請求。
注意：后面的段落用圓括號 () 將未加密數據括起來，將加密數據用大括號 {} 括起來：( x, y, z ) 表示 x, y, z 未加密；{ x, y, z }K 表示 x, y, z 使用對稱密鑰 K 一起加密。同樣重要的是要注意，在數據包中列出組件的順序與實際情況無關。
4.1 Authentication Server Request
在這個階段，稱為初始身份驗證請求，客戶端 (kinit) 向 KDC（更具體地說是 AS）請求一個 Ticket Granting Ticket。該請求是完全未加密的，如下所示：
?
其中： Principal Client 是與尋求身份驗證的用戶相關聯的principal（例如 pippo@EXAMPLE.COM）； PrincipalService 是與請求服務的ticket相關聯的主體，因此是字符串“krbtgt/REALM@REALM”（請參閱注釋*）； IP_list 是一個 IP 地址列表，指示可以使用將要發行的ticket的主機（請參閱注釋 **）； Lifetime是要簽發的票證的最大有效時間（請求）。
注意 *：添加主要服務到初始身份驗證請求，因為這將不斷設置為 TGS 主體，即 krbtgt/REALM@REALM。然而，情況并非如此，事實上，一個用戶計劃在一個工作會話期間只使用一項服務，不會使用單點登錄，并且可能直接向 AS 索要該服務的票證，從而跳過后續請求到 TGS。從操作的角度來看（MIT 1.3.6），以下命令就足夠了：kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM
注意 **：IP_list也可能為空。在這種情況下，任何機器都可以使用相應的票證。這解決了 NAT 下那些客戶端的問題，因為他們的請求到達服務時的源地址與請求用戶的源地址不同，但與進行 NAT 的路由器相同。相反，在具有多個網卡的機器的情況下，IP_list 應該包含所有卡的 IP 地址：事實上，很難預先預測提供服務的服務器將通過哪個連接進行聯系。
4.2 Authentication Server Reply
當前一個請求到達時，AS檢查 PrincipalClient和 PrincipalClient在 KDC 數據庫中是否存在：如果兩者中至少有一個不存在，則向客戶端發送錯誤消息，否則身份驗證服務器AS處理回復如下：
-
它隨機創建一個會話密鑰，該密鑰將成為客戶端和 TGS 之間共享的secret。此處稱為SK TGS;
-
它創建了Ticket Granting Ticket，寫入請求用戶的principal、服務principal（通常是krbtgt/REALM@REALM，但請閱讀上一段的注釋*）、IP地址列表（前三項信息是當它們到達時被 AS_REQ 數據包復制）、時間戳格式的日期和時間（KDC 的）、生命周期（見注釋**）以及最后的會話密鑰。 SK TGS; 因此，Ticket Granting Ticket如下所示：
- 它生成并發送包含以下內容的回復：服務密鑰加密的ticket，KTGS; 服務principal、時間戳、生命周期和session key都使用請求服務的用戶的密鑰加密（我們稱之為Kuser）。總之：
此消息似乎包含冗余信息（PrincipalService, timestamp, lifetime and session key）。但事實并非如此：由于 TGT 中存在的信息是使用服務器的密鑰加密的，因此客戶端無法讀取，需要重復。此時，當客戶端收到回復消息時，會要求用戶輸入密碼。鹽與密碼連接，然后應用 string2key 函數：使用生成的密鑰嘗試解密由 KDC 使用存儲在數據庫中的用戶的秘密密鑰加密的部分消息。如果用戶確實是他/她所說的那樣，并且因此輸入了正確的密碼，則解密操作將成功，因此可以提取會話密鑰并將 TGT（保持加密）存儲在用戶的憑據緩存中。
注 *：實際生命周期，如，放入票證的生命周期為以下值中的最低值：客戶端請求的生命周期、用戶主體中包含的生命周期和服務主體中包含的生命周期。實際上，在實現方面，可以從 KDC 的配置中設置另一個限制并應用于任何票證。
4.3 Ticket Granting Server Request (TGS_REQ)
此時，已經證明是他/她所說的用戶（因此在他/她的憑證緩存中有一個 TGT 和會話密鑰 SK TGS） ，想要訪問該服務但還沒有合適的票證，將請求 (TGS_REQ) 發送到構造它的票證授予服務Ticket Granting Service ，如下所示：
-
使用用戶principal、客戶端機器時間戳創建一個身份驗證器，并使用與 TGS 共享的session key加密所有內容，即：
? Authenticator = { Principal Client , Timestamp }SK TGS
-
創建一個請求數據包，其中包含：ticket需要的服務principal，未加密的生命周期 ；已經用 TGS 的密鑰加密的 Ticket Granting Ticket ；及剛剛創建的驗證器。總之：
TGS_REQ = ( PrincipalService , Lifetime , Authenticator) { TGT }KTGS
4.4 Ticket Granting Server Replay (TGS_REP)
當前一個請求到達時，TGS 首先驗證所請求服務的principal （PrincipalService) 存在于 KDC 數據庫中：如果存在，則使用 krbtgt/REAM@REALM 的密鑰打開 TGT 并提取會話密鑰session key (SK TGS) 用于解密驗證器authenticator。對于要簽發的服務的ticket，它會檢查以下條件是否成立：
- TGT 尚未到期；
- 這PrincipalClient 存在于驗證器中的與存在于 TGT 中的匹配；
- authenticator 不存在于重放緩存中且未過期；
- 如果 IP_list 不為空，它檢查請求數據包的源 IP 地址（TGS_REQ）是否是列表中包含的 IP 地址之一；
上述檢查的件證明TGT確實屬于發出請求的用戶，因此TGS開始處理回復如下：
-
它隨機創建一個會話密鑰session key，該密鑰將是客戶端和服務之間共享的secret。稱為SKService;
-
它創建服務t的icket，將請求用戶的Principal、服務Principal、IP 地址列表、時間戳格式的（KDC）日期和時間、生命周期（作為 TGT 的生命周期和與服務Principal相關聯），最后是會話密鑰 SKService,也被稱作Tserveice，新的ticket如下：
-
它發送包含以下內容的回復消息：先前創建的ticket（使用service secret key加密（我們稱之為
KService)）; 服務Principal、時間戳、生存期和新會話密鑰，都使用從 TGT 中提取的會話密鑰進行加密。總之：
當客戶端收到回復時，憑證緩存中會有session key SK TGS，它可以解密包含其他會話密鑰的消息部分，并將其與服務票證service ticket一起記憶， 然而，它仍然是加密的。
4.5 Application Request (AP_REQ)
擁有訪問服務的憑據（即ticket和相關session key）的客戶端可以通過 AP_REQ 消息請求應用服務器訪問資源。應該記住，與之前涉及 KDC 的消息不同，AP_REQ 不是標準的，而是因應用程序而異。因此，應用程序程序員的工作是制定客戶端將使用其憑據向服務器證明其身份的策略。但是，我們可以通過示例考慮以下策略：
-
客戶端創建一個包含用戶principal 和時間戳的身份驗證器authenticator ，并使用與應用程序服務器共享的會話密鑰 SKService加密所有內容，即：
Authenticator = { Principal Client , Timestamp }SKService
-
它創建一個包含服務ticket TService的請求數據包 這是用它的秘密密鑰和剛剛創建的驗證器加密的。總之：
AP_REQ = Authenticator { TService }KService
當前一個請求到達時，應用服務器使用所請求服務的密鑰打開票證并提取會話密鑰 SK服務它用于解密驗證器。為了確定發出請求的用戶是可信的，從而授予對服務的訪問權限，服務器會驗證以下條件：
- ticket 未過期；
- 驗證器中存在的PrincipalClien與ticket中存在的匹配；
- 身份驗證器不存在于重放緩存中且未過期；
- 如果 IP_list (從票證中提取) is not null 它檢查請求數據包 (AP_REQ) 的源 IP 地址是否是列表中包含的 IP 地址之一；
注意：前面的策略與票據授予服務器用來檢查請求服務票據的用戶的真實性的策略非常相似。但這并不奇怪，因為我們已經解釋過可以將 TGS 視為一個應用服務器，其服務是向那些使用 TGT 證明其身份的人提供票證。
4.6 Pre-Authentication
正如身份驗證服務器回復 (AS_REP) 的描述中所見，在分發票證之前，KDC 只需檢查請求用戶和服務提供者的主體是否存在于數據庫中。然后，特別是如果它涉及對 TGT 的請求，則更容易，因為 krbtgt/REALM@REALM 肯定存在，因此知道用戶的主體存在就足以通過簡單的初始身份驗證請求獲得 TGT . 顯然，如果請求來自非法用戶，則此 TGT 無法使用，因為他們不知道密碼，也無法獲取用于創建有效驗證器的會話密鑰。但是，以如此簡單的方式獲得的這張票可能會遭受暴力攻擊，試圖猜測該票所針對的服務的長期密鑰。明顯地，即使使用當前的處理能力，猜測服務的秘密也不是一件容易的事情，但是，在 Kerberos 5 中，引入了預身份驗證概念來加強安全性。因此，如果 KDC 策略（可配置）請求對初始客戶端請求進行預身份驗證，則身份驗證服務器會回復一個錯誤數據包，指示需要進行預身份驗證。根據錯誤，客戶端要求用戶輸入密碼并重新提交請求，但這次添加了用用戶長期密鑰加密的時間戳，正如我們所知，這是通過將 string2key 應用于未加密的密碼而獲得的加鹽后，如果有的話。這一次，KDC，既然知道了用戶的秘鑰，
需要注意的是，預身份驗證是 KDC 策略，因此協議不一定需要它。在實現方面，MIT Kerberos 5 和 Heimdal 默認禁用預身份驗證，而 Windows Active Directory 中的 Kerberos 和 AFS kaserver（這是一個預身份驗證的 Kerberos 4）請求它。
5 詳解Tickets
如前所述，既然已經討論了 KDC 的操作和參與身份驗證的主機之間的消息，我們現在可以轉向票證。這些取決于它們內部是否設置了屬性（也稱為標志），以某種方式運行。我在下面列出了最重要的票證類型，即使考慮到我在談論協議并不完全正確，我也會參考（足以使事情清楚）MIT Kerberos 5 的 1.3.6 版。
5.1 Initial tickets
初始票證是直接從 AS 獲得的票證，即當用戶必須通過輸入密碼進行身份驗證時。從這里可以推斷出 TGT 始終是初始票證。另一方面，服務票是由 TGS 在提供 TGT 時分發的，因此不是初始票。但是，此規則有一個例外：為了保證用戶僅在幾秒鐘之前輸入密碼，某些 Kerberos 應用程序可能會要求服務票證為初始值；在這種情況下，盡管不是 TGT，但從 AS 而不是 TGS 請求票證，因此是初始票證。在操作方面，用戶 pippo，希望獲得機器 mbox.example.com 上 imap 服務的初始票證（因此不使用 TGT），使用命令：
[pippo@client01 pippo]$ kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM pippo@EXAMPLE.COM 的 密碼： [pippo@client01 pippo]$ [pippo@client01 pippo]$ klist - f 票證緩存：FILE:/tmp/krb5cc_500 默認主體：pippo@EXAMPLE.COM有效起始過期服務主體 01/27/05 14:28:59 01/28/05 14:28:39 imap/mbox.example.com @EXAMPLE.COM標志：我Kerberos 4 票證緩存：/tmp/tkt500 klist：您沒有緩存票證應注意標志 I 的存在，表明它是初始票。
5.2 Renewable tickets
可更新票證可以重新提交給 KDC 進行更新，即在整個生命周期內重新分配。顯然，只有當票證尚未過期且未超過最大續訂時間（在密鑰分發中心數據庫中設置）時，KDC 才會接受續訂請求。能夠續訂票證結合了出于安全原因持有短期票證的必要性，并且不必長時間重新輸入密碼：例如，假設一項工作必須處理數天且不得需要任何人為干預. 在以下示例中，pippo 要求提供最多持續一小時但可續訂 8 天的票證：
kinit -l 1h -r 8d pippo pippo@EXAMPLE.COM 的密碼： [pippo@client01 pippo]$ [pippo@client01 pippo]$ klist -f 票證緩存：FILE:/tmp/krb5cc_500 默認主體：pippo@EXAMPLE.COM有效起始到期服務主體 01/27/05 15:35:14 01/27/05 16:34:54 krbtgt/EXAMPLE.COM@EXAMPLE.COM更新至 02/03/05 15:35:14，標志：RI Kerberos 4 票證緩存：/tmp/tkt500 klist：您沒有緩存票證而 pippo 無需重新輸入密碼即可更新他的票證：
[pippo@client01 pippo]$ kinit -R [pippo@client01 pippo]$ [pippo@client01 pippo]$ klist -f Ticket cache: FILE:/tmp/krb5cc_500 默認委托人：pippo@EXAMPLE.COM有效起始過期服務委托人 01 /27/05 15:47:52 01/27/05 16:47:32 krbtgt/EXAMPLE.COM@EXAMPLE.COM更新至 02/03/05 15:35:14，標志：RIT Kerberos 4 票證緩存：/ tmp/tkt500 klist：您沒有緩存任何票證5.3 Forwardable tickets
假設我們在具有相關 TGT 的機器上有一個工作會話，并希望從它登錄到另一臺機器上，并保留票證。可轉售票是這個問題的解決方案。從一臺主機轉發到另一臺主機的票證本身是可轉發的，因此一旦通過身份驗證，就可以訪問所有所需機器上的登錄名，而無需重新輸入任何密碼。
要在沒有 Kerberos 的情況下獲得相同的結果，必須使用安全性較低的方法，例如 rsh 或使用 ssh 進行公鑰身份驗證。然而，后一種方法在用戶主目錄位于網絡文件系統（例如 NFS 或 AFS）上的系統上可能不切實際，因為私鑰（應該是私有的）會通過網絡。
6 交叉認證 Cross Authentication
我們已經提到了屬于某個領域的用戶可以驗證和訪問另一個領域的服務的可能性。這種稱為交叉身份驗證的特性基于所涉及領域之間存在信任關系的假設。這可能是單向的，這意味著領域 A 的用戶可以訪問領域 B 的服務，但反之則不能，或者是雙向的，正如人們所期望的，相反的情況也是可能的。在下面的段落中，我們將研究交叉身份驗證，將信任關系分解為直接、傳遞和分層。
6.1 Direct trust relationships
這種類型的信任關系是基本的，是交叉認證的基礎，用于構建我們稍后將看到的其他兩種類型的關系。當領域 B 的 KDC 直接信任領域 A 的 KDC 時，就會發生這種情況，從而允許后一個領域的用戶訪問其資源。從實際的角度來看，通過讓兩個相關的 KDC 共享一個密鑰來獲得直接信任關系（如果需要雙向信任，則密鑰變為兩個）。為此，引入了遠程票證授予票證的概念，在兩個領域 A 和 B 的示例中，它采用 krbtgt/B@A 形式，并使用相同的密鑰添加到兩個 KDC。這個密鑰是保證兩個領域之間信任的秘密。顯然，要使其雙向（即 A 也信任 B），
正如我們將在下面的示例中很快看到的那樣，遠程 TGT 的引入使交叉身份驗證成為正常域內身份驗證的自然概括：這強調了先前對 Kerberos 操作的描述繼續有效，只要它被接受一個領域的 TGS 可以驗證另一個領域的 TGS 發布的遠程 TGT。注意當遠程 TGT 不是由 AS 發出時出現的正式異常，就像本地 TGT 發生的那樣，而是由本地票證授予服務器根據本地 TGT 發出。
現在讓我們看一個例子來闡明這一切。讓我們假設領域EXAMPLE.COM的用戶pippo，其關聯主體是pippo@EXAMPLE.COM，希望通過ssh訪問屬于TEST.COM領域的pluto.test.com服務器：
- 如果 Pippo 在領域EXAMPLE.COM 中還沒有TGT，他會發出初始身份驗證請求(kinit)。顯然，回復來自他領域的AS；
- 他給 ssh pippo@pluto.test.com 無需重新輸入密碼即可在 pluto.test.com 上打開遠程 shell 的命令；
- ssh 客戶端對 DNS 進行兩次查詢：它計算 pluto.test.com 的 IP，并在剛剛獲得的地址上執行相反的操作，以獲得規范形式的主機名 (FQDN)（在這種情況下，它與 pluto .test.com);
- 由于先前的結果，ssh 客戶端然后意識到目的地不屬于用戶的領域，因此向領域EXAMPLE.COM 的TGS（注意，它為此向其領域的TGS 詢問）遠程TGT krbtgt /TEST.COM@EXAMPLE.COM;
- 使用遠程 TGT，它向域 TEST.COM 的 TGS 請求 host/pluto.test.com@TEST.COM 服務票；
- 當 TEST.COM 票證授予服務收到請求時，它會檢查其數據庫中是否存在主體 krbtgt/TEST.COM@EXAMPLE.COM，它可以使用它來驗證信任關系。如果此驗證是肯定的，則最終頒發服務票證（使用 host/pluto.test.com@TEST.COM 的密鑰加密），pippo 將發送到主機 pluto.test.com 以獲取遠程 shell。
6.2 Transitive trust relationships
當必須進行交叉身份驗證的領域數量增加時，要交換的密鑰數量呈二次增加。例如，如果有 5 個領域并且關系必須是雙向的，則管理員必須生成 20 個密鑰（將 5 個元素的組合乘以 2 乘以 2）。
為了解決這個問題，Kerberos 5 在信任關系中引入了傳遞性：如果領域 A 信任領域 B，領域 B 信任領域 C，那么 A 將自動信任 C。這種關系屬性大大減少了密鑰的數量（即使認證通道增加）。
但是，仍然存在一個問題：如果不是直接的，客戶端無法猜測身份驗證路徑（capath）。因此，必須通過在每個客戶端的配置中創建一個特殊的節 ([capaths]) 來通知他們正確的路徑。KDC 也必須知道這些路徑，KDC 將使用它們來檢查傳輸。
6.3 Hierarchical trust relationships
如果在組織內使用大寫字母命名領域的約定（強烈推薦選擇），并且如果后者屬于層次結構，則 Kerberos 5 將支持具有信任關系的相鄰領域（層次結構） （自然，這種假定的信任必須得到適當密鑰的支持）并將自動構建（無需 capaths）傳遞身份驗證路徑。但是，管理員可以通過在客戶端配置中強制使用 capaths 來更改此自動機制（例如出于效率原因）。
總結
以上是生活随笔為你收集整理的Kerberos协议内容详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 远程读卡器web客户端（nodejs+w
- 下一篇： 转 《光明日报》：“大数据面前，统计学的