rfc2869.txt

很多RFC的中文文档

Network Working Group                                           C. Rigney
Request for Comments: 2869                                     Livingston
Category: Informational                                        W. Willats
                                                        Cyno Technologies
                                                               P. Calhoun
                                                         Sun Microsystems
                                                                June 2000


                           RADIUS扩展

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

摘要

本文档描述了利用远程拨入用户认证服务(RADIUS)协议在网络访问服务器(NAS)和共享的计费服务器之间传送认证、授权和计费信息的额外属性。其中RADIUS协议在RFC 2865和RFC 2866中描述。 

目  录
1引言	6
2具体操作	6
 2.1RADIUS对之间计费更新的支持	6
 2.2RADIUS对Apple远程接入协议的支持	7
 2.3RADIUS对扩展认证协议（EAP）的支持	11
 2.3.1协议回顾	11
 2.3.2重传	12
 2.3.3分片	13
 2.3.4举例	13
 2.3.5选择使用	20
3报文格式	20
4报文类型	20
5属性   	20
 5.1Acct-Input-Gigawords	23
 5.2Acct-Output-Gigawords	23
 5.3Event-Timestamp	24
 5.4ARAP-Password	25
 5.5ARAP-Features	26
 5.6ARAP-Zone-Access	28
 5.7ARAP-Security	29
 5.8ARAP-Security-Data	30
 5.9Password-Retry	31
 5.10  Prompt	31
 5.11  Connect-Info	32
 5.12  Configuration-Token	33
 5.13  EAP-Message	34
 5.14  Message-Authenticator	36
 5.15  ARAP-Challenge-Response	38
 5.16  Acct-Interim-Interval	39
 5.17  NAS-Port-Id	40
 5.18  Framed-Pool	40
 5.19  属性表	41
6IANA 考虑事项	42
7安全考虑事项	42
 7.1Message-Authenticator安全	42
 7.2EAP安全	43
 7.2.1EAP服务器和PPP认证者分离	43
 7.2.2连接劫持	43
 7.2.3中间的攻击	44
 7.2.4多数据库	44
 7.2.5协商攻击	44
8.     References ............................................   43
9.     Acknowledgements ......................................   44
10.    Chair's Address .......................................   44
11.    Authors' Addresses ....................................   45
12.    Full Copyright Statement ..............................   47

1. 引言
RFC2865和RFC2866描述了如何利用RADIUS协议进行认证和计费，目前正在应用。本文档建议了几个额外的属性，可以实现多种非常有用的功能，这几个额外的属性可以添加到RADIUS协议中。这几个属性目前没有大面积使用的经验，因此只能看作是实验性的。
扩展认证协议（EAP）是对PPP协议的扩展，通过EAP可以在PPP协议内支持额外的认证方法。本文档描述了RADIUS协议如何利用EAP-Message和Message-Authenticator属性支持EAP。
所有的属性由Type-Length-Value三元组组成。可以添加新的属性值而又不影响协议的实现。

1.1.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

   An implementation is not compliant if it fails to satisfy one or more
   of the must or must not requirements for the protocols it implements.
   An implementation that satisfies all the must, must not, should and
   should not requirements for its protocols is said to be
   "unconditionally compliant"; one that satisfies all the must and must
   not requirements but not all the should or should not requirements
   for its protocols is said to be "conditionally compliant."

   A NAS that does not implement a given service MUST NOT implement the
   RADIUS attributes for that service.  For example, a NAS that is
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
   for ARAP.  A NAS MUST treat a RADIUS access-request requesting an
   unavailable service as an access-reject instead.

1.2.  Terminology

   This document uses the following terms:

   service   The NAS provides a service to the dial-in user, such as PPP
             or Telnet.

   session   Each service provided by the NAS to a dial-in user
             constitutes a session, with the beginning of the session
             defined as the point where service is first provided and
             the end of the session defined as the point where service





Rigney, et al.               Informational                      [Page 3]

