Network Working Group B. Aboba
Request for Comments: 2607 Microsoft Corporation
Category: Informational J. Vollbrecht
Merit Networks, Inc.
June 1999
Network Working Group B. Aboba
Request for Comments: 2607 Microsoft Corporation
Category: Informational J. Vollbrecht
Merit Networks, Inc.
June 1999
Proxy Chaining and Policy Implementation in Roaming
漫游中的代理链接和策略实现
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document describes how proxy chaining and policy implementation can be supported in roaming systems. The mechanisms described in this document are in current use.
本文档介绍如何在漫游系统中支持代理链接和策略实现。本文档中描述的机制目前正在使用。
However, as noted in the security considerations section, the techniques outlined in this document are vulnerable to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves. As a result, such methods are not suitable for wide-scale deployment on the Internet.
但是，如安全注意事项一节所述，本文件中概述的技术容易受到外部方的攻击，也容易受到漫游伙伴自己实施的欺诈。因此，此类方法不适合在Internet上广泛部署。
This document frequently uses the following terms:
本文件经常使用以下术语：
Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network.
网络访问服务器网络访问服务器（NAS）是客户端为了访问网络而联系的设备。
RADIUS server This is a server which provides for authentication/authorization via the protocol described in [3], and for accounting as described in [4].
RADIUS服务器这是一个服务器，它通过[3]中描述的协议提供身份验证/授权，并按照[4]中描述进行记帐。
RADIUS proxy In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client.
RADIUS代理为了提供RADIUS身份验证和记帐请求的路由，可以使用RADIUS代理。对于NAS，RADIUS代理似乎充当RADIUS服务器；对于RADIUS服务器，代理似乎充当RADIUS客户端。
Network Access Identifier In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP (known as the Network Access Identifier or NAI) and in the subsequent RADIUS authentication and accounting requests, can contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. The NAI is defined in [6].
网络访问标识符为了提供RADIUS身份验证和记帐请求的路由，PPP（称为网络访问标识符或NAI）和后续RADIUS身份验证和记帐请求中使用的用户ID字段可以包含结构。此结构提供了RADIUS代理定位要接收请求的RADIUS服务器的方法。NAI的定义见[6]。
Roaming relationships Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming association, and relationships between an ISP and a roaming consortia. Together, the set of relationships forming a path between a local ISP's authentication proxy and the home authentication server is known as the roaming relationship path.
漫游关系漫游关系包括公司与ISP之间的关系、漫游关联中对等ISP之间的关系以及ISP与漫游联盟之间的关系。总之，在本地ISP的认证代理和家庭认证服务器之间形成路径的一组关系称为漫游关系路径。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [5].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[5]所述。
Today, as described in [1], proxy chaining is widely deployed for the purposes of providing roaming services. In such systems, authentication/authorization and accounting packets are routed between a NAS device and a home server through a series of proxies. Consultation of the home server is required for password-based authentication, since the home server maintains the password database and thus it is necessary for the NAS to communicate with the home authentication server in order to verify the user's identity.
如今，如[1]中所述，代理链接广泛用于提供漫游服务。在这样的系统中，身份验证/授权和记帐数据包通过一系列代理在NAS设备和家庭服务器之间路由。基于密码的认证需要咨询家庭服务器，因为家庭服务器维护密码数据库，因此NAS有必要与家庭认证服务器通信以验证用户的身份。
Proxies serve a number of functions in roaming, including:
代理在漫游中提供多种功能，包括：
Scalability improvement Authentication forwarding Capabilities adjustment Policy implementation Accounting reliability improvement Atomic operation
可扩展性改进认证转发能力调整策略实现记帐可靠性改进原子操作
Scalability improvement In large scale roaming systems, it is necessary to provide for scalable management of keys used for integrity protection and authentication.
可扩展性改进在大规模漫游系统中，有必要提供用于完整性保护和身份验证的密钥的可扩展管理。
Proxy chaining enables implementation of hierarchical forwarding within roaming systems, which improves scalability in roaming consortia based on authentication protocols without automated key management. Since RADIUS as described in [3] requires a shared secret for each client-server pair, a consortium of 100 roaming partners would require 4950 shared secrets if each partner were to contact each other directly, one for each partner pair. However, were the partners to route authentication requests through a central proxy, only 100 shared secrets would be needed, one for each partner. The reduction in the number of partner pairs also brings with it other benefits, such as a reduction in the number of bilateral agreements and accounting and auditing overhead. Thus, hierarchical routing might be desirable even if an authentiation protocol supporting automated key exchange were available.
代理链可以在漫游系统中实现分层转发，从而提高基于身份验证协议的漫游联盟的可伸缩性，而无需自动密钥管理。由于[3]中所述的RADIUS要求每个客户机-服务器对共享机密，因此，如果每个合作伙伴直接相互联系，则100个漫游合作伙伴的联盟将需要4950个共享机密，每个合作伙伴对一个共享机密。但是，如果合作伙伴通过中央代理路由身份验证请求，则只需要100个共享机密，每个合作伙伴一个共享机密。伙伴对数量的减少还带来其他好处，如双边协议数量的减少以及会计和审计费用的减少。因此，即使支持自动密钥交换的认证协议可用，分层路由也可能是可取的。
Capabilities adjustment As part of the authentication exchange with the home server, the NAS receives authorization parameters describing the service to be provided to the roaming user. Since RADIUS, described in [3], does not support capabilities negotiation, it is possible that the authorization parameters sent by the home server will not match those required by the NAS. For example, a static IP address could be specified that would not be routable by the NAS. As a result, capbilities adjustment is performed by proxies in order to enable communication between NASes and home servers with very different feature sets.
能力调整作为与家庭服务器进行身份验证交换的一部分，NAS接收描述要提供给漫游用户的服务的授权参数。由于[3]中描述的RADIUS不支持功能协商，因此家庭服务器发送的授权参数可能与NAS所需的参数不匹配。例如，可以指定NAS无法路由的静态IP地址。因此，通过代理执行容量调整，以实现NASE和具有非常不同功能集的家庭服务器之间的通信。
As part of capabilities adjustment, proxies can edit attributes within the Access-Accept in order to ensure compatibility with the NAS. Such editing may include addition, deletion, or modification of attributes. In addition, in some cases it may be desirable for a proxy to edit attributes within an Access-Request in order to clean up or even hide information destined for the home server. Note that if the proxy edits attributes within the Access-Accept, then it is possible that the service provided to the user may not be the same as that requested by the home server. This creates the possibility of disputes arising from inappropriate capabilities adjustment.
作为功能调整的一部分，代理可以编辑Access Accept中的属性，以确保与NAS的兼容性。此类编辑可能包括添加、删除或修改属性。此外，在某些情况下，代理可能需要编辑访问请求中的属性，以便清理甚至隐藏目的地为家庭服务器的信息。请注意，如果代理编辑Access Accept中的属性，则向用户提供的服务可能与家庭服务器请求的服务不同。这就产生了因能力调整不当而产生争议的可能性。
Note that were roaming to be implemented based on an authentication/authorization protocol with built-in capability negotiation, proxy-based capabilities adjustment would probably not be necessary.
请注意，如果漫游是基于具有内置功能协商的身份验证/授权协议实现的，则可能不需要基于代理的功能调整。
Authentication forwarding Since roaming associations frequently implement hierarchical forwarding in order to improve scalability, in order for a NAS and home server to communicate, authentication and accounting packets are forwarded by one or more proxies. The path travelled by these packets, known as the roaming relationship path, is determined from the Network Access Identifier (NAI), described in [6]. Since most NAS devices do not implement forwarding logic, a proxy is needed to enable forwarding of authentication and accounting packets. For reasons that are described in the security section, in proxy systems it is desirable for accounting and authentication packets to follow the same path.
身份验证转发由于漫游关联经常实施分层转发以提高可伸缩性，为了使NAS和家庭服务器通信，身份验证和记帐数据包由一个或多个代理转发。这些包所经过的路径称为漫游关系路径，由[6]中描述的网络访问标识符（NAI）确定。由于大多数NAS设备不实现转发逻辑，因此需要一个代理来支持身份验证和记帐数据包的转发。出于安全部分所述的原因，在代理系统中，记帐和身份验证数据包最好遵循相同的路径。
Note: The way a proxy learns the mapping between NAI and the home server is beyond the scope of this document. This mapping can be accomplished by static configuration in the proxy, or by some currently undefined protocol that provides for dynamic mapping. For the purposes of this document, it is assumed that such a mapping capability exists in the proxy.
注意：代理学习NAI和家庭服务器之间映射的方式超出了本文档的范围。这种映射可以通过代理中的静态配置来完成，也可以通过提供动态映射的一些当前未定义的协议来完成。在本文档中，假设代理中存在这种映射功能。
Policy implementation In roaming systems it is often desirable to be able to implement policy. For example, a given partner may only be entitled to use of a given NAS during certain times of the day. In order to implement such policies, proxies may be implemented at the interface between administrative domains and programmed to modify authentication/authorization packets forwarded between the NAS and the home server. As a result, from a security point of view, a proxy implementing policy
在漫游系统中，通常希望能够实现策略。例如，给定的合作伙伴可能仅在一天中的特定时间有权使用给定的NAS。为了实现这样的策略，可以在管理域之间的接口处实现代理，并对代理进行编程以修改在NAS和家庭服务器之间转发的认证/授权分组。因此，从安全性的角度来看，代理实现策略
operates as a "man in the middle."
作为一个“中间人”来运作。
Accounting reliability improvement In roaming systems based on proxy chaining, it is necessary for accounting information to be forwarded between the NAS and the home server. Thus roaming is inherently an interdomain application.
在基于代理链的漫游系统中，会计信息必须在NAS和家庭服务器之间转发。因此，漫游本质上是一种域间应用程序。
This represents a problem since the RADIUS accounting protocol, described in [4] is not designed for use on an Internet scale. Given that in roaming accounting packets travel between administrative domains, packets will often pass through network access points (NAPs) where packet loss may be substantial. This can result in unacceptable rates of accounting data loss.
这是一个问题，因为[4]中描述的RADIUS记帐协议不是为在互联网规模上使用而设计的。考虑到在漫游计费中，数据包在管理域之间传输，数据包通常会通过网络接入点（NAP），其中数据包丢失可能很大。这可能导致无法接受的会计数据丢失率。
For example, in a proxy chaining system involving four systems, a one percent failure rate on each hop can result in loss of 3.9 percent of all accounting transactions. Placement of an accounting proxy near the NAS may improve reliability by enabling enabling persistent storage of accounting records and long duration retry.
例如，在涉及四个系统的代理链接系统中，每个跃点上1%的失败率可能导致所有会计事务损失3.9%。在NAS附近放置记帐代理可以通过启用记帐记录的持久存储和长时间重试来提高可靠性。
Atomic operation In order to ensure consistency among all parties required to process accounting data, it can be desirable to assure that transmission of accounting data is handled as an atomic operation. This implies that all parties on the roaming relationship path will receive and acknowledge the receipt of the accounting data for the operation to complete. Proxies can be used to ensure atomic delivery of accounting data by arranging for delivery of the accounting data in a serial fashion, as discussed in section 5.2.
原子操作为了确保处理会计数据所需各方之间的一致性，最好确保会计数据的传输作为原子操作处理。这意味着漫游关系路径上的所有各方将接收并确认要完成操作的记帐数据的接收。如第5.2节所述，通过安排以串行方式交付会计数据，可以使用代理来确保会计数据的原子交付。
An example of a proxy chaining system is shown below.
代理链接系统的示例如下所示。
(request) (request) (request)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(reply) (reply) (reply) Server
<--------- <--------- <---------
(request) (request) (request)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(reply) (reply) (reply) Server
<--------- <--------- <---------
In the above diagram, the NAS generates a request and sends it to Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the request to the Home Server. The Home Server generates a reply and sends it to Proxy2. Proxy2 receives the reply, matches it with the request it had sent, and forwards a reply to Proxy1. Proxy1
在上图中，NAS生成一个请求并将其发送到Proxy1。Proxy1将请求转发给Proxy2，Proxy2将请求转发给家庭服务器。家庭服务器生成应答并将其发送到Proxy2。Proxy2接收回复，将其与发送的请求进行匹配，然后将回复转发给Proxy1。Proxy1
matches the reply with the request it sent earlier and forwards a reply to the NAS. This model applies to all requests, including Access Requests and Accounting Requests.
将答复与先前发送的请求相匹配，并将答复转发给NAS。此模型适用于所有请求，包括访问请求和记帐请求。
Except for the two cases described below, a proxy server such as Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1 without first having received a Reply packet initiated by the Home Server. The two exceptions are when the proxy is enforcing policy as described in section 5.1 and when the proxy is acting as an accounting store (as in store and forward), as described in section 5.2.
除了下面描述的两种情况外，代理服务器（如上图中的Proxy2）在未首先收到由家庭服务器发起的回复包之前，不应向Proxy1发送回复包。两种例外情况是，当代理执行第5.1节所述的策略时，以及当代理作为会计存储（如存储和转发）时，如第5.2节所述。
The RADIUS protocol described in [3] does not provide for end-to-end security services, including integrity or replay protection, authentication or confidentiality. As noted in the security considerations section, this omission results in several security problems within proxy chaining systems.
[3]中描述的RADIUS协议不提供端到端安全服务，包括完整性或重播保护、身份验证或机密性。正如安全注意事项一节中所指出的，这种省略会导致代理链接系统中出现几个安全问题。
Proxies are frequently used to implement policy in roaming situations. Proxies implementing policy MAY reply directly to Access-Requests without forwarding the request. When replying directly to an Access-Request, the proxy MUST reply either with an Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply directly with an Access-Accept. An example of this would be when the proxy refuses all connections from a particular realm during prime time. In this case the home server will never receive th Access-Request. This situation is shown below:
代理经常用于在漫游情况下实现策略。实现策略的代理可以直接回复访问请求，而无需转发请求。当直接回复访问请求时，代理必须回复访问拒绝或访问质询数据包。代理不能直接使用Access Accept进行回复。例如，当代理在黄金时段拒绝来自特定领域的所有连接时。在这种情况下，家庭服务器将永远不会收到访问请求。这种情况如下所示：
(request) (request)
NAS ----------> Proxy1 ----------> Proxy2 Home
(reply) (reply) Server
<--------- <---------
(request) (request)
NAS ----------> Proxy1 ----------> Proxy2 Home
(reply) (reply) Server
<--------- <---------
A proxy MAY also decide to Reject a Request that has been accepted by the home server. This could be based on the set of attributes returned by the home server. In this case the Proxy SHOULD send an Access-Reject to the NAS and an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server. This lets the home server know that the session it approved has been denied downstream by the proxy. However, a proxy MUST NOT send an Access-Accept after receiving an Access-Reject from a proxy or from the home server.
代理还可以决定拒绝已被家庭服务器接受的请求。这可能基于家庭服务器返回的属性集。在这种情况下，代理应向NAS发送访问拒绝，并向主服务器发送Acct Status Type=代理停止（6）的记帐请求。这使家庭服务器知道其批准的会话已被代理拒绝。但是，在从代理服务器或家庭服务器收到访问拒绝后，代理服务器不得发送访问接受。
(Access-Req) (Access-Req) (Access-Req)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Access-Reject) (Access-Accept) (Access-Accept) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
(Access-Req) (Access-Req) (Access-Req)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Access-Reject) (Access-Accept) (Access-Accept) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
As described above, a proxy MUST NOT reply directly with an Access-Accept, and MUST NOT reply with an Access-Accept when it has received an Access-Reject from another proxy or Home Server. As a result, in all cases where an accounting record is to be generated (accepted sessions), no direct replies have occurred, and the Access-Request and Access-Accept have passed through the same set of systems.
如上所述，代理服务器不得直接使用访问接受进行回复，也不得在收到来自另一个代理服务器或家庭服务器的访问拒绝时使用访问接受进行回复。因此，在所有要生成会计记录的情况下（接受的会话），都没有直接回复，并且访问请求和访问接受都通过了同一组系统。
In order to allow proxies to match incoming Accounting-Requests with previously handled Access-Requests and Access-Accepts, a proxy SHOULD route the Accounting-Request along the same realm path travelled in authentication/authorization. Note that this does not imply that accounting packets will necessarily travel the identical path, machine by machine, as did authentication/authorization packets. This is because it is conceivable that a proxy may have gone down, and as a result the Accounting-request may need to be forwarded to an alternate server. It is also conceivable that authentication/authorization and accounting may be handled by different servers within a realm.
为了允许代理将传入的记帐请求与以前处理的访问请求和访问接受相匹配，代理应该沿着身份验证/授权中经过的相同领域路径路由记帐请求。请注意，这并不意味着记帐数据包必然会像身份验证/授权数据包一样，一台机器一台机器地沿着相同的路径移动。这是因为可以想象代理服务器可能已关闭，因此可能需要将记帐请求转发到备用服务器。还可以想象，身份验证/授权和记帐可以由一个领域内的不同服务器处理。
The Class attribute can be used to match Accounting Requests with prior Access Requests. It can also be used to match session log records between the home Server, proxies, and NAS. This matching can be accomplished either in real-time (in the case that authentication and accounting packets follow the same path, machine by machine), or after the fact.
Class属性可用于将记帐请求与以前的访问请求相匹配。它还可用于匹配家庭服务器、代理和NAS之间的会话日志记录。这种匹配可以实时完成（在身份验证和记帐数据包遵循相同路径的情况下，一台机器接一台机器），也可以事后完成。
Home servers SHOULD insert a unique session identifier in the Class attribute in an Access-Accept and Access-Challenge. Proxies and NASes MUST forward the unmodified Class attribute. The NAS MUST include the Class attribute in subsequent requests, in particular for Accounting-Requests. The sequence of events is shown below:
家庭服务器应在Access Accept和Access Challenge的Class属性中插入唯一的会话标识符。代理和NASE必须转发未修改的类属性。NAS必须在后续请求中包括Class属性，特别是对于记帐请求。事件顺序如下所示：
Authentication/Authorization
认证/授权
--------> --------> --------->
NAS Proxy1 Proxy2 Home (add class)
<-class-- <-class- <-class--
--------> --------> --------->
NAS Proxy1 Proxy2 Home (add class)
<-class-- <-class- <-class--
Accounting
会计
(Accounting-req) (Accounting-req) (Accounting-req)
w/class w/class w/class
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Accounting-reply) (Accounting-reply)(Accounting-reply) Server
<--------- <--------- <---------
(Accounting-req) (Accounting-req) (Accounting-req)
w/class w/class w/class
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Accounting-reply) (Accounting-reply)(Accounting-reply) Server
<--------- <--------- <---------
Since there is no need to implement policy in accounting, a proxy MUST forward all Accounting Requests to the next server on the path. The proxy MUST guarantee that the Accounting Request is received by the End Server and all intermediate servers. The proxy may do this either by: 1) forwarding the Accounting Request and not sending a Reply until it receives the matching Reply from the upstream server, or 2) acting as a store point which takes responsibility for reforwarding the Accounting Request until it receives a Reply.
由于不需要在记帐中实现策略，代理必须将所有记帐请求转发到路径上的下一台服务器。代理必须保证最终服务器和所有中间服务器都接收到记帐请求。代理可以这样做：1）转发记帐请求，在从上游服务器收到匹配的答复之前不发送答复，或2）充当存储点，负责重新发送记帐请求，直到收到答复。
Note that when the proxy does not send a reply until it receives a matching reply, this ensures that Accounting Start and Stop messages are received and can be logged by all servers along the roaming relationship path. If one of the servers is not available, then the operation will fail. As a result the entire accounting transaction will either succeed or fail as a unit, and thus can be said to be atomic.
请注意，当代理在收到匹配的答复之前不发送答复时，这将确保收到记帐开始和停止消息，并且可以由漫游关系路径上的所有服务器记录这些消息。如果其中一台服务器不可用，则操作将失败。因此，作为一个整体，整个会计事务要么成功，要么失败，因此可以说是原子的。
Where store and forward is implemented, it is possible that one or more servers along the roaming relationship path will not receive the accounting data while others will. The accounting operation will not succeed or fail as a unit, and is therefore not atomic. As a result, it may not be possible for the roaming partners to reconcile their audit logs, opening new opportunities for fraud. Where store and forward is implemented, forwarding of Accounting Requests SHOULD be done as they are received so the downstream servers will receive them in a timely way.
在实现存储转发的情况下，漫游关系路径上的一个或多个服务器可能不会接收记帐数据，而其他服务器则会接收记帐数据。会计操作作为一个单元不会成功或失败，因此不是原子的。因此，漫游合作伙伴可能无法核对其审计日志，从而带来新的欺诈机会。在实现存储和转发的情况下，应在收到记帐请求时进行转发，以便下游服务器及时接收它们。
Note that there are cases where a proxy will need to forward an Accounting packet to more than one system. For example, in order to allow for proper accounting in the case of a NAS that is shutting down, the proxy can send an Accounting-Request with Acct-Status-Type=Accounting-Off (8) to all realms that it forwards to. In turn, these proxies will also flood the packet to their connected realms.
请注意，在某些情况下，代理需要将记帐数据包转发到多个系统。例如，为了在NAS关闭的情况下进行正确的记帐，代理可以向其转发的所有领域发送Acct Status Type=accounting Off（8）的记帐请求。反过来，这些代理也会将数据包泛滥到它们连接的领域。
[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[1] Aboba，B.，Lu J.，Alsop J.，Ding J.和W.Wang，“漫游实现的回顾”，RFC 2194，1997年9月。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[2] Aboba，B.和G.Zorn，“评估漫游协议的标准”，RFC 2477，1999年1月。
[3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[3] Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4] 里格尼，C.，“半径会计”，RFC 21391997年4月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[6] Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
The RADIUS protocol described in [3] was designed for intra-domain use, where the NAS, proxy, and home server exist within a single administrative domain, and proxies may be considered a trusted component. However, in roaming the NAS, proxies, and home server will typically be managed by different administrative entities. As a result, roaming is inherently an inter-domain application, and proxies cannot necessarily be trusted. This results in a number of security threats, including:
[3]中描述的RADIUS协议设计用于域内使用，其中NAS、代理和家庭服务器存在于单个管理域中，代理可以被视为受信任的组件。但是，在漫游NAS时，代理和家庭服务器通常由不同的管理实体进行管理。因此，漫游本质上是一个域间应用程序，代理不一定是可信的。这导致了许多安全威胁，包括：
Message editing Attribute editing Theft of passwords Theft and modification of accounting data Replay attacks Connection hijacking Fraudulent accounting
消息编辑属性编辑密码盗窃和修改会计数据重播攻击连接劫持欺诈性会计
Through the use of shared secrets it is possible for proxies operating in different domains to establish a trust relationship. However, if only hop-by-hop security is available then untrusted proxies are capable of perpetrating a number of man-in-the-middle attacks. These include modification of messages.
通过使用共享机密，在不同域中运行的代理可以建立信任关系。但是，如果只有逐跳安全性可用，则不受信任的代理可以实施大量中间人攻击。其中包括修改消息。
For example, an Access-Accept could be substituted for an Access-Reject, and without end-to-end integrity protection, there is no way for the NAS to detect this. On the home server, this will result in an accounting log entry for a session that was not authorized. However, if the proxy does not forward accounting packets or session records to the home server, then the home server will not be able to detect the discrepancy until a bill is received and audited.
例如，访问接受可以替代访问拒绝，如果没有端到端完整性保护，NAS将无法检测到这一点。在家庭服务器上，这将导致未授权会话的记帐日志条目。但是，如果代理未将记帐数据包或会话记录转发到家庭服务器，则家庭服务器将无法检测到差异，直到收到并审核账单。
Note that a proxy can also send an Access-Reject to the NAS after receiving an Access-Accept from the home server. This will result in an authentication log entry without a corresponding accounting log entry. Without the proxy sending an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server, then there will be no way for the home server to determine whether the discrepancy is due to policy implementation or loss of accounting packets. Thus the use of Acct-Status-Type=Proxy-Stop can be of value in debugging roaming systems.
请注意，代理还可以在从主服务器接收访问接受后向NAS发送访问拒绝。这将导致身份验证日志条目没有相应的记帐日志条目。如果代理不向家庭服务器发送Acct Status Type=proxy Stop（6）的记帐请求，则家庭服务器将无法确定差异是由于策略实施还是由于记帐数据包丢失造成的。因此，在调试漫游系统时，使用Acct Status Type=Proxy Stop很有价值。
It should be noted that even if end-to-end security were to be available, a number of sticky questions would remain. While the end-points would be able to detect that the message from the home server had been modified by an intermediary, the question arises as to what action should be taken. While the modified packet could be silently discarded, this could affect the ability of the home server to . accept an Acct-Status-Type=Proxy-Stop message from an intermediate proxy. Since this message would not be signed by the NAS, it may need to be dropped by the home server.
应该指出的是，即使提供端到端的安全性，仍然存在一些棘手的问题。虽然端点能够检测到来自家庭服务器的消息已被中介修改，但问题是应该采取什么行动。虽然修改后的数据包可能会被悄悄地丢弃，但这可能会影响家庭服务器的恢复能力。接受来自中间代理的Acct Status Type=代理停止消息。由于NAS不会对此消息进行签名，因此家庭服务器可能需要删除该消息。
This is similar to the problem that IPSEC-capable systems face in making use of ICMP messages from systems with whom they do not have a security association. The problem is more difficult here, since in RADIUS retransmission is driven by the NAS. Therefore the home server does not receive acknowledgement for Access-Accepts and thus would have no way of knowing that its response has not been honored.
这类似于支持IPSEC的系统在使用来自与其没有安全关联的系统的ICMP消息时所面临的问题。这里的问题更难，因为半径内的重传是由NAS驱动的。因此，家庭服务器不会收到访问接受的确认，因此无法知道其响应未得到遵守。
RADIUS as defined in [3] does not provide for end-to-end security or capabilities negotiation. As a result there is no way for a home server to securely negotiate a mutually acceptable configuration with the NAS or proxies. As a result, a number of attribute editing attacks are possible.
[3]中定义的RADIUS不提供端到端安全或协商功能。因此，家庭服务器无法安全地与NAS或代理协商双方均可接受的配置。因此，可能会发生许多属性编辑攻击。
For example, EAP attributes might be removed or modified so as to cause a client to authenticate with EAP MD5 or PAP, instead of a stronger authentication method. Alternatively, tunnel attributes might be removed or modified so as to remove encryption, redirect the tunnel to a rogue tunnel server, or otherwise lessen the security
例如，可以删除或修改EAP属性，以使客户端使用EAP MD5或PAP进行身份验证，而不是使用更强大的身份验证方法。或者，可以删除或修改隧道属性，以便删除加密、将隧道重定向到恶意隧道服务器或以其他方式降低安全性
provided to the client. The mismatch between requested and received services may only be detectable after the fact by comparing the Access-Accept attributes against the attributes included in the Accounting-Request. However, without end-to-end security services, it is possible for a rogue proxy to cover its tracks.
提供给客户。只有在将访问接受属性与记帐请求中包含的属性进行比较之后，才能检测到请求的服务和接收的服务之间的不匹配。但是，如果没有端到端安全服务，流氓代理可能会掩盖其踪迹。
Due to the complexity of proxy configuration, such attacks need not involve malice, but can occur due to mis-configuration or implementation deficiencies. Today several proxy implementations remove attributes that they do not understand, or can be set up to replace attribute sets sent in the Access-Accept with sets of attributes appropriate for a particular NAS.
由于代理配置的复杂性，此类攻击不需要涉及恶意，但可能由于配置错误或实现缺陷而发生。现在，有几种代理实现会删除它们不了解的属性，或者可以设置为使用适合特定NAS的属性集替换Access Accept中发送的属性集。
In practice, it is not possible to define a set of guidelines for attribute editing, since the requirements are very often implementation-specific. At the same time, protection against inappropriate attribute editing is necessary to guard against attacks and provide assurance that users are provisioned as directed by the home server.
在实践中，不可能为属性编辑定义一套指导原则，因为需求通常是特定于实现的。同时，有必要防止不适当的属性编辑，以防止攻击，并确保用户按照家庭服务器的指示进行配置。
Since it is not possible to determine beforehand whether a given attribute is editable or not, a mechanism needs to be provided to allow senders to indicate which attributes are editable and which are not, and for the receivers to detect modifications of "non-editable" attributes. Through implementation of end-to-end security it may be possible to detect unauthorized addition, deletion, or modification of integrity-protected attributes. However, it would still possible for a rogue proxy to add, delete or modify attributes that are not integrity-protected. If such attributes influence subsequent charges, then the possibility of fraud would remain.
由于无法事先确定给定属性是否可编辑，因此需要提供一种机制，以允许发送方指示哪些属性可编辑，哪些属性不可编辑，并让接收方检测“不可编辑”属性的修改。通过实现端到端安全性，可以检测完整性保护属性的未经授权的添加、删除或修改。但是，流氓代理仍然可以添加、删除或修改不受完整性保护的属性。如果这些属性影响后续指控，那么欺诈的可能性仍然存在。
RADIUS as defined in [3] does not provide for end-to-end confidentiality. As a result, where clients authenticate using PAP, each proxy along the path between the local NAS and the home server will have access to the cleartext password. In many circumstances, this represents an unacceptable security risk.
[3]中定义的RADIUS不提供端到端的保密性。因此，在客户端使用PAP进行身份验证的情况下，本地NAS和家庭服务器之间的路径上的每个代理都可以访问明文密码。在许多情况下，这是一种不可接受的安全风险。
Typically in roaming systems, accounting packets are provided to all the participants along the roaming relationship path, in order to allow them to audit subsequent invoices. RADIUS as described in [3] does not provide for end-to-end security services, including integrity protection or confidentiality. Without end-to-end integrity protection, it is possible for proxies to modify accounting packets or session records. Without end-to-end confidentiality, accounting
通常在漫游系统中，会计数据包沿着漫游关系路径提供给所有参与者，以便允许他们审核后续发票。[3]中所述的RADIUS不提供端到端安全服务，包括完整性保护或保密性。如果没有端到端完整性保护，代理可以修改记帐数据包或会话记录。没有端到端的保密性、会计
data will be accessible to proxies. However, if the objective is merely to prevent snooping of accounting data on the wire, then IPSEC ESP can be used.
代理可以访问数据。但是，如果目标仅仅是防止窃听在线会计数据，则可以使用IPSEC ESP。
In this attack, a man in the middle or rogue proxy collects CHAP-Challenge and CHAP-Response attributes, and later replays them. If this attack is performed in collaboration with an unscrupulous ISP, it can be used to subsequently submit fraudulent accounting records for payment. The system performing the replay need not necessarily be the one that initially captured the CHAP Challenge/Response pair.
在这种攻击中，中间人或流氓代理收集CHAP挑战和CHAP响应属性，并随后重放它们。如果此攻击是与不道德的ISP协作执行的，则可用于随后提交欺诈性会计记录以进行支付。执行重播的系统不一定是最初捕获CHAP质询/响应对的系统。
While RADIUS as described in [3] is vulnerable to replay attacks, without roaming the threat is restricted to proxies operating in the home server's domain. With roaming, such an attack can be mounted by any proxy capable of reaching the home server.
虽然[3]中所述的RADIUS易受重放攻击，但在不漫游的情况下，威胁仅限于在家庭服务器域中运行的代理。通过漫游，任何能够到达家庭服务器的代理都可以发起此类攻击。
In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the home server. RADIUS as described in [3] is vulnerable to such attacks since only Access-Reply and Access-Challenge packets are authenticated.
在这种形式的攻击中，攻击者试图将数据包注入NAS和家庭服务器之间的会话。[3]中描述的RADIUS容易受到此类攻击，因为只有访问应答和访问质询数据包经过身份验证。
In this form of attack, a local proxy transmits fraudulent accounting packets or session records in an effort to collect fees to which they are not entitled. This includes submission of packets or session records for non-existent sessions. Since in RADIUS as described in [3], there is no end-to-end security, a rogue proxy may insert or edit packets without fear of detection.
在这种形式的攻击中，本地代理传输欺诈性会计数据包或会话记录，以收取他们无权收取的费用。这包括为不存在的会话提交数据包或会话记录。由于在[3]中所述的RADIUS中，没有端到端安全性，因此恶意代理可以插入或编辑数据包而不必担心被检测到。
In order to detect submissions of accounting packets or session records for non-existent sessions, parties receiving accounting packets or session records would be prudent to reconcile them with the authentication logs. Such reconciliation is only typically possible when the party acts as an authentication proxy for all sessions for which an accounting record will subsequently be submitted.
为了检测不存在会话的记帐数据包或会话记录的提交，接收记帐数据包或会话记录的各方应谨慎地将其与身份验证日志进行核对。通常，只有当该方充当随后将提交会计记录的所有会话的身份验证代理时，才可能进行此类对账。
In order to make reconciliation easier, home servers involved in roaming include a Class attribute in the Access-Accept. The Class attribute uniquely identifies a session, so as to allow an authentication log entry to be matched with a corresponding accounting packet or session record.
为了简化对账，漫游中涉及的家庭服务器在Access Accept中包含一个Class属性。Class属性唯一地标识会话，以便允许身份验证日志条目与相应的记帐数据包或会话记录相匹配。
If reconciliation is put in place and all accounting log entries without a corresponding authentication are rejected, then the attacker will need to have obtained a valid user password prior to submitting accounting packets or session records on non-existent sessions. While use of end-to-end security can defeat unauthorized injection or editing of accounting or authentication packets by intermediate proxies, other attacks remain feasible. For example, unless replay protection is put in place, it is still feasible for an intermediate proxy to resubmit authentication or accounting packets or session records. In addition, end-to-end security does not provide protection against attacks by the local proxy, since this is typically where end-to-end security will be initiated. To detect such attacks, other measures need to be put in place, such as systems for detecting unusual activity of ISP or user accounts, or for determining whether a user or ISP account is within their credit limit.
如果进行了对账，并且拒绝了所有未经相应身份验证的记帐日志条目，则攻击者需要在提交不存在会话的记帐数据包或会话记录之前获得有效的用户密码。虽然使用端到端安全性可以阻止中间代理对记帐或身份验证数据包进行未经授权的注入或编辑，但其他攻击仍然可行。例如，除非实施重播保护，否则中间代理仍然可以重新提交身份验证或记帐数据包或会话记录。此外，端到端安全性不提供针对本地代理攻击的保护，因为这通常是端到端安全性启动的地方。为了检测此类攻击，需要采取其他措施，例如检测ISP或用户帐户异常活动的系统，或确定用户或ISP帐户是否在其信用限额内的系统。
Note that implementation of the store and forward approach to proxy accounting makes it possible for some systems in the roaming relationship path to receive accounting records that other systems do not get. This can result in audit discrepancies. About the best that is achievable in such cases is to verify that the accounting data is missing by checking against the authentication logs.
请注意，代理记帐的存储转发方法的实现使得漫游关系路径中的某些系统可以接收其他系统无法获取的记帐记录。这可能导致审计差异。在这种情况下，最好的方法是通过检查身份验证日志来验证会计数据是否丢失。
Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of CompuServe, Aydin Edguer of Morningstar, Bill Bulley of Merit, and Steven P. Crain of Shore.Net for useful discussions of this problem space.
感谢太阳微系统公司的帕特·卡尔霍恩、CompuServe公司的马克·比德尔、晨星公司的艾丁·埃德格尔、美德公司的比尔·布里和Shore.Net公司的史蒂文·P·克雷恩对这个问题空间进行了有益的讨论。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
电话：425-936-6605电子邮件：bernarda@microsoft.com
John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785
John R.Vollbrecht Merit Network，Inc.密歇根州安阿伯普利茅斯路4251号，邮编：48105-2785
Phone: 313-763-1206 EMail: jrv@merit.edu
电话：313-763-1206电子邮件：jrv@merit.edu
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。