锐英源精品开源心得，转载请注明出处：锐英源，www.wisestudy.cn，孙老师作品，联系电话13803810136。

RFC2865 - RADIUS协议－－第一部分  

IESG提示
本协议正在广泛使用中。研究表明大规模使用过程中，性能会下降，部分原因是其中没有包含拥塞处理的相关内容。读者可以访问IETF's AAA获得新的进展，他们可能开发了有更好寻址能力，缩放和拥塞控制的下一代协议。
摘要
本文描述了这样一种协议，它携带需要认证的网络接入服务器（NAS）和共享的认证服务器之间的认证和授权信息。

注意
本文是RADIUS协议。最初RADIUS使用UDP 1645端口，因为和“datametrics”服务冲突后来官方将其改为1812端口。

1. 概述

本文废弃了RFC 2138。与RFC 2138不同之处在附录的“修改记录”中有简要描述。
行政支持的重要需求是通过分布的串行线和modem池进行大量用户管理。因为modem池定义了连接外部网络的通路，需要关系户安全、授权和计费。最完美的实现是使用一个用户数据库，使用这个数据库，可以允许认证（认证用户名和密码）以及进行用户服务类型的配置。
RADIUS协议的特征如下：
l         C/S模式
网络访问服务器（NAS）是RADIUS的客户端。客户端的职责是将用户信息传递到服务器然后将服务器的应答传回客户端。
RADIUS服务器可以作为代理，将客户端请求转发到其他RADIUS服务器或不同类型的认证服务器。
l         网络安全
RADIUS服务器和客户端之间传递的信息使用一个共享密钥进行加密，这个密钥不在网络上传递。同时，用户密码加密传送，防止有人使用嗅探器得到用户密码。
l         可扩展的认证机制
RADIUS提供多种认证方式。当使用用户名和密码进行校验时，支持PPP、PAP、CHAP或UNIX登录以及其他认证机制。
l         可扩展协议
所有的报文都是由（属性，长度，值）组成。添加新属性不会影响已有属性。

1.1.必须的说明

本文中的"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL"关键字在BCP 14[2]中有解释。这些关键字忽略大小写。
不满足其中must和must not描述的实现与协议不兼容。满足所有must，must not，should和should not的实现认为是对协议的“无条件兼容”；只满足must和must not但不一定满足should和should not的实现认为是对协议“有条件兼容”。

1.2.术语

文档中频繁出现以下词汇：
l         服务(service)：
NAS为拨号用户提供服务比如PPP或telnet。
l         会话（session）：
NAS为拨号哟功能狐提供的每一个服务构成一个会话，当首次提供服务到服务结束时会话终止。如果NAS支持，一个用户可以串行或并行的拥有多个会话。
l         静默丢弃（silently discard）：
表明丢弃报文不进行后续处理。当记录日志出现错误时应该进行这个操作，并且应该计入统计信息中。

2. 操作

当客户端使用RADIUS时，每一个使用客户端的用户为客户端提供认证信息。可能使用一个登录弹出框，期待用户输入用户名和密码。用户可能使用连接帧协议例如PPP协议，使用协议报文传递上述信息。当客户端收到这些信息时，它选择使用RADIUS协议进行认证。
在认证过程中，客户端创建一个Access-Request报文包含用户名、密码、客户端ID和用户接入的端口ID。当包含密码时，使用RSA的信息摘要算法MD5进行加密。
Access-Request通过网络发送到RADIUS服务器。如果一段时间没有应答，请求重传几次。客户端可以将请求转发到另一个服务器或当主服务器不可达时转发。当主服务器几次重传失败或使用循环方式时使用另一个服务器。
当RADIUS服务器收到请求后，立即校验发送请求的客户端。如果发送请求的客户端没有共享密钥，报文被丢弃。如果客户端通过校验，RADIUS服务器请求用户信息数据库，查看用户名是否存在。用户信息数据库中的用户需要满足一系列规则。这些规则通常是校验用户密码，也可以校验客户端或端口是否允许进行接入。
RADIUS服务器可以将请求转发到其他服务器，这种情况下它的身份是客户端。
Access-Request中有任何代理状态属性（Proxy-State attributes），必须无修改的复制到应答报文中。其他属性可以放置在代理状态属性之前，之后或之间。
如果任何一个条件不满足，RADIUS服务器向用户发送一个Access-Reject报文，用户请求非法。如果需要，服务器可以在Access-Reject报文中加入文本信息，这些文本信息可以由客户端显示用户。其他属性都不允许在Access-Reject报文中出现，除了Proxy-State属性。
如果所有条件都满足，RADIUS服务器必须向客户端发送Access-Challenge报文，用来挑战客户端。报文中可能包含显示给用户的文本消息以及State属性。如果客户端收到Access-Challenge报文并且支持挑战/应答方式，可能显示消息。客户端使用一个新的请求ID重发Access-Request报文，报文中的User-Password属性使用应答进行替换，并且包含Access-Challenge 报文的State属性。只有0个或1个State属性应该出现在请求中。服务器可以使用Access-Accept、Access-Reject或另一个Access-Challenge报文进行应答。
如果所有条件都满足，用户的配置信息会包含在Access-Accept应答中。这些信息包括服务类型（SLIP、PPP、Login User）和所有需要交付服务的数据。对于SLIP和PPP来说，可能包括IP地址，子网掩码，MTU，压缩方式和包过滤符。对于文本模式的用户，可能包含协议和主机。

