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

Hi,

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.

Klaas

> 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 <http://tools.ietf.org/html/rfc4962> [1 <http://tools.ietf.org/html/draft-hoeper-proxythreat-01#ref-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 <http://tools.ietf.org/html/rfc2607>.
>>
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/proxies
>>   
> 
> 

_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies