Kerberos的組件和術語(翻譯和註解)

之因此要翻譯這篇文章，是由於提到了一些一般於對Kerberos協議簡介性質的文章所沒有提到的細節，而這些細節對於理解Kerberos的工做原理，以及Kerberos協議實現的使用都是頗有必要的。

1.3 組件和術語的定義

這一節給了關於對象和術語的定義，對於這些的瞭解對於接下來關於Kerberos協議的描述是很是關鍵的。由於有些定義是基於其它定義的，因此我會盡可能嘗試按照順序來說解它們，以使得先給出它們的含義再給出定義(譯註：這裏原文有些怪怪的，不過大概意思就是按照術語出現的前後來解釋它們)。儘管如此，把這一節多讀兩篇來徹底理解這些術語也是有必要的。

 

1.3.1 Realm

"realm"這個術語表示一個認證管理域(譯註，意思是：屬於同一個域的用戶使用一樣的認證方案。這個能夠見照kdc.conf來理解，在kdc.conf中，不少配置 項是每一個realm不一樣的，好比database的位置，ACL設置 等)。realm用來建立認證的邊界，在屬於一個認證服務的邊界內，這個認證服務纔有權利認證一個用戶，主機或者服務。但這並不意味着若是一個用戶和一個服務屬於不一樣的realm，它們就沒法互相認證，若是它們不在同一個realm中，可是它們所屬的realm有信任關係，那麼認證就能夠經過。本文下面會講到這個被稱爲"交叉認證 Cross-Authentiation的機制。

基本上能夠認爲，只有當一個用戶/服務和一個域的認證服務共享一個密祕(密碼/密鑰)時，這個用戶/服務才屬於這個域。

realm的名字是大小寫敏感的，也就是說，大寫和小寫字符是有區別的，全是一般的realm的名字都用大寫字母。另外一個好的實踐是，在一個組織中，讓realm名字和DNS域名一致(可是要大寫)。在選擇realm名字的時候遵循這些建議，將會顯著減小Kerberos客戶端的配置，並且若是想要在子域(subdomain)間創建信任關係，這樣配置是首要的。好比，若是一個組織屬於DNS域example.com，那麼最好把相關的Kerberos realm配成EXAMPLE.COM。

 

1.3.2 Principal

 

一個Principal就是一個名字，這個名字用於引用認證服務數據庫中的一個條目。一個Principal和一個特定realm的用戶、主機、或者服務相關聯。Kerberos5中的一個principal有如下的形式：

component1/component2/.../componentN@REALM

可是，在實踐中，最多隻使用兩個component。對於引代一個用戶的條目，它的principal是這樣的形式：

Name[/Instance]@REALM

其中Instance是可選 的，一般用於更好地限定用戶的類型。好比，一個管理員用戶一般會有admin instance(譯註：即Name/admin@REALM這種形式)。

下面是指代用戶的 一些principal的例子：

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

若是，這個條目指代的是服務，那麼principal就須要有如下的形式：

Service/Hostname@REALM

第一部分是service的名字，好比imap, AFS, ftp. 一般'host'這個名字被用於指明對一臺機器的通用的訪問(telnent, rsh, ssh)。

第二個component是提供這個服務的機器的徹底主機名(FQDN)。這個 component跟DNS對應用服務器的IP地址進行逆向解析後獲得的主機名

徹底一致是很重要的。下面是指代服務所用的principal的例子：

imap/mbox.example.com@EXAMPLE.COM

host/server.example.com@EXAMPLE.COM

afs/example.com@EXAMPLE.COM

須要指出的是最後一條是一個例外，由於它的第二個compoment不是主機名，而是AFS cell的名字。最後，有一些principal即不用來指代用戶，

也不用於指代服務，而是Kerberos認證系統的操做中扮演一個角色。一個首要的例子就是krbtgt/REALM@REALM，這個principal的密鑰會

