摘要

本文檔描述了利用遠程撥入用戶認證服務(RADIUS)協議在網絡訪問服務器(NAS)和共享的計費服務器之間傳送認證、授權和計費信息的額外屬性。其中RADIUS協議在RFC2865和RFC2866中描述。

目 錄
1引言 6
2具體操作 6
2.1RADIUS對之間計費更新的支持 6
2.2RADIUS對Apple遠程接入協議的支持 7
2.3RADIUS對擴展認證協議（EAP）的支持 11
2.3.1協議回顧 11
2.3.2重傳 12
2.3.3分片 13
2.3.4舉例 13
2.3.5選擇使用 20
3報文格式 20
4報文類型 20
5屬性 20
5.1Acct-Input-GigaWords 23
5.2Acct-Output-Gigawords 23
5.3Event-Timestamp 24
5.4ARAP-Password 25
5.5ARAP-Features 26
5.6ARAP-Zone-access 28
5.7ARAP-Security 29
5.8ARAP-Security-Data 30
5.9Password-Retry 31
5.10 PRompt 31
5.11 Connect-Info 32
5.12 Configuration-Token 33
5.13 EAP-Message 34
5.14 Message-Authenticator 36
5.15 ARAP-Challenge-Response 38
5.16 Acct-Interim-Interval 39
5.17 NAS-Port-Id 40
5.18 Framed-Pool 40
5.19 屬性表 41
6IANA 考慮事項 42
7安全考慮事項 42
7.1Message-Authenticator安全 42
7.2EAP安全 43
7.2.1EAP服務器和PPP認證者分離 43
7.2.2連接劫持 43
7.2.3中間的攻擊 44
7.2.4多數據庫 44
7.2.5協商攻擊 44
8. References ............................................ 43
9. Acknowledgements ...................................... 44
10. Chair's Address ....................................... 44
11. Authors' Addresses .................................... 45
12. Full Copyright Statement .............................. 47

1. 引言
RFC2865和RFC2866描述了如何利用RADIUS協議進行認證和計費，目前正在應用。本文檔建議了幾個額外的屬性，可以實現多種非常有用的功能，這幾個額外的屬性可以添加到RADIUS協議中。這幾個屬性目前沒有大面積使用的經驗，因此只能看作是實驗性的。
擴展認證協議（EAP）是對PPP協議的擴展，通過EAP可以在PPP協議內支持額外的認證方法。本文檔描述了RADIUS協議如何利用EAP-Message和Message-Authenticator屬性支持EAP。
所有的屬性由Type-Length-Value三元組組成。可以添加新的屬性值而又不影響協議的實現。

1.1. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [4].

An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the must, must not, should and
should not requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not requirements
for its protocols is said to be "conditionally compliant."

A NAS that does not implement a given service MUST NOT implement the
RADIUS attributes for that service. For example, a NAS that is
unable to offer ARAP service MUST NOT implement the RADIUS attributes
for ARAP. A NAS MUST treat a RADIUS access-request requesting an
unavailable service as an access-reject instead.

1.2. Terminology

This document uses the following terms:

service The NAS provides a service to the dial-in user, sUCh as PPP
or Telnet.

session Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session
defined as the point where service is first provided and
the end of the session defined as the point where service





Rigney, et al. Informational [Page 3]

RFC2869 RADIUS Extensions June 2000


is ended. A user may have multiple sessions in parallel or
series if the NAS supports that, with each session
generating a separate start and stop accounting record.

silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.

