當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

A guided tour of Kerberos: Tutorial

發(fā)布時間：2024/3/12 编程问答 51 豆豆

生活随笔收集整理的這篇文章主要介紹了 A guided tour of Kerberos: Tutorial 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

為了更好的理解 Kerberos 中的概念和認證的大體流程，這篇文檔是快速了解 Kerberos 的一篇非常棒的指南教程，原文地址為 KERBEROS PROTOCOL TUTORIAL，也可以直接訪問原文地址查看。

This tutorial was written by Fulvio Ricciardi and is reprinted here with his permission. Mr. Ricciardi works at the National Institute of Nuclear Physics in Lecce, Italy. He is also the author of the Linux project zeroshell.net, where he originally published this tutorial. Thank you, Mr. Ricciardi!

本教程由 Fulvio Ricciardi 撰寫，并由它的許可在這里轉(zhuǎn)載。Ricciardi 先生在意大利萊切（Lecce, Italy）國家核物理研究所工作，他還是 Linux 項目 zeroshell.net 的作者，他最初在該項目上發(fā)布了本文，Thank you, Mr. Ricciardi!

Document version: 1.0.3 (11/27/2007) Author: Fulvio Ricciardi (Fulvio.Ricciardi@le.infn.it) INFN - the National Institute of Nuclear Physics Computing and Network Services - LECCE, Italy文檔版本： 1.0.3 (2007-11-27) 作者：Fulvio Ricciardi (Fulvio.Ricciardi@le.infn.it)INFN - 國家核物理計算與網(wǎng)絡(luò)服務(wù)研究所-意大利萊切

1 介紹
2 目的
3 組件和術(shù)語的定義
- 3.1 Realm
- 3.2 Principal
- 3.3 票據(jù)（Ticket）
- 3.4 加密（Encryption）
  - 3.4.1 加密類型
  - 3.4.2 加密密鑰（Encryption key）
  - 3.4.3 鹽（Salt）
  - 3.4.4 key 版本號 - kvno （Key Version Number）
- 3.5 密鑰分發(fā)中心 - KDC（Key Distribution Center）
  - 3.5.1 數(shù)據(jù)庫（Database）
  - 3.5.2 身份認證服務(wù) - AS（Authentication Server）
  - 3.5.3 票據(jù)授權(quán)服務(wù) - TGS（Ticket Granting Server）
- 3.6 會話密鑰（Session Key）
- 3.7 身份驗證（Authenticator）
- 3.8 重放緩存（Replay Cache）
- 3.9 認證緩存（Credential Cache）
4 Kerberos 操作
- 4.1 身份驗證服務(wù)請求 - AS_REQ（Authentication Server Request）
- 4.2 身份驗證服務(wù)回復(fù) - AS_REP（Authentication Server Reply）
- 4.3 票據(jù)授權(quán)服務(wù)請求 - TGS_REQ（Ticket Granting Server Request）
- 4.4 票據(jù)授權(quán)服務(wù)重放 - TGS_REP（Ticket Granting Server Replay）
- 4.5 應(yīng)用服務(wù)請求 - AP_REQ（Application Server Request）
- 4.6 身份預(yù)認證（缺失應(yīng)用服務(wù)重放 - AP_REP）
5 深入理解票據(jù)（Tickets in-depth）
- 5.1 初始票據(jù)（Initial tickets）
- 5.2 可續(xù)票據(jù)（Renewable tickets）
- 5.3 可轉(zhuǎn)發(fā)票據(jù)（Forwardable tickets）
6 交叉認證（Cross Authentication）
- 6.1 直接信任關(guān)系（Direct trust relationships）
- 6.2 傳遞信任關(guān)系（Transitive trust relationships）
- 6.3 分層信任關(guān)系（Hierarchical trust relationships）

1 介紹

Kerberos 協(xié)議目標是在開放和不安全的網(wǎng)絡(luò)（open and insecure networks）上提供可靠的身份驗證，其中屬于該協(xié)議的主機之間的通信可能會被攔截。但是請注意，如果使用的計算機容易受到攻擊則 Kerberos 不提供任何保證：身份驗證服務(wù)、應(yīng)用程序服務(wù)(imap, pop, smtp, telnet, ftp, ssh , AFS, lpr, …) 和客戶端必須保持不斷更新以確保請求用戶和服務(wù)提供者的真實性。

以上幾點說明了這一句話：“Kerberos是用于不受信任網(wǎng)絡(luò)上的受信任主機的身份驗證協(xié)議”，舉例說明一下并重申一下這一概念：如果獲得對服務(wù)器的特權(quán)訪問的人可以復(fù)制包含密鑰的文件，則 Kerberos 的策略就沒有用。確實入侵者會將此密鑰放在另一臺計算機上，并且只需要為該服務(wù)器獲得一個簡單的欺騙 DNS 或 IP 地址即可將其顯示為真實的服務(wù)器。

2 目的

在描述組成 Kerberos 身份驗證系統(tǒng)的元素并查看其操作之前，下面列出了協(xié)議希望實現(xiàn)的一些目標：

用戶的密碼絕不能通過網(wǎng)絡(luò)傳播；
用戶密碼絕不能以任何形式存儲在客戶端計算機上：使用后必須立即丟棄；
用戶密碼永遠不要以未加密的形式存儲在身份驗證服務(wù)數(shù)據(jù)庫（authentication server database）中；
要求用戶在每個工作會話中僅輸入一次密碼，因此用戶可以透明地訪問其授權(quán)使用的所有服務(wù)，而不必在此會話期間重新輸入密碼。此特征稱為單點登錄（Single Sign-On）。
認證信息管理是集中式的且位于認證服務(wù)器上。應(yīng)用程序服務(wù)不得包含其用戶的身份驗證信息，這對于獲得以下結(jié)果至關(guān)重要：
管理員可以通過在單個位置執(zhí)行操作來禁用任何用戶的帳戶，而不必在提供各種服務(wù)的多個應(yīng)用程序服務(wù)上執(zhí)行操作；
用戶更改密碼時，同時更改所有服務(wù)的密碼；
沒有身份驗證信息的冗余，否則這些冗余信息必須在各個地方得到保護；
用戶不僅必須證明自己是誰，而且在被請求時，應(yīng)用程序服務(wù)還必須向客戶端證明其真實性，此特性稱為相互認證（Mutual authentication）。
完成身份驗證和授權(quán)后，如果需要客戶端和服務(wù)器必須能夠建立加密連接。為此 Kerberos 提供了對用于加密數(shù)據(jù)的加密密鑰的生成和交換的支持。

