1. 概述
1.1 網絡安全需求
五種需求:
-
機密性:防止數據未授權公開,讓消息對無關聽眾保密
-
完整性:防止數據被篡改
-
可控性:限制對網絡資源(硬件和軟件)和數據(存儲和通信)的訪問
-
目的:阻止未授權使用資源,未授權公開或修改數據
-
要素:標識、鑒別、授權、決策、執行
-
-
不可否認性:通信實體對自己的行為需要負責,不可抵賴。兩層含義:
-
發送者不能否認自己發送數據的行為
-
接收者不能否認接受數據的行為
-
-
可用性:合法用戶在需要使用網絡資源時能夠獲取正常的服務
注:可用性的實現往往依賴於其余四種特性的實現
1.2 網絡安全協議的定義
網絡安全協議可定義為基於密碼學的通信協議,包含兩層含義:
-
網絡安全協議以密碼學為基礎
-
網絡安全協議也是通信協議
第二層含義體現了網絡安全協議與普通協議之間的共性
1.3 構建網絡安全協議所需的組件
1.3.1 加密和解密
加密是保障數據機密性的手段,解密是其逆過程
加密解密過程示意圖
未知密鑰的情況下,最直觀的攻擊方式是窮舉攻擊,密文被破解的可能性與算法的安全性與密鑰長度密切相關
密鑰范圍足夠大與保證安全時間以及資源配備有關
密鑰是保障安全性的核心
公鑰密碼和對稱密碼的對比
-
密鑰交互和保密的角度:公鑰密碼優於對稱密碼。但保障數據機密性時對稱密碼的到廣泛應用,原因之一是對稱密碼算法效率高
-
應用的角度:公鑰密碼主要用於:
-
計算數字簽名確保不可否認性
-
用於密鑰交換
-
-
密鑰的實用角度:
-
保障機密性,使用接收方的公鑰加密
-
用於數字簽名,使用發送方的私鑰加密
-
1.3.2 信息摘要
表征該數據特征的字符串
獲取數據 摘要功能由散列函數完成,散列函數接受任意長度的數據,產生定長的值,數學表達式:
其中M是任意長度的銘文,H是散列函數,h是散列值
散列函數是一種壓縮映射的過程,輸入空間遠大於散列值的空間,不同的輸入可能產生相同的輸出,故不可能從散列值唯一確定輸入值
TCP和UDP都包含的”校驗和“字段就是摘要信息,字段都是定長的2B
信息摘要驗證數據完整性
摘要是驗證完整性的基礎,發送數據時可以加上數據摘要,接收方驗證摘要值和數據經計算后的摘要值是否相等,判斷數據完整性。
此過程用於檢測由於硬件失效或軟件錯誤所產生的傳輸錯誤時有效,但無法應對惡意攻擊
用於信息安全領域信息摘要需滿足的特性
-
映射分布均勻性和差分分布均勻性:散列值0和1總數應大致相等。雪崩效應:輸入中一個bit的變化,散列結果中將有一半以上的bit發生變化
-
單向性:不能由散列值得到輸入
-
抗沖突性:統計上無法產生兩個散列值相同的預映射(能用於完整性校驗的基本要求)
選擇摘要值
-
選擇摘要值的限定因素通常是抵御沖突的強度,而不是滿足單向性的強度
-
選擇摘要長度時還要考慮計算效率
1.3.3 消息驗證碼(MAC)
與完整性校驗含義相同,它基於密鑰和消息摘要獲得的一個值,可用於數據源發認證和完整性校驗(認證功能)
利用消息驗證碼驗證消息完整性原理
消息驗證碼 = 信息摘要 + 加密算法
驗證通過,得到:
-
數據確實用會話密鑰加密
-
消息驗證碼是消息摘要經過密鑰處理后所得,被更改后仍可用密鑰還原得到原始摘要的概率很低
消息驗證碼的計算方式
-
利用已有加密算法對消息摘要進行加密
-
使用專門的MAC算法,普遍認同的算法哈希運算消息驗證碼,計算方法如下:
K:密鑰,長度為哈希函數所處理的分組尺寸
M:消息
H:散列函數
opad和ipad:分別是0x5c和0x36組成的字符串
1.3.4 數字簽名
確保不可否認性,原理與消息驗證碼類似,具備認證功能
使用發送方的私鑰加密摘要,驗證發使用發送方的公鑰驗證
消息驗證碼和數字簽名的區別
-
消息驗證碼使用通信雙方共享的會話密鑰處理摘要
-
數字簽名使用發送方的私鑰加密摘要,驗證發使用發送方的公鑰驗證
1.3.5 密鑰管理
密鑰管理是密碼系統的核心,密鑰管理涉及:密鑰生成,分配,傳遞,保存,備份和銷毀
1.3.5.1 建立共享密鑰
-
基於可信的第三方
指通過密鑰分發中心(KDC)
-
密鑰協商方式
思想:通信雙方交換生成密鑰的素材,並各自利用這些素材在本地生成共享密鑰
D-H交換
-
發送方計算:
-
接收方計算:
通信雙方共享g和 p
-
-
密鑰傳輸方式
核心思想:
由通信一方生成共享密鑰,並通過某種途徑將該密鑰傳遞到通信對等端.碧璽保證通信安全.
利用公鑰密碼體制保護共享密鑰
1.3.5.2 公鑰管理
直接通過網絡發送公鑰可能遭受中間人攻擊
公鑰的分發和傳遞使用證書
證書系統
構建:基於證書授權中心,可信的第三方,負責證書的頒發,管理歸檔和撤銷
數字證書是一段數據,包含兩個關鍵字段:
-
證書所有者的公鑰
-
頒發該證書的CA用自己的私鑰對證書所做的簽名(防止中間人攻擊)
實施完整性驗證時必須要獲取該頒發者的公鑰
證書除了包括公鑰和簽名兩個關鍵字段還包括:版本,序列號,簽名算法,頒發者名稱,主體名稱和有效期
證書撤銷
CRL是一個經過簽名的,標有日期的,包含所有已撤銷證書的列表,表中的證書表示已失效
驗證證書的有效性
-
驗證證書的簽名
-
查看證書是否在CRL中
1.4 構建一個簡單的安全消息系統
提高交互效率
核心:證書和密鑰的傳遞步驟從整個通信過程中獨立開來
獨立出來的過程叫:握手或協商,在數據交互之前,包含三大功能:
-
身份認證
-
算法協商
-
密鑰生成
2. 鏈路層擴展
2.1 PPP的協議流程
PPP規定了以下內容:
-
幀格式和成幀方式
-
用於建立、配置、和測試PPP鏈路的鏈路控制協議
-
用於建立和配置網絡層協議的網絡控制協議
協議流程
發送方 | 回應方 |
---|---|
發送LCP配置請求報文(各項參數:認證協議,最大接收單元,壓縮協議) | 返回確認報文 |
提供口令和賬號(以便驗證身份) | 驗證身份成功后返回 |
發出IPCP配置請求 | 返回確認 + 分配IP |
發出LCP終止鏈路請求 | 返回確認鏈路終止 |
PPP鏈路轉換過程
五個階段:
-
鏈路不可用階段(Dead):鏈路狀態的起始和終止點
-
鏈路建立階段(Establish):通信雙方用LCP配置PPP鏈路
-
認證階段(Authenticate):回應方認發起方的身份
-
網絡層協議階段(Network):回應方給發起方分配IP
-
鏈路終止階段(Terminate):PPP鏈路終止,但物理層鏈路仍可用
幀格式
說明:
-
首尾兩個F(Flag)為幀定界標志,固定值7E
-
A(Address)為地址字段,設置為FF(點到點鏈路的端點唯一)
-
C(Control)是控制字段,包含幀類型和序號
-
協議字段指明了封裝的協議數據類型
-
數據字段的取值與協議類型相關
PPP幀有三種類型,信息幀(Information)、監督幀(Supervisory)、無編號幀(Unnumbered)
2.2 認證協議PAP和CHAP原理
2.2.1 PAP
PAP是基於口令的認證方法。
-
被認證方:發送報文(賬號和口令信息)
-
認證方:接收報文,通過返回Authenticate-Ack,不通過返回Authenticate-Nak
PAP包含的賬號 和口令信息明文傳輸,無法防止竊聽、重放和窮舉攻擊
PPP在建立鏈路階段使用
Authenticate-Ack報文格式
Authenticate-Nak報文格式
2.2.2 CHAP
CHAP是基於挑戰的認證協議
認證方 | 被認證方 |
---|---|
發出Challenge報文,包含隨機數c | 將雙方共享秘密值s和c作為輸入,計算hash值A1,通過Response報文返回 |
將本地的s和c作為輸入,計算hash值A2。若A1 = A2,返回Success,否則返回Failure |
Challenge報文格式
Response報文格式
2.3 L2TP概念和安全性分析
2.3.1 概念
L2TP是對PPP的擴展,它允許鏈路端點跨越多個網絡
關鍵組件
-
L2TP接入集中器(LAC)
-
L2TP網絡服務器(LNS)
他們之間通過協商建立隧道,用以轉發PPP報文
L2TP應用場景
遠程系統與家鄉局域網建立連接
-
通過公共電話網絡(PSTN)與LAC建立PPP鏈路。這段鏈路和隧道構成虛擬的PPP鏈路
-
遠程系統的PPP幀發送給LAC
-
LAC用L2TP封裝,且發送給LNS
-
LNS解封,發送給家鄉局域網主機
遠程系統和家鄉局域網主機就是L2TP的對等端
某些情況下,主機可以不依賴LAC,而是獨立運行L2TP,並與LNS建立隧道
除了IP網絡,L2TP也支持ATM和幀中繼等網絡類型,L2TP是一個應用層協議,使用知名端口1071
L2TP包含兩種消息:數據消息和控制消息,分別通過L2TP數據通道和控制通道傳輸。L2TP不保證數據消息的可靠傳輸,保證控制消息的可靠傳輸。
一條隧道對應一個控制連接,可承載多個會話
2.3.2 協議流程
-
建立控制連接SCC
-
SCCRQ(SCC請求,類型編號“1”)
-
SCCRP(SCC響應,類型編號“2”)
-
SCCCN(SCC已建立,類型編號“3”)
-
確認,完成控制連接建立
-
-
建立會話
-
呼入會話
-
呼出會話
-
-
數據傳輸
-
終止會話
-
終止控制連接
說明:
-
實際中LNS和LAC都可發起建立控制連接的協商
-
建立呼入會話和呼出會話是建立會話的兩種可能
-
建立控制連接階段的每個報文類型后用括號包含的兩個數字分別是發送序號和接受序號
-
L2TP每個步驟中都可能使用ZLB ACK報文,表示實體長度為0的確認報文
2.3.3 安全性分析
-
L2TP不提供對PPP數據的機密性和完整性保護。
-
若使用CHAP,則可體現端點身份認證功能
-
不提供對每個報文的認證功能,無法抵抗插入攻擊和地址欺騙
-
不提供對報文的完整性保護,造成拒絕服務器攻擊
-
沒有密鑰更新機制,密鑰被攻破的風險增大
3. IP層安全IPsec
Internet Protocol Security
3.1 IPsec的基本概念
IP的安全性
-
IP可能遭受欺騙
-
IP數據報被經過的所有網絡都可看到,甚至篡改其中的信息
IPsec相關概念
-
IPsec是一個協議族,包含多個RFC
-
IPsec是通過對IP協議的分組進行加密和認證來保護IP協議的網絡傳輸協議族
3.2 IPsec提供的安全服務
-
身份認證
-
機密性(數據源發認證)
-
完整性(完整性校驗)
-
抗重放保護
-
有限的通信流機密性保護
通信流是指報文的通聯要素,包括最初的源發地(IP地址、協議端口)和報文長度等。
協議的互操作性也是考慮的重要因素
IPsec在通用性、部署靈活性、安全策略統一性占優勢,在使用簡便性、通信效率和應用 開發支持不占優勢
3.3 IPsec的協議組成
3.3.1 協議組成
把IP通信過程分為協商和數據交互兩部分
協商階段:
-
通信雙方互相認證身份
-
根據安全策略協商使用的加密認證算法
-
生成共享會話密鑰
數據交互階段
-
利用協商好的算法和密鑰對數據進行安全處理以實現IPsec的各種安全功能
使用的協議:
-
互聯網密鑰交換協議 IKE ,對應協商階段
-
認證首部AH,對應數據交互階段,規定報文格式以及對報文的處理方式和處理過程。AH只提供認證功能,僅計算消息驗證碼(ICV,完整性校驗值)
-
封裝安全載荷ESP,對應數據交互階段。提供機密性和完整性保護,加密報文,計算ICV
IPsec標准中,互聯網安全關聯與密鑰管理協議(ISAKMP)、Oakley和IKE密切相關,他們都是協商協議
3.3.2 標准組成
按照描述的內容區分
-
IPsec體系結構 描述IPsec的基本概念、安全需求以及IPsec的應用模式
-
ESP協議 規定了ESP的語義、語法和時序
-
AH協議 規定了AH的語義、語法和時序
-
加密算法 描述了各種算法如何應用於ESP
-
認證算法 描述了各種認證算法如何應用於AH金額ESP
-
組合算法 描述了如何將加密和認證算法組合以提供服務
-
IKE 規定了協商協議的語義、語法和時序
IPsec RFC之間的關系
3.4 安全策略與安全關聯的概念和用途
3.4.1 安全策略的含義
-
安全策略位於安全規范的最高一級,是決定系統安全的關鍵要素。
-
安全策略定義了系統中哪些行為是允許的,哪些是不允許的
3.4.2 安全策略的作用
-
安全策略決定了一個組織怎樣保護自己
-
一般來說,安全策略包含兩個部分:總體策略和具體規則
3.4.3 安全策略的要素
IPsec本身沒有為策略定義標准,只規定了兩個策略組件:SPD(安全策略庫)和安全關聯庫(SAD)
外出的數據報,檢索SPD,決定提供給它的安全服務
進入的數據報,查閱SPD。判斷其提供的安全保護是否與策略規定的安全保護相符
策略描述主要包括:對通信特征的描述,對保護方法的描述
對通信特征的描述
-
目的IP地址
-
源IP地址
-
名字
-
傳輸層協議
-
源和目標端口
-
數據敏感等級
對保護方法的描述
對於進入或外出的數據包,都可能有三種處理方式:
-
丟棄
-
繞過
-
繞過或應用IPsec
若應用IPsec,策略要包含使用的:
-
安全協議(AH或ESP)
-
模式
-
算法
3.4.4 安全關聯SA
安全策略與安全關聯的關系
-
安全關聯用於實現安全策略,是安全策略的具體化和實例化
-
定義了如何對一個具體的數據報進行處理
-
對於SPD中的一條記錄,若使用IPsec進行保護,它必定要指向一個SA或SA束
-
一個SA對IP數據報只提供AH或ESP保護,要提供多種保護,則需使用多個SA
安全關聯的定義
安全關聯是兩個IPsec實體(主機、路由器)間的一個單工連接,決定保護什么,如何保護以及誰來保護通信數據
SA是單向的,要么對數據提供進入保護,要么提供外出保護
安全關聯庫SAD
SAD為進入和外出維護一個活動的SA列表,其中記錄是無序的,外出的SA保障外出數據報的安全,進入SA保障進入數據報的安全
字段包括:
-
目的IP地址
-
IPsec協議
-
序號計數器
-
序號計數器溢出標志
-
抗重放窗口
-
密碼算法及密鑰
-
安全關聯的生存期
-
IPsec協議模式:傳輸或隧道模式
-
路徑MTU
3.5 IPsec的協議流程
IPsec協議流程就是依托安全策略對數據報進行安全處理和驗證的過程
外出處理
處理方式可能有三種:
-
丟棄數據報
-
繞過IPsec給數據報添加IP頭,然后發送
-
應用IPsec查詢SAD,確定是否存在有效的SA,此時按如下步驟處理:
-
存在有效的SA,取出相應的參數,,將數據報封裝(包括加密、驗證、添加IPsec頭和IP頭),然后發送
-
尚未建立SA,啟動或觸發IKE協商,協商成功后,按如上步驟處理,不成功則將數據報丟棄
-
存在SA但無效,請求協商新的SA,成功按照步驟1處理,不成功將數據報丟棄
-
進入處理
收到數據報
-
查詢SAD
-
得到有效SA,查詢為該數據報提供的安全保護是否與策略要求相符
-
相符,將還原后的數據報交給相應高層協議模塊或轉發
-
不相符,將數據報丟棄
3.6 IKE定義的4種認證方法
IKE的功能包括:
-
SA協商
-
密鑰生成
-
身份認證
是一個應用層協議,基於UDP
SA協商:規定的SA屬性包括加密算法、散列算法、認證方法、D-H群信息、偽隨機函數、群描述、群類型、生命期類型、生命期以及密鑰長度
IKE定義的4種認證方法
-
基於數字簽名的方法
-
通信雙方互相交互證書和簽名信息,簽名認證通過,確認對方身份
-
-
基於公鑰加密的方法
-
通信雙方用對方的公鑰對身份、隨機數等加密處理好后,發送給對等端
-
通信雙方將身份、隨機數等信息作為輸入,生成認證信息
-
如果認證信息正確,驗證了對方的身份
-
-
改進的基於公鑰加密的方法
-
對某些信息采用公鑰加密,對其他信息采用對稱加密,提高效率
-
-
基於預共享密鑰的方法
-
通信雙方預先共享一個密鑰。
-
通信雙方在生成人生信息時,預共享密鑰作為輸入之一
-
如果認證信息正確,身份得以驗證
-
3.7 IKE使用數字簽名的主模式流程
IKE 主模式是ISAKMP身份保護交換實例,使用不同的認證方法,主模式的報文結構和驗證信息都不相同
3.7.1 使用數字簽名認證方法的主模式流程
-
NI和Nr:發送方和回應方的NONCE
-
SIC_I和SIC_R:發送方和回應方的簽名
-
[ ] :其中內容表示可選內容
-
*:標識內容是經過安全處理的
流程:
-
前兩個報文協商SA
-
3,4個報文交換信息和隨機數,此時,雙方都可在本地生成用於保護數據的秘密信息
-
最后兩個報文交換身份和認證信息,完成對等端認證
3.7.2 使用公鑰加密認證方法
-
HASH_I和HASH_R:發起方和回應方的散列值
-
PubKey_i 和 PubKey_r:表示發起方和 回應方的公鑰
-
<a>b:表示用b加密a
流程:
-
前兩個報文協商SA
-
3,4個報文包含了密鑰交換信息以及用對等端公鑰加密的身份信息和NONCE,第3個報文還包含了可選的散列值
該散列值用途:如果回應方有多個公鑰,發起方要向回應方通過使用那個公鑰,該信息以該公鑰對應的證書的散列值形式發出
-
完成報文交換和認證信息
3.7.3 使用改進的公鑰加密認證方法
-
Ke_i 和 Ke_r:發起方和回應方用於加密身份和密鑰交換信息的臨時密鑰
3.7.4 使用預共享密鑰認證方法
4. 傳輸層安全SSL和TLS
4.1 SSLv3的協議組成
SSL標准定義了:
-
握手協議
用於安全機制的協商功能:
-
客戶端認證服務器身份(*)
-
可選的客戶端認證,服務器可以選擇認證客戶端身份
-
算法協商(壓縮算法【加密之前壓縮】、加密算法、消息驗證碼算法)
-
密鑰生成,生成客戶端和服務端的共享密鑰
-
-
更改密碼規范協議
-
安全協商后互相交換一條消息,互相通告協商好的參數
-
-
警告協議
-
報錯機制
-
安全斷連機制
-
-
記錄協議
-
規定了SSLv3的報文格式和處理過程
-
SSL滿足:機密性,完整性,實現服務器身份認證以及可選的客戶端認證
4.2 SSLv3基本協議流程
SSL位於應用層和傳輸層之間
握手 —-> 密鑰導出 —-> 數據傳輸 —->關閉連接
基本流程
-
協商握手階段:客戶端驗證服務器身份,與服務器就算法和密鑰達成共識
-
客戶端向服務器發送ClientHello消息,包含:客戶端所支持的各種算法和一個隨機數(隨機數用於密鑰推導,阻止重放攻擊)
-
服務器返回ServerHello消息,包含:服務器選中的算法和另一個隨機數
-
服務器返回Certificate消息,包含:服務器證書(以便客戶端認證服務器,並獲得其公鑰)
-
服務器發送ServerHelloDone【可選】,告訴客戶端本階段消息發送完畢
-
客戶端發送ClientKeyExchange消息,包含:客戶端生成的預主密鑰(使用服務器公鑰加密)
-
客戶端和服務器,各自以預主密鑰和隨機數作為輸入,在本地計算會話密鑰
-
客戶端發送ChangeCipherSpec消息,通告啟用協商好的各項參數
-
服務器發送ChangeCipherSpec消息
-
服務器發送Finished消息
-
-
數據傳輸階段:利用協商好的算法和密鑰處理數據
-
客戶端和服務器之間交互應用數據,使用協商好的參數進行安全處理
-
-
通過可認證的方式斷開連接
-
客戶端發送Close_notify消息,以一種可認證的方式通告服務器斷開連接
-
服務器發送Close_notify消息
-
4.3 使用客戶端認證時的SSL流程
-
服務器發送 CertificateRequest消息,通告客戶端需驗證其身份
-
作為相應,客戶端發送Certificate消息,將自己的證書發送給服務器
-
客戶端發送CertificateVerify消息,其中包含了客戶端利用與 證書對應的 私鑰 對之前的握手消息進行簽名
4.4 基於DH交換生成預共享密鑰的SSL流程
相較於基於密鑰交換生成預共享密鑰的SSL流程,基於D-H交換生成預共享密鑰在握手階段多了兩條消息:
-
ServerKeyExchange
-
ClientKeyExchange
這兩條消息用於交換生成共享密鑰的素材或者包含D-H密鑰的證書
ServerKeyExchange除了交換密鑰素材外還有的用途:
-
當服務器沒有證書時,或僅有用於簽名的證書時,可用這個報文向客戶端提供口令
-
臨時RSA應用
-
Fortezaa應用
4.5 SSLv3密鑰導出過程
-
輸入:包括ClientHello和Server Hello中包含的隨機數,以及預主密鑰
輸出:主密鑰
-
輸入:包括兩個隨機數和主密鑰
輸出:密鑰分組
被分為6段:M~cs, M~sc, E~cs, E~sc, IV~cs, IV~sc
IV~cs, IV~sc是客戶端和服務器使用的初始化量
4.6 常用的協議端口
普通協議 | 普通端口 | 安全協議 | 安全端口 | 備注 |
---|---|---|---|---|
HTTP | 80 | HTTPS | 443 | 超文本傳輸協議 |
FTP | 21 | FTPS | 990 | 文件傳輸協議控制連接 |
FTP-data | 20 | FTPs-data | 989 | FTP數據連接 |
NNTP | 119 | NNTPS | 563 | 網絡新聞傳輸協議 |
Telnet | 23 | Telnets | 992 | 遠程登錄協議 |
IMAP | 143 | IMAPS | 993 | Internet郵件訪問協議 |
SMTP | 25 | SMTPS | 465 | 簡單右間傳輸協議 |
POP3 | 110 | POP3S | 995 | 郵局協議3 |
IRC | 194 | TRCS | 994 | Internet中繼聊天協議 |
LDAP | 389 | LDAPS | 636 | 輕目錄訪問協議 |
4.7 HTTP和HTTPS的對比
4.8 SSL典型函數調用對照
5. 認證協議Kerberos
5.1 網絡安全協議中的“認證”包含的范圍
-
實體身份認證
-
數據源發認證
-
數據完整性校驗
5.2 Kerberos協議的工作原理
-
基於對稱密碼體制,授予實體的身份憑證是票據
-
特點:用戶只需輸入一次身份認證信息就可以憑借此驗證獲得的票據訪問多個服務
流程
-
用戶初次登錄或票據過時,客戶端向可信第三方第三方發出消息,請求獲取票據
-
用戶請求某個新的應用服務或用於訪問某個應用服務的票據過期,客戶端向票據許可服務器發送包含票據和認證符的消息
-
用戶請求應用服務時,客戶端向應用服務器發送包含票據和認證符的消息
5.3 Kerberos協議應對的安全威脅
-
同一工作站的某個用戶可能冒充另一個用戶操作該機器
-
用戶可更改工作站的IP地址冒充另一台工作站
-
攻擊者可能實施重放攻擊
-
攻擊者可能操縱某台機器冒充服務器
5.4 重放攻擊、中間人攻擊與認證協議的設計
防止重放攻擊
-
引入時間參數
-
兩個參數:生命期(有效時間),時間戳(辦法時間)
防止中間人攻擊
-
引入會話密鑰和認證符
-
可信第三方在為用戶頒發票據的同時,還將為用戶和服務器生成共享的會話密鑰。
-
用戶訪問時需通過認證符證明自己擁有會話密鑰
5.5 Kerberos協議的跨域認證
什么是域?
每個組織或單位都可能建立一個Kerberos認證系統,該系統稱為Kerberos域(Realm)
5.5.1 跨越單個域
-
客戶端訪問ASa獲取訪問TGSa的票據TGTtgsa
-
訪問TGSa獲得訪問TGSb的票據TGTtgsb
-
訪問TGSb獲取訪問服務器的Ticket~b
-
訪問域b的服務器S
TGTtgsb使用A和B之間的域間密鑰加密,TGSb收到使用域間密鑰解密還原確保該票據是由TGSa頒發
5.5.2 跨越多個域
每兩個直接跨域認證的域之間都共享域間密鑰
若兩個域之間沒有共享域間密鑰,則可通過該樹建立一條認證路徑,它由跨越的中間域構成