EAP-TTLS預研報告

  1. 概述

EAP-TTLS(Tunneled Transport Level Security)是由Funk Software與Certicom所共同開發,爲了提供一比EAP-TLS簡單的方式而開發。TTLS只需要Server端的Certificate而大大降低管理所需時間。對TTLS鑑權算法的功能描述如下:

  1. 允許用戶使用username和password鑑權,而不損安全性;
  2. 提供加強的交互驗證,credential security和dynamic keys;
  3. 僅需要將證書(certificates)部署在Radius服務器上,而不需要放在客戶端;
  4. 與現有的用戶安全數據庫兼容,包括Windows Active Directory, token systems,SQL,LDAP等等。

EAP-TTLS的特點如下:

  1. TTLS先利用Server Certificate建立一個Tunnel到Client,再利用這個Tunnel讓Client將其密碼或Certificate送給Server。
  2. TTLS的特色如:
    1. 它的Tunnel之中可搭配任何形式的驗證法,如Password、Certificate或Token,如MS-CHAPv2、MS-CHAP、CHAP、PAP、MD5等。
    2. 只需要Server端的Certificate。
    3. 不怕黑客的Dictionary攻擊。
    4. 支持雙向驗證,漫遊時的Fast Reconnection,以及自動變換Key。

EAP-TTLSv0v1兩種版本,v0版本是命名爲EAP-TTLSv1版本命名爲EAP-TTLSv1。根據協議和需求,我們需要支持的鑑權算法爲v0版本的TTLS算法,即EAP-TTLSv0版本。

  1. 術語

AAA/H:用戶歸屬域的AAA服務器,用於給歸屬域管理的用戶鑑權和授權。

TTLS Server:能夠支持EAP-TTLS算法的AAA服務器。該服務器也可以承擔用戶鑑權功能,或者能夠代理轉發用戶鑑權到AAA/H。

Access Point:接入點,提供基於AAA服務器返回的信息,實現用戶接入控制和策略功能的實體。在本文中「access point」和「NAS」在體系結構上是等同的。「access point」一般是指無線接入領域,「NAS」一般用戶傳統接入領域,例如撥號接入。

Client:通過接入點接入到網絡的主機或設備。

  1. 網絡結構模型

下圖爲EAP-TTLS應用的網絡結構模型。

 

        上圖描述的實體,是邏輯實體,並不一定是分開的網元。例如,TTLS Server和AAA/H可以合一;TTLS Server和Access Piont可以合一;甚至Access Piont、TTLS Server和AAA/H都合一。

        我們EAP-TTLS的實現方式應該爲AAA/H和TTLS Server合一方式。

    1. 傳輸協議

上圖實體之間的通信,使用可以封裝EAP消息的傳輸協議。Client和Access Piont之間使用鏈路層傳輸協議,例如PPP或EAPOL。Access Point、TTLS Server和AAA/H之間通信使用AAA傳輸協議,例如RADIUS或Diameter。

 

    1. 協議分層模型

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)本文檔不在贅述。詳見相關參考文獻。

 

    1. 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。第二階段的用戶鑑權也不是必選的,因爲在握手階段執行了服務器對客戶端的鑑權(可選),就不需要在進行用戶鑑權。

 

      1. 握手階段

當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服務器的證書的鑑權。

如果客戶端所希望鑑權是基於證書的鑑權,那麼客戶端自己也必須發行一個證書,而且必須保留一個基於證書的私鑰。

      1. 隧道階段