3 組件和術(shù)語的定義

此部分提供了對象和術(shù)語的定義，其知識對于隨后的 Kerberos 協(xié)議描述至關(guān)重要。由于許多定義是基于其他定義的，因此作者盡可能嘗試將它們排序，以便在定義術(shù)語時不提前給出術(shù)語的定義。但是，可能需要閱讀本節(jié)兩次（twice）才能完全理解所有術(shù)語。

3.1 領(lǐng)域（Realm）

術(shù)語 Realm 表示認證管理域，其目的是建立一個邊界，在該邊界內(nèi)身份驗證服務(wù)有權(quán)對用戶、主機或服務(wù)進行身份驗證。這并不意味著用戶和服務(wù)之間的認證必須屬于同一 realm：如果兩個對象是不同 Realm 的一部分，并且它們之間存在信任關(guān)系，則可以進行認證。這種特性將在下文描述為交叉認證（Cross-Authentication）。

基本上 user/service 僅在其與該 realm 的身份驗證服務(wù)共享秘密（密碼/密鑰）時才屬于該 realm。

realm 的名稱區(qū)分大小寫，即大寫和小寫字母之間有區(qū)別，但通常情況下 realm 始終以大寫字母出現(xiàn)。在組織中使 realm 名稱與 DNS域相同（也是大寫字母）也是一種好習(xí)慣。在選擇 realm 名稱時遵循這些提示可以大大簡化 Kerberos 客戶端的配置，尤其是在需要與子域（subdomains）建立信任關(guān)系時。舉例來說，如果組織屬于 DNS 域 example.com，則相關(guān) Kerberos 的 realm 最好是 EXAMPLE.COM。

3.2 主體（Principal）

委托人是用于引用身份驗證服務(wù)數(shù)據(jù)庫中條目的名稱，principal 與給定 realm 的每個用戶、主機或服務(wù)相關(guān)聯(lián)。 Kerberos 5 中的主體具有以下類型：

component1/component2/.../componentN@REALM

但是實際上最多使用兩個組件，對于引用用戶的條目 principal 是以下類型：

Name[/Instance]@REALM

該實例是可選的且通常用于更好地限定用戶類型，例如管理員用戶通常具有admin實例。以下是引用給用戶的 principals 的示例：

pippo@EXAMPLE.COM admin/admin@EXAMPLE.COM pluto/admin@EXAMPLE.COM

相反如果條目引用服務(wù)，則主體采用以下形式：

Service/Hostname@REALM

第一個組件是服務(wù)的名稱，例如 imap、AFS、ftp。通常 “主機” 一詞用于表示對計算機（telnet，rsh，ssh）的一般訪問。第二部分是提供所請求服務(wù)的計算機的完整主機名（FQDN），重要的是，此組件必須與應(yīng)用程序服務(wù)器 IP 地址的 DNS 反向解析完全匹配（用小寫字母表示）。以下是引用服務(wù)的 principals 的有效示例：

imap/mbox.example.com@EXAMPLE.COM host/server.example.com@EXAMPLE.COM afs/example.com@EXAMPLE.COM

應(yīng)該注意的是最后一種情況是一個例外，因為第二個組件不是主機名，而是主體所指的 AFS cell 的名稱。最后有些 principals 不涉及用戶或服務(wù)，但在身份驗證系統(tǒng)的操作中起作用。一個整體示例是 krbtgt/REALM@REALM 及其關(guān)聯(lián)的密鑰，用于加密票據(jù)授予票據(jù)（我們將在后面介紹）。

在 Kerberos 4 中組件最多不能超過兩個，它們之間用字符.分隔而不是/，而引用服務(wù)的 principals 中的主機名是簡稱即不是 FQDN。以下是有效的示例：

pippo@EXAMPLE.COM pluto.admin@EXAMPLE.COM imap.mbox@EXAMPLE.COM

3.3 票據(jù)（Ticket）

ticket 是客戶端提供給應(yīng)用程序服務(wù)器以證明其身份真實性的東西，ticket 是由身份驗證服務(wù)器發(fā)行的，并使用其預(yù)定服務(wù)的密鑰進行加密。由于此密鑰是僅在身份驗證服務(wù)器和提供服務(wù)的服務(wù)器之間共享的秘密，因此即使請求 ticket 的客戶端也無法知道它或更改其內(nèi)容，ticket 中包含的主要信息包括：

請求用戶的 principal（通常是用戶名）；
principal 服務(wù)的目的；
可以使用 ticket 的客戶端計算機的 IP 地址，在 Kerberos 5 中此字段是可選的，也可以是多個字段，以便能夠在 NAT 或多宿主下運行客戶端。
ticket 有效期開始的日期和時間（以時間戳格式）；
ticket 的最大壽命
會話密鑰（其基本作用如下所述）；

每個 ticket 都有一個有效期（通常為10小時），這是必不可少的，因為身份驗證服務(wù)器不再對已發(fā)出的 ticket 具有任何控制權(quán)，即使 realm 管理員可以隨時阻止某個用戶發(fā)布新 ticket，也不能阻止用戶使用他們已經(jīng)擁有的 ticket，限制 ticket 壽命的原因是為了限制隨時間的濫用。

ticket 包含許多其他信息和標志，這些信息和標志描述了他們的行為，但我們在這里不做介紹。在了解身份驗證系統(tǒng)的工作原理之后，我們將再次討論 ticket 和標志。

3.4 加密（Encryption）

如您所見 Kerberos 通常需要對在身份驗證的各個參與者之間傳遞的消息（ticket 和身份驗證）進行加密和解密。重要的是要注意 Kerberos 僅使用對稱密鑰加密（換句話說相同的密鑰用于加密和解密）。某些項目（例如 pkinit）正在積極引入公鑰系統(tǒng)，以便通過呈現(xiàn)與經(jīng)認證的公鑰相對應(yīng)的私鑰來獲得初始用戶身份驗證，但是由于目前尚無標準，因此我們暫時跳過此討論。

3.4.1 加密類型

