Radius认证协议（一）

简介

        为大量用户管理分散的串行线和调制解调器池需要重要的管理支持。由于调制解调器池定义为与外部世界的链接，因此需要特别关注其安全、授权和计费。这可以通过管理单个的用户数据库来实现，该数据库可以进行认证（验证用户名和密码）以及向用户提供的服务类型的配置信息（例如SLIP、PPP、telnet、rlogin）。

Radius主要特征如下：

• C/S模型：网络接入服务器（NAS）是Radius的客户端，负责将用户信息传递给指定的RADIUS服务器，然后对返回的响应进行相应的操作。

         RADIUS服务器接收用户连接请求，认证用户，然后返回客户端提供服务所必需的配置信息。

          RADIUS服务器可以充当其他RADIUS服务器或其他类型的认证服务器的代理客户端。

•   网络安全：客户端和RADIUS服务器之间的事务通过永远不会通过网络发送的共享密钥进行身份验证。另外，所有用户密码都是以加密方式在客户端和RADIUS服务器之间发送， 消除了在不安全的网络上窥探用户密码的可能性。
• 灵活的认证机制：RADIUS服务器支持多种方法对用户进行身份验证。当用户提供的用户名和原始密码时，它可以支持PPP-PAP或CHAP、UNIX登录和其他身份验证机制。
• 可扩展的协议：所有事务均由可变长度的属性（Type）-长度（Length）-值（Value）3元组组成。 添加新的属性不会影响协议的现有实现。

     Radius协议被广泛实现和使用，但经验表明，在大规模系统中使用可能会导致性能下降和数据丢失，部分原因是由于radius协议不包括拥塞控制措施。

说明

            Nas不能实现的服务的属性不能出现在RADIUS属性中。例如，NAS不能提供ARAP服务，则ARAP的属性不能出现在RADIUS属性。NAS必须将授权不可用服务的RADIUS的access-accept视为access-reject。

术语

操作

        当客户端配置为使用RADIUS时，则客户端的任何用户都会向该客户端出示身份验证信息。 可能是自定义的登录提示，要求用户输入用户名和密码。或者，用户可以使用诸如点对点协议（PPP）之类的链路帧协议，此类协议具有携带认证信息的报文。

       客户端一旦获得了这些信息，就使用RADIUS进行身份验证。为此，客户端创建一个包含诸如用户名、密码、客户端ID和用户正在访问的PORT ID等属性的“Access- Request”。含有密码时，则使用基于RSA Message Digest Algorithm MD5的算法将其隐藏。

        Access- Request通过网络提交给RADIUS服务器。如果在一段时间内没有响应，则多次重发Access- Request。如果主服务器停机或无法访问，客户端还可以将请求转发到备用服务器。备用服务器可以在多次尝试主服务器失败后使用，也可以以循环方式使用。

        RADIUS服务器收到请求后，则验证发送请求的客户端。如果Radius服务器没有客户端的共享秘钥，则静默丢弃该请求。如果客户端有效，则RADIUS服务器在用户数据库查找名称与请求匹配的用户。用户条目包含允许用户访问所必须条件列表，通常包括密码，也可以指定用户允许访问的客户端或端口。

        RADIUS服务器可以向其他服务器转发请求，在这种情况下，它充当客户端。

        如果Access- Request中存在Proxy-State属性，则必须原封不动地将它们复制到响应数据包中。其他属性可以放置在Proxy-State属性之前、之后甚至之间。

        如果任一条件不满足，则RADIUS服务器发送“Access- Reject”响应，表示此用户请求无效。 如果需要，服务器可以在Access- Reject中包含一条客户端可以向用户展示的文本消息。Access- Reject中不允许有其他属性（Proxy-State除外）。

         如果所有条件都满足，而RADIUS服务器希望发出用户必须响应的质询，那么RADIUS服务器将发送“Access-Challenge”响应。它可以包括一条由客户端显示给用户的文本消息，提示用户对质询作出响应，并且可以包括一个State属性。

         如果支持质询/响应的客户端接收到Access-Challenge后，向用户显示文本消息（如果有），并提示用户进行响应。然后，客户端使用新的请求ID重新提交其原始的Access-Request，并用用户响应（加密）替换User-Password属性，以及包括Access-Challenge中的State属性（如果有）。 请求中仅应存在0或1个State属性实例。 服务器可以使用Access-Accept, an Access-Reject, 或另一个Access-Challenge来响应这个新的Access- Request。

          如果满足了所有条件，则将用户的服务类型（例如：SLIP，PPP）和实现服务所必需的配置值放入“Access-Accept”响应中。对于SLIP和PPP，这可能包括诸如IP地址，子网掩码，MTU，希望的压缩和希望的数据包过滤器标识符之类的值。 对于字符模式用户，这可能包括诸如所需协议和主机之类的值。