2.1.挑战应答

在挑战/应答的认证过程中，服务器给用户一个不可预测的数字，用户加密它并返回结果。授权用户使用特殊设备、智能卡或软件进行应答计算。未授权用户，缺少合适的设备或软件并且缺少模仿密钥的相关知识，只能瞎猜一个应答。
Access-Challenge报文包含一个作为挑战发送给用户的应答消息，例如不可能重复的数字。通常情况下，数字从另外的服务器获得，这台服务器知道认证用户的类型并且可以选择一个随机的或有合适基数和长度的不重复的伪随机数。
用户将挑战值放入他的设备（或软件）中计算应答，然后用户通过第二个Access-Request报文将应答发送回RADIUS服务器。如果应答符合RADIUS服务器的预期，回应一个Access-Accept报文，否则回应一个Access-Reject报文。
例如：NAS向RADIUS服务器发送一个Access-Request报文，报文中包括NAS-Identifier, NAS-Port, User-Name, User-Password（可能只是一个类似“challenge”之类的字符串或干脆忽略这个字段）。服务器发回Access-Challenge报文，报文中有状态信息和应答消息，同时有挑战值“12345678”，您在NAS提示框中输入应答。NAS发送应答，应答报文是一个新的Access-Request报文（使用新ID），包括NAS-Identifier, NAS-Port, User-Name, User-Password（加密），以及Access-Challenge中的状态。服务器根据应答是否满足要求返回Access-Accept 或Access-Reject报文，也可以返回另一个Access-Challenge报文。

2.2.与PAP和CHAP交互

对于PAP，NAS将PAP ID和密码以及用户名和密码封装在一个Access-Request报文中。NAS可能包括Service-Type = Framed-User和Framed-Protocol= PPP两种属性（告诉RADIUS服务器适合用PPP服务进行认证）。
对于CHAP，NAS生成一个随机数（最好是16个字节）并将它发送给用户，用户返回一个包含CHAP ID和CHAP用户名的CHAP应答。NAS然后发送Access-Request给RADIUS服务器，报文中将CHAP用户名作为用户名，将CHAP ID和CHAP应答作为CHAP密码。随机的挑战值可以保存在CHAP-Challenge属性中后者如果它是16个字节长，可以直接保在Access-Request报文的Request Authenticator域中。NAS可能包含Service-Type = Framed- User和Framed-Protocol = PPP两种属性告诉RADIUS服务器使用PPP服务。
RADIUS服务器根据用户名查询密码，使用MD5算法以CHAP ID加密密码和CHAP挑战值（CHAP-Challenge属性或Request Authenticator），比较CHAP-Password结果。如果一致，服务器返回Access-Accept报文，否则返回Access-Reject报文。
如果RADIUS服务器不能执行认证，必须返回Access-Reject报文。例如，CHAP方式需要用户密码以明文方式传递，然后才能加密CHAP挑战值和应答比较。如果密码不是明文，RADIUS服务器必须向客户端发送Access-Reject报文。

2.3.代理

作为RADIUS代理，一台RADIUS服务器从RADIUS客户端（例如NAS）接收一个认证或记账报文，将报文转发到远程RADIUS服务器，然后从远程RADIUS服务器接收应答，转发给客户端，可能做了一些修改以反映本地管理策略。RADIUS代理的一般用途是漫游。漫游允许一个或多个管理实体中的用户在自己的实体中拨号，使用各自实体中的网络资源。
NAS将RADIUS access-request报文发送给转发服务器，转发服务器将报文转发给远程服务器。远程服务器向转发服务器返回应答(Access-Accept, Access-Reject, or Access-Challenge)，然后抓发到NAS。User-Name属性可能包含RADIUS代理操作的网络接入标识符。哪一个服务器接收请求基于认证域。认证域可能是网络接入标识符中的域部分（命名域）。或者，哪一个服务器接收转发请求可能基于服务器配置的其他条件，比如Called- Station-Id（数字域）。
RADIUS服务器可以既是转发服务器又是远程服务器（为一些域作为转发服务器又为一些域作为远程服务器）。一个转发服务器可以向多个远程服务器进行转发。远程服务器可以可以接收多个转发服务器，可以为多个域提供认证服务。一个转发服务器可以将请求转发到其他转发服务器以提供代理链，在使用过程中需要防止形成循环代理链。
以下场景展示代理RADIUS和NAS以及远程RADIUS服务器之间通信的过程：
1.       NAS将access-request报文发送给转发服务器。
2.       转发服务器将access-request报文发送到远程服务器。
3.       远程服务器向转发服务器返回access-accept，access-reject或access-challenge报文。在本例中，返回一个access-accept报文。
4.       转发服务器将access-accept发送给NAS。
转发服务器必须将已经存在的Proxy-State属性认为是不透明数据。不能基于其他服务器添加的Proxy-State进行操作。
如果客户端的请求报文中包含任何Proxy-State属性，转发服务器在应答报文中也必须包含这些属性。转发服务器转发access-request请求时可以包含Proxy-State属性，或者转发请求时忽略它。如果转发服务器转发access-request报文时忽略了Proxy-State属性，将应答返回给客户端时，必须添加他们。
我们来看更详细的情况。
1.              NAS将access-request报文发送到转发服务器。如果有User-Password，转发服务器使用NAS中的共享密钥解密User-Password。如果报文中有CHAP-Password属性，并且报文中没有CHAP-Challenge属性，转发服务器必须保证Request-Authenticator不修改或拷贝到CHAP-Challenge属性。
转发服务器可能在报文中加入Proxy-State属性。如果添加Proxy-State属性，必须添加到其他Proxy-State属性之后。转发服务器不能哪个修改报文中的其他Proxy-State属性（可能不转发他们，但如果转发就不能修改）。转发服务器不能修改同类属性顺序，包括Proxy-State属性。
2.              如果存在用户密码，转发服务器使用远程服务器密钥加密用户密码，在需要时设置标识符，然后将access-request报文转发到远程服务器。
3.              远程服务器（如果是终点）使用User-Password, CHAP-Password或其他未来扩展的方式校验用户身份，向转发服务器应答access-accept、access- reject或access-challenge报文。远程服务器必须从access-request报文中拷贝所有Proxy-State属性（只拷贝这个属性）到应答报文中，不能进行任何修改。
4.              转发服务器使用远程服务器共享密钥校验Response Authenticator，如果不能通过校验，静默丢弃报文。如果报文通过校验，转发服务器删除最后一个Proxy-State（如果添加了），使用和NAS共享的密钥签名Response Authenticator，重置NAS的上一个标识符，然后将access- accept转发给NAS。
转发服务器可以根据本地策略修改属性。这些策略和相应的限制已经超出本文档的范围。转发服务器不能修改报文中已存在的Proxy-State、State或Class属性。
转发服务器实现时需要仔细考虑接收的范围类型。需要仔细考虑传递NAS提示的服务类型或在代理的Access-Accept报文中进行管理，实现者可以提供阻塞一些或其他服务类型或属性的方式。这些技巧已经超出本文的范围。

