當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

A guided tour of Kerberos: Tutorial

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

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

為了更好的理解 Kerberos 中的概念和認(rèn)證的大體流程，這篇文檔是快速了解 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 項(xiàng)目 zeroshell.net 的作者，他最初在該項(xiàng)目上發(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 - 國家核物理計(jì)算與網(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 版本號(hào) - kvno （Key Version Number）
- 3.5 密鑰分發(fā)中心 - KDC（Key Distribution Center）
  - 3.5.1 數(shù)據(jù)庫（Database）
  - 3.5.2 身份認(rèn)證服務(wù) - AS（Authentication Server）
  - 3.5.3 票據(jù)授權(quán)服務(wù) - TGS（Ticket Granting Server）
- 3.6 會(huì)話密鑰（Session Key）
- 3.7 身份驗(yàn)證（Authenticator）
- 3.8 重放緩存（Replay Cache）
- 3.9 認(rèn)證緩存（Credential Cache）
4 Kerberos 操作
- 4.1 身份驗(yàn)證服務(wù)請(qǐng)求 - AS_REQ（Authentication Server Request）
- 4.2 身份驗(yàn)證服務(wù)回復(fù) - AS_REP（Authentication Server Reply）
- 4.3 票據(jù)授權(quán)服務(wù)請(qǐng)求 - TGS_REQ（Ticket Granting Server Request）
- 4.4 票據(jù)授權(quán)服務(wù)重放 - TGS_REP（Ticket Granting Server Replay）
- 4.5 應(yīng)用服務(wù)請(qǐng)求 - AP_REQ（Application Server Request）
- 4.6 身份預(yù)認(rèn)證（缺失應(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 交叉認(rèn)證（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é)議目標(biāo)是在開放和不安全的網(wǎng)絡(luò)（open and insecure networks）上提供可靠的身份驗(yàn)證，其中屬于該協(xié)議的主機(jī)之間的通信可能會(huì)被攔截。但是請(qǐng)注意，如果使用的計(jì)算機(jī)容易受到攻擊則 Kerberos 不提供任何保證：身份驗(yàn)證服務(wù)、應(yīng)用程序服務(wù)(imap, pop, smtp, telnet, ftp, ssh , AFS, lpr, …) 和客戶端必須保持不斷更新以確保請(qǐng)求用戶和服務(wù)提供者的真實(shí)性。

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

2 目的

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

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

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

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

3.1 領(lǐng)域（Realm）

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

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

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

3.2 主體（Principal）

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

component1/component2/.../componentN@REALM

但是實(shí)際上最多使用兩個(gè)組件，對(duì)于引用用戶的條目 principal 是以下類型：

Name[/Instance]@REALM

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

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

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

Service/Hostname@REALM

第一個(gè)組件是服務(wù)的名稱，例如 imap、AFS、ftp。通常 “主機(jī)” 一詞用于表示對(duì)計(jì)算機(jī)（telnet，rsh，ssh）的一般訪問。第二部分是提供所請(qǐng)求服務(wù)的計(jì)算機(jī)的完整主機(jī)名（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)該注意的是最后一種情況是一個(gè)例外，因?yàn)榈诙€(gè)組件不是主機(jī)名，而是主體所指的 AFS cell 的名稱。最后有些 principals 不涉及用戶或服務(wù)，但在身份驗(yàn)證系統(tǒng)的操作中起作用。一個(gè)整體示例是 krbtgt/REALM@REALM 及其關(guān)聯(lián)的密鑰，用于加密票據(jù)授予票據(jù)（我們將在后面介紹）。

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

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

3.3 票據(jù)（Ticket）

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

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

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

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

3.4 加密（Encryption）

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

3.4.1 加密類型

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

3.4.2 加密密鑰（Encryption key）

如上所述 Kerberos 協(xié)議的目的之一是防止用戶密碼以未加密的形式存儲(chǔ)，甚至在身份驗(yàn)證服務(wù)器數(shù)據(jù)庫中也是如此。考慮到每種加密算法都使用其自己的密鑰長度，很明顯如果不強(qiáng)迫用戶為支持的每種加密方法使用固定大小的不同密碼，則加密 key 不能是密碼。由于這些原因引入了 string2key 函數(shù)，該函數(shù)將未加密的密碼轉(zhuǎn)換為適合于要使用的加密類型的加密密鑰。每次用戶更改密碼或輸入密碼進(jìn)行身份驗(yàn)證時(shí)都會(huì)調(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)點(diǎn)：

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

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

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

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

