Internet DRAFT - draft-hoeper-proxythreat

draft-hoeper-proxythreat






Network Working Group                                 S. Winter (Editor)
Internet-Draft                                                   RESTENA
Expires: September 10, 2009                                    K. Hoeper
                                                                Motorola
                                                           March 9, 2009


            Threat Model for Networks Employing AAA Proxies
                    draft-hoeper-proxythreat-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 September 10, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 1]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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.  In addition,
   mitigation techniques used in current AAA deployments are discussed
   and best practices for mitigating the identified attacks are
   identified.  As a result, this draft can serve as a guideline for
   risk assessments and problem mitigation by providers, implementers
   and protocol designers of systems with proxies.

































Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 2]

Internet-Draft        Threat Model for AAA Proxies            March 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Goals of this Document . . . . . . . . . . . . . . . . . .  4
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Enterprise Network Management  . . . . . . . . . . . . . .  7
     4.2.  Free International Roaming . . . . . . . . . . . . . . . .  8
     4.3.  Billable International Roaming . . . . . . . . . . . . . . 10
   5.  Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Network Entities and their Trust Relationships . . . . . . 10
     5.2.  Potential Attacks  . . . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Unauthenticated AAA messages send in clear . . . . . . 11
       5.2.2.  Authenticated AAA messages send in clear . . . . . . . 14
       5.2.3.  Authenticated and encrypted AAA messages . . . . . . . 15
   6.  Risk Analysis  . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Feasibility  . . . . . . . . . . . . . . . . . . . . . . . 16
     6.2.  Severity . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Mitigations Techniques and Best Practices  . . . . . . . . . . 18
     7.1.  Current Practices  . . . . . . . . . . . . . . . . . . . . 18
       7.1.1.  Authentication and Encryption of AAA messages  . . . . 18
       7.1.2.  RadSec . . . . . . . . . . . . . . . . . . . . . . . . 18
       7.1.3.  Relay Agents . . . . . . . . . . . . . . . . . . . . . 18
       7.1.4.  AAA in EAP executions  . . . . . . . . . . . . . . . . 18
       7.1.5.  Federated Authentication: eduroam  . . . . . . . . . . 19
       7.1.6.  Authentication at Untrusted Third Party ISP: Using
               OTP  . . . . . . . . . . . . . . . . . . . . . . . . . 20
       7.1.7.  Non-Recommended Practices  . . . . . . . . . . . . . . 20
     7.2.  Best practices . . . . . . . . . . . . . . . . . . . . . . 20
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   10. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 21
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23











Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 3]

Internet-Draft        Threat Model for AAA Proxies            March 2009


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.

   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 [RFC4962] is the most glaring aspect
   of the problem, but the progress of numerous drafts in a number of
   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
   revisit 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



Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 4]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   severity of the identified threats.  In addition, existing techniques
   that mitigate some of the attacks and their effectiveness are
   discussed.  From the previous discussions best practices to prevent
   and mitigate attacks by proxies are derived.

   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.

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.

1.3.  Terminology

   This section defines terms that are frequently used in this document.

   AAA
      Authentication, Authorization, and Accounting (AAA).  AAA
      protocols include RADIUS [RFC2865] and Diameter [RFC3588].

   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.



Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 5]

Internet-Draft        Threat Model for AAA Proxies            March 2009


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 insert, 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 maliciously modify or delete some
   attributes of an AAA request/reply in order to launch an attack.  Or
   a proxy in possession of AAA keying material can break the end-to-end
   integrity and/or confidentiality between NAS and 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 [RFC2607] between NAS and AAA server, not every party
   authenticates to all parties it communicates with as required in
   [RFC4962].  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: Any additional references that should be mentioned
   here?]

   Proxy-related security issues have been raised within the IETF for a
   long time and several issues as well as mitigation techniques are
   discussed in a number of RFCs, e.g. in [RFC2607], [RFC3748],
   [RFC5247], [RFC3588].

   [RFC2607] considers chaining of RADIUS proxies in roaming scenarios.
   Section 7 in RFC 2607 gives a good overview of security threats in
   such scenarios.




Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 6]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   [RFC3748] points out some potential security risks introduced by AAA
   proxies during an EAP execution.  For example, AAA proxies may have
   an impact on authorization decisions and identity protection.

   Among other things, [RFC5247] considers how EAP executions can meet
   the requirements in [RFC4962] even in the presence of AAA proxies.
   RFC 5747 identifies several security issues introduced by AAA proxies
   in the system (e.g. decryption of data traffic between peer and
   authenticators as well as impersonation of authenticators) and
   discusses some mitigation techniques.

   Diameter [RFC3588] introduces the concept of relay agents that,
   unlike proxies, do not need to modify messages.  This reduces the
   number of intermediaries in the network that need to possess keying
   material and, thus, reduces the risk of rouge proxies abusing keying
   material for launching attacks.

   While these and other issues and mitigation techniques have been
   discussed in various places, this document attempts to use these
   previous results to summarize important security issues in one place,
   comment on the security of current practices, and identify good
   solutions for the mitigation of the identified flaws.


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



Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 7]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   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 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 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 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



Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 8]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   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
   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 [EDUROAM].  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



