RFC2865在用户服务中的远程身份验证拨号RADIUS.docx

上传人:b****6 文档编号:5363856 上传时间:2022-12-15 格式:DOCX 页数:71 大小:62.58KB
下载 相关 举报
RFC2865在用户服务中的远程身份验证拨号RADIUS.docx_第1页
第1页 / 共71页
RFC2865在用户服务中的远程身份验证拨号RADIUS.docx_第2页
第2页 / 共71页
RFC2865在用户服务中的远程身份验证拨号RADIUS.docx_第3页
第3页 / 共71页
RFC2865在用户服务中的远程身份验证拨号RADIUS.docx_第4页
第4页 / 共71页
RFC2865在用户服务中的远程身份验证拨号RADIUS.docx_第5页
第5页 / 共71页
点击查看更多>>
下载资源
资源描述

RFC2865在用户服务中的远程身份验证拨号RADIUS.docx

《RFC2865在用户服务中的远程身份验证拨号RADIUS.docx》由会员分享,可在线阅读,更多相关《RFC2865在用户服务中的远程身份验证拨号RADIUS.docx(71页珍藏版)》请在冰豆网上搜索。

RFC2865在用户服务中的远程身份验证拨号RADIUS.docx

RFC2865在用户服务中的远程身份验证拨号RADIUS

组织:

