Internet Engineering Task Force K. Hoeper, Ed. Internet Draft NIST Intended status: Informational October 3, 2008 Expires: April 3, 2009 Threat Model for Networks Employing AAA Proxies draft-hoeper-proxythreat-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo defines a threat model for access networks with AAA proxies. Use cases of current and future applications in which AAA proxies are employed are described and it is discussed how proxies could launch attacks in the defined use cases. The risk associated with these attacks in each use case is analyzed. As a result, this draft can serve as a guideline for risk assessments by providers, implementers and protocol designers of systems with proxies. Hoeper Expires April 3, 2009 [Page 1] Internet-Draft AAA Proxy Threat Model October 2008 Table of Contents 1. Introduction...................................................2 1.1. Goals of this Document....................................3 1.2. Scope.....................................................4 1.3. Terminology...............................................4 2. Problem Statement..............................................5 3. Related Work...................................................6 4. Use Cases......................................................6 4.1. Enterprise Network Management.............................6 4.2. Free International Roaming................................7 4.3. Billable International Roaming............................9 5. Threat Model...................................................9 5.1. Network Entities and their Trust Relationships............9 5.2. Potential Attacks........................................10 6. Risk Analysis.................................................12 6.1. Feasibility..............................................12 6.2. Severity.................................................13 7. Security Considerations.......................................14 8. IANA Considerations...........................................14 9. Conclusions...................................................14 10. Acknowledgments..............................................15 11. References...................................................15 11.1. Normative References....................................15 11.2. Informative References..................................15 Authors' Addresses...............................................16 Intellectual Property Statement..................................16 Disclaimer of Validity...........................................16 1. Introduction Currently, AAA proxies are implemented in many access networks serving a variety of purposes. For example, proxies provide a scalable solution for access management in large networks. Furthermore, proxies can enable roaming because mobile nodes (MN) can access other networks by authenticating to their home server through local proxies. Some of these tasks require proxies to possess AAA keying material. The introduction of proxies can change the security model of a network as well as of the implemented protocols. As a consequence, AAA proxies may introduce new security vulnerabilities. However, currently the role of AAA proxies in networks and all their security implications are not considered in many existing RFCs and Internet drafts. The relationship with RFC 4962 [1] is the most glaring aspect of the problem, but the progress of numerous drafts in a number of Hoeper Expires April 3, 2009 [Page 2] Internet-Draft AAA Proxy Threat Model October 2008 working groups is affected by the so-called "proxy problem". Recently, there have been attempts to reconcile the widespread deployment of AAA proxies with the security requirements of individual Internet protocols or protocol extensions. While the re-occurrence of the proxy problem in several WGs may be bothersome and slow down progress, the problems are more severe for providers and users of already existing implementations with proxies. Doubts exist whether current security claims stated in RFCs and Internet Drafts are still valid for implementations with proxies. Hence, providers of networks with proxies that rely on such security claims may have unknowingly introduced new vulnerabilities to their systems that have not been covered in the respective protocol specifications. For the same reasons, users of such systems may be unknowingly exposed to attacks. Concluding, the proxy problem may affect existing and future implementations of Internet protocols whose specifications neglected proxies in their security considerations. If security issues introduced by proxies are not identified and addressed, future protocol specifications will suffer from the same problems. 1.1. Goals of this Document Since the "proxy problem" challenges the credibility of existing RFCs and slows down the progress of many IETF WGs, it seems necessary to evaluate this problem in detail and make the results available to all current and future IETF WGs and other standard bodies. This document shows how AAA proxies may change the security models of networks and their employed protocols in several use cases. Even more importantly, the document analyses the feasibility as well as severity of the identified threats. As a result, this draft can be used as a tool for risk assessment of a network with AAA proxies or protocols implemented in such networks. This draft shows which attacks by proxies are feasible in particular use cases under certain conditions. It is up to the provider/implementer/protocol designer to decide whether the identified threats justify the costs that would be introduced by countermeasures such as infrastructure and/or protocol modifications Current and future drafts that are subject to the "proxy problem" could reference this document to point out possible vulnerabilities and risks. Hoeper Expires April 3, 2009 [Page 3] Internet-Draft AAA Proxy Threat Model October 2008 Technical solutions addressing the identified vulnerabilities are not presented in this draft. However, authors of affected protocol specifications are encouraged to use the presented threat model to design a case-based security solution or at least highlight proxy- related security vulnerabilities. The threat model presented in this draft could also serve as basis for designing more general solutions in a separate draft. 1.2. Scope This document focuses on security issues related to AAA proxies and the discussions and results in this memo should not be applied to other types of proxies. However, it is encouraged to work on similar documents for other kind of proxies. This document solely identifies security-related issues introduced by AAA proxies and their severity but neither provides solutions to address these problems nor discusses non-security related issues (such as routing, performance, etc.). Furthermore, this document does not consider AAA proxies that are configured to solely serve as a re- direct (as supported by Diameter), because such proxies do not need to gain access to attributes and/or keying material. 1.3. Terminology This section defines terms that are frequently used in this document. AAA Authentication, Authorization, and Accounting (AAA). AAA protocols include RADIUS [2] and Diameter [3]. AAA Server A server which provides AAA services via an implemented AAA protocol to mobile nodes. AAA Client A network entity sending AAA requests to the AAA server and receiving AAA replies from the AAA server. NAS and AAA proxy can both act as AAA client. AAA Proxy An AAA proxy provides routing for AAA requests and replies. An AAA proxy appears to act as an AAA client to the AAA server and as AAA server to the AAA client. In this draft, pure re-direct proxies as supported by Diameter are not considered. Only AAA proxies that are capable of modifying attributes and may possess cryptographic keying material are considered. Hoeper Expires April 3, 2009 [Page 4] Internet-Draft AAA Proxy Threat Model October 2008 MN A mobile node (MN) that wishes to access the network. NAS The Network Access Server (NAS) is the network entity that mobile nodes contact in order to obtain access to the network. Proxy Chain A routing path through a sequence of AAA proxies. In roaming scenarios, when a proxy chain is across different administrative domains, roaming agreements exist between the first and last proxy of the chain as well as between each neighboring pair of proxies. Roaming agreement Roaming agreements include agreements between companies and Internet Service Providers (ISPs), agreements among peer ISPs within a roaming association, and relationships between an ISP and a roaming consortium. These agreements require a certain level of trust among all parties of a roaming agreement. In the context of this draft, roaming agreements between two administrative domains imply that AAA proxies in these domains may share pairwise AAA keys with each other or may be capable of establishing such pairwise keys. 2. Problem Statement Unlike some other network entities that simply forward packets in the network, AAA proxies are designed to have additional capabilities and properties such that the AAA protocols executed through AAA proxies may have the following features: o AAA proxies are able to modify and/or delete AAA attributes o AAA proxies share pairwise AAA keys with the AAA server and/or other AAA proxies; o AAA proxies and NAS cannot be distinguished by AAA server; o AAA proxies and AAA server cannot be distinguished by NAS; o AAA proxy chains cannot be distinguished from single proxies by neither NAS nor AAA server. The above special features may lead to new security vulnerabilities. For example, a proxy could modify or delete some attributes of an AAA request/reply. Or a proxy in possession of AAA keying material can break the end-to-end integrity and/or confidentiality between NAS and Hoeper Expires April 3, 2009 [Page 5] Internet-Draft AAA Proxy Threat Model October 2008 AAA server that is assumed in some protocols. The last three bullets show that the other communicating entities might not even be aware of the proxies on the communication path. In the case of a single proxy or a chain of proxies [4] between NAS and AAA server, not every party authenticates to all parties it communicates with as required in RFC 4962[1]. The sum of these and other security issues imposed by AAA proxies is referred to as "proxy problem" in this document. 3. Related Work [Editor's note: what other references should be mentioned here?] The "Security Consideration" Section of RFC 2607 [4] outlines security threats introduced by proxies in roaming scenarios using RADIUS. These observations and other threats will be further analyzed in this draft in a more general context. For instance, threats introduced by AAA proxies are analyzed in several use cases. In addition, this draft allows an application-based risk analysis. 4. Use Cases [Editor's note: Any more use cases?] For easier identification of vulnerabilities as well as analysis of feasibility and severity of attacks, a representative set of use cases for AAA proxies in networks are supplied here. 4.1. Enterprise Network Management In enterprise networks or other local networks with a single administrative domain, AAA proxies are used to enable easy and scalable network access in large networks. Here-instead of having a direct connection between each NAS and the authentication server- groups of NAS' can be connected to proxies in proximity. The proxies are then attached to the authentication server, resulting in a scalable network infrastructure. This is illustrated in Figure 1 for a network with two AAA proxies, where proxy 1 serves NAS 1 to NAS i and proxy 2 serves NAS j to NAS n. Hierarchical proxy routing can further simplify key management, as has been pointed out in RFC 2607. Note that this would lead to proxy chaining. Other reasons why proxies may be used in enterprise networks are that the administrator wants to assign different sets of offered services and policies for different groups of NAS'. In that case a proxy adjusts the AAA request from a certain NAS to the specified policy for this NAS, and/or adjusts the AAA reply to the capabilities of the NAS. This requires the proxy to modify or delete AAA attributes. For Hoeper Expires April 3, 2009 [Page 6] Internet-Draft AAA Proxy Threat Model October 2008 example, a NAS talking to proxy 1 only supports weak authentications (e.g. to constrained devices) but in return only limited services are made available to MNs connecting through this NAS. On the other hand, requests routed through proxy 2 may demand stronger authentication but provide a larger variety of services and information. +------+ | AAA | +------+ / \ / \ / \ / \ +------+ +------+ |proxy1| |proxy2| +------+ +------+ / \ / \ / \ / \ / \ / \ +----+ +----+ +----+ +----+ |NAS1|..|NASi| |NASj|..|NASn| +----+ +----+ +----+ +----+ Figure 1 Enterprise network with two proxies. 4.2. Free International Roaming AAA proxies are also used to enable roaming across administrative domains with roaming agreements. Note that roaming agreements may imply that proxies from one domain share AAA keys with proxies from the other domain or may be capable of establishing such shared keys. A proxy in domain 1 (lets say the home domain of a MN) can serve as entry point for roaming requests from a domain 2 (lets say a visited domain). Even though the roaming is free in this use case (and thus billing unnecessary), it can be very important in such applications that policies of both domains are observed (e.g. the minimum age of users or minimum security level of provided services). To ensure this, the home proxy may need to adjust incoming AAA requests and outgoing AAA replies according to the capabilities and policies of visited and home networks, respectively, as well as the roaming agreements between them. Note that the path for AAA communications between the visited domain and the home domain may consist of several proxies, i.e. a proxy chain. Here, the roaming agreements between domain 1 and domain 2 specify the relationship between proxies in domain 1 (say the first proxy in the chain) and proxies in domain 2(say the last proxy in the Hoeper Expires April 3, 2009 [Page 7] Internet-Draft AAA Proxy Threat Model October 2008 chain). However, successful AAA functionality may require roaming agreements between each neighboring pair of proxies in the proxy chain (e.g. to share pairwise keys). For this reason, either the existing roaming agreement between domain 1 and domain 2 needs to extend to the intermediated proxies or additional agreements are needed. The described roaming scenario is illustrated in Figure 2. - - - - - - - - - - - - - - - +-------+ Roaming agreements +-------+ | | Local | <==================> | Home | | | AAA | | | | AAA | | +-------+ +-------+ | | | | ^ | | | | | | | | | +-------+ [*proxy chain] +-------+ | | Local | -------- ... ----->| Home | | | Proxy | | | | Proxy | | +-------+ +-------+ | ^ | | | | | | | | | +-------+ | | Local | | | | | NAS | | +-------+ | | | ^ | | | | | | | +------+ | | | | MN | | +------+ | | | | Visited Domain | _|Home Domain | - - - - - - - - - - - - - - - *optional Figure 2 International Roaming Utilizing Proxies An example of an existing network enabling international roaming free of charge is eduroam [5]. Eduroam is a world-wide WLAN roaming network for users in education and research. The network consists of a hierarchy of RADIUS servers interconnecting participating sites. The hierarchy consists of a root level proxy, used for international roaming between different top-level domains, country-level proxy servers for roaming between institutions in the same top level Hoeper Expires April 3, 2009 [Page 8] Internet-Draft AAA Proxy Threat Model October 2008 domain, and institutional servers to perform the actual authentication (these servers may optionally further proxy requests to departments within their own institution at their discretion). Most RADIUS servers are duplicated for resiliency purposes. This architecture leads to a proxy path with at least five RADIUS servers in a chain when roaming internationally. 4.3. Billable International Roaming In many roaming scenarios, the MN will be billed for the used roaming services according to the roaming agreements between the MN's home network and the visited network. The network architecture with proxies is the same as in the previous use case (see Figure 2), however additional billing information needs to be exchanged. Please note that authentication and accounting data may not take the same routing path [4]. As a consequence this document distinguishes between authentication proxy and accounting proxy for this use case. 5. Threat Model To be able to analyze security vulnerabilities introduced by AAA proxies and their risks, a threat model needs to be established first. Section 5.1. describes the different players in the threat model. Section 5.2. defines the attacks an AAA proxy may launch in any of the use cases that have been described in Section 4. 5.1. Network Entities and their Trust Relationships Since this document focuses on potential security risks introduced by AAA proxies, all other network entities (such as AAA servers and NAS) and MNs are assumed to execute all protocol steps faithfully and do not behave maliciously in any way. The practicability of these assumptions is out of scope of this document. The above assumptions are generally based on the following trust relationships: o Within a home domain (can be also considered as an intra-domain) it is assumed that all entities are correctly configured and not controlled by a malicious party. This can be achieved by intrusion detection systems or other means to detect so-called malicious insiders. Hoeper Expires April 3, 2009 [Page 9] Internet-Draft AAA Proxy Threat Model October 2008 o The trust relationships between a home network and other local networks are specified in roaming agreements. These roaming agreements imply that the home network trusts the local network to faithfully carry out the roaming services that have been agreed on under specified conditions (e.g. roaming fees). This document deals with potential security threats introduced by AAA proxies. The attacks (as specified in the next Section) are executed by an AAA proxy that is either controlled by an adversary or mis- configured. In this threat model the following types of malicious proxies are distinguished: 1. Proxies in the home network 2. Proxies in the visited network 3. Proxies in a proxy chain between the home and the visited networks Furthermore, these three proxy types are split into authentication and accounting proxies. 5.2. Potential Attacks A malicious or misconfigured AAA proxy may launch the following attacks: 1. Passively eavesdrop on network traffic Monitoring network traffic is feasible for any entity with access to the network. It does not require any special capabilities or privileges, such as the knowledge of cryptographic keying material. Consequently, this attack is not limited to AAA proxies. Traffic analysis can be used to track the activity and/or mobility of particular users. 2. Replay data packets This attack consists of two phases: (i) the recording of data packets of previous network authentications and (ii) the replaying of this data at a later time. This requires access to the network but no knowledge of keying material. Hence, the attack is not limited to proxies. Hoeper Expires April 3, 2009 [Page 10] Internet-Draft AAA Proxy Threat Model October 2008 Replay attacks are typically prevented by the AAA protocol itself with the aid of time variant information [Editor's note: Is this true?]. 3. Re-direct data packets Any proxy could maliciously re-direct AAA data packets. This requires access to the routing path but no knowledge of keying material. Hence, the attack can also be carried out by routers and is not specific to proxies. It appears that this attack can only be exploited for Denial of Service (DoS) attacks [Editor's note: Is this true?] which are typically not preventable by cryptographic means. 4. Drop data packets As for re-direction attacks, any proxy can drop packets causing re- transmissions that can lead to a denial of service. [Editor's note: Is there any other attack?]. This attack can be executed by all entities on the routing paths, i.e. it is not limited to proxies and, e.g., can also be executed by routers. Note that this attack cannot easily be distinguished from "natural" packet losses. 5. Actively extract confidential information from network traffic This attack requires the knowledge of the encryption key(s). If shared AAA keys are used for encrypting data, then a proxy in possession of these keys can decrypt the data. For example, this attack can be used to gather personal user information or accounting information (such as roaming fees and offered services) of competitive networks. 6. Fabricate fake data packets This attack requires the knowledge of the keying material used to protect data packets. If shared AAA keys are used for protecting data, then a proxy in possession of these keys can generate fake data packets. For instance, a malicious proxy could fabricate valid authentication packets for an unauthorized mobile node or fabricate fake accounting data to charge for unused services. Hoeper Expires April 3, 2009 [Page 11] Internet-Draft AAA Proxy Threat Model October 2008 7. Modify messages If shared AAA keys are used for protecting AAA messages, then a proxy in possession of these keys can modify the data. If an AAA message is not protected, any proxy or any other network entity can modify it. If an AAA message (protected or unprotected) is not bound to any other protected message it can be dropped by any proxy or other network entity on the routing path. 8. Modify AAA attributes [Editor's note: Are AAA attributes typically protected?] If shared AAA keys are used for protecting AAA attributes, then a proxy in possession of these keys can modify the attributes. If an AAA attribute is not protected, any proxy or any other network entity can modify it. If an AAA attribute (protected or unprotected) is not bound to any other protected AAA message or attribute it can be dropped by any proxy or other network entity on the routing path. 6. Risk Analysis This section uses the thread model in Section 5. to analyze the feasibility and severity of the identified attacks 5. in each of the uses cases discussed in Section 4. An attack is only considered a risk, if the attack is feasible and the impact is sufficiently severe to justify the attack's costs from an attacker's perspective. 6.1. Feasibility It can be observed that the feasibility of attacks by proxies depend on the use case, the type of employed proxies, and whether the proxy possesses keying material required for an attack. In general, the existence of malicious home proxies in an enterprise network (and thus the feasibility of attacks in such networks) is fairly unlikely because enterprise networks can be efficiently protected. For such an attack, the trust assumption in the home network must be violated (see Section5.1. ). Hoeper Expires April 3, 2009 [Page 12] Internet-Draft AAA Proxy Threat Model October 2008 On the other hand, in roaming scenarios, the attacks by proxies (as listed in Section 5.2. ) can be classified as more feasible because they can be carried out by local proxies and/or proxies in a proxy chain between home and visited network. The trustworthiness of visited proxies is specified in the respective roaming agreements, while the trustworthiness of proxies in proxy chains may depend on a chain of roaming agreements. In a proxy chain, both ends of the chain (i.e. home and visited network) have roaming agreements with each other as well as neighboring pairs of proxies in the chain. Only if the chain consists of three or less proxies, the home network directly trusts all proxies (up to two) in the chain. For chains longer than three (including the end points) trust is transitive, i.e. the home proxy does not directly trust all proxies on the chain but rather trusts its direct neighbor to only have agreements with other trusted proxies and so forth. This results into a chain of trust. It can be observed, that a violation of this chain of trust is more likely than a direct trust violation in the home or visited network. Furthermore, the longer the proxy chain, the more diluted may the trust relations become and the more likely is a compromised or mis-configured proxy as part of the proxy chain. In any case, attacks in roaming use cases require that a trust relation as part of the roaming agreements is violated (see Section 5.1. . In addition, the feasibility of attacks depend whether they require knowledge of keying material. For instance, attacks 1-4 in Section 5.2. do not require the knowledge of keying material and thus can be executed by any proxy. On the other hand, attacks 5-8 require the knowledge of the AAA keying material that has been used to protect the data under attack. However, the possession of keying material is likely because AAA protocols are often based on hop-by-hop security using shared keys. In addition, proxies often need to be able to adjust (protected) AAA attributes to meet local requirements. 6.2. Severity In enterprise networks, the severity of attacks are rather limited, because the exchanged data would not be of great value for an attacker and the exploitation of fabricated of modified packets is limited (e.g. because of the lack of accounting data and mobility pattern of users). Hoeper Expires April 3, 2009 [Page 13] Internet-Draft AAA Proxy Threat Model October 2008 The severity of all attacks in roaming scenarios is higher due to the higher value of the exchanged information and offered services. For instance, traffic analysis attacks (attack 1) could be of interest to track the movements of particular mobile users. DoS attacks (attacks 3 and 4) could bring down the entire services, so the risk can be considered moderate to severe depending on the offered services. Especially accounting information is an attractive target for an adversary. However, the information of free roaming services (use case 2) can be of value as well. For example, in [5] data can contain the age, nationality, and other personal information of the mobile user wishing to access the network. Modification attacks can also be a severe risk, e.g. under aged users can control proxies to modify the age in order to pass the age limit for a requested service or local proxies may modify the roaming information to make their network services more attractive but later charge more. In addition modification attacks can be used for the downgrading of negotiated security credentials. Fabrication attacks can be classified as extremely severe in use case 3, because a malicious accounting proxy could fabricate false accounting information, such that the home network is charged for roaming fees even though no mobile node actually roamed. 7. Security Considerations TBD 8. IANA Considerations This document has no IANA considerations. 9. Conclusions This draft facilitates implementers and providers of networks with AAA proxies as well as protocols designers to carry out a risk analysis of threats introduced by AAA proxies. The result of such analysis enables to decide whether the potential security vulnerabilities introduced by AAA proxies in the network justify the costs of necessary system or protocol modifications to thwart the identified attacks. Furthermore, as another result of this draft, it can be observed that security solutions thwarting proxy attacks can be expected not to be of pure technical nature. The feasibility of attacks highly depends on the reliability of trust assumptions in enterprise networks and roaming agreements in roaming applications. Hoeper Expires April 3, 2009 [Page 14] Internet-Draft AAA Proxy Threat Model October 2008 Technical solutions such as providing end-to-end protection of AAA attributes and messages can prevent modifications and fabrication attacks and should be carefully studied in future works. 10. Acknowledgments Thanks to everybody contributing to the proxy list and/or the meeting in Philadelphia, especially Bernard Aboba, Alan DeKok, Pasi Eronen, Dan Harkins, Sam Hartman, Russ Housley, Tim Polk, Klaas Wierenga, and Glen Zorn. Special thanks to Stefan Winter for providing the eduroam application as one of the use cases. 11. References 11.1. Normative References (None). 11.2. Informative References [1] Housley, R. and Aboba, B., "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [2] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, J., "Diameter Base Protocol", RFC 3588, September 2003. [4] Aboba, B., "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [5] Wierenga, K. and S. Winter, "Deliverable DJ5.1.4: Inter-NREN Roaming Architecture: Description and Development Items", 2006, . Hoeper Expires April 3, 2009 [Page 15] Internet-Draft AAA Proxy Threat Model October 2008 Authors' Addresses Katrin Hoeper (editor) National Institute of Standards and Technology 100 Bureau Drive, MS: 8930 Gaithersburg, MD 20899 USA Email: khoeper@nist.gov Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Hoeper Expires April 3, 2009 [Page 16] Internet-Draft AAA Proxy Threat Model October 2008 Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hoeper Expires April 3, 2009 [Page 17]