Winter (Editor) & Hoeper  Expires September 10, 2009            [Page 9]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   roaming between different top-level domains, country-level proxy
   servers for roaming between institutions in the same top level
   domain, and institutional servers to perform the actual
   authentication (these servers may optionally further relay 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 [RFC2607].  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.

   o  The trust relationships between a home network and other local
      networks are specified in roaming agreements.  These roaming



Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 10]

Internet-Draft        Threat Model for AAA Proxies            March 2009


      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.  Naturally for insider attacks, this requires some of the
   above trust relations to be violated, which will be discussed in
   Section 6.  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

   This section lists potential attacks by proxies depending on the AAA
   deployment environment.  In particular, the following sections
   distinguish proxy attacks on AAA backends in which the exchanged AAA
   messages are: (1) unauthenticated and send in cleartext; (2)
   authenticated and send in cleartext; and (3) authenticated and
   encrypted.  The two latter sections discuss how some attacks can be
   mitigated by using already available AAA techniques for protecting
   messages.

5.2.1.  Unauthenticated AAA messages send in clear

   For obvious reasons, exchanging unprotected AAA messages (i.e.
   unauthenticated and not encrypted) from NAS to AAA server through
   intermediaries and vice versa offers the most attack points to a
   rogue or misconfigured AAA proxy.  For the same reason, not only
   proxies but any entity with access to the backend (e.g. routers,
   relay agents) could launch the following attacks in this setting:

   1.  Passively eavesdrop on network traffic
       Traffic analysis can be used to track the activity and/or
       mobility of particular users.  To do so the attacker needs to be
       able to correlate identifiers used in the AAA messages to users
       or network entities.
       Monitoring network traffic can be carried out by any entity with



Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 11]

Internet-Draft        Threat Model for AAA Proxies            March 2009


       access to the backend network and is thus not limited to AAA
       proxies.

   2.  Replay data packets
       This attack consists of two phases: (1) the recording of data
       packets of previous network authentications and (2) the replaying
       of this data at a later time.  This leads to impersonation of the
       message originator and can be exploited for creating false
       billing statements, unauthorized network access, and many more.
       Replay attacks can be carried out by any entity with access to
       the backend network and is thus not limited to AAA proxies.

   3.  Re-direct data packets
       Any proxy could maliciously re-direct AAA data packets.  It
       appears that this attack can only be exploited for Denial of
       Service (DoS) attacks [Editor's note: Is this true?] which are
       often not preventable by cryptographic means.
       Re-directing attacks require access to the routing path and thus
       can be carried out by routers, proxies and other intermediaries
       on the routes.

   4.  Drop data packets
       As for re-direction attacks, any proxy can drop packets causing
       re-transmissions potentially leading 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
       and thus can be carried out by routers, proxies and other
       intermediaries on the routes.  Note that this attack cannot
       easily be distinguished from "natural" packet losses.

   5.  Not executing checks
       Sometimes a proxy needs to perform certain checks upon receiving
       an AAA message and its further actions depend on the result of
       the check.  Such checks may be necessary to enable a proper flow
       of the AAA messages in the backend or to prevent or detect
       attacks by other entities in the backend.
       For example, a first-hop proxy may be required to check whether
       some particular address attributes in the received message match
       the address of the sender of the message.  This could, e.g.,
       prevent impersonation attacks by a NAS.  By (volunteeringly or
       unvolunteeringly) not performing checks, the proxy opens the door
       to the described and other attacks.

   6.  Extract confidential information from network traffic
       In this attack confidential information is extracted from
       exchanged AAA messages.  This could affect the privacy and
       confidentiality of exchanged information, e.g. user identities
       and user passwords, respectively.  Session keys obtained from



Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 12]

