什麼是Kerberos？

關於Kerberos

什麼是Kerberos？

一句話，Kerberos是一種認證機制。

它的目的：通過密鑰系統爲客戶端/服務器應用程序提供強大的認證服務：保護服務器防止錯誤的用戶使用，同時保護它的用戶使用正確的服務器，即支持雙向驗證；

Kerberos協議的整個認證過程實現不依賴於主機操作系統的認證，無需基於主機地址的信任，不要求網絡上所有主機的物理安全，並假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據。說白了， Kerberos通過傳統的加密技術（共享密鑰）實現了一種可信任的第三方認證服務。

認證授權

認證授權（Anthentication and Authorization）是系統權限管理經常需要考慮的問題，也是一個很複雜的問題，至少我是這樣覺得的。

認證：系統識別某個個體/請求的身份時，稱爲認證；即辨別身份真僞，解決“你是誰”的問題。

授權：系統賦予某個個體從事某種行動的權利，叫做授權；即解決“你能做什麼”的問題。

感覺應該說清楚了，認證未必授權，授權必須認證。

加密術語

上面說過，Kerberos是網絡服務的認證機制，使用加密技術實現認證，這裏再囉嗦下它們之間的關係。

加密：給數據加密，目的是保護數據，強調的是安全性

認證：判斷身份的真實性，目的是辨真僞，強調的是真實性

授權：根據不同的身份給予不同的授權；所以認證（authentication）與授權（authorization）往往是相伴而生。

給出幾個場景，來理解加密技術的一些術語：A爲信息發送方；B爲信息接收方

[密鑰]：就是一個參數，明文轉密文或密文轉明文的算法輸入數據

[對稱加密]（又稱私鑰加密）：加密和解密使用同一個密鑰（secret key）。常見的是使用用戶名密碼方式，例如A爲服務器，存儲了B的用戶名密碼，A發送一段數據給B前使用B的密碼加密，B收到後使用自己的密碼解密。

[非對稱加密]（又稱公鑰加密）：採用公鑰和私鑰的方式，A和B都各有一對公鑰和私鑰；注意，公鑰和私鑰成對出現，一個公鑰對應一個私鑰。

[公鑰]：公開的密鑰，可以公開

[私鑰]：私有的密鑰，只有當事人自己知道

[數字證書]：用來辨別對方身份的，可以簡單理解爲一個被權威性機構驗證過的公鑰。

[數字簽名]：使用私鑰加密的數據叫做數字簽名，採用對應的公鑰來驗證數字簽名，從而確認發送方的身份。

公鑰私鑰的目的：實現信息的安全傳輸：1）A發送給B，信息傳輸過程必須加密，防止別人看；2）B收到後能夠知道肯定是A發送的，而不是有人冒充A。

怎麼實現呢？

場景理解：

1）首先A用B的公鑰加密信息，進行發送，這保證了信息不會被別人看到或修改，B收到後使用B的私鑰解密，就可以看到A發送的信息了。

2）其次，A用A的私鑰給消息加密，B可以用A的公鑰解密，因爲A的私鑰只在A手裏，所以這可以確認信息是A發送的。

由此，可以看出【公鑰私鑰的主要用途】：

1）公鑰加密，對應上述場景中的前半段，重點是加密；實際應用中，公鑰常以數字證書的方式出現，爲了公鑰的安全性和有效性（被權威認證過的）。

2）私鑰加密，即公鑰認證，對應上述場景中的後半段，重點是認證（認證A身份的真實性）；私鑰加密的主要用途就是數字簽名。

現實的痛點：

上面說了大半天，使用公鑰私鑰不就可以實現安全通信麼，A和B要進行安全的通信，互相使用對方的公鑰加密信息，然後使用私鑰解密不就好了。實際情況是，有時候不一定雙方都有公私鑰對；更爲重要的是，使用公私鑰很費時間，很慢，影響通信體驗。SSL應運而生。

[SSL]（security sockets layer）：實際應用中實現安全通信。

簡單理解：SSL就是使用公私鑰約定會話密鑰，然後使用會話密鑰和對稱加密算法（例如DES）進行通信。

[會話密鑰]：A要和B實現安全通信，A使用B的公鑰加密一個密鑰C發給B，B拿到後用私鑰解密後得到密鑰C，以後A和B之間傳輸的信息都使用約定的密鑰C來加密，這個只有約定雙方知道的密鑰C叫做會話密鑰（session key），其中約定會話密鑰的過程叫做握手。