任何信息都可以在隧道階段進行交互,在此階段,客戶端把信息編碼到一系列的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。

 

      1. 產生密鑰元素(MSK

在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協議中定義的常量字符串中用戶名爲空的時候,發生衝突。

      1. 通過隧道成功進行CHAP鑑權流程

通過隧道成功進行CHAP鑑權。客戶端僅對服務器進行單向TLS鑑權認證,CHAP作爲隧道建立後的認證機制,並且TTLS服務器返回密碼套和密鑰元素。其中(1)-(11)屬於TLS握手階段,(11)-(15)屬於TLS隧道階段。EAP-TTLS的認證流程如下圖所示,分下列幾個步驟:

  1. AP收到後送出EAP-Request封包來要求Client做身份的驗證;
  2. Client收到後將身份識別數據送回給AP,僅包含域名信息,包括用戶名;
  3. AP對報文封裝後轉發給TTLS Server;
  4. TTLS Server收到客戶端發來的身份識別數據後,送出EAP-TTLS/START幀進行應答,要求開始EAP-TTLS會話過程(報文類型爲EAP-TTLS,無數據部分);
  5. AP將TTLS Server發給Client的身份識別數據轉發給Client;
  6. Client收到後發送Hello 報文(爲握手協議的開始),現在雙方的加密及壓縮數據的方式尚未協商完成,在Hello報文裏包含協商過程所需的參數,如:所用的TTLS版本、session ID、一個隨機數值與一些Client所能使用的整套加密方式(ciphersuite)等;
  7. AP將Client的Hello報文轉發給TTLS Server;
  8. 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);
  9. AP轉發給Client;當Client以內部之Issuer的公匙驗證TTLS Server。certificate_request時,必須要響應,響應的數據包含自己的證書、經自己簽署過的認證響應(certificate_verify驗證通過後,發送EAP-Response封包,包含建立session key的數據 (client_key_exchange)、設定完成加密的參數(change_cipher_spec)與TTLS完成的信息;
  10. TTLS Server端收到Client的EAP-Response,給Client發送EAP-Request再次確認加密的參數(change_cipher_spec)與TLS完成的信息。
  11. Client收到Server端的EAP-Request,握手階段結束。Client發送響應EAP-Response封包,攜帶用戶鑑權的AVP,使用CHAP鑑權時,攜帶User-Name、CHAP-Challenge、CHAR-Password。
  12. AP封裝爲RADIUS的Access-Request,轉發到歸屬AAA。
  13. 歸屬AAA完成用戶鑑權,鑑權通過後,發送Access-Acept消息給TTLS Server攜帶授權參數。
  14. TTLS Server收到歸屬AAA的RADIUS認證響應後,則會發送EAP-Success,表示EAP認證通過。
  15. AP向Client發送EAP-Success。

 

 

 

 

      1. 通過隧道成功進行EAP-MD5鑑權流程

使用EAP-MD5用戶鑑權,在握手階段是和CHAP相同,僅僅區別在於隧道階段使用MD5鑑權算法。

 

    1. EAP-TTLS編碼

EAP-TTLS是EAP算法中的一種,分配的EAP代碼爲21。除了下面子章節描述的之外,其他的編碼方式與EAP-TLS一樣(參考RFC2716)。

      1. EAP-TTLS Start Packet

EAP-TTLS Start packet可能將來的協議中允許包含數據(EAP-TLS Start packet是不包含數據的)。

這樣,EAP-TTLS Start packet包含數據被預留將來標準化,在這期間,服務器不能在EAP-TTLS Start packet中包含任何數據,客戶端必須忽略這些數據而不是拒絕。

      1. EAP-TTLS Packets with No Data

本節用來澄清不包含數據的EAP-TTLS packet,不同於EAP-TTLS Start packet。

EAP-TLS中定義這種包是作爲分包數據的響應使用的。當任何一方需要分包發送EAP-TLS packet,另外一方收到後回覆分包的響應,用於告知發起方發送下一個分包片斷。

EAP-TTLS使用分包響應的作用是和TLS一樣的。當然也有另外一些場景需要發送EAP-TTLS packet with no data:

  1. 當TTLS Server發送最後一個協商階段的EAP會話包時,Client必須響應EAP-TTLS packet with no data,用於允許TTLS Server發送最後的EAP-Success或EAP-Failure包;
  2. 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通過發送密鑰分發選擇,繼續協商階段。
    1. TLS層AVPs封裝
      1. AVP格式

    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字段。

 

      1. AVP序列

在TLS層封裝的數據是由一系列的0或AVPs組成。在序列中,每一個AVP和前一個AVP必須一個四字節的邊界間隔,如果一個AVP不是四字節的整數倍,最後用0填充。

注意:AVP長度不包括填充的0。

 

      1. AAA Server最大兼容性方針

爲了實現最大限度的兼容性,建議遵守以下AVP的使用指導原則:

  1. Non-vendor-specific AVPs必須從RADIUS定義的屬性中選擇,那就是說,屬性代碼必須小於256。這就能夠提供RADIUS和DIAMETER的兼容性。
  2. Vendor-specific AVPs必須在RADIUS術語中定義。Vendor-specific RADIUS屬性能夠自動地轉換爲Diamter,反之不行。RADIUS Vendor-specific 屬性使用RADIUS屬性26和包括wendor ID、Vendor-specific屬性編碼和長度,參見RFC2865。

 

    1. 隧道鑑權

Tunnel之中可搭配任何形式的驗證法,如Password、Certificate或Token,如MS-CHAPv2、MS-CHAP、CHAP、PAP、MD5等。

      1. 隱挑戰

        某些鑑權協議使用的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);

 
      1. 隧道鑑權協議

本文重點介紹如何在隧道階段使用MSCHAPv2協議。

        1. MS-CHAPv2

MS-CHAP v2是一種基於密碼的質詢-響應式相互身份驗證協議,使用工業標準的「信息摘要 4(Message Digest 4,MD4)」和數據加密標準(Data Encryption Standard,DES)算法來加密響應。身份驗證服務器質詢接入客戶端,然後接入客戶端又質詢身份驗證服務器。如果其中任一質詢沒有得到正確的回答,連接就被拒絕。MS-CHAP v2最初是由Microsoft當作一種PPP身份驗證協議來設計的,以便爲拔入和虛擬專用網(v*n)連接提供更好的保護。對於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一起,隧道發送這些鑑權相關屬性。

 

  1. 遺留問題
  1. 服務器證書如何部署?
  2. X.509證書格式,沒有具體研究,需要參考RFC2459,在TTLSTLS中使用X.509v3版本的證書。
  3. 「當Client以內部之Issuer的公匙驗證TTLS Server」,客戶端內部Issuer的公匙是什麼,如何驗證服務器發送回來的證書?->可以暫不考慮,我們可以只考慮服務器端需要處理的流程。
  4. 有關TTLS流程中的握手協議定義,參考RFC2246的章節7.4包括Hello Message、服務器/客戶端證書、證書驗證等消息格式和過程定義。
  1. 參考資料

[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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在,都有一个你没有努力的曾经。