rfc2607.txt

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

   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: [phone]
   EMail: [e-mail]


   John R. Vollbrecht
   Merit Network, Inc.
   4251 Plymouth Rd.
   Ann Arbor, MI 48105-2785

   Phone: [phone]
   EMail: [e-mail]

































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]