談談基於Kerberos的Windows Network Authentication[下篇]

來源:互聯網
上載者:User

六、User2User Sub-Protocol:有效地保障Server的安全

通過3個Sub-protocol的介紹,我們可以全面地掌握整個Kerberos的認證過程。實際上,在Windows 2000時代,基於Kerberos的Windows Authentication就是按照這樣的工作流程來進行的。但是我在上面一節結束的時候也說了,基於3個Sub-protocol的Kerberos作為一種Network Authentication是具有它自己的局限和安全隱患的。我在整篇文章一直在強調這樣的一個原則:以某個Entity的Long-term Key加密的資料不應該在網路中傳遞。原因很簡單,所有的密碼編譯演算法都不能保證100%的安全,對加密的資料進行解密只是一個時間的過程,最大限度地提供安全保障的做法就是:使用一個Short-term key(Session Key)代替Long-term Key對資料進行加密,使得惡意使用者對其解密獲得加密的Key時,該Key早已失效。但是對於3個Sub-Protocol的C/S Exchange,Client攜帶的Ticket卻是被Server Master Key進行加密的,這顯現不符合我們提出的原則,降低Server的安全係數。

所以我們必須尋求一種解決方案來解決上面的問題。這個解決方案很明顯:就是採用一個Short-term的Session Key,而不是Server Master Key對Ticket進行加密。這就是我們今天要介紹的Kerberos的第4個Sub-protocol:User2User Protocol。我們知道,既然是Session Key,僅必然涉及到兩方,而在Kerberos整個認證過程涉及到3方:Client、Server和KDC,所以用於加密Ticket的只可能是Server和KDC之間的Session Key(SKDC-Server)。

我們知道Client通過在AS Exchange階段獲得的TGT從KDC那麼獲得訪問Server的Ticket。原來的Ticket是通過Server的Master Key進行加密的,而這個Master Key可以通過Account Database獲得。但是現在KDC需要使用Server和KDC之間的SKDC-Server進行加密,而KDC是不會維護這個Session Key,所以這個Session Key只能靠申請Ticket的Client提供。所以在AS Exchange和TGS Exchange之間,Client還得對Server進行請求已獲得Server和KDC之間的Session Key(SKDC-Server)。而對於Server來說,它可以像Client一樣通過AS Exchange獲得他和KDC之間的Session Key(SKDC-Server)和一個封裝了這個Session Key並被KDC的Master Key進行加密的TGT,一旦獲得這個TGT,Server會緩衝它,以待Client對它的請求。我們現在來詳細地討論這一過程。


基本上翻譯了基於User2User的認證過程,這個過程由4個步驟組成。我們發現較之我在上面一節介紹的基於傳統3個Sub-protocol的認證過程,這次對了第2部。我們從頭到尾簡單地過一遍:

  1. AS Exchange:Client通過此過程獲得了屬於自己的TGT,有了此TGT,Client可憑此向KDC申請用於訪問某個Server的Ticket。
  2. 這一步的主要任務是獲得封裝了Server和KDC的Session Key(SKDC-Server)的屬於Server的TGT。如果該TGT存在於Server的緩衝中,則Server會直接將其返回給Client。否則通過AS Exchange從KDC擷取。
  3. TGS Exchange:Client通過向KDC提供自己的TGT,Server的TGT以及Authenticator向KDC申請用於訪問Server的Ticket。KDC使用先用自己的Master Key解密Client的TGT獲得SKDC-Client,通過SKDC-Client解密Authenticator驗證寄件者是否是TGT的真正擁有者,驗證通過再用自己的Master Key解密Server的TGT獲得KDC和Server 的Session Key(SKDC-Server),並用該Session Key加密Ticket返回給Client。
  4. C/S Exchange:Client攜帶者通過KDC和Server 的Session Key(SKDC-Server)進行加密的Ticket和通過Client和Server的Session Key(SServer-Client)的Authenticator訪問Server,Server通過SKDC-Server解密Ticket獲得SServer-Client,通過SServer-Client解密Authenticator實現對Client的驗證。

這就是整個過程。

七、Kerberos的優點

分析整個Kerberos的認證過程之後,我們來總結一下Kerberos都有哪些優點:

1.較高的Performance

雖然我們一再地說Kerberos是一個涉及到3方的認證過程:Client、Server、KDC。但是一旦Client獲得用過訪問某個Server的Ticket,該Server就能根據這個Ticket實現對Client的驗證,而無須KDC的再次參與。和傳統的基於Windows NT 4.0的每個完全依賴Trusted Third Party的NTLM比較,具有較大的效能提升。

2.實現了雙向驗證(Mutual Authentication)

傳統的NTLM認證基於這樣一個前提:Client訪問的遠端Service是可信的、無需對於進行驗證,所以NTLM不曾提供雙向驗證的功能。這顯然有點理想主義,為此Kerberos彌補了這個不足:Client在訪問Server的資源之前,可以要求對Server的身份執行認證。

3.對Delegation的支援

Impersonation和Delegation是一個分布式環境中兩個重要的功能。Impersonation允許Server在本地使用Logon 的Account執行某些操作,Delegation需用Server將logon的Account帶入到另過一個Context執行相應的操作。NTLM僅對Impersonation提供支援,而Kerberos通過一種雙向的、可傳遞的(Mutual 、Transitive)信任模式實現了對Delegation的支援。

4.互通性(Interoperability)

Kerberos最初由MIT首創,現在已經成為一行被廣泛接受的標準。所以對於不同的平台可以進行廣泛的互操作。

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

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

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.