3.4.4 key 版本號(hào) - kvno （Key Version Number）

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

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

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

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

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

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

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

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

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

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

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

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

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

3.6 會(huì)話密鑰（Session Key）

如我們所見用戶和服務(wù)與 KDC 共享一個(gè)秘密。對(duì)于用戶此秘密是從其密碼派生的密鑰，而對(duì)于服務(wù)這是其密鑰（由管理員設(shè)置）。這些密鑰被稱為長期密鑰，因?yàn)樗鼈冊诠ぷ鲿?huì)話更改時(shí)不會(huì)更改。

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

3.7 身份驗(yàn)證（Authenticator）

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

3.8 重播緩存（Replay Cache）

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

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

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

4 Kerberos 操作

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

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

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

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

4.1 身份驗(yàn)證服務(wù)請(qǐng)求 - AS_REQ（Authentication Server Request）

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

AS_REQ = (Principal_Client , Principal_Service , IP_list , Lifetime )

其中：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Authenticator = { Principal_Client , Timestamp} SK_TGS

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

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

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

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

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

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

它隨機(jī)創(chuàng)建一個(gè)會(huì)話密鑰，該密鑰將是客戶端和服務(wù)之間共享的秘密。假設(shè)為 SK_Service；
它創(chuàng)建服務(wù)票證，將請(qǐng)求用戶的 principal、服務(wù)的 principal、IP地址列表、時(shí)間戳格式的（KDC的）日期和時(shí)間、生存期（作為TGT生存期與與服務(wù) principal 相關(guān)聯(lián)），最后是會(huì)話密鑰 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、時(shí)間戳、生存期和新會(huì)話密鑰都使用從 TGT 提取的會(huì)話密鑰進(jìn)行了加密。概括起來如下：

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

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

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

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

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

Authenticator = { Principal_Client , Timestamp }SK_Service

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

AP_REQ = Authenticator { T_Service }K_Service

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

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

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

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

4.7 身份預(yù)認(rèn)證

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

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

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

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

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

初始化票據(jù)是直接從 AS 獲得的，即當(dāng)用戶必須通過輸入密碼進(jìn)行身份驗(yàn)證時(shí)，從這里可以推斷出，TGT 始終是初始票據(jù)。另一方面，服務(wù)票據(jù)由 TGS 在提供 TGT 時(shí)分發(fā)，因此不是初始票據(jù)。但是該規(guī)則有一個(gè)例外：為了保證用戶僅在幾秒鐘之前輸入密碼，某些 Kerberos 應(yīng)用程序可能會(huì)要求服務(wù)票據(jù)是初始的。在這種情況下，盡管不是 TGT，但票證是從 AS 而不是 TGS 請(qǐng)求的，因此是初始票據(jù)。在操作方面，用戶 pippo 希望獲得機(jī)器 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)該注意標(biāo)志 I 的存在，表明它是一張初始票。

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

可以將可續(xù)票據(jù)重新提交給 KDC 進(jìn)行更新，即在整個(gè)生命周期內(nèi)將其重新分配。顯然僅當(dāng)票據(jù)尚未過期且未超過最大續(xù)訂時(shí)間（在密鑰分發(fā)中心數(shù)據(jù)庫中設(shè)置）時(shí)，KDC 才會(huì)接受續(xù)訂請(qǐng)求。能夠更新票據(jù)的原因在于出于安全原因需要具有短時(shí)票據(jù)，而不必長時(shí)間重新輸入密碼：例如假設(shè)一項(xiàng)工作必須處理數(shù)天且無需任何人工干預(yù) 。在以下示例中，pippo 要求購買一張門票，該門票最多可使用一小時(shí)，但可續(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 的機(jī)器上進(jìn)行工作會(huì)話，并希望從該機(jī)器登錄另一臺(tái)機(jī)器并保留 ticket，可轉(zhuǎn)讓票據(jù)是解決此問題的方法。從一臺(tái)主機(jī)轉(zhuǎn)發(fā)到另一臺(tái)主機(jī)的票據(jù)本身是可轉(zhuǎn)發(fā)的，因此，一旦通過身份驗(yàn)證，便可以在所有所需計(jì)算機(jī)上訪問登錄名，而不必重新輸入任何密碼。

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

6 交叉認(rèn)證（Cross Authentication）

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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