2.具體操作
具體操作同RFC2865和RFC2866中定義的完全相同
RADIUS對之間計費更新的支持
當用戶認證通過以后，RADIUS服務器對認證請求報文Access-Request回應一個認證接受報文Access-Accept。假如服務器希望接到用戶的中間流量報文，那么在認證接受報文Access-Accept中必須包含RADIUS屬性Acct-Interim-Interval。這個屬性指明了中間計費報文的時間間隔（以秒為單位）。
當然，也可以在NAS上通過靜態配置設定一個中間計費報文的時間間隔。需要注重的是：這個NAS上配置的局部的時間間隔值必須覆蓋包含在認證接受報文Access-Accept中攜帶的時間間隔值。
這個方案并不會破壞后向兼容性。因為不支持這個擴展屬性的RADIUS服務器當然不會添加這個新的屬性。同樣，不支持這個擴展屬性的NAS也會忽略此屬性。
注重，在中間計費報文中的信息是累積的，即：報文中的發送分組數量是從會話開始的總的分組數量，而不是從上一個中間計費報文以后的分組數量。
可以預見，中間計費記錄（其中屬性Acct-Status-Type = Interim-Update (3)）中除了不包含屬性Acct-Term-Cause外，包含了計費結束報文中其它的所有屬性。
既然信息是累積的，NAS必須保證在給定的任何時間在重發隊列中對于某一個會話只有一個單獨的中間計費報文存在。NAS可以利用fudge因子在對應于不同會話的中間計費報文之間增加一段隨機時延。這樣可以避免所有的報文馬上發送。
利用中間計費更新應該認真考慮網絡和NAS CPU的負擔，因此應該合理選擇中間計費間隔Acct-Interim-Interval。
RADIUS對Apple遠程接入協議的支持
RADIUS協議提供了答應多個NAS共享同一個認證數據庫的一種方法。
Apple遠程接入協議（ARAP）支持在點到點鏈路上傳送AppleTalk網絡流量，點到點鏈路通常（但不唯一）是異步和ISDN交換電路連接。盡管Apple在未來的遠程接入業務中朝著ATCP on PPP的方向發展，但對已經使用遠程接入的Macintosh用戶來說，RARP仍然是一種普通的方法，而且可能要存在一段時間。
有幾個NAS提供商支持ARAP，同時，這些提供商在同一個NAS上也支持PPP、IPX和其它協議。在這些支持多協議的設備上通常不用RADIUS對ARAP連接進行認證，即便有，不同的提供商分別提供不同的解決方案。
本節描述支持RARP協議的RADIUS幾個額外屬性的使用。符合本規范的RADIUS客戶端和服務器端實現應該用可以互操作的方式對ARAPR連接驗證。
本節的討論假定讀者對RADIUS協議已很熟悉，因此首先直接探究ARAP應用的具體細節，然后再具體討論RADIUS協議的額外屬性。
本文檔不討論的兩個ARAP特色如下：
1. 用戶發起的密碼改變。這不是RADIUS的一部分，但可以通過軟件過程實現。
2. 帶外報文。NAS任何時候都可以向ARA客戶端發送報文，報文以對話框的形式顯示在 撥號接入用戶的屏幕上。這不屬于認證的一部分，也不屬于此處討論的范疇。但我們 注重到 認證接受報文Access-Accept中的Reply-Message屬性可以利用帶外信道傳給用 戶。
我們盡可能多地尊重已有的RADIUS協議精神，使設計與以前的技術兼容。更進一步討論，我們需要在兩方面作出平衡選擇處理。一方面，過多的新屬性造成RADIUS世界的泛濫；另一方面，將整個ARAP操作隱藏在一個單獨的復合ARAP屬性串中，或者在擴展認證協議（EAP）的機制內解決。
但是，我們認為只要保證幾個類似命名的屬性，ARAP從PPP分離出來就足夠了。
我們已經假定能夠理解ARAP的RADIUS服務器可以進行DES加密且可以產生安全模式挑戰字。這正與RADIUS的如下目標一致：靈活服務器/簡單NAS。
ARAP對一個連接的認證分兩個階段。第一個階段是利用用戶密碼作為密鑰，互換一個“二次DES”隨機數。之所以說是“二次”，是因為ARAP NAS挑戰撥號接入用戶對自己進行驗證，同樣，撥號接入用戶挑戰ARAP NAS從對自己進行驗證。
非凡地，ARAP執行如下過程：
1. NAS在ARAP的msg_auth_challenge分組中向撥號接入用戶發送兩個32位的隨機數。
2. 撥號接入用戶收到NAS發來的兩個隨機數后，利用用戶密碼對這兩個隨機數進行DES加 密，然后撥號接入客戶端將此加密后的結果連同用戶名和客戶端產生的兩個32位的隨機數 在ARAP msg_auth_request分組中回應給NAS。
3. NAS接收到以后，確認由撥號接入客戶端發送過來的經過加密的隨機數是否是自己所期望 的。假如是，它利用密碼對撥號接入客戶端發送過來的挑戰字進行加密，并且把加密后的 結果在ARAP msg_auth_response分組中發給撥號接入客戶端。
注重假如撥號接入客戶端的響應錯誤（這意味著用戶密碼錯誤），服務器可以重發，直到重發次數達到NAS答應的最大發送次數。在這種情況下，當撥號接入客戶端接收到ARAP msg_auth_response分組后，將用ARAP msg_auth_again分組進行確認。
第一個“DES Phase”階段通過以后，ARAP NAS可以利用被Apple稱之為“Add-In Security Modules”的機制發起第二個認證階段。 Security Modules是運行在客戶端和服務器上的幾小段代碼，答應通過通訊鏈路讀和寫任意數據，從而實現額外的認證功能。各種安全令牌提供商利用這種機制對ARA呼叫者進行認證。
盡管ARAP答應安全模塊讀寫它們所需要的任意信息，但是已經存在的安全模塊是利用簡單的挑戰和響應循環，當然可能攜帶某些全局控制信息。本文檔假定利用一個或幾個challenge/response循環可以支持所有已經存在的安全模塊。
在DES Phase之后，Security Module phase之前，RAP向下發送某些概貌信息，使RADIUS和ARAP集成復雜。這意味著，在某些異常時間，除了對challenge的響應以外，還必須存在概貌信息。幸運的是這些信息只是幾個與密碼相關的數字，本文檔中把這些信息封裝在一個單獨的新的屬性中。
向RADIUS發送一個Access-Request報文代表ARAP連接是非常直接的。ARAP NAS產生一個隨機的數字挑戰字，然后接受撥號接入客戶端的響應，客戶端的挑戰字和用戶名。假定用戶不是一個guest，在Access-Request分組中轉發如下信息： User-Name（最長31個字符），Framed-Protocol （對于ARAP，此域值填為3），ARAP-Password和其它希望攜帶的屬性，如Service-Type， NAS-IP-Address，NAS-Id，NAS-Port-Type，NAS-Port，NAS-Port-Id， Connect-Info等。
Request Authenticator是一個NAS產生的16字節的隨機數。這個隨機數的低8個字節作為兩個四字節的隨機數放在ARAP msg_auth_challenge報文中傳給撥號接入用戶。其中字節0-3作為第一個隨機數，字節4-7作為第二個隨機數。
Access-Request報文中的ARAP-Password包含一個16 字節的隨機數域，用來攜帶撥號進入用戶對NAS挑戰的響應及客戶端自己 對NAS的挑戰字。高字節包含撥號接入用戶對NAS的挑戰字（2個32位的數字，共8字節），第字節包含撥號接入用戶對NAS挑戰的響應（2個32位的數字，共8字節）。
User-Password， CHAP-Password 或ARAP-Password三個屬性在Access-Request報文中只能出現一個，也可以出現一個或多個EAP-Messages。
假如RADIUS服務器不支持ARAP，它應該向NAS返回一個Access-Reject報文。
假如RADIUS服務器不支持ARAP，它應該利用Challenge（Request Authenticator中的低8個字節）和用戶響應（ARAP-Password 中的低8個字節）來確認用戶的響應。
假如認證失敗，RADIUS服務器應該向NAS返回一個Access-Reject報文，報文中攜帶可選屬性Password-Retry和Reply-Messages。假如攜帶Password-Retry屬性，這就告知ARAP NAS可以選擇再發起幾個挑戰-響應循環，直到循環次數等于Password-Retry屬性中的整數值。
假如用戶認證通過，RADIUS服務器應該向NAS返回一個Access-Accept報文（Code等于2），ID和Response Authenticator跟通常情況一樣，其它屬性如下：
Service-Type of Framed-Protocol
Framed-Protocol of ARAP (值為3)
Session-Timeout，它代表用戶可以連接的最長時間（以秒為單位）。假如用戶被授權為無限 制用戶，那么在Access-Accept報文中就不應該包含Session-Timeout屬性。此時ARAP將用戶作為無限制用戶超時（值為-1）。
ARAP-Challenge-Response，它包含8個字節，代表對撥號接入用戶的響應。RADIUS是用如下方法填充出此屬性的。RADIUS服務器從ARAP-Password屬性中取出高8個字節（實際為撥號接入用戶的挑戰），然后再用認證用戶的密碼作為密鑰，對前邊已取出的用戶的挑戰進行DES加密。假如用戶的密碼在長度上小于8個字節，那么就在用戶密碼填充NULL字節，直到滿8個字節；假如用戶密碼長度大于8個字節，那就應該返回一個Access-Reject報文。
ARAP-Features，它包含了NAS在ARAP“feature flags”報文中將攜帶給用戶的信息。
字節0：假如值為0，表示用戶不能改變密碼，假如值不為0，表示用戶可以改變密碼（RADIUS不處理密碼更改，僅用屬性指明ARAP是否可以改變密碼）。
字節1：表示最小的可接受的密碼長度（0-8）。
字節2-5：表示Macintosh格式的密碼產生日期，為一32位的無符號整數，代表從Midnight GMT January 1, 1904以后的總的時間（以秒為單位）。
字節6-9：表示從密碼產生以后的有效時間長度（以秒為單位）。
字節10-13：以Macintosh格式表示的目前RADIUS時間。
作為可選項，回應報文中可以包含Reply-Message屬性，其內容為一字符串，最多可以包含253個字符，這些內容可以在對話框中顯示給用戶。
Framed-AppleTalk-Network：此屬性可以包含在報文中。
Framed-AppleTalk-Zone：此屬性可包含在報文中，最大長度為32個字符。
對于一個用戶，ARAP定義了區域列表。與區域名字列表一起，ARAP定義了區域訪問標志（被NAS使用），此標志說明了如何利用區域名字列表。即：撥號接入用戶可能只答應訪問缺省區域，或者只能訪問區域列表中區域，也或者只能訪問除區域列表中列出的以外的其它區域。
ARAP NAS中含有一個指定的濾波器，用此濾波器可以處理此問題，其中濾波器起碼的區域名字。用此機制，解決了如下問題：用一個單獨的RADIUS服務器治理不同的NAS客戶端，并且客戶端有或許不能全部看到用戶區域列表中的區域名字。區域名字只對NAS才有意義。這種方法的不足之處在于濾器必須在首先NAS中以某種方式啟動，然后再由RADIUS Filter-Id引用。
ARAP-Zone-Access屬性中包含一個整數，此屬性指明了該如何使用針對一個用戶的區域列表該。假如包含此屬性且其值為2或4，那么就必須包含Filter-Id屬性，Filter-Id屬性命名了一個適用訪問標記的濾波器。
在Access-Accept報文中包含Callback-Number或Callback-Id屬性可能導致ARAP NAS在發送Feature Flags開始回調處理后切斷連接。其中回調處理是以一種ARAP特有的方式進行。
在Access-Accept報文中也可以包含其它屬性。
ARAP要完成到客戶端撥號接入的連接，還需要其它信息。這種信息可由ARAP NAS通過SNMP配置，NAS治理程序或從NAS的AppleTalk堆棧中獲得，不需要RADIUS的任何幫助。非凡地：
1. 將AppearAsNet和AppearAsNode值傳送給客戶端，告訴它在數據報分組中應該適用什么樣的網絡和節點值。 AppearAsNet可以從Framed-AppleTalk-Network屬性中獲得，或者通過配置，或者通過NAS的堆棧獲得。
2. 撥號接入終端將出現在缺省區域內，缺省區域也就是AppleTalk的名字。 （或者用Framed-AppleTalk-Zone屬性指明）
3. 其它的NAS特有的資料，如NAS的名字和smartbuffering信息。（Smartbuffering是ARAP的一種機制。它用小的令牌取代普通的AppleTalk數據報，從而改善了某些普通慢鏈路的性能。）
4. 用戶的“Zone List”信息。 ARAP規范定義了一個“zone count”域，實際上沒有使用。
RADIUS用以下方式支持ARAP Security Modules。
DES認證結束以后，RADIUS服務器通知ARAP NAS為撥號接入用戶運行一個或多個security modules。盡管基本的協議支持連續執行多個security modules，但在實踐中，目前的實現只答應實現一個。通過使用多個Access-Challenge請求，就可以支持多個安全模式，但這種功能可能永遠不會被使用。
同時我們也假定，盡管ARAP答應在點到點鏈路的端點上安全模式之間使用自由格式的對話，但在實踐中，所有的安全模式可以簡化為簡單的挑戰/響應循環。
假如RADIUS服務器希望通知ARAP NAS運行一個安全模式，那么它應該給NAS發送一個Access-Challenge報文，作為可選項，報文中可以攜帶State屬性，加上ARAP-Challenge-Response ，ARAP-Features和其它兩個屬性：
ARAP-Security：一個四字節的模式簽名，包含一個Macintosh OSType。
ARAP-Security-Data：一個字符串，攜帶了實際的模式挑戰和響應。
當執行完安全模式，NAS向RADIUS再發送一個Access-Request報文，報文中的屬性ARAP-Security-Data包含了安全模式的響應，同時也包含Access-Challenge中得到的State屬性。 在這種情況下，authenticator域內不再包含非凡的信息，因為可以由存在的State屬性來辨別。
RADIUS對擴展認證協議（EAP）的支持
擴展認證協議（EAP）描述了在PPP內支持額外認證的一種標準機制。通過EAP，可以支持許多額外認證方案，包括智能卡（Smart card )，Kerberos，Public Key，One Time Passwords和其它多種。為了在RADIUS內支持EAP，本文檔引入了兩個新的屬性： EAP-Message和Message-Authenticator。本節描述了RADIUS如何利用這兩個新的屬性來支持EAP。
在提出的方案中，利用RADIUS服務器在NAS和后端安全服務器之間傳送封裝在RADIUS內的EAP報文。盡管可以利用后端服務器發展的私有協議在RADIUS服務器和后端服務器之間進行會話，但通過將EAP報文封裝在RASIUS報文的EAP-Message屬性內也是可能的。這樣的優點是RADIUS服務器為了支持EAP，不需要增加針對某種認證的代碼，這些針對某種認證的代碼的可以放在后端安全服務器上。
協議回顧
認證對等端（撥號接入用戶）和NAS之間的EAP會話以LCP中的EAP協商開始。一旦EAP協商通過，NAS必須向認證對等端發送一個EAP-Request/Identity報文，除非通過其它途徑如Called-Station-Id或Calling-Station-Id確定了身份。認證對等端然后向NAS發送一個EAP-Response/Identity報文，NAS收到此報文后封裝在RADIUS的Access-Request報文的EAP-Message屬性內轉發給RADIUS服務器。RADIUS服務器通常將利用EAP-Response/Identity來斷定將對用戶使用何種EAP類型。
為了答應不能理解EAP的RADIUS代理轉發Access-Request報文，假如NAS發送EAP-Request/Identity，NAS必須將EAP-Response/Identity中的內容拷貝到User-Name屬性中，同時在隨后的每一個Access-Request報文中的User-Name屬性中必須包含EAP-Response/Identity。 也建議將NAS-Port和NAS-Port-Id屬性包含在NAS發送的Access-Request報文中，而NAS-Identifier和NAS-IP-Address則必須包括在內。為了答應不理解EAP的代理能夠轉發Access-Reply，假如在Access-Request中包含User-Name屬性，RADIUS服務器在隨后的Access-Accept中必須包含User-Name屬性。假如沒有用戶名屬性，計費和生成帳單將變得非常難于治理。
假如通過其它途徑如Called-Station-Id或Calling-Station-Id確定了身份，NAS在每一個Access-Request報文中必須包含這些身份屬性。
盡管這種方法將節省一個往返，但是不通用。在某些情況下（如認證和計費是基于Called-Station-Id或Calling-Station-Id），用戶的身份可能不需要，因此NAS就不必向認證對等端方發送EAP-Request/Identity報文。當NAS不需要發送EAP-Request/Identity報文時，NAS將向RADIUS服務器發送一個RADIUS Access-Request報文，其中攜帶EAP-Message屬性，意味著EAP-Start。通過攜帶一個2字節的EAP-Message屬性（沒有數據）來指明EAP-Start。需要注重的是：由于Access-Request報文中沒有攜帶User-Name屬性，這種方法同RFC2865種描述的RADIUS不兼容，同時也不適用于代理的情況，如漫游和共享使用網絡。
假如RADIUS服務器支持EAP，它必須用Access-Challenge報文響應，報文中攜帶EAP-Message屬性。 假如RADIUS服務器不支持EAP，它必須用Access-Reject報文響應。 EAP-Message屬性攜帶包括一個封裝的EAP報文，此EAP報文被繼續傳送給認證端。假如NAS沒有向認證對等端發起一個EAP-Request/Identity報文，那么Access-Challenge報文通常會包含一個EAP-Message屬性，此屬性中封裝有一個EAP-Request/Identity報文，請求撥號接入終端確定自己的身份。此時NAS以Access-Request報文作為響應，報文中包含屬性EAP-Message，此屬性中封裝有EAP-Response報文。會話一直繼續，直到收到一個RADIUS Access-Reject報文或Access-Accept
報文。
一旦收到一個RADIUS Access-Reject報文，不管有還是沒有一個EAP-Failure報文封裝在屬性EAP-Message中，都將導致NAS向認證對等端發送一個LCP Terminate Request報文。假如收到一個RADIUS Access-Accept報文，并且報文中攜帶有一個封裝有EAP-Success報文的EAP-Message屬性，那么認證階段就結束。 RADIUS Access-Accept/EAP-Message/EAP-Success報文中必須包含所有期望的由Access-Accept帶回的屬性。
對于上面所描述的方案，NAS從來不需要對EAP進行操作。另外一種替代方案是EAP-Request/Identity報文總是由NAS向認證對等端發送。
對于代理RADIUS請求，有兩種處理方法。假如基于Called-Station-Id來確定域，那么RADIUS服務器可以代理最初的RADIUS Access-Request/EAP-Start。假如域是基于用戶身份來確定的，那么本地RADIUS服務器必須用一個RADIUS Access-Challenge/EAP-Identity報文響應。從認證對等端返回的響應必須被代理給最終的認證服務器。
對于代理RADIUS請求，NAS可能收到一個Access-Reject報文，此報文是對Access-Request/EAP-Identity報文的響應。假如請求報文被代理給一個不支持EAP-Message擴展的RADIUS服務器，上述情況就會發生。一旦收到一個Access-Reject報文，NAS就必須向認證對等端發送一個LCP Terminate Request報文，終端連接。
重傳
如同RFC2284所描述的那樣，EAP認證者（NAS）負責認證對等端和NAS之間的報文重傳。因此一旦一個報文從認證對等端傳到NAS的過程中丟失（反之亦然），NAS將重傳。這類似于RFC2865中所描述的RADIUS，RADIUS客戶端負責RADIUS客戶端和RADIUS服務器之間的報文重傳。
需要注重的是在某些情況下有必要調整重傳策略和認證超時時間。例如，假如使用智能卡，那么就必須給用戶留出額外的時間以便用戶找到卡且輸入卡的代號。由于NAS通常不了解所需要的參數，因此這些參數需要RADIUS服務器提供。這個問題可以這樣解決：在Access-Challenge報文內包含Session-Timeout和Password-Retry屬性。
假如在Access-Challenge報文中包含Session-Timeout屬性和EAP-Message屬性，Session-Timeout的值指出了NAS在向撥號接入用戶重傳EAP-Message報文，等待EAP-Response報文的最長時間（以秒為單位）。
分片
利用EAP-Message屬性，RADIUS服務器可能將一個大于NAS和認證對等端之間鏈路MTU的EAP報文封裝在屬性內。由于RADIUS服務器不可能利用MTU發現來確定鏈路MTU，因此可以在一個攜帶EAP-Message屬性的Access-Request報文中再攜帶Framed-MTU屬性，由此可以給RADIUS服務器提供信息。
舉例
下面的例子給出了認證對等端、NAS和RADIUS服務器之間的會話。例中使用One Time Password（OTP）進行認證。用OTP認證，只是為了演示的目的，實際也可以用其它認證協議。若用其它認證協議，行為在某些方面可能不同。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------

