1 簡介

Kerberos協議旨在通過開放和不安全的網絡提供可靠的身份驗證，其中可能攔截屬于它的主機之間的通信。但是，應該知道，如果使用的計算機容易受到攻擊，Kerberos不提供任何保證：身份驗證服務器，應用程序服務器（imap，pop，smtp，telnet，ftp，ssh，AFS，lpr，...）和客戶端必須不斷更新，以確保請求用戶和服務提供商的真實性。

以上幾點證明了這句話：“Kerberos是不受信任網絡上可信主機的身份驗證協議”。舉例來說，并重申這一概念：如果獲得對服務器的特權訪問的人可以復制包含密鑰的文件，則Kerberos的策略是無用的。實際上，入侵者會將此密鑰放在另一臺計算機上，并且只需要為該服務器獲取一個簡單的欺騙DNS或IP地址，以便將客戶端顯示為可靠的服務器。

2 目的

在描述構成Kerberos身份驗證系統的元素并查看其操作之前，協議希望實現的一些目標如下所示：

• 用戶密碼絕不能通過網絡傳輸;

• 用戶密碼絕不能以任何形式存儲在客戶端計算機上：必須在使用后立即丟棄;

• 即使在認證服務器數據庫中，用戶的密碼也不應以未加密的形式存儲;

• 要求用戶每個工作會話僅輸入一次密碼。因此，用戶可以透明地訪問他們授權的所有服務，而無需在此會話期間重新輸入密碼。這種特性稱為單點登錄 ;

• 身份驗證信息管理是集中的，駐留在身份驗證服務器上。應用程序服務器不得包含其用戶的身份驗證信息。這對于獲得以下結果至關重要：

• 管理員可以通過在單個位置執行來禁用任何用戶的帳戶，而無需對提供各種服務的多個應用程序服務器進行操作;

• 當用戶更改其密碼時，會同時更改所有服務的密碼;

• 沒有冗余的認證信息，否則必須在各個地方加以保護;

• 用戶不僅必須證明他們是他們所說的人，而且，在請求時，應用程序服務器也必須向客戶證明其真實性。這種特性稱為相互認證 ;

• 完成身份驗證和授權后，如果需要，客戶端和服務器必須能夠建立加密連接。為此，Kerberos支持生成和交換用于加密數據的加密密鑰。

3?組件和術語的定義

3.1 Realm

術語realm表示身份驗證管理域。其目的是建立認證服務器有權對用戶，主機或服務進行認證的邊界。這并不意味著用戶和服務之間必須屬于同一領域的身份驗證：如果這兩個對象是不同領域的一部分并且它們之間存在信任關系，則可以進行身份驗證。下面將描述稱為交叉認證的這種特性。

基本上，當且僅當他/它與該領域的認證服務器共享秘密（密碼/密鑰）時，用戶/服務才屬于領域。

領域的名稱區分大小寫，即大寫和小寫字母之間存在差異，但通常領域始終以大寫字母顯示。在組織中，使領域名稱與DNS域相同（盡管是大寫字母）也是一種很好的做法。在選擇領域名稱時遵循這些提示可以顯著簡化Kerberos客戶端的配置，尤其是在需要與子域建立信任關系時。舉例來說，如果組織屬于DNS域example.com，則相關的Kerberos領域是EXAMPLE.COM是合適的。

3.2 Principle

Princip是用于引用身份驗證服務器數據庫中的條目的名稱。主體與給定領域的每個用戶，主機或服務相關聯。Kerberos 5中的主體具有以下類型：

COMPONENT1 / COMPONENT2 /.../ componentN @ REALM

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

名稱[/實例] @REALM

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

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

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

服務/主機名@ REALM

第一個組件是服務的名稱，例如imap，AFS，ftp。通常它是單詞host，用于表示對機器的通用訪問（telnet，rsh，ssh）。第二個組件是提供所請求服務的機器的完整主機名（FQDN）。重要的是，此組件與應用程序服務器的IP地址的DNS反向解析完全匹配（以小寫字母表示）.?以下是引用服務的委托人的有效示例：

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

