2023年7月4日发(作者：)

Radius认证协议（⼀）简介 为⼤量⽤户管理分散的串⾏线和调制解调器池需要重要的管理⽀持。由于调制解调器池定义为与外部世界的链接，因此需要特别关注其安全、授权和计费。这可以通过管理单个的⽤户数据库来实现，该数据库可以进⾏认证（验证⽤户名和密码）以及向⽤户提供的服务类型的配置信息（例如SLIP、PPP、telnet、rlogin）。主要特征如下：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。术语名词服务会话解释NAS为拨⼊⽤户提供服务，如PPP或Telnet。NAS向拨⼊⽤户提供的每个服务都构成⼀个会话，会话的开始定义为⾸次提供服务的点，会话的结束定义为服务结束的点。如果NAS⽀持，则⼀个⽤户可以有多个并⾏或串⾏会话。静默丢弃在没有进⼀步处理的情况下丢弃数据包。但应该记录包括静默丢弃的数据包的内容的错误，并且应该在统计计数器中记录事件。操作 当客户端配置为使⽤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 yourresponse 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属性或RequestAuthenticator）进⾏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服务器。