ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Informational John R. Vollbrecht
<draft-ietf-roamops-auth-09.txt> Merit Networks, Inc.
16 December 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-09.txt>, and expires July 1, 1999. Please send
comments to the authors.
2. Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
3. 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 tech-
niques outlined in this draft do not provide for end-to-end security.
As a result, they are vulnerable to attack from external parties as
well as susceptible to fraud perpetrated by the roaming partners them-
selves. As a result, such methods are not suitable for wide-scale
deployment on the Internet.
Aboba & Vollbrecht Informational [Page 1]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
4. 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
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. The NAI is defined in [6].
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.
5. 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].
6. 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.
Aboba & Vollbrecht Informational [Page 2]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
Proxies serve a number of functions in roaming, including:
Scalability improvement
Authentication forwarding
Capabilities adjustment
Policy implementation
Accounting reliability improvement
Atomic operation
It should be noted that while a number of these functions can be pro-
vided within a new protocol, thus reducing the need to use proxies to
perform these functions, the policy implementation function is funda-
mental and therefore is likely to remain, regardless of the protocol
chosen.
Scalability improvement
Proxy chaining enables implementation of hierarchical for-
warding within roaming systems, which significantly improves
scalability. 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 bilat-
eral agreements and auditing workload.
Capabilities adjustment
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 with the NAS. Such editing may include
addition, deletion, or modification of attributes. In addi-
tion, in some cases it may be desirable for a proxy to edit
attributes within an Access-Request. Note that if the proxy
edits attributes within the Access-Accept, then it is possi-
ble that the service provided to the user may not be the
same as that requested by the home server. Note that capa-
bilities adjustment provided by proxies goes beyond capabil-
ities negotiation in that proxies may enable communication
between NASes and home servers with very different feature
sets.
Authentication forwarding
Since roaming partners typically do not communicate directly
due to scalability concerns, 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
Aboba & Vollbrecht Informational [Page 3]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
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 proper routing
of authentication and accounting packets. For reasons that
are described in the security section, it is desirable for
accounting and authentication data 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 done by static configuration in the proxy, or
by some currently undefined pro- tocol 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
RADIUS proxies can be used to implement policy. For example,
a given partner may only be entitled to use of a given NAS
during certain times of the day.
Accounting reliability improvement
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 appli-
cation. 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 sys-
tem 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.
7. 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 agram, the NAS generates a request and sends it to
Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the
Aboba & Vollbrecht Informational [Page 4]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
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 section 7.1 and when the proxy is acting as an
accounting store (as in store and forward), as described in section
7.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 considera-
tions section, this omission results in several security problems.
7.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 th 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 receiv-
ing 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
<--------- <--------- <---------
Aboba & Vollbrecht Informational [Page 5]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
(AcctPxStop) (AcctPxStop)
----------> ---------->
7.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:
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
Aboba & Vollbrecht Informational [Page 6]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
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 refor-
warding the Accounting Request until it receives a Reply.
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 for-
ward 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 shut-
ting down, the proxy can send an Accounting-Request with Acct-Sta-
tus-Type=Accounting-Off (8) to all realms that it forwards to. In
turn, these proxies will also flood the packet to their connected
realms.
8. References
[1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roam-
ing Implementations", RFC 2194, September 1997.
[2] Aboba, B., and G. Zorn, "Roaming Requirements", Internet draft
(work in progress), draft-ietf-roamops-roamreq-10.txt, May 1998.
[3] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen-
tication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[4] Rigney C., "RADIUS Accounting", RFC 2139, April 1997.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Aboba, B., and M. Beadles, "The Network Access Identifier",
Internet draft (work in progress), draft-ietf-roamops-nai-10.txt, May
1998.
Aboba & Vollbrecht Informational [Page 7]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
9. Security Considerations
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. In this case the proxy 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. As a result, a number of secu-
rity threats arise in roaming systems, including:
Message editing
Attribute editing
Theft of passwords
Theft of accounting data
Replay attacks
Connection hijacking
Fraudulent accounting
9.1. Message editing
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 capa-
ble 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.
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-Sta-
tus-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 sys-
tems.
Note that with end-to-end security in place, the end-points would be
able to detect that the message from the home server had been modified
by an intermediary. Presumably, this would result in the modified
packet being silently discarded. Note however that this would affect
the ability of the home server to accept an Acct-Status-Type=Proxy-
Stop message from an intermediate proxy. Messages from such proxies
not implementing end-to-end security cannot be trusted since they
could be used to perpetrate denial of service attacks.
Aboba & Vollbrecht Informational [Page 8]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
However, even if end-to-end security is implemented, a security issue
remains since the Acct-Status-Type=Proxy-Stop message relates to the
status of a request destined for the NAS. Therefore unless the proxy
is trusted to speak for the NAS, then this error indication cannot be
accepted by the home server. 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. In fact, the prob-
lem is even more difficult here, since in RADIUS retransmission is
driven by the NAS. Therefore the home server does not receive
acknowledgement for Access-Accepts and will have no way of knowing
that its response has not been honored.
9.2. Attribute editing
RADIUS as defined in [3] does not provide for either end-to-end secu-
rity 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.
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 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 implementa-
tion 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.
In practice, it is not possible to define a set of guidelines for
attribute editing, since the requirements are very often implementa-
tion-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 is pos-
sible to detect unauthorized addition, deletion, or modification of
integrity-protected attributes. Note that it is still possible for a
rogue proxy to add, delete or modify attributes that are not
integrity-protected. If such attributes influence subsequent charges,
Aboba & Vollbrecht Informational [Page 9]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
then fraud is still possible.
The choice of which attributes are editable can be left up to the
sender of the packet. One way in which this can be achieved is to
enable end-to-end integrity-protection an an attribute-by-attribute
basis. For example, if the home server wishes to guarantee that the
client will be tunneled to a given destination, then it can integrity
protect tunnel attributes. .
If a proxy is unable to accept an integrity protected attribute within
an Access-Request, then it can 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 can 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.
9.3. Theft of passwords or keys
With RADIUS as defined in [3], where clients authenticate using PAP,
or where the Tunnel-Password attribute is included with the Access-
Accept, each proxy along the path between the local NAS and the home
server will have access to the cleartext password or key. In many cir-
cumstances, this represents an unacceptable security risk. As a
result, the end-to-end confidentility is needed in order to protect
against disclosure of attributes to proxies, including User-Password
or Tunnel-Password.
9.4. Integrity and confidentiality of accounting data
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 protec-
tion, it is possible for proxies to modify accounting packets or ses-
sion records. Without end-to-end confidentiality, accounting data will
be accessible to proxies. However, if the objective is merely to pre-
vent snooping of accounting data on the wire, then IPSEC ESP can be
used.
9.5. Replay attacks
In this attack, a man in the middle or rogue proxy collects CHAP-Chal-
lenge 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 pay-
ment. The system performing the replay need not necessarily be the
one that initially captured the CHAP Challenge/Response pair.
While RADIUS as described in [3] is vulnerable to replay attacks,
without roaming the threat is restricted to proxies operating in the
Aboba & Vollbrecht Informational [Page 10]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
home server's domain. With roaming, such an attack can be mounted by
any proxy capable of reaching the home server.
In order to protect against replay attacks, CHAP-Challenge and CHAP-
Response attributes could be protected using end-to-end confidential-
ity. CHAP replay attacks can also be defeated by means of an end-to-
end challenge-response exchange. For example, if the home server
returns an Access-Challenge packet containing a CHAP-Challenge
attribute and maintains state with respect to outstanding challenges,
replay attacks cannot succeed.
However, it should also be noted that end-to-end challenges (as prac-
ticed within the EAP MD5 authentication method, or in the CHAP-Chal-
lenge method described above) are also subject to attacks by rogue
proxies. In such an attack a proxy substitutes a static challenge for
the challenge sent by the home server, and on receiving the response,
checks it against a databases of hashes applied against a dictionary.
This attack can be prevented via use of end-to-end security.
9.6. Connection hijacking
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.
9.7. Fraudulent accounting
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.
In order to detect submissions of accounting packets or session
records for non-existent sessions, parties receiving accounting pack-
ets 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 roam-
ing include a Class attribute in the Access-Accept. The Class
attribute uniquely identifies a session, so as to allow an authentica-
tion log entry to be matched with a corresponding accounting packet or
session record.
If reconciliation is put in place and all accounting log entries with-
out 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
Aboba & Vollbrecht Informational [Page 11]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
use of end-to-end security can defeat unauthorized injection or edit-
ing 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 activ-
ity of ISP or user accounts, or for determining whether a user or ISP
account is within their credit limit.
Note that implementation of the store and forward approach to proxy
accounting makes it possible for some systems in the roaming relation-
ship path to receive accounting records that other systems do not get.
This can result in audit discrepancies. About the best that is achiev-
able in such cases is to verify that the accounting data is missing by
checking against the authentication logs.
10. 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.
11. 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: 313-763-1206
EMail: jrv@merit.edu
12. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
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 implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
Aboba & Vollbrecht Informational [Page 12]
INTERNET-DRAFT Proxy Chaining and Policy in Roaming 16 December 1998
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other Inter-
net 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 permis-
sions 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 WAR-
RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
13. Expiration Date
This memo is filed as <draft-ietf-roamops-auth-09>, and expires July
1, 1999.
Aboba & Vollbrecht Informational [Page 13]
