Chinaunix首页 | 论坛 | 博客
  • 博客访问: 18701139
  • 博文数量: 7460
  • 博客积分: 10434
  • 博客等级: 上将
  • 技术积分: 78178
  • 用 户 组: 普通用户
  • 注册时间: 2008-03-02 22:54
文章分类

全部博文(7460)

文章存档

2011年(1)

2009年(669)

2008年(6790)

分类: 系统运维

2008-03-24 20:40:03

摘要

该文档描述的是一些超出2138、2139范围的在当前的一些NAS产品中的具体实现。
这样做的目的是给出一些范例,说明处理和标准化这些类型的ad-hoc函数(ad-hocfunction)
的必要性。因为这些特性需要一个匹配的服务器支持,因而配置个NAS和AAA服务器产品的
相互操作的能力被严重的阻碍了。

记载在这儿的实践列举了在将来开发NAS时实现AAA所期望的一些功能。

1、简介
RADIUS工作组成立于1995年,专门文档化一些同名的, 并被特许在一定的范围之内
支持拨号拨号接入终端服务器。遗憾的是现实中的NAS不再只是停留在小而简单的状态,而是
以惊人的速度在发展。

该文档列举了一些当前市场上的已经超出了RADIUS功能范围的实现。一些特性彻底的
超出了。这些特性利用RADIUS的结构和格式,但是应用和语意已经超出了文档。

我通过一些手册了解这些功能的细节,并在投标规格书中对这些功能做出一些响应。当它
们变成该领域的配置时,它们就成了实际上的标准。

因为它们是在文档范围之外被实现的,它们是厂商特有的,从而在产品的可互操作方面
引入了困难。

1.1 非保证事项(Disclaimers)

该文档中的数据是从公共数据来源以及厂商的文档收集来的。这些特性的实现以及以后的
变化没有被确认。

该文档是当前已经知道的一些实践的集合。其目的不是想标准化这些实践或者是使得该文档
通用。如果文档中给出了一些细节的信息,请注意那不是该文档的目的。该文档的目的不是
想将提到的一些功能描述成完全的功能规范。

作者没有转录版权材料,也不清楚这些实现是否有知识产权的限制。

任何分配的数据或者是功能操作如果被厂商修改了,请恕不通知。如果有直接从实现者那里
获得的资料,特别是第一手资料,我将感激不尽。

1.2 表示方法

由于这些材料专门组织,信息按照一种简单的分类方法。

-AttributeUsage

-AttributeDataTypes

-MessageCodes

-NewOperations

2. 属性用法(AttributeUsage)

RADIUS的定义了给出了属性类型的范围,以及一些属性的定义。

-定义了大约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(VendorspecificEnumerations)。
这种方法就是将用于填充某个属性的值的空间分割一部分出来,将厂商的ID以数字值
的形式填入(alaVSAs)。该技术没有被工作组以及其它厂商采用,但是,厂商没有
达到额外工作组或者是其它厂商值不冲突的目的。

VSE值的字典示例如下:

VALUEService-TypeVSE-Authorize-Only0x06300001
VALUEAcct-Status-TypeVSE-User-Reject0x06300001
VALUEAcct-Status-TypeVSE-Call-Reject0x06300002
VALUEAcct-Status-TypeVSE-IPCP-Start0x06300003
VALUEAcct-Status-TypeVSE-CP-Start0x06300004
VALUEAcct-Status-TypeVSE-A-Start0x06300005
VALUEAcct-Status-TypeVSE-Accounting-Restart0x06300006
VALUEAcct-Status-TypeVSE-Accounting-Shutoff0x06300007
VALUEAcct-Status-TypeVSE-Tunnel-Start0x06300008
VALUEAcct-Status-TypeVSE-Tunnel-Stop0x06300009
VALUEAcct-Status-TypeVSE-Tunnel-Reject0x0630000a
VALUEAcct-Status-TypeVSE-Tunnel-Link-Start0x0630000b
VALUEAcct-Status-TypeVSE-Tunnel-Link-Stop0x0630000c
VALUEAcct-Status-TypeVSE-MP-Start0x0630000d
VALUEAcct-Status-TypeVSE-MP-Stop0x0630000e
VALUEAcct-Status-TypeVSE-Line-Seizure0x0630000f
VALUEAcct-Status-TypeVSE-Rlogin-Start0x06300010
VALUEAcct-Status-TypeVSE-Rlogin-Stop0x06300011

2.3. 厂商特有的属性(VSA)的用法

由于在RADIUS工作组的开发中,26号属性--VendorSpecificAttributes(VSAs)
--直到后来才出现,有些服务器到后来才支持该属性。现在,一些前沿的关于客户端的
实现也利用VSA做扩展。非常不幸的是VSA的具体实现有不同的格式。这是因为建议的
格式支持的属性不能多于256个。