质询/回应

         在质询/响应认证中，用户被质询，给用户一个不可预测的数字，用户对其进行加密并返回结果。授权用户配备了可以计算正确的响应的诸如智能卡或软件等特殊设施。未经授权的用户，则缺少适当的设备或软件，以及不知道模拟这种设备或软件所需的密钥，只能猜测响应。

       Access-Challenge数据包一般包含一个要显示给用户的包含质询的Reply-Message，例如不可能重复的数字值。通常从知道授权用户拥有哪种类型的身份验证的外部服务器获得的，因此可以选择适当基数和长度的随机或非重复伪随机数。

           然后，用户将质询输入他的设备（或软件）中并计算响应，用户将响应输入客户端，客户端通过第二个Access-Request将其转发给RADIUS服务器。如果响应与预期的响应匹配，RADIUS服务器将以Access-Accept作为响应，否则将以Access-Reject作为响应。

        示例：NAS向RADIUS服务器发送带有NAS-Identifier、NAS-Port、User-Name、User-Password（可以只是一个固定字符串，如“challenge”或被忽略）的Access-Request。服务器发回一个带有State的和需要NaS显示的” Challenge 12345678, enter your response at the prompt “的Reply-Message的Access-Challenge。NAS会提示响应并向服务器发送一个带有NAS-Identifier、NAS-Port、User-Name、User-Password（用户刚刚输入的响应，已加密）以及与Access-Challenge相同的State的的新的Access-Request（使用新的ID）。然后，服务器根据响应是否与所需值匹配，发送Access-Accept或Access-Reject，甚至可以发送另一个Access-Challenge。

与PAP和CHAP的互操作

          对于PAP，NAS会获取PAP ID和密码，并在Access-Request中将它们作为User-Name和User-Password发送。NAS可以包括属性Service-Type = Framed-User和Framed-Protocol = PPP，向RADIUS服务器提示需要PPP服务。

          对于CHAP，NAS生成一个随机质询（最好是16字节）并将其发送给用户，用户返回CHAP响应以及CHAP ID和CHAP用户名。然后，NAS向RADIUS服务器发送一个Access-Request数据包，其中CHAP用户名作为User-Name，CHAP ID和CHAP响应作为CHAP-Password（属性3）。随机质询可以放在在CHAP-Challenge属性中，或者，如果它是16字节，则可以将其放置在Access-Request的Request Authenticator字段中。NAS可以包括属性Service-Type = Framed-User和Framed-Protocol = PPP，向RADIUS服务器提示需要PPP服务。

         RADIUS服务器根据用户名查找密码，对CHAP ID、密码和CHAP质询（如果存在，则来自CHAP-Challenge属性或Request Authenticator）进行MD5加密，并将结果与CHAP-Password进行比较。如果匹配，服务器返回Access-Accept，否则返回Access-Reject。

       如果RADIUS服务器无法执行请求的身份验证，则必须返回Access-Reject。例如，CHAP要求用户的密码以明文形式提供给服务器，以便服务器可以加密CHAP质询并将其与CHAP响应进行比较。如果密码不能以明文形式提供给RADIUS服务器，那么服务器必须向客户端发送Access-Reject。

代理

        作为代理RADIUS，一个RADIUS服务器接收来自RADIUS客户端（如NAS）的身份验证（或计费）请求，将请求转发到远端的RADIUS服务器，接收来自远端服务器的回复，并将该回复发送到客户端（可能会进行更改以反映本地管理策略）。代理RADIUS的一个常见用法是漫游。漫游是两个或多个管理实体允许彼此的用户拨入任一实体的网络进行服务。

        NAS发送access-request到“转发服务器”，该转发服务器转发到远端服务器。 远端服务器发送响应（Access-Accept，Access-Reject或Access-Challenge）到转发服务器，转发服务器再将其发送回NAS。User-Name属性可以包含用于RADIUS代理操作的网络访问标识符。 选择哪个服务器接收转发的请求应该基于认证“域名”。 认证域名可以是网络访问标识符（“命名领域”）的域名部分。 备选地，哪个服务器接收转发的请求的选择可以基于转发服务器配置的其他标准，例如Called-Station-Id（“编号域名”）。

       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属性，则转发服务器务必在其对客户端的答复中包括那些Proxy-State属性。 转发服务器转发请求时，可以在access-request中包含Proxy-State属性，也可以省略它们。如果转发服务器在转发的访问请求中省略了Proxy-State属性，则必须在将响应发送给客户端之前将它们附加到响应中。

     现在，详细地检查每个步骤。

