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

[Stefan Winter <[e-mail]>]

Hi Bernard,

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/proxies
>   


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]

_______________________________________________
Proxies mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/proxies