2.3.1 VSA在一些客户端中的应用

写该文档是,参考过下面的内容:

-Microsoft:severalforMS-CHAPauthenticationsupport[9]

-ACC:42[10]

-Nortel(Bay):about60VSAsand16VSEs

-Nortel(Aptis):about60VSA:201-byte,~1304-byteheader.
由于它有大量的属性,Aptis的VSA已经从通常的格式变为头长度为4-byte的格式。

-3Com(USR):about130
USR的VSA格式不同于2138所推荐的格式。它的Type域有4个字节长度,并且
内部没有长度域。

有部分厂商开始没有使用VSA,后来则变成将VSA用为一个可配置的选项。

2.3.2 支持多个厂商属性的客户端

如今MS-CHAP的RADIUS属性已经在2548中作为MicrosoftVSA属性被出版, 这使得支持
MS-CHAP认证的NAS客户端在处理不同的厂商的VSA类型时,它会成为典型的应用。这提示服务器
可以根据厂商的NAS客户端过滤或者是裁减一些属性。

一个NAS客户端可以接收最多3种不同的VSA属性集,但是只会根据操作员配置的模式发送特定的属性,
这使得它能适合于那些客户是需要依赖于一组特定的RADIUS属性的的环境,这也允许NAS能随意
访问而不必改变服务器的属性(allowstheNASto"drop-in"withoutserverattribute
changes)。

现在还有另外一种NAS,能同时支持3种厂商属性。更准确的说,就是给服务器响应时,它使用不同
厂商的VSA属性的组合。这样做为了支持那些竞争厂商的扩张属性的超集,也是为了支持给NAS的
同类产品的扩展属性。

3. 属性数据类型

只定义了4种基本的数据类型

-integer,32bitunsigned

-string,1-253bytes,counted.

-ipaddr,32bit

-date,32bitUnixformat.

以后又添加了一些其它数据类型:

在关于隧道认证的文档[6]中隧道属性中增加了一个可选的组合字段-“tag"。
这是一个预先被添加到数据域中的单字节,用于支持返回的属性集合。该字节
的取值范围必需是0x01-0x3F,或者被考虑成数据域中的数据〔译者注:不再
将它看成一个"tag"字段〕。

请注意没有关于的支持。实际上在一些固定的消息组件中也没有关于的支持。

在服务器里又构造了一些新的属性类型。为了包过滤,构造了一种叫做"abinary"
的格式。用户在profile中输入一串ASCII字符串格式的过滤描述。在将它传到NAS
端前,服务器将它解析成二进制串。这有利于将来服务器端解析的复杂度。另外,
还有一种"phonestring"的服务器数据类型允许在程序的入口处做额外的数据类型
检查。

4. 新近的消息

一系列新的消息已经被逐步引入。原来基本的规范是6个,厂商增加了26个。

这些消息分成了几类,我们在下面描述。其中的一些消息,用类似于RADIUS的,
用于RADIUS服务器和其它资源服务器之间,实现一些新的功能。

6AccountingStatus
(nowInterimAccounting[5])
7PasswordRequest
8PasswordAck
9PasswordReject
10AccountingMessage

21ResourceFreeRequest
22ResourceFreeResponse
23ResourceQueryRequest
24ResourceQueryResponse
25AlternateResourceReclaimRequest
26NASRebootRequest
27NASRebootResponse

29NextPasscode
30NewPin
31TerminateSession
32PasswordExpired
33EventRequest
34EventResponse
40DisconnectRequest
41DisconnectAck
42DisconnectNak
43ChangeFiltersRequest
44ChangeFiltersAck
45ChangeFiltersNak
50IPAddressAllocate
51IPAddressRelease

5. 附加的功能

有一些操作,是通过RADIUS的扩展以及其它的消息类型来实现的。

5.1 修改密码

有关于远程修改密码的描述和建议,但是该工作组没有采用。但是,这个
特性在一些产品中还是被开发出来了。

消息类型;
-PasswordRequest
-PasswordAckorReject

5.2 认证模式

增加了一些消息类型用于协商智能卡服务器之间的密码修改(passcodechanges)。
-NextPasscode
-NewPIN
-PasswordExpired
这允许NAS和RADIUS服务器能通过其它的一台安全服务器协商修改密码。

5.3 菜单

至少有两家厂商开发了用于拨号终端的、通过菜单相互操作的系统。

一种实现使用Reply-Message作为要显示的菜单文本,用State属性来跟踪菜单内的位置。
通过Access-Challenge消息来显示菜单。象通常处理challenge一样,将响应在编码在
User-Password域内。

按照这种方式使用,一些RADIUS客户端会出问题,因为它们不能处理返回的太长的或者是
多个Reply-Message。一个Echo属性应该通过菜单的响应来控制响应行为。用State属性
来明了Challenge序列也是一种标准行为。

