ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Standards Track John R. Vollbrecht
<draft-ietf-roamops-auth-06.txt> Merit Networks, Inc.
20 July 1998
Proxy Chaining and Policy Implementation in Roaming
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-roamops-auth-06.txt>, and expires January 15, 1999. Please send
comments to the authors.
2. Abstract
This document describes the proxy chaining in roaming and how policy
may be implemented concurrently with end-to-end security.
3. 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/autho-
rization via the protocol described in [3], and for account-
ing as described in [4].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
Aboba & Vollbrecht [Page 1]
INTERNET-DRAFT 20 July 1998
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 subse-
quent 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.
Roaming relationships
Roaming relationships include relationships between compa-
nies and ISPs, relationships among peer ISPs within a roam-
ing association, and relationships between an ISP and a
roaming consortia. Together, the set of relationships form-
ing a path between a local ISP's authentication proxy and
the home authentication server is known as the roaming rela-
tionship path.
4. 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 [8].
5. Introduction
Today, as described in [1], proxy chaining is widely deployed for the
purposes of providing roaming services. In such systems, authentica-
tion and accounting packets are routed between a NAS device and a home
server through a series of proxies.
Proxies serve a number of functions in roaming, including:
Scalability improvement
Authentication forwarding
Network parameter adjustment
Policy implementation
Accounting reliability improvement
Proxy chaining enables implementation of hierarchical forwarding
within roaming systems, which significantly improves scalability.
Since RADIUS requires a shared secret for each communicating pair of
systems, 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
Aboba & Vollbrecht [Page 2]
INTERNET-DRAFT 20 July 1998
secrets would be needed, one for each partner.
Since roaming partners typically do not communicate directly due to
scalability concerns, in order for a NAS and home server to communi-
cate, authentication and accounting packets are forwarded by one or
more proxies. The path travelled by these packets, known as the roam-
ing relationship path, is determined from the Network Access Identi-
fier (NAI), described in [9]. Since most NAS devices do not implement
forwarding logic, a proxy is needed to enable proper routing of
authentication and accounting packets.
Since RADIUS does not support capabilities negotiation, it is possible
that network parameters sent back from the home server will not match
those required by the NAS. Proxies can edit attributes within the
Access-Accept in order to ensure compatibility. In addition, in some
cases it may be desirable for a proxy to edit attributes within an
Access-Request.
RADIUS proxies can also be used to implement policy. For example, a
given partner may only be entitled to use of a given NAS during cer-
tain times of the day.
The RADIUS accounting protocol, described in [4] is not designed for
use on an Internet scale. This is a significant issue in roaming,
which is inherently an interdomain application. 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 per-
sistent storage of accounting records and long duration retry. In
addition, proxies may serve to implement a "poor man's transaction"
capability, ensuring that all entities along the roaming relationship
path receive accounting information.
6. 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 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
Aboba & Vollbrecht [Page 3]
INTERNET-DRAFT 20 July 1998
and Accounting Requests. Except where policy is being implemented
(described below), a proxy server such as Proxy2 in the diagram below
SHOULD NOT send a Reply packet to Proxy1 without first having received
a Reply packet initiated by the home server.
While the RADIUS protocol described in [3] does not provide for end-
to-end security services, this is made possible using the attributes
described in [10]. The Security-Parameter-Index and End-to-End-Signa-
ture attributes SHOULD be included in packets sent between administra-
tive domains, including Access-Request, Access-Challenge, Access-
Accept, and Access-Reject packets. The Hidden attribute MAY be
included as necessary, in order to prevent disclosure of passwords or
keys to untrusted proxies.
6.1. Policy implementation
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 the Access-Request. This situation
is shown below:
(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 message with Acct-Status-
Type=Proxy-Stop 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.
(Access-Req) (Access-Req) (Access-Req)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Access-Reject) (Access-Accept) (Access-Accept) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
Aboba & Vollbrecht [Page 4]
INTERNET-DRAFT 20 July 1998
6.2. Accounting behavior
As described above, a proxy MUST NOT reply directly with an ccess-
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 ses-
sions), no direct replies have occurred, and the Access-Request and
Access-Accept have passed through the same set of ystems.
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 as did
authentication/authorization packets, machine by machine. 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.
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 Class attribute. The NAS MUST include the Class
attribute in subsequent requests, in particular for Accounting-
Requests. The sequence of events is shown below:
Authentication/Authorization
--------> --------> --------->
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
<--------- <--------- <---------
Since there is no need to implement policy in accounting, a proxy
SHOULD NOT reply directly to Accounting-Requests, and a proxy server
such as Proxy2 in the diagram below SHOULD NOT send an Accounting-
Reply packet to Proxy1 without first having received an Accounting-
Reply packet initiated by the home server. This ensures when a NAS
receives an Accounting-Reply the Accounting-Request will have been
Aboba & Vollbrecht [Page 5]
INTERNET-DRAFT 20 July 1998
received by all systems along the authentication/authorization path.
Note that there are cases where a proxy may 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 may need to send an Accounting-Request with Acct-Sta-
tus-Type=Accounting-Off to all realms that it forwards to. In turn,
these proxies will also flood the packet to their connected realms.
7. Attribute editing
One of the biggest obstacles to interoperation of proxies today
results from editing behavior. 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 network.
In practice, it is not possible to define a set of guidelines for
attribute editing, since the requirements are very often implementa-
tion-specific. However, using the end-to-end security attributes
defined in [10], it is possible to provide for both "protected" and
"unprotected" attributes. Protected attributes preceed an End-to-End-
Signature attribute within the packet, and as a result, these
attributes are integrity-protected end-to-end. Protected attributes
MUST NOT be added, deleted, or modified by a proxy.
Unprotected attributes follow the End-to-End-Signature attribute, and
are not covered by the message integrity check. As a result, these
attributes MAY be added, deleted, or modified by a proxy.
The choice of which attributes are protected or unprotected is left up
to the sender of the packet. For example, if the home server wishes to
guarantee that the client will be tunneled to a given destination,
then it will integrity protect tunnel attributes by placing them prior
to the End-to-End-Signature attribute. In general, home servers SHOULD
protect attributes whose modification would compromise security,
including tunnel attributes, and EAP-Message attributes.
If a proxy is unable to accept a protected attribute within an Access-
Request, then it MUST reply to the NAS with an Access-Reject packet.
If a proxy is unable to accept a protected attribute within an Access-
Accept or Access-Challenge packet, then it SHOULD send an Access-
Reject to the NAS, as well as well as an Accounting message with Acct-
Status-Type=Proxy-Stop to the home server.
8. Acknowledgments
Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of CompuServe,
Aydin Edguer of Morningstar, and Steven P. Crain of Shore.Net for use-
ful discussions of this problem space.
Aboba & Vollbrecht [Page 6]
INTERNET-DRAFT 20 July 1998
9. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi-
ainfo, Merit, September 1997.
[2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." Internet
draft (work in progress), draft-ietf-roamops-roamreq-10.txt,
Microsoft, May 1998.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April
1997.
[5] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work
in progress), draft-ietf-radius-ext-01.txt, Livingston, December 1997.
[6] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC
2068, UC Irvine, January 1997.
[7] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[8] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March 1997.
[9] B. Aboba, M. Beadles. "The Network Access Identifier." Internet
draft (work in progress), draft-ietf-roamops-nai-10.txt, Microsoft,
CompuServe, May 1998.
[10] P. Calhoun and B. Aboba. "End-to-End Security in Roaming."
Internet draft (work in progress), draft-ietf-roamops-roamsec-01.txt,
Sun Microsystems, Microsoft, July 1998.
10. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
John R. Vollbrecht
Merit Network, Inc.
4251 Plymouth Rd.
Aboba & Vollbrecht [Page 7]
INTERNET-DRAFT 20 July 1998
Ann Arbor, MI 48105-2785
Phone: 313-763-1206
EMail: jrv@merit.edu
s
Aboba & Vollbrecht [Page 8]
