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-TTLS有v0和v1兩種版本，v0版本是命名爲EAP-TTLS，v1版本命名爲EAP-TTLSv1。根據協議和需求，我們需要支持的鑑權算法爲v0版本的TTLS算法，即EAP-TTLS的v0版本。

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. 1. 傳輸協議

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

 

1. 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. 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 1. 通過隧道成功進行EAP-MD5鑑權流程

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

 

1. 1. EAP-TTLS編碼

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

1. 1. 1. EAP-TTLS Start Packet

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

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

1. 1. 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. 1. 1. AVP序列

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

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

 

1. 1. 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. 1. 隧道鑑權

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

1. 1. 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. 1. 1. 隧道鑑權協議

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

1. 1. 1. 1. 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一起，隧道發送這些鑑權相關屬性。

 

1. 遺留問題

1. 服務器證書如何部署？
2. X.509證書格式，沒有具體研究，需要參考RFC2459，在TTLS、TLS中使用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