應該注意的是，最后一種情況是一個例外，因為第二個組件不是主機名，而是主體引用的AFS單元的名稱。最后，有些主體不是指用戶或服務，而是在認證系統的操作中發揮作用。一個整體示例是krbtgt / REALM @ REALM，其關聯密鑰用于加密票證授予票證（稍后我們將對此進行說明）。

在Kerberos 4中，永遠不會有兩個以上的組件，它們由字符“。”分隔。當引用服務的主體中的主機名是短的，而不是FQDN時，而不是“/”。以下是有效的例子：

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

3.3 Ticket

票證是客戶端呈現給應用程序服務器以證明其身份的真實性的事物。票證由認證服務器發出，并使用它們所針對的服務的密鑰加密。由于該密鑰是僅在認證服務器和提供服務的服務器之間共享的秘密，因此即使請求該票證的客戶端也不知道它或改變其內容。機票中包含的主要信息包括：

• 請求用戶的主體（通常是用戶名）;

• 它旨在用于服務的主體;

• 可以使用故障單的客戶端計算機的IP地址。在Kerberos 5中，此字段是可選的，也可以是多個字段，以便能夠在NAT或多宿主下運行客戶端。

• 門票有效期開始時的日期和時間（以時間戳格式）;

• 門票的最長壽命

• 會話密鑰（這具有基本作用，如下所述）;

每張票都有一個到期日（通常為10小時）。這是必不可少的，因為身份驗證服務器不再對已發出的票證有任何控制權。即使領域管理員可以隨時阻止為某個用戶發布新票證，也不能阻止用戶使用他們已經擁有的票證。這是限制門票生命周期以限制任何濫用行為的原因。

門票包含許多其他信息和標志，表明了他們的行為，但我們不會在這里討論。在查看身份驗證系統的工作原理后，我們將再次討論故障單和標記。

3.4 加密

3.4.1 加密類型(可略)

Kerberos 4實現了單一類型的加密，即56位的DES。此加密的弱點加上其他協議漏洞使Kerberos 4過時了。但是，Kerberos的第5版不預先確定支持的加密方法的數量或類型。每個特定實現的任務是支持和最佳地協商各種類型的加密。但是，協議的這種靈活性和可擴展性加劇了Kerberos 5的各種實現之間的互操作性問題。為了使用不同實現的客戶端和應用程序和認證服務器進行互操作，它們必須至少具有一種共同的加密類型。與Kerberos 5的Unix實現和Windows Active Directory中存在的實現之間的互操作性相關的困難就是一個典型的例子。實際上，Windows Active Directory支持有限數量的加密，并且只有與Unix共用的56位DES。如果必須保證互操作性，盡管存在眾所周知的風險，但這需要保持后者。該問題隨后通過MIT Kerberos 5的1.3版解決。該版本引入了RC4-HMAC支持，它也存在于Windows中，并且比DES更安全。在支持的加密（但不是Windows）中，三重DES（3DES）和更新的AES128和AES256值得一提。Windows Active Directory支持有限數量的加密，并且只有與Unix共用的56位DES。如果必須保證互操作性，盡管存在眾所周知的風險，但這需要保持后者。該問題隨后通過MIT Kerberos 5的1.3版解決。該版本引入了RC4-HMAC支持，它也存在于Windows中，并且比DES更安全。在支持的加密（但不是Windows）中，三重DES（3DES）和更新的AES128和AES256值得一提。Windows Active Directory支持有限數量的加密，并且只有與Unix共用的56位DES。如果必須保證互操作性，盡管存在眾所周知的風險，但這需要保持后者。該問題隨后通過MIT Kerberos 5的1.3版解決。該版本引入了RC4-HMAC支持，它也存在于Windows中，并且比DES更安全。在支持的加密（但不是Windows）中，三重DES（3DES）和更新的AES128和AES256值得一提。

3.4.2 加密密鑰

如上所述，Kerberos協議的目標之一是防止用戶的密碼以未加密的形式存儲，即使在認證服務器數據庫中也是如此。考慮到每個加密算法使用其自己的密鑰長度，很明顯，如果不強制用戶對支持的每種加密方法使用固定大小的不同密碼，則加密密鑰不能是密碼。由于這些原因，string2key引入了一種功能，它將未加密的密碼轉換為適合所用加密類型的加密密鑰。每次用戶更改密碼或輸入密碼進行身份驗證時，都會調用此函數。string2key被稱為散列函數，這意味著它是不可逆的：假設加密密鑰無法確定生成它的密碼（除非是暴力）。著名的哈希算法是MD5和CRC32。

3.4.3 鹽

在Kerberos 5中，與版本4不同，已經引入了密碼鹽的概念。這是在應用string2key函數獲取密鑰之前要連接到未加密密碼的字符串。Kerberos 5使用與salt相同的用戶主體：

?

K pippo = string2key（P pippo +“pippo@EXAMPLE.COM”）

?

K pippo是用戶pippo的加密密鑰，P pippo是用戶的未加密密碼。 這種鹽具有以下優點：

• 屬于同一領域且具有相同未加密密碼的兩個主體仍具有不同的密鑰。例如，假設一個管理員擁有日常工作的主體（pippo@EXAMPLE.COM）和一個管理工作的管理員（pippo/admin@EXAMPLE.COM）。出于方便的原因，該用戶很可能為兩個主體設置了相同的密碼。鹽的存在保證了相關的鍵是不同的。

• 如果用戶在不同領域有兩個帳戶，則兩個領域的未加密密碼相同是相當頻繁的：由于存在鹽，一個領域可能會損害帳戶，不會自動導致另一個妥協。

可以配置空鹽以與Kerberos 4兼容。反之亦然，為了與AFS兼容，可以配置不是主體的完整名稱的鹽，而只是單元的名稱。

在討論了加密類型，string2key和salt的概念之后，可以檢查以下觀察的準確性：為了在各種Kerberos實現之間存在互操作性，僅僅協商一種常見的加密方式是不夠的，但是也需要使用相同類型的string2key和salt。 同樣重要的是要注意，在解釋string2key和salt的概念時，僅引用用戶主體，而不是服務器的主體。原因很清楚：即使服務與身份驗證服務器共享密鑰，服務也不是未加密的密碼（誰會輸入？），但是一旦由Kerberos服務器上的管理員生成的密鑰被記憶為它位于提供服務的服務器上。

3.4.4 密鑰版本號（kvno）

當用戶更改密碼或管理員更新應用程序服務器的密鑰時，通過推進計數器來記錄此更改。標識密鑰版本的計數器的當前值被稱為密鑰版本號或更簡稱為kvno。

3.5 密鑰分發中心（KDC）

我們一直在談論身份驗證服務器。由于它是用戶和服務認證中涉及的基本對象，因此我們現在將更深入地了解它，而不必考慮其操作的所有細節，而不是專用于協議操作的部分的主題。 Kerberos環境中的身份驗證服務器基于其用于訪問服務的票證分發功能，稱為密鑰分發中心或更簡要的KDC。由于它完全駐留在單個物理服務器上（通常與單個進程一致），因此可以在邏輯上將其分為三個部分：數據庫，身份驗證服務器（AS）和票證授予服務器（TGS）。我們來看看它們。

注意：可以在主/從（MIT和Heimdal）或Multimaster結構（Windows Active Directory）中使服務器在域內冗余。協議不描述如何獲得冗余，但取決于所使用的實現，這里不再討論。

3.5.1 數據庫

數據庫是與users和services關聯的entries的容器。我們通過使用Principal（即entry的名稱）來引用條目，即使通常將term principal用作entry的同義詞。每個entry包含以下信息：

• Entry所關聯的Principal;

• 加密密鑰和相關的kvno;

• 與Principal相關的Ticket最長有效期;

• 可以renewed與Principle關聯的Ticket的最長時間（僅限Kerberos 5）;

• 表示Tickets行為的屬性或標志;

• Password到期日;

• Principal的到期日，之后不會發出票。

為了使竊取數據庫中存在的密鑰更加困難，實現使用主密鑰加密數據庫，該主密鑰與主體K / M @ REALM相關聯。甚至用作備份或從KDC主機向從機傳播的任何數據庫轉儲都使用此密鑰進行加密，為了重新加載它們，必須知道該密鑰。

3.5.2 認證服務器（AS）

