?? rfc2882.txt
字號:
Network Working Group D. Mitton
Request for Comments: 2882 Nortel Networks
Category: Informational July 2000
網絡接入服務器(NAS)需求:擴展RADIUS實踐
(RFC2882-Network Access Servers Requirements:
Extended RADIUS Practices)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
摘要
該文檔描述的是一些超出RFC2138、2139范圍的在當前的一些NAS產品中的具體實現。
這樣做的目的是給出一些范例,說明處理和標準化這些類型的 ad-hoc函數(ad-hoc function)
的必要性。因為這些特性需要一個匹配的服務器支持,因而配置個管理NAS和AAA服務器產品的
相互操作的能力被嚴重的阻礙了。
記載在這兒的實踐列舉了在將來開發NAS時實現AAA所期望的一些功能。
1、 簡介
RADIUS工作組成立于1995年,專門文檔化一些同名的協議, 并被特許在一定的范圍之內
支持撥號撥號接入終端服務器。遺憾的是現實中的NAS不再只是停留在小而簡單的狀態,而是
以驚人的速度在發展。
該文檔列舉了一些當前市場上的已經超出了RADIUS協議功能范圍的實現。一些特性徹底的
超出了協議。這些特性利用RADIUS協議的結構和格式,但是應用和語意已經超出了RFC文檔。
我通過一些手冊了解這些功能的細節,并在投標規格書中對這些功能做出一些響應。當它
們變成該領域的配置時,它們就成了實際上的標準。
因為它們是在RFC文檔范圍之外被實現的,它們是廠商特有的,從而在產品的可互操作方面
引入了困難。
1.1 非保證事項(Disclaimers)
該文檔中的數據是從公共數據來源以及廠商的文檔收集來的。這些特性的實現以及以后的
變化沒有被確認。
該文檔是當前已經知道的一些實踐的集合。其目的不是想標準化這些實踐或者是使得該文檔
通用。如果文檔中給出了一些細節的信息,請注意那不是該文檔的目的。該文檔的目的不是
想將提到的一些功能描述成完全的功能規范。
作者沒有轉錄版權材料,也不清楚這些實現是否有知識產權的限制。
任何分配的數據或者是功能操作如果被廠商修改了,請恕不通知。如果有直接從實現者那里
獲得的資料,特別是第一手資料,我將感激不盡。
1.2 表示方法
由于這些材料專門組織,信息按照一種簡單的分類方法管理。
- Attribute Usage
- Attribute Data Types
- Message Codes
- New Operations
2. 屬性用法(Attribute Usage)
RADIUS 的 RFC 定義了給出了屬性類型的范圍,以及一些屬性的定義。
-定義了大約70個RADIUS屬性
-192-193為試驗使用保留
-224-240為特有的實現使用保留
-241-255保留,不得使用
26號屬性被定義為廠商特有屬性(VSA),它利用更深一層的內在結構,允許
廠商擴展。
2.1 屬性沖突
實際上,屬性92-255被一個廠商使用。而另一個廠商也用了屬性90-104,而且這
兩種用法有沖突。
為了處理這個問題,服務器開發商把特定廠商參數加入到它們的客戶端數據庫文件中。
管理者在指出NAS的IP地址和共享密鑰的同時,還要指出NAS的類型,這樣服務器才
能消除這些屬性用法的歧義。
一種服務器用一個大的廠商文件來將所有的屬性映射到一種保留廠商ID的內部格式。
另外一種服務器則用多個詞典實現,每個詞典對應著一種NAS和廠商定義列表模型。
2.2 屬性值沖突
相對于簡單的特性需求來說,增加額外的屬性可能會變得更麻煩。通常,現有的屬性
能通過另外的值來擴展(特別是那些枚舉選擇的屬性)。但是這樣做,就沒有辦法保證
不會與其它廠商的擴展出現沖突。
2.2.1 關于廠商特有屬性枚舉值的建議
關于該問題的一個推薦的解決方法是VSE(Vendor specific Enumerations)。
這種方法就是將用于填充某個屬性的值的空間分割一部分出來,將廠商的ID以數字值
的形式填入(ala VSAs)。該技術沒有被工作組以及其它廠商采用,但是,廠商沒有
達到額外工作組或者是其它廠商值不沖突的目的。
VSE值的字典示例如下:
VALUE Service-Type VSE-Authorize-Only 0x06300001
VALUE Acct-Status-Type VSE-User-Reject 0x06300001
VALUE Acct-Status-Type VSE-Call-Reject 0x06300002
VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003
VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004
VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005
VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006
VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007
VALUE Acct-Status-Type VSE-Tunnel-Start 0x06300008
VALUE Acct-Status-Type VSE-Tunnel-Stop 0x06300009
VALUE Acct-Status-Type VSE-Tunnel-Reject 0x0630000a
VALUE Acct-Status-Type VSE-Tunnel-Link-Start 0x0630000b
VALUE Acct-Status-Type VSE-Tunnel-Link-Stop 0x0630000c
VALUE Acct-Status-Type VSE-MP-Start 0x0630000d
VALUE Acct-Status-Type VSE-MP-Stop 0x0630000e
VALUE Acct-Status-Type VSE-Line-Seizure 0x0630000f
VALUE Acct-Status-Type VSE-Rlogin-Start 0x06300010
VALUE Acct-Status-Type VSE-Rlogin-Stop 0x06300011
2.3. 廠商特有的屬性(VSA)的用法
由于在RADIUS工作組的開發中,26號屬性--Vendor Specific Attributes(VSAs)
--直到后來才出現,有些服務器到后來才支持該屬性。現在,一些前沿的關于客戶端的
實現也利用VSA做擴展。非常不幸的是VSA的具體實現有不同的格式。這是因為RFC建議的
格式支持的屬性不能多于256個。
2.3.1 VSA在一些客戶端中的應用
寫該文檔是,參考過下面的內容:
- Microsoft: several for MS-CHAP authentication support [9]
- ACC: 42 [10]
- Nortel(Bay): about 60 VSAs and 16 VSEs
- Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header.
由于它有大量的屬性,Aptis的VSA已經從通常的格式變為頭長度為4-byte的格式。
- 3Com (USR): about 130
USR的VSA格式不同于RFC2138所推薦的格式。它的Type域有4個字節長度,并且
內部沒有長度域。
有部分廠商開始沒有使用VSA,后來則變成將VSA用為一個可配置的選項。
2.3.2 支持多個廠商屬性的客戶端
如今MS-CHAP的RADIUS屬性已經在RFC 2548中作為Microsoft VSA屬性被出版, 這使得支持
MS-CHAP認證的NAS客戶端在處理不同的廠商的VSA類型時,它會成為典型的應用。這提示服務器
可以根據廠商的NAS客戶端過濾或者是裁減一些屬性。
一個NAS客戶端可以接收最多3種不同的VSA屬性集,但是只會根據操作員配置的模式發送特定的屬性,
這使得它能適合于那些客戶是需要依賴于一組特定的RADIUS屬性的的環境,這也允許NAS能隨意
訪問而不必改變服務器的屬性(allows the NAS to "drop-in" without server attribute
changes)。
現在還有另外一種NAS,能同時支持3種廠商屬性。更準確的說,就是給服務器響應時,它使用不同
廠商的VSA屬性的組合。這樣做為了支持那些競爭廠商的擴張屬性的超集,也是為了支持給NAS的
同類產品的擴展屬性。
3. 屬性數據類型
RFC只定義了4種基本的數據類型
- integer, 32 bit unsigned
- string, 1-253 bytes, counted.
- ipaddr, 32 bit IPv4
- date, 32 bit Unix format.
以后又添加了一些其它數據類型:
在關于隧道認證的文檔[6]中隧道屬性中增加了一個可選的組合字段-“tag"。
這是一個預先被添加到數據域中的單字節,用于支持返回的屬性集合。該字節
的取值范圍必需是0x01-0x3F,或者被考慮成數據域中的數據〔譯者注:不再
將它看成一個"tag"字段〕。
請注意沒有關于IPv6的支持。實際上在一些固定的消息組件中也沒有關于IPv6的支持。
在服務器里又構造了一些新的屬性類型。為了包過濾,構造了一種叫做"abinary"
的格式。用戶在profile中輸入一串ASCII字符串格式的過濾描述。在將它傳到NAS
端前,服務器將它解析成二進制串。這有利于將來服務器端解析的復雜度。另外,
還有一種"phonestring"的服務器數據類型允許在程序的入口處做額外的數據類型
檢查。
4. 新近的消息
一系列新的消息已經被逐步引入。原來基本的規范是6個,廠商增加了26個。
這些消息分成了幾類,我們在下面描述。其中的一些消息,用類似于RADIUS的協議,
用于RADIUS服務器和其它資源服務器之間,實現一些新的功能。
6 Accounting Status
(now Interim Accounting [5])
7 Password Request
8 Password Ack
9 Password Reject
10 Accounting Message
21 Resource Free Request
22 Resource Free Response
23 Resource Query Request
24 Resource Query Response
25 Alternate Resource Reclaim Request
26 NAS Reboot Request
27 NAS Reboot Response
29 Next Passcode
30 New Pin
31 Terminate Session
32 Password Expired
33 Event Request
34 Event Response
40 Disconnect Request
41 Disconnect Ack
42 Disconnect Nak
43 Change Filters Request
44 Change Filters Ack
45 Change Filters Nak
50 IP Address Allocate
51 IP Address Release
5. 附加的功能
有一些操作,是通過RADIUS的擴展以及其它的消息類型來實現的。
5.1 修改密碼
有關于遠程修改密碼的描述和建議,但是該工作組沒有采用。但是,這個
特性在一些產品中還是被開發出來了。
消息類型;
- Password Request
- Password Ack or Reject
5.2 認證模式
增加了一些消息類型用于協商智能卡服務器之間的密碼修改(passcode changes)。
- Next Passcode
- New PIN
- Password Expired
這允許NAS和RADIUS服務器能通過其它的一臺安全服務器協商修改密碼。
5.3 菜單
至少有兩家廠商開發了用于撥號終端的、通過菜單相互操作的系統。
一種實現使用Reply-Message作為要顯示的菜單文本,用State屬性來跟蹤菜單內的位置。
通過Access-Challenge消息來顯示菜單。象通常處理challenge一樣,將響應在編碼在
User-Password域內。
按照這種方式使用,一些RADIUS客戶端會出問題,因為它們不能處理返回的太長的或者是
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -