[原創]談談基於Kerberos的Windows Network Authentication – Part II

四、引入Ticket Granting  Service

通過上面的介紹，我們發現Kerberos實際上一個基於Ticket的認證方式。Client想要擷取Server端的資源，先得通過Server的認證；而認證的先決條件是Client向Server提供從KDC獲得的一個有Server的Master Key進行加密的Session Ticket（Session Key + Client Info）。可以這麼說，Session Ticket是Client進入Server領域的一張門票。而這張門票必須從一個合法的Ticket頒發機構獲得，這個頒發機構就是Client和Server雙方信任的KDC， 同時這張Ticket具有超強的防偽標識：它是被Server的Master Key加密的。對Client來說， 獲得Session Ticket是整個認證過程中最為關鍵的部分。

上面我們只是簡單地從大體上說明了KDC向Client分發Ticket的過程，而真正在Kerberos中的Ticket Distribution要複雜一些。為了更好的說明整個Ticket Distribution的過程，我在這裡做一個類比。現在的股事很火爆，上海基本上是全民炒股，我就舉一個認股權證的例子。有的上市公司在股票配股、增發、基金擴募、股份減持等情況會向公眾發行認股權證，認股權證的持有人可以憑藉這個權證認購一定數量的該公司股票，認股權證是一種具有看漲期權的金融衍生產品。

而我們今天所講的Client獲得Ticket的過程也和通過認股權證購買股票的過程類似。如果我們把Client提供給Server進行認證的Ticket比作股票的話，那麼Client在從KDC那邊獲得Ticket之前，需要先獲得這個Ticket的認購權證，這個認購權證在Kerberos中被稱為TGT：Ticket Granting Ticket，TGT的分發方仍然是KDC。

我們現在來看看Client是如何從KDC處獲得TGT的：首先Client向KDC發起對TGT的申請，申請的內容大致可以這樣表示：“我需要一張TGT用以申請擷取用以訪問所有Server的Ticket”。KDC在收到該申請請求後，產生一個用於該Client和KDC進行安全通訊的Session Key（SKDC-Client）。為了保證該Session Key僅供該Client和自己使用，KDC使用Client的Master Key和自己的Master Key對產生的Session Key進行加密，從而獲得兩個加密的SKDC-Client的Copy。對於後者，隨SKDC-Client一起被加密的還包含以後用於評鑑Client身份的關於Client的一些資訊。最後KDC將這兩份Copy一併發送給Client。這裡有一點需要注意的是：為了免去KDC對於基於不同Client的Session Key進行維護的麻煩，就像Server不會儲存Session Key（SServer-Client）一樣，KDC也不會去儲存這個Session Key（SKDC-Client），而選擇完全靠Client自己提供的方式。

當Client收到KDC的兩個加密資料包之後，先使用自己的Master Key對第一個Copy進行解密，從而獲得KDC和Client的Session Key（SKDC-Client），並把該Session 和TGT進行緩衝。有了Session Key和TGT，Client自己的Master Key將不再需要，因為此後Client可以使用SKDC-Client向KDC申請用以訪問每個Server的Ticket，相對於Client的Master Key這個Long-term Key，SKDC-Client是一個Short-term Key，安全保證得到更好的保障，這也是Kerberos多了這一步的關鍵所在。同時需要注意的是SKDC-Client是一個Session Key，他具有自己的生命週期，同時TGT和Session相互關聯，當Session Key到期，TGT也就宣告失效，此後Client不得不重新向KDC申請新的TGT，KDC將會產生一個不同Session Key和與之關聯的TGT。同時，由於Client Log off也導致SKDC-Client的失效，所以SKDC-Client又被稱為Logon Session Key。