Kerberos 4 實現(xiàn)了一種加密類型即56位 DES，這種加密的弱點以及其他協(xié)議漏洞已使 Kerberos 4 過時了。但是 Kerberos 版本5 不能確定支持的加密方法的 number 或類型。支持并最佳地協(xié)商各種類型的加密是每個特定實現(xiàn)版本的任務(wù)，但是協(xié)議的這種靈活性和可擴展性加劇了 Kerberos 5 各種實現(xiàn)之間的互操作性問題。為了讓用了不同實現(xiàn)的客戶端以及應(yīng)用程序和身份驗證服務(wù)器能夠互操作，它們必須至少具有一種共同的加密類型。與 Kerberos 5 的 Unix 實現(xiàn)和 Windows Active Directory 中存在的實現(xiàn)之間的互操作性相關(guān)的困難就是一個典型的例子。實際上 Windows Active Directory 支持有限數(shù)量的加密，并且與 Unix 一樣僅具有 56位的 DES。盡管必須保證互操作性，但是盡管眾所周知的風險也要求使后者保持啟用狀態(tài)。隨后使用 MIT Kerberos 5 的 1.3 版本解決了該問題，此版本引入了 RC4-HMAC 支持，該支持也存在于 Windows 中，并且比 DES 更安全。在受支持的加密中（但不是 Windows），值得一提的是三重 DES（3DES）以及較新的 AES128 和 AES256。

3.4.2 加密密鑰（Encryption key）

如上所述 Kerberos 協(xié)議的目的之一是防止用戶密碼以未加密的形式存儲，甚至在身份驗證服務(wù)器數(shù)據(jù)庫中也是如此。考慮到每種加密算法都使用其自己的密鑰長度，很明顯如果不強迫用戶為支持的每種加密方法使用固定大小的不同密碼，則加密 key 不能是密碼。由于這些原因引入了 string2key 函數(shù)，該函數(shù)將未加密的密碼轉(zhuǎn)換為適合于要使用的加密類型的加密密鑰。每次用戶更改密碼或輸入密碼進行身份驗證時都會調(diào)用此方法。string2key 稱為哈希函數(shù)，這意味著它是不可逆的：鑒于加密密鑰無法確定生成該密鑰的密碼（除非通過暴力），著名的哈希算法是 MD5 和 CRC32。

3.4.3 鹽（Salt）

與版本4不同在 Kerberos 5 中引入了密碼鹽的概念。這是在應(yīng)用 string2key 函數(shù)獲取密鑰之前要與未加密密碼連接的字符串。Kerberos 5 使用與 salt 相同的 principal 用戶：

K_pippo = string2key(P_pippo + "pippo@EXAMPLE.COM")

K_pippo 是用戶 pippo 的加密密鑰，而 P_pippo 是用戶的未加密密碼。這種鹽具有以下優(yōu)點：

屬于同一 realm 并且具有相同的未加密密碼的兩個 principals 仍然具有不同的密鑰。例如假設(shè)有一個管理員負責日常工作（pippo@EXAMPLE.COM）且一個負責管理工作（pippo/admin@EXAMPLE.COM），為方便起見，此用戶很可能為兩個 principals 設(shè)置了相同的密碼，鹽的存在保證了相關(guān)密鑰是不同的。
如果用戶在不同的 realm 中有兩個帳戶，則經(jīng)常會出現(xiàn)兩個 realm 的未加密密碼相同的情況，由于鹽的存在，一個 realm 中一個帳戶的可能破壞不會自動導(dǎo)致另一個 realm 被妥協(xié)。

可以配置一個 null 鹽來與 Kerberos 4 兼容，反之亦然，為了與 AFS 兼容可以配置一個鹽，它不是 principal 的完整名稱，而僅僅是 cell 的名稱。

在討論了加密類型、string2key 和 salt 的概念之后，可以檢查以下觀察的準確性：為了使各種 Kerberos 實現(xiàn)之間具有互操作性，僅協(xié)商一種通用的加密類型是不夠的，但是同樣也需要使用相同類型的 string2key 和 salt。

還需要注意的是，在解釋 string2key 和 salt 的概念時僅引用了用戶 principals 而沒有引用服務(wù)器的 principals，原因很明顯：即使服務(wù)與身份驗證服務(wù)器共享秘密，它也不是未加密的密碼（誰會輸入它呢？），而是由管理員在 Kerberos 服務(wù)器上生成的密鑰，其存儲為它所提供服務(wù)的服務(wù)器上。

3.4.4 key 版本號 - kvno （Key Version Number）

當用戶更改密碼或管理員更新應(yīng)用程序服務(wù)器的密鑰時，此更改將通過增加計數(shù)器來記錄，標識密鑰版本的計數(shù)器的當前值稱為密鑰版本號或更簡稱為 kvno。

3.5 密鑰分發(fā)中心 - KDC（Key Distribution Center）

我們已經(jīng)談到認證服務(wù)器，由于它是用戶和服務(wù)認證中涉及的基本對象，因此我們現(xiàn)在將對其進行更深入的研究，但不涉及其操作的所有細節(jié)，而將其作為協(xié)議操作部分的主題。

Kerberos 環(huán)境中的身份驗證服務(wù)器基于其用于訪問服務(wù)的 ticket 分發(fā)功能，被稱為密鑰分發(fā)中心，或更簡稱為 KDC。由于它完全駐留在單個物理服務(wù)器上（它通常與單個進程重合），因此可以從邏輯上將其分為三個部分：數(shù)據(jù)庫、身份驗證服務(wù)器（AS）和票證授予服務(wù)器（TGS），讓我們簡單地看一下它們。

注意：可以使服務(wù)器在 Master/Slave（MIT 和 Heimdal）或多主控結(jié)構(gòu)（Windows Active Directory）中的 realm 內(nèi)為冗余。協(xié)議沒有描述如何獲得冗余，而是取決于所使用的實現(xiàn)方式，在此將不進行討論。

3.5.1 數(shù)據(jù)庫（Database）

數(shù)據(jù)庫是與用戶和服務(wù)關(guān)聯(lián)的條目（entries）的容器，即使經(jīng)常使用術(shù)語 principal 作為條目的同義詞，我們也使用 principal（即條目的名稱）來引用條目，每個條目包含以下信息：

條目所關(guān)聯(lián)的 principal；
加密密鑰和相關(guān)的 kvno；
與 principal 關(guān)聯(lián)的 ticket 的最大有效期；
可以更新與 principal 相關(guān)聯(lián)的 ticket 的最長時間（僅 Kerberos 5）；
表征 ticket 行為的屬性或標志；
密碼到期日期；
principal 的到期日，之后將不發(fā)行 ticket。