被用來加密Tikcet Granting Ticket(咱們下面會講到這個)(譯註，krb就是指kerberos, tgt就是指Ticket Granting Ticket，因此這個特殊的principal就是

krbtgt。這個principal的密鑰會被用到加密TGT，只有KDC擁有krbtgt的密鑰，因此TGT纔不能被僞造).

 

對於Kerberos 4，永遠不能有超過兩個的components，而且它們之間的分隔符是".", 而不是"/"，而且用於指代服務的principal的hostname是短

的那種，不是FQDN。下面是可用的例子：

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

 

1.3.3 Ticket

Ticket是客戶端提供給應用服務器用於代表本身真實身份的東西(譯註：這是Kerberos的最終目的，你們能夠想一下是Kerberos是怎麼基於

對稱密碼算法作到這一點的)。Ticket是認證服務器(AS, Authentication Server)分發的，而且使用客戶端想要訪問的服務的密鑰加密。因爲

加密ticket使用的密鑰是AS和提供服務的服務器之間的祕密，所以即便請求ticket的客戶端也不能知道或更改它的內容(譯註：因此, ticket的

準確的概念是指用service的密鑰加密前的內容，而不是加密後被client提交給service 所在server的那些數據)。ticket包括的主要信息包括：

• 發出請求的用戶的principal（一般就是用戶名）
• 想要訪問的服務的principal
• 想要使用這個ticket的客戶端所在機器的IP地址。在Kerberos 5中這個field是可選的，而且但是有多個，以即可以在NAT或者多宿主主機（multihomed）下使用
• 準備啓用ticket的日期和時間(以時間戳的形式)（The date and time when the tickets validity commences）
• ticket的最大生存時間
• 會話密鑰(session key)(這個密鑰有很是重要的做用，在下面將會描述它的角色)

每一個ticket都會有一個過時時間(一般是10小時)。這很是關鍵，由於AS沒法控制一個已經分發去出的ticket(譯註：由於AS和提供service的server之間是沒有聯繫的。所以，AS是沒辦法主動銷燬一個已經分發出去的ticket的)。儘管realm的管理員能夠在任什麼時候間中止給特定的用戶分發新的ticket，可是卻沒法阻止用戶使用已經擁有的ticket。限制一個ticket的生命週期，就是爲了防止無時間限制的濫用。

ticket中還有其它不少信息和標誌，用來指示它們的行爲，可是這篇文章不會講這麼多。咱們將會在介紹完認證系統的工做方式之後再來介紹ticket和標誌位。

 

 1.3.4 加密

 

就像你所看到的 同樣，Kerberos常常須要加密和解密在認證過程當中的參與者之間傳遞的消息(ticket和authenticator)(譯註：authenticator的概念後面會講)。須要強調的是，Kerberos只使用對稱加密算法(也就是說一樣的密鑰即用於加密也用於解密)。某些工程(好比pkinit)致力於引用公鑰系統，利於與特定公鑰相關的私鑰來對初始用戶進行驗證，可是鑑於這種作法並無一個標準，因此咱們會暫時跳過。

1.3.4.1 加密類型

Kerberos 4只實現了一種加密類型，就56位DES。這種加密算法的脆弱性和一些協議上的漏洞(譯註：指Kerberos 4協議上的漏洞)使得Kerberos 4已經再也不使用 了。Kerbeors 5，不一樣於它的前任，沒有它所支持的加密算法的數量和類型。而是由Kerberos的不一樣實現來支持和溝通各類不一樣的加密算法(譯註：這裏的溝通應該是指KDC和Client間對使用的加密算法進行溝通)。可是，這種靈活性和可擴展性卻加重了Kerberos的各類實現之間的互操做問題。Kerberos的不一樣實現的客戶端、程序和認證服務器之間若是想要互操做(interoperate), 它們必須至少有一種相同的加密算法。Unix實現的Kerberos 5和Windows的Active Directory之間的互操做存在的因難就是一個典型的例子。事實上，Windows Active Directory只支持有限的幾種加密算法，而且它和Unix的Kerberos實現間只有56位DES是相同的。這就使得若是它們想要互操做的話，56位DES必須被啓用，雖然這樣作的風險是衆所周知的。這個問題後來被1.3版本的MIT Kerberos 5解決了。這個版本加入了對RC4-HMAC的支持，這個算法也被Windows支持，而且比DES更加安全。在Kerberos支持的算法中(可是不被Windows支持)，3DES和更新的AES128和AES256值得一提(譯註：這些算法的安全性都還說得過去，三者之間AES256是最強的，一般AES128已經夠用，而3DES的加解密速度會比較慢。對於JDK，AES256須要下policy文件才能使用)。