RFC 2869                   RADIUS Extensions                   June 2000


             is ended.  A user may have multiple sessions in parallel or
             series if the NAS supports that, with each session
             generating a separate start and stop accounting record.

   silently discard
             This means the implementation discards the packet without
             further processing.  The implementation SHOULD provide the
             capability of logging the error, including the contents of
             the silently discarded packet, and SHOULD record the event
             in a statistics counter.

2.具体操作
具体操作同RFC2865和RFC2866中定义的完全相同
RADIUS对之间计费更新的支持
当用户认证通过以后，RADIUS服务器对认证请求报文Access-Request回应一个认证接受报文Access-Accept。如果服务器希望接到用户的中间流量报文，那么在认证接受报文Access-Accept中必须包含RADIUS属性Acct-Interim-Interval。这个属性指明了中间计费报文的时间间隔（以秒为单位）。
当然，也可以在NAS上通过静态配置设定一个中间计费报文的时间间隔。需要注意的是：这个NAS上配置的局部的时间间隔值必须覆盖包含在认证接受报文Access-Accept中携带的时间间隔值。
这个方案并不会破坏后向兼容性。因为不支持这个扩展属性的RADIUS服务器当然不会添加这个新的属性。同样，不支持这个扩展属性的NAS也会忽略此属性。
注意，在中间计费报文中的信息是累积的，即：报文中的发送分组数量是从会话开始的总的分组数量，而不是从上一个中间计费报文以后的分组数量。
可以预见，中间计费记录（其中属性Acct-Status-Type = Interim-Update (3)）中除了不包含属性Acct-Term-Cause外，包含了计费结束报文中其它的所有属性。
既然信息是累积的，NAS必须保证在给定的任何时间在重发队列中对于某一个会话只有一个单独的中间计费报文存在。NAS可以利用fudge因子在对应于不同会话的中间计费报文之间增加一段随机时延。这样可以避免所有的报文立刻发送。
利用中间计费更新应该认真考虑网络和NAS CPU的负担，因此应该合理选择中间计费间隔Acct-Interim-Interval。
RADIUS对Apple远程接入协议的支持
        RADIUS协议提供了允许多个NAS共享同一个认证数据库的一种方法。
        Apple远程接入协议（ARAP）支持在点到点链路上传送AppleTalk网络流量，点到点链路通常（但不唯一）是异步和ISDN交换电路连接。尽管Apple在未来的远程接入业务中朝着ATCP on PPP的方向发展，但对已经使用远程接入的Macintosh用户来说，RARP仍然是一种普通的方法，而且可能要存在一段时间。
         有几个NAS提供商支持ARAP，同时，这些提供商在同一个NAS上也支持PPP、IPX和其它协议。在这些支持多协议的设备上通常不用RADIUS对ARAP连接进行认证，即便有，不同的提供商分别提供不同的解决方案。
         本节描述支持RARP协议的RADIUS几个额外属性的使用。符合本规范的RADIUS客户端和服务器端实现应该用可以互操作的方式对ARAPR连接验证。
         本节的讨论假定读者对RADIUS协议已很熟悉，因此首先直接探究ARAP应用的具体细节，然后再详细讨论RADIUS协议的额外属性。
       本文档不讨论的两个ARAP特色如下：
              1.  用户发起的密码改变。这不是RADIUS的一部分，但可以通过软件过程实现。
              2.  带外报文。NAS任何时候都可以向ARA客户端发送报文，报文以对话框的形式显示在                       拨号接入用户的屏幕上。这不属于认证的一部分，也不属于此处讨论的范畴。但我们                      注意到 认证接受报文Access-Accept中的Reply-Message属性可以利用带外信道传给用                   户。
         我们尽可能多地尊重已有的RADIUS协议精神，使设计与以前的技术兼容。更进一步讨论，我们需要在两方面作出平衡选择处理。一方面，过多的新属性造成RADIUS世界的泛滥；另一方面，将整个ARAP操作隐藏在一个单独的复合ARAP属性串中，或者在扩展认证协议（EAP）的机制内解决。
        但是，我们认为只要保证几个类似命名的属性，ARAP从PPP分离出来就足够了。
        我们已经假定能够理解ARAP的RADIUS服务器可以进行DES加密且可以产生安全模式挑战字。这正与RADIUS的如下目标一致：灵活服务器/简单NAS。
        ARAP对一个连接的认证分两个阶段。第一个阶段是利用用户密码作为密钥，互换一个“二次DES”随机数。之所以说是“二次”，是因为ARAP NAS挑战拨号接入用户对自己进行验证，同样，拨号接入用户挑战ARAP NAS从对自己进行验证。
       特别地，ARAP执行如下过程：
        1.  NAS在ARAP的msg_auth_challenge分组中向拨号接入用户发送两个32位的随机数。
        2.  拨号接入用户收到NAS发来的两个随机数后，利用用户密码对这两个随机数进行DES加                    密，然后拨号接入客户端将此加密后的结果连同用户名和客户端产生的两个32位的随机数              在ARAP msg_auth_request分组中回应给NAS。
        3.  NAS接收到以后，确认由拨号接入客户端发送过来的经过加密的随机数是否是自己所期望              的。如果是，它利用密码对拨号接入客户端发送过来的挑战字进行加密，并且把加密后的               结果在ARAP msg_auth_response分组中发给拨号接入客户端。
      注意如果拨号接入客户端的响应错误（这意味着用户密码错误），服务器可以重发，直到重发次数达到NAS允许的最大发送次数。在这种情况下，当拨号接入客户端接收到ARAP msg_auth_response分组后，将用ARAP msg_auth_again分组进行确认。
       第一个“DES Phase”阶段通过以后，ARAP NAS可以利用被Apple称之为“Add-In Security Modules”的机制发起第二个认证阶段。 Security Modules是运行在客户端和服务器上的几小段代码，允许通过通讯链路读和写任意数据，从而实现额外的认证功能。各种安全令牌提供商利用这种机制对ARA呼叫者进行认证。
        尽管ARAP允许安全模块读写它们所需要的任意信息，但是已经存在的安全模块是利用简单的挑战和响应循环，当然可能携带某些全局控制信息。本文档假定利用一个或几个challenge/response循环可以支持所有已经存在的安全模块。
       在DES Phase之后，Security Module phase之前，RAP向下发送某些概貌信息，使RADIUS和ARAP集成复杂。这意味着，在某些异常时间，除了对challenge的响应以外，还必须存在概貌信息。幸运的是这些信息只是几个与密码相关的数字，本文档中把这些信息封装在一个单独的新的属性中。
         向RADIUS发送一个Access-Request报文代表ARAP连接是非常直接的。ARAP NAS产生一个随机的数字挑战字，然后接受拨号接入客户端的响应，客户端的挑战字和用户名。假定用户不是一个guest，在Access-Request分组中转发如下信息： User-Name（最长31个字符），Framed-Protocol （对于ARAP，此域值填为3），ARAP-Password和其它希望携带的属性，如Service-Type， NAS-IP-Address，NAS-Id，NAS-Port-Type，NAS-Port，NAS-Port-Id， Connect-Info等。
         Request Authenticator是一个NAS产生的16字节的随机数。这个随机数的低8个字节作为两个四字节的随机数放在ARAP msg_auth_challenge报文中传给拨号接入用户。其中字节0-3作为第一个随机数，字节4-7作为第二个随机数。
       Access-Request报文中的ARAP-Password包含一个16 字节的随机数域，用来携带拨号进入用户对NAS挑战的响应及客户端自己 对NAS的挑战字。高字节包含拨号接入用户对NAS的挑战字（2个32位的数字，共8字节），第字节包含拨号接入用户对NAS挑战的响应（2个32位的数字，共8字节）。
         User-Password， CHAP-Password 或ARAP-Password三个属性在Access-Request报文中只能出现一个，也可以出现一个或多个EAP-Messages。
        如果RADIUS服务器不支持ARAP，它应该向NAS返回一个Access-Reject报文。
        如果RADIUS服务器不支持ARAP，它应该利用Challenge（Request Authenticator中的低8个字节）和用户响应（ARAP-Password 中的低8个字节）来确认用户的响应。
         如果认证失败，RADIUS服务器应该向NAS返回一个Access-Reject报文，报文中携带可选属性Password-Retry和Reply-Messages。如果携带Password-Retry属性，这就告知ARAP NAS可以选择再发起几个挑战-响应循环，直到循环次数等于Password-Retry属性中的整数值。
         如果用户认证通过，RADIUS服务器应该向NAS返回一个Access-Accept报文（Code等于2），ID和Response Authenticator跟通常情况一样，其它属性如下：
        Service-Type of Framed-Protocol
        Framed-Protocol of ARAP (值为3)
        Session-Timeout，它代表用户可以连接的最长时间（以秒为单位）。如果用户被授权为无限 制用户，那么在Access-Accept报文中就不应该包含Session-Timeout属性。此时ARAP将用户作为无限制用户超时（值为-1）。
        ARAP-Challenge-Response，它包含8个字节，代表对拨号接入用户的响应。RADIUS是用如下方法填充出此属性的。RADIUS服务器从ARAP-Password属性中取出高8个字节（实际为拨号接入用户的挑战），然后再用认证用户的密码作为密钥，对前边已取出的用户的挑战进行DES加密。如果用户的密码在长度上小于8个字节，那么就在用户密码填充NULL字节，直到满8个字节；如果用户密码长度大于8个字节，那就应该返回一个Access-Reject报文。
       ARAP-Features，它包含了NAS在ARAP“feature flags”报文中将携带给用户的信息。
             字节0：如果值为0，表示用户不能改变密码，如果值不为0，表示用户可以改变密码（RADIUS不处理密码更改，仅用属性指明ARAP是否可以改变密码）。
              字节1：表示最小的可接受的密码长度（0-8）。
              字节2-5：表示Macintosh格式的密码产生日期，为一32位的无符号整数，代表从Midnight GMT January 1, 1904以后的总的时间（以秒为单位）。  
              字节6-9：表示从密码产生以后的有效时间长度（以秒为单位）。
              字节10-13：以Macintosh格式表示的目前RADIUS时间。
        作为可选项，回应报文中可以包含Reply-Message属性，其内容为一字符串，最多可以包含253个字符，这些内容可以在对话框中显示给用户。
        Framed-AppleTalk-Network：此属性可以包含在报文中。      
        Framed-AppleTalk-Zone：此属性可包含在报文中，最大长度为32个字符。
         对于一个用户，ARAP定义了区域列表。与区域名字列表一起，ARAP定义了区域访问标志（被NAS使用），此标志说明了如何利用区域名字列表。即：拨号接入用户可能只允许访问缺省区域，或者只能访问区域列表中区域，也或者只能访问除区域列表中列出的以外的其它区域。
         ARAP NAS中含有一个指定的滤波器，用此滤波器可以处理此问题，其中滤波器起码的区域名字。用此机制，解决了如下问题：用一个单独的RADIUS服务器管理不同的NAS客户端，并且客户端有或许不能全部看到用户区域列表中的区域名字。区域名字只对NAS才有意义。这种方法的不足之处在于滤器必须在首先NAS中以某种方式启动，然后再由RADIUS Filter-Id引用。
        ARAP-Zone-Access属性中包含一个整数，此属性指明了该如何使用针对一个用户的区域列表该。如果包含此属性且其值为2或4，那么就必须包含Filter-Id属性，Filter-Id属性命名了一个适用访问标记的滤波器。
        在Access-Accept报文中包含Callback-Number或Callback-Id属性可能导致ARAP NAS在发送Feature Flags开始回调处理后切断连接。其中回调处理是以一种ARAP特有的方式进行。
         在Access-Accept报文中也可以包含其它属性。
         ARAP要完成到客户端拨号接入的连接，还需要其它信息。这种信息可由ARAP NAS通过SNMP配置，NAS管理程序或从NAS的AppleTalk堆栈中获得，不需要RADIUS的任何帮助。特别地：
       1.  将AppearAsNet和AppearAsNode值传送给客户端，告诉它在数据报分组中应该适用什么样的网络和节点值。 AppearAsNet可以从Framed-AppleTalk-Network属性中获得，或者通过配置，或者通过NAS的堆栈获得。
       2.  拨号接入终端将出现在缺省区域内，缺省区域也就是AppleTalk的名字。 （或者用Framed-AppleTalk-Zone属性指明）
        3.  其它的NAS特有的资料，如NAS的名字和smartbuffering信息。（Smartbuffering是ARAP的一种机制。它用小的令牌取代普通的AppleTalk数据报，从而改善了某些普通慢链路的性能。）
        4.  用户的“Zone List”信息。 ARAP规范定义了一个“zone count”域，实际上没有使用。
        RADIUS用以下方式支持ARAP Security Modules。
         DES认证结束以后，RADIUS服务器通知ARAP NAS为拨号接入用户运行一个或多个security modules。尽管基本的协议支持连续执行多个security modules，但在实践中，目前的实现只允许实现一个。通过使用多个Access-Challenge请求，就可以支持多个安全模式，但这种功能可能永远不会被使用。
        同时我们也假定，尽管ARAP允许在点到点链路的端点上安全模式之间使用自由格式的对话，但在实践中，所有的安全模式可以简化为简单的挑战/响应循环。
        如果RADIUS服务器希望通知ARAP NAS运行一个安全模式，那么它应该给NAS发送一个Access-Challenge报文，作为可选项，报文中可以携带State属性，加上ARAP-Challenge-Response ，ARAP-Features和其它两个属性：
         ARAP-Security：一个四字节的模式签名，包含一个Macintosh OSType。
         ARAP-Security-Data：一个字符串，携带了实际的模式挑战和响应。
         当执行完安全模式，NAS向RADIUS再发送一个Access-Request报文，报文中的属性ARAP-Security-Data包含了安全模式的响应，同时也包含Access-Challenge中得到的State属性。 在这种情况下，authenticator域内不再包含特别的信息，因为可以由存在的State属性来辨别。
