rfc2607.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 844 行 · 第 1/3 页
TXT
844 行
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.
1. Abstract
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.
2. Terminology
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.
RADIUS server
This is a server which provides for authentication/authorization
via the protocol described in [3], and for accounting as described
in [4].
Aboba & Vollbrecht Informational [Page 1]
RFC 2607 Proxy Chaining and Policy in Roaming June 1999
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.
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].
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.
3. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [5].
4. Introduction
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.
Aboba & Vollbrecht Informational [Page 2]
RFC 2607 Proxy Chaining and Policy in Roaming June 1999
4.1. Advantages of proxy chaining
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.
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.
Aboba & Vollbrecht Informational [Page 3]
RFC 2607 Proxy Chaining and Policy in Roaming June 1999
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.
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.
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.
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
Aboba & Vollbrecht Informational [Page 4]
RFC 2607 Proxy Chaining and Policy in Roaming June 1999
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.
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.
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.
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. Proxy chaining
An example of a proxy chaining system is shown below.
(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
Aboba & Vollbrecht Informational [Page 5]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?