二、關於Kerberos
（有一些細節沒有描述，如時間戳）
Kerberos能提供身份認證、數據完整性和數據私有性。 |
1、 產生：MIT
2、 名字起源：守護地獄的三隻狗
3、 基礎：單密鑰加密技術
a) 加密解密使用同一密鑰（密鑰就是有一定長度的字符串）
b) 最大的問題就是密鑰分發問題
c) 常使用的算法：DES ,Triple-DES ,RC2 ,RC4
4、 Kerberos中的密鑰分發方法和交互登陸方法
口令密鑰：用戶登陸時使用
動態密鑰：使用其他服務時使用
1) 用戶登錄
a) 口令密鑰是用戶密碼的散列值，散列是單向的。
b) 服務器方面並不保存用戶口令的明文，而是保存口令的散列值
單密鑰如何提供身份認證？ 如果你和我共享一個密鑰，我給你發個用此密鑰加密的信息，如果你用這個密鑰解開了信息並且與我發的信息相同，就表明了我身份。 我不需要傳遞密鑰。 |
c) 這個加密的信息稱爲Ticket：Ticket是用一些明文信息和用自己的密鑰加密的密文組合的一個數據結構。其中包含的重要信息有：明文中有用戶名；密文中有Ticket標誌、會話密鑰、用戶名、時間戳、地址、令牌；
在進行身份認證時Ticket中的明文包含用戶名，密文中也包含用戶名，所以服務器在得到某個用戶認證時查找明文中指出的用戶的服務器端的口令散列密鑰並用它解密，如果密文中的用戶名和當前用戶名相同就可以認定此用戶是合法用戶。 |
d) 其他名詞
KDC：密鑰分發中心，動態生成會話密鑰
KX：密鑰，x的私鑰
{anyting} KX：用x的私鑰加密後的信息
{T}KX：用x的私鑰加密後的證書
KX,y：x和y的會話密鑰
{anyting} KX,y：用x和y的會話密鑰加密後的信息
e) 用戶第一次登陸到服務器
客戶方發送Ticket中包含明文的用戶名和加密的用戶名、時間戳和等KDC接收到請求後按以前說過的方法進行用戶的身份認證。
如果用戶身份已經驗證並正確那麼KDC發送給客戶端兩部分內容。第一部分爲KDC動態產生一個客戶和KDC以後要進行會話的會話密鑰Kk，c，並用KDC的密鑰Kk 將Kk，c 和客戶的一些信息保存成爲一個TGT，即{TGT}Kk。第二部分爲用客戶的KC將Kk，c 進行加密，即{ Kk，c }KC。
客戶收到此Ticket後用自己的KC解密後可得到Kk，c
以後客戶有請求時（下一節描述的第一個過程），將請求的內容用會話密鑰進行加密並將{TGT}Kk連接發送過去KDC用Kk解開{TGT}Kk後得到Kk，c 並用它來解開用戶請求的內容。
2) 使用其他服務
a) 用戶使用某種資源時必須獲得指向該服務的Ticket，因爲這Ticket中包含了用戶和服務進行通訊的會話密鑰。
b) 請求專門用來發放Ticket的Ticket叫TGT（Ticket-Granting Ticket）。
c) 客戶與使用服務S的安全資源時的認證過程如下：
用戶用與KDC會話的密鑰Kk，c加密與服務器S連接的請求，並附帶KDC以前傳來的{TGT}Kk
KDC接收{TGT}Kk{Authenticator}Kc，k
Ticket後用自己的密鑰Kk解開{TGT}Kk 從TGT中取出會話密鑰Kc，k再用它解開{Authenticator}Kc，k得到客戶要與服務S連接的信息（間接的表明KDC不保存會話密碼，以後的服務相同），之後創建新的客戶與服務S會話的密鑰Ks，k並查找服務S的密鑰對其它和其它信息加密形成{T}Ks，再把會話密鑰用Kc，k進行加密發送給客戶端。
客戶接收後用Kc，k解開{Kc，s}Kc，k從中取出客戶與服務S進行會話的密鑰，並將請求的服務用它加密，附上KDC傳來的{T}Ks傳給S服務器。S服務器根據自己的密鑰Ks將{T}Ks解開從T中得到會話密鑰Kc，s ，用它解開{Authenticator}Kc，s 得到客戶的請求並根據客戶的令牌的能力提供服務。
數據完整性：使用MD5對發送的消息和其他信息計算校驗和並用RC4算法用會話密鑰進行加密。 |
數據私有性：用會話密鑰進行加密後只有數據傳輸的雙方知道密鑰。 |
5、 雙向認證
客戶如何確定服務器就是它所聲稱的服務器呢？
可能一個僞裝的服務器做出一個這樣的Ticket。
在這一步中客戶可以得到會話密鑰，而且TGT中也包含這個會話密鑰Kc，k所以如果知道KDC的密鑰Kk就可以知道KDC是否也知道會話密鑰了，就確定了服務器的身份。也就是說如果進行雙向認證必須得知道KDC口令（服務器雷同）。