單點登錄

SSO（single sign on）：單點登錄。多系統共存的情況下，用戶一次登錄得到其他所有系統的信任；

單點登錄到處可見，平時在公司上班，公司有多個內部系統，如果每個系統都要輸入用戶名密碼真的是很崩潰的一件事情，登錄一次就可以訪問所有的系統，這就是單點登錄；例如淘寶和天貓是兩個不同的系統，你上淘寶買東西，買好又去天貓買，這個時候就不需要再重新登錄，即單點登錄。

SSO比較經典的解決方案是CAS（central authentication service）：中央認證服務。

CAS的原理和工作流程基本都是參考Kerberos票據的原理，所以也不用去研究CAS原理，直接搞懂Kerberos原理，CAS原理也就通了。

Kerberos術語

KDC（key distribution center）：密鑰發放中心

AS（authentication service）：認證服務，索取credential，發放 TGT

TGS（ticket granting service）：票據授權服務，索取TGT，發放ST

ST（service ticket）：服務票據，由KDC的TGS發放，任何一個應用（application）都需要一張有效的服務票據才能訪問；如果能正確接受ST，說明client和server之間的信任關係已經被建立，通常爲一張數字加密的證書。

TGT（ticket granting ticket）：票據授權票據，由KDC的AS發放；獲得這樣一張票據後，以後申請其他應用的服務票據（ST）時，就不需要向KDC提交身份認證信息（credential），TGT具有一定的有效期，就像是kerberos進行kinit以後只是具有固定時間的有效期，需要不斷的去renew來續約。

上面幾個術語簡單說下它們的關係：KDC由AS和TGS組成，AS進行身份認證發放TGT，TGT是用來避免多次請求而需要重複認證的憑證；TGS發放ST，ST用來訪問某個service時的憑證，ST相當於告訴service你的身份被KDC認證爲合法的一個憑證。可以參考Kerberos原理中所畫的圖來理解這些術語。

Authenticator：驗證器，與票據結合用來證明提交票據的user就是其所聲明的身份，內容包括{user, address, start_time, lifetime}，這些內容使用user和service之間的session key加密；驗證器是user客戶端自己構建，只能“被使用一次”。

Kerberos原理

爲什麼要有Kerberos這樣一箇中央認證機制？

既然認證就是辨別身份，那我輸入用戶名密碼不就好了，爲何要有Kerberos這樣一個複雜的東西；

舉例來說，有A，B，C三個服務器，分別提供不同的服務，user要訪問ABC都需要輸入用戶名密碼，但是ABC沒必要都存一份user的密碼，所以就衍生出一箇中央服務器D來專門存儲用戶名密碼；如果user通過了D的認證，那就是合法的身份，就可以使用ABC任何一個服務，所以user需要告訴ABC它通過了D的認證。

如何證明這個事情，以及信息在網絡傳輸過程如何防止被截獲篡改而假冒等等，解決這些問題就靠Kerberos，強烈推薦閱讀MIT經典對話，可以理解協議中每條信息有什麼字段，爲何要設置這個字段等。

這個部分簡單總結下Kerberos協議的認證流程，只有幾步，詳細的請參見 [經典對話手記] 來細緻理解。

認證流程：

User向KDC中的AS請求身份驗證，AS爲user和TGS生成一個session key：SK_TGS，併發送{ TGT, SK_TGS } K_USER；

其中，{TGT, SK_TGS}K_USER表示使用user的密碼加密的packet，包含了TGT和用戶與TGS的session key；這個請求驗證的過程實際上是使用kinit來完成的，kinit將username傳給AS，AS查找username的密碼，將TGT和SK_TGS使用用戶密碼加密後發送給kinit，kinit要求用戶輸入密碼，解密後得到TGT和SK；其中，TGT使用TGS的密碼加密，信息內容爲{ user, address, tgs_name, start_time, lisftime, SK_TGS} K_TGS

User向KDC中的TGS請求訪問某個Service的ST，發送[ TGT, Authenticator ]；

其中，Authenticator用於驗證發送該請求的user就是TGT中所聲明的user，內容爲：{ user, addresss, start_time, lifetime}；Authenticator使用的TGS和user之間的session key加密的，防止TGT被盜。TGS先使用自己的密碼解開TGT獲得它與user之間的session key，然後使用session key解密Authenticator，驗證用戶和有效期。

TGS判斷無誤後，爲user和Service之間生成一個新的session key：SK_Service；然後發送給user一個包：[ {SK_Service} SK_TGS, ST ]；

