doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc2607.txt b/doc/rfc/rfc2607.txt
new file mode 100644
index 0000000..2d34c5b
--- /dev/null
+++ b/doc/rfc/rfc2607.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                           B. Aboba
+Request for Comments: 2607                         Microsoft Corporation
+Category: Informational                                    J. Vollbrecht
+                                                    Merit Networks, Inc.
+                                                               June 1999
+
+
+          Proxy Chaining and Policy Implementation in Roaming
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1.  Abstract
+
+   This document describes how proxy chaining and policy implementation
+   can be supported in roaming systems. The mechanisms described in this
+   document are in current use.
+
+   However, as noted in the security considerations section, the
+   techniques outlined in this document are vulnerable to attack from
+   external parties as well as susceptible to fraud perpetrated by the
+   roaming partners themselves. As a result, such methods are not
+   suitable for wide-scale deployment on the Internet.
+
+2.  Terminology
+
+   This document frequently uses the following terms:
+
+   Network Access Server
+      The Network Access Server (NAS) is the device that clients contact
+      in order to get access to the network.
+
+   RADIUS server
+      This is a server which provides for authentication/authorization
+      via the protocol described in [3], and for accounting as described
+      in [4].
+
+
+
+
+
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 1]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+   RADIUS proxy
+      In order to provide for the routing of RADIUS authentication and
+      accounting requests, a RADIUS proxy can be employed. To the NAS,
+      the RADIUS proxy appears to act as a RADIUS server, and to the
+      RADIUS server, the proxy appears to act as a RADIUS client.
+
+   Network Access Identifier
+      In order to provide for the routing of RADIUS authentication and
+      accounting requests, the userID field used in PPP (known as the
+      Network Access Identifier or NAI) and in the subsequent RADIUS
+      authentication and accounting requests, can contain structure.
+      This structure provides a means by which the RADIUS proxy will
+      locate the RADIUS server that is to receive the request. The NAI
+      is defined in [6].
+
+   Roaming relationships
+      Roaming relationships include relationships between companies and
+      ISPs, relationships among peer ISPs within a roaming association,
+      and relationships between an ISP and a roaming consortia.
+      Together, the set of relationships forming a path between a local
+      ISP's authentication proxy and the home authentication server is
+      known as the roaming relationship path.
+
+3.  Requirements language
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
+   described in [5].
+
+4.  Introduction
+
+   Today, as described in [1], proxy chaining is widely deployed for the
+   purposes of providing roaming services. In such systems,
+   authentication/authorization and accounting packets are routed
+   between a NAS device and a home server through a series of proxies.
+   Consultation of the home server is required for password-based
+   authentication, since the home server maintains the password database
+   and thus it is necessary for the NAS to communicate with the home
+   authentication server in order to verify the user's identity.
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 2]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+4.1.  Advantages of proxy chaining
+
+   Proxies serve a number of functions in roaming, including:
+
+   Scalability improvement
+   Authentication forwarding
+   Capabilities adjustment
+   Policy implementation
+   Accounting reliability improvement
+   Atomic operation
+
+   Scalability improvement
+      In large scale roaming systems, it is necessary to provide for
+      scalable management of keys used for integrity protection and
+      authentication.
+
+      Proxy chaining enables implementation of hierarchical
+      forwarding within roaming systems, which improves scalability
+      in roaming consortia based on authentication protocols without
+      automated key management.  Since RADIUS as described in [3]
+      requires a shared secret for each client-server pair, a
+      consortium of 100 roaming partners would require 4950 shared
+      secrets if each partner were to contact each other directly,
+      one for each partner pair.  However, were the partners to
+      route authentication requests through a central proxy, only
+      100 shared secrets would be needed, one for each partner. The
+      reduction in the number of partner pairs also brings with it
+      other benefits, such as a reduction in the number of bilateral
+      agreements and accounting and auditing overhead.  Thus,
+      hierarchical routing might be desirable even if an
+      authentiation protocol supporting automated key exchange were
+      available.
+
+   Capabilities adjustment
+      As part of the authentication exchange with the home server,
+      the NAS receives authorization parameters describing the
+      service to be provided to the roaming user.  Since RADIUS,
+      described in [3], does not support capabilities negotiation,
+      it is possible that the authorization parameters sent by the
+      home server will not match those required by the NAS. For
+      example, a static IP address could be specified that would not
+      be routable by the NAS. As a result, capbilities adjustment is
+      performed by proxies in order to enable communication between
+      NASes and home servers with very different feature sets.
+
+
+
+
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 3]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+      As part of capabilities adjustment, 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
+      addition, in some cases it may be desirable for a proxy to
+      edit attributes within an Access-Request in order to clean up
+      or even hide information destined for the home server.  Note
+      that if the proxy edits attributes within the Access-Accept,
+      then it is possible that the service provided to the user may
+      not be the same as that requested by the home server. This
+      creates the possibility of disputes arising from inappropriate
+      capabilities adjustment.
+
+      Note that were roaming to be implemented based on an
+      authentication/authorization protocol with built-in capability
+      negotiation, proxy-based capabilities adjustment would
+      probably not be necessary.
+
+   Authentication forwarding
+      Since roaming associations frequently implement hierarchical
+      forwarding in order to improve scalability, 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 forwarding of
+      authentication and accounting packets. For reasons that are
+      described in the security section, in proxy systems it is
+      desirable for accounting and authentication packets 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 accomplished by static configuration in the
+      proxy, or by some currently undefined protocol 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
+      In roaming systems it is often desirable to be able to
+      implement policy. For example, a given partner may only be
+      entitled to use of a given NAS during certain times of the
+      day. In order to implement such policies, proxies may be
+      implemented at the interface between administrative domains
+      and programmed to modify authentication/authorization packets
+      forwarded between the NAS and the home server. As a result,
+      from a security point of view, a proxy implementing policy
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 4]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+      operates as a "man in the middle."
+
+   Accounting reliability improvement
+      In roaming systems based on proxy chaining, it is necessary
+      for accounting information to be forwarded between the NAS and
+      the home server. Thus roaming is inherently an interdomain
+      application.
+
+      This represents a problem since the RADIUS accounting
+      protocol, described in [4] is not designed for use on an
+      Internet scale.  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 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. Proxies can
+      be used to ensure atomic delivery of accounting data by
+      arranging for delivery of the accounting data in a serial
+      fashion, as discussed in section 5.2.
+
+5.  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
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 5]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+   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 5.1 and when the proxy is acting as an
+   accounting store (as in store and forward), as described in section
+   5.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
+   considerations section, this omission results in several security
+   problems within proxy chaining systems.
+
+5.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
+   receiving an Access-Reject from a proxy or from the home server.
+
+
+
+
+
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 6]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+         (Access-Req)       (Access-Req)       (Access-Req)
+     NAS ----------> Proxy1 ----------> Proxy2 ---------->     Home
+         (Access-Reject)    (Access-Accept)    (Access-Accept) Server
+         <---------         <---------         <---------
+                            (AcctPxStop)       (AcctPxStop)
+                            ---------->        ---------->
+
+5.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
+   sessions), 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           Informational                      [Page 7]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+                      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) 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
+   reforwarding 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
+   forward 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 shutting
+   down, the proxy can 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.
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 8]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+6.  References
+
+   [1]  Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
+        Roaming Implementations", RFC 2194, September 1997.
+
+   [2]  Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
+        Protocols", RFC 2477, January 1999.
+
+   [3]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+        Authentication 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", RFC
+        2486, January 1999.
+
+7.  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, and proxies 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.  This results in a number of
+   security threats, including:
+
+      Message editing
+      Attribute editing
+      Theft of passwords
+      Theft and modification of accounting data
+      Replay attacks
+      Connection hijacking
+      Fraudulent accounting
+
+7.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 capable of perpetrating a number of man-in-the-middle
+   attacks.  These include modification of messages.
+
+
+
+
+
+Aboba & Vollbrecht           Informational                      [Page 9]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+   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-
+   Status-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
+   systems.
+
+   It should be noted that even if end-to-end security were to be
+   available, a number of sticky questions would remain. While the end-
+   points would be able to detect that the message from the home server
+   had been modified by an intermediary, the question arises as to what
+   action should be taken. While the modified packet could be silently
+   discarded, this could affect the ability of the home server to .
+   accept an Acct-Status-Type=Proxy-Stop message from an intermediate
+   proxy. Since this message would not be signed by the NAS, it may need
+   to be dropped 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. The problem is more difficult here, since in
+   RADIUS retransmission is driven by the NAS.  Therefore the home
+   server does not receive acknowledgement for Access-Accepts and thus
+   would have no way of knowing that its response has not been honored.
+
+7.2.  Attribute editing
+
+   RADIUS as defined in [3] does not provide for end-to-end security 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
+
+
+
+Aboba & Vollbrecht           Informational                     [Page 10]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+   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
+   implementation 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
+   implementation-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 may be
+   possible to detect unauthorized addition, deletion, or modification
+   of integrity-protected attributes. However, it would still possible
+   for a rogue proxy to add, delete or modify attributes that are not
+   integrity-protected. If such attributes influence subsequent charges,
+   then the possibility of fraud would remain.
+
+7.3.  Theft of passwords
+
+   RADIUS as defined in [3] does not provide for end-to-end
+   confidentiality. As a result, where clients authenticate using PAP,
+   each proxy along the path between the local NAS and the home server
+   will have access to the cleartext password. In many circumstances,
+   this represents an unacceptable security risk.
+
+7.4.  Theft and modification 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
+   protection, it is possible for proxies to modify accounting packets
+   or session records.  Without end-to-end confidentiality, accounting
+
+
+
+Aboba & Vollbrecht           Informational                     [Page 11]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+   data will be accessible to proxies.  However, if the objective is
+   merely to prevent snooping of accounting data on the wire, then IPSEC
+   ESP can be used.
+
+7.5.  Replay attacks
+
+   In this attack, a man in the middle or rogue proxy collects CHAP-
+   Challenge 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 payment.  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.
+
+7.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.
+
+7.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
+   packets 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
+   roaming include a Class attribute in the Access-Accept.  The Class
+   attribute uniquely identifies a session, so as to allow an
+   authentication log entry to be matched with a corresponding
+   accounting packet or session record.
+
+
+
+
+Aboba & Vollbrecht           Informational                     [Page 12]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+   If reconciliation is put in place and all accounting log entries
+   without 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 use of end-to-end security can defeat unauthorized
+   injection or editing 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 activity 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
+   relationship path to receive accounting records that other systems do
+   not get. This can result in audit discrepancies. About the best that
+   is achievable in such cases is to verify that the accounting data is
+   missing by checking against the authentication logs.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Vollbrecht           Informational                     [Page 13]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+9.  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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Vollbrecht           Informational                     [Page 14]
+
+RFC 2607          Proxy Chaining and Policy in Roaming         June 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 implementation 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
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet 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 permissions 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 WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Vollbrecht           Informational                     [Page 15]
+