[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升级之路