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]