密鑰分發(fā)中心（KDC）
密鑰分發(fā)中心是一種運行在物理安全服務器上的服務胸蛛，KDC維護著領域中所有安全主體賬戶信息數(shù)據(jù)庫。
與每一個安全主體的其他信息一起，KDC存儲了僅安全主體和KDC知道的加密密鑰，這個密鑰也稱長效密鑰（主密鑰）衫哥，用于在安全主體和KDC之間進行交換。
KDC是作為發(fā)起方和接收方共同信任的第三方襟锐，因為他維護者一個存儲著該域中所有賬戶的賬戶數(shù)據(jù)庫撤逢，也就是說，他知道屬于每個賬戶的名稱和派生于該賬戶密碼的Master Key（主密鑰）。而用于Alice和Bob相互認證的會話密鑰就是由KDC分發(fā)的蚊荣，下面詳細講解KDC分發(fā)會話密鑰的過程初狰。
分發(fā)會話密鑰過程
1、首先客戶端向KDC發(fā)送一個會話密鑰申請互例。這個申請的內容可以簡單概括為”我是某客戶端奢入，我需要個Session Key用于與某服務器通話“。
2媳叨、KDC在接收到這個請求的時候腥光，生成一個會話密鑰。為了保證這個會話密鑰僅僅限于發(fā)送請求的客戶端和它希望訪問的服務器知道糊秆，KDC會為這個會話密鑰生成兩個副本武福，分別被客戶端和服務器使用。然后從賬戶數(shù)據(jù)庫中提取客戶端和服務器的主密鑰分別對這兩個副本進行對稱加密痘番。對于服務器捉片，與會話密鑰一起被加密的還包含關于客戶端的一些信息，以便對發(fā)起連接請求的客戶端進行身份認證汞舱。
注意：KDC不是直接把這兩個會話密鑰副本分發(fā)客戶端和服務器的伍纫，因為如果這樣做，對于服務器來說會
出現(xiàn)下面兩個問題昂芜。由于一個服務器會面對若干不同的客戶端莹规，而每個客戶端都具有一個不同的Session
Key。那么服務器就會為所有的客戶端維護這樣一個會話密鑰的列表泌神，這樣對服務器來說工作量就非常
大了访惜。由于網(wǎng)絡傳輸?shù)牟淮_定性，可能會出現(xiàn)這樣一種情況：客戶端很快獲得會話密鑰用于副本腻扇，并將
這個會話密鑰作為憑據(jù)隨同訪問請求發(fā)送到服務器，但是用于服務器的會話密鑰卻還沒有收到砾嫉，并且很
有可能這個會話密鑰永遠也到不了服務器端幼苛，這樣客戶端將永遠得不到認證。為了解決這個問題焕刮，
Kerberos將這兩個被加密的副本一同發(fā)送給客戶端舶沿，屬于服務器的那份由客戶端發(fā)送給服務器。因為
這兩個會話密鑰副本分別是由客戶端和服務器端的主密鑰加密的配并，所以不用擔心安全問題括荡。
3、通過上面的過程溉旋，客戶端實際上獲得了兩組信息：一個是通過自己主密鑰加密的會話密鑰畸冲；另一個是被Server的主密鑰加密的數(shù)據(jù)包，包含會話密鑰和關于自己的一些確認信息。在這個基礎上邑闲，我們再來看看服務器是如何對客戶端進行認證的算行。
4、客戶端通過用自己的主密鑰對KDC加密的會話密鑰進行解密從而獲得會話密鑰苫耸，隨后創(chuàng)建認證符（Authenticator州邢，包括客戶端信息和時間戳（Timestamp）），并用會話密鑰對其加密褪子。最后連同從KDC獲得的量淌、被服務器的主密鑰加密過的數(shù)據(jù)包（客戶端信息和會話密鑰）一并發(fā)送到服務器端。我們把通過服務器的主密鑰加密過的數(shù)據(jù)包稱為服務票證（Session Ticket）嫌褪。
5呀枢、當服務器接收到這兩組數(shù)據(jù)后，先使用它自己的主密鑰對服務票證進行解密渔扎，從而獲得會話密鑰硫狞。隨后使用該會話密鑰解密認證符，通過比較由客戶端發(fā)送來的認證符中的客戶端信息（Client Info）和服務票證中的客戶端信息實現(xiàn)對客戶端身份的驗證晃痴。
雙方進行了身份認證的同時也獲得了會話密鑰残吩，那么雙方可以進行會話了。
流程圖如下：
客戶端簡稱為Alice倘核，服務端簡稱為Bob
