老规矩, 先看维基: 远端用户拨入验证服务(RADIUS, Remote Authentication Dial In User Service)是一个AAA协议,意思就是同时兼顾验证(authentication)、受权(authorization)及计费(accounting)三种服务的一种网络传输协议(protocol),一般用于网络存取、或流动IP服务,适用于局域网及漫游服务。
https://zh.wikipedia.org/wiki/RADIUShtml
上面的介绍来自维基百科. 说的权威,可是不太好懂. 咱们这里再详细介绍如下几个问题, 但愿能给初次接触radius的小伙伴有所帮助:服务器
1) Radius 究竟是什么.
2) Radius 应用和工做方式.
3) Radius 的协议细节.网络
一. Radius 究竟是什么.tcp
上面维基百科 说的很具体了, Radius 远程拨入服务, 它集成了 认证, 受权 和计费功能. 怎么理解这个问题呢. 举个不是十分贴切的栗子, 宽带 ADSL 拨号上网的后台认证和计费系统就能够用radius, 或者 V-P-N 系统的后台验证计费系统就是radius 的使用场景.网络传输协议
固然, 并不能把 radius 的概念限制在 “拨号”, 实际上, 不光是这种 “拨号” 服务, 其余几乎任何服务, 均可以使用 radius 来进行认证,受权和计费服务.加密
二. Radius 的工做方式.code
咱们以搭建 V-P-N 为例, 介绍radius的工做方式.server
图中有三个角色, v-p-n(下面简称XXX服务器)服务器, 客户端 和radius 服务器.htm
Radius 主要工做在 xxx 服务器和 Radius 服务器之间, 客户几乎直接接触不到.blog
对于radius 协议来讲, xxx 服务器其实是 一个client, 而 radius 服务器是真正提供服务的server.
(若是看英文文档的话, rfc有专门解释 client 和server 的章节.)
这样看起来, radius 更像是 C/S 模式的协议.
因此后面的讨论主要集中在 xxx 服务器和 radius 服务器之间, 请自行脑补.
三. Radius 的协议细节.
这里仍是介绍一下大致的细节, 重点介绍如何阅读rfc. 有了方向,再读rfc就容易多了. 不会详细介绍每一个字节如何生成, 这是rfc的责任.
做为参考, 这是 radius 的rfc : https://tools.ietf.org/html/rfc2865
1) 首先, radius 是基于udp的协议, 全部数据包都是封装在udp协议中.
至于为何是udp,而不是tcp, 请参看 rfc 的解释: Why udp?
2) radius 协议包的格式.
基本上, radius 协议有四种包:
Access-Request Access-Accept Access-Reject Access-Challenge
这四种包都有统一的格式: https://tools.ietf.org/html/rfc2865#page-13
这四种包在 xxx服务器和radius 服务器之间通讯,来完成整个过程.
上图中, 前面三个交互是必须的, 后面两个绿色的带星号的交互不是必须的.
首先, xxx 服务器向radius发送 Access-Request 数据包, 包含用户信息和密码哈希等等信息用于认证.
此时服务器有四个选择:
第一, 若是认证经过,就返回一个 “Access-Accept” 数据包, 认证完成.
第二, 若是认证不经过,则返回 “Access-Reject”,认证失败.
第三, 若是服务器认为必要, 能够返回一个”Access-Challenge” 数据包, 让用户提供更多的附加信息以完成认证. 而xxx服务器在收到 “Access-Challenge” 消息以后, 须要向用户索要必须的附加信息,而后组成一个新的 ” Access-Request” 数据包发给radius服务器来继续认证. 此时服务器能够重复第一,或第二.
第四, 若是 “Access-Request” 数据包有问题, 服务器还能够采起 “静默丢弃”(silently discard) 的方式, 不作任何反应.
这就是主要的通讯流程了.
通常来说, 做为 radius 的客户端, “Access-Request” 数据包的格式比较重要. 他负责将认证信息加密传输给radius 服务器.
咱们再介绍一下 “Access-Request” 数据包的格式:
https://tools.ietf.org/html/rfc2865#page-17
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Request Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-
咱们如今介绍后面的 “Attributes” 数据区. 这里包含了用户的密码信息.
radius 协议将用户名,密码等等身份信息 都封装成一个一个的 attribute.
举个栗子, 可能最少须要两个 attribute, 一个是用户名, 另外一个是password hash. 这是最简单的方式了.
https://tools.ietf.org/html/rfc2865#page-22
目前, radius 的密码封装方式有两种,
一种是: User-Password, https://tools.ietf.org/html/rfc2865#page-27
另外一种是: CHAP-Password, https://tools.ietf.org/html/rfc2865#page-28
两种方式只是密码的hash计算方法不同而已. 具体生成方法比较明确. rfc 写的很明显,就很少说了.
到这里, radius 认证协议的客户端过程基本完成了. 至于服务端, 通常不用本身来写. 可使用开源的现成服务端.
欢迎访问个人我的独立博客: https://blog.byNeil.com