Movatterモバイル変換

Network Working Group                                           B. AbobaRequest for Comments: 2607                         Microsoft CorporationCategory: Informational                                    J. Vollbrecht                                                    Merit Networks, Inc.                                                               June 1999Proxy Chaining and Policy Implementation in RoamingStatus 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 19994.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 policyAboba & 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 insection 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. Proxy1Aboba & 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 insection 5.1 and when the proxy is acting as an   accounting store (as in store and forward), as described insection5.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 19996.  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",RFC2486, 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 accounting7.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 securityAboba & 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, accountingAboba & 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 19999.  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.eduAboba & Vollbrecht           Informational                     [Page 14]

RFC 2607          Proxy Chaining and Policy in Roaming         June 199910.  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]