EAP-TTLS(Tunneled Transport Level Security)是由Funk Software與Certicom所共同開發,爲了提供一比EAP-TLS簡單的方式而開發。TTLS只需要Server端的Certificate而大大降低管理所需時間。對TTLS鑑權算法的功能描述如下:
- 允許用戶使用username和password鑑權,而不損安全性;
- 提供加強的交互驗證,credential security和dynamic keys;
- 僅需要將證書(certificates)部署在Radius服務器上,而不需要放在客戶端;
- 與現有的用戶安全數據庫兼容,包括Windows Active Directory, token systems,SQL,LDAP等等。
EAP-TTLS的特點如下:
- TTLS先利用Server Certificate建立一個Tunnel到Client,再利用這個Tunnel讓Client將其密碼或Certificate送給Server。
- TTLS的特色如:
- 它的Tunnel之中可搭配任何形式的驗證法,如Password、Certificate或Token,如MS-CHAPv2、MS-CHAP、CHAP、PAP、MD5等。
- 只需要Server端的Certificate。
- 不怕黑客的Dictionary攻擊。
- 支持雙向驗證,漫遊時的Fast Reconnection,以及自動變換Key。
EAP-TTLS有v0和v1兩種版本,v0版本是命名爲EAP-TTLS,v1版本命名爲EAP-TTLSv1。根據協議和需求,我們需要支持的鑑權算法爲v0版本的TTLS算法,即EAP-TTLS的v0版本。
AAA/H:用戶歸屬域的AAA服務器,用於給歸屬域管理的用戶鑑權和授權。
TTLS Server:能夠支持EAP-TTLS算法的AAA服務器。該服務器也可以承擔用戶鑑權功能,或者能夠代理轉發用戶鑑權到AAA/H。
Access Point:接入點,提供基於AAA服務器返回的信息,實現用戶接入控制和策略功能的實體。在本文中“access point”和“NAS”在體系結構上是等同的。“access point”一般是指無線接入領域,“NAS”一般用戶傳統接入領域,例如撥號接入。
Client:通過接入點接入到網絡的主機或設備。
下圖爲EAP-TTLS應用的網絡結構模型。
上圖描述的實體,是邏輯實體,並不一定是分開的網元。例如,TTLS Server和AAA/H可以合一;TTLS Server和Access Piont可以合一;甚至Access Piont、TTLS Server和AAA/H都合一。
我們EAP-TTLS的實現方式應該爲AAA/H和TTLS Server合一方式。
上圖實體之間的通信,使用可以封裝EAP消息的傳輸協議。Client和Access Piont之間使用鏈路層傳輸協議,例如PPP或EAPOL。Access Point、TTLS Server和AAA/H之間通信使用AAA傳輸協議,例如RADIUS或Diameter。
EAP-TTLS包是封裝在EAP,EAP又是通過傳輸協議進行傳送的。EAP-TTLS包本事封裝了TLS,TLS又是用來封裝用戶鑑權信息的。所以EAP-TTLS消息可以描述爲以下分層模式,每一層都封裝在下面一層中。
當用戶鑑權採用EAP鑑權時,EAP-TTLS協議分層可以描述爲下面的模式:
傳輸協議PPP(RFC1611)、EAPOL(IEEE802.1X, Standard for Port Based Network Access Control)、RADIUS(RFC2865)、Diameter(RFC3588)本文檔不在贅述。詳見相關參考文獻。
-
- TTLS流程
EAP-TTLS協商流程包括兩個階段:TLS握手階段(TLS handshake phase)和TLS隧道階段(TLS tunnel phase)。
在握手階段,TLS用在客戶端對TTLS服務器進行鑑權,服務器對客戶端的鑑權是可選的。在此階段,客戶端和服務器進行協商選定加密用的加密套,建立TLS通道。協商的加密套的類型決定了在下一階段數據的安全程度,如果協商的是空的加密套,那麼在後面的數據傳輸中就沒有任何安全可言。
在第二階段,即通道建立後的TLS隧道階段,可以執行一系列操作,包括:用戶鑑權、協商數據通訊安全等級、密鑰分發、通訊或計費信息等。Client和TTLS Server之間的信息交互通過AVPs(Attribute-value pairs)。
EAP-TTLS定義了在第二階段如何進行用戶鑑權。在這個階段用戶鑑權可以使用EAP,例如MD5,也可以使用傳統的鑑權協議,例如PAP、CHAP、MS-CHAP或MS-CHAP-V2。第二階段的用戶鑑權也不是必選的,因爲在握手階段執行了服務器對客戶端的鑑權(可選),就不需要在進行用戶鑑權。
當Client發送EAP-Response/Identity報文的時候,表明TLS握手階段開始,這個報文中並不包含用戶名信息,但它可以包含域名信息,如‘@myisp.com’。
TTLS服務器發出EAP-TTLS/Start來響應EAP-Response/Identity,這是一個EAP-Request報文,類型爲EAP-TTLS,並且S位(Start)置1,無數據部分。這個報文指示客戶端送上ClientHello報文,表明TLS握手開始。
客戶端和TTLS服務器直到互相ChangeCipherSpec Finished,纔算完成TLS握手成功。
在某些TLS握手協議中,TTLS服務器會發送自己的證書,連同一個可信任的CA頒發的證書鏈,這時客戶端就需要配置可信任的CA的證書,以便執行對TTLS服務器的證書的鑑權。
如果客戶端所希望鑑權是基於證書的鑑權,那麼客戶端自己也必鬚髮行一個證書,而且必須保留一個基於證書的私鑰。
任何信息都可以在隧道階段進行交互,在此階段,客戶端把信息編碼到一系列的AVPs中,再通過TLS層加密發送到TTLS Server。
Client在AVPs序列中編碼信息,開始第二階段的數據交換,傳送AVPs序列到TL進行加密,併發送結果數據給TTLS server。
TTLS Server從TLS層收到AVPs,並恢復成明文。並用自己的AVPs序列進行響應,TTLS Server將自己的AVPs序列,通過TLS層加密發送結果數據到Client。
如果AVP序列包含鑑權信息,它將繼續傳送到AAA Server。注意:EAP-TTLS Server和AAA Server有可能是一個,並且是相同的,在這種情況下,它僅僅只是在本地執行一下就可以了。
TTLS server 通過自己的AVPs序列響應。它傳送AVP序列到TLS層進行加密併發送結果數據到Cleint。例如The TTLS可能發送密鑰分發信息(key distribution information),或者轉發從AAA/H收到的鑑權挑戰。
這個過程直到TTLS server有足夠的信息去下發EAP-Success或EAP-Failure爲止。這樣,如果AAA/H拒絕基於前轉鑑權信息的Client,TTLS Server將下發EAP-Failure;如果AAA/H接受這個Client,TTLS Server將下發EAP-Success。
TTLS Server在分發EAP-Success消息的報文中同時分發數據連接鍵控信息和其它的授權信息給Access Piont。
在TLS握手後,一個僞隨機函數PRF(Pseudo-Random Function)用來把協商的主密鑰、服務器的隨機數、客戶端的隨機數展開成一串二機制序列,作爲密鑰元素,它的長度依賴協商的密碼套。幷包含6個部分:client_write_MAC_secret,server_write_MAC_secret,client_write_key,server_write_key,client_write_IV(可選),server_write_IV(可選)。其中一個常量字符串作爲PRF的輸入,用來產生這個序列。
EAP-TTLS通過這種方式,在客戶端和AP之間產生密鑰元素用於數據傳送,完全一致的PRF可以用來產生所需大量的密鑰元素。常量字符串設爲‘ttls keying material’,如下所示:
EAP-TTLS_keying_material =
PRF(SecurityParameters. master_secret,
”ttls keying material”,
SecurityParameters.client_ random+SecurityParameters.server_random);
PRF(secret, label, seed)爲僞隨機函數(詳細參考RFC2246),定義如下:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed)+
HMAC_hash(secret, A(2) + seed)+
HMAC_hash(secret, A(3) + seed)+ ...
這裏A()定義如下:
A(0) = seed A(i) = HMAC_hash(secret, A(i-1))
僞隨機函數:
PRF(secret, label, seed) =P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);
這裏,S1和S2爲secret的各一半,如果secret爲奇數個字節,則S1和S2共享一個字節。
用來產生密鑰元素的主密鑰、客戶端隨機數以及服務器隨機數,必須是在握手階段建立時使用的值。如果握手成功的話,不管是客戶端還是服務器生成的密鑰元素,都能保證是一致的。TTLS服務器通過AAA協議向AP分發產生的密鑰元素。
注意:EAP-TTLS中客戶端隨機數、服務器隨機數的順序和TLS協議中是顛倒的,改變隨機數的順序是爲了避免EAP-TTLS和TLS協議中定義的常量字符串中用戶名爲空的時候,發生衝突。
-
-
- 通過隧道成功進行CHAP鑑權流程
-
通過隧道成功進行CHAP鑑權。客戶端僅對服務器進行單向TLS鑑權認證,CHAP作爲隧道建立後的認證機制,並且TTLS服務器返回密碼套和密鑰元素。其中(1)-(11)屬於TLS握手階段,(11)-(15)屬於TLS隧道階段。EAP-TTLS的認證流程如下圖所示,分下列幾個步驟:
- AP收到後送出EAP-Request封包來要求Client做身份的驗證;
- Client收到後將身份識別數據送回給AP,僅包含域名信息,包括用戶名;
- AP對報文封裝後轉發給TTLS Server;
- TTLS Server收到客戶端發來的身份識別數據後,送出EAP-TTLS/START幀進行應答,要求開始EAP-TTLS會話過程(報文類型爲EAP-TTLS,無數據部分);
- AP將TTLS Server發給Client的身份識別數據轉發給Client;
- Client收到後發送Hello 報文(爲握手協議的開始),現在雙方的加密及壓縮數據的方式尚未協商完成,在Hello報文裏包含協商過程所需的參數,如:所用的TTLS版本、session ID、一個隨機數值與一些Client所能使用的整套加密方式(ciphersuite)等;
- AP將Client的Hello報文轉發給TTLS Server;
- TTLS Server收到後,先確認session ID,其內容爲空或無法辨識,會先選擇新的來重新建立新聯機,如果與先前步驟所用的session ID符合,則會從Client所送達的ciphersuite中挑選出後續步驟所要使用的。也送出Server端Hello的信息,其項目與Client送出的相同,並送出Server端的證書(certificate)、建立session key的數據(server_key_exchange)
要求認證Client的證書(certificate _request)及Server端完成hello交談 (server_hello_done); - AP轉發給Client;當Client以內部之Issuer的公匙驗證TTLS Server。
certificate_request時,必須要響應,響應的數據包含自己的證書、經自己簽署過的認證響應(certificate_verify)驗證通過後,發送EAP-Response封包,包含建立session key的數據 (client_key_exchange)、設定完成加密的參數(change_cipher_spec)與TTLS完成的信息; - TTLS Server端收到Client的EAP-Response,給Client發送EAP-Request再次確認加密的參數(change_cipher_spec)與TLS完成的信息。
- Client收到Server端的EAP-Request,握手階段結束。Client發送響應EAP-Response封包,攜帶用戶鑑權的AVP,使用CHAP鑑權時,攜帶User-Name、CHAP-Challenge、CHAR-Password。
- AP封裝爲RADIUS的Access-Request,轉發到歸屬AAA。
- 歸屬AAA完成用戶鑑權,鑑權通過後,發送Access-Acept消息給TTLS Server攜帶授權參數。
- TTLS Server收到歸屬AAA的RADIUS認證響應後,則會發送EAP-Success,表示EAP認證通過。
- AP向Client發送EAP-Success。
-
-
- 通過隧道成功進行EAP-MD5鑑權流程
-
使用EAP-MD5用戶鑑權,在握手階段是和CHAP相同,僅僅區別在於隧道階段使用MD5鑑權算法。
-
- EAP-TTLS編碼
EAP-TTLS是EAP算法中的一種,分配的EAP代碼爲21。除了下面子章節描述的之外,其他的編碼方式與EAP-TLS一樣(參考RFC2716)。
EAP-TTLS Start packet可能將來的協議中允許包含數據(EAP-TLS Start packet是不包含數據的)。
這樣,EAP-TTLS Start packet包含數據被預留將來標準化,在這期間,服務器不能在EAP-TTLS Start packet中包含任何數據,客戶端必須忽略這些數據而不是拒絕。
本節用來澄清不包含數據的EAP-TTLS packet,不同於EAP-TTLS Start packet。
EAP-TLS中定義這種包是作爲分包數據的響應使用的。當任何一方需要分包發送EAP-TLS packet,另外一方收到後回覆分包的響應,用於告知發起方發送下一個分包片斷。
EAP-TTLS使用分包響應的作用是和TLS一樣的。當然也有另外一些場景需要發送EAP-TTLS packet with no data:
- 當TTLS Server發送最後一個協商階段的EAP會話包時,Client必須響應EAP-TTLS packet with no data,用於允許TTLS Server發送最後的EAP-Success或EAP-Failure包;
- EAP-TTLS packet with no data也有可能在協商中間階段發送。這種包可以簡單理解爲不包含AVPs的包。例如,在會話恢復階段,Client首先發送Finished消息,TTLS Server響應Finished消息給客戶端。因爲TTLS Server必須等待Client密鑰分發參數選擇指示,所以不可能在發送Finished消息的EAP-TTLS包中搭載密鑰分發AVPs。但是Client可能沒有參數選擇,這樣就不會發送任何AVPs。Client就簡單的發送一個EAP-TTLS packet with no data,允許TTLS Server通過發送密鑰分發選擇,繼續協商階段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
AVP代碼四字節。
AVP Flags
AVP標誌,共一個字節,用於提供給接收者解析AVP必須的信息。
'V' (Vendor-Specific)位指示Vendor-ID字段是否提供。設置爲1標識提供Vendor-ID字段,爲0標識沒有提供。
'M' (Mandatory)位指示AVP是否支持。如果設置爲0,標識如果接收方不能過解析或支持AVP,則可以忽略。如果設置爲1,表示接收方如果不能解析AVP時,協商失敗,對於一個TTLS Server來說,就需要向客戶端返回EAP-Failure,這就意味着放棄協商。
'r' (reserved) 位保留,必須設置爲 0。
AVP Length
AVP長度域時三個字節,用於表示AVP的長度,包括AVP Code, AVP Length, AVP Flags, Vendor-ID(如果提供) 和 Data。
Vendor-ID
如果AVP Flags 的'V'設置爲1,表示AVP中包含Vendor-ID字段。 該字段四個字節,包含IANA分配給廠家的代碼("SMI Network Management Private Enterprise Codes")。廠家必須保證在RADIUS、DIAMETER和REP-TTLS中保持一致。如果Vendor-ID爲0,等同於沒有提供Vendor-ID字段。
-
-
- AVP序列
-
在TLS層封裝的數據是由一系列的0或AVPs組成。在序列中,每一個AVP和前一個AVP必須一個四字節的邊界間隔,如果一個AVP不是四字節的整數倍,最後用0填充。
注意:AVP長度不包括填充的0。
-
-
- AAA Server最大兼容性方針
-
爲了實現最大限度的兼容性,建議遵守以下AVP的使用指導原則:
- Non-vendor-specific AVPs必須從RADIUS定義的屬性中選擇,那就是說,屬性代碼必須小於256。這就能夠提供RADIUS和DIAMETER的兼容性。
- Vendor-specific AVPs必須在RADIUS術語中定義。Vendor-specific RADIUS屬性能夠自動地轉換爲Diamter,反之不行。RADIUS Vendor-specific 屬性使用RADIUS屬性26和包括wendor ID、Vendor-specific屬性編碼和長度,參見RFC2865。
Tunnel之中可搭配任何形式的驗證法,如Password、Certificate或Token,如MS-CHAPv2、MS-CHAP、CHAP、PAP、MD5等。
某些鑑權協議使用的challenge/response機制依賴於挑戰元素,並不是由鑑權服務器產生的,因此需要特殊處理。
在CHAP, MS-CHAP和MS-CHAP-V2中,例如NAS發送一個挑戰給客戶端,客戶端使用哈希算法使用密碼加擾該挑戰,向NAS回覆響應,NAS將挑戰和響應發送給AAA服務器。因爲AAA服務器不是自己產生挑戰,協議就容易被重放攻擊。
如果客戶端能夠產生挑戰和響應,任何人都能夠發現CHAP或MS-CHAP交換都能夠用戶冒充,即使使用EAP-TTLS。
爲了使得這些協議在EAP-TTLS使用時更加安全,必須提供一種產生挑戰的機制,而不會被客戶端控制或預知。一種成熟的方法就是使用上面提到的產生密鑰元素的技術。
當使用一種基於挑戰的鑑權機制時,TTLS服務器和客戶端都使用僞隨機函數生成和挑戰一樣多的字節數。利用常量字符串“ttls challenge”,基於主密鑰和握手階段產生的隨機數:
EAP-TTLS_challenge = PRF(SecurityParameters.master_secret,
"ttls challenge",
SecurityParameters.client_random +
SecurityParameters.server_random);
本文重點介紹如何在隧道階段使用MSCHAPv2協議。
-
-
-
- MS-CHAPv2
-
-
MS-CHAP v2是一種基於密碼的質詢-響應式相互身份驗證協議,使用工業標準的“信息摘要 4(Message Digest 4,MD4)”和數據加密標準(Data Encryption Standard,DES)算法來加密響應。身份驗證服務器質詢接入客戶端,然後接入客戶端又質詢身份驗證服務器。如果其中任一質詢沒有得到正確的回答,連接就被拒絕。MS-CHAP v2最初是由Microsoft當作一種PPP身份驗證協議來設計的,以便爲拔入和虛擬專用網(VPN)連接提供更好的保護。對於Windows XP SP1和Windows Server 2003家族,MS-CHAP v2還是一種EAP類型。
雖然MS-CHAP v2比以前基於PPP的質詢-響應身份驗證協議提供更好的保護,但它仍然容易受到脫機字典的攻擊。 惡意的用戶能夠捕獲成功的MS-CHAP v2交換,並想方設法地猜測密碼,直至確定正確的密碼。運用TTLS和MS-CHAP v2的組合,MS-CHAP v2交換就能通過TLS通道強大的安全性得到保護。
MS-CHAP-V2算法描述詳見RFC2579 。RADIUS 屬性定義格式見RFC2548。
客戶端和TTLS服務器都產生17個字節的挑戰元素,使用常量字符串“ttls challenge”,這些字節用作以下用途:
MS-CHAP-Challenge [16 octets]
Ident [1 octet]
客戶把User-Name、MS-CHAP-Challenge和MS-CHAP2-Response的AVPs通過隧道發送給TTLS服務器,MS-CHAP-Challenge來自挑戰元素。MS-CHAP2-Response包含Ident(取自挑戰元素)、Flages(設置爲0)、Peer-Challenge(設置爲隨機數)和響應(依照MS-CHAP-V2算法計算出來)。
TTLS服務器收到客戶端的AVPs時,必須校驗MS-CHAP-Challenge AVP和客戶端MS-CHAP2-Response AVP中Ident的值是否和挑戰元素相等,如果不匹配,服務器則拒絕客戶端,否則在Access-Request中轉發AVPs給歸屬AAA。
如果鑑權成功,歸屬AAA響應一個包含MS-CHAP2-Succes屬性的Access-Accept給TTLS服務器。這個屬性包含一個42字節字符串,該字符串用於鑑權歸屬AAA到基於Peer-Challenge的客戶端。TTLS服務器通過隧道轉發AVP到客戶端。需要注意的是鑑權並沒有完全結束,客戶端仍然必須接收歸屬AAA的鑑權響應。
在客戶端收到MS-CHAP2-Success AVP時,它應該能夠鑑別歸屬AAA。如果鑑權成功,客戶端發送一個EAP-TTLS packet with no data包給TTLS服務器。TTLS收到客戶端發送的這個空EAP-TTLS packet時,發送EAP-Success包。
如果鑑權失敗,歸屬AAA將會響應一個包含MS-CHAP2-Error屬性的Access- Challenge。這個屬性中包含一個新的Ident和一個附加信息字符串(例如錯誤原因)以及是否允許重試的標誌。如果錯誤原因是非期望的密碼和允許重試標誌,客戶端可以繼續改變用戶密碼進行重試。如果錯誤原因不是非期望的密碼或客戶端不想改變密碼重試,即放棄EAP-TTLS協商。
如果客戶端希望更改密碼,它要把MS-CHAP-NT-Enc-PW、MS-CHAP2-CPW和 MS-CHAP-Challenge AVPs通過隧道發送給TTLS服務器。MS-CHAP2-CPW AVP來自新的Ident和MS-CHAP2-Error AVP中收到的挑戰。MS-CHAP-Challenge AVP只不過迴應了新的挑戰。
TTLS服務器收到這些來自客戶端的AVPs時,它必須校驗客戶端MS-CHAP2-CPW AVP 中MS-CHAP-Challenge AVP的值和Ident的值是否與MS-CHAP2-Error AVP的一致。如果任何一組不一致,服務器必須拒絕客戶端,反之向歸屬AAA在Access-Request中轉發這些AVPs。
如果鑑權成功,歸屬AAA響應一個包含MS-CHAP2-Success屬性的Access-Accept。這時候,TTLS服務器發送MS-CHAP2-Success給客戶端,客戶端基於這個AVP鑑別歸屬AAA,客戶可以放棄協商,也可以發送一個EAP-TTLS packet with no data包給TTLS服務器,服務器回覆EAP-Success。
注意:一些附加的AVPs將會在MS-CHAP-V2中發送給歸屬AAA。例如MS-CHAP-Domain。TTLS服務器必須能夠連同MS-CHAP2-Succes一起,隧道發送這些鑑權相關屬性。
- 服務器證書如何部署?
- X.509證書格式,沒有具體研究,需要參考RFC2459,在TTLS、TLS中使用X.509v3版本的證書。
- “當Client以內部之Issuer的公匙驗證TTLS Server”,客戶端內部Issuer的公匙是什麼,如何驗證服務器發送回來的證書?->可以暫不考慮,我們可以只考慮服務器端需要處理的流程。
- 有關TTLS流程中的握手協議定義,參考RFC2246的章節7.4。包括Hello Message、服務器/客戶端證書、證書驗證等消息格式和過程定義。
[1] PPP Extensible Authentication Protocol(EAP) RFC 2284。
[2] PPP EAP TLS Authentication Protocol RFC 2716。
[3] The TLS Protocol Version 1.0 RFC 2246。
[4] Remote Authentication Dial In User Service(RADIUS) RFC 2865。
[5] draft-ietf-pppext-eap-ttls-05 Paul Funk.July 2004。
[6] PPP Extensible Authentication Protocol (EAP) RFC3874。
[7] Microsoft PPP CHAP Extensions, Version 2 RFC2759
[8] Microsoft Vendor-specific RADIUS Attributes RFC2548