Proxy Chaining and Policy Implementation in Roaming
RFC 2607
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
Show full document text