One document matched: draft-ietf-roamops-auth-07.txt
Differences from draft-ietf-roamops-auth-06.txt
ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Standards Track John R. Vollbrecht
<draft-ietf-roamops-auth-07.txt> Merit Network, Inc.
October 8, 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
material 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 ds.internic.net (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-07.txt>, and expires April 15, 1999. Please send
comments to the authors.
2. Abstract
This document describes the use of 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/authorization via the protocol described in
[3], and for accounting as described in [4].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
Aboba & Vollbrecht [Page 1]
INTERNET-DRAFT October 8, 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 com-
panies and ISPs, relationships among peer ISPs within a
roaming 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 authen-
tication requests through a central proxy, only 100 shared secrets
Aboba & Vollbrecht [Page 2]
INTERNET-DRAFT October 8, 1998
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 Identif-
ier (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.
Note: The way a proxy learns the mapping between NAI and end servers
is beyond the scope of this document. This mapping can be done by
static configuration in the proxy, or by some currently undefined pro-
tocol that get the mapping information dynamically. The assumption is
that such a mapping exists in the proxy.
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 a given NAS during certain
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
Aboba & Vollbrecht [Page 3]
INTERNET-DRAFT October 8, 1998
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
and Accounting Requests.
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 the Policy implementation section below and when the
proxy is acting as an accounting Store (as in store and forward)
point, as described in the Accounting Behavior section below.
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-
Signature attributes SHOULD be included in packets sent between admin-
istrative 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-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.
Aboba & Vollbrecht [Page 4]
INTERNET-DRAFT October 8, 1998
(Access-Req) (Access-Req) (Access-Req)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
(Access-Reject) (Access-Accept) (Access-Accept) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
6.2. Accounting behavior
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 ses-
sions), 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.
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:
Aboba & Vollbrecht [Page 5]
INTERNET-DRAFT October 8, 1998
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 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) forarding the Accounting Request and not sending a Reply until
iet 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.
This ensures that Accounting Start and Stop messages are received, and
can be logged by all servers along the authentication/authorization
path. 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 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-
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.
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 from the home server
with sets of attributes appropriate for a particular NAS.
In practice, it is not possible to define a set of guidelines for
attribute editing, since the requirements are very often
implementation-specific. However, using the end-to-end security attri-
butes 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
Aboba & Vollbrecht [Page 6]
INTERNET-DRAFT October 8, 1998
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-Request
with Acct-Status-Type=Proxy-Stop (6) to the home server.
8. Acknowledgments
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.
9. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance,
Asiainfo, Merit, September 1997.
[2] B. Aboba, G. Zorn. "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.
Aboba & Vollbrecht [Page 7]
INTERNET-DRAFT October 8, 1998
[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.
Ann Arbor, MI 48105-2785
Phone: 734-763-1206
EMail: jrv@merit.edu
Aboba & Vollbrecht [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 18:37:31 |