其中，ST是使用Service的密碼加密的，SK_Service使用TGS和user之間的session key加密的；ST的內容爲：{ user, address, start_time, lifetime, SK_Service } K_Service

User使用與TGS之間的會話祕鑰解開包得到與Service之間的會話祕鑰SK_Service，然後使用SK_Service生成一個Authenticator，向Service發送[ ST, Authenticator ]；

其中，此處的Authenticator是使用user和service之間的會話祕鑰加密的，Service收到包後先使用自己的密碼解密ST，或者會話祕鑰SK_Service，然後使用SK_Service解密Authenticator來驗證發送請求的用戶就是票中所聲明的用戶。

Service向用戶發送一個包以證明自己的身份，這個包使用SK_Service加密。

此後user與Service之間使用SK_Service進行通信，且在TGT有效期內，user直接跳過第一步直接從第二步使用TGT向TGS證明自己的身份。注意：user client會等待service server發送確認信息，如果不是正確的service server，就無法解開ST，也就無法獲得會話祕鑰，從而避免用戶使用錯誤的服務器。

個人理解要點：

TGS可以理解爲一種service，TGT就可以理解爲TGS的‘ST’，這樣理解Kerberos就簡單了，除了AS，其他都是一種Service對應着它們所需要的服務票據ST
整個過程涉及兩個Session Key，一個是user和TGS之間的（由AS設置），一個是user和某個Service之間的（由TGS設置）；按照把TGS作爲一種特殊service的方式來理解的話，就是user和service之間都是通過Session key來通信的。
Service（包括特殊的TGS）取得相應session key是通過service自己的密碼獲得的，用戶獲得session key也是通過自己的密碼取得的；即二者都通過自己的密碼取得session key，然後使用session key進行通信；與上面說的加密技術是一樣的道理。
至於爲何要使用Session key，爲何要使用Authenticator，原因還是去讀一下經典對話吧，看看它們是如何被一步步設計出來的。

說到這裏，其實上面的流程圖也就是CAS的原理：

用戶訪問某個應用程序，應用服務器接收請求後檢查ST和TGT，如果都有則用戶正常進行訪問；如果沒有或者不對（如圖，步驟1），轉到CAS認證服務器的登錄頁面，通過安全認證後得到相應應用的TGT（步驟2-3）和該應用的ST（步驟4-5），再重定向到相關的應用服務器（步驟6），如果在會話週期內再定向到別的應用（步驟7），將出示TGT和該應用的ST（如果沒有，就直接通過步驟4-5得到該應用的ST，即步驟8）進行認證。

這裏引用參考文獻的一個小場景，覺得作者寫的非常好，拿來很助於理解：

用戶要去遊樂場，首先要在門口檢查用戶的身份(即 CHECK 用戶的 ID 和 PASS), 如果用戶通過驗證，遊樂場的門衛 (AS) 即提供給用戶一張門卡 (TGT)。

這張卡片的用處就是告訴遊樂場的各個場所，用戶是通過正門進來，而不是後門偷爬進來的，並且也是獲取進入場所一把鑰匙。

現在用戶有張卡，但是這對用戶來不重要，因爲用戶來遊樂場不是爲了拿這張卡的而是爲了遊覽遊樂項目，這時用戶摩天樓，並想遊玩。

這時摩天輪的服務員 (client) 攔下用戶，向用戶要求摩天輪的 (ST) 票據，用戶說用戶只有一個門卡 (TGT), 那用戶只要把 TGT 放在一旁的票據授權機 (TGS) 上刷一下。

票據授權機 (TGS) 就根據用戶現在所在的摩天輪，給用戶一張摩天輪的票據 (ST), 這樣用戶有了摩天輪的票據，現在用戶可以暢通無阻的進入摩天輪裏遊玩了。

當然如果用戶玩完摩天輪後，想去遊樂園的咖啡廳休息下，那用戶一樣只要帶着那張門卡 (TGT). 到相應的咖啡廳的票據授權機 (TGS) 刷一下，得到咖啡廳的票據 (ST) 就可以進入咖啡廳

當用戶離開遊樂場後，想用這張 TGT 去刷打的回家的費用，對不起，用戶的 TGT 已經過期了，在用戶離開遊樂場那刻開始，用戶的 TGT 就已經銷燬了。

經典對話手記

todo …

參考：

http://web.mit.edu/kerberos/dialogue.html