中国互动出版网(http:

//www.china-

RFC文档中文翻译计划(http:

//www.china-

E-mail:

Emook@china-

(会员名:

oscianoscian@oscian@)

译文发布时间:

2002-6-21

版权:

本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。

 

NetworkWorkingGroupR.Droms

RequestforComments:

2242BucknellUniversity

Category:

StandardsTrackK.Fong

Novell

November1997

 

远程拨入用户认证服务(RADIUS)

(RemoteAuthenticationDialInUserService(RADIUS))

写在翻译文档前的说明

本翻译文档中的所有“字节”都指的是八位二进制数。

本文档用到英文缩略语的中文说明

NAS网络接入服务器

UTC通用协调时间

本备忘录的状态

本文档讲述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建

议以得到改进。

请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。

本备忘录的发布不受任何限制。

版权声明

Copyright(C)TheInternetSociety(2000)。

IESG提示

这个协议被广泛的实现和使用。

试验已经证明在一个大规模的系统中使用时,它会降低性能和丢失数据,部分的原因是它没有提供阻塞控制的协议,这篇文档的阅读者或许会发现跟踪Internet工程任务组AAA工程小组得工程进程师有意义的,因为他们可能开发一种能更好的应用于大范围和阻塞控制情况的后续协议。

摘要

本文档描述了一种在希望对它的连接进行认证的网络接入服务器与共享认证服务器之间传送认证、授权和配置信息的一种协议。

应用提示

这篇备忘录说明的是RADIUS协议。

早期的RADIUS配置是使用UDP端口,端口号是1645,它是与数据量度(datametrics)服务冲突。

RADIUS正式分配的端口号是1812。

目录

写在翻译文档前的说明1

本文档用到英文缩略语的中文说明1

本备忘录的状态1

IESG提示1

摘要1

应用提示2

目录2

内容4

1.介绍4

1.1要求术语的说明5

1.2术语5

2.运行5

2.1盘问/响应6

2.2用不加密验证和加密验证配合动作7

2.3代理7

2.4为什么使用UDP9

2.5中继提示10

2.6保持激活状态应该考虑的损害10

3.包的格式10

编码11

标识符11

长度11

鉴别码12

管理标记12

4.数据包的类型13

4.1接入请求13

4.2接入允许14

4.3接入拒绝15

4.4接入盘问16

5.属性17

5.1用户名20

5.2 用户密码21

5.3 CHAP密码22

5.4网络接口服务器IP地址23

5.5NAS端口24

5.6服务类型24

5.7帧协议26

5.8IP地址配置27

5.9IP网络掩码配置28

5.10路由方法配置28

5.11筛选器编号29

5.12MTU配置30

5.13压缩协议配置31

5.14登录IP主机32

5.15登录服务32

5.16登录TCP端口33

5.17未分配34

5.18回复消息34

5.19回叫号码35

5.20回叫Id36

5.21未分配37

5.22路由配置37

5.23IPX网络配置38

5.24状态38

5.25类别39

5.26供应商特性40

5.27会话超时41

5.28空闲超时42

5.29终止动作43

5.30拨出号码44

5.31呼叫站ID45

5.32NAS标识符45

5.33代理状态46

5.34登录LAT服务47

5.35登录LAT节点48

5.36登录LAT组49

5.37配置AppleTalk连接50

5.38配置AppleTalk网络51

5.39配置AppleTalk区域51

5.40CHAP盘问52

5.41NAS端口类型53

5.42端口限制54

5.43 登录LAT端口55

5.44属性表56

6.IANA考虑57

6.1术语定义57

6.2推荐登记政策58

7.例子58

7.1用户远程登录到特定主机58

7.2用CHAP配置用户认证59

7.3拥有盘问响应插件的用户61

8.安全考虑62

9.更改记录63

10.参考资料64

11.致谢65

12.主席地址65

13.作者地址65

14.版权陈述66

内容

1.介绍

这篇文档废除了RFC2138[1]。

这篇文档对RFC2138的修改可以在“更改记录(ChangLog)”附录中找到。

管理用户大量分散的串行线(serialline)或调制池(modempools)用户会产生一种明显的管理支持需求。

既然调制池(modempools)已被解释为一种到达外部世界的连接,则他们需要在安全、授权和计费方面给予认真的关注,通过管理一个用户数据库,可以把这种关注良好的体现出来,此数据库兼顾了认证(验证用户名和密码)和配置信息细节——交付给用户的服务类型(如:

串行线路接口协议(SLIP),端对端协议(PPP),远程连接的标准协议(Telnet),远程登录(rLogin))。

客户/服务模式(Client/Server)

网络接入服务器(NetworkAccessServer)是作为RADIUS的客户端运作的。

这个客户端负责将用户信息传递给指定的RADIUS服务器,并负责执行返回的响应。

RADIUS服务器负责接收用户的连接请求,鉴别用户,并为客户端返回所有为用户提供服务所必须的配置信息。

一个RADIUS服务器可以为其他的RADIUSServer或其他种类认证服务器担当代理。

网络安全(NetworkSecurity)

客户端和RADIUS服务器之间的事务是通过使用一种从来不会在网上传输的共享机密进行鉴别的。

另外,在客户端和RADIUS服务器之间的任何用户密码都是被加密后传输的,这是为了避免某些人在不安全的网络上监听获取用户密码的可能性。

灵活的认证机制(FlexibleAuthenticationMechanisms)

RADIUS服务器能支持多种认证用户的方法。

当用户提供了用户名和原始密码后,RADIUS服务器可以支持点对点的PAP认证(PPPPAP)、点对点的CHAP认证(PPPCHAP)、UNIX的登录操作(UNIXLogin)、和其他认证机制。

扩展协议(ExtensibleProtocol)

所有事务由变长的属性、长度和值,这样的三元组组成。

新属性的值可以在不中断已存在协议执行的前提下进行添加。

1.1要求术语的说明

本文中的关键字“必须”,“必须不”,“要求的”,“应该”,“不应该”,“会”,“不会”,“建议”,“或许”,“可选的”在这篇文档中的解释是和BCP14[2]中描述的意思是一样。

而且不管它们是否为大写,它们所表述的意思都是一样的。

如果一项操作对它执行的协议不能满足一个或多个必须条件或满足了不可被满足的条件,则此项操作不会被执行。

一项操作对它要执行的协议满足了所有“必须”,“必须不”,“应该”,“不应该”的必要条件,它被称为“无条件服从”;一项操作对它要执行的协议满足了所有“必须”,“必须不”必要条件,但没有完全达到“会”,“不会”条件,则被称为“有条件服从”。

一个不执行给定服务的网络接入服务器(NetworkAccessServer)一定没有具备执行那项服务的RADIUS属性。

例如,一个不能提供AppleTalk远程接入协议(ARAP)服务的NAS服务器一定没有满足执行ARAP服务RADIUS属性。

一个NAS服务器一定会把一项在接入允许数据包中的不可实现的指定服务看作是收到了接入拒绝数据包。

1.2术语

这篇文档将会常用到以下术语:

服务

网络接入服务器对拨号接入的用户提供的一种服务。

例如,点对点传输,远程登录。

会话

每一个由NAS服务器提供的给拨号用户的服务由会话组成,它的起始被定义为服务首

次被提供的那点,会话结束被定义为服务结束的那一点。

在NAS服务器支持的前提下,用户可以有多个并行或串行的会话。

简单丢弃

这意味着执行操作没有做进一步处理的能力,只是将数据包简单的丢弃。

该执行应该提

供记录错误的能力,如丢弃包的内容;并在统计处记录下该事件。

2.运行

在一个客户端被设置使用RADIUS协议后,任何使用这个终端的用户都需要向这个客户端提供认证信息。

此信息或许以一种定制化的提示信息出现,用户需要输入他们的用户名和密码。

或许也可以选择一种配置连接协议,比如像点对点的传输协议(Point-to-PointProtocol),通过认证包来传递这种认证信息。

一旦客户端收到此类信息,它会选择使用RADIUS协议进行认证。

之后,客户端创建一个“接入请求”数据包,此包包含了诸如像用户名、用户密码、客户机ID、用户正在访问的端口编号。

当密码出现时,有一种基于RSA实验室的信息分类算法(MessageDigestAlgorithm)MD5[3]的方法对其加密。

“接入请求”是通过网络提交给RADIUS服务器。

如果在一定长度的时间里,服务器没有返回响应信息,请求会被重复传输许多次。

在主服务器故障或不能连接到的情况下,客户端也可以继续向一个或多个后备服务器发出请求。

后备服务器在多次尝试连接主服务器失败后,或在一轮循环方式结束后被选择连接。

重试和回退算法是当前研究的课题,本文不对它做详细说明。

一旦RADIUS服务器收到请求信息,它会对传输信息的客户端进行验证。

一个来自没有和RADIUS服务器具有共享机密的客户端请求,该数据包会被简单的丢弃。

如果客户端是合法的,RADIUS服务器会查询用户数据库找到这个用户,把查询到的用户名同请求中的进行比较。

数据库中的用户记录包含了一组对用户来说必须满足的用户接入条件,它不只是包含用户的密码验证信息,而且也可以指定允许接入的客户端和端口号。

在为了满足某个请求时,RADIUS服务器也可以作为客户端,向其他服务器传输请求。

如果任何“代理状态(Proxy-State)”属性出现在接入请求数据包中,它们都必须在不做任何更改和保持原顺序的前提下拷贝到响应数据包中。

其他属性可以放到“代理状态(Proxy-State)”属性的前面、后面甚至是中间。

如果有任何条件没有得到满足,RADIUS服务器会发出一个“接入拒绝(Access-Reject)”响应,表示该用户请求是无效的。

如果要求的话,RADIUS服务器可以在接入拒绝响应中包含文本消息,此文本消息可以通过客户端显示给用户。

除了代理状态(Proxy-State)属性外没有任何其他属性允许存在于接入拒绝(Access-Reject)响应中。

如果所有的条件被满足而且服务器会传输一个用户必须响应的盘问,因此RADIUS服务器会传输一个“接入盘问(AccessChallenge)”响应。

它或许会包含一个文本信息,可以在用户端向用户显示的响应提示,并可以包含一种状态属性。

如果客户端收到接入盘问而且支持“盘问/响应(challenge/respond)”,如果有的话,它会向用户显示文本信息,并提示用户做出响应。

然后,客户端再次提交一个包含新请求号的源接入请求,并用加密响应代替用户密码属性,如果有的话,还包括来自接入盘问的状态属性。

状态属性应该仅有0或1两个常数出现在一个请求中。

服务器可以用“接入接受(Access-Accept)”、“接入拒绝(Access-Reject)”或“接入盘问(Access-Challenge)”对这个新接入请求进行响应。

如果所有的条件都被满足,用户的配置值表被置于接入允许响应中。

这些值包含了服务类型(如:

串行线路接口协议(SLIP),点对点传输协议(PPP),登录用户(LoginUser))和交付要求服务的所有必须值。

对串行线路接口协议(SLIP)和点对点传输协议(PPP)来说,这些值也许包括诸如IP地址、子网掩码、最大传输单元(MTU),要求压缩率和指定的包过滤标志。

对字符模式的用户,这些值或许还包括请求的协议和主机。

2.1盘问/响应

在盘问响应认证过程中,用户被给予一个不可预知的数字,并要求对此数字加密后返回结果。

已授权用户装备有特殊的设备,如智能卡或软件,它们能不费力的计算出正确响应结果。

没有授权的用户仅仅只能对响应进行猜测,因为他们缺少适当的设备或软件和必需的密钥知识来模拟此种设备或软件。

接入盘问报文典型地包含一个回复信息,此信息中包括一个可以显示给用户的盘问,例如一个不可能被重复的数值。

典型的情况是来自扩展服务器,扩展服务器是知道那一类鉴别码对应这个已经被授权的用户,因此能选择一个适当基数和长度的随机的或不重复的伪随机数。

用户然后把这个盘问(不重复的数值)输入到他的设备或软件中,并计算出一个响应值,用户将此值输入到客户端,由客户端通过第二个接入请求数据包把它提交给RADIUS服务器。

如果响应报文是与RADIUS服务器预期的响应报文匹配,则服务器会回送一个接入允许数据包,否则是回送接入拒绝数据包。

例如,网络接入服务器传输一个接入请求数据包给RADIUS服务器,包中包含网络接入服务器的标识,网络接入服务器的端口号,用户名,用户密码(此密码或许是一个像“challenge”似的固定字符串,或者是被忽略的)。

服务器送回一个具有状态和回复消息的接入盘问数据包,其中回复消息包含有“challenge12345678,在提示处输入你的响应值”信息,这几行信息可由接入服务器显示给用户。

网络接入服务器(NAS)为这个响应提供提示信息,传输一个新的接入请求给服务器(用新的包编号),包括NAS标识、NAS端口号、用户名、用户密码(刚才由用户输入的响应值,现在已经加密),和来自服务器端接入盘问中相同的状态属性。

根据判断响应值是否与要求的值匹配,服务器送回一个接入允许或接入拒绝数据包,或者甚至会传输另一个接入盘问数据包。

2.2用不加密验证和加密验证配合动作

对口令验证协议(PAP),NAS采取了PAPID和密码,在一个接入请求包中将它们作为用户名和用户密码传输出去。

NAS可以包含服务类型属性AttributeService-Type=Framed-User,和Framed-Protocol=PPP作为一个提示告诉RADIUS服务器PPP服务是所希望的服务。

对质询握手身份认证协议(CHAP),NAS创建一个随机质询(最好是是16个字节),然后把它传输给用户,用户返回一个带有CHAPID和CHAP用户名的CHAP响应。

NAS随后传输一个请求接入数据包给RADIUS服务器,该请求包中,CHAP用户名称替代了用户名(User-Name)、CHAPID和加密的响应值代替CHAP密码(CHAP-Password)(属性3)。

随机质询或者被包含在CHAP盘问(CHAP-Challenge)属性中,或者如果它是16个字节长,它可被放到接入请求数据包中的请求鉴别码(RequestAuthenticator)域中。

NAS可以包含AttributeService-Type=Framed-User,和Framed-Protocol=PPP作为一个提示告诉RADIUS服务器PPP服务是所希望的服务。

RADIUS服务器根据用户名检查对应的密码,加密盘问,用MD5算法对CHAPID字节,前面找到的密码和CHAP盘问(如果在CHAP盘问属性存在则来自与此,否则来自请求认证者),把这个结果与CHAP密码进行比较。

如果它们是相匹配,服务器送回一个接入允许数据包,否则送回一个接入拒绝数据包。

如果RADIUS服务器不能执行被请求的认证,它一定返回一个接入拒绝数据包。

例如,CHAP要求以明文方式给服务器传输密码,以便它能加密CHAP盘问并与CHAP响应相比较。

如果不是以明文传输密码,服务器一定会给客户端传输一个接入拒绝包。

2.3代理

对RADIUS代理服务器来说,一个RADIUS服务器在收到一个来自RADIUS客户端(例如NAS服务器)的验证请求(或者记账请求)后,向一个远程的RADIUS服务器提交该请求,收到来自远程服务器的回复后,将这个回复传输给客户,这个回复可能带有反映本地管理策略的变化。

使用RADIUS代理服务器通常是为了漫游。

漫游功能使两个或更多的管理实体允许每一个用户为某项服务而拨入到任一个实体网络中。

NAS传输RADIUS接入请求给“转送服务器(forwardingserver)”,转送服务器把这个请求转送给“远程服务器(remoteserver)”。

远程服务器送回一个响应(接入允许、接入拒绝、接入质询)给转送服务器,转送服务器再把这个响应返回给NAS。

对于RADIUS代理操作,用户名属性可以包含一个网络接口标识符[8]。

哪一个服务器应该接收转送请求是根据认证域确定。

认证域可以是网络接口标识符(指定的域)的一部分。

或者,哪个服务器接收转送请求的选择可以基于任何一种转送服务器指定使用的标准,例如“调用站编号(Called-StationId)”。

一个RADIUS服务器可以同时作为转送服务器和远程服务器运行。

在某些域中作为一个转发服务器,在其他域中作为一个远程服务器。

一个转发服务器可以作为任何数量远程服务器的转发者。

一个远程服务器可以有任意数量的转发服务器向它转发,也能向任意数量域提供认证。

一个转发服务器可以向另一个转发服务器转发,从而生成一个代理链,应当注意避免循环引用。

下面的过程解释了一个代理服务器在一个NAS服务器、转发服务器和远程服务器之间的通信。

1.NAS向一个转发服务器发出接入请求。

2.转发服务器把这个请求转发给一个远程服务器。

3.远程服务器给转发服务器送回接入允许、接入拒绝或接入盘问。

在这个例子中,服务器送回的是接入允许。

4.转发服务器将接入允许传输给NAS。

转发服务器必须把已经存在于数据包中的任何代理状态属性当作不可见的数据。

它的操作禁止依靠被前面服务器添加到代理状态属性中的内容

如果收到来自客户端的请求中有任何代理状态属性,在给客户端的回复中,转发服务器必须在给客户端的回复中包括这些代理状态属性。

当转发服务器转发这个请求时,它可以把代理状态属性包含在其中,也可以在已转发的请求中忽略代理状态属性。

如果转发服务器在转发的接入请求中忽略了代理状态属性,它必须在响应返回给用户之前把这些代理状态属性添加到该响应中。

现在我们更为详细地说明每一步。

1.NAS传输它的接入请求给转发服务器。

如果用户密码存在,转发服务器会用与NAS共有的密钥对用户密码进行解密。

如果在数据包中有一个CHAP密码属性存在,没有CHAP盘问属性存在,转发服务器必须保证请求鉴别码完整的情况下,或者把它拷贝到CHAP盘问属性中。

转发服务器可以向数据包添加一个代理状态属性(只能添加一个)。

如果它添加了代理状态,该代理状态只能出现在数据包中任何其他代理状态属性之后。

转发服务器禁止修改任何其他已经存在于数据包中的代理状态属性(转发服务器可以选择不转发它们,但一定不能对它们修改)。

转发服务器禁止改变包括代理状态在内的同种类型任何属性的顺序。

2.如果用户密码存在的话,转发服务器用和远程服务器共有的密钥对用户密码进行加密。

它还会根据要求设置标识,向远程服务器转发接入请求。

3.远程服务器(如果是最终目标服务器)会使用用户密码、CHAP密码或者是将来扩

展时指定的一些方法验证用户的合法性,然后返回接入允许、接入拒绝或者接入盘问给转发

服务器。

对于这个例子,远程服务器传输的是一个接入允许数据包,远程服务器必须按照原

有的顺序而且不做任何修改的情况下,把所有的代理状态属性从接入请求中拷贝到响应数据

包中。

4.转发服务器使用它与远程服务器共有的密钥对响应鉴别码(ResponseAuthenticator)

进行验证,如果验证失败,它会简单的将数据包丢弃。

如果验证通过,转发服务器去掉最后

的代理状态(如果数据包内它附加过一个),使用它与NAS共有的密钥签发响应鉴别码,恢

复标识使它与NAS传输的源请求标识匹配,然后传输接入允许给NAS。

转发服务器可能修改属性以执行本地策略。

关于这种策略的讨论是在这篇文档范围之

外,而且是受以下限制的。

转发服务器禁止修改数据包中存在的代理状态、状态或类别属性。

转发服务器的实施者应该认真考虑什么样的值可以做为服务类型(Service-Type)接受。

对在代理请求允许中通过NAS提示的服务种类或管理的服务种类一起传输服务种类的结果

要给与认真的考虑,而且实施者希望可以提

供一些机制阻止那些以上提到的这些种类,或者

是其他的服务种类,或者是其他的属性。

关于这些机制的讨论不是在本文档范围之

内的。

2.4为什么使用UDP

一个经常问到的问题是为什么使用UDP而不是TCP作为传输协议。

选择UDP是基于严格的技术上的原因。

这有许多必须被理解的论点。

RADIUS是一个事务,基于几个具有有趣特点的协议。

1.如果向主验证服务器发出的请求失败,则必须查找备用服务器。

为了满足这个要求,考虑到向备用服务器传输请求,请求副本必须保留在传输层。

这意味着重发计时器仍然是需要的。

2.这个特别协议的计时要求与TCP所提供的有较大的不同。

在一种极端的情况下,RADIUS不做丢失数据的响应检查。

用户愿意为完成验证而

等几秒钟。

通常带有侵略性的TCP中继(基于平均往返时间)是不需要的,TC确认P开销也

是不需要的。

在另一种极端情况下,用户不愿花几分钟等待验证。

因此两分钟后,可靠的TCP数

据递送也是无效的。

对备用服务器快速的使用能在用户放弃之前获得访问。

3.协议的无状态特性简化了UDP的使用

服务器和客户机不停变化。

系统重新启动,或单路供电。

通常情况下,这不会产生问题,

但会导致出现超时和TCP连接中断检测,通过编写编码能够处理这类异常事件。

无论如何

UDP完全消除了这类特殊处理以及其中的任何一部分。

每一个服务器和客户端只需一次打开

他们UDP传输,尔后可以使传输处于一种打开的状态,也许在网络上从始至终传输的是不

成功信息。

4.UDP简化了服务器的实现

在最早的RADIUS实现中,服务器是单线程的。

这意味着只能有一个请求被接收、处理

和返回。

随后发现在后台安全机制会占用实时时间(1秒或更多)的环境中这样做是难管理

的。

服务器的请求队列会被填满,在每分钟内有成百上千的用户正在等待验证的环境中,请

求的轮换时间会长于用户所能忍受的等待时间,(尤其严重的是在数据库中的一次特殊的查

找,或者花在DNS上的时间大于30

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 其它

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1