Internet-Draft        Threat Model for AAA Proxies            March 2009


       exchanged AAA messages compromise protected communications
       between a NAS and a MN if such keys will be used to derive
       further keys to protect this link.  Also accounting information
       could be a target.
       Where AAA protocols do not encrypt their payload or parts of it
       on the wire, any attacker with access to the backend network may
       extract confidential information from the exchanged AAA packets.

   7.  Fabricate fake data packets
       In this attack, the attacker fabricates valid AAA messages.  This
       can be exploited for unauthorized network access, fabrication of
       accounting data to charge for unused services or don't charge for
       used services and other very damaging attacks.
       If AAA messages are completely unprotected in the backend, any
       entity with access to the backend can fabricate packets that do
       not need to contain some secret or otherwise unknown information.
       However, fabricated packets for network access or billing
       information may require secret passwords or certain identifiers.
       In that case the attacker first needs to observe this secret
       information in a first phase of this attack before using this
       information in a fabricated packet.

   8.  Modify messages
       In this attack, the attacker modifies exchanged data.  This can
       be exploited for impersonation attacks, manipulating accounting
       data and many other very damaging attacks.
       Completely unprotected messages are susceptible to this attack
       which can be launched by any entity on the routing path.

   9.  Insert, modify or drop AAA attributes
       Some proxies are able to insert, modify or drop AAA attributes to
       enforce local policies.  These capabilities can be exploited by
       malicious proxies for many attacks.  For example, a proxy could
       grant or deny authorization for network access even if this is
       against the local policy.  Unprotected AAA attributes can be
       modified by any proxy or other intermediary.  This can be
       exploited for severe attacks, e.g. a proxy could forge NAS-IP-
       Address, NAS-IPv6-Address, or NAS-Identifier to cause that keying
       material is send to another NAS.  Such modifications can also
       lead to granting network access to an entity different from the
       one requesting network access.  In addition, any AAA attribute
       (protected or unprotected) that is not bound to any other
       protected AAA message or attribute can be dropped unnoticed by
       any proxy or other intermediary on the routing path.







Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 13]

Internet-Draft        Threat Model for AAA Proxies            March 2009


5.2.2.  Authenticated AAA messages send in clear

   This section considers attacks that can be launched by proxies in AAA
   backends in which AAA messages provide message authentication but are
   not encrypted.  Here, the authentication includes the exchanged data
   as well as the AAA attributes.  If a part of the message is not
   authenticated, the discussion of the previous section applies.
   Basically the attacks are the same, but some of them only work under
   certain conditions described in the following (see Section 5.2.1 for
   the definition of the attacks):

   1.  Passively eavesdrop on network traffic
       Authenticated messages can be still monitored by any entity with
       access to the backend networks.

   2.  Replay data packets
       Proper message authentication mitigates replay attacks by
       including time variant information (such as timestamps, nonces,
       and/or sequence numbers) into each message.  This type of
       countermeasure is typically included in AAA protocols such as
       RADIUS and Diameter.  However, there are legacy operation modes
       in RADIUS that can be replayed easily (e.g.  Access-Request
       packets without the Message-Authenticator attribute, which is
       against the Recommendation of [RFC5080]).

   3.  Re-direct data packets
       Re-direction attacks cannot be mitigated by message
       authentication.

   4.  Drop data packets
       Authenticated messages can be still dropped by proxies and
       intermediaries on the routing path.

   5.  Not executing checks
       Same as in Section 5.2.1.

   6.  Extract confidential information from network traffic
       Confidential information can be still extracted from
       authenticated AAA messages that send data in the clear.

   7.  Modify messages
       Modifying authenticated messages requires the knowledge of the
       key used to protect the data.  If a proxy is in possession of
       this key, it can still modify messages.  Note that other
       intermediaries such as routers and relay agents do not possess
       any keys required for the attack.





Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 14]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   8.  Modify or drop AAA attributes
       Authenticated AAA attributes can still be modified or dropped by
       a proxy that is in possession of the authentication key.  This is
       a fairly common scenario because proxies need to be able to
       enforce local system policies and thus are required to modify or
       drop AAA attributes in certain situations.