1.3.4.2 密鑰

在前邊提到過，Kerberos的一個目標就是防止用戶的密碼被以未加密的形式存儲，即便是在認證服務器的數據庫裏。考慮到不一樣的加密算法使用不一樣的密鑰長度，那麼，很明顯的就是不能強制用戶爲每一個加密算法指定一個符合它們長度要求的密碼。由於這個緣由，Kerberos引入了string2key函數，這個函數會所未加密的密碼轉化成符合加密算法要求的長度的密鑰。這個函數在每次用戶更改密碼或者用密碼進行驗證時都會被調用。string2key被稱做一個哈希函數，意思是它是不可逆的：知道密鑰是不可以推出來生成它時使用的密碼的(除了暴力破解)。最著名的哈希算法是MD5和CRC32.(譯註：另外一個著名的哈希算法是SHA系列。CRC32只能生成32位的摘要，所以一般用於作校驗碼。而MD5有126，SHA1有160位，理論上，消息摘要的長度越大，碰撞的可能性越小)。

 

1.3.4.3 鹽  Salt

Kerberos5, 不一樣於Kerberos 4, 引用於密碼鹽(password salt)的概念。鹽被加到密碼的明文的後面，而後再經過string2key函數來獲取密鑰。Kerberos 5使用用戶的principal做爲鹽：

Kpippo = string2key ( Ppippo + "pippo@EXAMPLE.COM" )

這種形式的鹽有如下的優勢：

• 屬於同一個realm的兩個principal，即便有相同的密碼，也會有不一樣的密鑰。好比，若是一個管理員有一個principal用於平常工做(pippo@EXAMPLE.COM)，另外一個用於管理工做(pippo/admin@EXAMPLE.COM)。極可能這個用戶爲了方便，給兩個principal設置了相同的密碼。這種形式的鹽的使用確保了有關聯的密鑰是不一樣的。
• 若是一個用戶有兩個在不一樣的realm中的帳戶，那麼一個廣泛的狀況就是這兩個帳戶的密碼是相同的：感謝salt的存在，這樣即便一個realm中的賬戶被攻破了，也不會自動異致另外一個realm中的帳戶被攻破。

 

在Kerberos 5中，也能夠指定不用salt，以和Kerberos 4兼容。一樣，爲了和AFS兼容，也能夠用配置salt不用principal的完整的名字，而只使用cell的名字。

 

在 討論了加密類型，string2key，salt以後，就能夠檢查一下下面的說法準確性了：爲了在不一樣的Kerberos實現之間相行互操做，它們擁有相同的加密算法還不夠，它們還必須有相同的string2key和salt。

另外一點須要注意的是，在解釋string2key和salt的時候，咱們只是提了用戶principal，而沒有提server principal。緣由很明顯：一個服務，即便和驗證服務器共享一個祕密，也不會使用 一個未加密的密碼(誰來輸入這個密碼呢？)(譯註：這倒不必定...), 而是一個由管理員生成的密鑰，這個密鑰被存儲(譯註：原文是memorized)在提供服務的服務器上。

 

1.3.4.4 密鑰版本號(kvno)

當用戶修改密碼或者管理員爲應用服務器升級密鑰的時候，這個修改會被以增長計數器計數的形式記錄下來。計數器的當前值 表示密鑰的版本，這被稱爲Key Version Number, 或者簡稱爲kvno.

 