另一种实现是用两个厂商定义的属性(VSA-Menu-Item,VSA-Menu-Selector)来传递
这些信息。这种实现是厂商特有的。

5.4 虚拟用户

一种客户端将RADIUS服务器的能力优势,将它用做一台远端的数据库服务器。通过用一些
周知的、特定的用户名和密码,NAS可以从服务器获取一些特定的信息:静态IP路由、静态
路由、或者是如期等。

这叫做虚拟用户,因为它们是使用一个构造的用户名,获取非认证的其它信息。

另一种客户端也使用虚拟客户技术来解决未知的Filter-ID的值。将一个Access-Request
报文----将Filter-ID设为用户名,用周知的密码,设置Service-Type为VSE-Authorization-Only
---发送到RADIUS服务器。响应报文中Service-Type值必需相同,否则会被丢弃。
响应报文中必需包含IP-Filter属性(该属性是一个VSA属性),该属性定义了过滤法。

必需注意的如果没有将一个特定的或者是可操作的有效的Service-Type绑定到虚拟用户的profile,
则虚拟用户的profile会有安全问题。客户端必需测试这个返回值,以防止普通的拨号用户
通过这个profile接入。

6. 资源

为了提供服务,认证会话可能还需要分配其它的动态资源。最典型的就是IP地址。这种
分配可以在一个独立于RADIUS服务器的层次上被延迟,直到有需要或者类似的需求为止。
可能使用其它的一些消息去分配或者释放这些资源。RADIUS服务器可以代理将这个需求
转发给其它的服务器。

示例:一些服务器能分配本地的地址给NAS或者是使用外部的地址服务器。另外一些服务
器有本地的地址池,通过选择分配一个地址,填入Framed-IP-Address属性。

6.1 被的资源

被的资源包括:IP地址,并行登陆,拨号端口分配策略,隧道限定和均衡负载
(loaddistribution)。

有几种不同的实现技术:

-Explicitrequest/freeresourcerequests
-Monitorusagewithdeamonswatchingthestate
-Explicitmessagestoastatedeamon
-MonitorAccountingmessagesforstatechanges

6.2 资源消息

用于资源的消息:

-IPAddressAllocate
-IPAddressRelease

-ResourceRequest
-ResourceResponse
-ResourceFreeRequest
-ResourceFreeResponse
-ResourceReclaimRequest
-NASRebootRequest/Response

这些消息用于为NAS从一个集中的服务器分配/释放资源。这些方案允许业务提供者
(serviceprovider)能有比那些自动的LAN业务(它们是没有输入策略或者的)
有着更好的。

6.3 并行登陆(ConcurrentLogin)

遵照RADIUS的服务器是没有状态的。这就是说,服务器不知道每个会话的状态。
但是,对于很多服务提供商来说,它们有必要跟踪一个用户打开了多少个会话,这样
可以禁止一些非法接入。


在RADIUS环境中有几种不同的技术可以实现限制接入数。一些厂商已经开发出一些
工具,这些工具能利用或者是其它的方法检查会话的状态。

而另一些厂商则是通过分离接入或者是记账请求中的状态信息来监视RADIUS的接入和
记账消息。这些监视没有直接查询NAS可靠,但是它较少的依赖于特定的厂商。倘若它
发送所有的流到同一个服务器,那它能与任何RADIUSNAS工作。

目前使用的几种方法:

-commands
-Telnetmonitordeamon
-Accountingmonitor

6.4 授权修改

如果需要实现动态修改一个在线的会话,例如修改过滤器(filter)或者是超时切断,
那么厂商至少还需要一个类似于RADIUS的服务器,该服务器接收网络上的应用程序
发出的消息,匹配会话,然后执行相应的动作。

从服务器发给NAS的消息:
-ChangeFilterRequest
-ChangeFilterAck/Nak
-DisconnectRequest
-DisconnectResponse

过滤器通过限制用户发送报文的系统和来限制用户的接入。通过在一个授权服务器
上完成一些注册,业务提供者可以移去这些限制,或者是掐断一个用户。

7. 策略服务

一些厂商通过把RADIUS作为控制,实现了策略服务器。 两个明显的策略者作为
一个RADIUS代理过滤器,使用RADIUS消息,拒绝那些超出了当前策略限制的接入。

一种实现实现就象一个RADIUS代理服务器,但是通过一个策略进程下一步的决定。最
典型的就是当一个呼叫到达时,NAS在发出认证消息前发出一个其它的消息(例如想在最新
的草案中的Service-Type=CallCheck)。该消息只在用户名域包含呼叫号的信息。服
务器收到这个Access-Request消息后,通过它所知道的网络状态和预备的策略处理该报文。