為了使竊取數(shù)據(jù)庫中存在的密鑰更加困難，實現(xiàn)中使用與主 K/M@REALM 關(guān)聯(lián)的主密鑰（master key）對數(shù)據(jù)庫進行加密。即使是任何數(shù)據(jù)庫轉(zhuǎn)儲、用作備份或從 KDC 主服務(wù)器向從屬服務(wù)器傳輸也都使用此密鑰進行加密，為了重新加載它們必須知道該密鑰。

3.5.2 身份認證服務(wù) - AS（Authentication Server）

身份驗證服務(wù)器是 KDC 的一部分，當尚未經(jīng)過身份驗證的用戶必須輸入密碼時它會響應(yīng)來自客戶端的初始身份驗證請求。響應(yīng)于身份驗證請求，AS發(fā)出一個特殊的 ticket，稱為票證授予票據(jù)（Ticket Granting Ticket），或更簡單地說是 TGT，與之關(guān)聯(lián)的主體是 krbtgt/REALM@REALM。如果用戶實際上就是他們所說的真實身份（我們將在后面看到他們的演示方式），則可以使用 TGT 獲得其他服務(wù)票證而無需重新輸入密碼。

3.5.3 票據(jù)授權(quán)服務(wù) - TGS（Ticket Granting Server）

票證授予服務(wù)器是 KDC 組件，它通過有效的 TGT 將服務(wù)票證分發(fā)給客戶端，從而保證了身份的真實性，以便在應(yīng)用程序服務(wù)器上獲得請求的資源。TGS 可以看作是一個應(yīng)用程序服務(wù)器（假設(shè)要訪問它，必須提供 TGT），該服務(wù)器提供服務(wù)票證的發(fā)行服務(wù)，重要的是不要混淆縮寫 TGT 和 TGS：第一個表示票證，第二個表示票務(wù)。

3.6 會話密鑰（Session Key）

如我們所見用戶和服務(wù)與 KDC 共享一個秘密。對于用戶此秘密是從其密碼派生的密鑰，而對于服務(wù)這是其密鑰（由管理員設(shè)置）。這些密鑰被稱為長期密鑰，因為它們在工作會話更改時不會更改。

但是，至少在客戶端在服務(wù)器上打開工作會話的時間內(nèi)，用戶還必須與服務(wù)共享一個秘密：發(fā)行票證時由 KDC 生成的此密鑰稱為會話密鑰。用于服務(wù)的副本由 KDC 封裝在票證中（無論如何，其應(yīng)用服務(wù)器知道長期密鑰并可以對其進行解碼并提取會話密鑰），而用于用戶的副本則與用戶的長期密鑰封裝在加密的數(shù)據(jù)包中。會話密鑰在證明用戶的真實性方面起著基本作用，我們將在以下段落中看到。

3.7 身份驗證（Authenticator）

即使用戶 principal 存在于票證中并且只有應(yīng)用程序服務(wù)器才能提取且可能管理此類信息（因為票證已使用服務(wù)的密鑰進行了加密），但這不足以保證客戶端的真實性。當合法客戶將票證發(fā)送到應(yīng)用程序服務(wù)器時，冒名頂替者可以捕獲（記住一個假設(shè)在開放且不安全的網(wǎng)絡(luò)下）票證，并在適當時機將其發(fā)送給非法獲取服務(wù)。另一方面，將機器的 IP 地址包括在可以使用的地方不是很有用：眾所周知，在開放和不安全的網(wǎng)絡(luò)中，地址很容易被偽造。為了解決該問題，必須利用這樣一個事實，即客戶端和服務(wù)器至少在會話期間，具有一個只有他們才知道的會話密鑰（KDC 自生成它以來也知道它，但是從定義上來說它是受信任的!!!）。因此將應(yīng)用以下策略：客戶端與包含票證的請求一起添加另一個包（身份驗證器），其中包含用戶 principal 和時間戳（在那時），并使用會話密鑰對其進行加密；必須提供服務(wù)的服務(wù)器在收到此請求后，將第一張 ticket 解包提取會話密鑰，如果用戶確實是他/她所說的話，則服務(wù)器可以對驗證者進行解密以提取時間戳。如果后者與服務(wù)器時間相差少于2分鐘（但是可以配置容差）則認證成功。這強調(diào)了屬于同一 realm 的機器之間同步的重要性。

3.8 重播緩存（Replay Cache）

冒名頂替者有可能同時竊取票證和驗證者并在驗證者有效的2分鐘內(nèi)使用它們，這是非常困難但并非不可能的。為使 Kerberos 5 解決這個問題，引入了重播緩存。在應(yīng)用程序服務(wù)器中（但在 TGS 中），也可以記住最近2分鐘內(nèi)到達的身份驗證器，如果它們是副本則可以拒絕它們。這樣只要冒名頂替者不夠聰明，無法復(fù)制票證和驗證器并使它們在合法請求到達之前到達應(yīng)用程序服務(wù)器，就可以解決問題。這確實是一個騙局，因為當冒名頂替者可以訪問該服務(wù)時真實用戶將被拒絕。

3.9 憑據(jù)緩存（Credential Cache）

客戶端永遠不會保留用戶的密碼，也不會記住通過應(yīng)用 string2key 獲得的密鑰：它們用于解密來自 KDC 的答復(fù)并被立即丟棄。但是另一方面，要實現(xiàn)單點登錄（SSO）特性，即要求用戶每個工作會話僅輸入一次密碼，則必須記住票證和相關(guān)的會話密鑰，該數(shù)據(jù)的存儲位置稱為憑據(jù)緩存，該高速緩存需要放置的位置并不取決于協(xié)議，而是因?qū)崿F(xiàn)方式而異。通常出于可移植性目的，它們位于文件系統(tǒng)（MIT 和 Heimdal）中。在其他實施方式（AFS 和 Active Directory）中，為了在出現(xiàn)易受攻擊的客戶端的情況下提高安全性，將憑據(jù)緩存放置在僅內(nèi)核可訪問且不能在磁盤上交換的內(nèi)存區(qū)域中。

4 Kerberos 操作

最后獲得了前面段落中描述的概念之后，可以討論 Kerberos 的工作方式。我們將通過列出并描述身份驗證期間在客戶端和 KDC 之間以及客戶端和應(yīng)用程序服務(wù)器之間傳遞的每個數(shù)據(jù)包來完成此操作。在這一點上，重要的是要強調(diào)應(yīng)用程序服務(wù)器永遠不要直接與密鑰分發(fā)中心進行通信：票據(jù)服務(wù)即使由 TGS 打包，也只能通過希望訪問它們的客戶端才能到達服務(wù)。下面將列出我們將討論的消息（另請參見下圖）：