<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->

RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase 結束，
NCP Phase 開始

假如NAS首先向RADIUS服務器發送一個EAP-Start報文給服務器，那么會話過程如下：

Authenticating Peer NAS RADIUS Server
------------------- --- -------------

<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EA-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase 結束，
NCP Phase 開始

假如客戶端EAP認證失敗，會話過程如下：

Authenticating Peer NAS RADIUS Server
------------------- --- -------------

<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure

<- PPP EAP-Failure
(客戶端終端連接)

假如RADIUS服務器或者代理不支持EAP-Message，會話過程如下：

Authenticating Peer NAS RADIUS Server
------------------- --- -------------

<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(用戶中斷連接)


假如本地RADIUS服務器支持EAP-Message，而遠端RADIUS服務器不支持，會話過程如下：
Authenticating Peer NAS RADIUS Server
------------------- --- -------------

<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity
(MyID) ->
RADIUS
Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Reject
(proxied from remote
RADIUS Server)
<- PPP LCP Terminate
(User Disconnected)


假如認證對等不支持EAP，但需要對用戶用EAP認證，會話過程如下：

Authenticating Peer NAS RADIUS Server
------------------- --- -------------

<- PPP LCP Request-EAP
auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)

假如NAS不支持EAP，而需要對用戶使用EAP認證，會話過程如下：

