Kerberos的整個(gè)架構(gòu)比較復(fù)雜，但是基本精神就是上面的兩個(gè)推論和第三方認(rèn)證。如果接下來的內(nèi)容令你感到困惑，建議回頭看看這個(gè)基本精神，相信很多問題可以迎刃而解。

我們的域里有一臺(tái)Windows客戶機(jī)，一臺(tái)KDC(即權(quán)威第三方)，還有一臺(tái)NAS?，F(xiàn)在我們來看看用戶甲從和KDC互相認(rèn)證到訪問NAS的整個(gè)過程。

一. 用戶甲與KDC相互認(rèn)證：

1. 用戶甲在客戶機(jī)的登陸界面上輸入用戶名，密碼和域名?？蛻魴C(jī)上有個(gè)叫LSA的服務(wù)將處理這些輸入信息。

2. LSA利用hash函數(shù)把用戶密碼轉(zhuǎn)化為密鑰Kclt，再用Kclt來加密即將發(fā)給KDC的信息，這些加密的信息稱為Authenticator。隨著 Authenticator一起被發(fā)送的還有一些明文信息。LSA發(fā)送給KDC的這些信息就是Kerberos的身份認(rèn)證請(qǐng)求，稱為 KRB_AS_REQ。

Authenticator:{用戶甲相關(guān)信息，時(shí)間戳}Kclt

Note: 這表示大括號(hào)里的內(nèi)容被Kclt加密后成為Authenticator，本文將一直用這種格式來表示。

KRB_AS_REQ：“我是用戶甲”，Authenticator

Note: 這表示KRB_AS_REQ由明文“我是用戶甲”和Authenticator組成，本文將一直用這種格式來表示。

3. KDC收到KRB_AS_REQ之后，只能讀出明文部分“我是用戶甲”。于是便從數(shù)據(jù)庫中找出甲的密碼，用同樣的hash函數(shù)轉(zhuǎn)化為Kclt。然后KDC 就可以用Kclt解開Authenticator，得到{用戶甲相關(guān)信息，時(shí)間戳}。如果用戶甲的相關(guān)信息確認(rèn)無誤，則可認(rèn)為這請(qǐng)求是甲生成的(推論 2)。如果時(shí)間戳在規(guī)定時(shí)間內(nèi)，則可排除重演攻擊，因?yàn)殡y以在這么短時(shí)間里截獲KRB_AS_REQ并在另一臺(tái)客戶機(jī)偽裝起來。

4. KDC認(rèn)證了甲的身份后，本來可以回復(fù)“{時(shí)間戳}Kclt” 來完成相互認(rèn)證(時(shí)間戳是從Authenticator中解密出來的，可以證明KDC有解密的能力)。但這樣做不夠完美，因?yàn)榻酉聛碛脩艏自谡?qǐng)求KDC做 第三方認(rèn)證時(shí)，信息還得用Kclt加密。用戶每用一次Kclt，KDC就得從數(shù)據(jù)庫取一次密碼來解密，這對(duì)KDC來說是一個(gè)不小的負(fù)擔(dān)。為了解決這個(gè)問 題，KDC先隨機(jī)生成兩把一樣的Kclt-kdc，作為以后用戶甲和KDC共享的密鑰。其中一把直接交給了用戶甲，另一把KDC需要自己使用，但是又不想 保管它。所以KDC利用自己的密鑰Kkdc把它加密起來，成為一個(gè)只有KDC才能打開的ticket，然后一并交給用戶甲保管。這個(gè)ticket叫 Ticket-Granting Ticket(TGT)。KDC給用戶甲回復(fù)的這些信息就是KRB_AS_REP。

TGT：{用戶甲相關(guān)信息，Kclt-kdc}Kkdc

KRB_AS_REP：{Kclt-kdc,時(shí)間戳}Kclt，TGT

5. LSA收到KRB_AS_REP之后，先用Kclt解開第一部分，得到Kclt-kdc和時(shí)間戳。由時(shí)間戳可知KDC有解密能力，從而確認(rèn)KDC身份(推論1)。至此用戶甲和KDC終于相互認(rèn)證了。接下來LSA和KDC都摧毀Kclt，因?yàn)椴辉傩枰恕?/p>

在上面這個(gè)過程中，客戶機(jī)只是輔助用戶甲和KDC相互認(rèn)證，它自身并沒有被認(rèn)證。KDC在認(rèn)證結(jié)束后，仍然只保管Kkdc，沒有增加負(fù)擔(dān)。用戶甲則獲得了Kclt-kdc和TGT，相當(dāng)于重復(fù)向KDC請(qǐng)求認(rèn)證的能力。

二. 用戶甲登陸到客戶機(jī)，這個(gè)過程和接下來用戶甲訪問NAS很相似，不作詳述。

三. 用戶甲訪問NAS：

1. 用戶甲向KDC請(qǐng)求訪問NAS的Ticket。這個(gè)請(qǐng)求在Kerberos里被稱為KRB_TGS_REQ。

KRB_TGS_REQ：TGT，{用戶甲相關(guān)信息，時(shí)間戳}Kclt-kdc，“NAS相關(guān)信息”

2. KDC收到KRB_TGS_REQ后，先用Kkdc解開TGT，得到Kclt-kdc。再用Kclt-kdc解開加了密的第二部分，得到用戶甲相關(guān)信息和 時(shí)間戳，由此確定這不是假冒請(qǐng)求或者重演攻擊。接下來KDC隨機(jī)生成兩把一樣的Kclt-nas，一把用Kclt-kdc加密，另一把用Knas加密成為 Ticket，一并發(fā)給用戶甲。這個(gè)Ticket和Kclt-nas將用于用戶甲與NAS的相互認(rèn)證。這就是Kerberos里的 KRB_TGS_REP。

Ticket:{用戶甲的組信息，Kclt-nas}Knas

Note:因?yàn)門icket可以重復(fù)使用，所以一旦生成后，用戶甲屬于哪個(gè)組就確定了。如果在域里更改了甲的組設(shè)置，需要讓用戶甲重新登陸一次才能生效。

KRB_TGS_REP：{Kclt-nas}Kclt-kdc，Ticket

3. 用戶甲收到KRB_TGS_REP之后，先用Kclt-kdc解密第一部分得到Kclt-nas。然后用它來建立Authenticator。最后把Authenticator和Ticket一起組成KRB_AP_REQ發(fā)給NAS。

Authenticator: {用戶甲相關(guān)信息，時(shí)間戳}Kclt-nas

KRB_AP_REQ: Authenticator，Ticket

4. NAS收到KRB_AP_REQ之后，先用Knas解密Ticket，得到了Kclt-nas和甲的組信息。再用Kclt-nas解密Authenticator。如果這些信息沒有問題，那NAS就可以允許甲的訪問，即回復(fù)KRB_AP_REP給用戶甲。

KRB_AP_REP：{時(shí)間戳}Kclt-nas

5. 用戶甲收到時(shí)間戳后，即可確認(rèn)這臺(tái)NAS的身份(因?yàn)橹挥蠳AS有能力解密得到時(shí)間戳)。

在這個(gè)過程中，其實(shí)還是有重演攻擊的可能。比如復(fù)制整個(gè)KRB_AP_REQ，然后偽裝成用戶甲去訪問NAS。對(duì)此問題，Kerberos除了利用 時(shí)間戳來限制偽造時(shí)間，還利用cache功能確保每個(gè)authenticator都只能使用一次。這就大大降低了被攻擊的可能。

如果上面的過程太瑣碎，看看右邊的圖片也許有助于理解和總結(jié)。我個(gè)人的學(xué)習(xí)習(xí)慣是什么協(xié)議都要抓個(gè)包來研究。下圖展示了用戶linp1在登陸 10.32.106.116時(shí)，和KDC 10.32.106.103的通信過程。被選定的包是KRB_AS_REP，可以從中看到(Ticket-Granting)Ticket。

wangzhen