1.3.4 密鑰分發中心(KDC)

咱們以前講的大都是認證服務器(authentication server)。由於它是用戶和服務進行身份認證時須要基礎組件，所以咱們如今還更深刻地看一下它，可是咱們不會講解它的操做的全部細節，對這些細節的講解是講解Kerberos協議那個主題提一節所要作的。

在Kerberos環境中，認證服務器（Authentication Server），因爲它具備分發ticket的功能，被稱爲密鑰分發中心(Key Distribution Center)，或者簡稱爲KDC。由於它整個在一個物理的服務器上(一般就是一個進程)，因此它能夠從邏輯上分紅三部分：數據庫，認證服務器(Authentication Server)和票據分發服務器(Ticket Granting Server)。讓咱們簡要地分別介紹一下它們。

注意：可使得一個realm中有Master/Slave形式的冗餘服務器(在MIT和Heimdal中),或者Multimaster結構(在Windows Active Directory中)。如何得到冗餘並無在Kerberos協議中指定，而是由Kerberos的實現本身肯定，所以這裏不進行討論

 

1.3.5.1 數據庫

數據庫是與用戶和服務有關的條目(entry)的容器。咱們用principal(也就是條目的名字)來引用一個條目，儘管一般principal這個術語被用和條目混用。每一個條目包括如下的信息：

• 與這個條目相關聯的principal
• 密鑰和相關的kvno（譯註: 注意這裏並非密碼，而是密碼）;
• 與這個principal相關聯的ticket最長可用時間
• 與這個principal相關聯的ticket的最長的renew時間(譯註：是指這個ticket經過renew機制累計可用的時間)(只在kerberos 5中可用)
• 決定這個ticket的具體行爲的屬性和標誌位。
• 密碼過時時間
• 這個principal的過時時間，在此以後就不爲這個principal分發ticket了。

爲了使得竊取數據庫中的密鑰更加因難，Kerberos的實現們使用master key來對數據庫進行加密，master key被關聯在K/M@REALM這個principal上。即便是數據庫的dump,備份和master KDC到salve KDC的propagation也會被用這個密鑰加密，所以，若是想要從新加載它們，就必須知道這個密鑰。

1.3.5.2 AS

AS是KDC是一部分，它用於回覆用戶初始的認證請求，當用戶沒有被認證時，他必須輸入密碼(譯註：也可使用keytab)。做爲對認證請求的響應，AS分發一個特殊的ticket，被稱爲Ticket Granting Ticket，簡稱爲TGT，與TGT相關聯的principal是krbtgt/REALM@REALM(譯註：意思是TGT使用krbtgt/REALM＠REALM這個principal的密鑰來加密)。若是用戶的確具備他們所聲稱的身份(將下來咱們會看一下他們是怎麼證實這個的)，它們就可使用TGT來獲取其它服務的ticket，而不是從新輸入密碼。

 

1.3.5.3 TGS

KDC的TGS組件用於爲擁有可用的TGT的客戶端分發service ticket，它能夠確保請求一個應用服務器上的資源的身份的真僞(譯註：意思是，TGS能夠確保訪問服務的人的身份是真實的)。TGS能夠被當作是一個應用服務器(application server)(由於訪問它必須要使用TGT)，它被用來提供給其它服務分發ticket的服務。這裏不能把TGT和TGS的後綴：第一個表示ticket，第二個表示service。

 

1.3.6  會話密鑰 Session Kery

就像咱們所看到的同樣，用戶和服務和KDC共享一個祕密。對於用戶來講，這個祕密就是從密碼推導出來的密鑰，對於服務來講，就是密鑰(由管理員指定)。這些密鑰被稱爲長期密鑰(long term)，由於在工會話程改變時，它們是不變的。可是，用戶和服務間也有必要共享祕密，至少當用戶和服務之間存在工做會話的時候：這個密鑰在KDC分發ticket時候生成，稱爲Session Key。分發給服務的session key被KDC封裝在ticket中(應用服務器擁有long term key，所以能夠從ticket中解碼出session key)，分發給用戶的session key被使用用戶的長期密鑰加密封裝。Session key在認證用戶的身份真僞上起了基礎性的角色，咱們在接下來的章節中會看到這點。

 