RADIUS对扩展认证协议（EAP）的支持
扩展认证协议（EAP）描述了在PPP内支持额外认证的一种标准机制。通过EAP，可以支持许多额外认证方案，包括智能卡（Smart card )，Kerberos，Public Key，One Time Passwords和其它多种。为了在RADIUS内支持EAP，本文档引入了两个新的属性： EAP-Message和Message-Authenticator。本节描述了RADIUS如何利用这两个新的属性来支持EAP。
在提出的方案中，利用RADIUS服务器在NAS和后端安全服务器之间传送封装在RADIUS内的EAP报文。尽管可以利用后端服务器发展的私有协议在RADIUS服务器和后端服务器之间进行会话，但通过将EAP报文封装在RASIUS报文的EAP-Message属性内也是可能的。这样的优点是RADIUS服务器为了支持EAP，不需要增加针对某种认证的代码，这些针对某种认证的代码的可以放在后端安全服务器上。
协议回顾
认证对等端（拨号接入用户）和NAS之间的EAP会话以LCP中的EAP协商开始。一旦EAP协商通过，NAS必须向认证对等端发送一个EAP-Request/Identity报文，除非通过其它途径如Called-Station-Id或Calling-Station-Id确定了身份。认证对等端然后向NAS发送一个EAP-Response/Identity报文，NAS收到此报文后封装在RADIUS的Access-Request报文的EAP-Message属性内转发给RADIUS服务器。RADIUS服务器通常将利用EAP-Response/Identity来断定将对用户使用何种EAP类型。
为了允许不能理解EAP的RADIUS代理转发Access-Request报文，如果NAS发送EAP-Request/Identity，NAS必须将EAP-Response/Identity中的内容拷贝到User-Name属性中，同时在随后的每一个Access-Request报文中的User-Name属性中必须包含EAP-Response/Identity。 也建议将NAS-Port和NAS-Port-Id属性包含在NAS发送的Access-Request报文中，而NAS-Identifier和NAS-IP-Address则必须包括在内。为了允许不理解EAP的代理能够转发Access-Reply，如果在Access-Request中包含User-Name属性，RADIUS服务器在随后的Access-Accept中必须包含User-Name属性。如果没有用户名属性，计费和生成帐单将变得非常难于管理。