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

Klaas Wierenga <> Sat, 15 November 2008 12:18 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id EF4A33A68E0; Sat, 15 Nov 2008 04:18:04 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B2F93A68F5 for <>; Sat, 15 Nov 2008 04:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HaQoxzvUQI4Q for <>; Sat, 15 Nov 2008 04:18:02 -0800 (PST)
Received: from ( [IPv6:2001:610:508:110:192:87:110:29]) by (Postfix) with ESMTP id CFABF3A68B0 for <>; Sat, 15 Nov 2008 04:18:01 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1L1K68-00053t-Tj; Sat, 15 Nov 2008 13:17:57 +0100
Message-ID: <>
Date: Sat, 15 Nov 2008 13:16:34 +0100
From: Klaas Wierenga <>
User-Agent: Thunderbird (Windows/20080914)
MIME-Version: 1.0
To: Stefan Winter <>
References: <> <> <BLU137-W54E3AB48E6D604B591851E931F0@phx.gbl> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-Antivirus: no malware found
Cc: Bernard Aboba <>,,
Subject: Re: [proxies] Review of draft-hoeper-proxythreat-01.txt (Part 1)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


I am not very much in favor of mixing security considerations with
operational considerations of proxies. It is my understanding that these
are of a different nature. I would prefer to work from the assumption in
this document that we stay out of any debate about whether proxies are a
good or a bad thing but rather take it as a given and analyse the
security and privacy threats that result.

An operational considerations document would be a welcome separate
document, but let's not mix these two. In a way the latter document to
some extent will explain how the security threats can be overcome (in
addition to other operational considerations).

Or to put in yet another way, I believe the former document is more of a
theorteical exercise whereas the second is dealing with the practical
impact of this exercise.


> thanks a lot for this thorough review! I won't be able to answer you in
> all detail before leaving to MSP, but a few general remarks:
> as you may have seen, I've recently been invited as a co-author of this
> document. I was starting with the precondition that this document is
> strictly dealing with the *threats* which are introduced by proxies. I'm
> in line with your comments below though that it might make more sense to
> broaden the scope to include usage considerations about proxies.
> renaming it to, say, "AAA Proxy Operational Considerations" or so. If
> such a broadening of scope is seen as a good idea, I would certainly
> also be available to include the operational experience of the eduroam
> community, where I'm somewhat involved. I'm sure we will have one or
> another opportunity to discuss the course of the document in Minneapolis.
> Greetings,
> Stefan Winter
> Bernard Aboba schrieb:
>> 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).  
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Proxies mailing list

Proxies mailing list