Authenticating Peer NAS RADIUS Server
------------------- --- -------------

<- PPP LCP Request-CHAP
Auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->

<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)

選擇使用
目前，由于沒有標準化，后端安全服務器和RADIUS服務器之間的會話是私有的。為了提高標準化程度，也為了提供RADIUS供給商和后端安全提供商之間的互通性，建議會話將EAP報文封裝在RADIUS內。
這樣作的好處是RADIUS服務器為了支持EAP，不需要與具體某種特定認證有關的代碼，與具體某種特定認證有關的代碼可以潴留在后端安全服務器上。
假如RADIUS服務器和后端安全服務器之間的會話使用RAIUS封裝的EAP報文，那么后端安全服務器通常會返回一個Access-Accept/EAP-Success報文，報文中不需要包含當前Access-Accept中返回的屬性。這意外著RADIUS服務器在向NAS發送Access-Accept/EAP-Success報文之前，必須添加這些屬性。
報文格式
報文格式同RFC2865和RFC2866中描述的完全相同。
報文類型
報文類型同RFC2865和RFC2866中描述的完全相同。
參見下面的“屬性表”來確定什么報文類型可以包含此處定義的什么樣的屬性。
屬性
RADIUS屬性攜帶著認證、授權和計費請求和響應的具體信息。
某些屬性可能被包含不止一次。這種效果是屬性特有的，并且在每一個屬性描述中指明。建議相同類型的屬性保持順序不變，而對于不同類型的屬性其順序則不必保持。
以RADIUS報文的長度指明屬性列表的末尾。
屬性格式的概述同RFC2865描述的相同，但為了引用方便，此處又列出屬性。按照從左至右的順序傳輸各域。

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Type域占一個字節。目前最新的RADIUS Type域值在最新的RFC1994中分配。屬性值192-223保留給實驗用，值224-240保留給非凡的實現用，值241-255保留不用。本規范涉及如下屬性值：