AS_REQ 是初始用戶身份驗證請求（即使用 kinit 發(fā)出的請求）。此消息定向到稱為身份驗證服務(wù)器（AS）的 KDC 組件；
AS_REP 是身份驗證服務(wù)器對先前請求的答復(fù)。基本上它包含 TGT（使用 TGS 密鑰加密）和會話密鑰（使用發(fā)出請求的用戶的密鑰加密）；
TGS_REQ 是從客戶端到票據(jù)授權(quán)服務(wù)器（TGS）的服務(wù)票證請求。該數(shù)據(jù)包包括從先前的消息中獲得的 TGT 和由客戶端生成并使用會話密鑰加密的身份驗證器。
TGS_REP 是票據(jù)授權(quán)服務(wù)器對先前請求的答復(fù)。位于其中的是請求的服務(wù)票證（使用服務(wù)的密鑰加密）和由 TGS 生成并使用 AS 生成的先前會話密鑰加密的服務(wù)會話密鑰；
AP_REQ 是客戶端發(fā)送到應(yīng)用程序服務(wù)器以訪問服務(wù)的請求。這些組件是從 TGS 獲得的帶有先前答復(fù)的服務(wù)票證，以及由客戶端再次生成的身份驗證器，但是這次使用服務(wù)會話密鑰（由TGS生成）進行了加密；
AP_REP 是應(yīng)用程序服務(wù)器提供給客戶端的答復(fù)，以證明它確實是客戶端期望的服務(wù)器。并非總是請求此數(shù)據(jù)包，客戶端僅在需要相互認證時才向服務(wù)器請求。

現(xiàn)在參考 Kerberos 5 更詳細地描述每個先前的階段，但會指出與版本4的區(qū)別。但是應(yīng)該記住 Kerberos 協(xié)議相當復(fù)雜，本文檔不作為指南。對于那些想知道確切的操作細節(jié)的人（無論如何，這些細節(jié)已經(jīng)在 RFC1510 中編寫了）。下面的討論被有意抽象的，但對于那些檢查 KDC 日志的人員來說理解各種身份驗證轉(zhuǎn)換和發(fā)生的任何問題就足夠了。

注意：后續(xù)段落將未加密的數(shù)據(jù)括在圓括號()中，將加密的數(shù)據(jù)括在大括號{}中：( x, y, z )表示x,y,z未加密；{ x, y, z }K 表示使用對稱密鑰 K 一起加密了x,y,z。同樣重要的是要注意，包中列出的組件的順序與實際消息（UDP 或 TCP）中的實際順序無關(guān)。討論非常抽象，如果您希望獲得更多詳細信息，請參閱具有描述性協(xié)議 ASN.1 的背景知識的 RFC1510。

4.1 身份驗證服務(wù)請求 - AS_REQ（Authentication Server Request）

在此階段中稱為初始身份驗證請求，客戶端（kinit）向 KDC（更具體地為 AS）請求票證授予票證。該請求是完全未加密的，如下所示：

AS_REQ = (Principal_Client , Principal_Service , IP_list , Lifetime )

其中：

Principal_Client 是與尋求身份驗證的用戶關(guān)聯(lián)的 principal（例如pippo@EXAMPLE.COM）；
Principal_Service 是與票證要求的服務(wù)關(guān)聯(lián)的 principal，因此是字符串krbtgt/REALM@REALM（請參閱 Note *）；
IP_list 是一個 IP 地址列表，指示可以在其中使用將要發(fā)出的票證的主機（請參閱 Note **）；
Lifetime 是要發(fā)行的票證的最大有效時間（要求的）。

Note *：將 Principal_Service 添加到初始身份驗證請求似乎是多余的，因為這將一直設(shè)置為 TGS 主體，即krbtgt/REALM@REALM。但是事實并非如此，實際上計劃在工作會話中僅使用一項服務(wù)的用戶不會使用單一登錄，而是可以直接向 AS 請求該服務(wù)的票證從而跳過隨后的請求到TGS。從操作角度來看（MIT 1.3.6），以下命令已足夠：kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM

Note **：IP_list 也可以為空，在這種情況下任何機器都可以使用相應(yīng)的票證。這解決了那些在 NAT 下的客戶端的問題，因為它們的請求將以與請求用戶的源地址不同但與進行 NAT 的路由器相同的源地址到達服務(wù)。相反對于具有多個網(wǎng)卡的計算機，IP_list 應(yīng)該包含所有網(wǎng)卡的 IP 地址：實際上很難預(yù)先預(yù)測提供服務(wù)的服務(wù)器將與哪個連接聯(lián)系。

4.2 身份驗證服務(wù)回復(fù) - AS_REP（Authentication Server Reply）

當前一個請求到達時，AS 會檢查 KDC 數(shù)據(jù)庫中是否存在 Principal_Client 和 Principal_Service：如果兩者中至少有一個不存在則會向客戶端發(fā)送錯誤消息，否則 Authentication Server如下處理答復(fù)：

它隨機創(chuàng)建一個會話密鑰，該密鑰將是客戶端和 TGS 之間共享的秘密。假設(shè)為 SK_TGS；
它將創(chuàng)建 TGT 并將其放入請求用戶的 principal，principal 服務(wù)（通常為 krbtgt/REALM@REALM,，但請閱讀上一段的 Note *），IP地址列表（前三部分信息是在它們通過 AS_REQ 數(shù)據(jù)包到達時進行復(fù)制），
時間戳格式的日期和時間（KDC 的日期和時間），lifetime（請參閱 Note *）以及最后的會話密鑰。 SK_TGS；因此 TGT 如下所示：

TGT = (Principal_Client , krbtgt/REALM@REALM , IP_list , Timestamp , Lifetime , SK_TGS )

它生成并發(fā)送包含以下內(nèi)容的答復(fù)：先前創(chuàng)建的票證，已使用服務(wù)的密鑰進行了加密（我們將其稱為K_TGS）；服務(wù) principal、timestamp、lifetime 和會話密鑰均使用請求服務(wù)的用戶的密鑰進行了加密（我們將其稱為K_User），總結(jié)為：

AS_REP = {Principal_Service , Timestamp , Lifetime , SK_TGS}K_User { TGT }K_TGS

該消息似乎包含冗余信息（Principal_Service、Timestamp、Lifetime 和會話密鑰）。但是事實并非如此：由于 TGT 中存在的信息是使用服務(wù)器的密鑰加密的，客戶端無法讀取它，因此需要重復(fù)該信息。此時當客戶端收到回復(fù)消息時，它將要求用戶輸入密碼，鹽與密碼連接在一起，然后應(yīng)用 string2key 函數(shù)：使用生成的密鑰，嘗試使用存儲在數(shù)據(jù)庫中的用戶的密鑰來解密由 KDC 加密的消息部分。如果用戶確實是他/她說的人，并因此輸入了正確的密碼，則解密操作將成功，因此可以提取會話密鑰，并將 TGT（保持加密狀態(tài)）存儲在用戶的憑據(jù)緩存中。

Note *：實際 lifetime，即票證中的實際 lifetime 是以下值中的最小值：客戶端請求的 lifetime、用戶 principal 中包含的 lifetime 以及服務(wù) principal 中包含的 lifetime。實際上，在實現(xiàn)方面，可以從 KDC 的配置中設(shè)置另一個限制，并將其應(yīng)用于任何票證。

4.3 票據(jù)授權(quán)服務(wù)請求 - TGS_REQ（Ticket Granting Server Request）

此時，用戶已經(jīng)證明是他/她所說的那個人（因此，在他/她的憑證緩存中有一個 TGT 和會話密鑰 SK_TGS，想要訪問該服務(wù)但還沒有合適的 ticket，則發(fā)送一個 TGS_REQ，其構(gòu)造如下：

使用用戶 principal、客戶端機器時間戳創(chuàng)建身份驗證器，并使用與 TGS 共享的會話密鑰對所有內(nèi)容進行加密，即：

Authenticator = { Principal_Client , Timestamp} SK_TGS

創(chuàng)建一個請求數(shù)據(jù)包，其中包含：需要票證且未加密生命周期的服務(wù) principal；該票證已使用TGS的密鑰加密的 TGT；和剛剛創(chuàng)建的身份驗證器。概括起來如下：

TGS_REQ = ( Principal_Service , Lifetime, Authenticator) { TGT }K_TGS )

4.4 票據(jù)授權(quán)服務(wù)重放 - TGS_REP（Ticket Granting Server Replay）

當先前的請求到達時 TGS 首先驗證 KDC 數(shù)據(jù)庫中是否存在所請求的服務(wù)的主體（Principal_Service）：如果存在，則使用 krbtgt/REAM@REALM 的字符串打開 TGT 并提取會話密鑰SK_TGS 作為要解密的身份驗證器。對于要發(fā)行的票據(jù)服務(wù)，進行檢查以下情況是否有肯定的結(jié)果：

TGT 尚未過期；
身份驗證器中存在的 Principal_Client 與 TGT 中存在的 Principal_Client 相匹配；
驗證者不存在于重播緩存中并且尚未過期；
如果IP_list不為null，它將檢查請求數(shù)據(jù)包（TGS_REQ）的源 IP 地址是否為列表中包含的 IP 地址之一；

先前檢查的條件證明 TGT 確實屬于發(fā)出請求的用戶，因此 TGS 開始按以下方式處理答復(fù)：

它隨機創(chuàng)建一個會話密鑰，該密鑰將是客戶端和服務(wù)之間共享的秘密。假設(shè)為 SK_Service；
它創(chuàng)建服務(wù)票證，將請求用戶的 principal、服務(wù)的 principal、IP地址列表、時間戳格式的（KDC的）日期和時間、生存期（作為TGT生存期與與服務(wù) principal 相關(guān)聯(lián)），最后是會話密鑰 SK_Service。被稱為 T_Service 的新票證是：

T_Service = ( Principal_Client , Principal_Service , IP_list , Timestamp , Lifetime , SK_Service)

它發(fā)送包含以下內(nèi)容為回復(fù)消息：先前創(chuàng)建的票證、已使用服務(wù)密鑰加密（我們將其稱為 K_Service ）、服務(wù) principal、時間戳、生存期和新會話密鑰都使用從 TGT 提取的會話密鑰進行了加密。概括起來如下：

TGS_REP = {Principal_Service , Timestamp , Lifetime , SK_Service}SK_TGS { T_Service }K_Service

當客戶端收到答復(fù)后，在憑據(jù)緩存中具有會話密鑰 SK_TGS，它可以解密包含其他會話密鑰的消息部分，并將其與服務(wù)票證 T_Service 一起存儲，但是該票證仍保持加密狀態(tài)。

4.5 應(yīng)用服務(wù)請求 - AP_REQ（Application Server Request）

具有訪問服務(wù)的憑據(jù)（即票證和相關(guān)會話密鑰）的客戶端可以通過 AP_REQ 消息向應(yīng)用程序服務(wù)器請求對資源的訪問。應(yīng)該牢記的是與先前涉及 KDC 的消息不同，AP_REQ 不是標準的而是根據(jù)應(yīng)用程序而有所不同，因此應(yīng)用程序程序員負責建立策略，客戶端將使用該策略使用其憑據(jù)向服務(wù)器證明其身份。但是，我們可以通過示例考慮以下策略：

客戶端創(chuàng)建一個包含用戶 principal 和時間戳的身份驗證器，并使用與應(yīng)用程序服務(wù)器共享的會話密鑰 SK_Service 加密所有內(nèi)容，即：

Authenticator = { Principal_Client , Timestamp }SK_Service

它創(chuàng)建一個包含服務(wù)票證 T_Service 的請求數(shù)據(jù)包，該服務(wù)票證已使用其密鑰和剛剛創(chuàng)建的身份驗證器進行了加密，概括起來如下：

AP_REQ = Authenticator { T_Service }K_Service

當先前的請求到達時，應(yīng)用程序服務(wù)器使用所請求服務(wù)的密鑰打開票證，并提取會話密鑰 SK_Service，它將其用于解密身份驗證器。為了確定發(fā)出請求的用戶是真實的，并因此授予對該服務(wù)的訪問權(quán)限，服務(wù)器將驗證以下條件：

票據(jù)尚未過期；
身份驗證器中存在的 Principal_Client 與票證中存在的 Principal_Client 相匹配；
驗證者不存在于重播緩存中并且尚未過期；
如果 IP_list（從票證中提取）不為空，則檢查請求包的源 IP 地址（AP_REQ）是否為列表中包含的IP地址之一；

注意：先前的策略與票證授權(quán)服務(wù)器用來檢查請求服務(wù)票證的用戶的真實性的策略非常相似，但這不足為奇，因為我們已經(jīng)解釋了 TGS 可以被視為應(yīng)用服務(wù)器，其服務(wù)是向那些使用 TGT 證明自己身份的人提供票證。

