radius属性

一、关于radius

RADIUS原先的目的是为拨号用户进行认证和计费。后来经过多次改进，形成了一项通用的认证计费协议。

RADIUS是一种C/S结构的协议，它的客户端最初就是NAS服务器，现在任何运行RADIUS客户端软件的计算机都可以成为RADIUS的客户端。

在RADIUS的Server端和Client端之间的通信主要有两种情况:一种是接入认证；另一种是计费请求。

RADIUS协议认证机制灵活，可以采用PAP、CHAP或者Unix登录认证等多种方式。

基于挑战/应答（Challenge/Response）方式的身份认证机制

RADIUS的基本工作原理：用户接入NAS，NAS向RADIUS服务器使用Access-Require数据包提交用户信息，包括用户名、密码等相关信息，其中用户密码是经过MD5加密的，双方使用共享密钥，这个密钥不经过网络传播；RADIUS服务器对用户名和密码的合法性进行检验，必要时可以提出一个Challenge，要求进一步对用户认证，也可以对NAS进行类似的认证；如果合法，给NAS返回Access-Accept数据包，允许用户进行下一步工作，否则返回Access-Reject数据包，拒绝用户访问；如果允许访问，NAS向RADIUS服务器提出计费请求Account-Require，RADIUS服务器响应Account-Accept，对用户的计费开始，同时用户可以进行自己的相关操作。

Radius

Client

(NAS)

Radius

Server

Access-Request

（用户名、口令、NAS的ID及端口）

Access-challenge （或Access-Reject）

用户信息，包括状态属性（或错误文本信息）

Access-Request

当前用户的反应信息及之前Access-challenge的状态属性

Access-Accept

认证不成功时，重试Access-challenge,拒绝Access-Reject

Radius认证过程

RADIUS还支持代理和漫游功能。简单地说，代理就是一台服务器，可以作为其他RADIUS服务器的代理，负责转发RADIUS认证和计费数据包。所谓漫游功能，就是代理的一个具体实现，这样可以让用户通过本来和其无关的RADIUS服务器进行认证。

RADIUS是一种可扩展的协议，它进行的全部工作都是基于Attribute-Length-Value的向量进行的。

RADIUS服务器和NAS服务器通过UDP协议进行通信，RADIUS服务器的1812端口负责认证，1813端口负责计费工作。采用UDP的基本考虑是因为NAS和RADIUS服务器大多在同一个局域网中，使用UDP更加快捷方便。

RADIUS协议还规定了重传机制。如果NAS向某个RADIUS服务器提交请求没有收到返回信息，那 么可以要求备份RADIUS服务器重传。由于有多个备份RADIUS服务器，因此NAS进行重传的时候，可以采用轮询的方法。如果备份RADIUS服务器 的密钥和以前RADIUS服务器的密钥不同，则需要重新进行认证。

RADIUS是目前最常用的认证计费协议之一，它简单安全，易于管理，扩展性好，所以得到广泛应用。但是由于协议本身的缺陷，比如基于UDP的传输、简单的丢包机制、没有关于重传的规定和集中式计费服务，都使得它不太适应当前网络的发展，需要进一步改进。

数据包结构

RADIUS数据包被包装在UDP数据报的数据块（Data field)）中，其中的目的端口为1812。具体的数据包结构如表1。

8位	8位	16位
code	Identifier	Length
Authenticator（128位）
Attributes…（不定长）

· Code Code域长度为8位，具体取值见表2。其中，1、2、3用于用户认证，而4、5则是统计流量用，12、13 用于试验阶段，255作为保留。

code	含义
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server(experimenta)
13	Status-client(experimenta)
255	Reserved

· Identifier Identifier域长度为8位，主要用于匹配请求和回应数据包，也即是数据包的编号。

· Length 长度为16位，取值范围（20<=Length<=4096），此长度包括Code、Identifier、Length、Authenticator和 Attribute五个数据域的长度总和（Code、Identifier、Length、Authenticator为定长，Attribute为变长)。超出范围的数据将被视为附加数据（Padding）或直接被忽略。

· Authenticator 长度为16个字节(128位)，主要用于鉴定来自RADIUS服务器的回应，同时也用于对用户口令进行加密。

(1) Request Authenticator

在“Access-Request”数据包中，Authenticator是一个16字节的随机数，称为“Request Authenticator”。它在NAS和RADIUS服务器之间通过“共享密码”(secret)传输数据的整个生命周期中是唯一的。　　

(2) Response Authenticator

在“Access-Accept”、“Access-Reject”和“Access-Challenge”中的Authenticator域被称为“Response Authenticator”。

