[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Internet Engineering Task Force                          K. Hoeper, Ed.
Internet Draft                                                     NIST
Intended status: Informational                                S. Winter
Expires: May 3, 2009                                            RESTENA
                                                       November 3, 2008

              Threat Model for Networks Employing AAA Proxies

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 3, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   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 & Winter          Expires May 3, 2009                   [Page 1]

Internet-Draft           AAA Proxy Threat Model           November 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..............................................13
      6.2. Severity.................................................14
   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...........................................17

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 & Winter          Expires May 3, 2009                   [Page 2]

Internet-Draft           AAA Proxy Threat Model           November 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 & Winter          Expires May 3, 2009                   [Page 3]

Internet-Draft           AAA Proxy Threat Model           November 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.

      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 & Winter          Expires May 3, 2009                   [Page 4]

Internet-Draft           AAA Proxy Threat Model           November 2008

      A mobile node (MN) that wishes to access the network.

      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 & Winter          Expires May 3, 2009                   [Page 5]

Internet-Draft           AAA Proxy Threat Model           November 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 & Winter          Expires May 3, 2009                   [Page 6]

Internet-Draft           AAA Proxy Threat Model           November 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 & Winter          Expires May 3, 2009                   [Page 7]

Internet-Draft           AAA Proxy Threat Model           November 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  |
       - - - - - - - -                 - - - - - - -

             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 & Winter          Expires May 3, 2009                   [Page 8]

Internet-Draft           AAA Proxy Threat Model           November 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

   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

Hoeper & Winter          Expires May 3, 2009                   [Page 9]

Internet-Draft           AAA Proxy Threat Model           November 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

   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

     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 & Winter          Expires May 3, 2009                  [Page 10]

Internet-Draft           AAA Proxy Threat Model           November 2008

     Replay attacks are typically prevented by the AAA protocol itself
     with the aid of time variant information. There are legacy
     operation modes in RADIUS that can be replayed easily (Access-
     Request packets without the Message-Authenticator attribute, which
     is against the Recommendation of RFC 5080[6]).

     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

     Where AAA protocols do not encrypt their payload or parts of it on
     the wire, an attacker may extract confidential information from the
     packet without knowledge of encryption keys. In this case, any
     intermediate hop (like routers) can eavesdrop on the non-encrypted
     parts of the protocol payload.

     If the protocol payload is encrypted as a whole, 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

Hoeper & Winter          Expires May 3, 2009                  [Page 11]

Internet-Draft           AAA Proxy Threat Model           November 2008

     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.

     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

     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.

     Current AAA protocols provide shared keying material for payload
     protection and thus expose packet contents to proxies. There are
     key wrapping schemes to protect individual attributes though, which
     can encrypt AAA attributes between any two AAA servers while not
     exposing them to intermediate AAA proxies. These key wrapping
     schemes require out of band negotiation of wrapping keys, which is
     hardly scalable.

6. Risk Analysis

   This section uses the threat 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

Hoeper & Winter          Expires May 3, 2009                  [Page 12]

Internet-Draft           AAA Proxy Threat Model           November 2008

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

   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

Hoeper & Winter          Expires May 3, 2009                  [Page 13]

Internet-Draft           AAA Proxy Threat Model           November 2008

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


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

Hoeper & Winter          Expires May 3, 2009                  [Page 14]

Internet-Draft           AAA Proxy Threat Model           November 2008

   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.

   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


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.

Hoeper & Winter          Expires May 3, 2009                  [Page 15]

Internet-Draft           AAA Proxy Threat Model           November 2008

   [5]      Wierenga, K. and S. Winter, "Deliverable DJ5.1.4: Inter-NREN
     Roaming Architecture: Description and Development Items", 2006,

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

Authors' Addresses

   Katrin Hoeper (editor)
   National Institute of Standards and Technology
   100 Bureau Drive, MS: 8930
   Gaithersburg, MD 20899

   Email: khoeper@nist.gov

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

   Email: stefan.winter@restena.lu

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

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary

Hoeper & Winter          Expires May 3, 2009                  [Page 16]

Internet-Draft           AAA Proxy Threat Model           November 2008

   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hoeper & Winter          Expires May 3, 2009                  [Page 17]