1. NAS发送access-request到转发服务器。转发服务器使用它与NAS的共享密钥解密User-Password（如果存在）。如果数据包中存在CHAP-Password属性而不存在CHAP-Challenge属性，则转发服务器必须保持Request-Authenticator不变，或者将其复制到CHAP-Challenge属性。                                                                                                            转发服务器可以向包中添加一个Proxy-State属性。（不能添加多个。）添加的Proxy-State必须位于数据包中其他Proxy-State之后。转发服务器不能修改数据包中的其他Proxy-State（可以不转发，但不能更改）。转发服务器不得更改同一类型的任何属性的顺序，包括Proxy-State。
2. 转发服务器使用与远程服务器共享的秘钥对User-Password（如果存在）进行加密，根据需要设置Identifier，转发access-request给远端服务器。
3. 远端服务器（最终目的地）使用User-Password、CHAP-Password或将来扩展规定的方法验证用户，并发生access-accept、access- reject 或 access-challenge给转发服务器。对于本例，发送access-accept。远端服务器必须按顺序将所有Proxy-State属性（仅Proxy-State属性）从access-request复制到响应数据包，且不进行任何修改。
4. 转发服务器使用与远程服务器的共享秘钥验证Response Authenticator，验证失败，则静默丢弃数据包；验证通过，转发服务器则删除最后一个Proxy-State（如果它附加了Proxy-State），使用与NAS的共享秘钥对Response Authenticator进行签名，恢复Identifier以匹配NAS原始请求中的Identifier，发送access-accept到NAS。

转发服务器为了实施本地策略可以修改属性，但不得修改数据包中现有的Proxy-State、State或Class属性。

转发服务器的实现应该仔细考虑愿意接受哪些Service-Type值。必须仔细考虑在代理Access-Accept中传递NAS-Prompt或管理的Service-Types的影响，具体实现会提供阻止其他服务类型或其他属性的机制。

采用UDP的原因

有许多必须理解的问题。 RADIUS是基于事务的协议，具有几个有趣的特征：

1. 如果对主认证服务器的请求失败，则必须查询备服务器。                                                                                                                                                                                                为了满足这一要求，请求的副本必须保存在传输层之上，以允许交替传输。这意味着仍然需要重传计时器。
2. 这个协议的计时要求与TCP提供的有很大的不同。                                                                                                                                                                                                            极端情况下，RADIUS不需要对丢失的数据进行“响应式”检测。用户为了身份验证愿意等几秒钟。不需要TCP主动重传（基于平均往返时间），也不需要TCP的确认开销。             另一个极端是，用户不愿意为了身份验证等几分钟。因此，两分钟后的TCP可靠地传输数据是没有用的。使用备服务器能更快地使用户获得访问权限。
3. 这个协议的无状态特性简化了UDP的使用。                                                                                                                                                                                                                    客户端和服务器来来往往。一般来说，系统重启不会引起问题，并且通过创造性的超时和TCP连接丢失的检测，可以编写代码来处理异常事件。不过，UDP完全消除了这种特殊处理。每个客户端和服务器可以只打开一次UDP传输，并在网络上的所有类型的故障事件中保持打开状态。
4. UDP简化了服务器实现。                                                                                                                                                                                                                                              RADIUS服务器最早采用的单线程。在实时的后端安全机制（1秒或更长时间）的环境中，这是不可管理的。在每分钟有数百人进行身份验证的环境中，服务器请求队列就会很快填满，请求周转时间就会超过用户愿意等待的时间（数据库或DNS中的查找需要30秒或更长时间时，这种情况则更为严重）。显而易见的解决方案是服务器使用多线程，而使用UDP实现这一点很简单。单独的线程来为每个请求提供服务，这些线程可以通过将一个简单的UDP数据包发送到客户端的原始传输而直接响应客户端NAS。

但这不是万能的。如前所述，使用UDP需要人为地管理到同一服务器的重传计时器。

重传提示

如果主备RADIUS服务器使用相同的共享秘钥，因为属性的内容没有更改，则数据包重传到备RADIUS服务器可以使用相同的ID和Request Authenticator，也可以使用新的Request Authenticator。

如果更改任何属性的内容，则需要一个新的Request Authenticator和ID。

如果NAS重传RADIUS请求到同一服务器，且没有更改任何属性，则必须使用相同的Request Authenticator、ID和源端口。如果更改了任何属性，则必须使用新的Request Authenticator和ID。

NAS可以在所有服务器上使用相同的ID，也可以每个服务器的使用单独ID，这取决于实现者。如果NAS需要超过256个ID来处理未完成的请求，它可以使用其他源端口来发送请求，并跟踪每个源端口的ID。这允许一次向单个服务器发送多达1600万个左右的未完成请求。

Keep-Alives有害

不鼓励实现者采用了发送测试RADIUS请求以查看服务器是否处于活动状态的做法，因为它会增加负载并损害可伸缩性，而不会提供任何其他有用的信息。因为RADIUS请求包含在一个数据报中，所以与发送ping所需的时间相同，可以只发送RADIUS请求，得到一个回复就说明RADIUS服务器启动了。如果没有要发送的RADIUS请求，服务器是否启动并不重要，因为没有使用它。

可以使用SNMP监视RADIUS服务器。