4.6 應(yīng)用服務(wù)重放 - AP_REP （缺失）

4.7 身份預(yù)認證

從 Authentication Server Reply（AS_REP）的說明中可以看出，在分發(fā)票證之前 KDC 只需檢查數(shù)據(jù)庫中是否存在請求用戶和服務(wù)提供者的 principal。然后尤其是在涉及到 TGT 的請求時這甚至?xí)尤菀?#xff0c;因為 krbtgt/REALM@REALM 確實存在，因此只要知道用戶的 principal 就可以通過簡單的初始身份驗證請求獲得 TGT 就足夠了。顯然，如果請求來自一個非法用戶，則無法使用該 TGT，因為他們不知道密碼，也無法獲取用于創(chuàng)建有效身份驗證器的會話密鑰。但是以這種簡單方式獲得的該票證可能會遭受暴力攻擊，以試圖猜測該票證旨在提供的服務(wù)的長期密鑰。顯然，即使使用當前的處理能力，猜測服務(wù)的秘密也不是一件容易的事，然而對于 Kerberos 5 還是引入了預(yù)認證概念以增強安全性。因此，如果 KDC 策略（可配置）請求對初始客戶端請求進行身份預(yù)驗證，則身份驗證服務(wù)器將以錯誤包答復(fù)，指示需要進行身份預(yù)驗證。鑒于錯誤，客戶端要求用戶輸入密碼并重新提交請求，但是這次添加了用用戶長期密鑰加密的時間戳，我們知道這是通過在加鹽后將 string2key 應(yīng)用于未加密的密碼（如果有）來獲得的。這次，由于KDC知道用戶的秘密密鑰，因此它嘗試解密的請求中存在時間戳，如果成功，并且時間戳符合要求，即包含在已建立的容限內(nèi)，則它判斷請求的用戶是真實的，并且身份驗證過程可以正常繼續(xù)。

重要的是要注意，身份預(yù)驗證是 KDC 策略，因此協(xié)議不一定要求它。在實現(xiàn)方面默認情況下 MIT Kerberos 5 和 Heimdal 禁用了預(yù)身份驗證，而 Windows Active Directory 和 AFS kaserver（這是經(jīng)過預(yù)身份驗證的 Kerberos 4）中的 Kerberos 會請求它。

5 深入理解票據(jù)（Tickets in-depth）

如前面所述，既然已經(jīng)討論了 KDC 的操作以及身份驗證所涉及的主機之間的消息，那么現(xiàn)在我們來看看票據(jù)。這些取決于它們是否在其中設(shè)置了屬性（也稱為標志），它們以某種方式運行。我在下面列出了最重要的票據(jù)類型，即使考慮到我在談?wù)搮f(xié)議也不完全正確，我仍將引用 MIT Kerberos 5 的 1.3.6 版（足以使事情變得清楚）。

5.1 初始化票據(jù)（Initial tickets）

初始化票據(jù)是直接從 AS 獲得的，即當用戶必須通過輸入密碼進行身份驗證時，從這里可以推斷出，TGT 始終是初始票據(jù)。另一方面，服務(wù)票據(jù)由 TGS 在提供 TGT 時分發(fā)，因此不是初始票據(jù)。但是該規(guī)則有一個例外：為了保證用戶僅在幾秒鐘之前輸入密碼，某些 Kerberos 應(yīng)用程序可能會要求服務(wù)票據(jù)是初始的。在這種情況下，盡管不是 TGT，但票證是從 AS 而不是 TGS 請求的，因此是初始票據(jù)。在操作方面，用戶 pippo 希望獲得機器 mbox.example.com 上 imap服務(wù) 的初始票證（因此無需使用 TGT），因此使用以下命令：

[pippo@client01 pippo]$ kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM Password for pippo@EXAMPLE.COM: [pippo@client01 pippo]$ [pippo@client01 pippo]$ klist -f Ticket cache: FILE:/tmp/krb5cc_500 Default principal: pippo@EXAMPLE.COMValid starting Expires Service principal 01/27/05 14:28:59 01/28/05 14:28:39 imap/mbox.example.com@EXAMPLE.COMFlags: IKerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached

應(yīng)該注意標志 I 的存在，表明它是一張初始票。

5.2 可續(xù)票據(jù)（Renewable tickets）

可以將可續(xù)票據(jù)重新提交給 KDC 進行更新，即在整個生命周期內(nèi)將其重新分配。顯然僅當票據(jù)尚未過期且未超過最大續(xù)訂時間（在密鑰分發(fā)中心數(shù)據(jù)庫中設(shè)置）時，KDC 才會接受續(xù)訂請求。能夠更新票據(jù)的原因在于出于安全原因需要具有短時票據(jù)，而不必長時間重新輸入密碼：例如假設(shè)一項工作必須處理數(shù)天且無需任何人工干預(yù) 。在以下示例中，pippo 要求購買一張門票，該門票最多可使用一小時，但可續(xù)簽8天：

kinit -l 1h -r 8d pippo Password for pippo@EXAMPLE.COM: [pippo@client01 pippo]$ [pippo@client01 pippo]$ klist -f Ticket cache: FILE:/tmp/krb5cc_500 Default principal: pippo@EXAMPLE.COMValid starting Expires Service principal 01/27/05 15:35:14 01/27/05 16:34:54 krbtgt/EXAMPLE.COM@EXAMPLE.COMrenew until 02/03/05 15:35:14, Flags: RIKerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached while for pippo to renew his ticket without re-entering the password:[pippo@client01 pippo]$ kinit -R [pippo@client01 pippo]$ [pippo@client01 pippo]$ klist -f Ticket cache: FILE:/tmp/krb5cc_500 Default principal: pippo@EXAMPLE.COMValid starting Expires Service principal 01/27/05 15:47:52 01/27/05 16:47:32 krbtgt/EXAMPLE.COM@EXAMPLE.COMrenew until 02/03/05 15:35:14, Flags: RITKerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached

5.3 可轉(zhuǎn)發(fā)票據(jù)（Forwardable tickets）

假設(shè)我們在具有相關(guān) TGT 的機器上進行工作會話，并希望從該機器登錄另一臺機器并保留 ticket，可轉(zhuǎn)讓票據(jù)是解決此問題的方法。從一臺主機轉(zhuǎn)發(fā)到另一臺主機的票據(jù)本身是可轉(zhuǎn)發(fā)的，因此，一旦通過身份驗證，便可以在所有所需計算機上訪問登錄名，而不必重新輸入任何密碼。

