[Kerberos] Kerberos教程（一）
1 簡介
Kerberos協(xié)議旨在通過開放和不安全的網(wǎng)絡(luò)提供可靠的身份驗(yàn)證，其中可能攔截屬于它的主機(jī)之間的通信。但是，應(yīng)該知道，如果使用的計(jì)算機(jī)容易受到攻擊，Kerberos不提供任何保證：身份驗(yàn)證服務(wù)器，應(yīng)用程序服務(wù)器（imap，pop，smtp，telnet，ftp，ssh，AFS，lpr，...）和客戶端必須不斷更新，以確保請求用戶和服務(wù)提供商的真實(shí)性。
以上幾點(diǎn)證明了這句話：“Kerberos是不受信任網(wǎng)絡(luò)上可信主機(jī)的身份驗(yàn)證協(xié)議”。舉例來說，并重申這一概念：如果獲得對服務(wù)器的特權(quán)訪問的人可以復(fù)制包含密鑰的文件，則Kerberos的策略是無用的。實(shí)際上，入侵者會將此密鑰放在另一臺計(jì)算機(jī)上，并且只需要為該服務(wù)器獲取一個簡單的欺騙DNS或IP地址，以便將客戶端顯示為可靠的服務(wù)器。
2 目的
在描述構(gòu)成Kerberos身份驗(yàn)證系統(tǒng)的元素并查看其操作之前，協(xié)議希望實(shí)現(xiàn)的一些目標(biāo)如下所示：
-
用戶密碼絕不能通過網(wǎng)絡(luò)傳輸;
-
用戶密碼絕不能以任何形式存儲在客戶端計(jì)算機(jī)上：必須在使用后立即丟棄;
-
即使在認(rèn)證服務(wù)器數(shù)據(jù)庫中，用戶的密碼也不應(yīng)以未加密的形式存儲;
-
-
身份驗(yàn)證信息管理是集中的，駐留在身份驗(yàn)證服務(wù)器上。應(yīng)用程序服務(wù)器不得包含其用戶的身份驗(yàn)證信息。這對于獲得以下結(jié)果至關(guān)重要：
-
管理員可以通過在單個位置執(zhí)行來禁用任何用戶的帳戶，而無需對提供各種服務(wù)的多個應(yīng)用程序服務(wù)器進(jìn)行操作;
-
當(dāng)用戶更改其密碼時，會同時更改所有服務(wù)的密碼;
-
沒有冗余的認(rèn)證信息，否則必須在各個地方加以保護(hù);
-
用戶不僅必須證明他們是他們所說的人，而且，在請求時，應(yīng)用程序服務(wù)器也必須向客戶證明其真實(shí)性。這種特性稱為相互認(rèn)證 ;
-
完成身份驗(yàn)證和授權(quán)后，如果需要，客戶端和服務(wù)器必須能夠建立加密連接。為此，Kerberos支持生成和交換用于加密數(shù)據(jù)的加密密鑰。
3?組件和術(shù)語的定義
術(shù)語realm表示身份驗(yàn)證管理域。其目的是建立認(rèn)證服務(wù)器有權(quán)對用戶，主機(jī)或服務(wù)進(jìn)行認(rèn)證的邊界。這并不意味著用戶和服務(wù)之間必須屬于同一領(lǐng)域的身份驗(yàn)證：如果這兩個對象是不同領(lǐng)域的一部分并且它們之間存在信任關(guān)系，則可以進(jìn)行身份驗(yàn)證。下面將描述稱為交叉認(rèn)證的這種特性。
基本上，當(dāng)且僅當(dāng)他/它與該領(lǐng)域的認(rèn)證服務(wù)器共享秘密（密碼/密鑰）時，用戶/服務(wù)才屬于領(lǐng)域。
領(lǐng)域的名稱區(qū)分大小寫，即大寫和小寫字母之間存在差異，但通常領(lǐng)域始終以大寫字母顯示。在組織中，使領(lǐng)域名稱與DNS域相同（盡管是大寫字母）也是一種很好的做法。在選擇領(lǐng)域名稱時遵循這些提示可以顯著簡化Kerberos客戶端的配置，尤其是在需要與子域建立信任關(guān)系時。舉例來說，如果組織屬于DNS域example.com，則相關(guān)的Kerberos領(lǐng)域是EXAMPLE.COM是合適的。
3.2 Principle
Princip是用于引用身份驗(yàn)證服務(wù)器數(shù)據(jù)庫中的條目的名稱。主體與給定領(lǐng)域的每個用戶，主機(jī)或服務(wù)相關(guān)聯(lián)。Kerberos 5中的主體具有以下類型：
COMPONENT1 / COMPONENT2 /.../ componentN @ REALM
但是，實(shí)際上最多使用兩個組件。對于引用用戶的條目，主體是以下類型：
名稱[/實(shí)例] @REALM
該實(shí)例是可選的，通常用于更好地限定用戶類型。例如，管理員用戶通常具有管理員實(shí)例。以下是引用用戶的主體示例：
pippo@EXAMPLE.COM admin/admin@EXAMPLE.COM pluto/admin@EXAMPLE.COM
相反，如果條目引用服務(wù)，則主體采用以下形式：
服務(wù)/主機(jī)名@ REALM
第一個組件是服務(wù)的名稱，例如imap，AFS，ftp。通常它是單詞host，用于表示對機(jī)器的通用訪問（telnet，rsh，ssh）。第二個組件是提供所請求服務(wù)的機(jī)器的完整主機(jī)名（FQDN）。重要的是，此組件與應(yīng)用程序服務(wù)器的IP地址的DNS反向解析完全匹配（以小寫字母表示）.?以下是引用服務(wù)的委托人的有效示例：
imap/mbox.example.com@EXAMPLE.COM host/server.example.com@EXAMPLE.COM afs/example.com@EXAMPLE.COM
應(yīng)該注意的是，最后一種情況是一個例外，因?yàn)榈诙€組件不是主機(jī)名，而是主體引用的AFS單元的名稱。最后，有些主體不是指用戶或服務(wù)，而是在認(rèn)證系統(tǒng)的操作中發(fā)揮作用。一個整體示例是krbtgt / REALM @ REALM，其關(guān)聯(lián)密鑰用于加密票證授予票證（稍后我們將對此進(jìn)行說明）。
在Kerberos 4中，永遠(yuǎn)不會有兩個以上的組件，它們由字符“。”分隔。當(dāng)引用服務(wù)的主體中的主機(jī)名是短的，而不是FQDN時，而不是“/”。以下是有效的例子：
pippo@EXAMPLE.COM pluto.admin@EXAMPLE.COM imap.mbox@EXAMPLE.COM
3.3 Ticket
票證是客戶端呈現(xiàn)給應(yīng)用程序服務(wù)器以證明其身份的真實(shí)性的事物。票證由認(rèn)證服務(wù)器發(fā)出，并使用它們所針對的服務(wù)的密鑰加密。由于該密鑰是僅在認(rèn)證服務(wù)器和提供服務(wù)的服務(wù)器之間共享的秘密，因此即使請求該票證的客戶端也不知道它或改變其內(nèi)容。機(jī)票中包含的主要信息包括：
-
請求用戶的主體（通常是用戶名）;
-
它旨在用于服務(wù)的主體;
-
可以使用故障單的客戶端計(jì)算機(jī)的IP地址。在Kerberos 5中，此字段是可選的，也可以是多個字段，以便能夠在NAT或多宿主下運(yùn)行客戶端。
-
門票有效期開始時的日期和時間（以時間戳格式）;
-
門票的最長壽命
-
會話密鑰（這具有基本作用，如下所述）;
每張票都有一個到期日（通常為10小時）。這是必不可少的，因?yàn)樯矸蒡?yàn)證服務(wù)器不再對已發(fā)出的票證有任何控制權(quán)。即使領(lǐng)域管理員可以隨時阻止為某個用戶發(fā)布新票證，也不能阻止用戶使用他們已經(jīng)擁有的票證。這是限制門票生命周期以限制任何濫用行為的原因。
門票包含許多其他信息和標(biāo)志，表明了他們的行為，但我們不會在這里討論。在查看身份驗(yàn)證系統(tǒng)的工作原理后，我們將再次討論故障單和標(biāo)記。
3.4 加密
3.4.1 加密類型(可略)
3.4.2 加密密鑰
如上所述，Kerberos協(xié)議的目標(biāo)之一是防止用戶的密碼以未加密的形式存儲，即使在認(rèn)證服務(wù)器數(shù)據(jù)庫中也是如此。考慮到每個加密算法使用其自己的密鑰長度，很明顯，如果不強(qiáng)制用戶對支持的每種加密方法使用固定大小的不同密碼，則加密密鑰不能是密碼。由于這些原因，string2key引入了一種功能，它將未加密的密碼轉(zhuǎn)換為適合所用加密類型的加密密鑰。每次用戶更改密碼或輸入密碼進(jìn)行身份驗(yàn)證時，都會調(diào)用此函數(shù)。string2key被稱為散列函數(shù)，這意味著它是不可逆的：假設(shè)加密密鑰無法確定生成它的密碼（除非是暴力）。著名的哈希算法是MD5和CRC32。
3.4.3 鹽
在Kerberos 5中，與版本4不同，已經(jīng)引入了密碼鹽的概念。這是在應(yīng)用string2key函數(shù)獲取密鑰之前要連接到未加密密碼的字符串。Kerberos 5使用與salt相同的用戶主體：
?
K pippo = string2key（P pippo +“pippo@EXAMPLE.COM”）
?
K pippo是用戶pippo的加密密鑰，P pippo是用戶的未加密密碼。 這種鹽具有以下優(yōu)點(diǎn)：
-
屬于同一領(lǐng)域且具有相同未加密密碼的兩個主體仍具有不同的密鑰。例如，假設(shè)一個管理員擁有日常工作的主體（pippo@EXAMPLE.COM）和一個管理工作的管理員（pippo/admin@EXAMPLE.COM）。出于方便的原因，該用戶很可能為兩個主體設(shè)置了相同的密碼。鹽的存在保證了相關(guān)的鍵是不同的。
-
如果用戶在不同領(lǐng)域有兩個帳戶，則兩個領(lǐng)域的未加密密碼相同是相當(dāng)頻繁的：由于存在鹽，一個領(lǐng)域可能會損害帳戶，不會自動導(dǎo)致另一個妥協(xié)。
可以配置空鹽以與Kerberos 4兼容。反之亦然，為了與AFS兼容，可以配置不是主體的完整名稱的鹽，而只是單元的名稱。
在討論了加密類型，string2key和salt的概念之后，可以檢查以下觀察的準(zhǔn)確性：為了在各種Kerberos實(shí)現(xiàn)之間存在互操作性，僅僅協(xié)商一種常見的加密方式是不夠的，但是也需要使用相同類型的string2key和salt。 同樣重要的是要注意，在解釋string2key和salt的概念時，僅引用用戶主體，而不是服務(wù)器的主體。原因很清楚：即使服務(wù)與身份驗(yàn)證服務(wù)器共享密鑰，服務(wù)也不是未加密的密碼（誰會輸入？），但是一旦由Kerberos服務(wù)器上的管理員生成的密鑰被記憶為它位于提供服務(wù)的服務(wù)器上。
3.4.4 密鑰版本號（kvno）
當(dāng)用戶更改密碼或管理員更新應(yīng)用程序服務(wù)器的密鑰時，通過推進(jìn)計(jì)數(shù)器來記錄此更改。標(biāo)識密鑰版本的計(jì)數(shù)器的當(dāng)前值被稱為密鑰版本號或更簡稱為kvno。
3.5 密鑰分發(fā)中心（KDC）
我們一直在談?wù)撋矸蒡?yàn)證服務(wù)器。由于它是用戶和服務(wù)認(rèn)證中涉及的基本對象，因此我們現(xiàn)在將更深入地了解它，而不必考慮其操作的所有細(xì)節(jié)，而不是專用于協(xié)議操作的部分的主題。
注意：可以在主/從（MIT和Heimdal）或Multimaster結(jié)構(gòu)（Windows Active Directory）中使服務(wù)器在域內(nèi)冗余。協(xié)議不描述如何獲得冗余，但取決于所使用的實(shí)現(xiàn)，這里不再討論。
3.5.1 數(shù)據(jù)庫
數(shù)據(jù)庫是與users和services關(guān)聯(lián)的entries的容器。我們通過使用Principal（即entry的名稱）來引用條目，即使通常將term principal用作entry的同義詞。每個entry包含以下信息：
-
Entry所關(guān)聯(lián)的Principal;
-
加密密鑰和相關(guān)的kvno;
-
與Principal相關(guān)的Ticket最長有效期;
-
-
表示Tickets行為的屬性或標(biāo)志;
-
Password到期日;
-
Principal的到期日，之后不會發(fā)出票。
為了使竊取數(shù)據(jù)庫中存在的密鑰更加困難，實(shí)現(xiàn)使用主密鑰加密數(shù)據(jù)庫，該主密鑰與主體K / M @ REALM相關(guān)聯(lián)。甚至用作備份或從KDC主機(jī)向從機(jī)傳播的任何數(shù)據(jù)庫轉(zhuǎn)儲都使用此密鑰進(jìn)行加密，為了重新加載它們，必須知道該密鑰。
3.5.2 認(rèn)證服務(wù)器（AS）
當(dāng)尚未通過身份驗(yàn)證的用戶必須輸入密碼時，身份驗(yàn)證服務(wù)器是KDC的一部分，它會回復(fù)來自客戶端的初始身份驗(yàn)證請求。為了響應(yīng)身份驗(yàn)證請求，AS會發(fā)出一個稱為Ticket Granting Ticket的特殊Ticket，或者更簡要的TGT，與之關(guān)聯(lián)的主體是krbtgt / REALM @ REALM。如果用戶實(shí)際上是他們所說的人（我們稍后會看到他們?nèi)绾巫C明這一點(diǎn)），他們可以使用TGT獲取其他service tickets，而無需重新輸入密碼。
3.5.3 票證授予服務(wù)器（TGS）
TGS是KDC組件，它將service tickets分發(fā)給具有有效TGT的客戶端，從而保證用于在應(yīng)用程序服務(wù)器上獲取所請求資源的身份的真實(shí)性。可以將TGS視為應(yīng)用服務(wù)器（假定訪問它需要呈現(xiàn)TGT），其提供service tickets作為服務(wù)的發(fā)布。重要的是不要混淆縮寫TGT和TGS：第一個表示ticket，第二個表示service。
3.6 Session Key
正如我們所看到的，users和services與KDC共享秘密。對于users，此sercret是從其password派生的key，而對于services，它是他們的secret key（由管理員設(shè)置）。這些密鑰稱為long term長期密鑰，因?yàn)樗鼈冊诠ぷ鲿捀臅r不會更改。
但是，users還必須與services共享秘密，至少在客戶端在服務(wù)器上打開工作會話的時間：此密鑰由KDC在發(fā)出ticket時生成，稱為session key。用于服務(wù)的副本由ticket中的KDC封裝（在任何情況下，他們的應(yīng)用服務(wù)器都知道長期密鑰并且可以對其進(jìn)行解碼并提取會話密鑰），而用于該用戶的副本封裝在加密的數(shù)據(jù)包中用戶長期密鑰。會話密鑰在證明用戶的真實(shí)性方面起著重要作用，我們將在下一段中看到。
3.7 Authenticator
即使user principal存在于ticket中，并且只有應(yīng)用程序服務(wù)器可以提取并可能管理此類信息（因?yàn)閠icket是使用service的密鑰加密的），這不足以保證客戶端的真實(shí)性。當(dāng)合法客戶端將票證發(fā)送到應(yīng)用程序服務(wù)器時，冒名頂替者可以捕獲（記住開放且不安全的網(wǎng)絡(luò)的假設(shè)），并且在合適的時間將其發(fā)送給非法獲取服務(wù)。另一方面，包括可以使用它的機(jī)器的IP地址并不是很有用：眾所周知，在開放且不安全的網(wǎng)絡(luò)中，地址很容易被偽造。要解決這個問題，必須利用客戶端和服務(wù)器這一事實(shí)，至少在會話期間，只有他們知道的會話密鑰是共同的（KDC也知道它，因?yàn)樗闪怂?#xff0c;但它在定義中是受信任的!!!）。因此，應(yīng)用以下策略：與包含票證的請求一起，客戶端添加另一個包（驗(yàn)證者），其中包括user principle和時間戳（當(dāng)時），并使用會話密鑰對其進(jìn)行加密; 必須提供服務(wù)的服務(wù)器在接收到該請求時，解包第一張ticket，提取會話密鑰，如果用戶實(shí)際是他/她說的話，則服務(wù)器能夠解密驗(yàn)證者提取時間戳。如果后者與服務(wù)器時間的差異小于2分鐘（但可以配置容差），則驗(yàn)證成功。
3.8 重放緩存Replay Cache
冒名頂替者可能同時竊取ticket和authenticator，并在驗(yàn)證者有效的2分鐘內(nèi)使用它們。這非常困難，但并非不可能。為了解決Kerberos 5的這個問題，引入了重放緩存。在應(yīng)用程序服務(wù)器中（但也在TGS中），存在記住在最后2分鐘內(nèi)到達(dá)的authenticators的能力，并且如果它們是replicas則拒絕它們。這樣就解決了問題，只要冒名頂替者不夠智能就不能復(fù)制ticket和authenticator，并使它們在合法請求到達(dá)之前到達(dá)應(yīng)用服務(wù)器。這真的是一個騙局，因?yàn)楫?dāng)冒名頂替者可以訪問該服務(wù)時，真實(shí)用戶將被拒絕。
3.9 憑證緩存Credential Cache
客戶端永遠(yuǎn)不會保留用戶的密碼，也不會記住通過應(yīng)用string2key獲得的密鑰：它們用于解密來自KDC的回復(fù)并立即丟棄。然而，另一方面，為了實(shí)現(xiàn)單點(diǎn)登錄（SSO）特性，其中要求用戶每個工作會話僅輸入一次密碼，則需要記住票證和相關(guān)會話密鑰。存儲此數(shù)據(jù)的位置稱為“憑據(jù)緩存”。需要定位此高速緩存的位置不依賴于協(xié)議，而是從一個實(shí)現(xiàn)到另一個實(shí)現(xiàn)。通常出于可移植性目的，它們位于文件系統(tǒng)（MIT和Heimdal）中。在其他實(shí)現(xiàn)（AFS和Active Directory）中，為了在出現(xiàn)易受攻擊的客戶端時提高安全性，
?
【參考】
http://www.kerberos.org/software/tutorial.html
轉(zhuǎn)載于:https://www.cnblogs.com/dreamfly2016/p/11213057.html
總結(jié)
以上是生活随笔為你收集整理的[Kerberos] Kerberos教程（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 射频测试仪器简谈
- 下一篇： 腾讯搜搜soso升级之路