ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     Category: Standards Track                           John R. Vollbrecht
     <draft-ietf-roamops-auth-08.txt>                  Merit Networks, Inc.
     13 October 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 (US East Coast), (Europe), (US West Coast), or (Pacific Rim).
     The distribution of this memo is unlimited.  It is  filed  as  <draft-
     ietf-roamops-auth-08.txt>, and  expires May 1, 1999.  Please send com-
     ments to the authors.
     2.  Copyright Notice
     Copyright (C) The Internet Society (1998).  All Rights Reserved.
     3.  Abstract
     This document describes the use of proxy chaining in roaming  and  how
     policy may be implemented concurrently with end-to-end security.
     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
     Aboba & Vollbrecht          Standards Track                   [Page 1]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
               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
               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.
     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
     Aboba & Vollbrecht          Standards Track                   [Page 2]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     perform  these functions, the policy implementation function is funda-
     mental and therefore is likely to remain, regardless of  the  protocol
     Scalability improvement
               Proxy  chaining  enables implementation of hierarchical for-
               warding 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  secrets
               would be needed, one for each partner.
     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
               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.
               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 map-
               ping exists in the proxy.
     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. 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.  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.
     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
     Aboba & Vollbrecht          Standards Track                   [Page 3]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
               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
     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
     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  [7].  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
     Aboba & Vollbrecht          Standards Track                   [Page 4]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     included, as necessary, in order to prevent disclosure of passwords or
     keys to untrusted proxies.
     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 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 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
           <---------         <---------         <---------
                              (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
     Aboba & Vollbrecht          Standards Track                   [Page 5]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     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:
           -------->         -------->          --------->
      NAS            Proxy1              Proxy2             Home (add class)
          <-class--          <-class-           <-class--
          (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
     it  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.  Note  that  in  the
     former  arrangement,  atmoic  operation can be supported, while in the
     latter case it typically cannot.
     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
     Aboba & Vollbrecht          Standards Track                   [Page 6]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     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
     8.  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 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.  However,  using  the  end-to-end  security  attributes
     defined  in  [7],  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-Request with Acct-
     Status-Type=Proxy-Stop (6) to the home server.
     9.  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.
     Aboba & Vollbrecht          Standards Track                   [Page 7]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     [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
     [7]  Calhoun, P., and B.  Aboba,  "End-to-End  Security  in  Roaming",
     Internet  draft (work in progress), draft-ietf-roamops-roamsec-01.txt,
     July 1998.
     10.  Security Considerations
     The following security threats have been identified  in  roaming  sys-
        Rogue proxies
        Theft of passwords
        Theft of accounting data
        Replay attacks
        Connection hijacking
        Fraudulent accounting
     10.1.  Rogue proxies
     In conventional ISP application, the NAS, proxy, and home server exist
     within a single administrative entity. As a result, the proxy  may  be
     considered a trusted component.
     However, in a roaming system implemented with proxy chaining, the NAS,
     proxies, and home server may be managed  by  different  administrative
     entities. Through the use of shared secrets it is possible for proxies
     operating in different domains to establish a trust relationship. How-
     ever,  if  packets  are only authenticated on a hop-by-hop basis, then
     untrusted proxies are capable of perpetrating a number of  man-in-the-
     middle attacks.
     These attacks typically involve the editing of attributes, or the mod-
     ification or insertion of messages, such as  the  substitution  of  an
     Access-Accept  for  an Access-Reject.  For example, a proxy may modify
     an Access-Accept sent by the home server so as to lessen the  security
     obtained  by  the client. 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, tun-
     nel attributes might be removed or modified so as  to  remove  encryp-
     tion,  redirect  the  tunnel  to  a  rogue tunnel server, or otherwise
     lessen the security provided to the client.
     Through implementation of the End-to-End-Signature  attribute,  it  is
     possible to detect unauthorized addition, deletion, or modification of
     Aboba & Vollbrecht          Standards Track                   [Page 8]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     protected attributes. Note that it is still possible for a rogue proxy
     to add, delete or modify unprotected attributes.
     While  a proxy MUST NOT send an Access-Accept to the NAS after receiv-
     ing an Access-Reject from the home server, a proxy MAY send an Access-
     Reject  to  the  NAS  after  receiving  an Access-Accept from the home
     server. Note that  in  the  latter  case,  a  Security-Parameter-Index
     attribute should be used denoting the security association between the
     proxy and the NAS, rather than that between the home  server  and  the
     NAS,  since  the  proxy has originated the packet. This will allow the
     NAS to verify the End-to-End-Signature attribute  within  the  packet,
     and  decide whether to silently discard the packet.  As noted earlier,
     an Access-Accept originated by a proxy MUST be silently  discarded  by
     the NAS, even if the End-to-End-Signature attribute can be verified.
     The  determination  of  whether end-to-end security is to be used in a
     conversation is made using out-of-band mechanisms. Typically  this  is
     based  either  on  static  configuration  or  on  the outcome of a key
     exchange conversation between the two endpoints.  However, once it  is
     determined  that  the end systems wish to use end-to-end security, all
     packets sent MUST include an End-to-End-Signature attribute and  pack-
     ets   received  without  an  End-to-End-Signature  attribute  MUST  be
     silently discarded. Note that policy determination  using  an  out-of-
     band  mechanism  rather than a proxied conversation limits the ability
     of a rogue proxy to interfere with the  security  negotiation  between
     the two end systems.
     10.2.  Theft of passwords or keys
     Unless  the Hidden attribute is used, 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
     circumstances,  this  represents  an unacceptable security risk.  As a
     result, the Hidden attribute SHOULD be used to provide end-to-end con-
     fidentiality for User-Password or Tunnel-Password attributes.
     10.3.  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. In order to prevent modifica-
     tion of accounting packets by untrusted proxies, the End-to-End-Signa-
     ture  attribute  MAY be used. If it is desired that accounting data be
     kept confidential from a proxy, the Hidden attribute MAY be  used.  If
     the  objective  is to prevent snooping of accounting data on the wire,
     then IPSEC ESP MAY be used.
     Aboba & Vollbrecht          Standards Track                   [Page 9]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     10.4.  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
     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 MAY be protected using the Hidden attribute.  CHAP
     replay attacks can also be defeated by means of  an  end-to-end  chal-
     lenge-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 may be prevented through use of  the  End-to-End-Signature
     10.5.  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.  This  attack  may  be
     defeated  via use of an End-to-End-Signature attribute as described in
     10.6.  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..
     In  order  to  detect  submissions  of  accounting  packets or session
     records for non-existent sessions, parties receiving accounting  pack-
     ets  or session records will typically wish 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
     Aboba & Vollbrecht          Standards Track                  [Page 10]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     which an accounting record will subsequently be submitted.
     In order to make reconciliation easier, home servers involved in roam-
     ing  SHOULD include a Class attribute in the Access-Accept.  The Class
     attribute SHOULD uniquely identify  a  session,  so  as  to  allow  an
     authentication log entry to be matched with a corresponding accounting
     packet or session record.
     Note that in order to prevent submission of accounting packets or ses-
     sion  records  for  non-existent  sessions, it is necessary to prevent
     11.  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.
     12.  Authors' Addresses
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     Phone: 425-936-6605
     John R. Vollbrecht
     Merit Network, Inc.
     4251 Plymouth Rd.
     Ann Arbor, MI 48105-2785
     Phone: 313-763-1206
     13.  Full Copyright Statement
     Copyright (C) The Internet Society (1997).  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,
     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
     Aboba & Vollbrecht          Standards Track                  [Page 11]

     INTERNET-DRAFT   Proxy Chaining and Policy in Roaming  13 October 1998
     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
     14.  Expiration Date
     This  memo is filed as <draft-ietf-roamops-auth-08>,  and  expires May
     1, 1999.
     Aboba & Vollbrecht          Standards Track                  [Page 12]