rfc2607.txt

中、英文RFC文档大全打包下载完全版 .


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