為了在沒有 Kerberos 的情況下獲得相同的結(jié)果，有必要使用安全性低得多的方法，例如 rsh 或 ssh 的公鑰身份驗證。但是，后一種方法在用戶主目錄位于網(wǎng)絡(luò)文件系統(tǒng)（例如 NFS 或 AFS）上的系統(tǒng)可能不可行，因為私鑰（應(yīng)為私有）將通過網(wǎng)絡(luò)。

6 交叉認證（Cross Authentication）

我們已經(jīng)提到了屬于某個 realm 的用戶驗證和訪問另一個 realm 的服務(wù)的可能性。稱為交叉身份驗證的此特征基于以下假設(shè)：所涉及的 realm 之間存在信任關(guān)系，這可能是單向的，這意味著 realm A 的用戶可以訪問 realm B 的服務(wù)，但反之則不能；或者是雙向的，正如人們可能期望的那樣，也可以相反。在以下各文章段落中，我們將研究交叉身份驗證，將信任關(guān)系分為直接、傳遞和分層。

6.1 直接信任關(guān)系（Direct trust relationships）

這種類型的信任關(guān)系是基本的，是交叉身份驗證的基礎(chǔ)并且用于構(gòu)造其他兩種類型的關(guān)系，我們將在后面介紹。當 realm B 的 KDC 直接信任 realm A 的 KDC 時，就會發(fā)生這種情況，從而允許后者的用戶訪問其資源。從實際的角度來看，直接信任關(guān)系是通過使兩個參與的 KDC 共享一個密鑰來獲得的（如果需要雙向信任，則密鑰將變?yōu)閮蓚€）。為此，引入了遠程 TGT 的概念，在兩個 realm A 和 B 的示例中，TGT 的形式為 krbtgt/B@A，并使用相同的密鑰添加到兩個 KDC 中，該密鑰是確保兩個 realm 之間信任的秘密。顯然，要使其成為雙向的（即 A 也信任 B），有必要在兩個 KDC 中創(chuàng)建遠程 TGT krbtgt/A@B，并將它們與另一個密鑰相關(guān)聯(lián)。

我們將在下面的示例中很快看到，引入遠程 TGT 使得交叉身份驗證成為常規(guī) intra-realm 身份驗證的自然概括：這說明只要接受一個 realm 的 TGS 可以驗證另一 realm 的 TGS 發(fā)出的遠程 TGT，則先前對 Kerberos 操作的描述將繼續(xù)有效。請注意，當遠程 TGT 不是由 AS 發(fā)布時（由本地發(fā)布，而是由本地票據(jù)授權(quán)服務(wù)器在發(fā)布本地 TGT 時發(fā)生）時，會出現(xiàn)形式上的異常。

現(xiàn)在讓我們看一個例子來闡明所有這些，假設(shè)示例 EXAMPLE.COM 的用戶 pippo（其關(guān)聯(lián) principal 為 pippo@EXAMPLE.COM）希望通過 ssh 訪問屬于 TEST.COM realm 的 pluto.test.com 服務(wù)器：

如果 Pippo 在 EXAMPLE.COM realm 中尚未具有 TGT，他將發(fā)出初始身份驗證請求（kinit）。顯然答復(fù)來自其 realm 的 AS。
他給出了 ssh pippo@pluto.test.com 命令，該命令應(yīng)在 pluto.test.com 上打開遠程 shell 而無需重新輸入密碼。
ssh 客戶端對 DNS 進行兩次查詢：計算出 pluto.test.com 的 IP，然后對剛獲得的地址進行反向查詢，以獲取規(guī)范形式的主機名（FQDN）（在這種情況下它與 pluto.test.com 一致）;
然后，由于先前的結(jié)果 ssh 客戶端意識到目的地不屬于用戶的 realm，因此向該 realm 的 TGS 詢問 EXAMPLE.COM（請注意，它為此向其 realm 的 TGS 詢問）以獲得遠程TGT krbtgt/TEST.COM@EXAMPLE.COM;
通過遠程 TGT，它向 TEST.COM realm 的 TGS 索要 host/pluto.test.com@TEST.COM 服務(wù)票據(jù)；
當 TEST.COM 票據(jù)授權(quán)服務(wù)收到請求時，它將檢查其數(shù)據(jù)庫中是否存在 principal krbtgt/TEST.COM@EXAMPLE.COM，它可以用來驗證信任關(guān)系。
如果此驗證是肯定的，則最終會發(fā)出服務(wù)票據(jù)（使用 host/pluto.test.com@TEST.COM 的密鑰加密），然后 pippo 將其發(fā)送到主機 pluto.test.com 以獲取遠程 shell。

6.2 傳遞信任關(guān)系（Transitive trust relationships）

當必須進行交叉身份驗證的 realms 的數(shù)量增加時，要交換的密鑰的數(shù)量將平方增加。例如如果有5個 realms 并且關(guān)系必須是雙向的，則管理員必須生成20個密鑰（將5個元素的組合乘以2乘以2）。

為解決此問題，Kerberos 5 在信任關(guān)系中引入了可傳遞性：如果 realm A 信任 realm B，realm B 信任 realm C，則 A 將自動信任 C。此關(guān)系屬性將大大減少密鑰的數(shù)量（即使身份驗證次數(shù)增加）。

但是，仍然存在一個問題：如果身份驗證路徑（capath）不是直接的則客戶端無法猜測。因此，必須通過在每個客戶端的配置中創(chuàng)建一個特殊的節(jié)（[capaths]）來告知他們正確的路徑。這些路徑也必須是 KDC 已知的，KDC 將使用它們來檢查運轉(zhuǎn)。

6.3 分層信任關(guān)系（Hierarchical trust relationships）

如果在組織內(nèi)部使用以大寫字母表示 DNS 域名稱的 realm 的約定（強烈建議選擇），并且如果后者屬于一個層次結(jié)構(gòu)，則 Kerberos 5 將支持（具有層次結(jié)構(gòu)的）具有信任關(guān)系的相鄰 realm（自然而然，假定的信任必須由適當?shù)拿荑€來支持），并且將自動構(gòu)造（無需附加功能）可傳遞認證路徑。但是，管理員可以通過強制客戶端配置中的限制來更改此自動機制（例如，出于效率方面的考慮）。

總結(jié)

以上是生活随笔為你收集整理的A guided tour of Kerberos: Tutorial的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：电源系列2：LDO 基本原理（二）
下一篇： Cu50温度传感器的误差分析