由于最近的項目中要用到kerberos and spnego protocol,查了一些資料,結(jié)合網(wǎng)上的資料和對它一定的理解,整理如下,以備后查.(如有不對之處,肯請高手指教)
kerberos是一個很重要的網(wǎng)絡(luò)認(rèn)證協(xié)議,它實現(xiàn)了在一個非安全的網(wǎng)絡(luò)環(huán)境中,一個實體向另一個實體證實自己的身份,從而以安全的方式進行交流.kerberos protocol已經(jīng)被廣泛應(yīng)用于各種應(yīng)用中,最為典型的莫過于windows中的kerberos認(rèn)證,它在spnego protocol之下,為windows域用戶登錄提供安全保障.
首先相關(guān)名詞:
Long term key:就是長期保持不變的key.
Master key:就是Long term key經(jīng)過Hash運算得到的Hash code.
Short term key:就是只在一定時間內(nèi)有效的key.有時也叫Session key.
原則上Long term key 是不能在網(wǎng)絡(luò)上傳輸?shù)?因為很可能Long term key在傳輸過程中被人截獲,一旦它被截獲,原則上只要有足夠的時間,就可以被破解.另外,對于一個帳戶而言,密碼僅限于該用戶知道,對于domain的Administrator也應(yīng)該保密,但由于密碼是用戶向Administrator證明身份的憑據(jù),所以要基于用戶的密碼生成來的信息來證明用戶的身份,通常做法是對密碼進行Hash運算,生成Hash code,這個Hash code就是我們說的Master key.因為Hash Algorithm具有不可逆,同時保證了密碼與Master key一一對應(yīng)的特性,保證了密碼的保密性,也保證了Master key可以代表密碼作為用戶身份的憑證.而作為 Short term key,用來加密在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù),由于它只在一定時間內(nèi)有效,即使被人截獲,等到被破解時,這個key早就過期了.
Client 服務(wù)請求者
Server 服務(wù)提供者
KDC kerberos distribution certer.在整個認(rèn)證過程中作為client和server共同信認(rèn)的第三方.
以windows2003中的Domain為例,Domain Controller扮演著kdc的角色.
下面我來介紹一下這kerberos協(xié)議如何實現(xiàn)認(rèn)證的.
前提:client和server都在kdc上已注冊.
第一步 Authentication Service Exchange
第二步 Ticket Granting Service Exchange
第三步 Client/Server Exchange
首先Client向kdc申請server服務(wù),kdc查看server服務(wù)是受保護的服務(wù),所以要驗證client的身份,這就是第一步,kdc驗證client的身份(Authentication Service Exchange).當(dāng)kdc核實client的身份正確后,會給client一個證明,用這個證明我們可以得到訪問server服務(wù)的許可證(Ticket),所以我們把這個證明叫做TGT(Ticket Granting Ticket).
當(dāng)client得到TGT后,用TGT來向kdc索要訪問server服務(wù)的通行證(Ticket),這就是第二步Ticket Granting Service Exchange.
當(dāng)client得到通行證(Ticket)后,就與server交互,向server出示通行證(Ticket),即第三步Client/Server Exchange,從可得到server的服務(wù).
以上三步的具體實現(xiàn)要復(fù)雜得多,簡單介紹如下:
1． Authentication Service Exchange
通過這個Sub-protocol，KDC（確切地說是KDC中的Authentication Service）實現(xiàn)對Client身份的確認(rèn)，并頒發(fā)給該Client一個TGT。具體過程如
下：
Client向KDC的Authentication Service發(fā)送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的大體包含以下的內(nèi)容：
Pre-authentication data：包含用以證明自己身份的信息。說白了，就是證明自己知道自己聲稱的那個account的Password。一般地，它的內(nèi)容是
一個被Client的Master key加密過的Timestamp。
Client name & realm: 簡單地說就是Domain name\Client Server Name：注意這里的Server Name并不是Client真正要訪問的Server的名稱，而我們也說
了TGT是和Server無關(guān)的（Client只能使用Ticket，而不是TGT去訪問Server）。這里的Server Name實際上是KDC的Ticket Granting Service的Server Name。
AS（Authentication Service）通過它接收到的KRB_AS_REQ驗證發(fā)送方的是否是在Client name & realm中聲稱的那個人，也就是說要驗證發(fā)送放是
否知道Client的Password。所以AS只需從Account Database中提取Client對應(yīng)的Master Key對Pre-authentication data進行解密，如果是一個合法
的Timestamp，則可以證明發(fā)送放提供的是正確無誤的密碼。驗證通過之后，AS將一份Authentication Service Response（KRB_AS_REP
）發(fā)送給Client。KRB_AS_REQ主要包含兩個部分：本Client的Master Key加密過的Session Key（
SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大體又包含以下的內(nèi)容
：
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）發(fā)送Ticket Granting Service Request
（KRB_TGS_REQ）開始。KRB_TGS_REQ大體包含以下的內(nèi)容：
TGT：Client通過AS Exchange獲得的Ticket
Granting Ticket，TGT被KDC的Master Key進行加
密。
Authenticator：用以證明當(dāng)初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在發(fā)給Client真正的Ticket之前，先得整個Client提供的那個TGT是否是AS頒發(fā)給它的。于是它不得不通過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進行驗證。驗證通過向?qū)Ψ桨l(fā)送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大體包含以下一些內(nèi)容：
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是一種高效的認(rèn)證方式，它可以直接通
過Client和Server雙方來完成，不像Windows NT 4下的NTLM認(rèn)證方式，每次認(rèn)證都要通過一個雙方信任的第3方來完成。
我們現(xiàn)在來看看 Client如果使用Ticket和Server怎樣進行交互的，這個階段通過我們的第3個Sub-protocol來完成：CS（Client/Server ）
Exchange。
3． CS（Client/Server ）Exchange
Client通過TGSExchange獲得Client和Server的Session Key（SServer-Client），隨后創(chuàng)建用于證明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）進行加密。最后將這個被加密過的Authenticator和Ticket作為Application Service Request（KRB_AP_REQ）發(fā)
送給Server。除了上述兩項內(nèi)容之外，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）進行加密，并將其發(fā)送給Client用于
Client驗證Server的身份。
想要更深入的理解kerberos,請參考官方網(wǎng)站
http://web.mit.edu/Kerberos/