[proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)

Overall comment:  

Discussion of AAA proxy security issues has a long history within the IETF, starting in 1996
with the IESG review of RFC 2607, which spawned the development of RFC 4962, the 
AAA requirements documents, and threat model and security analysis included within RFC 5247. 

As with NAT, AAA proxies became widely entrenched before their implications were
fully understood, and in addition, they offered the solution to a wide range of
real or perceived problems, as discussed in RFC 2607.   

Given this, progress on the proxy problem has experienced some of the same
issues that have been encountered in developing "NATless" infrastructures within
IPv6.  While in theory alternatives are possible, in practice there are many
operational details that would need to be solved before they can be deployed. 

Teasing out all the potential benefits of proxies, and evaluating the extent
to which deployable alternatives are available has proven to be a daunting
task.   For example, the key management issues identified in RFC 2607
have been attacked via a variety of PKI approaches, which themselves
have encountered deployment issues, influencing the perceived practicality
of proposals such as Diameter CMS and Redirect.  

However, at the same time, some of the operational issues with proxies
(such as increased packet loss and latency) have also come to be better
appreciated, motivating new approaches to solutions within organizations
such as EDUROAM.  As a result, it would appear to me that operational
issues, not security, provide both the major impediments to and motivations 
for progress. 

While the focus of this document is threat analysis, it would seem important
to address some of those operational concerns, given their critical influence
on deployment.  Otherwise we risk developing a scism between the 
Security and O&M Areas in addressing these concerns. 

Specific Comments

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

The security vulnerabilities introduced by AAA proxies are not "new";
the RFC 2607 security analysis was initially requested by the IESG a 
decade ago.  In order to address the issues raised by the RFC 2607
threat analysis, support for end-to-end security was made a 
requirement for the development of a new AAA protocol. 
RFC 4962 was developed in part to formalize that requirement,
and RFC 5247 was added to the EAP WG charter in order to provide
an analysis of the degree to which existing EAP/AAA implementations
complied with those requirements. 

In order to satisfy the requirements that eventually were codified
in RFC 4962, the AAA WG developed multiple proposals for
end-to-end transport of attributes through proxies; these included
CMS, Kerberos, and Redirect proposals.  Of these, the AAA WG eventually
settled on Diameter Redirect, and this proposal was included within
RFC 3588.  

Given all of this, AAA proxies have long been an area of focus within
the IETF, encompassing many man-years of work which have resulted in
more than a hundred pages of RFCs and Internet-Drafts relating to the
issue as well as many, many discussions and postings on the subject. 

Therefore to say that the implications are "not considered" seems
odd, given the amount of time that has been spent on this. 

   Doubts exist whether current security claims stated in RFCs and
   Internet Drafts are still valid for implementations with proxies.

"Doubts" is perhaps too weak a word -- RFC 5247 shows that many
of the fundamental security requirements can no longer be met
where proxies are present. 

   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.

Not sure that the term "unknowing" is appropriate here.  Given the 
volume of work, it would be quite hard for providers to plead ignorance.
Rather, the issue is more likely to be the difficulty of operating
and managing a network that addresses the problems. 

   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.

Proxies have become a fundamental aspect of the architecture of a
number of IETF protocols, including SMTP, SIP and AAA.  In each
case, implementers and deployers of those protocols are painfully
aware of the problems that they cause.  Also, in each case a number
of proposals have been made (such as domain certificates) to address
operational issues.  So I don't think you can say that proxies
have been neglected in the security considerations.

Section 1.1

   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.

As noted earlier, operational issues have proven to be a very difficult
challenge.  If you ignore these, I think you will miss the crux of the
problem. 

Section 2

  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.

Each of the above statements are not always true:

a.  The Diameter CMS, Redirect  and Kerberos proposals limited the 
ability of AAA proxies to modify attributes.  

b. Security schemes such as Diameter or RADSEC do not rely on 
pairwise AAA keys, but are based on certificates. 

c. Properly configured AAA servers *can* distinguish between AAA clients. 

d. Properly configured NASes *can* distinguish between AAA servers and proxies.

e. Some proposals *do* support distinguishing of proxy chains from single proxies
(e.g. RADIUS/Kerberos, Route Record functionality). 

Section 3

3. Related Work

   [Editor's note: what other references should be mentioned here?]

I'd look at RFC 5247, which discusses the EAP security model and the
effects of proxies (and AAA mis-configuration) in some detail.   There
are also the Diameter CMS and RADIUS/Kerberos proposals, the AAA
Requirements Documents, and discussions of proxy security and deployment
in the RADIUS, AAA, RADEXT, DIME and SIP WGs. 

Section 4.1

   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.

Given the prevalence of enterprise customer arrangements with 
access wholesalers and aggregators, many enterprise deployments
do in fact support inter-domain usage.  However, in those
deployments it's probably accurate to say that the enterprise
trusts the wholesaler/aggregator infrastructure. 

   Hierarchical proxy routing can
   further simplify key management, as has been pointed out in RFC 2607.

The Terena/EDUROAM experience is probably worth pointing out here, since
they are both using certificates (rather than symmetric keys), as well
as encountering issues with latency (leading to the desire for reduced
chain length).  