有下面的计算方法：

ResponseAuth = MD5(Code+ID+Length+RequestAuth+ Attributes+Secret) ——（公式1）

· Attributes 属性域的数据格式如表3所示。

8位	8位	不定长（0或多个字节）
Type	Length	value…

Type指示了Atribute的类型，通用的有几十种，如表4所示。

Type	说明	Type	说明
1	User-Name	5	NAS-Port-Id
2	Password	6	Service-Type
3	CHAP-Password	7	Framed-Protocol
4	NAS-IP-Address	…	…

数据包类型

RADIUS数据包的类型由其Code域（头8位）指定。

· Access-Request（接入-请求）

“Access-Request”数据包由NAS发出，由RADIUS服务器接收。

其中的“User-Password”或“CHAP-Password”属性值被默认地以MD5方法加密。

数据包结构如表5所示。

8位	8位	16位
Code＝1	Identifier-随着Attributes的Value变化而变化，重传时则保持不变	Length
Authenticator（128位）—根据Identifier变化而变化
Attributes…（不定长）

Attributes应该包括以下几个属性：

◆ “User-Name”

◆ “User-Password”或“CHAP-Password”

◆ “NAS-IP-Address”

* “NAS-Identifier”

◆ “NAS-Port”

◆ “NAS-Port-Type”

· Access-Accept

“Access-Accept” 由RADIUS服务器发出，返回给NAS。表示用户的信息是合法的。其中包括了必要的配置信息，以便下一步为用户提供服务。数据包结构如表6所示。

8位	8位	16位
Code＝2	Identifier-和“Access－Request”的Identifier相同	Length
Authenticator(128位)－属于Response Authenticator，由公式1计算得到
Attributes…（不定长）

Access-Reject“Access-Reject”由RADIUS服务器发出，返回给NAS。表示用户的信息是非法的。其中应该包括一个或多个的“Reply-Message”（回复消息，包含一些便于NAS返回给用户的一些错误信息）。数据包结构如表7所示。

8位	8位	16位
Code＝3	Identifier－和“Access－Request”的Identifier相同	Length
Authenticator（128位）－属于Response的Authenticator，由公式1计算得到
Attributes…（不定长）

属性

属性如表8所示。其中，Length的计算方法为：Type+Length+Value。

8位	8位	不定长（0或多个字节）
Type	Length	Value…

Value有4种类型：

◆ String —— 0~253字节，字符串

◆ Ipaddress —— 32位，IP地址

◆ Integer —— 32位，整数

◆ Time —— 32位，从00:00:00 GMT, January 1, 1970到当前的总秒数

从这里可看出，RADIUS协议是一个不定长的协议栈。

二、关于freeradius

支持的平台：Linux, FreeBSD, OpenBSD, OSF/Unix, and Solaris

安装配置过程见文档《freeradius服务器的架设》和《安装笔记》

认证测试也计费说明见《freeradius数据库说明》

三、附录一些相关解释

CHAP

质询握手身份验证协议 (CHAP) 是一种质询/响应身份验证协议，它使用作为行业标准的消息摘要 5 (MD5) 哈希方案对响应进行加密。CHAP 被各种网络访问服务器和客户端供应商广为采用。运行路由和远程访问的服务器支持 CHAP，以便能够对要求使用 CHAP 的远程访问客户端进行身份验证。CHAP 要求使用可逆加密的密码。

PAP

密码身份验证协议 (PAP) 使用明文密码，它是安全性最差的身份验证协议。如果远程访问客户端和远程访问服务器不能协商一种更安全的验证形式，则通常商定使用它。

EAP-TLS
　　EAP-TLS既提供认证，又提供动态会话钥匙分发。EAP-TLS认证机制是在无线客户端和服务器之间提供互相认证。所有的无线客户端以及服务器都需要事先申请一个标准的X.509证书并安装，在认证的时候客户端和服务器要相互交换证书。在交换证书的同时，客户端和服务器要协商出一个基于会话的钥匙，一旦认证通过，服务器将会话钥匙传给客户端并通知无线访问点允许该客户端使用网络服务。

EAP-MD5
　　该功能通过Radius服务器提供简单的集中用户认证。在这种方式下，Radius服务器不需要证书或者安装在无线工作站中的其它安全信息。用户注册时，Radius服务器只是检查用户名和口令，如果匹配，就通知无线访问点允许该客户端访问网络服务。

EAP-MD5是一种单向认证机制，只能保证客户端到服务器的认证，并不保证服务器到客户端的认证。