接收这个呼叫后,一个Access-Accept报文被返回给系统,同时还包含一些动态的策略信息
以及特定的虚拟POP缺省参数(VirtualPOPspecificdefaultparameters)。当一
个真正的ppp认证消息到达后,代理将该报文转发给RADIUS服务器。这个过程可以看做是
一个认证预处理过程。它也可以处理没有这种预处理的接入请求,而用用户名域获得它想要
获得的用于策略评估的信息。

其它的实现也有类似的操作。不同的是他不是用预认证消息,而是在Access-Request中使用
VSA。

8. 记账扩展

通常记账只记录会话的开始和结束,这个感觉挺烦的。当相关操作发生时,为了给出一个更好的
描述而额外上报一些其它的信息是很容易的事。

8.1 审核/行为(Auditing/Activity)

-CallorModemStarts,Stops
-TunnelStarts,Stops
-TunnelLinkStarts&Stops
-Adminchanges

如果一个状态服务器监视上面这些事件,那它可以被用于收集一个用户/会话的网络使用信息。
与向后跟踪IP地址流相比,一个特定用户进入网络的信息与网络业务更相关。通过一定
范围内的NAS收集的关于使用端口的有效信息能使得业务提供者能很快的发现有问题的区域
或者是用户。

同样,对于业务提供者来说,关于用户呼叫的成功、失败、质量的信息同样很重要。

扩展RADIUS记账很容易,但奇怪的是很多实现都没有关于这个方面的内容。

9. 结论

实际中,RADIUS服务器的软件实现变得相当复杂。他们经常作为一个中间人将认证或授权
信息转到其它的授权处或者是某个中心。为了实现这种解决方案,通常将不同的RADIUS
组合在一起使用。

一些解决方案能被一些潜在的更好的业务替代。

对实现者来说,这意味者RADIUS与的描述变得更不相关了。很多增加的特性需要
匹配客户端和服务器关于消息的处理。如果没有标准,我们在该领域不能协同工作,
则更多的精力花费在相互作用上。

无论如何,该文档不是一个完全的调查。它只是我写这篇文档时所知道的一些典型
应用摘要。感谢那些提供关于一些实践和细节的材料的用户和厂商。如果你有什么参
考材料能提供的话,我也感激不尽。

10. 安全考虑



11. 实现文档

下面的材料可以从各自的所有者获得。很多列表在制造厂商的站点上就能找到。

11.1 客户端

-3Com(USR)TotalControlHub
-Ericsson(ACC)Tigris
draft-ilgun-radius-accvsa-01.txt,Dec1998
-Lucent(Ascend)MAXTNT
-Lucent(Livingston)Portmaster
-Nortel(Aptis)CVX1800
-Nortel(BayNetworks)Versalar5399/8000RemoteAccessController
-Intel(Shiva)

11.2 服务器

-Ericsson(ACC)VirtualPortServerManager
-FunkSteel-BeltedRADIUS
-Intel(Shiva)AccessManager
-Lucent(Ascend)AccessControl
-Lucent(Ascend)NavisAccess
-Lucent(Ascend)ModifiedLivingston1.16
-Lucent(Livingston)V2.01
-Lucent(Livingston)ABM
-LucentPortAuthority
-MERITAAAServers
-Nortel(BayNetworks)BaySecureAccessControl
-NortelPresideRadius
-NortelCVXPolicyManager

12 参考材料

[1]Rigney,C.,Rubens,A.,Simpson,W.andS.Willens,"Remote
AuthenticationDialInUserService(RADIUS)",2138,April
1997.

[2]Rigney,C.,"RADIUSAccounting",2139,April1997.

[3]Rigney,C.,Willens,S.,Ruebens,A.andW.Simpson,"Remote
AuthenticationDialInUserService(RADIUS)",2865,June
2000.

[4]Rigney,C.,"RADIUSAccounting",2866,June2000.

[5]Rigney,C.,Willats,W.andP.Calhoun,"RADIUSExtensions",
2869,June2000.

[6]Zorn,G.,Leifer,D.,Rubens,A.,Shriver,J.,Holdrege,M.and
I.Goyret,"RADIUSAttributesforTunnelProtocolSupport",
2868,June2000.

[7]Zorn,G.,Aboba,B.andD.Mitton,"RADIUSAccounting
ModificationsforTunnelProtocolSupport",2867,June2000.

[8]Aboba,B.andG.Zorn,"ImplementationofL2TPCompulsory
TunnelingviaRADIUS",2809,April2000.

[9]Zorn,G.,"MicrosoftVendor-specificRADIUSAttributes",
2548,March1999.

[10]Ilgun,K.,"RADIUSVendorSpecificAttributesforACC/Ericsson
DatacomAccess",WorkinProgress.

13.Author'sAddress

DavidMitton
NortelNetworks
880TechnologyParkDrive
Billerica,MA01821

Phone:978-288-4570
EMail:dmitton@nortelnetworks.com

14.FullCopyrightStatement

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

阅读(1215) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~