2.4.为什么使用UDP

为什么RADIUS使用UDP而不使用TCP作为传输层协议是一个最常使用到的问题。使用UDP有严格的技术原因。
RADIUS是一个基于事务的协议，有一些有趣的特点：
1.       如果主服务器的请求失败，必须请求备用服务器。
为了满足这个需求，需要在传输层保留用作重传的报文复本。同时需要重传计时器。
2.       这个协议对时间的需求和TCP协议有很大不同
一个极端是，RADIUS协议不需要丢失数据的应答检测。用户愿意等待几秒进行认证。不需要TCP重传机制（基于平均往返时间），也不需要增加TCP的这部分负载。
另一个极端是，用户不愿意等待几分钟进行认证。所以TCP2分钟的可信传输时间没用。快速的偿失另一台服务器在用户放弃前让用户通过认证。
3.       UDP无状态特性是协议很简单。
客户端和服务器过来过去。系统重启都不依赖于循环动力。一般情况下，TCP的超时和丢包检测没有理由存在，通过代码可以处理异常时间。UDP完全没有这些异常处理机制。每一个客户端和服务器可以只打开UDP传输一次然后一直为所有网络失败时间开放。
4.       UDP简化服务器实现。
早期的RADIUS服务器实现中，服务器使用单线程。只有一个请求被接收、处理、返回。当后端安全策略占据1秒或以上时间时，就不能控制了。在真实环境中每分钟有上百个进行认证服务器请求队列已满，应答返回的的时间比用户可以等待的时间还要长（当有数据库查询或DNS需要30秒以及更长时间时这种情况更加严重）。显而易见的解决方案是使用多线程服务器。使用UDP会更加容易。每一个独立的线程被为每一个请求服务，并且这些线程可以直接使用简单的UDP报文应答客户端NAS。
UDP不是灵丹妙药。使用UDP需要实现TCP中的一些内置功能：必须手动处理同一个服务器的重传计时器。这时使用UDP的一个不足。

2.5.重传暗示

如果RADIUS服务器和其他RADIUS服务器共享同样的密钥，向其他RADIUS服务器重传报文时使用同样的ID和Request Authenticator没有问题，因为属性内容没有修改。如果使用一个新的Request Authenticator向其他的服务器发送，也可以。
如果您修改了User-Password属性的内容，需要创建一个新的Request Authenticator和新ID。
如果NAS像上次一行为相同RADIUS服务器发送重传报文并且所有属性都没有修改，必须使用相同的Request Authenticator、ID和源端口。如果任何属性被修改，需要使用一个新的Request Authenticator和ID。
NAS可能为所有服务器使用相同ID或为不同服务器保存不同ID，由实现者决定。如果NAS为未处理的请求需要多于256个ID，需要使用其他的源端口发送请求，并且与每一个源端口的ID保持联系。允许一个服务器同时支持1600万未处理ID。

2.6.保持活动是有害的

一些设计者使用向RADIUS发送测试请求的方式判断服务器是否运行。强烈建议停止这种实践，因为这样不但增加了服务器的负载，而且没有提供任何有用的信息。因为RADIUS请求封装在一个单独的数据报中间性发送，发送一个ping报文的时间也可以发送一个RADIUS请求，然后得到应答表明服务器正在运行。如果不发送RADIUS请求，服务器是否运行也没有关系，因为你不使用它。
如果需要监视您的RADIUS服务器，使用SNMP协议，这个协议就是干这个的。

3. 报文结构

一个RADIUS报文封装在UDP报文中，端口是1812。当应答生成后，源端口和目的端口被倒转。
这份文档介绍RADIUS协议。最初的RADIUS协议使用UDP 1645端口，这和datametrics服务冲突。RADIUS协议的正式端口是1812。
RADIUS协议数据结构如下，数据从左向右传送。

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    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |     Code      |  Identifier   |            Length             |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |                                                               |    |                         Authenticator                         |    |                                                               |    |                                                               |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |  Attributes ...    +-+-+-+-+-+-+-+-+-+-+-+-+-

3.1.Code

Code字段长度为一个字节，表示RADIUS报文的类型。如果收到报文Code字段非法，则被静默丢弃。
RADIUS报文中code字段含义如下：