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