1-39 (參照RFC2865 [1], "RADIUS")
40-51 (參照 RFC2866 [2], "RADIUS Accounting")
52 Acct-Input-Gigawords
53 Acct-Output-Gigawords
54 Unused
55 Event-Timestamp
56-59 Unused
60-63 (參照 RFC2865 [1], "RADIUS")
64-67 (參照 RFC2868)
68 (參照 RFC2867）
69 (參照 RFC2868）
70 ARAP-Password
71 ARAP-Features
72 ARAP-Zone-Access
73 ARAP-Security
74 ARAP-Security-Data
75 Password-Retry
76 Prompt
77 Connect-Info
78 Configuration-Token
79 EAP-Message
80 Message-Authenticator
81-83 (參照 RFC2868）
84 ARAP-Challenge-Response
85 Acct-Interim-Interval
86 (參照 RFC2867）
87 NAS-Port-Id
88 Framed-Pool
89 Unused
90-91 (參照 RFC2868）
92-191 Unused

Length

Length域占一個字節，指明了屬性的長度，長度包括Type， Length 和Value域的總長度。假如接收到的報文中屬性長度錯誤，那么整個請求報文都要被默默丟棄。

Value

Value域占0個或多個字節，里邊包含屬性特有的消息。格式和長度由Type和Length域決定。
需要注重的是對RADIUS的類型，其Value域都不以NULL（十六進制00）結束。非凡地，“文本”類型和“字符串”類型都不以NULL結束（十六進制00）。屬性有一個長度域，不使用結束符。文本包含UTF-8編碼的10646字符，而字符串包含8位的二進制數據。服務器和客戶端必須能夠處理報文中包含的null。利用C作為實現工具的RADIUS一定要注重不能使用strcpy()函數處理字符串。
value域的格式使用無種類型中的一種，需要注重的是“文本”是“字符串”的子集。

text 長度為1-253個字節，包含UTF-8格式編碼的10646字符。假如文本的長度為0，那么就忽略掉此屬性，不被傳遞。

String 1-253個字節，包含二進制數據（也包括十進制0-255）。假如值域長度為0，那忽略整個屬性，不予傳遞。

Address 32 位的無符號值，最重要的字節在前。
Integer 32 位的無符號值，最重要的字節在前。

Time 32 位的無符號值，最重要的字節在前 -- 從00:00:00 UTC, January 1, 1970以后的時間（以秒為單位）。


Acct-Input-Gigawords
描述
這個屬性描述了自從提供服務以來，Acct-Input-Octets 計數器已經反轉過 2^32 多少次，并且此屬性只能出現在Accounting-Request記錄中，其中Acct-Status-Type值為Stop或Interim-Update。
Acct-Input-Gigawords屬性格式如下所述，從左至右傳輸各域。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

52 for Acct-Input-Gigawords.

Length

6

Value

Value 域占4個字節。

Acct-Output-Gigawords
描述
這個屬性描述了自從傳遞服務以來，Acct-Output-Octets 計數器已經反轉過 2^32 多少次，并且此屬性只能出現在Accounting-Request記錄中，其中Acct-Status-Type 值為 Stop 或 Interim-Update。
Acct-Output-Octets屬性格式如下所述，從左至右傳輸各域。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

53 for Acct-Output-Gigawords.

Length

6

Value

Value 域占4個字節。

Event-Timestamp
描述
這個屬性包含在Accounting-Request報文中，記錄了事件在NAS上的發生時間，從January 1, 1970 00:00 UTC開始計算（以秒為單位）。
Event-Timestamp屬性格式如下所述，從左至右傳輸各域。



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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

55 for Event-Timestamp

Length

6

Value

Value 域占4個字節，將從January 1,1970 00:00 UTC開始計算的時間（以秒為單位）編碼成一個無符號的整數。


ARAP-Password
描述
這個屬性只出現在Access-Request報文中，報文中包含一個ARAP的Framed-Protocol。
在Access-Request報文中，只需出現User-Password、CHAP-Password或ARAP-Password中的一個，報文中也出現一個或多個EAP-Messages。
ARAP-Password屬性格式如下所述，從左至右傳輸各域。





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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

70 for ARAP-Password.

Length

18

Value

這個屬性包含一個16字節的字符串，用來攜帶撥號接入用戶對NAS挑戰的響應及客戶端自己對NAS的挑戰。高階字節（Value1 和 Value2）包含了撥號接入用戶對NAS挑戰的響應（2個32位的數字，共8個字節），低階字節（Value3 和 Value4）包含了撥號接入用戶對NAS的挑戰（2個32位的數字，共8個字節），

ARAP-Features
描述
這個屬性出現在Access-Accept報文中，報文中同時包含一個ARAP的Framed-Protocol屬性。 ARAP-Features屬性包含了NAS將要以ARAP "feature flags"報文發送給用戶的密碼信息。
在Access-Request報文中，只需出現User-Password、CHAP-Password或ARAP-Password中的一個，報文中也出現一個或多個EAP-Messages。
ARAP-Features屬性格式如下所述，從左至右傳輸各域。


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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value1 Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

71 for ARAP-Features.

Length

16

Value

Value域是一個復合字符串，包含了NAS將要在ARAP "feature flags"報文中發送給用戶的信息。

Value1: 假如為0，表示用戶不能改變他們的密碼，假如不等于0，表示用戶可以修改他們的密碼。（RADIUS不處理密碼改變，只是用屬性指明ARAP是否可以改變密碼）

Value2: 可接受的最小的長度的密碼，值從0到8。

Value3: 以Macintosh格式表示的密碼產生日期，為一32位的無符號整數，表示從Midnight GMT January 1, 1904以后的秒數。

Value4: 密碼從產生以來的有效時間（以秒為單位）。

Value5: 以Macintosh格式表示的RADIUS目前 時間。


ARAP-Zone-Access

描述
這個屬性同ARAP的Framed-Protocol屬性一起出現在Access-Accept報文中，指出該如何使用針對用戶的區域列表。
ARAP-Zone-Access屬性格式如下所述，從左至右傳輸各域。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

72 for ARAP-Zone-Access.

Length

6

Value

Value 域占4個字節，對如下整數值進行編碼：

1 只答應訪問缺省區域
2 答應訪問區域濾波器包含的區域
4 答應訪問區域濾波器不包含的區域


數值3跳過，不是因為這是位標記，而是因為在某些ARAP實現中，數值3意味著“所有區域”，在所有RADIUS下，這跟完全沒有指明區域一樣。

假如存在此屬性，并且屬性值為2或者4，那就必須攜帶屬性Filter-Id，用Filter-Id命名一個采用訪問標記的區域列表濾波器。

ARAP-Security

描述
這個屬性鑒別了一個在Access-Challenge報文中使用的ARAP Security Module。
ARAP-Security屬性格式如下所述，從左至右傳輸各域。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

73 for ARAP-Security.

Length

6

Value

Value域占4個字節，包含一個整數，指明安全模式簽名，其格式為 Macintosh OSType。（Macintosh OSTypes 是4個ascii字符，分配作為一個32位的整數）

ARAP-Security-Data

描述

這個屬性包含了實際的安全模式挑戰或響應，可以在Access-Challenge和Access-Request報文中找到。
ARAP-Security-Data屬性格式如下所述，從左至右傳輸各域。

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

74 for ARAP-Security-Data.

Length

>=3

String

String 域包含了與在ARAP-Security指定的ARAP Security Module相關的安全模式挑戰或響應。
Password-Retry

描述

這個屬性可以出現在Access-Reject報文中，用來指明用戶在被切斷以前可以被答應嘗試多少次認證。
此屬性最初主要是給ARAP認證使用的。
Password-Retry屬性格式如下所述，從左至右傳輸各域。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

75 for Password-Retry.

Length

6

Value

Value 域占4個字節，包含一個整數，指明用戶可以嘗試密碼的次數。

Prompt

描述

這個屬性只能出現在Access-Challenge報文中，它向NAS指明當用戶進入NAS時，NAS是否應該回顯用戶的響應。
Prompt屬性格式如下所述，從左至右傳輸各域。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

76 for Prompt.


Length

6

Value

Value 域占4個字節。

0 沒有回顯
1 回顯

Connect-Info

描述

這個屬性由NAS發出，指明用戶連接的特性。
NAS可以在Access-Request或Accounting-Request中包含此屬性，指明用戶連接的特性。
Connect-Info屬性格式如下所述，從左至右傳輸各域。

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

77 for Connect-Info.

Length

>= 3

Text

文本域包含UTF-8格式編碼的10646字符。報文中第一個Connect-Info屬性的開始應該包括連接速度。假如傳輸和接收連接速度不同，那么它們必須全部包含在第一個屬性內，首先寫傳輸速度（即NAS modem的傳輸速度），后面跟一個反斜杠（/），再跟接受速度，然后是其它任選信息。如 "28800 V42BIS/LAPM" 或 "52000/31200 V90"。在Accounting-Request報文中可以包含一個或多個Connect-Info 屬性，以便讓modems用一種標準的格式報告更多的連接信息，信息的長度可能超過252字節。


Configuration-Token

描述

這個屬性應用在基于代理的大型分布式認證網絡中。此屬性由RADIUS代理服務器放在Access-Accept報文中發送給RADIUS代理客戶端，用來指明使用的用戶概況（表）。此屬性不應該發送給NAS。
Configuration-Token屬性格式如下所述，從左至右傳輸各域。

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

78 for Configuration-Token.

Length

>= 3

String

String域占一個或多個字節。實際的信息格式與使用的場所和應用有關，一個健壯的實現應該將此域當作未加區分的字節來支持。

應用此域的條件范圍已經超出了本規范的討論范圍。

EAP-Message

描述

本屬性用于封裝擴展認證協議（EAP）報文，以便讓NAS即使不理解EAP協議，也能利用EAP對撥號接入用戶進行認證。

NAS把從用戶接收到的EAP報文放在一個或多個EAP屬性中，作為Access-Request的一部分，轉發給RADIUS服務器，RADIUS服務器可以在Access-Challenge, Access-Accept 或 Access-Reject中返回EAP屬性。
RADIUS服務器假如對收到的EAP報文不理解，就返回一個Access-Reject報文。

NAS把從認證對等端接收到的EAP報文放在一個或多個EAP-Message屬性中，放在Access-Request 報文中，轉發給RADIUS服務器。假如Access-Request或Access-Challenge報文中包含多個EAP-Messages屬性，那么它們必須按連續順序排好放在Access-Request或Access-Challenge報文中。 Access-Accept和Access-Reject報文中應該只有一個EAP-Message屬性，此屬性中包含EAP-Success或EAP-Failure。

希望用EAP實現多種認證方法，包括強壯的加密技術。為了預防攻擊者通過攻擊RADIUS/EAP破壞EAP（例如，通過 修改EAP-Success或EAP-Failure報文），RADIUS/EAP有必要提供身份保護，至少象EAP方法本身那樣強壯。

因此，必須 用Message-Authenticator屬性保護所有攜帶EAP-Message屬性的Access-Request, Access-Challenge, Access-Accept, 和Access-Reject 報文。

對于帶有EAP-Message屬性的Access-Request報文，假如報文中沒有Message-Authenticator屬性，RADIUS服務器就應該丟棄此報文。支持EAP-Message的RADIUS服務器必須計算Message-Authenticator的正確值，假如正確值與發送的值不匹配，RADIUS服務器就丟棄報文。假如RADIUS服務器不支持EAP-Message，當它收到一個含有EAP-Message屬性的Access-Request報文時，必須返回一個Access-Reject報文。假如RADIUS服務器收到一個它不能理解的EAP-Message屬性，也必須返回一個Access-Reject。

對于攜帶有EAP-Message屬性的Access-Challenge, Access-Accept 或 Access-Reject 報文，若報文中不含有Message-Authenticator屬性，NAS應該丟棄此報文。假如NAS支持EAP-Message屬性，它必須計算正確的Message-Authenticator屬性值，假如計算的值與接收到的值不匹配，NAS就丟棄此報文。

EAP-Message屬性格式如下所述，從左至右傳輸各域。

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

79 for EAP-Message.

Length

>= 3

String

String域包含EAP報文，EAP報文在RFC2284定義。假如報文中含有多個EAP-Message屬性，這幾個屬性應該連成一串，因此答應長度大于253個字節的EAP報文放在RADIUS中傳輸。

Message-Authenticator

描述

本屬性可用來對Access-Requests報文簽名，防止利用CHAP, ARAP 或 EAP認證方法欺騙ccess-Requests。此屬性可以用在任何Access-Request報文中，必須用在任何帶有EAP-Message屬性的Access-Request, Access-Accept, Access-Reject 或 Access-Challenge報文中。

假如RADIUS服務器中接收到的Access-Request報文中含有Message-Authenticator屬性，那么服務器必須計算正確的Message-Authenticator值，假如計算的結果與發送過來的值不同，就丟棄此報文。

假如RADIUS客戶端接收到的Access-Accept, Access-Reject或Access-Challenge報文中含有Message-Authenticator屬性，那么客戶端必須計算正確的Message-Authenticator值，假如計算的結果與發送過來的值不同，就丟棄此報文。

此備忘錄的早期草案將此屬性稱為"Signature"，但是Message-Authenticator更準確。具體操作沒有改變，只是名字改變而已。

Message-Authenticator屬性格式如下所述，從左至右傳輸各域。


0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

80 for Message-Authenticator

Length

18

String

假如出現在Access-Request報文中，Message-Authenticator是整個Access-Request報文的HMAC-md5校驗和，包括Type, ID, Length 和 authenticator，計算校驗和時利用共享密鑰作為密鑰，過程如下：

Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)

計算校驗和時，簽名字符串應該被看作16個為0的字節。

對于Access-Challenge, Access-Accept 和 Access-Reject報文，利用Request-Authenticator計算essage-Authenticator如下：

Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)

計算校驗和時，簽名字符串應該被看作16個為0的字節，共享密鑰作為HMAC-MD5 hash的密鑰。在計算Response Authenticator正確計算并且插入到報文中。

當報文中有User-Password屬性時，此屬性就不需要了，但在其它認證類型中，可以防止攻擊。此屬性是為了阻止攻擊者啟動“欺騙”NAS，實施針對RADIUS服務器的在線字典攻擊。此屬性不能提供對離線攻擊的預防，如攻擊者截獲包括CHAP 挑戰和響應的報文，然后實施針對離線報文的字典攻擊。

IP Security 屬性最終會使此屬性沒有必要，因此此屬性只能看作是一個臨時的方法。

ARAP-Challenge-Response

描述

本屬性與ARAP的Framed- Protocol屬性一起出現在Access-Accept報文中，包含對撥號接入用戶挑戰的響應。

ARAP-Challenge-Response屬性格式如下所述，從左至右傳輸各域。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

84 for ARAP-Challenge-Response.

Length

10

Value

Value 域占8個字節，包含對撥號接入用戶挑戰的響應。RADIUS服務器從ARAP-Password屬性的高8字節中取出撥號接入用戶的挑戰，用挑戰用戶的密碼作為密鑰，對取出的高8字節進行DES加密。假如用戶密碼長度小于8個字節，在作為密鑰以前，在用戶密碼后補NULL，直到長度達到8個字節。

Acct-Interim-Interval

描述

本屬性描述了對于某個確定的會話，中間更新流量信息的時間間隔（以秒為單位）。本屬性只能出現在Access-Accept報文中。

Acct-Interim-Interval屬性格式如下所述，從左至右傳輸各域。


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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

85 for Acct-Interim-Interval.

Length

6

Value

Value域包含NAS發送中間更新信息的時間間隔（以秒為單位），其值必須不能小于60，建議此屬性值不要小于600，在實際中應認真考慮此間隔對網絡流量的影響。

NAS-Port-Id

描述

本屬性包含一個識別正在認證用戶的NAS的端口的文本串。此屬性只能用在Access-Request 和 Accounting-Request 報文中。需要注重的是此處的端口是NAS物理連接意義上的端口，而不是TCP或UDP的端口號。

假如NAS在它的端口范圍內區分，那么在Access-Request報文中應該攜帶NAS-Port或 NAS-Port-Id 。NAS-Port-Id目的是給不能方便地給端口編號的NAS使用。

NAS-Port-Id屬性格式如下所述，從左至右傳輸各域。


0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

87 for NAS-Port-Id.

Length

>= 3

Text

Text 域包含以UTF-8格式編碼的10646字符命名的端口名字。

Framed-Pool

描述

本屬性包含了用于給用戶分配地址的地址池名字。假如NAS不支持多個地址池，應該忽略此屬性。地址池一般用于IP地址，但是假如NAS支持其它協議，地址池也可以用于其他協議。

Framed-Pool屬性格式如下所述，從左至右傳輸各域。


0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Length String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

88 for Framed-Pool

Length

>= 3

String

String 域包含了NAS上配置的地址池名字。

屬性表

下表可以作為關于在什么報文里可能攜帶什么屬性的應用指南。Acct-Input-Gigawords, Acct-Output-Gigawords, Event-Timestamp 和NAS-Port-Id 可能在Accounting-Request報文里出現0次或1次。本文檔中增加的其它屬性一定不能出現在Accounting-Request內。

Request Accept Reject Challenge # Attribute
0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access
0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 74 ARAP-Security-Data
0 0 0-1 0 75 Password-Retry
0 0 0 0-1 76 Prompt
0-1 0 0 0 77 Connect-Info
0 0+ 0 0 78 Configuration-Token
0+ 0+ 0+ 0+ 79 EAP-Message [Note 1]
0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1]
0 0-1 0 0-1 84 ARAP-Challenge-Response
0 0-1 0 0 85 Acct-Interim-Interval
0-1 0 0 0 87 NAS-Port-Id
0 0-1 0 0 88 Framed-Pool
Request Accept Reject Challenge # Attribute

[注解 1] 假如Access-Request 報文中包含User-Password，或者CHAP-Password 或者ARAP-Password 或者一個或多個EAP-Message屬性，那么報文中包含的上述四種屬性類型一定不能超過一個。假如報文中不包括上述四種屬性中的任何一個，那么報文中應該包含or one or more EAP-Message Message-Authenticator屬性。假如報文中包含一個EAP-Message屬性，那么報文中必須包含Message-Authenticator屬性。

下表定義了上表中各表項的具體含義。

0 本屬性一定不能出現
0+ 此屬性可能出現0 次或多次。
0-1 此屬性可能出現0 次或一次。
1 此屬性必須出現1 次。

IANA 考慮事項
在RFC2865中"IANA考慮事項"一節中描述的RADIUS命字空間中,IANA注冊了本文檔定義的報文類型Code，屬性類型以及屬性值。同BCP 26 一致。
安全考慮事項
本文檔中除了Message-Authenticator和EAP-Message外沒有額外的安全考慮超出在RFC2865 中已經標識的。
Message-Authenticator安全
帶User-Password的Access-Request報文在發送Access-Request的用戶和NAS間建立了身份，因為在NAS和RADIUS服務器之間 使用了共享密鑰。帶CHAP-Password 或EAP-Message的Access-Request報文沒有User-Password屬性，因此在沒有User-Password的Access-Request報文中應該使用Message-Authenticator屬性，以便連接發送請求的NAS的身份。

EAP安全
因為EAP的目的是為PPP認證提供增強的安全性，因此RADIUS安全地支持EAP是至關重要的。非凡地，必須解決下面的問題：

EAP服務器和PPP認證者分離
連接劫持
中間的攻擊
多數據庫
協商攻擊

EAP服務器和PPP認證者分離
EAP端點相互認證，協商加密組，為隨后PPP加密取得一個會話密鑰是可能的。
因為對端和EAP客戶在同一臺機器上，這不是一個問題。所需要的就是EAP客戶模塊向PPP加密模塊傳遞一個會話密鑰。
當EAP和RADIUS一起使用時，情況就比較復雜了，因為一般PPP認證者和EAP服務器不在同一臺機器上。例如，EAP服務器可能是一臺后端安全服務器，或者RADIUS服務器上的一個模塊。
在EAP服務器和PPP認證者在不同的機器上的情況下，關于安全有如下幾方面的含義。首先，交互認證將在對端和EAP服務器上發生，而不是在對端和認證者之間。這意味著對端不可能證實它連接的NAS或隧道服務器的身份。
如前所述，當EAP/RADIUS被用來封裝EAP報文時，從NAS或隧道服務器發往RADIUS服務器的EAP/RADIUS Access-Request中需要Message-Authenticator屬性。因為Message-Authenticator屬性包含一個HMAC-MD5 hash項，使得RADIUS服務器有可能驗證Access-Request的完整性和NAS或隧道服務器的身份。類似地，從RADIUS服務器發往NAS的Access-Challenge報文也被驗證并由HMAC-MD5 hash項保護完整性，使得NAS或隧道服務器可以判定報文的完整性并且驗證RADIUS服務器的身份。 此外，通過包含其它完整性保護方法來發送的EAP報文不能被欺詐的NAS或隧道服務器成功地修改。
EAP服務器和PPP認證者在不同的機器上引來的第二個問題是，對端和EAP服務器協商的會話密鑰需要傳送到認證者。因此必須提供從EAP服務器到要使用密鑰的認證者或隧道服務器的傳送會話密鑰的一個機制。這個傳送機制的規范超出了本文檔的范圍。

連接劫持
在這種攻擊方式中，攻擊者試圖在NAS和RADIUS服務器之間或RADIUS服務器和后端安全服務器之間的會話中注入一些報文。同RFC2865中描述的那樣，RADIUS不支持加密，只有Access-Reply和Access-Challenge報文受完整性保護。此外，在RFC2865中描述的完整性保護機制比一些EAP方法使用的弱，使得攻擊EAP/RADIUS有可能擾亂那些方法。
如前所述，為了給EAP互換的所有報文提供驗證，所有EAP/RADIUS報文必須使用Message-Authenticator屬性來驗證。

中間的攻擊
因為RADIUS安全基于共享密鑰，在認證或計費報文通過一個代理鏈轉發的情況下不能提供端到端的安全。結果，獲得一個RADIUS代理控制權的攻擊者將能夠修改傳送中的EAP報文。

多數據庫
在許多情況下，為了提供EAP服務，后端安全服務器和RADIUS服務器一塊使用。除非后端安全服務器也實現RADIUS服務器的功能，否則要用兩個分離的用戶數據庫，每一個數據庫內包含有關用戶安全需求的信息。這意味著安全的降低，因為只要成功攻擊數據庫中的任何一個或攻擊它們的后端數據庫都可能損害安全性。當使用多個用戶數據庫時，假如要增加一個用戶，就必須進行多個操作，這就增加了出錯的概率。當用戶信息也放在LDAP上時，危害性又被進一步放大，因為此時必須在三個地方存放用戶信息。

為了解決這些威脅，建議合并數據庫。這可以通過以下途徑來解決： RADIUS服務器和后端安全服務器在同一個后端服務器上存儲信息；后端服務器提供一個完全的RADIUS實現；或將后端安全服務器和RADIUS服務器合并到同一個機器上。

協商攻擊
在協商攻擊中，欺騙的NAS、隧道服務器、RADIUS代理或RADIUS服務器使認證對等端選擇一個安全小的方法，這樣欺騙者可以比較輕易地得到用戶密碼。例如，一個會話本來在通常用EAP認證，被協商攻擊后，可能用CHAP或PAP認證；一個會話本來用一種EAP類型認證，被協商攻擊后，可能使用一種安全系數小的EAP類型認證，如MD5。以前認為很遙遠的欺騙設備威脅，已經給電話公司交換系統造成了危害。

要使系統不受協商攻擊，需要消除向下協商。這可以通過以下方式實現：對認證對等端而言，使用每一個連接策略，對RADIUS服務器而言，使用每一個用戶策略。
對于認證對等端而言，認證策略應該建立在每一個連接的基礎之上。每一個連接策略答應呼叫一種服務時認證對等端來協商EAP，而呼叫另一種服務時協商CHAP，即使兩種服務通過同一個電話號碼就可以訪問。

對于每一個連接策略，只有當期望支持EAP時，認證對等端才會試圖協商EAP。因此假定假如認證對等端選擇EAP，那么就認為認證對等端需要哪個等級的安全。假如不能提供，那么極有可能是配置錯誤，甚至認證對等端連接到了錯誤的服務器上。萬一NAS不能協商EAP，或NAS發送的EAP-Request與期望的不同，認證對等端必須端開連接。期望協商EAP的認證對等端一定不能協商CHAP或PAP。

對于NAS而言，在它知道用戶的身份之前，它可能無法確定一個用戶是否需要EAP認證。例如，共用NAS，可能對一個專賣者實現EAP，對另外一個則不實現。在這些情況下，假如NAS的每一個用戶必須用EAP，那么NAS必須試圖為每一個呼叫協商EAP，這樣可以避免能夠EAP認證的客戶端因用多種認證而削弱安全性。

假如協商了CHAP，NAS將把User-Name 和CHAP-Password 屬性放在Access-Request報文中傳給RADIUS服務器。假如沒有要求用戶用EAP認證，那么RADIUS服務器可以用Access-Accept或Access-Reject報文響應，這要看用哪一個報文回應更合適。但是，假如已經協商過了CHAP而需要EAP，那么RADIUS服務器必須回一個Access-Reject報文，而不能回應Access-Challenge/EAP-Message/EAP-Request報文。認證對等端必須拒絕重新協商認證，即使是從CHAP協商到EAP。

假如已經協商過了EAP，但RADIUS代理或服務器不支持，那么服務器或代理必須用Access-Reject報文響應。在這些情況下，NAS必須發送一個LCP-Terminate并且切斷用戶。這是正確的行為，因為認證對等端期望協商EAP，但期望不能被滿足。對于支持EAP的認證對等端，假如最初已經協商了EAP，那么解決重新協商認證協議。需要注重的是因RADIUS代理服務器不支持EAP而出現的問題是很難診斷的。因為從一個地方撥號接入的用戶（代理支持EAP）或許能夠用EAP成功認證，而同一個用戶從另一個地方撥號進入時（代理不支持EAP），或許始終被切斷。

8. References

[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC2865, June
2000.

[2] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.

[3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC2284, March 1998.

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March, 1997.

[5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.

[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2868, June 2000.

[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC2867, June 2000.

[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.






Rigney, et al. Informational [Page 43]

RFC2869 RADIUS Extensions June 2000


[9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC2104, February 1997.

[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.

[11] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995.

9. Acknowledgements

RADIUS and RADIUS Accounting were originally developed by Livingston
Enterprises (now part of Lucent Technologies) for their PortMaster
series of Network Access Servers.

The section on ARAP is adopted with permission from "Using RADIUS to
Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
Technologies (ward@cyno.com).

The section on Acct-Interim-Interval is adopted with permission from
an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark
Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.

The section on EAP is adopted with permission from an earlier work in
progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit
Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson
and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of
Microsoft for useful discussions of this problem space.

10. Chair's Address

The RADIUS working group can be contacted via the current chair:

Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588

Phone: +1 925 737 2100
EMail: cdr@telemancy.com











Rigney, et al. Informational [Page 44]

RFC2869 RADIUS Extensions June 2000


11. Authors' Addresses

Questions about this memo can also be directed to:

Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588

EMail: cdr@telemancy.com

Questions on ARAP and RADIUS may be directed to:

Ward Willats
Cyno Technologies
1082 Glen Echo Ave
San Jose, CA 95125

Phone: +1 408 297 7766
EMail: ward@cyno.com































Rigney, et al. Informational [Page 45]

RFC2869 RADIUS Extensions June 2000


Questions on EAP and RADIUS may be directed to any of the following:

Pat R. Calhoun
Network and Security Research Center
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025

Phone: +1 650 786 7733
EMail: pcalhoun@eng.sun.com


Allan C. Rubens
Tut Systems, Inc.
220 E. Huron, Suite 260
Ann Arbor, MI 48104

Phone: +1 734 995 1697
EMail: arubens@tutsys.com


Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 936 6605
EMail: bernarda@microsoft.com























Rigney, et al. Informational [Page 46]

RFC2869 RADIUS Extensions June 2000


12. Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise eXPlain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.