转自http://blog.csdn.net/twingao/archive/2006/08/05/1024207.aspx
Network Working Group C. Rigney
Request for Comments: 2865 S. Willens
Obsoletes: 2138 Livingston
Category: Standards Track A. Rubens
Merit
W. Simpson
Daydreamer
June 2000
远程认证拨号用户服务（RADIUS）
备忘录状态
本文档描述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行
讨论和建议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来
获得本协议的标准化程度和状态。本备忘录可以不受限制地传播。
版权说明
Copyright (C) The Internet Society (2000). All Rights Reserved.
IESG说明:
本协议已经被广泛实现和使用，经验表明当本协议在一个大范围的系统中使用
会降低性能和丢失数据。部分原因是协议中没有提供拥塞控制的机制。读者可
以发现阅读本文对跟踪IETF组织的AAA工作组的工作进程有很大的帮助，AAA工
作组可能会开发一个能够更好的解决扩展性和拥塞控制问题的成功的协议。
摘要
本文描述了一个传输认证、授权和配置信息的协议。这些信息在想要认证链路
的网络接入服务器（Network Access Server）和共享的认证服务器务器之间传
递。
实现说明
本备忘录记录了RADIUS协议，RADIUS协议的早期版本使用的UDP端口是1645，由
于和"datametrics"服务冲突，官方为RADIUS协议分配了一个新的端口号1812。
Rigney, et al. Standards Track [Page 1]
RFC 2865 RADIUS June 2000
目录
1. 简介 .................................................. 3
1.1 描述文档的约定 .................................. 4
1.2 术语 ............................................ 5
2. 操作 .................................................. 5
2.1 挑战/回应 ....................................... 7
2.2 使用PAP和CHAP互操作 ............................. 8
2.3 代理 ............................................ 8
2.4 为什么使用UDP ................................... 11
2.5 重发提醒 ........................................ 12
2.6 被证明是有害的心跳 .............................. 13
3. 报文格式 .............................................. 13
4. 报文类型 .............................................. 17
4.1 接入请求报文 .................................... 17
4.2 接入成功回应报文 ................................ 18
4.3 接入拒绝回应报文 ................................ 20
4.4 接入挑战报文 .................................... 21
5. 属性 .................................................. 22
5.1 User-Name ....................................... 26
5.2 User-Password ................................... 27
5.3 CHAP-Password ................................... 28
5.4 NAS-IP-Address .................................. 29
5.5 NAS-Port ........................................ 30
5.6 Service-Type .................................... 31
5.7 Framed-Protocol ................................. 33
5.8 Framed-IP-Address ............................... 34
5.9 Framed-IP-Netmask ............................... 34
5.10 Framed-Routing .................................. 35
5.11 Filter-Id ....................................... 36
5.12 Framed-MTU ...................................... 37
5.13 Framed-Compression .............................. 37
5.14 Login-IP-Host ................................... 38
5.15 Login-Service ................................... 39
5.16 Login-TCP-Port .................................. 40
5.17 (unassigned) .................................... 41
5.18 Reply-Message ................................... 41
5.19 Callback-Number ................................. 42
5.20 Callback-Id ..................................... 42
5.21 (unassigned) .................................... 43
5.22 Framed-Route .................................... 43
5.23 Framed-IPX-Network .............................. 44
5.24 State ........................................... 45
5.25 Class ........................................... 46
5.26 Vendor-Specific ................................. 47
5.27 Session-Timeout ................................. 48
5.28 Idle-Timeout .................................... 49
5.29 Termination-Action .............................. 49
Rigney, et al. Standards Track [Page 2]
RFC 2865 RADIUS June 2000
5.30 Called-Station-Id ............................... 50
5.31 Calling-Station-Id .............................. 51
5.32 NAS-Identifier .................................. 52
5.33 Proxy-State ..................................... 53
5.34 Login-LAT-Service ............................... 54
5.35 Login-LAT-Node .................................. 55
5.36 Login-LAT-Group ................................. 56
5.37 Framed-AppleTalk-Link ........................... 57
5.38 Framed-AppleTalk-Network ........................ 58
5.39 Framed-AppleTalk-Zone ........................... 58
5.40 CHAP-Challenge .................................. 59
5.41 NAS-Port-Type ................................... 60
5.42 Port-Limit ...................................... 61
5.43 Login-LAT-Port .................................. 62
5.44 Table of Attributes ............................. 63
6. IANA注意事项 .......................................... 64
6.1 术语定义 ........................................ 64
6.2 推荐的注册策略 .................................. 65
7. 举例 .................................................. 66
7.1 用户Telnet到指定主机上 .......................... 66
7.2 用户使用CHAP认证方式认证 ........................ 67
7.3 用户使用挑战-回应卡 ............................. 68
8. 安全事项 .............................................. 71
9. 更新记录 .............................................. 71
10. 参考文献 .............................................. 73
11. 致谢 .................................................. 74
12. AAA工作组主席地址 ..................................... 74
13. 作者地址 .............................................. 75
14. 版权声明 .............................................. 76
1. 简介
本文档废弃了RFC 2138 [1]。它与RFC 2138之间的差别可以在附录“更新记
录”中找到。
要经营为众多的用户提供的串口线路和modem池，这会带来巨大的管理支持方面
的需求。由于modem池是通向外部的链路，因此它对安全、认证、计费都提出了
很高的要求。可以通过维护一个用户数据库来实现该需求，该数据库包含了认
证（验证用户的名字和密码）以及为用户提供的服务类型的详细的配置信息
（如SLIP、PPP、telnet和rlogin等）。
Rigney, et al. Standards Track [Page 3]
RFC 2865 RADIUS June 2000
RADIUS协议的主要特性如下：
客户/服务器模式
网络接入服务器(NAS)是RADIUS的客户端。客户端负责将用户信息传递给指
定的RADIUS服务器，然后处理RADIUS服务器的回应。
RADIUS服务器负责接收用户的连接请求，认证该用户，然后给客户端返回能
够给用户提供服务的所有必要的配置信息。
RADIUS服务器可以作为其它RADIUS服务器或者其他类型的认证服务器的代理
客户端。
网络安全
客户端与RADIUS服务器之间的交互是通过共享密钥来进行相互认证的，共享
密钥不会通过网络传送。另外，为了减少在不安全的网络中侦听到用户密码
的可能性，在客户端和RADIUS服务器之间传送的密码都是加密的。
弹性的认证机制
RADIUS服务器能够支持多种认证用户的方式，如果用户提供了用户名和用户
密码的明文，RADIUS协议能够支持PPP PAP或者CHAP、UNIX login以及其它
的认证方式。
协议扩充性
所有的交互报文由多个不同长度的Attribute-Length-Value三元组组
成，新属性值的加入不会破坏到协议的原有实现。
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要求，那么该实现和本协议是有条件兼容。
Rigney, et al. Standards Track [Page 4]
RFC 2865 RADIUS June 2000
不支持某个特定服务的NAS一定不要（MUST NOT）支持该服务的RADIUS属性，例
如：不能提供ARAP服务的NAS一定不要（MUST NOT）支持ARAP服务的RADIUS属
性，对于授权不支持的服务的接入成功回应报文，NAS必须将之做为接入拒绝回
应报文一样处理。
1.2. 术语
本文使用了以下的术语：
服务 NAS为拨入用户提供的某种服务，如：PPP或者Telnet。
会话 NAS为拨入用户提供的每一个服务都会建立一个会话。第一次开始提
供服务做为会话的开始，服务终止做为会话的结束。如果NAS支持的
话，一个用户可以有多个并行或者串行的会话。
静默丢弃
应用程序不对包进行任何处理就直接丢弃。应用程序应该
（SHOULD）有提供记录错误的能力，其中包括被静默丢弃的包的内
容，而且应用程序应该（SHOULD）在一个统计计数器中记录下该事
件。
2. 操作
当一个客户端被配置成采用RADIUS协议时，客户端的任何用户提交认证信息给
客户端。当用户想输入他们的用户名和密码时，客户端可以给出定制化的登陆
提示信息。或者，用户可以使用一种如PPP协议的链路协议，这些协议有能够携
带这些信息的认证报文。
一旦客户端获得这些信息，可能会选择使用RADIUS协议进行认证，为了这样
做，客户端生成一个包含用户名，用户密码，客户端的ID号，以及用户接入的
端口号ID属性的接入请求报文。当提供用户密码时，用户密码都被用MD5算法隐
藏起来。
Rigney, et al. Standards Track [Page 5]
RFC 2865 RADIUS June 2000
通过网络将接入请求报文提交给RADIUS服务器，如果在一定长的时间内没有回
应，请求报文将被重复发送几次。如果主服务器一旦宕机或者不可达，客户端也可
以将请求报文转发给备用的一个或者多个服务器。在多次重试都发现主服务器
失败，备用服务器可以被启用，当然也可以使用循环（round-robin）的方式。
重试和放弃算法是目前正在研究的一个课题，在本文中就不再赘述了。
一旦RADIUS服务器接收到请求报文，服务器将验证发送请求报文的客户端的有
效性，一个在RADIUS服务器中没有共享密钥的客户端请求必须（MUST）被静默
丢弃。如果客户端是有效的，RADIUS从用户数据库中查找是否有和请求匹配的
用户。数据库中的用户记录中包含了一系列必须满足的允许接入用户的要求。
这些要求始终包含密码，但也可能包含用户允许被接入的特定客户端和端口
号。
RADIUS服务器为了满足请求也可以（MAY）向其他服务器发起请求。在这种情况
下，它是做为客户端的。
如果有任何Proxy-State属性在接入请求报文中出现，这些属性必须（MUST）原
封不动地按顺序拷贝到回应报文中。其它属性可以被置于Proxy-State属性的前
面，后面，甚至中间。
如果任何条件没有被满足，RADIUS服务器将发送接入拒绝回应报文以表明用户
的请求是无效的。如果需要的话，服务器可以（MAY）在接入拒绝回应报文中包
含一个文本信息，这个信息可以（MAY）被客户端显示给用户。除了
Proxy-State属性外，其它属性不能出现在接入拒绝回应报文中。
如果所有的条件都被满足，而RADIUS服务器想要发送一个用户必须（must）回
应的挑战，RADIUS服务器将发送一个接入挑战报文，该报文可以（MAY）包含一
条客户端显示给用户的文本信息，这个信息提示用户对挑战做出回应。该报文
也可以（MAY）包含一个State属性。
如果客户端接收到一个接入挑战报文，并且支持挑战/回应认证方式，如果有的
话，客户端可以给用户提示文本信息，提示用户回应。然后客户端使用新的请
求ID重新提交最初的接入请求报文，并且携带上被回应替换的User-Password属
性（被加密的），并且包含从接入挑战报文中获得的State属性，如果有的话，
State属性在请求报文中只应该（SHOULD）出现零次或者1次。对于新的接入请
求报文，服务器可能回应接入成功回应报文，接入拒绝回应报文或者接入挑战
报文。
Rigney, et al. Standards Track [Page 6]
RFC 2865 RADIUS June 2000
如果所有的条件都满足，一系列的用户配置信息将被放入到接入成功回应报文
中，这些值包含了服务类型（如：SLIP，PPP或者Login User）和提供服务所有
必需的值。对于SLIP和PPP服务来说，可能包含IP地址，子网掩码，MTU，想要
的压缩算法，想要的报文过滤标识符。对于字符模式的用户，可能包含想要的
协议和主机。
2.1. 挑战/回应
在挑战/回应认证方式下，给用户下发一个不可预测的数字，挑战用户加密该数
字，然后传回结果，能够被认证的用户往往配备了特别的设备，如能够很容易
计算出正确回应的智能卡或软件。不能被认证的用户，往往缺乏合适的设备或
者软件，并且也缺少必要的密钥而不能仿造出设备或者软件，而只能靠猜测来
回应。
接入挑战报文通常携带有一个需要显示给用户的挑战字符串，该挑战字符串包
含在Reply-Message属性中，如一个永远不可能重复的数字。通常，该数字是从
外部服务器获得，这个服务器知道认证用户的认证类型，因此可以根据合适的
基数和长度选择一个随机或者不可重复伪随机数。
然后用户将这个挑战字输入到能够计算出回应的设备（或者软件）中，然后将
计算出的回应传到客户端中，客户端将之通过第二个接入请求报文转发给
RADIUS服务器，如果该回应和服务器想要的回应相匹配，RADIUS服务器就返回
一个接入成功回应报文，否则，就返回一个接入拒绝回应报文。
例如：NAS给RADIUS服务器发送了一个携带NAS-Identifier，NAS-Port，
User-Name和User-Password（可能只是一个固定字符串"challenge"或者不携
带）属性的接入请求报文，服务器回应一个携带State和Reply-Message属性的
接入挑战报文，Reply-Message属性包含字符串"Challenge 12345678, enter
your response at the prompt"，这个字符串由NAS上显示，NAS接收到回应，
向服务器发送一个新的携带NAS-Identifier，NAS-Port，User-Name，
User-Password（正是用户输入的用户密码，已经被加密）以及被接入挑战报文
带来的State属性的接入请求报文，服务器判断回应是否和想要的回应相匹配，
然后返回接入成功回应报文或者接入拒绝回应报文。或者甚至再发送一个接入
挑战报文。
Rigney, et al. Standards Track [Page 7]
RFC 2865 RADIUS June 2000
2.2. 使用PAP和CHAP互操作
对于PAP认证方式，NAS获得PAP ID和密码，然后将它们做为接入请求报文中的
User-Name和User-Password属性发送出去。NAS可以（MAY）包含值为
Framed-User的Service-Type属性和值为PPP的Framed-Protocol属性，以提示
RADIUS服务器用户需要PPP服务。
对于CHAP认证方式，NAS生成一个随机挑战字（16个字节比较合适）并发送给用
户，用户回应一个携带CHAP ID和CHAP用户名的CHAP回应。NAS然后向RADIUS服
务器发送一个接入请求报文，该请求报文将CHAP用户名做为User-Name属性，
CHAP ID和CHAP回应做为CHAP-Password属性。随机挑战字可以包含在
CHAP-Challenge属性中，或者如果是16个字节长度的话，它可以放在接入请求
报文的Request Authenticator域中。NAS可以（MAY）包含值为Framed-User的
Service-Type属性和值为PPP的Framed-Protocol属性，以提示RADIUS服务器用
户需要PPP服务。
RADIUS根据User-Name属性查找到用户密码，对CHAP ID字节，密码和CHAP挑战
字（如果CHAP-Challenge属性存在，该该属性取值，否则从Request
Authenticator域取值）进行MD5加密获得挑战字，然后将加密结果和
CHAP-Password属性比较，如果匹配，服务器发送回接入成功回应报文，否则发
送回接入拒绝回应报文。
如果RADIUS服务器不能完成请求的认证过程，必须（MUST）返回接入拒绝回应
报文，例如：CHAP认证方式需要用户的密码在服务端是可以明文存放的，因为
它需要加密CHAP挑战字然后同CHAP回应比较，如果在服务端不能获取明文的用
户密码，服务器必须（MUST）给客户端发送接入拒绝回应报文。
2.3. 代理
在代理RADIUS下，一个RADIUS服务器从RADIUS客户端（如NAS）接到一个认证
（或计费）请求时，将该请求转发给远程RADIUS服务器，接收到远程服务器的
回应以后，然后将该回应发送回客户端。代理机制反映了本地管理策略的变化。代
理RADIUS的常用的用途是漫游，漫游允许两个或者更多的管理实体允许彼此
的用户在另一个实体网络中拨号登陆。
Rigney, et al. Standards Track [Page 8]
RFC 2865 RADIUS June 2000
NAS向“转发服务器”发送RADIUS接入请求报文，该服务器将报文转发到“远程
服务器”，远程服务器发送回应报文（接入成功回应报文，接入拒绝回应报文
或者接入挑战报文）给转发服务器，转发服务再将报文发送回NAS。为方便
RADIUS代理操作，User-Name属性可以（MAY）包含一个网络接入标识[8]。哪个
远程服务器将接收到转发的报文应该（SHOULD）取决于认证“域”的选择，认
证域可以（MAY）是网络接入标识（一个命名的域）的一个部分。做为另一选
择，哪个服务器将接收到转发的报文也可以（MAY）取决于转发服务器的配置，
例如Called-Station-Id属性（一个数字化的域）。
一个RADIUS服务器既可以做转发服务器，也可以做远程服务器，对于其中一些
域，它做为转发服务器，对另外一些域，它做为远程服务器。一个转发服务器
可以做为任意个数的远程服务器的转发器，一个远程服务器可以有任意个数的
转发服务器给它转发报文，也可以为任意个数的域提供认证。一个转发服务器
可以将报文转发给另一个转发服务器，形成一个代理链，但是需要小心避免形
成循环转发。
下面场景阐述了NAS、转发服务器以及远程服务器之间的代理通讯机制：
1. NAS发送接入请求报文给转发服务器。
2.转发服务器将接入请求报文转发给远程服务器。
3.远程服务器回应接入成功回应报文，接入拒绝回应报文或者接入挑战报文给
转发服务器，例如，回应接入成功回应报文。
4.转发服务器将接入成功回应报文发送回NAS。
转发服务器必须（MUST）将已经在报文中的Proxy-State属性做不透明处理（不
需要理解它们）。它的操作必须不能（MUST NOT）依赖于由前一个服务器增加
的Proxy-State属性的内容。
如果从客户端接收到的请求报文中有任何Proxy-State属性，转发服务器在回应
给客户端时必须（MUST）包含这些Proxy-State属性，当转发接入请求报文时，
转发服务器可以（MAY）在请求报文中包含Proxy-State属性，或者也可以
（MAY）在转发请求报文时删除它们，如果转发服务器在转发接入请求报文时删
除了Proxy-State属性，那么在回应给客户端之前必须（MUST）重新携带这些
Proxy-State属性。
Rigney, et al. Standards Track [Page 9]
RFC 2865 RADIUS June 2000
现在我们阐述以下每一步骤的细节：
1. NAS发送接入请求报文给转发服务器，如果存在User-Password属性的话，转
发服务器使用已经知道的该NAS的共享密钥解密它，如果报文中有
CHAP-Password属性但没有CHAP-Challenge属性，转发服务器必须（MUST）
不能修改Request Authenticator域，或者将之拷贝到CHAP-Challenge属
性中。
'' 转发服务器可以（MAY）增加一个Proxy-State属性到报文中（一定不能
（MUST NOT）超过一个），如果要增加Proxy-State属性，增加的
Proxy-State属性必须（MUST）出现所有其它Proxy-State属性的最后面。转
发服务器一定不能（MUST NOT）改动任何已经存在于报文中的Proxy-State
属性（可以（may）选择不转发它们，但一定不能（MUST NOT）修改它们的内
容）。转发服务器一定不要（MUST NOT）改动任何相同类型的属性顺序，包
括Proxy-State属性。
2. 如果User-Password属性存在的话，转发服务器需要使用远程服务器的共享
密钥加密User-Password属性，如果必要的话，重新设置Identifier域，然后
将接入请求报文转发到远程服务器。
3. 远程服务器（如果是最终的目的地）使用User-Password，CHAP-Password属
性，或者使用其他将来扩展的认证方式验证用户。然后回应接入成功回应报
文，接入拒绝回应报文或者接入挑战报文给转发服务器。例如，回应一个接
入成功回应报文。远程服务器必须（MUST）按顺序将所有的Proxy-State属
性（只有Proxy-State属性）从接入请求报文中拷贝到回应报文中，而且不
能改动它们。
4. 转发服务器使用远程服务器的共享密钥验证Response Authenticator域，如
果验证失败就静默丢弃该报文，如果报文验证被通过，转发服务器移去最后
一个Proxy-State属性（如果转发服务器曾经增加过该属性），使用和NAS共享
密钥生成Response Authenticator域，恢复和NAS的原始请求报文匹配的
Identifier域，然后将接入成功回应报文发送回NAS。
为了强制使用本地策略，转发服务器可能（MAY）需要修改属性，该策略已经超
出本文说明的范围，但以下的限制需要说明，转发服务器一定不能（MUST
not）改动已经在报文中存在的Proxy-State，State或者Class属性。
Rigney, et al. Standards Track [Page 10]
RFC 2865 RADIUS June 2000
转发服务器的实现应该（should）认真考虑哪个Service-Type属性值可以接
受，必须（must）认真考虑在被代理的接入请求报文中的Service-Type，
NAS-Prompt或者Administrative属性的影响，转发服务器的实现也可以（may）
提供机制阻止这些属性或者其它的服务类型或者其它的属性转发，但该机制超
出了本文说明的范围。
2.4. 为什么使用UDP?
一个经常被问到的问题是为什么使用UDP而不是TCP做为传输协议，选择UDP是基
于以下严格的技术理由：
有许多观点必须（must）要理解，RADIUS是一个基于有几个有趣的特性的协议
的交互过程：
1. 如果请求的主认证服务器失败了，备服务器必须（must）能够被找到。
为了满足该需求，在传输层之上必须（must）保存一份请求的拷贝以可以选
择发送。这意味也需要一个重传定时器。
2. 这个特殊协议的定时需求和TCP提供的定时机制有明显的不同。
举一个极端的例子，RADIUS不需要数据丢失的检测，用户愿意为认证完成等
待几秒钟。强悍的TCP的重传（基于平均的回环时间）是不需要的，既然TCP
重传太耗时间。
另一个极端的例子，用户不会愿意为认证等待上几分钟，因此TCP的可靠传
输机制在两分钟后是没有用的，更快的启用备用服务器允许用户在（不耐烦
而）放弃之前就获得接入。
3. 本协议的无状态的特性简化了UDP的使用
客户端和服务器存在还是不存在，系统被重启。这些都不会产生超时机制和
TCP连接丢失的检测问题，而通常都需要写大量代码处理这些异常事件。UDP
则完全消除了这些特殊处理。（每一个客户端和服务器能够只打开一次UDP传
输并且让网络中的所有类型的失败事件通过。）
Rigney, et al. Standards Track [Page 11]
RFC 2865 RADIUS June 2000
4. UDP简化了服务器的实现
在最早的RADIUS实现中，服务器是单线程的，这意味着，同时只可以接收，
处理然后返回一个请求。后来发现后台的想要做到实时（1秒或者多秒）处
理是难以实现的，当每一分钟都有成百的用户需要认证的时候，服务端的请
求队列会被填满。请求到回应之间的时间会增长到用户无法忍受的地步（当
在数据库中查询或者DNS耗费了30秒或者更多的秒时，这种情况会变得更加
严重）。一种最明显的解决方案就是服务器支持多线程，多线程这一点对于
UDP来说实现起来很简单，每个请求都有单独的处理线程，处理线程能够使
用UDP报文直接回应给客户端NAS。
这当然不是万能药，众所周知，使用UDP协议时，需要做一件已经内置到TCP协
议中的事：我们必须人工管理到同一服务器的重传定时器。尽管使用TCP协议不
需要对定时器有相同的关注。在本协议中这一缺点相对于使用UDP的优势来说只
是一个小的代价。
如果没有TCP协议，我们可能仍然在用锡罐传递信息，但对于本协议，UDP是更好的
选择。
2.5. 重传提示
如果RADIUS服务器和备用RADIUS服务器使用相同的共享密钥，那么转发给备用
RADIUS服务器的报文可以使用相同的ID和Request Authenticator域，因为属性
的内容没有改变。如果您想往备用服务器发送的报文使用新的Request
Authenticator域，您也可以改变。
如果您改变了User-Password属性（或者任何其它的属性）的内容，您需要一个
新的Request Authenticator域，当然因此需要一个新的ID。
如果NAS向相同的服务器重传RADIUS请求报文，这些属性都没有变化，您必须
（MUST）使用相同的Request Authenticator和ID域，使用相同的源端口号。如
果有任何属性变化了，您必须（MUST）使用一个新的Request Authenticator和
ID域。
对于所有的服务器，NAS可以（MAY）使用相同的ID，或者可以（MAY）对于每个
服务器使用独立的ID序列。这要看具体的实现。如果NAS需要为请求报文使用超
过256个ID，则NAS可以（MAY）使用其它端口号发送请求，这样每个源端口号都
可以保持一个ID序列。这样，对于一个服务器，同时可以有1600万请求报文。
Rigney, et al. Standards Track [Page 12]
RFC 2865 RADIUS June 2000
2.6. 被证明是有害的心跳
一些实现采用发送测试RADIUS请求报文的方式检查服务器是否有效。强烈质疑
这种方式，它增加了负载而且不能提供任何额外的有用的信息，既然RADIUS请
求报文包含在一个数据包，在这个时间段，你可以发送一个ping报，但您只发
送了一个RADIUS请求报文，获得了一个表明RADIUS服务器是有效的回应，但是
如果您没有RADIUS请求需要发送，那么服务器是有效的还是无效的根本不是一
个问题，因为您根本就没有用它。
如果你想监控您的RADIUS服务器，请使用SNMP协议，这时SNMP的工作。
3. 报文格式
准确地讲，RADIUS报文是封装在UDP报文的数据域[4]中的，它的UDP目的端口号
是1812（十进制数）。
当产生一个回应的时候，源端口和目的端口互换。
本文定义了RADIUS协议。早期的RADIUS计费协议使用UDP端口1645，由于它和著
名的"datametrics"服务相冲突。官方为RADIUS计费协议重新分配的端口号是
1812。
Rigney, et al. Standards Track [Page 13]
RFC 2865 RADIUS June 2000
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
代码
Code域占位一个字节，它用来标识RADIUS报文类型。当收到的报文的代码域
非法时，该报文将会被静默丢弃。
RADIUS计费报文Code域（十进制）分配如下：
1 接入请求报文
2 接入成功回应报文
3 接入拒绝回应报文
4 计费请求报文
5 计费回应报文
11 接入挑战报文
12 服务器状态报文（试验）
13 客户端状态报文（试验）
255 保留
代码4和5在RADIUS计费文档[5]中说明，代码12和13为可能的使用预留，但本文
不做进一步讨论。
标识符
Identifier域占位一个字节，用于匹配请求和回应报文。如果在一个很短的
时间内接收到相同的源IP地址、源UDP端口号和相同的Identifier域的请求
报文，RADIUS服务器就可以认为是重复的请求报文。
Rigney, et al. Standards Track [Page 14]
RFC 2865 RADIUS June 2000
长度
长度域占位两个字节。它包含了报文中的Code域，Identifier域，Length
域，Authenticator域和属性域的总长度。在长度域限定的范围之外的字节
必须（MUST）作为填充字节，在接收到时不予处理。如果包的实际长度小于
长度域中给出的值，该包必须（MUST）被静默丢弃。报文的最小长度是20，
最大长度是4096。
认证字
Authenticator域占位16个字节。最重要的字节先传输。该域的值用来鉴别
服务器的回应报文，并且用在用户密码的隐藏算法中。
请求认证字
在接入请求报文中，认证字的值是一个占位16个字节随机数，称作请求
认证字。该值在共享密钥（客户端和服务器的共享密钥）的生命周期中
应该（SHOULD）是不可预测的和唯一的。否则在同一密钥下，重复的请
求报文将使攻击者能够使用以前截获的回应报文回应。既然可以想像得
到在不同的地理区域可以（MAY）使用相同的共享密钥认证。那么，请求
认证字域应该（SHOULD）在全球范围内唯一。
在接入请求报文中的Request Authenticator域的值也应该（SHOULD）是
不可预测的，以免攻击者可以欺骗服务器，让服务器响应一个预计的挑战
值，然后用该响应冒充服务器欺骗后续的接入请求。
尽管RADIUS协议没有能力阻止通过实时的主动搭线攻击窃听认证会话，
然而生成唯一的和不可预知请求报文就能够防范大多数的主动攻击。
NAS和RADIUS服务器共享一个密钥，该共享密钥被加在请求认证字域后
面，然后对之使用MD5算法生成一个16字节的摘要，将该摘要和用户输入
的密钥进行异或，然后将异或结果放入接入请求报文的User-Password属
性中，请参考属性章节中关于User-Password属性的条目以了解更详细的
信息。
Rigney, et al. Standards Track [Page 15]
RFC 2865 RADIUS June 2000
回应认证字
在接入成功回应报文，接入拒绝回应报文和接入挑战报文中的认证字域
的值称作回应认证字。包含对如下字段组成的字节流的MD5加密的摘要信
息：从代码域开始，包含标识符域，长度域，接入请求报文中的请求认
证字域和回应报文中的属性，然后后面加上共享密钥。即ResponseAuth
= MD5(Code+ID+Length+RequestAuth+Attributes+Secret)，这里+表示
连接。
管理提示
共享密钥（在客户端和RADIUS服务器之间的共享密钥）的长度应该
（SHOULD）至少大到不可能猜测的程度。推荐的共享密钥应该至少16个字
节。这样才会有总够大的密钥范围以阻止穷举攻击。密钥必须不能（MUST
NOT）是空的，因为这样报文很容易被伪造。
RADIUS服务器必须（MUST）根据RADIUS的UDP报文的源IP地址决定使用那个
共享密钥，因此，RADIUS请求才可以被代理。
当使用转发代理时，代理必须（must）能够在报文通过的每个方向上更改报
文。当代理转发请求报文时，代理可以（MAY）增加Proxy-State属性，当代
理转发回应报文时，代理必须（MUST）移除它增加的Proxy-State属性（如
果它曾经增加过）。Proxy-State属性总是在其它的Proxy-State属性后增加
或者移除，没有其它关于该属性在属性列表中位置的要求。由于是基于整个
报文内容鉴别接入成功回应报文和接入拒绝回应报文的，Proxy-State属性
的变化会使得原来的签名无效，因此代理不得不重新签名。
RADIUS代理实现的进一步的详细信息超出了本文描述的范围。
Rigney, et al. Standards Track [Page 16]
RFC 2865 RADIUS June 2000
4. 报文类型
RADIUS报文类型由在报文中第一个字节中的代码域决定。
4.1. 接入请求报文
描述
接入请求报文被发送给RADIUS服务器，报文携带了决定是否允许用户接入指
定NAS的信息，还包含该用户需要使用的服务的信息。一个RADIUS实现想要
认证用户，那么必须（MUST）发送一个代码域值置为1的RADIUS报文。
一旦从一个有效的客户端接受到接入请求报文，必须（MUST）要有一个合适
的回应报文被发送回。
一个接入请求报文应该（SHOULD）包含User-Name属性，它必须包含
NAS-IP-Address或者NAS-Identifier属性（或者两者都包含）。
一个接入请求报文必须（MUST）包含User-Password，CHAP-Password或者
State属性。一个接入请求报文必须不能（MUST NOT）同时包含
User-Password和CHAP-Password属性。如果将来的扩展允许携带其它类型的
认证信息，扩展的属性可以替代接入请求报文中的User-Password和
CHAP-Password属性。
一个接入请求报文应该（SHOULD）包含NAS-Port或者NAS-Port-Type属性，
或者两者都包含，除非被请求的接入类型不涉及端口或者NAS不区分端口。
一个接入请求报文可以（MAY）包含额外的属性做为对服务器的提示，但服务器
不需要一定处理该提示。
当User-Password属性存在时，会采用基于MD5 [3]算法的方法将该属性值隐藏
起来。
Rigney, et al. Standards Track [Page 17]
RFC 2865 RADIUS June 2000
接入请求报文格式如下所示。各个域是自左向右传输的。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
代码
1 代表接入请求报文
标识符
当属性域的内容变化时，或者接收到前一个请求的有效回应时，Identifier
域必须（MUST）改变。当报文重发时，Identifier域必须（MUST）保持不
变。
请求认证字
每当使用新的标识符域时，请求认证字域的值必须（MUST）改变。
属性
属性域的长度是变化的，包含了请求服务类型所需要的属性列表，也
包含了任何想要的可选属性。
4.2. 接入成功回应报文
描述
接入成功回应报文是由RADIUS服务器发送的，提供了开始给用户提供服务的
特定的配置信息。如果接收到的接入请求报文的所有属性都是可以接受的，那
么RADIUS实现必须（MUST）发送一个代码域值为2的报文（接入成功回应报
文）。
Rigney, et al. Standards Track [Page 18]
RFC 2865 RADIUS June 2000
客户端接收到接入成功回应报文后，标识符域应该和一个等待回应的接入请
求报文的相应域匹配。回应认证字域必须（MUST）包含对等待回应的接入请
求报文的正确回应，无效的报文将被静默丢弃。
接入成功回应报文格式如下所示。各个域是自左向右传输的。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
代码
2 代表接入成功回应报文
标识符
标识符域是对引起这次回应的接入请求报文的标识符域的一个拷贝。
回应认证字
回应认证字的值根据接入请求报文计算得来，已经在前面描述过了。
属性
Attributes域的长度是变化的，其中包含了零个或者多个属性。
Rigney, et al. Standards Track [Page 19]
RFC 2865 RADIUS June 2000
4.3. 接入拒绝回应报文
描述
如果接收到的任何属性不可接受，RADIUS服务必须（MUST）发送一个代码域
值为2的报文（接入拒绝回应报文）。该报文包含一个或者多个
Reply-Message属性，该属性包含了一个文本消息，它可以（MAY）由NAS显
示给用户。
接入拒绝回应报文格式如下所示。各个域是自左向右传输的。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
代码
3 代表接入拒绝回应报文
标识符
标识符域是对引起这次回应的接入请求报文的标识符域的一个拷贝。
回应认证字
回应认证字域的值根据接入请求报文计算得来，已经在前面描述过了。
属性
属性域的长度是变化的，其中包含了零个或者多个属性。
Rigney, et al. Standards Track [Page 20]
RFC 2865 RADIUS June 2000
4.4. 接入挑战报文
描述
如果RADIUS服务器想要给用户发送一个挑战，要求用户回应，那么RADIUS服
务器必须（MUST）回应一个代码域值为11的报文（接入挑战报文）。
属性域中可以（MAY）有一个或者多个Reply-Message属性，可以（MAY）有
一个或者0个State属性，Vendor-Specific，Idle-Timeout，
Session-Timeout和Proxy-State属性也可以（MAY）包含。本文中不允许接
入挑战报文包含其它任何属性。
客户端接收到接入挑战报文后，标识符域应该和一个等待回应的接入请求报
文的标识符域匹配。另外，回应认证字域必须（MUST）包含对等待回应的接入
请求报文的正确回应，无效的报文将被静默丢弃。
如果NAS不支持挑战/回应认证方式，NAS必须（MUST）将接入挑战报文做为
接入拒绝回应报文对待。
如果NAS支持挑战/回应认证方式，接收到一个有效的接入挑战报文表示应该
（SHOULD）发送一个新的接入请求报文了。如果有文本消息，NAS可以
（MAY）显示给用户，并等待用户回应，然后NAS发送原来的接入请求报文，
该报文携带了新的请求ID，新的请求认证字，User-Password属性被用户的
回应替换（加密的），也包含了接入挑战报文中的State属性（如果有的
话），但只能有0个或者1个State属性包含在接入请求报文中。
（支持PAP认证方式的NAS可以（MAY）转发Reply-Message属性给拨号客户端
然后接受一个PAP回应，好像是用户输入的回应一样）。如果NAS不支持这种
方式，NAS必须（MUST）将接入挑战报文做为接入拒绝回应报文对待。
Rigney, et al. Standards Track [Page 21]
RFC 2865 RADIUS June 2000
接入挑战报文格式如下所示。各个域是自左向右传输的。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
代码
11 代表接入挑战报文
标识符
标识符域是对引起这次回应的接入请求报文的标识符域的一个拷贝。
回应认证字
回应认证字域的值根据接入请求报文计算得来，已经在前面描述过了。
属性
Attributes域的长度是变化的，其中包含了零个或者多个属性。