5.2.3.  Authenticated and encrypted AAA messages

   In networks in which AAA messages are authenticated and encrypted
   proxies can still launch the same attacks as described in the two
   previous section, however, the conditions for a success may require
   proxies to be in possession of the used keying material.  These
   attacks are then specific to proxies and cannot be launched by other
   intermediaries (such as routers and relay agents) any longer.  The
   condition for successful attacks on authenticated and encrypted AAA
   messages by proxies can be summarized as follows:

   1.  Passively eavesdrop on network traffic
       If identifiers, addresses and information identifying an entity
       are encrypted, rogue proxies cannot simply eavesdrop on AAA
       communications to perform traffic analysis any longer.  Analyzing
       the network traffic would require an active attack by a proxy in
       possession of the encryption keys.

   2.  Replay data packets
       Authentication can mitigate this problem (see previous section),
       encryption does not provide further protection.

   3.  Re-direct data packets
       Re-direction attacks cannot be mitigated by neither message
       authentication nor encryption.

   4.  Drop data packets
       Messages can be still dropped by proxies and intermediaries on
       the routing path.

   5.  Not executing checks
       Same as in Section 5.2.1.

   6.  Extract confidential information from network traffic
       The extraction of confidential information from encrypted
       messages requires now the knowledge of keying material.  This
       attack is especially attractive if cryptographic keys are
       exchanged in the AAA messages.  Only proxies in possession of the
       encryption keys are able to decrypt, all other intermediaries
       cannot.




Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 15]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   7.  Modify messages
       Same as in Section 5.2.2.

   8.  Modify or drop AAA attributes
       Same as in Section 5.2.2.


6.  Risk Analysis

   This section uses the threat model in Section 5 to analyze the
   feasibility and severity of the identified attacks 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 Section 5.1).

   On the other hand, in roaming scenarios, the attacks by proxies (as
   listed in Section 5.2) can be classified as more probable 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.




Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 16]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   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-5 in
   Section 5.2) do not require the knowledge of keying material and thus
   can be executed by any proxy or other intermediary.  On the other
   hand, attacks 6-9 may 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).

   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 [EDUROAM] 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.






Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 17]

Internet-Draft        Threat Model for AAA Proxies            March 2009


7.  Mitigations Techniques and Best Practices

   Some of the aforementioned challenges when deploying an AAA fabric
   with proxies can be mitigated technically, but most of them can only
   be mitigated by an appropriate policy or code of conduct between the
   entities in the proxy fabric.  This section consists of two parts:
   the first section describes deployed AAA fabrics as well as existing
   mitigation techniques and analyses which of the aforementioned
   challenges are mitigated technically, policy-wise, or not at all.
   The second part identifies best practices for AAA systems employing
   proxies, basically combining known techniques to address the attacks.

7.1.  Current Practices

7.1.1.  Authentication and Encryption of AAA messages

   RADIUS and Diameter both support authentication and encryption for
   AAA packets.  AAA authentication and encryption mitigate attacks # 2,
   6, 7, 8 and 9 in Section 5.2 by intermediaries that are not in
   possession of the used keying material.  However, as discussed in
   Section 5.2, these techniques do not provide end-to-end security.
   Hence rogue proxies could use their keys to break authentication and
   confidentiality of the exchanged data.

7.1.2.  RadSec

   [TBD]

7.1.3.  Relay Agents

   Diameter enables the implementation of redirect functionality (see
   [RFC3588]) in which so-called relay agents relay AAA messages
   directly from the source to the destination.  These relays do not
   need to store keying material which distinguishes them from AAA
   proxies.  Thus, deploying relay agents mitigates all attacks that
   require the knowledge of keying material.

7.1.4.  AAA in EAP executions

   During an EAP execution the authenticator often acts as a pass-trough
   device between peer and the authentication server [RFC3748].  The
   authenticator and the authentication server use an AAA protocol to
   encapsulate the EAP messages exchanged between each other.  RFC 5247
   considers how AAA guidelines in RFC 4962 can be met during EAP
   executions even in the presence of proxies.  Recall that RFC 4962
   does not address the proxy problem.  RFC 5247 identifies several
   direct or indirect attacks by proxies that have been covered in
   Section 5.2 and suggests using the redirect functionality to mitigate



Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 18]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   these attacks.  In addition, instead of relying on a proxy executing
   a check, RFC 5247 recommends to rather use EAP channel bindings
   ([I-D.ietf-emu-chbind]) to address the attack.  Basically this
   removes a crucial security check that needs to be executed by a proxy
   by another mitigation technique that does not depend on proxies at
   all (here EAP peer and the authentication server ensure the
   prevention of the attack by implementing and executing channel
   bindings).