1.3.7 Authenticator

(譯註：這一段對於理解Kerberos認證流程的設計原理很是很是重要)

儘管ticket中含有用戶的principal信息，而且只有應用服務器能夠獲取和(可能)管理這些信息(由於ticket被用服務的密鑰加密)，但這不足以保證用戶身份的真僞。一個冒名頂替者能夠在一個合法的客戶端嚮應用服務器發送ticket時捕捉(記住Kerberos的假設是在一個開放以及不安全的網絡)這個ticket，而且在適當的時候發送它，來非法獲取服務。另外一方面，在ticket中包含可使用這個ticket的ip地址並非很是有用：衆所周知的是在一個開放和不安全的網絡環境中，網各地址能夠很容易地僞造。

爲了解決這個問題，咱們必須利於一個事實：客戶端和服務器至少在一個公話中共享會話密鑰，而且只有它們知道這個密鑰(KDC也知道，由於正是KDC產生了這個密鑰，可是根據定義，KDC必定是可信的！！！)。所以，如下的策略被採用:  和包含ticket的請求一塊兒，客戶端添加了另外一個包(就是authenticator)，用戶的principal和時間戳(當時的時間)被用session key加密後放在這個包裏；提供服務的服務器在收到這個請求後，解開第一個包，獲取session key，若是用戶的確是他/她所聲稱，那麼服務器就能夠解密authenticator，而且提取時間戳。若是這個時間戳和服務器的時間相差在兩分種之內(這個值 是能夠配置 的)，那麼這個認證成功。這個時間給同一個realm中的服務器的同步劃了一個底線。(譯註：以上的邏輯並不足以阻止攻擊者的重放攻擊。攻擊者能夠竊聽客戶最終向服務器發送的信息，即加密後的ticket和authenticator，而後接下來重放這些信息給服務器。實際上，Kerberos協議有有制能夠阻止這種攻擊。就是服務器不只會檢查authenticator中的時間戳，還會檢查它是否曾經見到過這個authenticator。以上這些也代表了Kerberos自己並不能保證客戶端和服務器之間傳遞的消息並不會被竊聽，要作到這點，須要對兩者創建鏈接以後的通信進行加密。）

 

1.3.8 Replay Cache

如下的可能性仍然存在：一個冒名頂替者同時竊取了ticket和authenticator,而且authenticator可用的2分鐘內使用它。這很難，但不是不可能。爲了在Kerberos 5中解決這個問題，引入了Replay Cache。應用服務器application server(也在TGS中)能夠記住過去兩分種內到達的authenticator，而且拒絕重複的authenticator。只有冒名頂替者沒有能力在合法請求到達前複製ticket和authenticator而後發送它們到service，他的攻擊就不能得逞。若是他可以作到的話，那麼真正的用戶就會被拒絕，而冒名頂替者將會成功獲取服務

1.3.9  Credential Cache

客戶端從不保存用戶的密碼，也不會記住 它經過string2key得到的密鑰：密鑰被用於解密KDC的回覆而且被當即丟棄。可是，另外一方面，爲了實現單點登陸(singl e sign-on)功能，也就是說用戶在一個工做會話中只被要求輸入一次密碼，必需要存儲ticket和相關的會話密鑰。這些數據被存儲的地方叫作"Credential Cache". 這個cache的位置並不禁kerberos協議來指定，而是由它的實現來決定。一般爲了可移值性的緣由，這個cache被放在文件系統中(MIT和Heimdal)。在其它的實現中(AFS和  Active Directory)，爲了增長脆弱的客戶端的安全性，credential cache被放在了一個只有內核 才能訪問的內存區域，而且不會被交換到磁盤。