接下來，我們看看Client如何使用TGT來從KDC獲得基於某個Server的Ticket。在這裡我要強調一下，Ticket是基於某個具體的Server的，而TGT則是和具體的Server無關的，Client可以使用一個TGT從KDC獲得基於不同Server的Ticket。我們言歸正傳，Client在獲得自己和KDC的Session Key（SKDC-Client）之後，產生自己的Authenticator以及所要訪問的Server名稱的並使用SKDC-Client進行加密。隨後連同TGT一併發送給KDC。KDC使用自己的Master Key對TGT進行解密，提取Client Info和Session Key（SKDC-Client），然後使用這個SKDC-Client解密Authenticator獲得Client Info，對兩個Client Info進行比較進而驗證對方的真實身份。驗證成功，產生一份基於Client所要訪問的Server的Ticket給Client，這個過程就是我們第二節中介紹的一樣了。

五、Kerberos的3個Sub-protocol：整個Authentication

通過以上的介紹，我們基本上瞭解了整個Kerberos authentication的整個流程：整個流程大體上包含以下3個子過程：

1. Client向KDC申請TGT（Ticket Granting Ticket）。
2. Client通過獲得TGT向DKC申請用於訪問Server的Ticket。
3. Client最終向為了Server對自己的認證向其提交Ticket。

不過上面的介紹離真正的Kerberos Authentication還是有一點出入。Kerberos整個認證過程通過3個sub-protocol來完成。這個3個Sub-Protocol分別完成上面列出的3個子過程。這3個sub-protocol分別為：

1. Authentication Service Exchange
2. Ticket Granting Service Exchange
3. Client/Server Exchange

簡單展示了完成這個3個Sub-protocol所進行Message Exchange。

1． Authentication Service Exchange

通過這個Sub-protocol，KDC（確切地說是KDC中的Authentication Service）實現對Client身份的確認，並頒發給該Client一個TGT。具體過程如下：

Client向KDC的Authentication Service發送Authentication Service Request（KRB_AS_REQ）, 為了確保KRB_AS_REQ僅限於自己和KDC知道，Client使用自己的Master Key對KRB_AS_REQ的主體部分進行加密（KDC可以通過Domain 的Account Database獲得該Client的Master Key）。KRB_AS_REQ的大體包含以下的內容：

• Pre-authentication data：包含用以證明自己身份的資訊。說白了，就是證明自己知道自己聲稱的那個account的Password。一般地，它的內容是一個被Client的Master key加密過的Timestamp。
• Client name & realm: 簡單地說就是Domain name\Client
• Server Name：注意這裡的Server Name並不是Client真正要訪問的Server的名稱，而我們也說了TGT是和Server無關的（Client只能使用Ticket，而不是TGT去訪問Server）。這裡的Server Name實際上是KDC的Ticket Granting Service的Server Name。

AS（Authentication Service）通過它接收到的KRB_AS_REQ驗證發送方的是否是在Client name & realm中聲稱的那個人，也就是說要驗證發送放是否知道Client的Password。所以AS只需從Account Database中提取Client對應的Master Key對Pre-authentication data進行解密，如果是一個合法的Timestamp，則可以證明發送放提供的是正確無誤的密碼。驗證通過之後，AS將一份Authentication Service Response（KRB_AS_REP）發送給Client。KRB_AS_REQ主要包含兩個部分：本Client的Master Key加密過的Session Key（SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大體又包含以下的內容：

• Session Key: SKDC-Client：Logon Session Key
• Client name & realm: 簡單地說就是Domain name\Client
• End time: TGT到期的時間。

Client通過自己的Master Key對第一部分解密獲得Session Key（SKDC-Client：Logon Session Key）之後，攜帶著TGT便可以進入下一步：TGS（Ticket Granting Service）Exchange。

2． TGS（Ticket Granting Service）Exchange

TGS（Ticket Granting Service）Exchange通過Client向KDC中的TGS（Ticket Granting Service）發送Ticket Granting Service Request（KRB_TGS_REQ）開始。KRB_TGS_REQ大體包含以下的內容：

• TGT：Client通過AS Exchange獲得的Ticket Granting Ticket，TGT被KDC的Master Key進行加密。
• Authenticator：用以證明當初TGT的擁有者是否就是自己，所以它必須以TGT的辦法方和自己的Session Key（SKDC-Client：Logon Session Key）來進行加密。
• Client name & realm: 簡單地說就是Domain name\Client。
• Server name & realm: 簡單地說就是Domain name\Server，這回是Client試圖訪問的那個Server。

TGS收到KRB_TGS_REQ在發給Client真正的Ticket之前，先得整個Client提供的那個TGT是否是AS頒發給它的。於是它不得不通過Client提供的Authenticator來證明。但是Authentication是通過Logon Session Key（SKDC-Client）進行加密的，而自己並沒有儲存這個Session Key。所以TGS先得通過自己的Master Key對Client提供的TGT進行解密，從而獲得這個Logon Session Key（SKDC-Client），再通過這個Logon Session Key（SKDC-Client）解密Authenticator進行驗證。驗證通過向對方發送Ticket Granting Service Response（KRB_TGS_REP）。這個KRB_TGS_REP有兩部分組成：使用Logon Session Key（SKDC-Client）加密過用於Client和Server的Session Key（SServer-Client）和使用Server的Master Key進行加密的Ticket。該Ticket大體包含以下一些內容：

• Session Key：SServer-Client。
• Client name & realm: 簡單地說就是Domain name\Client。
• End time: Ticket的到期時間。

Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分後獲得Session Key（SServer-Client）。有了Session Key和Ticket，Client就可以之間和Server進行互動，而無須在通過KDC作中間人了。所以我們說Kerberos是一種高效的認證方式，它可以直接通過Client和Server雙方來完成，不像Windows NT 4下的NTLM認證方式，每次認證都要通過一個雙方信任的第3方來完成。

我們現在來看看 Client如果使用Ticket和Server怎樣進行互動的，這個階段通過我們的第3個Sub-protocol來完成：CS（Client/Server ）Exchange。

3． CS（Client/Server ）Exchange

這個已經在本文的第二節中已經介紹過，對於重複發內容就不再累贅了。Client通過TGS Exchange獲得Client和Server的Session Key（SServer-Client），隨後建立用於證明自己就是Ticket的真正所有者的Authenticator，並使用Session Key（SServer-Client）進行加密。最後將這個被加密過的Authenticator和Ticket作為Application Service Request（KRB_AP_REQ）發送給Server。除了上述兩項內容之外，KRB_AP_REQ還包含一個Flag用於表示Client是否需要進行雙向驗證（Mutual Authentication）。

Server接收到KRB_AP_REQ之後，通過自己的Master Key解密Ticket，從而獲得Session Key（SServer-Client）。通過Session Key（SServer-Client）解密Authenticator，進而驗證對方的身份。驗證成功，讓Client訪問需要訪問的資源，否則直接拒絕對方的請求。

對於需要進行雙向驗證，Server從Authenticator提取Timestamp，使用Session Key（SServer-Client）進行加密，並將其發送給Client用於Client驗證Server的身份。

到此為止，Kerberos的整個過程大體上已經介紹完畢。不知道他們有沒有意識到這其中有什麼安全隱患？我在一開始在介紹Long-term Key和Short-term Key的時候就已經強調過：被Long-term Key加密的資訊最好不要在網路中傳遞，然後Client從KDC獲得的Ticket確是通過Server的Master Key加密的，這顯然對Server來說是不安全的，為瞭解決這個問題，Kerberos引入了第4個Sub-protocol: User2User。關於User2User Protocol，敬請關注本Blog的第三部分。

相關內容：
[原創]談談基於Kerberos的Windows Network Authentication - Part I
[原創]談談基於Kerberos的Windows Network Authentication - Part II
[原創]談談基於Kerberos的Windows Network Authentication - Part III

作者：Artech
出處：http://artech.cnblogs.com
本文著作權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文串連，否則保留追究法律責任的權利。