7.1.5.  Federated Authentication: eduroam

   Eduroam is a world-wide roaming consortium exclusively for the
   education and research sector (i.e. schools, universities, research
   centres) [EDUROAM].  It is exclusive in the sense that only education
   users may hold a user account from a participating organisation to
   log in.

   Technology-wise, it's an IEEE 802.1X-based roaming fabric which
   interconnects the individual educational organisations via a
   hierarchy of RADIUS servers.  These organisations manage their user
   accounts independently.  The RADIUS hierarchy provides realm-based
   routing to facilitate international roaming.  Only EAP mutual
   authentication is used to authenticate users, EAP payloads typically
   being TTLS-PAP, PEAP-MSCHAPv2 and TLS to protect the user's
   credentials in transit: the inner credentials are only ever exposed
   at the user's 'home' authentication server, thus preserving privacy.
   Both wireless and wired 802.1X are implemented.

   There is no per-session or per-volume accounting, i.e. it is
   'free'(eligibility fees from the Identity Provider side
   notwithstanding).  A service provider ('hotspot'), typically a
   university, runs on the principle of mutuality: their users are
   granted global roaming rights, while their hotspot in turn allows any
   international users to roam at their site.  Participant organisations
   cover their own operational costs.

   Mitigates:

   1.  Traffic analysis: ?

   2.  Replay: ?

   3.  Re-direct: ?

   4.  Drop packets: ?

   5.  Attack on confidentiality:?




Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 19]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   6.  Data fabrication: yes, stops fraus accounting

   7.  Message modification: partial, EAP payloads in Auth only

   8.  Attribute modification: ?

7.1.6.  Authentication at Untrusted Third Party ISP: Using OTP

   [Editor's note: Need volunteer who knows how Cisco's OTP is deployed
   to write this section]

   Mitigates:

   1.  Traffic analysis: ?

   2.  Replay: ?

   3.  Re-direct: ?

   4.  Drop packets: ?

   5.  Attack on confidentiality:?

   6.  Data fabrication:?

   7.  Message modification:?

   8.  Attribute modification: ?

7.1.7.  Non-Recommended Practices

   An example of a bad, but unfortunately widely implemented practice is
   to send plain text credentials through proxies.  This is done by most
   WiFi hotspot roam ops ('captive portals').

   [Editor's note: Is this worth elaborating on?  Any more examples of
   bad practices?]

7.2.  Best practices

   [Editor's note: Please help to extend the list of good mitigation
   techniques]

   From the previous discussions the following mitigation techniques are
   considered good practices to thwart the attacks by proxies described
   in Section 5.2:





Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 20]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   o  Use authentication and encryption for all sensitive data exchanged
      in the AAA messages

   o  Keep the number of proxies in the network that require the
      knowledge of keys to an absolute minimum, e.g. by analysing the
      function and corresponding capabilities of each proxy and/or using
      redirect functionality in Diameter.

   o  Replace security checks relying on proxies by security checks that
      can be performed by other, more trustworthy, entities.  For
      example use channel bindings.

   o  Implement additional, external means guarding the integrity of the
      home or enterprise network that help to detect and remove
      compromised and misconfigured proxies.

   o  Formulate roaming agreements between all participating networks
      and establish security policies for all participating entities.
      This establishes responsibilities in the case a misbehaving proxy
      causes damage.

   Only a combination of the above technical and policy-based mitigation
   techniques can thwart most of the identified attacks by rogue
   proxies.


8.  Security Considerations

   [TBD]


9.  IANA Considerations

   This document has no IANA considerations.


10.  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.  A set of existing countermeasures partially used
   in already deployed AAA networks have been discussed and good
   practices for mitigating attacks by proxies have been identified.




Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 21]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   As a result of the presented discussions, 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 security policies in enterprise networks and
   roaming agreements in roaming applications.


11.  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.


12.  References

12.1.  Normative References

12.2.  Informative References

   [EDUROAM]  Wierenga, K. and S. Winter, "Deliverable DJ5.1.4: Inter-
              NREN  Roaming Architecture: Description and Development
              Items", 2006,
              <http://www.geant2.net/roaming-techspec.pdf>.

   [I-D.ietf-emu-chbind]
              Clancy, T. and K. Hoeper, "Channel Binding Support for EAP
              Methods", November 2008.

   [RFC2607]  Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
              Implementation in Roaming", RFC 2607, June 1999.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
              Authorization, and Accounting (AAA) Key Management",
              BCP 132, RFC 4962, July 2007.



Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 22]

Internet-Draft        Threat Model for AAA Proxies            March 2009


   [RFC5080]  Nelson, D. and A. DeKok, "Common Remote Authentication
              Dial In User Service (RADIUS) Implementation Issues and
              Suggested Fixes", RFC 5080, December 2007.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, August 2008.


Authors' Addresses

   Stefan Winter
   RESTENA Foundation
   6, rue Richard Coudenhove-Kalergi
   Luxembourg  1359
   Luxembourg

   Phone: +35 242 44091
   Email: stefan.winter@restena.lu


   Katrin Hoeper
   Motorola
   1301 E Algonquin Road
   Schaumburg, IL  60196
   USA

   Phone: +1 847 576 4714
   Email: khoeper@motorola.com






















Winter (Editor) & Hoeper  Expires September 10, 2009           [Page 23]