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
draft-hoeper-proxythreat-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo defines a threat model for access networks with AAA
proxies. Use cases of current and future applications in which AAA
proxies are employed are described and it is discussed how proxies
could launch attacks in the defined use cases. The risk associated
with these attacks in each use case is analyzed. As a result, this
draft can serve as a guideline for risk assessments by providers,
implementers and protocol designers of systems with proxies.
Hoeper & 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.
AAA
Authentication, Authorization, and Accounting (AAA). AAA protocols
include RADIUS [2] and Diameter [3].
AAA Server
A server which provides AAA services via an implemented AAA
protocol to mobile nodes.
AAA Client
A network entity sending AAA requests to the AAA server and
receiving AAA replies from the AAA server. NAS and AAA proxy can
both act as AAA client.
AAA Proxy
An AAA proxy provides routing for AAA requests and replies. An
AAA proxy appears to act as an AAA client to the AAA server and
as AAA server to the AAA client. In this draft, pure re-direct
proxies as supported by Diameter are not considered. Only AAA
proxies that are capable of modifying attributes and may possess
cryptographic keying material are considered.
Hoeper & Winter Expires May 3, 2009 [Page 4]
Internet-Draft AAA Proxy Threat Model November 2008
MN
A mobile node (MN) that wishes to access the network.
NAS
The Network Access Server (NAS) is the network entity that mobile
nodes contact in order to obtain access to the network.
Proxy Chain
A routing path through a sequence of AAA proxies. In roaming
scenarios, when a proxy chain is across different administrative
domains, roaming agreements exist between the first and last proxy
of the chain as well as between each neighboring pair of proxies.
Roaming agreement
Roaming agreements include agreements between companies and
Internet Service Providers (ISPs), agreements among peer ISPs
within a roaming association, and relationships between an ISP and
a roaming consortium. These agreements require a certain level of
trust among all parties of a roaming agreement.
In the context of this draft, roaming agreements between two
administrative domains imply that AAA proxies in these domains may
share pairwise AAA keys with each other or may be capable of
establishing such pairwise keys.
2. Problem Statement
Unlike some other network entities that simply forward packets in the
network, AAA proxies are designed to have additional capabilities and
properties such that the AAA protocols executed through AAA proxies
may have the following features:
o AAA proxies are able to modify and/or delete AAA attributes
o AAA proxies share pairwise AAA keys with the AAA server and/or
other AAA proxies;
o AAA proxies and NAS cannot be distinguished by AAA server;
o AAA proxies and AAA server cannot be distinguished by NAS;
o AAA proxy chains cannot be distinguished from single proxies by
neither NAS nor AAA server.
The above special features may lead to new security vulnerabilities.
For example, a proxy could modify or delete some attributes of an AAA
request/reply. Or a proxy in possession of AAA keying material can
break the end-to-end integrity and/or confidentiality between NAS and
Hoeper & 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 |
- - - - - - - - - - - - - - -
*optional
Figure 2 International Roaming Utilizing Proxies
An example of an existing network enabling international roaming free
of charge is eduroam [5]. Eduroam is a world-wide WLAN roaming
network for users in education and research. The network consists of
a hierarchy of RADIUS servers interconnecting participating sites.
The hierarchy consists of a root level proxy, used for international
roaming between different top-level domains, country-level proxy
servers for roaming between institutions in the same top level
Hoeper & 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
relationships:
o Within a home domain (can be also considered as an intra-domain)
it is assumed that all entities are correctly configured and not
controlled by a malicious party. This can be achieved by intrusion
detection systems or other means to detect so-called malicious
insiders.
Hoeper & 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
networks
Furthermore, these three proxy types are split into authentication
and accounting proxies.
5.2. Potential Attacks
A malicious or misconfigured AAA proxy may launch the following
attacks:
1. Passively eavesdrop on network traffic
Monitoring network traffic is feasible for any entity with access
to the network. It does not require any special capabilities or
privileges, such as the knowledge of cryptographic keying material.
Consequently, this attack is not limited to AAA proxies.
Traffic analysis can be used to track the activity and/or mobility
of particular users.
2. Replay data packets
This attack consists of two phases: (i) the recording of data
packets of previous network authentications and (ii) the replaying
of this data at a later time. This requires access to the network
but no knowledge of keying material. Hence, the attack is not
limited to proxies.
Hoeper & 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
TBD
8. IANA Considerations
This document has no IANA considerations.
9. Conclusions
This draft facilitates implementers and providers of networks with
AAA proxies as well as protocols designers to carry out a risk
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
(None).
11.2. Informative References
[1] Housley, R. and Aboba, B., "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", BCP 132, RFC
4962, July 2007.
[2] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, J.,
"Diameter Base Protocol", RFC 3588, September 2003.
[4] Aboba, B., "Proxy Chaining and Policy Implementation in
Roaming", RFC 2607, June 1999.
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,
<http://www.geant2.net/roaming-techspec.pdf>.
[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
USA
Email: khoeper@nist.gov
Stefan Winter
RESTENA Foundation
6, rue Richard Coudenhove-Kalergi
1359 Luxembourg
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
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
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
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hoeper & Winter Expires May 3, 2009 [Page 17]