當尚未通過身份驗證的用戶必須輸入密碼時，身份驗證服務器是KDC的一部分，它會回復來自客戶端的初始身份驗證請求。為了響應身份驗證請求，AS會發出一個稱為Ticket Granting Ticket的特殊Ticket，或者更簡要的TGT，與之關聯的主體是krbtgt / REALM @ REALM。如果用戶實際上是他們所說的人（我們稍后會看到他們如何證明這一點），他們可以使用TGT獲取其他service tickets，而無需重新輸入密碼。

3.5.3 票證授予服務器（TGS）

TGS是KDC組件，它將service tickets分發給具有有效TGT的客戶端，從而保證用于在應用程序服務器上獲取所請求資源的身份的真實性。可以將TGS視為應用服務器（假定訪問它需要呈現TGT），其提供service tickets作為服務的發布。重要的是不要混淆縮寫TGT和TGS：第一個表示ticket，第二個表示service。

3.6 Session Key

正如我們所看到的，users和services與KDC共享秘密。對于users，此sercret是從其password派生的key，而對于services，它是他們的secret key（由管理員設置）。這些密鑰稱為long term長期密鑰，因為它們在工作會話更改時不會更改。

但是，users還必須與services共享秘密，至少在客戶端在服務器上打開工作會話的時間：此密鑰由KDC在發出ticket時生成，稱為session key。用于服務的副本由ticket中的KDC封裝（在任何情況下，他們的應用服務器都知道長期密鑰并且可以對其進行解碼并提取會話密鑰），而用于該用戶的副本封裝在加密的數據包中用戶長期密鑰。會話密鑰在證明用戶的真實性方面起著重要作用，我們將在下一段中看到。

3.7 Authenticator

即使user principal存在于ticket中，并且只有應用程序服務器可以提取并可能管理此類信息（因為ticket是使用service的密鑰加密的），這不足以保證客戶端的真實性。當合法客戶端將票證發送到應用程序服務器時，冒名頂替者可以捕獲（記住開放且不安全的網絡的假設），并且在合適的時間將其發送給非法獲取服務。另一方面，包括可以使用它的機器的IP地址并不是很有用：眾所周知，在開放且不安全的網絡中，地址很容易被偽造。要解決這個問題，必須利用客戶端和服務器這一事實，至少在會話期間，只有他們知道的會話密鑰是共同的（KDC也知道它，因為它生成了它，但它在定義中是受信任的!!!）。因此，應用以下策略：與包含票證的請求一起，客戶端添加另一個包（驗證者），其中包括user principle和時間戳（當時），并使用會話密鑰對其進行加密; 必須提供服務的服務器在接收到該請求時，解包第一張ticket，提取會話密鑰，如果用戶實際是他/她說的話，則服務器能夠解密驗證者提取時間戳。如果后者與服務器時間的差異小于2分鐘（但可以配置容差），則驗證成功。

3.8 重放緩存Replay Cache

冒名頂替者可能同時竊取ticket和authenticator，并在驗證者有效的2分鐘內使用它們。這非常困難，但并非不可能。為了解決Kerberos 5的這個問題，引入了重放緩存。在應用程序服務器中（但也在TGS中），存在記住在最后2分鐘內到達的authenticators的能力，并且如果它們是replicas則拒絕它們。這樣就解決了問題，只要冒名頂替者不夠智能就不能復制ticket和authenticator，并使它們在合法請求到達之前到達應用服務器。這真的是一個騙局，因為當冒名頂替者可以訪問該服務時，真實用戶將被拒絕。

3.9 憑證緩存Credential Cache

客戶端永遠不會保留用戶的密碼，也不會記住通過應用string2key獲得的密鑰：它們用于解密來自KDC的回復并立即丟棄。然而，另一方面，為了實現單點登錄（SSO）特性，其中要求用戶每個工作會話僅輸入一次密碼，則需要記住票證和相關會話密鑰。存儲此數據的位置稱為“憑據緩存”。需要定位此高速緩存的位置不依賴于協議，而是從一個實現到另一個實現。通常出于可移植性目的，它們位于文件系統（MIT和Heimdal）中。在其他實現（AFS和Active Directory）中，為了在出現易受攻擊的客戶端時提高安全性，

?

【參考】

http://www.kerberos.org/software/tutorial.html

轉載于:https://www.cnblogs.com/dreamfly2016/p/11213057.html

總結

以上是生活随笔為你收集整理的[Kerberos] Kerberos教程（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。